"좋은 엔지니어링 관리"는 유행일 뿐이다

• 엔지니어링 관리에 대한 업계의 기대치는 비즈니스 환경 변화에 따라 반복적으로 재정의되어 왔으며, 각 시대마다 '좋은 리더십'의 정의가 달라짐
• 2000년대 후반에는 팀 기회 포착과 조직 탐색이, 2010년대에는 엔지니어 유치·유지·동기부여가, 2020년대에는 hands-on 실무 역량이 강조됨
• 각 전환기마다 도덕적 서사가 덧붙여지지만, 실제 동인은 채용 경쟁, ZIRP 종료, AI 도구 생산성 기대 등 비즈니스 현실임
• 효과적인 관리자는 실행·팀·오너십·정렬 같은 핵심 역량과 테이스트·명료성·모호성 탐색·시간축 운영 같은 성장 역량을 균형 있게 확보해야 함
• 장기적으로는 에너지 관리, 역할 선택의 기준, 인생 단계에 따른 40년 커리어 구성을 염두에 두고 스스로 지속가능하게 일할 수 있는 방식으로 설계하는 것이 중요함

---

리더십 기대치의 시대별 변화

• 2000년대 후반 Yahoo 시절: 2년간 매니저와 1:1 미팅이 단 두 번뿐이었으며, 당시 관리 스타일은 팀의 중요한 기회를 포착하고 진행을 방해할 수 있는 조직을 탐색하는 것이 핵심
  • Tracy Kidder의 The Soul of A New Machine에 나오는 팀 리더 스타일과 유사
  • 현대적 기준에서는 빈약해 보이지만 당시 맥락에서는 효과적이었음
• 2010년대: 하이퍼그로스(hypergrowth) 시대로, 예산 제한이 없고 우수 엔지니어 채용이 관리자의 최우선 자질로 여겨졌음
  • 매니저들은 관리 전환의 첫 단계로 소프트웨어 작성을 중단하라는 조언을 받았으며, 당시에는 적절한 지침이었음
• 2020년대(2022년 후반~): 고금리로 ZIRP(제로금리정책) 가 종료되고, 생산형 LLM이 깊은 엔지니어링 조직을 대체할 것이라는 전망 대두
  • 조직이 평탄화되면서 이전에 조정 역할을 했던 직책들이 hands-on keyboard 실무를 기대받음
  • 이전 시대의 최고 매니저들이 이제는 핵심 리더가 아닌 관료(bureaucrats) 로 재프레이밍됨

도덕적 서사와 실제 동인

• 각 전환기마다 도덕적 서사(morality tale) 가 덧붙여짐
  • 2010년대: "엔지니어 역량 강화(empowered)가 근본적 선"이라는 서사 → 실제로는 채용 경쟁 때문
  • 2020년대: "관료적 중간관리자들이 조직을 경직되고 비효율적으로 만들었다"는 서사 → 실제 동인은 ZIRP 종료와 AI 도구의 생산성 향상 기대
• 결론: 현재의 도덕적 서사를 진실로 받아들이면, 업계가 다시 변할 때 심각하게 불리한 위치에 놓이게 됨
  • 실제 변화의 동력은 비즈니스 조건 변화이며, 이에 리더십의 ‘정답’이 지속적으로 바뀌는 현상이 발생함

8가지 기초 엔지니어링 관리 역량

• 효과적인 매니저가 갖춰야 할 역량을 Core Skills(핵심 기술) 과 Growth Skills(성장 기술) 두 클러스터로 분류

Core Skills (핵심 기술)

• 모든 역할(entry-level 관리직 포함)에서 필수적인 기술

• 1. Execution (실행)

  • 팀이 기대되는 유형·무형의 작업을 납품하도록 이끄는 것
  • 예시: 프로젝트 출시, 온콜 로테이션 관리, 스프린트 계획, 인시던트 관리
  • 팀이 실행하지 못하면 매니저 역할을 시작하거나 유지할 기회가 없음

• 2. Team (팀)

  • 팀과 환경을 형성하여 성공하도록 만드는 것
  • 팀을 위해 일하는 것도, 리더십을 위해 일하는 것도 아닌 양자 간 균형 찾기
  • 예시: 채용, 코칭, 성과 관리, 상위 관리자에게 옹호

• 3. Ownership (오너십)

  • 현실이 어려울 때도 일관된 진전을 이루기 위해 현실을 탐색하는 것
  • 일이 되지 않는 것이 다른 사람 탓이라는 방법을 찾는 것이 아니라, 일을 완수하는 방법을 찾는 것
  • 예시: 어려운 일 하기, 불편할 때 나서기, 시스템적 문제에도 불구하고 책임지기

