엔지니어링 매니저의 일, 네 가지 축으로 나눠 보기

출처: Effective Software Leads (James Samuel)
원문: https://softwareleads.substack.com/p/the-four-pillars-of-engineering-management
작성자: 팔복소프트-김팔복

한눈에 보기

• 엔지니어링 매니저가 존재하는 이유는 본인의 기여가 아니라 팀 전체의 성과를 키우기 위해서다.
• 매니저의 일은 People, Technical, Product, Delivery 네 가지 리더십으로 나눌 수 있다.
• 네 축의 비중은 고정되어 있지 않고, 팀 상황에 따라 1년 사이에도 크게 바뀐다.
• AI 도구가 보편화된 지금도 매니저가 코드베이스에서 멀어지지 않기를 기대하는 조직이 있다.
• 국내 개발 조직은 PM 부재와 플레잉 매니저 관행 때문에 네 축 중 특정 축에 쏠리기 쉽다.

배경

국내에서는 "엔지니어링 매니저"라는 직함보다 파트장, 팀장, 개발실장 같은 이름이 더 익숙합니다. 역할 정의 없이 시니어 개발자가 어느 날 팀장이 되고, 코드는 그대로 짜면서 사람 관리와 일정 관리가 얹히는 경우가 대부분입니다. 해외에서는 이 역할을 별도 직군으로 보고 어떤 책임을 지는지 나누어 설명하려는 시도가 많은데, 이번 글은 그중 가장 단순한 분류 하나를 제안합니다.

주요 내용

매니저는 왜 필요한가

글쓴이는 매니저가 없는 완전 수평 조직을 먼저 가정해 봅니다. CEO와 CTO 밑에 수백 명의 개발자가 AI 도구를 끼고 코드를 짜는 구조입니다. 이 구조가 무너지는 이유는 규모입니다. 인원이 늘수록 소통, 우선순위 조정, 의사결정에 드는 비용이 커지고, 누군가 의도적으로 정렬을 만들지 않으면 실력 있는 팀도 느려집니다. 매니저는 이 문제를 풀라고 만든 자리이고, 그래서 매니저의 성과는 본인이 한 일이 아니라 영향을 준 사람들의 성과 합으로 측정됩니다.

네 가지 축

원문의 핵심은 매니저의 책임을 아래 네 가지로 묶은 것입니다. 원문에는 없는 형태로 정리해 봤습니다.

People 축이 가장 어렵다고 글쓴이는 봅니다. 기술 문제와 달리 사람 문제는 0과 1로 떨어지지 않고, 팀원마다 동기와 목표가 다르기 때문입니다.

Technical 축에서 눈에 띄는 대목은 "팀에서 가장 잘하는 개발자가 될 필요는 없다"는 점입니다. 매니저의 기술 리더십은 모든 결정을 직접 내리는 게 아니라, 팀이 일관되게 좋은 결정을 내리도록 돕고 그 결정이 비즈니스 목표와 맞는지 확인하는 일입니다. 우아한 해법이라도 너무 오래 걸리거나 불필요한 복잡성을 더하면 틀린 해법이라는 지적도 있습니다.

Product 축은 PM을 대체하라는 뜻이 아닙니다. 6개월짜리 기능 요청이 들어왔을 때 예/아니오로 답하는 대신, 더 작은 기능으로 문제를 풀 수 없는지, 투자 전에 가설을 검증할 수 없는지 묻는 역할입니다.

Delivery 축에서는 Agile, Scrum, Kanban 같은 프레임워크 자체는 성공 요인이 아니라고 못 박습니다. 중요한 건 개발자가 기다리고 추측하는 시간을 줄이고 만드는 시간을 늘리는 것입니다.

비중은 계속 움직인다

원문이 반복해서 강조하는 부분입니다. 플랫폼 마이그레이션이 한창일 때는 Technical 축에 시간이 쏠리지만, 마이그레이션이 끝나고 조직이 급성장하면 같은 직함으로 채용과 온보딩에 대부분의 시간을 쓰게 됩니다. 매니저의 일은 "지금 팀의 발목을 잡는 게 무엇인지 찾아서 치우는 것"이고, 그 대상이 바뀌면 시간 배분도 바꿔야 합니다.

팔복소프트 관점

• 국내 개발 조직, 특히 SI와 초기 스타트업에서 팀장은 대부분 플레잉 매니저입니다. 이 구조에서는 Technical 축에 시간이 집중되고 People 축은 연말 평가 때만 잠깐 등장합니다. 이 글의 네 축을 자기 달력에 대입해 보면 어디가 비어 있는지 바로 드러납니다. 저는 이 글의 쓸모가 여기에 있다고 봅니다.
• Product 축은 국내에서 오히려 비중이 더 큽니다. 전담 PM 없이 기획자와 개발팀장이 요구사항을 나눠 들고 있는 팀이 많고, 기획자가 개발 비용 감각이 없으면 "만들지 말아야 할 것"을 말할 사람은 개발팀장뿐입니다. 이 역할을 안 하면 팀이 요구사항 처리기로 전락합니다.
• Delivery 축에서 프레임워크가 중요하지 않다는 원문의 입장에 동의합니다. Jira를 도입하고 스프린트를 돌리는 것으로 애자일을 했다고 여기는 조직이 아직 많은데, 실제로 봐야 할 지표는 개발자가 착수 전에 요구사항을 다시 물어보러 다니는 시간입니다.
• 한계도 분명합니다. 이 글은 분류 체계이지 실천 가이드가 아닙니다. 1:1 미팅을 어떻게 하는지, 기술 부채 투자를 경영진에게 어떻게 설득하는지는 나오지 않습니다. Will Larson의 An Elegant Puzzle이나 Camille Fournier의 The Manager's Path처럼 실행 방법을 다룬 책과 같이 읽어야 균형이 맞습니다.
• 그래도 신임 팀장이 처음 읽기에는 이 글 정도의 단순함이 낫습니다. 지난 한 달간 쓴 시간을 네 축에 나눠 적어 보는 것만으로도 자기 진단이 됩니다.

정리

기억할 것은 하나입니다. 매니저의 일은 코드를 더 많이 짜는 게 아니라 팀이 막힌 곳을 찾아 치우는 것이고, 막힌 곳은 사람일 수도, 기술일 수도, 제품 방향일 수도, 실행 체계일 수도 있습니다. 네 축은 그걸 빠뜨리지 않고 점검하는 체크리스트로 쓰면 됩니다. 지금 어느 축에 시간을 쓰고 있는지, 그게 팀에 지금 필요한 축인지 한 번 대조해 보세요.

• 엔지니어링 매니저
• 개발팀장
• 조직문화
• 리더십
• 개발 프로세스