시니어 개발자가 된 뒤, 다음 단계가 막막하신가요? “이제 매니저로 가야 하나, 계속 코드를 짜야 하나” 사이에서 고민하는 분들이 정말 많아요.
사실 시니어 다음에는 Staff Engineer라는 또 하나의 길이 있어요. 매니저가 되지 않고도 더 큰 임팩트를 만드는, IC(Individual Contributor) 트랙의 본격적인 시작점이에요. 이 글에서는 Staff Engineer가 정확히 어떤 자리이고, 어떻게 준비해야 하는지 정리해드릴게요.
핵심 메시지: Staff Engineer는 더 어려운 코드를 짜는 자리가 아니라, 더 큰 임팩트를 만드는 자리예요.
[이미지 placeholder] alt: 시니어에서 Staff로 이어지는 IC 트랙 사다리 일러스트
1. 시니어 다음, 정말 매니저밖에 없을까요?
많은 시니어 개발자들이 “관리자가 될 자신은 없는데, 그렇다고 시니어로 머무르고 싶진 않다”는 고민을 해요.
다행히 글로벌 빅테크에서는 오래전부터 두 갈래 사다리를 운영해 왔어요. 하나는 매니저 트랙(EM → Director → VP), 다른 하나는 기술 트랙인 IC 트랙이에요. IC 트랙의 일반적인 모습은 이렇게 정리돼요[2].
Junior → Engineer → Senior → Staff → Sr Staff → Principal → Distinguished
즉, 시니어가 끝이 아니라 그 위로 Staff, Senior Staff, Principal까지 이어지는 구조예요[2]. 이 흐름을 커리어 탐색이라는 관점으로 바라보면, 다음 5~10년의 방향을 잡기가 훨씬 수월해져요.
2. Staff Engineer는 어떤 자리인가요?
Will Larson은 그의 책 Staff Engineer에서 Staff를 이렇게 정의해요.
“A Staff engineer is a senior, individual contributor role in a Software Engineering organization.”[2]
쉽게 말해 시니어 개인 기여자 중에서 한 단계 더 올라간 자리예요. 매니저처럼 사람을 직접 관리하지는 않지만, 여러 팀에 걸친 기술 의사결정을 주도해요.
Senior와 Staff의 결정적 차이
항목 | Senior | Staff |
|---|---|---|
스코프 | 한 팀 | 여러 팀 / 조직 단위 |
시간 호라이즌 | 분기 (3개월) | 1~3년 |
평가 기준 | 개인의 코드 기여 | 다른 엔지니어를 임파워하는 임팩트 반경 |
권한 | 본인 코드 영역 | 조직 차원의 기술 방향 |
Alex Ewerlöf는 “Staff Engineering은 다른 엔지니어들을 임파워하는 임팩트 반경으로 측정되는 리더십 역할”이라고 설명해요[5]. 시니어가 “내가 짜는 코드”의 품질로 평가받는다면, Staff는 “내가 만든 변화가 얼마나 많은 사람을 움직였는가”로 평가받는 거예요.
보상은 얼마나 차이날까요?
미국 빅테크 기준의 자가신고 데이터를 보면 차이가 분명해요. levels.fyi에 보고된 Google의 사례예요[3].
레벨 | 직급 | 평균 토탈 패키지 (USD) |
|---|---|---|
L5 | Senior SWE | 약 $425,000 |
L6 | Staff SWE | 약 $599,000 |
L5에서 L6로 올라가는 것만으로 토탈 보상이 약 41% 상승해요[3]. 물론 한국 시장에 그대로 적용되지는 않지만, IC 트랙의 상단이 매니저 트랙 못지않게 보상이 크다는 점은 분명한 신호예요.
참고: levels.fyi 데이터는 자가신고 기반이라 정확한 평균이 아닌 “보고된 중간값”에 가까워요.
3. Staff Engineer의 4가지 아키타입
Will Larson은 Staff Engineer가 회사 안에서 맡는 역할을 4가지 아키타입으로 정리했어요[1]. 자기 성향에 맞는 아키타입을 찾는 게 첫 단추예요.
1) Tech Lead — 한 팀의 기술 방향타
“guides the approach and execution of a particular team.”[1]
한 팀의 기술 방향과 실행을 책임져요. 보통 한 명의 매니저와 짝을 이뤄 일하고, 대부분의 회사에서 가장 흔한 아키타입이에요[1].
2) Architect — 핵심 영역의 설계자
“responsible for the direction, quality, and approach within a critical area.”[1]
특정 도메인(예: 결제, 검색, 데이터 플랫폼)의 기술 방향과 품질, 다년간의 로드맵을 책임져요.
3) Solver — 어려운 문제 해결사
“digs deep into arbitrarily complex problems and finds an appropriate path forward.”[1]
조직이 막힌 어려운 문제를 깊이 파고들어서 해결해요. 한 영역에 오래 머물기도 하고, 핫스팟을 옮겨 다니기도 해요.
4) Right Hand — 임원의 오른팔
“a partner and an extension of an executive-level manager, borrowing their scope and authority.”[1]
엔지니어링 임원의 권한과 스코프를 빌려 큰 조직을 함께 운영해요. 수백 명 이상의 엔지니어 조직에서만 등장하는 아키타입이에요[1].
아키타입 | 가장 잘 어울리는 사람 |
|---|---|
Tech Lead | 팀 단위 실행과 사람 성장에 강한 시니어 |
Architect | 한 도메인을 깊이 파고드는 걸 좋아하는 엔지니어 |
Solver | 모호한 문제를 정의하고 푸는 데 능한 엔지니어 |
Right Hand | 큰 조직의 정치/전략까지 다루는 게 잘 맞는 엔지니어 |
4. Staff로 가기 위한 4가지 핵심 역량
기술적 깊이만으로는 부족해요. Ryan Peterman은 Staff 레벨의 일을 복잡성(Complexity), 임팩트(Impact), 스케일(Scale) 세 축으로 정의해요[4].
- Complexity: “Solving problems that senior engineers can't.”[4] - Impact: “Wins span more than just your team.”[4] - Scale: “Many engineers involved and roadmap spanning quarters.”[4]
이를 만들어내려면 다음 4가지가 함께 필요해요.
① 스코프를 한 팀 너머로 확장하기
Ryan Peterman은 “그런 스코프가 우리 팀에는 없을 수도 있다”며, 인접 팀이나 더 큰 조직과의 파트너십을 적극적으로 찾아 나서야 한다고 말해요[4]. 시니어처럼 매니저가 일을 던져 주길 기다리지 말고, 본인이 직접 큰 문제를 발견해야 해요.
② 글로 영향력 만들기 (테크 라이팅)
Staff 엔지니어는 권한 없이 사람을 움직여야 하는 자리예요[5]. 그래서 설계 문서, RFC, 포스트모템, 기술 전략 문서가 핵심 무기예요. 회의 한 번보다 잘 쓴 디자인 닥 한 편이 더 큰 결정을 만들어내요.
③ 영향력과 스폰서십
Alex Ewerlöf는 Staff의 핵심 책임으로 “mentorship, coaching, and sponsorship”을 꼽아요[5]. 후배에게 단순히 코드를 알려주는 게 아니라, 그들이 큰 프로젝트를 맡을 수 있도록 신뢰를 빌려주는 일(스폰서십) 까지 해야 해요.
④ Glue work를 ‘보이게’ 만들기
Tanya Reilly는 glue work — 멘토링, 코디네이션, 문서화, 누락된 일 챙기기 — 가 팀의 성공에 필수지만, 평가에서 잘 보이지 않는다고 지적해요[6]. 그래서 시니어 엔지니어가 글루 워크에만 매몰되면 “기술적 기여가 부족하다”는 피드백을 받기 쉬워요[6].
균형이 중요해요. 글루 워크를 하지 않는 것이 아니라, 임팩트로 변환해 보이게 만드는 것이 핵심이에요. 평소에 본인이 만든 변화를 꾸준히 기록해 두는 경험 관리 습관이 큰 도움이 돼요.
핵심 리트머스 테스트: “이 엔지니어는 좋은 롤모델인가?”[5]
5. 한국 개발자가 지금부터 할 수 있는 것
한국 IT 회사에서도 Staff/Principal 트랙이 존재할까요? 결론부터 말하면 회사마다 달라요.
네이버와 카카오는 자체 레벨 체계를 운영하고 있고, 쿠팡은 2015년경 비교적 일찍 미국식 IC 트랙을 도입한 편이에요[7]. 다만 “Staff Engineer”라는 직급명이 그대로 통용되는 곳은 많지 않고, 일반 IT 회사들은 별도의 엔지니어 레벨이 없는 경우도 흔해요[7]. 그래서 직급 이름에 매달리기보다 Staff급 임팩트를 만들어 두는 것이 우선이에요. 임팩트가 쌓이면 회사가 바뀌어도 자산이 되니까요.
오늘부터 시작할 수 있는 3가지를 추천드려요.
브래그 문서(Brag Document) 쓰기 — 분기마다 본인이 만든 임팩트(어떤 문제를, 누구와, 어떤 결과로 풀었는지)를 한 페이지로 정리해두세요. 이력서와 평가의 1차 자료가 돼요.
기술 글쓰기 루틴 만들기 — 사내 위키 글, 디자인 닥, 외부 블로그 글 어느 것이든 좋아요. 글이 곧 영향력의 통화예요[5].
크로스 팀 프로젝트 1개 잡기 — 우리 팀이 아닌 인접 팀의 문제를 같이 풀어보세요. Staff급 스코프는 보통 팀 ‘바깥’에서 발견돼요[4].
본인의 보유/필요 역량을 정리해 두고 싶다면 트리업의 스킬 관리 기능을 활용해보세요. 기술 스택뿐 아니라 멘토링·테크 라이팅 같은 소프트 스킬도 함께 추적할 수 있어요.
6. 마무리
정리하자면 Staff Engineer는,
그리고 Staff로 가는 길은 단순히 “더 어려운 코드”가 아니라, 스코프 확장 + 글쓰기 + 스폰서십 + 가시화된 글루 워크의 조합이에요[4][5][6].
작은 노력들이 모여 큰 성장을 만들어요. 이번 분기에는 “팀 바깥의 문제 하나”와 “디자인 닥 한 편”부터 시작해보시는 건 어때요?
