▲

엔지니어링 매니저가 되지 말아야 하는 이유

 (newsletter.manager.dev)
1P by GN⁺ 12시간전 | ★ favorite | 댓글 1개
  • 기술 변화 속도가 급격히 빨라진 시점에서 관리직으로 전환하면 기술 적응력과 실험 기회가 줄어드는 위험이 커짐
  • 기업 구조가 평탄화되며 EM → Director → VP로 이어지는 승진 경로가 좁아지고 경쟁이 심화됨
  • 업계 전반에서 시니어·스태프 엔지니어의 보상이 EM보다 높게 형성, 관리직 전환이 경제적으로 불리할 수 있음
  • 그럼에도 불구하고 직무 자체의 즐거움과 사람 관리의 만족감 때문에 EM 역할을 지속하는 경우도 존재
  • 현재는 관리직 전환보다 기술 중심 경로를 유지하는 것이 유리한 시기로, 신중한 판단이 필요함

1. 기술에서 멀어지기엔 좋지 않은 시기

  • 최근 1년간 기술 변화 속도가 매우 빠르며, AI 코딩 도구와 새로운 프로젝트의 등장이 잦음
    • 예시로 OpenClaw 같은 새로운 프로젝트가 빠르게 확산되고 있음
  • 이러한 변화 속에서 매니저는 실험과 학습에 쓸 시간이 부족, 특히 6명 규모 이상의 팀을 맡으면 더욱 어려움
  • 기술을 직접 다루며 새로운 아이디어를 시도하고 싶은 엔지니어에게는 관리직 전환이 제약으로 작용

2. 관리직 승진 구조의 경쟁 심화

  • 전통적인 EM → Senior EM → Director → VP 승진 사다리가 유지되기 어려운 상황
  • Amazon이 IC 대비 매니저 비율을 15% 높인 사례처럼, 기업들이 조직을 평탄화하며 상위 직급이 줄어듦
  • 그 결과 내부 승진 기회가 감소, 더 많은 인원을 관리하지 않으면 승진이 어렵고, 동일 팀 내에서는 범위 확장만 가능
  • 반면 IC(Individual Contributor) 로서 뛰어난 기술 역량을 발휘하면 더 빠른 성장 가능

3. 보상 측면의 불리함

  • EM 승진 시 급여 인상은 있으나, 동일 업계의 Senior/Staff Engineer 제안보다 총보상이 낮은 경우가 많음
  • 업계 전반적으로 스태프 엔지니어 수요가 높아 보상이 더 큼, 관리직보다 기술직이 경제적으로 유리
  • 사례로, 한 엔지니어는 EM 승진보다 스태프 엔지니어로 이직 시 20~30% 높은 보상을 받을 수 있었음

4. 그럼에도 EM으로 남는 이유

  • 경험 많은 EM이 여전히 가치 있는 역할을 수행할 수 있으며, 기술적 예리함은 줄더라도 관리 경험이 강점으로 작용
  • 개인적으로는 직무에 대한 즐거움과 만족감이 커서 계속 EM으로 일함
  • 다만 2026년 현재 기준으로는 IC 경로가 더 합리적인 선택으로 판단

5. 결론 및 조언

  • 시니어 엔지니어라면 당장은 관리직 전환을 미루는 것이 바람직, 향후 몇 년간 상황을 지켜볼 필요
  • 그러나 내적 동기와 열정이 확실하다면 도전 가능, 단순한 보상이나 승진 논리로 접근해서는 안 됨
  • 좋은 엔지니어가 반드시 좋은 매니저가 되는 것은 아님, 두 역할에 필요한 역량이 다름
  • 기업은 이를 인식하고 핸즈온 기술 경로에도 충분한 보상 체계를 마련해야 함
  • 그렇지 않으면 개발자들이 보상만을 위해 관리직으로 이동하는 부작용이 발생할 수 있음
▲
GN⁺ 12시간전  [-]
Hacker News 의견들

  • 나는 “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(위키 링크)의 희생양이 됨
    개발자로 남는 것도 전혀 문제없음. 좋아하는 일을 하면서 버틸 수 있다면 이미 성공한 것임

    • 내 매니저는 평가 시즌 외에는 거의 아무 일도 안 하지만 나보다 연봉이 높고, 팀의 성과를 전부 자기 공으로 돌림
      겉보기엔 꽤 쉬운 일처럼 보임
    • Peter Principle을 처음 알게 됐는데, 1969년에 나온 개념이 아직도 유효하다는 게 놀라움
    • IC 입장에서 보면, 사람 관리가 그 역할의 가장 명확한 부분인데 그걸 준비 안 한다는 게 이해가 안 됨
      나는 휴가 승인이나 슬랙에서 누군가를 혼내는 일은 절대 하고 싶지 않음
    • 내 경험상 Peter Principle보다 Dilbert Principle(위키 링크)이 더 현실적임
      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 주식 사지 마라” 같은 말은
    결국 상황에 따라 가치가 달라지는 시장의 원리와 같음
    인생은 결국 저평가된 가치를 찾는 게임임
    남들이 싫어하는 선택이 나에게는 최고의 기회가 될 수도 있음

답변달기