• 4. Alignment (정렬)

  • 리더십, 이해관계자, 팀, 문제 영역 간 공유된 이해를 구축하는 것
  • 주변 사람들을 놀라게 하거나 놀라지 않고 현실적 계획 찾기
  • 예시: 주요 문제와 위기 중 업데이트를 문서화하고 공유

Growth Skills (성장 기술)

• 존재 여부가 커리어에서 얼마나 멀리 갈 수 있는지를 결정하는 기술

• 5. Taste (안목)

  • 기술적으로, 비즈니스적으로, 프로세스/전략적으로 "좋은 것"이 무엇인지 분별하는 판단력
  • 넓은 안목은 진정한 시니어 역할의 보편적 기준
  • Amazon의 "Are Right, A Lot" 원칙의 전제 조건
  • 예시: 제안된 제품 컨셉 개선, 고위험 리라이트 회피, 팀 작업의 사용성 문제 발견

• 6. Clarity (명확성)

  • 팀, 이해관계자, 리더십이 무엇을 왜 하는지 알고 납득하는 것
  • 가장 큰 문제를 어떻게 극복하고 있는지 이해시키는 것
  • "확장성 문제로 고전 중"이 아니라 "새 클러스터에서 사용자 로그인 데이터베이스 샤딩하여 부하 감소" 처럼 구체적으로
  • 예시: 진전을 위한 레버 식별, 위기 탈출 계획 수립, 해당 계획 실행 진전 보여주기

• 7. Navigating Ambiguity (모호함 탐색)

  • 복잡한 문제에서 의견 있고 실행 가능한 접근법으로 나아가는 것
  • 극도로 지저분하고 열린 문제가 주어졌을 때도 진전 방법 찾기
  • 예시: 새 사업 라인 출시, 개발자 경험 개선, 1개에서 N개 클라우드 리전으로 확장
  • 시니어 리더들이 모호한 문제를 가져오는지 여부가 이 역량의 지표

• 8. Working Across Timescales (시간 척도 간 작업)

  • 책임 영역이 단기와 장기 모두에서 진전하도록 보장
  • 오늘 코너를 자르면 성공해 보이지만 내일 재앙으로 끝나는 방식들이 많음
  • 예시: 명확한 목적지 보유, 단기 작업이 그쪽으로 향하게 하기, 장기적으로 경직되고 단기적으로 유연하게

역량별 자기 진단

• 각 역량에 대해 스스로 점검할 수 있는 사고 질문들

• Execution

  • 팀이 마지막으로 작업 납품에 마찰이 있었던 때는? 반복되는 문제인가?
  • 정말 잘 진행된 어려운 것을 출시한 때는?
  • 마지막으로 시간에 민감하고 임원에게 보이는 프로젝트에 투입된 때는?

• Team

  • 마지막으로 채용한 우수 성과자는?
  • 가장 우수한 성과자들을 유지했는가?
  • 어떤 우수 성과자들이 팀에 합류하고 싶어 하는가?
  • 어떤 동료들이 팀을 매우 효과적이라고 생각하는가?
  • 임원이 팀을 탁월하다고 묘사한 때는?

• Ownership

  • 팀이 역경을 극복하고 중요한 것을 납품한 때는? (이해관계자들도 동의할까?)
  • 마지막으로 해결하고 재발하지 않은 어려운 문제는?
  • 교차 팀 격차를 해결하기 전에 문제를 먼저 해결한 때는?

• Alignment

  • 마지막으로 이해관계자에게 놀란 때는? 재발 방지를 위해 할 수 있는 것은?
  • 새 이해관계자가 우선순위 트레이드오프(근거 포함)를 어떻게 이해하는가?
  • 관계를 손상시키지 않고 이해관계자를 실망시킨 때는?
  • 당신을 신뢰해서 회사에 합류할 이해관계자는?

• Taste

  • 당신의 참석으로 의미 있게 개선된 최근 결정은?
  • 제품 담당자가 떠나면 어떤 결정을 내리기 어려울까?
  • 디자인이나 출시를 크게 바꾼 미묘한 명확화는?
  • 코너를 미리 봄으로써 팀 결과를 바꾼 방법은?

• Clarity

  • 최근 팀이 내리도록 도운 어려운 트레이드오프는?
  • 직접 참여 없이도 같은 트레이드오프를 내리게 하려면?
  • 최근 번복된 결정은? 어떻게?

• Navigating Ambiguity

  • 지원 전에 막혀 있었고 지원 후 풀린 문제는?
  • 어떻게 풀었는가?
  • 시니어 리더들이 모호한 문제를 가져오는가? 왜?

• Working Across Timescales

  • 단기와 장기 우선순위 간 최근 트레이드오프는?
  • 시간 척도 간 트레이드오프를 어떻게 알리는가?
  • 상당한 단기 비용을 들여 보호하는 장기 목표는?

