What Actually Makes you Senior

TL;DR

시니어 엔지니어를 정의하는 핵심은 코딩 실력이나 기술 스택이 아니라 **'모호함을 줄이는 능력(Reducing Ambiguity)'**입니다. 중간급 엔지니어가 명확한 명세를 받아 뛰어난 결과물을 만든다면, 시니어는 불분명한 요구사항을 분석하고 실행 가능한 구체적 계획으로 전환하여 프로젝트 리스크를 사전에 제거합니다. 이는 타고난 재능이 아닌 연습 가능한 기술이며, 코딩 전에 올바른 질문을 던지는 것부터 시작됩니다.

Key Takeaways

• 모호함 제거가 시니어의 핵심 역량: 아키텍처, 리더십 등 모든 기술은 '무엇을 만들지'가 명확해진 후에야 가치를 발휘하며, 불확실성 해소가 선행되어야 함
• De-risking이 진짜 가치: 시니어의 급여는 코딩 품질보다 "무엇인지 모르는 상태"를 "실행 가능한 작은 프로젝트"로 변환하여 프로젝트 실패 확률을 낮추는 능력에서 나옴
• 현재 채용 시스템의 맹점: LeetCode와 기술 스택 체크리스트는 모호한 요구사항을 다루는 실전 능력을 평가하지 못해 '무늬만 시니어'를 양산
• 본질적 질문이 출발점: "해결하려는 근본 문제는?", "우리의 가정 중 틀린 것은?", "실패 시 최악의 시나리오는?" 등의 질문으로 문제를 구체화
• 보이지 않는 작업의 가치: 시니어가 잘 일하면 프로젝트가 '너무 쉬워 보이지만', 실제로는 사전에 막대한 명확화 작업이 수행된 결과

상세 내용

시니어 엔지니어의 진짜 정의

일반적으로 시니어 엔지니어를 정의할 때 우리는 긴 체크리스트를 나열합니다. 아키텍처 설계, 커뮤니케이션, 오너십, 리더십, 멘토링... 하지만 직함과 연봉, 경력 연차를 모두 제거하고 나면, 시니어 이상의 엔지니어를 실질적으로 구분 짓는 핵심 기술은 단 하나입니다.

모호함을 줄이는 능력(Reducing Ambiguity)

다른 모든 역량은 이 기본 능력을 토대로 파생됩니다. 아무리 뛰어난 아키텍처 설계 능력이 있어도, 무엇을 만들어야 하는지 명확하지 않다면 그 기술은 방향을 잃습니다.

중간급 vs 시니어: 문제 해결 방식의 본질적 차이

중간급(Mid-level) 엔지니어의 강점은 명확한 문제 해결입니다. 잘 정의된 명세(Spec)와 합리적인 제약 조건이 주어지면 탁월한 결과물을 만들어냅니다. 이것 자체로도 충분히 가치 있는 능력입니다.

하지만 문제의 성격이 바뀌면 상황이 달라집니다:

• "성능을 개선해야 합니다"
• "사용자들이 온보딩 플로우에 대해 불만을 제기하고 있습니다"
• "확장성을 고려해야 할 것 같습니다"

이처럼 모호하고 추상적인 요구사항 앞에서 시니어 엔지니어와의 차이가 드러납니다. 이는 중간급 엔지니어가 능력이 부족해서가 아니라, 불확실한 문제는 근본적으로 다른 접근법을 요구하기 때문입니다.

시니어 엔지니어는 크고 복잡하고 추상적인 문제를 받으면 즉시 분석을 시작합니다:

• 다른 사람들이 생각하지 못한 질문을 던짐
• 중요한 신호와 노이즈를 분리
• 지금 해야 할 것과 미뤄도 될 것을 구분

프로젝트 De-risking: 시니어의 핵심 가치

시니어 엔지니어가 높은 급여를 받는 이유는 단순히 좋은 코드를 작성하기 때문만은 아닙니다(물론 그것도 중요하지만). 진짜 가치는 프로젝트의 리스크를 제거(De-risk)하는 데 있습니다.

그들은 "이게 뭔지도 모르겠는" 상태를 "2개의 작은 프로젝트와 1개의 제거해야 할 요소"로 구체화합니다. 이 과정에서:

• 불필요한 서프라이즈 감소
• 프로덕션 장애 최소화
• 긴급 회의 빈도 축소

흥미로운 점은 시니어가 이 일을 잘 수행하면 '아무것도 한 것 같지 않아' 보인다는 것입니다. 프로젝트가 그냥 순조롭게 진행됩니다. 하지만 실제로는 사전에 엄청난 양의 '보이지 않는 작업(Invisible Work)'이 수행되었습니다.

