Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

"Management is a career change, not a promotion." — Camille Fournier 『The Manager's Path』

[커뮤니케이션 가이드]에서 1:1·피드백·협상을 다뤘다. 이 기술을 본격적으로 쓰는 직업이 엔지니어링 매니저(EM)다.

많은 시니어 엔지니어가 EM 제안을 받고 고민한다. "승진이니까 받아야지"가 가장 흔한 실수다. EM은 승진이 아니라 직업 전환. 당신이 좋아하는 기술 문제는 줄어들고, 사람 문제가 늘어난다. 이 글은 그 결정을 정보에 근거해 내릴 수 있게 한다.

대상:

EM 오퍼를 받은 시니어.
EM 전환 후 첫 1년에 헤매는 사람.
IC로 돌아오고 싶은 EM.
자신의 EM을 이해하고 싶은 IC.

EM은 무엇을 하는가 — 역할 정의
IC vs EM 트랙 선택의 결정 트리
EM 첫 90일 플레이북
위임·Delegation — 매니저의 가장 어려운 기술
채용·면접·온보딩
성과 평가와 승진 결정
해고와 PIP — 가장 어려운 대화
조직 확장과 Reorg
기술 이해를 유지하는 법
IC로 돌아오는 경로
한국 조직의 EM 현실
체크리스트와 안티패턴

1. EM은 무엇을 하는가 — 역할 정의

1.1 하루의 변화

IC 시니어의 하루:

코딩 60%·리뷰 20%·미팅 20%.
Deep work 블록 3~4시간 확보 가능.

EM의 하루:

1:1 30%·미팅 30%·계획·문서 20%·코드 리뷰 10%·직접 코딩 10%.
Deep work 1~2시간, 중간 중간 interrupt.

1.2 성공의 측정 기준

IC: 내 코드·설계·출력.
EM: 팀의 출력.

내가 아니라 팀이 잘하는 것을 봐야 한다. 이게 가장 큰 심리적 전환.

1.3 EM의 핵심 책임 5가지

People: 채용·성장·평가·해고.
Delivery: 프로젝트 완성.
Strategy: 방향·우선순위.
Process: 팀 운영·의례.
Stakeholder: 다른 팀·상위·PM과 조율.

1.4 EM 유형

Tech Lead Manager (TLM):

Google 전통. 기술 + 사람 반반.
팀 4~6명.

Pure People Manager:

기술 결정은 tech lead·staff engineer.
7~15명.

Director (M2):

Manager of Managers.
20~50명.

1.5 좋은 EM의 시그널

팀 engagement score 높음.
Eng retention.
프로젝트 예측 가능성.
주니어 → 시니어 승진.
후속 EM·Staff 배출.

1.6 EM이 무엇이 아닌지

기술 감독관이 아님.
PM 대체가 아님.
팀의 최고 기술자가 아님 (그게 Staff).
업무 분배 기계가 아님.

2. IC vs EM 트랙 선택의 결정 트리

2.1 EM이 맞을 수도 있는 신호

타인 성장에 에너지 충전.
복잡한 사람 관계 탐색 즐김.
글·1:1·미팅에서 에너지 소진 적음.
여러 프로젝트 동시 파악 즐김.
추상적·애매한 문제 견딤.

2.2 IC가 맞을 수도 있는 신호

깊이·기술 탐구가 주요 만족.
미팅 많으면 탈진.
여러 프로젝트 추적이 고통.
사람 문제 피로도 높음.

2.3 "해보면 안다"

대부분 회사가 EM trial 허용: 3~6개월.
돌아갈 수 있다는 전제로 시도.

2.4 Dual-track 회사

Google, Meta, Stripe: Staff/Principal IC 트랙 강함.
Amazon: Principal Engineer 트랙 명확.
Apple: IC 트랙 유명.
한국: 대기업 IC 트랙 아직 초기. 스타트업이 더 유연.

2.5 연봉 비교

L5 수준: EM ≈ Senior IC.
L6~L7: Staff IC > Senior EM (일부).
L7+: Principal IC = Director.

즉, 연봉 상승을 이유로 EM 가는 건 중간 레벨에만 타당.

2.6 시간 지평

5년 후 어디에 있고 싶은가.
Founding CEO 되고 싶으면 EM 경험 유리.
Deep tech researcher 되고 싶으면 IC 유지.

