연봉 값을 하는 엔지니어의 비밀: "모르는 것(Ambiguity)"을 "할 수 있는 것"으로 바꾸는 기술
(terriblesoftware.org)핵심 요점:
- 시니어와 중간급 엔지니어를 가르는 결정적 차이는 불확실하고 모호한 문제를 구체화하는 능력임.
- 시니어의 가치는 코딩 기술 그 자체가 아니라, 프로젝트의 리스크를 제거하고 실행 가능한 계획으로 전환하는 데서 옴.
- 현재의 채용 관행(알고리즘 테스트 등)은 이러한 역량을 평가하는 데 실패하고 있음.
- 진정한 성장은 코딩 전 단계에서 문제를 명확히 정의하는 연습에서 시작됨.
서론: 시니어 엔지니어의 정의 재고
- 일반적으로 시니어 엔지니어는 아키텍처 설계, 커뮤니케이션, 리더십 등 다양한 기술 목록으로 정의됨.
- 그러나 직함, 연봉, 연차를 제외했을 때 시니어 이상의 엔지니어를 구분 짓는 단 하나의 핵심 기술은 '모호함을 줄이는 능력' 임.
- 다른 모든 역량(기술적 실행 등)은 이 핵심 기술을 바탕으로 파생되는 결과물임.
본론
1. 문제 해결 방식의 차이: 명확함 대 모호함
- 중간급(Mid-level) 엔지니어: 명확한 명세(Spec)와 제약 조건이 주어졌을 때 뛰어난 성과를 냄. 잘 정의된 문제를 해결하는 데 능숙함.
- 시니어 엔지니어: "성능 개선 필요", "사용자 불만 증가", "확장성 고려"와 같이 불분명하고 추상적인 요구사항을 받았을 때 차별화됨.
- 시니어는 모호한 문제를 단순히 수행하는 것이 아니라, 이를 분석하고 해체하여 구체적인 과제로 변환함.
2. 시니어의 핵심 역할은 프로젝트의 리스크 제거이다
-
시니어 엔지니어는 거대하고 추상적인 문제 앞에서 다음과 같은 접근을 통해 불확실성을 해소함:
-
남들이 하지 않는 본질적인 질문 제기.
-
중요한 신호와 소음(Noise)의 분리.
-
즉시 실행할 것과 미룰 것의 우선순위 결정.
-
이 과정은 프로젝트의 리스크를 낮추고(De-risking), "무엇인지 모르는 상태"를 "실행 가능한 작은 프로젝트와 제거할 요소"로 정리함.
-
시니어가 이를 잘 수행하면 프로젝트가 매끄럽게 진행되어 겉보기에는 쉬워 보이지만, 실제로는 사전에 막대한 '보이지 않는 작업'이 수행된 결과임.
3. 모호함을 해소하기 위한 구체적 접근법
- 시니어 엔지니어는 코딩에 앞서 문제를 명확히 하기 위해 다음과 같은 질문을 던짐:
- 문제의 본질: 우리가 원하는 솔루션이 아니라, 해결하려는 실제 근본 문제는 무엇인가?
- 사용자 정의: 구체적으로 누구의 어떤 고통을 해결하려 하는가? ("사용자"라는 포괄적 단어 지양)
- 가정 검증: 현재 계획에 숨겨진 잘못된 가정은 무엇인가?
- 리스크 평가: 우리의 판단이 틀렸을 때 발생할 최악의 상황은 무엇인가?
4. 채용 시스템의 한계와 잘못된 시니어 선발
- 대부분의 기업은 기술 스택 목록이나 알고리즘 문제 해결(LeetCode) 능력에 집중하여 채용을 진행함.
- 이러한 방식은 모호한 제품 요구사항을 실행 가능한 계획으로 변환하는 능력을 검증하지 못함.
- 결과적으로 코딩 실력은 뛰어나지만, 불완전한 명세 앞에서는 아무것도 하지 못하는 '무늬만 시니어' 엔지니어가 양산됨.
결론: 성장을 위한 제언
- 아키텍처나 커뮤니케이션 능력도 중요하지만, 이는 '무엇을 만들지' 가 명확해진 이후에야 가치를 발휘함.
- 모호함을 줄이지 못한 상태에서의 기술적 우수성은 '잘못된 문제를 우아하게 해결하는 것'에 불과함.
- 자신이 시니어 레벨인지 판단하는 기준은 추상적인 과제를 받았을 때 타인의 명확화 작업을 기다리는지, 아니면 스스로 팀이 실행할 수 있도록 구체화하는지에 달려 있음.
- 이는 타고난 재능이 아니라 연습의 영역이므로, 모호한 티켓(업무)을 받았을 때 즉시 코딩하기보다 문제를 구체화하는 훈련을 시작해야 함.
GeekNews Weekly에 포함된 글입니다.
에디터 코멘트 보기
댓글과 토론
시니어 개발자를 "알고리즘 코딩 테스트"로 확인하는 과정은 저도..채용 시스템의 한계라고 봅니다. 뭔가 문제의 본질에 가까워진 사람, 가까워질 수 있는 사람이 연봉값을 하는 시니어 개발자라 생각되네요.
보는 관점에 따라 제각각이란 걸 이 글에서 배우네요. 제 기준에는 시니어와 중간 엔지니어를 구분하는 기준은 단지 스코프라 생각합니다.
Ambiguity를 구체화 하는 건 엔지니어의 기본 소양이고 중간급 엔지니어부터 이걸 할 수 있어야 엔지니어라는 타이틀이 적합한 것 같습니다. 그래서 제게는 이 글이 중간급 엔지니어와 초보 (associate) 엔지니어를 가르는 기준이 될 수 있겠네요.
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이 급여 책정을 위해 만든 행정적 분류에 불과하다는 냉소적 의견 존재.
- 기업 간 격차: 빅테크 기업의 시니어(높은 모호함과 범위 해결)와 일반 기업의 시니어(단순 장기 근속자) 간의 역량 및 처우 격차가 매우 큼.