모호함을 해소하는 구체적 질문들

시니어 엔지니어는 코딩에 앞서 문제를 명확히 하기 위해 다음과 같은 질문을 던집니다:

1. 실제로 해결하려는 문제는 무엇인가?

• 우리가 원하는 솔루션이 아니라, 근본적인(Underlying) 문제를 찾음
• 예: "사용자가 원하는 기능"이 아닌 "사용자가 겪는 고통"

2. 사용자는 구체적으로 누구이며, 무엇이 그들에게 고통스러운가?

• "사용자들"이라는 포괄적 답변을 거부
• 특정 페르소나와 구체적 맥락을 정의

3. 우리가 전제하고 있는 것 중 틀린 것은 무엇인가?

• 모든 계획에는 숨겨진 가정들이 있음
• 이를 명시적으로 끄집어내어 검증

4. 잘못 판단했을 때 최악의 시나리오는?

• 실패의 다운사이드를 미리 평가
• 되돌릴 수 없는 결정과 실험 가능한 변경을 구분

이러한 질문들은 먼저 문제를 명확하게 만들고, 그 다음에야 해결에 착수하는 순서를 강제합니다.

채용 시스템이 놓치고 있는 것

안타깝게도 많은 기업들은 여전히 이 핵심 역량을 평가하는 데 실패하고 있습니다:

현재 채용 프로세스의 문제점:

• 직무 기술서는 기술 스택과 경력 연차만 나열
• 면접은 LeetCode 스타일 알고리즘 문제에 집중
• 모호한 제품 요구사항을 실행 가능한 계획으로 변환하는 능력은 측정하지 않음

결과적으로: 화이트보드에서 이진 트리를 뒤집는 데는 능숙하지만, 명세가 불완전하면 얼어붙는 시니어 엔지니어들이 양산됩니다. 코딩 실력은 뛰어나지만 불확실성 앞에서는 무력한 '무늬만 시니어'입니다.

AI Research Engineer 관점에서의 적용

이 원칙은 AI/ML 분야에서 특히 중요합니다:

AI 프로젝트의 전형적인 모호한 요구사항들:

• "모델 성능을 개선해야 합니다"
• "추천 시스템이 더 개인화되어야 합니다"
• "LLM 응답 품질을 높여야 합니다"

시니어 AI Research Engineer의 접근:

• 어떤 메트릭으로 무엇을 측정할 것인가?
• 성능 저하의 근본 원인은 데이터인가, 모델인가, 인프라인가?
• A/B 테스트 설계 시 최소 유의미한 효과 크기는?
• 모델 개선이 비즈니스 목표와 어떻게 연결되는가?

성장을 위한 실천 방법

모호함 해소 능력은 타고난 재능이 아닌 연습 가능한 기술입니다. 다음과 같이 시작할 수 있습니다:

1. 코딩 전 일시정지 습관: 티켓을 받았을 때 즉시 코드를 작성하는 대신, 10분간 문제를 구체화하는 시간을 가지세요

2. "왜?"를 5번 묻기: 요구사항 뒤에 숨은 진짜 문제를 찾을 때까지 질문을 반복하세요

3. 가정 명시하기: 프로젝트 시작 전 "우리가 맞다고 가정하는 것들" 리스트를 작성하고 팀과 공유하세요

4. Post-mortem에서 배우기: 프로젝트가 끝난 후 "초기에 어떤 질문을 했다면 문제를 예방할 수 있었을까?" 돌아보세요

마무리: 우아하게 틀린 문제를 푸는 함정

아키텍처와 커뮤니케이션 능력도 중요합니다. 하지만 이런 기술들은 '무엇을 만들지'가 명확해진 이후에야 진가를 발휘합니다.

모호함을 줄이지 못한 채 발휘되는 기술적 우수성은 '잘못된 문제를 우아하게 해결하는 것'에 불과합니다. 완벽한 아키텍처로 설계되었지만 아무도 원하지 않는 기능, 깔끔한 코드로 구현되었지만 본질적 문제는 해결하지 못하는 솔루션.

자신이 시니어 레벨에서 일하고 있는지 판단하는 기준:

• 추상적인 과제를 받았을 때, 누군가 명확히 해주기를 기다리는가?
• 아니면 스스로 팀이 실행할 수 있도록 구체화하는가?

그 차이가 바로 시니어를 정의합니다.

References

• What Actually Makes You Senior - Terrible Software