# 엔지니어링 매니저가 되지 마세요

> Clean Markdown view of GeekNews topic #27192. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=27192](https://news.hada.io/topic?id=27192)
- GeekNews Markdown: [https://news.hada.io/topic/27192.md](https://news.hada.io/topic/27192.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-03-04T20:33:13+09:00
- Updated: 2026-03-04T20:33:13+09:00
- Original source: [newsletter.manager.dev](https://newsletter.manager.dev/p/dont-become-an-engineering-manager)
- Points: 11
- Comments: 3

## Summary

기술 변화 속도가 가파르게 높아진 지금은 **관리직 전환보다 기술 중심 경로를 유지하는 것이 유리한 시기**입니다. 기업 구조가 평탄화되며 EM 이상의 승진 기회가 줄었고, 업계 전반에서는 시니어·스태프 엔지니어의 보상이 오히려 더 높게 형성되고 있습니다. 관리 경험의 가치가 여전히 존재하더라도, 실험과 학습의 시간을 확보하기 어려운 환경에서는 기술적 성장의 기회를 놓치기 쉽습니다. 그래서 결론적으로 **시니어 엔지니어라면 당장은 관리직 전환을 미루는 것이 바람직**하며, 향후 **2~3 년간 상황을 지켜보는 것**을 권장합니다.

## Topic Body

- 기술 변화 속도가 급격히 빨라진 시점에서 **관리직으로 전환하면 기술 적응력과 실험 기회가 줄어드는 위험**이 커짐  
- 기업 구조가 평탄화되며 **EM → Director → VP로 이어지는 승진 경로가 좁아지고 경쟁이 심화**됨  
- 업계 전반에서 **시니어·스태프 엔지니어의 보상이 EM보다 높게 형성**, 관리직 전환이 경제적으로 불리할 수 있음  
- 그럼에도 불구하고 **직무 자체의 즐거움과 사람 관리의 만족감** 때문에 EM 역할을 지속하는 경우도 존재  
- 현재는 **관리직 전환보다 기술 중심 경로를 유지하는 것이 유리한 시기**로, 신중한 판단이 필요함  
  
---  
  
### 1\. 기술에서 멀어지기엔 좋지 않은 시기  
- 최근 1년간 기술 변화 속도가 매우 빠르며, 일하는 방식의 거의 모든 부분이 달라지고 있음  
  - **AI 코딩 도구와 새로운 프로젝트의 등장**이 잦고, OpenClaw 같은 새로운 프로젝트가 빠르게 확산  
- [Claude Code 개발자가 Anthropic에 왜 아직 소프트웨어 엔지니어가 필요한지를 설명하는 트윗](https://x.com/bcherny/status/2022762422302576970)이 화제가 된 바 있음  
  > 누군가는 클로드에게 지시를 내리고, 고객과 소통하고, 다른 팀과 협력하고, 다음에 무엇을 개발할지 결정해야 합니다. 엔지니어링은 변화하고 있으며, 훌륭한 엔지니어는 그 어느 때보다 중요합니다.  
- 이러한 변화 속에서 **매니저는 실험과 학습에 쓸 시간이 부족**, 특히 6명 규모 이상의 팀을 맡으면 더욱 어려움  
- 기술을 직접 다루며 새로운 아이디어를 시도하고 싶은 엔지니어에게는 **관리직으로 전환하면 시간이 절대적으로 부족**  
  
### 2\. 관리직 승진 구조의 경쟁 심화  
- 기존 EM 커리어 경로는** EM → Senior EM → Director → VP**였으나, 최근 2년간 기업들이 **조직 구조를 평탄화**하는 추세  
- Amazon이 **IC 대 매니저 비율을 15% 높였고**, 다른 기업들도 이를 따르고 있어 상위 직급이 줄어듦  
- Director와 VP 자리가 줄어들었고, Senior EM 포지션도 감소하여, 유능한 EM이라도 수년간 제자리에 머물 수 있음  
- 평탄화된 기업에서 해고된 경험 많은 리더들과 경쟁해야 하므로, **Senior EM 이상의 경쟁 강도**가 이전보다 훨씬 높음  
- 그 결과 **내부 승진 기회가 감소**, 더 많은 인원을 관리하지 않으면 승진이 어렵고, 동일 팀 내에서는 범위 확장만 가능  
- 반면 **IC(Individual Contributor)** 로서 뛰어난 기술 역량을 발휘하면 더 빠른 성장 가능  
  
### 3\. 보상 측면의 불리함  
- EM 승진 시 급여 인상을 제안받지만, 다른 스타트업의 **Senior/Staff Engineer** 제안보다 총 보상이 낮을수 있음  
  - 같은 회사 내에서는 EM이 Senior Engineer보다 보상이 높지만, 업계 전반으로 비교하면 **Staff Engineer가 더 높은 보상**을 받음  
- 이는 **해당 엔지니어들에 대한 수요가 매우 크고, 앞으로도 지속**될 것이기 때문  
- IC 트랙을 유지하며 Staff Engineer로 성장 후 이직할 경우, EM 승진 대비 **약 20~30% 더 높은 보상** 가능  
  
### 4\. 그럼에도 EM으로 남아 있는 이유  
- **핸즈온을 유지하는 경험 많은 EM**에 대해서는 낙관적이며, 수년간 쌓은 매니지먼트 스킬은 여전히 유효함  
  - **여전히 가치 있는 역할**을 수행할 수 있으며, 기술적 예리함은 줄더라도 관리 경험이 강점으로 작용  
- 개인적으로는 **직무에 대한 즐거움과 만족감**이 커서 계속 EM으로 일하고 있음  
- 다만 2026년 현재 기준으로는 **IC 경로가 더 합리적인 선택**이라고 생각됨  
  
### 5\. 결론 및 조언  
- **시니어 엔지니어라면 당장은 관리직 전환을 미루는 것이 바람직**, 향후 **2~3 년간 상황을 지켜보는 것**을 권장  
- 그러나 **내적 동기와 열정이 확실하다면 도전 가능**, 단순한 보상이나 승진 논리로 접근해서는 안 됨

## Comments



### Comment 52431

- Author: coremaker
- Created: 2026-03-05T10:16:09+09:00
- Points: 1

이거 공감하는 매니저 분들 많을 것 같네요.

### Comment 52434

- Author: kalista22
- Created: 2026-03-05T10:40:35+09:00
- Points: 1
- Parent comment: 52431
- Depth: 1

아주 공감합니다

### Comment 52393

- Author: neo
- Created: 2026-03-04T20:33:13+09:00
- Points: 1

###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47232727) 
- 나는 “tech” 업계에서 **직함(title)** 이 거의 임의적이라는 느낌을 받음  
  “Senior”, “Lead”, “Principal”, “Staff” 같은 호칭은 회사마다 정의가 달라서, 실제로는 조직 구조에 따라 의미가 완전히 달라짐  
  예를 들어 “Senior Backend Developer”일 때가 “Staff Engineer”일 때보다 더 많은 책임을 맡았던 적도 있음  
  세 대륙에서, 6명짜리 스타트업부터 1만 명 넘는 대기업까지 일해봤지만, 직함의 기준은 여전히 제각각이었음
  - 맞음. 직함은 **회사 내부에서는 일관성** 있게 쓰여야 하지만, 회사 간에는 전혀 호환되지 않음  
    신입들에게 이걸 여러 번 설명해야 했음. “Senior Engineer” 타이틀 때문에 수만 달러를 포기하려는 사람도 있었음  
    채용할 때는 Microsoft나 Google처럼 **공개된 레벨링 시스템**이 있는 회사 출신이 아니면 직함은 거의 무시함  
    “Principal Staff Engineer”나 “CTO” 타이틀을 가진 사람이 실제로는 평균 회사의 시니어 수준에도 못 미치는 경우도 있었음  
    반대로 “Senior Software Engineer”인데 팀 누구보다 뛰어난 사람도 있었음  
  - 대부분의 회사는 보상과 평가를 위해 자체적인 **레벨 구조**를 가짐  
    일반적으로는 L1 인턴부터 L10 Fellow까지 이어지는 구조이며, L5(Senior)가 대부분의 엔지니어가 도달 가능한 ‘종착점’ 역할을 함  
    L6 이상은 특별한 영향력과 **제품·비즈니스 임팩트**를 요구함  
    L9~L10은 업계 전체에 영향을 준 사람들로, 예를 들어 MapReduce나 Kubernetes를 만든 수준임  
  - IC(Individual Contributor)에게 직함은 **보상과 평가**에 직접 연결됨  
    대기업에서는 Staff와 Senior의 RSU 차이가 크지만, 스타트업에서는 거의 의미가 없음  
    평가 시즌에는 직함에 따라 평가 기준이 달라지지만, 실제로는 매니저가 곡선을 맞추기 위해 점수를 조정함  
    VP, Director, C레벨로 가면 조직 간 비교가 가능해지고, **정치적 요소**가 커짐  
  - 직함은 외부에서 나를 설명하는 **가장 상위 비트**임  
    한 회사에 오래 있을 거면 중요하지 않지만, 커리어 이동을 고려한다면 협상 포인트가 됨  
    나는 “Senior DevSecOps Engineer”라는 타이틀을 직접 협상했음  
    이 타이틀 덕분에 내가 **보안 파이프라인 관리**에는 강하지만, 머신러닝 모델 튜닝에는 약하다는 걸 명확히 보여줄 수 있음  
  - 예전에 기계·전기 기반의 **시스템 엔지니어**로 일했는데, 소프트웨어 업계가 같은 타이틀을 가져가면서 혼란이 생겼음  
    내 역할은 실제 하드웨어와 공압, 전류를 다루는 일이었는데, 이제는 검색하면 전부 Unix나 Python 관련 직무만 나옴  
    “Unix Server Engineer” 같은 좀 더 구체적인 이름을 썼다면 좋았을 것 같음  

- 엔지니어링 매니저가 되고 싶다면, 단순히 다음 단계로 생각하지 말고 **장기적으로 어떤 역할을 원하는지** 고민해야 함  
  매니저는 기술보다 **사람 관리와 HR**이 핵심이며, Director 이상으로 가면 회의와 정보 정리에 대부분의 시간을 씀  
  많은 개발자가 Peter Principle([위키 링크](https://en.wikipedia.org/wiki/Peter_principle))의 희생양이 됨  
  개발자로 남는 것도 전혀 문제없음. 좋아하는 일을 하면서 버틸 수 있다면 이미 성공한 것임
  - 내 매니저는 평가 시즌 외에는 거의 아무 일도 안 하지만 나보다 **연봉이 높고**, 팀의 성과를 전부 자기 공으로 돌림  
    겉보기엔 꽤 쉬운 일처럼 보임  
  - Peter Principle을 처음 알게 됐는데, 1969년에 나온 개념이 아직도 유효하다는 게 놀라움  
  - IC 입장에서 보면, 사람 관리가 그 역할의 **가장 명확한 부분**인데 그걸 준비 안 한다는 게 이해가 안 됨  
    나는 휴가 승인이나 슬랙에서 누군가를 혼내는 일은 절대 하고 싶지 않음  
  - 내 경험상 Peter Principle보다 **Dilbert Principle**([위키 링크](https://en.wikipedia.org/wiki/Dilbert_principle#Definition))이 더 현실적임  
    Apple에서 매니저로 승진한 사람들이 작성한 끔찍한 코드를 디버깅하면서, 그들이 애초에 잘했던 적이 없다는 걸 깨달음  
    고위 관리자는 실제 일보다 **중요해 보이게 만드는 능력**이 중요함  
    회의 예약하고 슬라이드 만드는 게 실력처럼 보이는 구조임  
  - 모두가 “엔지니어링 경험 있는 매니저”를 원하지만, 정작 **그 매니저가 되고 싶어 하는 사람은 없음**  

- 산업별로 구분하지 않으면 이런 분석은 의미가 없음  
  “Engineering Manager”는 너무 일반적인 타이틀이라 스타트업, 빅테크, 엔터프라이즈마다 다름  
  엔터프라이즈에서는 Staff Engineer가 거의 없고, 보통 SWE1/2/3 → Tech Lead → Architect 구조임  
  반면 테크 기업은 SWE1/2/3 → Staff → Principal 구조를 가짐  
  매니저는 종종 **종착점 역할**을 하며, 20년간 같은 포지션에 머무는 경우도 많음  
  결국 매니저로 가는 건 **커리어 전환**임
  - 하지만 Staff 이상은 EM과 **보상 수준이 비슷**하고, 오히려 **이직 자유도**가 높음  
    EM은 책임이 크고 근무시간이 길지만 급여 차이는 미미함  
    프로젝트가 늦어지면 영업팀의 희생양이 되기 쉬워 **고용 안정성**도 낮음  

- 최근 1년간의 변화가 “엄청나다”는 주장에 동의하지 않음  
  내 업무는 몇 년 전과 거의 비슷하고, 변화는 **점진적**임  
  AI 도구의 발전 속도가 빠르다는 건 **예측**이지, 이미 필수라는 증거는 아님  
  - “예측”이란 말이 무슨 뜻인지 모르겠음. 단순히 AI 도구를 안 써봤다는 건가?  
    과대평가되었더라도 생산성 향상이 있다면 이미 **워크플로우 변화**는 일어나고 있는 것임  
  - 그 사람이 업계 경력이 5년 미만일 것 같음  
    학교에서 바로 온 사람은 아직 배울 게 많아서 변화가 크게 느껴질 수 있음  
  - AI 도구에 대한 담론이 모순적임  
    “누구나 쉽게 쓸 수 있다”면서도 “지금 안 쓰면 뒤처진다”고 함  
    어차피 곧 더 좋아질 거라면, 지금 **불완전한 버전**을 배우는 게 낭비처럼 느껴짐  

- 매니저로 전환하는 것에 대한 논쟁이 있음  
  기술적 역량보다 **사람 관리와 정치력**이 중요하며, 이게 맞지 않으면 매니저가 되지 말아야 함  
  - 하지만 매니저로 가면 **이직 기회가 줄고**, 해고 위험이 더 큼  
    EM은 대체가 쉽고, 프로젝트 실패 시 **희생양**이 되기 쉬움  
    반면 IC는 책임을 분산시킬 수 있음  

- 나는 IC에서 매니저로 전환했는데, 두 트랙은 완전히 다름  
  VP는 Distinguished Engineer와 비슷한 레벨이지만, DE는 업계에서 **유명세**를 얻어야 함  
  결국 돈이나 승진보다 **무엇을 좋아하느냐**가 기준이 되어야 함  
  AI가 단순 업무를 대체하는 시대에는, **열정을 가진 사람만** 남게 될 것임  

- 대부분의 회사에서 매니저는 **‘내부 서클’** 로 여겨지고, 기술자는 단순 노동자로 취급됨  
  매니저는 더 많은 정보와 회의 접근권을 통해 영향력을 얻음  
  - 하지만 실제로는 **라인 매니저**가 가장 쉽게 교체 가능한 포지션임  
    나는 주요 프로젝트를 맡을 때 CTO에게 직접 보고하도록 요구했음  
  - 이런 구조를 모른다면, 매니저로서의 자질이 부족한 것임  
    회사의 **‘마피아 구조’** 에 들어가는 셈임  
  - 매니저는 깊은 기술 지식이 부족한 대신 **정치력과 가시성**으로 영향력을 확보함  

- 보상 비교는 **동일 조건**으로 해야 함  
  나는 Google과 여러 회사에서 Staff Engineer와 EM을 모두 해봤음  
  뛰어난 IC는 일부 회사에서 **100만 달러 이상** 받을 수 있고,  
  그렇지 않다면 매니저로 가는 게 더 나은 선택일 수 있음  

- “엔지니어와 매니저는 동등한 트랙”이라는 말은 **신화에 가깝음**  
  실제로는 매니저 트랙이 훨씬 **승진 기회와 가시성**이 많음  
  큰 조직에서는 내부 네트워크 접근성이 커서 유리함  
  게다가 **실력 없는 매니저**가 엔지니어보다 오래 버티는 경우도 많음  

- “무엇을 하지 말라”는 식의 조언은 위험함  
  “디트로이트로 가지 마라”, “학계로 가지 마라”, “Google 주식 사지 마라” 같은 말은  
  결국 **상황에 따라 가치가 달라지는 시장**의 원리와 같음  
  인생은 결국 **저평가된 가치**를 찾는 게임임  
  남들이 싫어하는 선택이 나에게는 최고의 기회가 될 수도 있음