Core Skills의 시대별 변화

• "핵심"과 "성장" 기술의 구분은 명확해 보이지만, 일부 기술은 유행 변화에 따라 핵심과 성장 사이를 이동
• Execution은 오늘날 기초 기술이지만, 하이퍼그로스 시대에는 덜 핵심적이었고, 투자자 시대에는 더욱 덜했음
• 유행을 넘어 성공하려면 각 기술에 충분히 넓은 기반이 필요, 그렇지 않으면 시대가 예측 불가능하게 끝날 때 약한 매니저로 인식될 가능성 높음
• 생존을 위해서는 8개 역량을 전체적으로 균형 있게 확보해야 함

에너지 관리의 중요성

• The Engineering Executive's Primer 의 "Manage your priorities and energy" 챕터
• ‘우선순위와 에너지 관리’ 개념은 이상적·수리적 우선순위만으로는 관리자가 오래 갈 수 없다는 점을 강조함
  • 완벽한 작업 배분은 영향력을 최대화하는 수학적 이상이 아님
  • 수학적 이상과 장기간 동기 부여를 유지할 수 있게 에너지를 주는 일 사이의 균형
• 장기적으로 일하기 위해서는 자신의 에너지를 충전해주는 활동을 일정 부분 포함시켜야 함
  • 예: 코딩을 좋아하는 관리자는 조금 더 코드를 써야 장기적으로 유지됨
  • 프로세스를 다듬는 걸 좋아하는 사람은 효율 개선을 병행해야 유지됨
• ‘완벽한 최적화’보다 ‘지속 가능한 동력’을 만드는 것이 실제 커리어 성과에 더 중요함

40년 커리어 관점

• A forty-year career 글의 아이디어 탐구
• 각 역할에서 속도(pace), 사람(people), 명성(prestige), 이익(profit), 학습(learning) 등 다른 차원에 우선순위를 둘 기회가 있음
• "정답"은 없고 항상 트레이드오프가 있음
• 커리어 초기 결정들이 이후 40년에 걸쳐 복리로 작용
• 저자의 경우: 커리어 초기에는 타인에 대한 책임이 적어 Uber 같은 곳에서 극도로 열심히 일할 기회가 있었음
• 현재는 가족 책임이 더 많아 그런 방식으로 일관되게 일하는 트레이드오프를 감수할 의향이 없음
• 이러한 트레이드오프를 인식하고 의도적으로 결정하는 것이 커리어 형성에서 가장 가치 있는 일 중 하나
• 이러한 차원을 고려하고 반평생 동안 참여를 유지할 트레이드오프를 이해하는 건강한 자기 인식 없이는 커리어 자체를 갖기 매우 어려움

[GN⁺]

Hacker News 의견

• 나는 대기업부터 스타트업까지 네 곳에서 Engineering Manager(EM) 로 일해봤는데, ‘EM 역할’이라는 건 사실상 신화에 가깝다고 생각함

  • 회사마다 역할이 완전히 달라서, 어떤 곳에서는 프로덕트 중심, 어떤 곳에서는 사람 관리 중심이었음

  • 팀의 병목이 어디에 있느냐에 따라 Product / Process / People / Programming 네 축 중 하나를 보완하는 게 핵심임

  • 인원이 적으면 직접 코딩하며 범위를 조정하고, PM이 없으면 제품 기획부터 고객 커뮤니케이션까지 맡게 됨

  • 인원이 많으면 코딩은 포기하고 커리어 관리와 조직 내 조율에 집중해야 함

  • CEO에 가까운 보고 라인이면 세일즈, 운영, 고객 대응까지 다리 역할을 해야 함

  • 결국 중요한 건 팀의 균형을 맞추는 감각임

  • 나도 리더십 포지션 대부분이 이런 식이라고 느낌

    • 300명 규모 회사에서 Principal Tech Lead로 일하면서 PM, 사용자 인터뷰, CEO 데모 제작, 핵심 기술 개발까지 다 했음
    • 리더로 갈수록 ‘가장 가치 있는 일을 직접 찾아서 실행하는 사람’이 되어야 함

  • 작은 회사에서는 이런 적응력이 매니저뿐 아니라 개인 기여자(IC)에게도 필요함

  • 이 댓글이 원문 기사보다 훨씬 통찰력 있다고 느낌

