목차

1. 엔지니어링 커리어 래더

소프트웨어 엔지니어의 커리어 성장 경로는 크게 두 트랙으로 나뉩니다:

**IC (Individual Contributor) 트랙:**

Junior → Mid-level → Senior → Staff → Senior Staff → Principal → Distinguished Fellow

**Management 트랙:**

Senior → Tech Lead → Engineering Manager → Senior EM → Director → VP of Engineering → CTO

대부분의 회사에서 Senior 레벨까지는 동일한 경로를 따르며, 그 이후 IC와 Manager 트랙으로 분기됩니다.

| 레벨 | 경력 (일반적) | 영향 범위 | 자율성 | 모호성 대응 |

|------|------------|----------|-------|-----------|

| **Junior** | 0-2년 | 태스크 | 지시 수행 | 명확한 문제 |

| **Mid** | 2-4년 | 기능(Feature) | 일부 자율 | 약간의 모호성 |

| **Senior** | 4-7년 | 프로젝트/팀 | 자율적 | 모호한 문제 정의 |

| **Staff** | 7-12년 | 여러 팀/조직 | 완전 자율 | 모호한 문제 발견 |

| **Principal** | 12년+ | 회사 전체 | 방향 설정 | 업계 수준의 모호성 |

| **Distinguished** | 15년+ | 업계 | 새로운 분야 개척 | 미지의 영역 |

2. 각 레벨이 실제로 의미하는 것

영향 범위 (Scope of Impact)

가장 중요한 성장 지표는 **영향 범위**입니다:

- **Junior:** "이 함수가 올바르게 동작하는가?"

- **Mid:** "이 기능이 요구사항을 충족하는가?"

- **Senior:** "이 시스템이 확장 가능하고 유지보수 가능한가?"

- **Staff:** "이 아키텍처가 조직의 3년 로드맵에 적합한가?"

- **Principal:** "이 기술 전략이 회사의 비즈니스 목표에 부합하는가?"

자율성 (Autonomy)

| 레벨 | 자율성 수준 |

|------|-----------|

| Junior | 무엇을(what), 어떻게(how) 모두 지시받음 |

| Mid | 무엇을 지시받고, 어떻게는 스스로 결정 |

| Senior | 무엇을 함께 정하고, 어떻게는 자율 결정 |

| Staff | 왜(why)를 이해하고, 무엇을을 스스로 정의 |

| Principal | 왜를 설정하고, 조직의 방향에 영향 |

모호성 대응 (Dealing with Ambiguity)

성장할수록 **더 모호한 문제**를 다뤄야 합니다:

- Junior: "이 버그를 고쳐주세요" (명확)

- Mid: "이 페이지의 성능을 개선해주세요" (약간 모호)

- Senior: "사용자 경험을 개선해주세요" (모호)

- Staff: "시스템 아키텍처의 방향을 제시해주세요" (매우 모호)

- Principal: "향후 5년간의 기술 전략을 세워주세요" (극도로 모호)

3. 주니어 → 미드레벨 (1-3년)

핵심 역량

1. **코드 품질** — 깨끗하고 읽기 쉬운 코드 작성

2. **디버깅 능력** — 문제의 근본 원인을 찾는 체계적 접근

3. **코드 리뷰** — 다른 사람의 코드에서 배우기, 건설적 피드백

4. **추정 능력** — 작업 시간을 합리적으로 예측

5. **기본기 강화** — 자료구조, 알고리즘, 네트워크, OS 기초

구체적 행동 지침

DO:

- 질문하되, 먼저 조사하고 질문하기 (15분 규칙)

- 코드 리뷰에서 '왜 이렇게 했는지' 질문하기

- PR을 작게, 자주 올리기

- 테스트 코드 작성 습관화

- 매일 학습 노트 기록

DON'T:

- 혼자 끙끙대며 하루 종일 고민하기

- 이해 못했는데 고개 끄덕이기

- 완벽한 코드를 만들겠다고 PR 미루기

