주니어와 시니어 엔지니어의 차이는 그들이 작성하는 코드가 아니다

Source: Dev.to

Seniors Design for Failure First

주니어 엔지니어는 행복한 경로만 구축합니다: 사용자가 가입하고, 데이터가 저장되고, 응답이 반환됩니다. 개발 환경에서는 모든 것이 정상적으로 동작하지만, 프로덕션에서는 모든 것이 깨집니다.

시니어 엔지니어는 “실패가 발생하면 어떻게 될까?”라는 질문부터 시작합니다. 외부 API 호출에 회로 차단기(circuit breaker)를 추가해 하나의 다운스트림 타임아웃이 전체 장애로 이어지지 않게 합니다. DynamoDB TTL을 설정해 오래된 데이터를 자동으로 만료시켜 테이블이 무한히 커지는 것을 방지합니다. 첫날부터 SQS 데드레터 큐를 연결해 실패한 메시지가 조용히 사라지지 않도록 합니다.

차이는 편집증이 아니라 경험입니다. 제3자 API가 다운돼 전체 서비스가 중단돼 새벽 2시에 깨던 경험이 있다면, 다시는 실패 처리를 건너뛰지 않을 것입니다.

시니어는 코드를 쓰기보다 더 많이 읽는다

주니어 엔지니어가 새로운 작업을 받으면 빈 파일을 열고 바로 코딩을 시작합니다. 시니어 엔지니어가 같은 작업을 받으면 처음 30 분을 기존 코드베이스를 읽는 데 사용합니다.

이는 느림이 아니라 정확성입니다. 그들은 이미 존재하는 패턴, 공유 유틸리티, 네이밍 규칙, 그리고 아키텍처 결정 등을 찾아봅니다. 새로운 것을 추가하기 전에 무엇이 이미 있는지 이해하고 싶어합니다.

제가 미국 클라이언트를 위해 작업하고 있는 NestJS monorepo에는 공유 모듈, 커스텀 데코레이터, 그리고 몇 주에 걸쳐 구축된 TypeORM 레포지토리 패턴이 있습니다. 읽는 단계를 건너뛰는 주니어는 로직을 중복하고, 규칙을 깨며, 다음 스프린트에서 다른 사람이 정리해야 할 기술 부채를 만들게 됩니다.

코드를 읽는 것은 가장 과소평가된 엔지니어링 스킬입니다. 제가 함께 일한 최고의 엔지니어들은 코딩보다 읽는 데 더 많은 시간을 투자합니다. 그들은 기존 패턴을 재사용할 만큼 코드베이스를 잘 파악하고 있어, 새로 만들 필요 없이 작업 시간을 절반으로 줄이고 버그를 한 차원 낮출 수 있습니다.

Seniors Debug the System, Not the Symptom

주니어 엔지니어는 500 오류를 보고, 예외가 발생한 라인을 찾아 try‑catch를 추가하고 넘어갑니다. 버그가 수정된 것처럼 보이지만, 실제로는 그렇지 않습니다.

시니어 엔지니어는 CloudWatch Logs를 통해 요청 흐름을 추적하고, Lambda 콜드‑스타트 지연 시간을 확인하며, DynamoDB 사용 용량을 검토한 뒤, 실제 근본 원인이 두 개의 상위 서비스에 있음을 발견합니다: 로드가 걸릴 때 중복 처리를 일으키는 잘못 구성된 SQS 가시성 타임아웃.

증상은 500 오류였지만, 원인은 6개월 전에 배포된 뒤 아무도 살펴보지 않은 큐 설정이었습니다. 시니어는 증상을 고치는 것이 아니라 전체 경로를 추적하고 시스템 자체를 고칩니다.

이것이 관측성 도구가 비용을 정당화하는 이유입니다. 구조화된 로깅, 분산 추적, CloudWatch 대시보드가 없으면 추측에 의존해 디버깅하게 됩니다. 시니어는 필요하기 전에 관측성을 구축합니다.

Seniors Ask “What Happens at 10×?”

주니어는 현재 가지고 있는 트래픽을 기준으로 설계합니다. 시니어는 6개월 후에 예상되는 트래픽을 기준으로 설계합니다.

이는 조기 최적화를 의미하는 것이 아니라, 모든 아키텍처 결정 전에 한 가지 질문을 던지는 것입니다: “현재 부하의 10배가 되었을 때는 어떻게 될까?”

제가 Menthera의 실시간 음성 AI 시스템을 구축할 때, 처음부터 애플리케이션과 DynamoDB 사이에 Redis 캐시 레이어를 추가했습니다. 이는 첫 날부터 규모 문제가 있었기 때문이 아니라, 동시 WebRTC 세션이 읽기 캐시 없이 데이터베이스를 과부하시킬 것이라는 점을 알고 있었기 때문입니다.

시니어는 트래픽 급증이 발생하기 전에 파티션 전략, 커넥션 풀, 캐시 레이어, 그리고 레이트 리미터를 추가합니다—정전이 발생한 뒤가 아니라. 이러한 요소들을 나중에 추가하는 비용은 처음부터 설계에 포함시키는 비용보다 항상 더 높습니다.

실제 차이

대부분의 엔지니어는 코드를 작성하는 데 최적화합니다. 시니어 엔지니어는 not 코드를 작성하는 데 최적화합니다.

• 그들은 쓰기 전에 읽습니다.
• 그들은 기능을 설계하기 전에 실패를 설계합니다.
• 그들은 패치하기 전에 추적합니다.
• 그들은 필요하기 전에 확장을 계획합니다.

코드 자체는 업무에서 가장 중요하지 않은 부분입니다. 코드 주변의 시스템이 전부입니다.

이 중 하나만 기억한다면: 다음에 무언가를 만들기 위해 앉을 때, 코드를 쓰는 것을 제외한 모든 일에 첫 한 시간을 투자하세요. 기존 코드베이스를 읽고, 실패 처리 로직을 추가하고, 가시성을 설정하고, 10× 상황을 물어보세요. 그런 다음 코드를 작성하세요. 더 빠르게 배포하고 더 편안히 잘 수 있습니다.

엔지니어링 접근 방식을 바꾼 한 가지 습관은 무엇인가요?