• 엔지니어링 매니지먼트에는 유행이 많음

  • ‘기술을 몰라도 관리만 잘하면 된다’는 식의 관리 문화의 유행이 있었는데, 경제적 이유로 생긴 현상 같음

  • 진짜 리더십은 시대를 초월하고, 좋은 리더는 팀이 스스로보다 더 큰 성과를 내게 만드는 사람임

  • 나쁜 리더를 피하는 방법은 단순함 — 리소스를 거두고 거리두기임

  • 회사에서는 다른 팀으로 옮기는 식으로 표현할 수 있고, 이런 이동이 쌓이면 무능한 리더는 자연히 드러남

  • 하지만 엔지니어들은 종종 프로젝트 성공에 대한 헌신 때문에 나쁜 리더 밑에서도 오래 버팀

    • 리더를 바꾸는 건 도박이고, 인생 상황상 쉽게 옮기기 어려운 경우도 많음

  • 모든 리더십은 결국 기술적 리더십이어야 함

    • 도메인 전문성이 없는 리더십은 허상임
    • 비기술적 관리가 유행하면서 리더십 전반이 위기에 빠졌고, 정치·엔터테인먼트·기술 등 모든 분야에서 창의력 고갈이 나타남

• 나는 엔지니어링 매니지먼트의 유행이 걱정됨

  • 프로세스를 결과보다 중시하면 형식적 행동과 잘못된 인센티브가 생김

  • EM의 성과를 객관적으로 평가하기 어려워서 정치적 행동이 늘어남

  • 그래도 이 역할은 미래 리더를 키우는 핵심 단계라고 믿음

  • 젊을 땐 프로세스를 귀찮게 여겼지만, 지금은 가드레일의 중요성을 이해함

    • 이제는 자동화와 툴링으로 효율을 높이는 데 집중함

  • 엔지니어·디자이너·PM이 섞인 폴리매스 팀 구조라면 평가가 더 명확해질 수도 있다고 생각함

  • EM 역할이 비난받는 이유는 일부가 작은 왕국의 폭군이 되기 때문이라고 봄

• 훌륭한 퍼포머의 핵심은 적응력임

  • 유행이 바뀌어도 상황과 사람에 맞게 접근을 바꾸는 사람이 결국 성공함

  • 때로는 진짜 산출물이 행복한 팀 그 자체일 때도 있음

• 리더십은 15년 유행을 넘어서는 시대 초월적 주제임

  • 미 육군의 정의처럼, 리더십은 목적·방향·동기 부여를 통해 조직을 개선하는 과정임

  • 하지만 미군 사례에서 배울 점은 두 가지임

    1. 충분한 자원과 시간이 있으면 절대적 규율과 자율적 판단을 동시에 유지할 수 있음
    2. ‘장교 vs 병사’처럼 계층을 나누면 인센티브 불일치로 인해 목표 달성이 어려워짐

• 좋은 엔지니어링 매니지먼트의 기준은 객관적이지 않음

  • 조직의 문화와 습관 안에서 맥락적으로 정의되어야 함

  • 조직 안팎의 상황에 따라 ‘좋은 매니저’의 기준이 달라짐

    • 대규모 채용기에는 다르고, 대규모 해고기에는 또 다름
    • AI 도구 시대의 좋은 매니저가 어떤 모습일지는 앞으로 5년은 더 걸릴 것 같음

  • 정책의 실행이 곧 정책 그 자체임

    • 인력 최소화 정책이라면, 좋은 매니저는 이직 방지에 능한 사람임

• 리더십의 절대적 정의는 없지만, 상대적 정의는 있음

  • 목표와의 정렬(alignment) 정도가 핵심이며, 그 목표를 명확히 아는 것이 가장 어려움

• 요즘 많은 회사가 중간관리자 축소를 시도하지만, 관리 기능은 여전히 필요함

  • 그렇지 않으면 방향이 흐트러짐

  • 좋은 매니저는 매뉴얼이 아니라 상황판단력으로 움직이는 사람임

  • 하지만 이런 글을 보면 예전의 PTSD가 떠오름

• 상위 경영진과의 관계에서 EM의 핵심 역량은 정렬(alignment) 임

  • Product Management가 약하면 EM이 아무리 뛰어나도 조직 전체가 흔들림
  • 결국 제품팀과의 정렬이 모든 걸 좌우함

• 모든 기술은 결국 공감(empathy) 으로 귀결됨

  • 정렬이란 결국 공감의 다른 표현임

  • 나도 누군가를 설득할 때는 먼저 경청과 공감으로 시작함

    • 그 후에야 제안이 받아들여질 공간이 열림

  • 하지만 공감만으로는 부족하고, 때로는 미움받을 용기가 필요함

    • 공감이 과하면 갈등 상황에서 아무 결정도 못 내림

  • 공감의 중요성에는 동의하지만, 현실에서는 고함으로 밀어붙이는 리더도 존재함

    • 그런 장면을 보면 공감만으로는 조직이 돌아가지 않음을 느낌