- 동료의 코드를 비판하기 (건설적 피드백과 다름)

성장 체크리스트

- 담당 컴포넌트의 코드를 완전히 이해하는가?

- 버그를 체계적으로 추적하고 재현할 수 있는가?

- 기술 문서를 작성하고 다른 개발자가 이해할 수 있는가?

- 온콜(on-call) 로테이션에 참여할 수 있는가?

- 팀의 개발 프로세스와 도구를 효율적으로 사용하는가?

4. 미드레벨 → 시니어 (3-5년)

핵심 전환점

미드레벨에서 시니어로의 전환은 **개인 기여에서 팀 기여로의 전환**입니다.

시니어의 기대치

1. **프로젝트 오너십** — 기능을 처음부터 끝까지 책임지고 delivery

2. **멘토링** — 주니어/미드레벨 개발자를 성장시킴

3. **시스템 설계** — 확장 가능한 시스템을 설계하고 기술적 의사결정

4. **기술 부채 관리** — 리팩토링의 시기와 범위를 판단

5. **크로스 팀 협업** — PM, 디자이너, 다른 팀과 효과적 소통

시니어 엔지니어가 하는 일

기술적 의사결정:

- "Kafka vs RabbitMQ — 우리 사용 사례에는 Kafka가 적합합니다. 이유는..."

- "이 서비스는 마이크로서비스로 분리할 때가 되었습니다"

- "이 기술 부채는 이번 분기에 해결해야 합니다"

팀 기여:

- 코드 리뷰에서 아키텍처적 피드백 제공

- RFC(Request for Comments) 문서 작성

- 온보딩 문서 정리

- 장애 대응 및 포스트모템 주도

시니어로의 승진을 위한 전략

1. **성과 문서(Brag Document) 시작** — 매주 성과를 기록

2. **가시성 확보** — 팀 밖에서도 당신의 기여를 알게 하기

3. **갭 분석** — 현재 레벨과 다음 레벨의 차이를 파악

4. **스폰서십 확보** — 당신을 밀어줄 시니어/매니저 찾기

5. **"이미 그 레벨에서 일하기"** — 승진 전에 이미 다음 레벨의 업무를 수행

5. 시니어 → Staff (5-8년)

Staff 엔지니어란?

Staff 엔지니어는 **팀을 넘어서는 기술적 영향력**을 가진 사람입니다.

Will Larson의 "Staff Engineer" 책에서 정의한 4가지 아키타입:

| 아키타입 | 설명 | 적합한 사람 |

|---------|------|-----------|

| **Tech Lead** | 팀의 기술적 방향 이끔 | 팀 리더십 + 기술력 |

| **Architect** | 기술적 비전과 방향 설정 | 깊은 시스템 설계 능력 |

| **Solver** | 가장 어려운 문제를 해결 | 깊은 전문성 |

| **Right Hand** | 조직 리더의 기술적 파트너 | 넓은 시야 + 실행력 |

Staff 레벨의 핵심 차이

**시니어:** "이 시스템을 잘 만들겠습니다"

**Staff:** "조직이 올바른 시스템을 만들도록 이끌겠습니다"

Staff 엔지니어의 일상:

- **30% 코딩** — 전략적 프로토타입, 핵심 코드 리뷰, 기술적 방향 코드

- **30% 기술 전략** — RFC 작성, 아키텍처 리뷰, 기술 로드맵

- **20% 멘토링/교육** — 시니어 개발자 성장 지원, 기술 토크

- **20% 조직 영향** — 채용 면접, 프로세스 개선, 크로스팀 조율

Staff 승진 전략

1. **조직 수준의 문제를 찾고 해결하기**

- "우리 팀" → "우리 조직"으로 시야 확장

- 여러 팀에 영향을 미치는 기술적 결정을 주도

2. **기술 전략 문서 작성**

- RFC, ADR(Architecture Decision Record), 기술 비전 문서

- 이것이 Staff의 핵심 산출물(artifact)