3. EM 첫 90일 플레이북

3.1 Week 1-2: Listen

1:1 전체 팀원 with.
"What's broken? What should continue?".
아무것도 바꾸지 말기 (Chesterton's Fence).

3.2 Week 3-4: Map

Team charter: 무엇 하는 팀인가.
Stakeholder map: 누구와 일하는가.
Current projects: 상태·health.
Team skill matrix: 누가 무엇 잘함.

3.3 Week 5-8: Diagnose

문제 3가지 우선 순위.
Process·people·project.
내 boss와 합의.

3.4 Week 9-12: Act

최소 1개 변화: quick win.
3개월 로드맵 제시.
팀 ritual 조정 (standup·retro·review).

3.5 First 90 안티패턴

즉시 reorg: 맥락 없이.
이전 EM 비난.
내 코드 스타일 강제.
모든 미팅 재설계.
1:1 건너뛰기.

3.6 "관리자 신고식"

첫 해고.
첫 승진 추천.
첫 "no" 말하기.
첫 difficult 1:1.

각각이 경험 마일스톤.

4. 위임 — 매니저의 가장 어려운 기술

4.1 왜 위임이 어려운가

"내가 하면 더 빨라" 함정.
실수 risk.
Context 전달 비용.

하지만 위임 없이는 scale이 안 된다.

4.2 위임 매트릭스 (Tanya Reilly)

Level	설명	예
1	Do exactly this	Task 명시
2	Research and recommend	조사 후 제안
3	Decide and tell	결정 후 보고
4	Decide and do	그냥 하라

주니어는 1~~2, 시니어는 3~~4.

4.3 Radical Responsibility

위임했어도 결과 책임은 매니저.
실패 시 "내 책임", 성공 시 "팀 공".

4.4 위임 후 체크인

너무 자주 체크: micromanagement.
너무 드물게: drift.
주간 1:1 + 중간 마일스톤 균형.

4.5 "내 일" 목록 vs "내 관심 영역"

직접 하는 것 vs 팀이 하는 것.
EM 시간의 10% 이하만 hands-on.
나머지는 enable.

4.6 Hands-on vs Hands-off

프로덕션 incident: hands-on으로 참여.
Feature 구현: hands-off.
채용: hands-on.

5. 채용·면접·온보딩

5.1 채용은 매니저의 최우선

한 번의 잘못된 hire = 6~12개월 후 PIP/해고.
좋은 채용 = 팀의 영구 자산.

5.2 JD 작성

Must-have vs Nice-to-have 분리.
팀 맥락·성장 기회.
연봉 밴드 공개 (trust 신호).

5.3 면접 프로세스 설계

Phone screen (30분 recruiter + 45분 hiring manager).
Technical: coding (60~90분) + system design (60분).
Behavioral: hiring manager + peer.
Bar raiser: 타 팀·부서.
Debrief meeting: 참여자 모여 결정.

5.4 Calibration

Scorecard: 각 축 1-5.
강한 no = 거부: 약한 yes 다수보다 강함.
Written feedback 먼저, 토론 후.

5.5 Signal vs Noise

Code style 편향: 내 스타일과 다른 걸 거부.
대학 이름·회사 이름 halo.
Likability bias: 친근하면 더 좋아 보임.

→ 표준화된 rubric이 방어선.

5.6 온보딩 30-60-90

30일: 환경 설정·첫 PR·1:1 완료.
60일: 중간 프로젝트 기여.
90일: 독립적 owner.

5.7 한국 채용 맥락

평판·레퍼런스 영향 큼.
지원자 풀 적어서 유명 기업 경쟁 치열.
스타트업 경험 편차 커서 검증 필요.
글로벌 원격 채용 점점 흔해짐.

6. 성과 평가와 승진 결정

6.1 평가의 목적

성장 피드백.
보상 결정.
승진 자격.

이 세 개가 혼합되면 솔직한 대화 어려움.

6.2 평가 축

Impact (영향).
Technical execution.
Collaboration·influence.
Growth / Leadership.

회사마다 가중치 다름.

6.3 Calibration 프로세스

매니저들이 모여 팀 간 비교.
Forced distribution (bell curve): 논란.
상대 비교로 bias 조정.

6.4 승진 자격

"이미 다음 레벨에서 일하고 있다"는 증거.
Promo packet: artifacts·레퍼런스·self-assessment.
2~4 분기 일관된 성과.

6.5 승진 추천 준비

매니저가 6개월 전부터 준비.
Peer 피드백 수집.
스코프 확장 기회 제공.
가시성 늘리기.

6.6 승진 안 됐을 때

1주 이내 솔직한 대화.
이유 구체화.
다음 사이클 계획.
분노·퇴사 유혹 관리.

6.7 Compensation 대화

밴드 투명성.
Delta 이유 명확.
경쟁 오퍼 match 정책.

7. 해고와 PIP — 가장 어려운 대화

7.1 해고는 빠를수록 인도적

나쁜 hire 유지 = 모든 팀원에게 부정적.
"해고 결정을 1주 빨리 못 한 걸 후회한다"가 매니저 공통.

7.2 Performance Improvement Plan (PIP)

30~90일 공식 개선 기간.
명확한 기대치·측정 가능.
주 1~2회 체크인.

PIP 통과율: 회사·지역에 따라 다르나 일반적으로 20~40%.

7.3 해고의 법적·윤리적 절차

미국:

At-will 고용 (대부분 주).
Documentation 중요 (PIP·lettering).
Severance + release.

한국:

정당한 사유 필요.
30일 전 통지 또는 통상 임금.
권고사직 vs 정리해고 구분.

7.4 해고 대화 스크립트

15분 미만.
단도직입: "오늘이 네 마지막 근무일이야."
이유: 간결·사실 기반.
논쟁 금지.
다음 단계: HR·severance·benefit.

7.5 해고 후 팀 공지

24시간 내 팀에 알림.
존중: 이유 공개 금지.
재배치: 업무 interim plan.

7.6 Layoff (대규모 해고)

2022~2024 tech 산업 대규모 layoff.
개인 잘못이 아님 강조.
Severance·career transition 지원.
남은 팀 morale 집중.

7.7 자발 퇴사의 관리

Exit interview: 솔직한 이유.
Counter offer는 함정: 한번 떠나기 결정한 사람 거의 다시 떠남.
Off-boarding 깔끔: 지식 이전·관계 유지.
Alumni network: 재입사·추천.

8. 조직 확장과 Reorg

8.1 팀 크기의 phase transition

1~5명: 모두 모든 것 알기.
5~10명: role 분리 시작.
10~20명: sub-team 고려.
20명+: EM of EMs 필요.

8.2 언제 팀을 나누는가

Stand-up이 30분 넘음.
지식 silos 생김.
서비스가 커뮤니케이션 복잡.

8.3 Reorg 설계 원칙

Why first: 모두가 이해해야.
Team Topologies 참조.
Minimal disruption: 필요 최소한.
Champions: 각 팀에 옹호자.

8.4 Reorg 발표

1주 전 매니저 라인에 sync.
all-hands 발표.
Individual 1:1 후속.
FAQ 문서.

8.5 Reorg 저항

상실감: 팀·identity·관계.
Trust 비용: 너무 자주 reorg 금물 (연 1회 이하 권장).

8.6 Span of Control

EM당 직속 5~8명 권장.
10명 넘으면 depth 부족.
3명 이하면 under-utilized.

9. 기술 이해를 유지하는 법

9.1 위험 — 3년 후 기술 disconnect

EM 5년 → 다시 IC는 힘듦.
시장에서 평가 애매.
팀 기술 결정에 권위 약화.

9.2 hands-on 유지 전략

매주 최소 4시간 코딩: 작은 PR, prototype.
Major tech review 참여.
On-call rotation 1/월.
신기술 sandbox: 새 LLM, 프레임워크 직접 사용.

9.3 독서·학습

주간 1시간 paper·blog.
오픈소스 훓기.
컨퍼런스 참석 2~3회/년.

9.4 Tech lead와의 협력

대부분 tech 결정은 Tech Lead·Staff가 주도.
EM은 질문자·challenger 역할.
"왜?"와 "대안은?"으로 질 향상.

9.5 Technical radar

매월 팀 기술 스택 리뷰.
ThoughtWorks Radar·InfoQ.

10. IC로 돌아오는 경로

10.1 EM에서 IC로 = Career suicide?

과거엔 그랬다. 지금은 정상화.

"Career pendulum": 회사 내 왔다갔다.
Staff IC 수요 증가로 rehoming 가능.

10.2 언제 돌아와야 하나

매 1:1 전 dread.
하루 끝에 "I didn't build anything" 공허.
People 문제보다 tech 문제에 에너지.
건강·정신 상태.

10.3 돌아가는 방법

매니저와 대화 먼저.
Title·comp 협상: 일부 회사는 downgrade, 일부는 horizontal.
1~3개월 transition.

10.4 돌아온 후 적응

기술 갭 메꾸기: 2~6개월 집중.
EM 경험이 자산: 팀 이해·stakeholder 관리.
Tech Lead·Staff Engineer로 빠르게 진입 가능.

10.5 EM → IC → EM 다시

가능. Charity Majors (Honeycomb CTO)가 대표적으로 옹호.
"Engineer/Manager Pendulum" 블로그 글.
양쪽 경험이 각각을 강화.

11. 한국 조직의 EM 현실

11.1 전통 대기업

관리직이 전통적 출세 경로.
"부장·임원" 승진.
기술 잃어버린 매니저 비판.

11.2 테크·스타트업

EM·Staff 분리 점진 정착.
네이버·카카오·쿠팡·토스·당근.
여전히 "나이 많으면 관리" 관행.

11.3 외국계 지사

Global track 따름.
IC 트랙 명확.
한국 채용 경쟁력 강점.

11.4 한국 특유 EM 도전

연공서열 vs 평가 충돌.
"회식·야근" 문화 vs 글로벌 수평.
외국인 동료 증가에 high-context 문제.

11.5 한국 EM을 위한 추천

글로벌 표준 학습: Camille Fournier·Will Larson.
해외 EM 네트워크: LinkedIn·Meetup.
영어 커뮤니케이션 훈련.
Dual-track 신호: 조직이 Staff 트랙 있으면 건강한 신호.

12. EM 번아웃 관리

12.1 EM은 특히 번아웃 위험

감정 노동 많음.
Deep work 부족.
성과가 늦게 가시화.

12.2 에너지 관리

회의 back-to-back 금지.
Buffer time: 15분 회의간.
주간 deep work block.

12.3 지원 네트워크

EM 동료 그룹.
코칭 / 테라피 고려.
멘토: 1~2단계 위.

12.4 재충전

휴가 실제 off: 업무 Slack 끄기.
Sabbatical: 3~6개월.
취미: 완전히 다른 결.

체크리스트

내 EM 역량이 건강한가?

☐ 매주 모든 직속 부하와 1:1을 한다.
☐ 팀 스킬 매트릭스를 분기별 업데이트한다.
☐ 마지막 6개월에 채용 인터뷰를 진행했다.
☐ 직속 부하 중 최소 1명의 승진을 성공시켰다.
☐ 팀 retrospective를 월 1회 한다.
☐ 기술 hands-on 시간이 주 4시간 이상이다.
☐ 나의 매니저와 매주 1:1.
☐ Skip-level 1:1을 분기별로.
☐ 해고·PIP 프로세스를 문서로 알고 있다.
☐ 번아웃 전조 증상을 파악하고 있다.
☐ IC 복귀 옵션을 매니저와 논의해본 적 있다.
☐ EM 동료 네트워크 최소 3명.

자주 보는 안티패턴 10가지

승진 이유로 EM 수락 — 적성 무시.
첫 90일에 reorg.
기술 무관심 — 3년 후 IC 복귀 불가.
해고 미룸 — 팀 전체 사기 파괴.
Favoritism: 편애.
팀 성과를 내 것으로.
1:1 cancel 반복.
하향식 의사결정만 — 팀 autonomy 파괴.
번아웃 무시.
Career pendulum 고정관념 — "한번 EM이면 영원히".

다음 글 예고 — “엔지니어 팀 문화 설계 완전 가이드: Psychological Safety·DevEx·Rituals·Retrospective·Code Review·문서화까지”

EM이든 IC든, 팀이 건강해야 한다. 팀 문화는 설계 대상이다.

Google Project Aristotle의 5가지 요인
Psychological Safety 측정·개선
DevEx (Developer Experience) 프레임워크
팀 ritual 설계 — standup·retro·review
코드 리뷰 문화
문서화 문화
Inclusion과 diversity
갈등을 생산적으로
원격·하이브리드 팀 문화

개인 역량을 넘어 팀 설계의 예술. 다음 글에서 이어진다.

목차