연봉 값을 하는 엔지니어의 비밀: "모르는 것(Ambiguity)"을 "할 수 있는 것"으로 바꾸는 기술
(terriblesoftware.org)핵심 요점:
- 시니어와 중간급 엔지니어를 가르는 결정적 차이는 불확실하고 모호한 문제를 구체화하는 능력임.
- 시니어의 가치는 코딩 기술 그 자체가 아니라, 프로젝트의 리스크를 제거하고 실행 가능한 계획으로 전환하는 데서 옴.
- 현재의 채용 관행(알고리즘 테스트 등)은 이러한 역량을 평가하는 데 실패하고 있음.
- 진정한 성장은 코딩 전 단계에서 문제를 명확히 정의하는 연습에서 시작됨.
서론: 시니어 엔지니어의 정의 재고
- 일반적으로 시니어 엔지니어는 아키텍처 설계, 커뮤니케이션, 리더십 등 다양한 기술 목록으로 정의됨.
- 그러나 직함, 연봉, 연차를 제외했을 때 시니어 이상의 엔지니어를 구분 짓는 단 하나의 핵심 기술은 '모호함을 줄이는 능력' 임.
- 다른 모든 역량(기술적 실행 등)은 이 핵심 기술을 바탕으로 파생되는 결과물임.
본론
1. 문제 해결 방식의 차이: 명확함 대 모호함
- 중간급(Mid-level) 엔지니어: 명확한 명세(Spec)와 제약 조건이 주어졌을 때 뛰어난 성과를 냄. 잘 정의된 문제를 해결하는 데 능숙함.
- 시니어 엔지니어: "성능 개선 필요", "사용자 불만 증가", "확장성 고려"와 같이 불분명하고 추상적인 요구사항을 받았을 때 차별화됨.
- 시니어는 모호한 문제를 단순히 수행하는 것이 아니라, 이를 분석하고 해체하여 구체적인 과제로 변환함.
2. 시니어의 핵심 역할은 프로젝트의 리스크 제거이다
-
시니어 엔지니어는 거대하고 추상적인 문제 앞에서 다음과 같은 접근을 통해 불확실성을 해소함:
-
남들이 하지 않는 본질적인 질문 제기.
-
중요한 신호와 소음(Noise)의 분리.
-
즉시 실행할 것과 미룰 것의 우선순위 결정.
-
이 과정은 프로젝트의 리스크를 낮추고(De-risking), "무엇인지 모르는 상태"를 "실행 가능한 작은 프로젝트와 제거할 요소"로 정리함.
-
시니어가 이를 잘 수행하면 프로젝트가 매끄럽게 진행되어 겉보기에는 쉬워 보이지만, 실제로는 사전에 막대한 '보이지 않는 작업'이 수행된 결과임.
3. 모호함을 해소하기 위한 구체적 접근법
- 시니어 엔지니어는 코딩에 앞서 문제를 명확히 하기 위해 다음과 같은 질문을 던짐:
- 문제의 본질: 우리가 원하는 솔루션이 아니라, 해결하려는 실제 근본 문제는 무엇인가?
- 사용자 정의: 구체적으로 누구의 어떤 고통을 해결하려 하는가? ("사용자"라는 포괄적 단어 지양)
- 가정 검증: 현재 계획에 숨겨진 잘못된 가정은 무엇인가?
- 리스크 평가: 우리의 판단이 틀렸을 때 발생할 최악의 상황은 무엇인가?
4. 채용 시스템의 한계와 잘못된 시니어 선발
- 대부분의 기업은 기술 스택 목록이나 알고리즘 문제 해결(LeetCode) 능력에 집중하여 채용을 진행함.
- 이러한 방식은 모호한 제품 요구사항을 실행 가능한 계획으로 변환하는 능력을 검증하지 못함.
- 결과적으로 코딩 실력은 뛰어나지만, 불완전한 명세 앞에서는 아무것도 하지 못하는 '무늬만 시니어' 엔지니어가 양산됨.
결론: 성장을 위한 제언
- 아키텍처나 커뮤니케이션 능력도 중요하지만, 이는 '무엇을 만들지' 가 명확해진 이후에야 가치를 발휘함.
- 모호함을 줄이지 못한 상태에서의 기술적 우수성은 '잘못된 문제를 우아하게 해결하는 것'에 불과함.
- 자신이 시니어 레벨인지 판단하는 기준은 추상적인 과제를 받았을 때 타인의 명확화 작업을 기다리는지, 아니면 스스로 팀이 실행할 수 있도록 구체화하는지에 달려 있음.
- 이는 타고난 재능이 아니라 연습의 영역이므로, 모호한 티켓(업무)을 받았을 때 즉시 코딩하기보다 문제를 구체화하는 훈련을 시작해야 함.
1. 질문의 기술과 사회적 자본 (Social Capital)
- 전략적 무지: 시니어의 질문은 무지에서 비롯된 것이 아니라, 불확실성을 제거하기 위한 의도적 행위임. 기초적인 질문("이 약어가 무엇인가?")을 부끄러움 없이 던지는 것이 핵심 역량.
- 사회적 자본 활용: 주니어와 달리 시니어는 '사회적 자본(신뢰)'이 구축되어 있어, "바보 같은 질문"을 해도 능력 없다는 평가를 받지 않음. 이를 활용해 회의의 모호함을 걷어내는 것이 시니어의 역할.
- 정치적 맥락 고려: 명확성을 기피하는 관리자에게 직설적인 질문은 위협이 될 수 있음. 따라서 정치적으로 안전하면서도 프로젝트를 진전시키는 질문을 선별하는 고도의 처세술이 요구됨.
2. 자율성과 리스크 관리 (Autonomy & Risk)
- 안전망 없는 문제 해결: 외부의 도움이나 명확한 지침 없이도 스스로 문제를 돌파(Plough through)하고 완수하는 능력이 시니어의 기준.
- 카오스(Chaos) 통제: 무조건적인 명확성보다는 상황에 맞춰 '멈춤'과 '전진'을 결정함. 완벽한 스펙을 기다리기보다 적절한 가정을 세워 실행(Ship)함으로써 혼란을 줄임.
- 계산된 리스크 감수: 컴파일되지 않는 코드를 런타임에 수정하거나 대규모 리팩토링을 감행하는 등, 주니어가 할 수 없는 과감한 기술적 결단을 내리고 그 결과에 책임을 짐.
3. 직함 인플레이션과 채용의 구조적 모순
- 직함 인플레이션(Title Inflation): 성과 지표 달성을 위해 준비되지 않은 주니어를 시니어로 승진시키는 관행이 만연함. 이로 인해 타이틀과 실제 역량 간의 괴리가 발생.
- 채용 방식의 한계: 기업들이 모호한 요구사항을 구체화하는 능력이 아닌, 알고리즘(LeetCode) 문제 해결 능력에만 집중하여 채용함. 결과적으로 '스펙이 없으면 아무것도 못 하는 시니어'가 양산됨.
- PM 역할의 대리 수행: 시니어 엔지니어가 게으른 PM이 던진 불완전한 기획(Half-baked spec)을 구체화하는 데 시간을 쏟는 현상이 발생함. 이는 엔지니어의 역량이기도 하지만 조직적 비효율의 방증임.
4. 단순 경력(Tenure) 대 의도적 수련
- 경력의 질적 차이: "10년의 성장"과 "1년의 경험을 10번 반복한 것"은 명확히 구분되어야 함. 진정한 시니어는 익숙한 영역을 벗어난 의도적 연습과 도전을 통해 형성됨.
-
If vs What-if: 주니어는 주어진 조건(
If)을 처리하는 데 집중하지만, 시니어는 조건이 변할 경우(What-if)를 가정하고 대비함. - 성장 단계 정의: 업계의 보편적 기준은 '지도를 받는 단계(Junior)' → '독립 수행 단계(Regular)' → '타인을 지도하는 단계(Senior)'로 구분됨.
5. 시니어 타이틀에 대한 회의적 시각
- 단순 급여 등급(Pay Grade): 시니어라는 호칭은 역량의 지표라기보다, HR이 급여 책정을 위해 만든 행정적 분류에 불과하다는 냉소적 의견 존재.
- 기업 간 격차: 빅테크 기업의 시니어(높은 모호함과 범위 해결)와 일반 기업의 시니어(단순 장기 근속자) 간의 역량 및 처우 격차가 매우 큼.