3. **multiplier 효과 입증**

- 본인의 직접적 성과보다 **다른 사람을 더 효과적으로 만드는 능력**

- "나 때문에 팀이 30% 더 빨라졌다"

4. **스폰서십은 필수**

- Staff 이상은 자격만으로는 부족 — 적극적으로 밀어주는 시니어 리더 필요

- Skip-level 1:1에서 당신의 영향력을 공유

6. Staff+ (8년+)

Principal 엔지니어

Principal은 **회사 전체의 기술 방향**에 영향을 미칩니다:

- 3-5년 기술 전략 수립

- 회사의 기술 스택 결정에 핵심 역할

- 업계 컨퍼런스 발표, 기술 블로그 리더십

- 채용에서 시니어급 인재 판단

- CEO/CTO에게 기술적 조언

Distinguished/Fellow

업계 수준의 영향력:

- 오픈소스 프로젝트 주도 (예: React, Kubernetes의 창시자)

- 학술 논문 발표

- 새로운 기술 패러다임 정의

- 업계 표준 수립에 참여

7. IC vs Manager: 경로 선택

비교 표

| 항목 | IC 트랙 | Manager 트랙 |

|------|--------|-------------|

| **일상 업무** | 코딩, 설계, 기술 전략 | 1:1, 채용, 프로세스 관리 |

| **성과 측정** | 기술적 산출물, 영향력 | 팀 성과, 인원 성장 |

| **에너지원** | 기술적 문제 해결 | 사람 성장 지원 |

| **스트레스원** | 기술적 복잡성 | 조직 정치, 갈등 관리 |

| **성장 한계** | Principal/Fellow | VP/CTO |

| **이직 용이성** | 높음 (스킬 이전 용이) | 중간 (조직 맥락 의존) |

| **번아웃 원인** | 기술 변화 피로 | 관계 갈등, 정치 |

IC를 선택해야 하는 신호

- 코딩할 때 가장 에너지가 넘친다

- 기술적 문제를 깊이 파고드는 것을 즐긴다

- 1:1 미팅보다 코드 리뷰가 더 기대된다

- 다른 사람의 성과보다 자신의 기술적 기여에 보람을 느낀다

- 조직 정치에 관심이 없다

Manager를 선택해야 하는 신호

- 다른 사람의 성장을 보며 보람을 느낀다

- 팀의 프로세스와 문화를 개선하고 싶다

- 기술적 문제보다 조직적 문제에 관심이 간다

- 1:1 미팅에서 에너지를 얻는다

- 채용, 온보딩, 피드백 프로세스를 만들고 싶다

언제 트랙을 바꿀 수 있는가?

돌아갈 수 있습니다. Manager에서 IC로 돌아가는 "pendulum" 패턴이 점점 보편화되고 있습니다. 다만:

- Manager로 2년 이상 있으면 코딩 실력이 녹슬 수 있음

- IC로 돌아갈 때 레벨이 낮아질 수 있음

- 양쪽 경험은 어느 트랙에서든 큰 자산

8. 테크 리드: 하이브리드 경로

테크 리드란?

테크 리드는 IC와 Manager의 하이브리드입니다:

- **50-70% 기술:** 코딩, 아키텍처 결정, 코드 리뷰

- **30-50% 리더십:** 프로젝트 계획, 팀 조율, 이해관계자 소통

테크 리드의 핵심 역할

1. **기술적 비전 설정** — 팀의 기술 방향 결정

2. **프로젝트 실행 책임** — 일정, 품질, 리스크 관리

3. **기술 멘토링** — 팀원의 기술적 성장 지원

4. **크로스 팀 소통** — PM, 디자인, 다른 엔지니어링 팀과 조율

5. **기술 부채 관리** — 리팩토링 계획 수립 및 실행

테크 리드의 흔한 함정

함정 1: 모든 코드를 직접 짜려 한다

→ 해결: 전략적 코드에만 집중, 나머지는 위임

함정 2: 기술만 잘하면 된다고 생각한다

→ 해결: 소통, 갈등 해결, 프로젝트 관리 스킬 필요

함정 3: 본인이 병목이 된다

→ 해결: 결정을 문서화하고, 팀원이 자율적으로 결정하도록 가이드라인 제공

함정 4: 개인 기여에만 평가받으려 한다

→ 해결: 팀의 성과 = 나의 성과로 인식

9. 승진 전략

9.1 성과 문서 (Brag Document)

매주 15분 투자하여 자신의 성과를 기록합니다:

성과 문서 템플릿

2026 Q1

프로젝트

- [대규모] 결제 시스템 마이그레이션 주도 — 레이턴시 40% 감소

- [중규모] 온보딩 자동화 구축 — 신규 개발자 적응 기간 2주→3일

기술 리더십

- RFC 3건 작성 (인증 시스템 개선, API 버전 관리 전략, 모니터링 표준화)

- 아키텍처 리뷰 주 2회 참여

멘토링

- 주니어 개발자 2명 멘토링 (1명 미드레벨 승진 성공)

- 기술 세미나 "시스템 설계 기초" 발표

조직 영향

- 채용 면접관 12회 (3명 합격)

- 배포 프로세스 개선으로 배포 빈도 주 1회→일 3회

9.2 가시성 확보

- **팀 내:** 데모 발표, 기술 세미나, 코드 리뷰 리더

- **조직 내:** RFC 작성, 크로스팀 프로젝트 참여, 장애 대응 주도

- **회사 내:** 기술 블로그 기고, 올핸즈 발표, 내부 도구 개발

- **업계:** 컨퍼런스 발표, 오픈소스 기여, 기술 블로그 운영

9.3 스폰서십과 멘토

**멘토 vs 스폰서:**

| 역할 | 멘토 | 스폰서 |

|------|------|-------|

| 하는 일 | 조언과 가이드 | 승진을 위해 적극 옹호 |

| 관계 | 비공식 | 공식/비공식 |

| 필요한 시기 | 항상 | 승진 시즌 |

| 예시 | "이런 접근도 있어" | "이 사람은 Staff 준비가 됐습니다" |

9.4 Skip-level 1:1

매니저의 매니저와 정기적 1:1을 가지세요:

- 자신의 영향력과 기여를 공유

- 조직의 전략적 방향을 이해

- 승진에 대한 피드백 요청

- 숨겨진 기회(hidden opportunity) 발견

10. 연봉 협상

총 보상 구조 (Total Compensation)

총 보상 = 기본급 + 주식(RSU/스톡옵션) + 보너스 + 기타 혜택

빅테크 시니어 (미국 기준):

- 기본급: 180K-250K USD

- RSU: 100K-300K USD/year (4년 베스팅)

- 보너스: 15-25% of base

- 총 보상: 350K-700K+ USD

한국 시니어 (대기업 기준):

- 기본급: 8,000만-1.2억원

- RSU/스톡옵션: 회사에 따라 다름

- 보너스: 0-300% (성과에 따라)

- 총 보상: 8,000만-2억+ 원

협상 전략

1. **먼저 숫자를 말하지 마세요** — 회사가 먼저 제안하게 하기

2. **경쟁 오퍼 확보** — 가장 강력한 협상 도구

3. **총 보상으로 비교** — 기본급만 보지 말기

4. **협상 가능한 항목 파악:**

- 기본급 (가장 경직적)

- 사이닝 보너스 (가장 유연)

- RSU 수량/가속 베스팅

- 원격 근무 일수

- 학습 예산

- 타이틀

5. **카운터 오퍼 주의** — 현 회사의 카운터 오퍼를 받으면:

- 단기적으로는 좋지만 장기적 관계에 영향

- 이직 이유가 해결되었는지 확인

- 카운터 오퍼 후 6개월 내 떠나는 경우가 많음

11. 이직 타이밍

떠나야 할 신호

1. **성장 정체** — 6개월 이상 새로운 것을 배우지 못하고 있다

2. **조직 문화** — 회사의 가치관과 본인의 가치관이 맞지 않는다

3. **보상 불균형** — 시장 대비 현저히 낮은 보상

4. **매니저 문제** — 나쁜 매니저는 이직의 가장 흔한 이유

5. **기술 스택** — 시장에서 경쟁력 없는 기술만 사용

6. **번아웃** — 환경 변화 없이는 회복 불가

머물러야 할 신호

1. **성장 기회** — 새로운 프로젝트나 역할이 열려 있다

2. **좋은 팀** — 팀원과 매니저가 나의 성장을 지원

3. **승진 임박** — 3-6개월 내 승진 가능성이 높다

4. **RSU 베스팅** — 대규모 베스팅이 임박 (cliff 주의)

5. **영향력** — 조직에서 의미 있는 변화를 만들고 있다

2년 규칙

- 최소 2년은 한 곳에 있어야 이력서에서 불안정해 보이지 않는다

- 단, 이것은 가이드라인일 뿐 — 독성 환경이라면 빨리 떠나세요

- 한 곳에 너무 오래 있는 것도 리스크 — 5년 이상이면 성장 점검 필요

12. 브랜드 구축

기술 블로그

- 주 1회 기술 글 작성 목표

- 깊이 있는 포스트 1개가 얕은 포스트 10개보다 가치

- SEO 최적화: 검색 가능한 제목, 메타 설명

- 실전 코드와 경험 공유가 가장 인기

오픈소스 기여

- Star가 많은 프로젝트의 이슈부터 시작

- 문서 개선은 가장 쉬운 첫 기여

- 본인의 유틸리티 라이브러리를 오픈소스로 공개

- "Made at Company X" 프로젝트는 회사와 개인 브랜드 모두 강화

발표 (Conference Talks)

- 사내 기술 세미나부터 시작

- 밋업 발표 → 국내 컨퍼런스 → 해외 컨퍼런스

- 발표 자료는 블로그 포스트로 재활용

- 발표 준비 과정에서 깊은 학습 효과

교육 및 멘토링

- 사내 스터디 그룹 운영

- 외부 멘토링 프로그램 참여

- 강의 플랫폼에서 코스 제작

- 기술 서적 리뷰어 활동

13. 한국 개발자 환경의 특수성

연차 문화와 직급 체계

한국 회사의 직급 체계는 글로벌 기업과 다릅니다:

| 한국 직급 | 글로벌 대응 | 특징 |

|----------|-----------|------|

| 사원/주임 | Junior | 1-3년차 |

| 대리 | Mid | 3-6년차 |

| 과장 | Senior | 6-10년차 |

| 차장/부장 | Staff/Principal | 10년차+ |

**주요 차이점:**

1. **연차 기반 승진** vs 성과 기반 승진

- 한국: 일정 연차가 되면 자동 승진하는 문화가 아직 남아 있음

- 글로벌: 순수하게 역할과 영향력 기반

2. **포괄임금제 주의**

- 연봉에 야근 수당이 포함되어 있는지 확인

- 실제 시급을 계산해보면 생각보다 낮을 수 있음

3. **이직 문화**

- 한국: 과거에는 이직이 부정적이었으나 현재는 보편화

- IT 업계: 2-3년 주기의 이직이 일반적

4. **네이버/카카오/배민 vs 외국계**

- 국내 대기업: 한국어 환경, 국내 사용자 규모, 빠른 실행

- 외국계: 글로벌 환경, 영어 소통, 체계적 엔지니어링 문화

글로벌 커리어를 위한 준비

- **영어 능력** — 기술 토론이 가능한 수준 (OPIC IH 이상)

- **글로벌 오픈소스 기여** — 영어로 PR, 이슈 소통 경험

- **해외 컨퍼런스** — 발표 또는 참가 경험

- **글로벌 기업 면접 준비** — 시스템 설계, 코딩 인터뷰, 행동 면접

14. 실전 퀴즈

**정답: 영향 범위(Scope of Impact)**

시니어는 **팀 내** 프로젝트를 주도하고, Staff은 **팀을 넘어** 조직 수준의 기술적 영향력을 발휘합니다. Staff은 여러 팀의 기술적 방향을 조율하고, 조직의 기술 전략을 수립합니다.

**정답:**

1. **완료한 프로젝트** — 규모, 영향, 측정 가능한 결과

2. **기술 리더십** — RFC, 아키텍처 결정, 기술 방향 제시

3. **멘토링** — 누구를 도왔고, 어떤 성과로 이어졌는지

4. **조직 기여** — 채용, 프로세스 개선, 문화 기여

5. **학습과 성장** — 새로 배운 기술, 발표, 블로그

**정답:** 에너지원을 관찰하세요:

- **기술적 문제 해결**에서 에너지를 얻으면 → IC

- **사람의 성장**에서 에너지를 얻으면 → Manager

- 둘 다 좋으면 → **테크 리드** (하이브리드)

중요: 관리직이 "승진"이 아닙니다. IC와 Manager는 **다른 직종**입니다. 코딩이 좋은데 매니저 타이틀에 이끌려 전환하면 양쪽 모두에서 불행해질 수 있습니다.

**정답: 경쟁 오퍼(Competing Offer) 확보**

다른 회사의 오퍼가 있으면 협상력이 극적으로 올라갑니다:

1. 관심 있는 3-5개 회사에 동시 지원

2. 오퍼 타이밍을 맞춤 (비슷한 시기에 오퍼 받도록)

3. 총 보상(TC) 기준으로 비교

4. 가장 높은 오퍼를 기준으로 다른 회사와 협상

단, 블러핑(거짓 오퍼)은 절대 금지 — 업계는 생각보다 좁습니다.

**정답:** 핵심 질문 3가지로 판단합니다:

1. **"6개월 후에 더 성장해 있을 것인가?"**

- No → 이직 고려

2. **"이 환경에서 내 목표를 달성할 수 있는가?"**

- No → 이직 고려

3. **"떠나려는 이유가 어디서든 발생하는 문제인가?"**

- Yes → 먼저 내부에서 해결 시도

이직은 "도망"이 아니라 "성장을 위한 선택"이어야 합니다.

15. 참고 자료

도서

1. "Staff Engineer: Leadership Beyond the Management Track" — Will Larson

2. "The Manager's Path" — Camille Fournier

3. "An Elegant Puzzle: Systems of Engineering Management" — Will Larson

4. "The Staff Engineer's Path" — Tanya Reilly

5. "Radical Candor" — Kim Scott

온라인 리소스

6. [StaffEng.com](https://staffeng.com/) — Staff 엔지니어 인터뷰 모음

7. [Levels.fyi](https://www.levels.fyi/) — 레벨별 보상 데이터

8. [Engineering Ladders](https://www.engineeringladders.com/) — 커리어 래더 프레임워크

9. [Julia Evans — Brag Document](https://jvns.ca/blog/brag-documents/) — 성과 문서 작성 가이드

10. [Charity Majors — The Engineer/Manager Pendulum](https://charity.wtf/2017/05/11/the-engineer-manager-pendulum/)

강의 및 영상

11. [LeadDev Conference](https://leaddev.com/) — 엔지니어링 리더십 컨퍼런스

12. [Gergely Orosz — The Pragmatic Engineer](https://www.pragmaticengineer.com/)

13. [Software Engineering Radio — Career Episodes](https://www.se-radio.net/)

한국 리소스

14. [원티드 연봉 인사이트](https://www.wanted.co.kr/) — 한국 IT 연봉 데이터

15. [리멤버 커리어](https://www.rememberapp.co.kr/) — 네트워킹 및 이직

16. [한국 개발자 커뮤니티](https://careerly.co.kr/) — 커리어리 커리어 정보