엔지니어링 매니저로 10년간 일하며 깨달은, 흔히 말하지 않는 교훈들—역할의 유연성, 제품 중심 사고, 프로세스의 함정, 신뢰와 위임, 그리고 리스크 관리까지.
제 상사가 제게 팀 채용을 시작해야 한다고 말한 지도 꽤 시간이 흘렀습니다. 채용을 하는 김에 온보딩도 맡아달라고 했죠… 로드맵을 알고 있으니 그 부분도 책임지라고 했고… 사람들을 아니까 커리어 코칭도 할 수 있겠다고 했습니다.
그때는 몰랐지만, 그는 저를 엔지니어링 매니저로 만들어버리고 있었습니다.
그 이후로 저는 네 개 회사에서 매니저로, 한 회사에서는 창업자로, 또 다른 곳에서는 매니저들의 매니저로 일했습니다. 흔히들 하는 엔지니어링 매니지먼트의 표준 조언과 교훈은 건너뛰고, 덜 очевид한(비자명한) 것들에 집중해 보겠습니다.
엔지니어링 매니저(Engineering Manager)의 표준 정의 같은 것은 없습니다. 무작위로 두 명의 매니저를 뽑아 보면, 같은 회사에 있더라도 하는 일이 매우 다를 수 있습니다.
제가 일했던 모든 회사에서 제 역할은 한 번도 똑같았던 적이 없습니다. 유일한 상수는 “팀의 필요”에 의해 역할이 정의된다는 점이고, 그 과정에서 당신은 네 가지 기둥: 제품(Product), 프로세스(Process), 사람(People), 프로그래밍(Programming) 사이의 균형을 맞춰야 한다는 것입니다.
몇 가지 예를 들면:
팀이 큰가? 프로그래밍과는 작별하세요. 커리어를 설계하고, 노력을 조율하고, 조직을 헤쳐 나가며 팀이 필요한 리소스를 확보하는 데 집중하게 됩니다.
팀이 작은가? 현실에 맞게 스코프를 관리해야 하고, 커뮤니케이션 오버헤드가 적으니 실제로 코딩도 조금 할 수 있습니다.
PM이 없는가? 제품을 전적으로 책임집니다. 기능을 검증하고, 로드맵 우선순위를 정하고, 고객과 대화합니다. 사용자 가치가 없는 기능을 출시하는 건 다른 모든 일을 무의미하게 만들기 때문에, 이게 대부분의 시간을 차지합니다.
CEO에게 직접 보고하는가? 이제 영업, 운영, 고객 커뮤니케이션으로 연결되는 고리가 됩니다.
핵심은 소프트웨어 개발 라이프사이클에서 팀의 병목이 어디에 있는지 파악하는 것입니다. 상황이 바뀌면 기둥 사이를 오가게 될 텐데, 그게 바로 요점입니다. 이 역할은 유연성을 요구합니다.
팁: 인터뷰에서 “매니저에게 뭘 기대하나요?”라고 직접 묻지 마세요. 어떤 매니저들은 자신의 경험이 업계 표준이라고 생각해서 그 질문을 이상하게 여길 수 있습니다. 대신 그들의 하루 일과가 어떤지, 시간 대부분을 잡아먹는 도전 과제가 무엇인지 물어보세요.
개발자로 일하던 시절, 저는 몇 번이나 “이 기능은 대체 누구를 위한 거지? 누가 쓰는 거지?”라고 생각했습니다. 그런데 팀의 누구도 몰랐습니다. 우리가 하는 이유는 시키니까 였죠. 사기는 낮았습니다. 중요하지 않은 것들에 시간을 쓰고 있다는 느낌이 들었고—실제로도 그랬습니다. 결국 팀은 해체됐고, 엔지니어들은 다른 프로젝트로 흩어졌습니다.
회사가 실패하는 가장 흔한 이유는 사용자가 돈을 낼 만큼의 가치를 제공하지 못하는 제품을 만들기 때문입니다.
“아, 그건 PM이 하는 거 아닌가요?”라고 말할 수도 있습니다. 하지만 PM이 있다고 해서 충분하지 않습니다. 모두가 제품을 신경 써야 합니다. 팀은 단지 코드를 ‘납품’하라고 돈을 받는 게 아니라, 코드를 통해 문제를 해결하라고 돈을 받습니다.
코드는 최종 사용자에게 이득이 있을 때만 가치가 있습니다. 때로는 노코드(no-code) 통합이 커스텀 솔루션보다 더 나을 수도 있습니다. 어떤 때는 새 기능을 아예 만들지 않는 편이 유지보수해야 할 시스템을 늘리지 않아서 더 낫습니다. 스펙이 아니라 문제를 이해하는 팀은 필요할 때 방향을 바꿀 수 있습니다.
모든 프로세스는 시간과 주의를 신뢰성이나 품질로 바꾸는 트레이드오프입니다. 문제는 팀이 그 트레이드오프가 여전히 가치가 있는지 묻기를 멈출 때 발생합니다. 의식(세레머니)은 의례가 됩니다. 지표는 목표가 됩니다. 우리가 왜 이 회의에 인생의 한 시간을 쓰는지 아무도 기억하지 못합니다.
프로세스 비대화는 천천히 스며듭니다. 어떤 엔지니어가 깨진 UI를 프로덕션에 내보냅니다. 디자이너는 불평하고, 매니저는 패닉에 빠지고, 어느새 모든 PR에 디자이너 승인 절차가 생깁니다. 단 한 번의 고립된 사고 때문에 팀 전체가 비용을 부담합니다.
좋은 프로세스는 고객을 잘 섬기기 위해 당신을 돕습니다. 하지만 경계하지 않으면 프로세스가 ‘그 자체’가 될 수 있습니다. 결과를 보지 않고, 그저 프로세스를 제대로 따르고 있는지만 확인하게 되죠. 프로세스는 ‘그 자체’가 아닙니다. 우리가 프로세스를 소유하는지, 프로세스가 우리를 소유하는지 묻는 것은 언제나 가치가 있습니다.
— 제프 베이조스, 2016 주주 서한
올바른 프로세스는 맥락에 따라 달라집니다. 팀 규모, 숙련도, 데드라인 압박. 성숙한 팀에 맞는 방식이 새 팀에는 맞지 않을 수 있습니다. 계속 질문하고 반복 개선하세요. 프로세스가 딜리버리 개선에 도움이 되지 않는다면, 없애세요.
직속 보고자(direct reports)는 당신과 가장 많이 상호작용하는 사람들입니다. 그들은 당신에게 리더십과 명확성을 기대하고, 필요한 정보를 알려줄 것이라고 믿습니다.
그래서 그들에게 영향을 주는 정보를 거짓말하거나 숨기면 되돌릴 수 없는 손상이 생깁니다. 당장 퇴사하지는 않아도, 당신을 원망하게 됩니다.
제 친구는 3년 전에 한 매니저가 했던 거짓말을 아직도 원망합니다. 그 친구는 다른 회사로 옮겼지만, 그 일에 여전히 화가 나 있습니다.
“신뢰는 걸어서 오고, 말 타고 떠난다.”
- 네덜란드 속담
어떤 매니저들은 역할을 “위에서 내려오는 모든 것을 막아주는 방패”라고 설명하는데, 저는 동의하지 않습니다. 좋은 매니저는 불투명한 방패가 아니라 투명한 우산에 가깝습니다. 불필요한 스트레스와 압박으로부터 팀을 보호하되, 현실을 숨기지는 않습니다.
팀에게 이렇게 말하는 것: “지금까지 사용자 반응이 썩 좋지 않아요. 더 잘 섬길 방법을 찾아야 합니다. 그러지 못하면 프로젝트가 취소될 위험이 있어요.” 이런 건 충분히 말해도 됩니다. 팀은 알 권리가 있습니다.
어려운 소식을 전할 때는 명확히 말하고, 팀이 무엇을 할 것인지에 초점을 맞추세요. 당신이 겁먹은 듯 행동하면 팀도 겁먹습니다. 목표는 다음 단계를 생각하게 만드는 것입니다.
저는 매니저들이 임원 회의에 들어가서 “우리도 잘 모르겠어요—A일 수도 있고 B일 수도 있고요?”라고 말하고, 결국 팀이나 프로젝트에 도움이 되지 않는 Z를 하라는 지시를 받고 나오는 것을 봅니다.
임원들은 모든 가능성을 세부적으로 검토할 수 없습니다. 그 책임은 당신과 제품 오너에게 있습니다(앞에서 봤듯, 그 사람이 당신일 수도 있습니다). 문제가 임원까지 올라갔다는 것은 의사결정이 필요하다는 뜻이고, 그들은 결정을 내릴 것입니다.
윗사람들은 당신의 구체적인 이슈에 집중할 시간이 제한적입니다. 그들에게 정보를 한꺼번에 쏟아붓는(info dump) 건 불가능합니다. 당신이 전달한 내용 때문에 그들이 잘못된 행동을 하면, 그건 당신 책임이 됩니다.
무언가를 믿는다면, 장단점을 포함해 논리를 분명히 제시하세요. 상사가 당신 대신 생각해 주길 기대하지 마세요. 직속 상사에게 거친 아이디어를 던져보는 것은 괜찮지만, 그 이상으로는 생각을 정제하세요. 당신 문제를 당신과 팀만큼 진지하게 고민해 줄 사람은 없습니다.
가이드라인이 필요하다면 문서는 이렇게 구성하면 됩니다: 맥락 → 문제 → 계획/대안 → 필요한 지원.
플레이어(10%): 네, 고작 10%입니다. 팀이 반기지 않는 일이지만 중요한 일을 맡을 수 있습니다. 예: CI/CD 개선, 불안정한 테스트(flaky tests) 정리, 프로세스/툴링 개선. 하지만 크리티컬 패스에서는 빠져 있어야 합니다. 필수 티켓을 직접 처리하기 시작하면, 매니저 일이 당신을 끌고 갈 때 팀을 막게 됩니다.
코치(30%): 매니저로서의 성과는 팀 산출물의 합입니다. 코칭은 독성, 반복되는 실수, 지속적인 저성과 같은 문제 행동이 ‘정상’으로 굳어지지 않도록 막는 것을 포함합니다.
또한 적절한 수준의 도전을 주고, 올바른 피드백을 제공하며, 앞으로도 가져갈 수 있는 역량을 키우도록 도와 엔지니어의 성장을 지원하는 것이기도 합니다.
치어리더(60%): 생각보다 더 많이 칭찬하세요. 인정은 중요합니다. 대부분의 엔지니어는 탁구대가 있는 것보다 인정받는 느낌을 더 선호합니다.
다만 칭찬은 자동으로가 아니라 진심으로 하세요. 저는 한 번 레트로스펙티브에 매주 30분씩 상호 칭찬을 하는 팀에 들어간 적이 있습니다. 매주 n²개의 칭찬을 주고받는 셈이었죠. 공허하게 느껴졌습니다. 매주 특별한 일이 있는 건 아니고, 칭찬이 ‘기대’가 되면 효과를 잃습니다. 쾌락 적응(hedonic treadmill)은 واقعی로 존재합니다.
팀 밖에서도 엔지니어들의 성과가 보이게 만드세요. 팀 외부에서 임팩트를 추구하도록 격려하고, 그렇게 했을 때 성취를 함께 축하하세요.
모든 팀은 더 큰 조직 안에서 작은 회사처럼 작동합니다. 저는 그 팀의 사기 또한 회사 전체 사기와 독립적으로 존재한다고 느낍니다.
대부분의 매니저는 병목이 되려고 계획하지 않습니다. 점진적으로 그렇게 됩니다. 중요한 도구에 오너가 필요해서 “일단 내가 할게”라고 생각합니다. 다른 팀과의 창구 역할을 누군가가 해야 하는데, 내가 하는 게 가장 쉽습니다. 맥락을 아는 사람이 나뿐이라 기술적 결정이 계속 내 책상으로 떨어집니다. 어느 순간, 내가 없으면 일이 멈춥니다.
한 달 휴가를 다녀와도 팀이 잘 굴러가게 만들 수 없다면, 그렇게 될 수 있도록 노력해야 합니다.
당신은 병목이 되기에는 너무 바쁩니다. 반복적인 업무로 사람들이 계속 당신을 찾는다면, 누군가에게 가르쳐서 위임하세요. 팀원들을 서로 직접 연결해 주거나, 더 좋게는 자연스러운 논의가 이뤄지도록 그룹 채팅을 만드세요.
버스 팩터(bus factor)가 1이 되지 마세요. 당신이 과부하이거나 부재해도 일이 매끄럽게 진행되도록 다른 사람을 훈련시키세요.
작고 되돌릴 수 있는 결정에 대해 사람들이 당신의 허락이 필요하다고 느끼게 하지 마세요. 자율성을 부여하세요. 결정 내용을 공유해 달라고 요청하되, 기술적인 판단은 그들이 하게 하세요.
이렇게 해야 하는 이유는, 매니저 업무는 최악의 타이밍에 튀어나올 수 있고 실제로 튀어나오기 때문입니다. 당신이 버스 팩터라면, 그 일이 벌어졌을 때 팀을 망치게 됩니다. 엔지니어는 여럿이지만 매니저는 한 명뿐입니다. 당신만이 할 수 있는 일에 접근 가능하게 남아 있으세요.
마이크로매니저가 마이크로매니징을 하는 이유는 신뢰하지 않기 때문입니다.
스스로에게 물어보세요. 당신이 계속 지켜보지 않아도 팀의 모든 엔지니어가 최선을 다할 거라고 믿을 수 있나요? 아니라면, 바뀌어야 할 것은 당신이거나 그들입니다.
신뢰는 기술력만의 문제가 아닙니다. 지금 제 팀의 엔지니어들에게(모바일/웹 개발자) Game Boy 에뮬레이터를 처음부터 만들라고 하면, 어디서부터 시작해야 할지 모를 겁니다. 아마 몇 달이 걸릴 것이고(어떤 사람은 몇 주), 하지만 포켓몬 골드를 돌리기 위해 최선을 다해 파고들 거라는 건 확신합니다.
당신은 그들의 능력과 정직함 둘 다를 신뢰해야 합니다:
그들의 경력 수준에서 기술을 신뢰할 수 없다면, 더 잘하도록 돕는 것이 당신의 일입니다.
정직함을 신뢰할 수 없고, 그럴 만한 이유가 충분하다면, 함께 갈 수 없습니다.
심지어 뛰어난 엔지니어도 본인이 막혔다는 사실을 모른 채 막힐 수 있습니다. 진행 상황을 관찰하면, 다른 사람들이 그들을 저성과자로 보기 전에 지원이 필요한 순간을 포착할 수 있습니다.
스프린트나 OKR 같은 프로세스는 주로 “검증(verify)” 단계에 집중합니다 (보시다시피, 당신의 상사도 이걸 합니다). 이는 일이 완료되도록 보장하는 공유 인터페이스 역할을 합니다. 이는 불신의 문제가 아니라 책임(accountability)의 문제입니다.
검증은 지표와 증거를 활용합니다. 정량과 정성, 두 가지가 있습니다.
정량은 단순합니다: 머지된 PR 수, 완료 포인트, 코드 리뷰 수. 이런 것들은 대충 볼 수는 있지만, 이것만으로 결정을 내리면 안 됩니다. 숫자로 엔지니어 성과를 측정할 수 있다면 매니저는 필요 없을 겁니다.
정성 지표를 아는 것이 매니저의 가치를 보여줍니다. “이 엔지니어는 PR 수는 적지만, 항상 Slack을 보고 있다가 다른 사람을 도우려고 콜에 들어온다.” “이 엔지니어는 항상 제품과 티켓을 먼저 논의한다—그래서 결과물이 초기 스펙보다 훨씬 낫다.” “이 엔지니어는 복잡한 개념을 모두가 이해할 수 있게 설명하고, 다른 팀이 우리 도구를 더 잘 쓰게 만든다.”
이런 통찰은 팀을 정말로 알아야만 생깁니다. 그래서 대부분의 ‘관리 AI 도구’는 실패할 수밖에 없습니다. 그들은 정량 지표에만 집중합니다. 스탠드업에도 참석하지 않고, 1:1을 대신해주지도 못하며, 조용히 팀을 떠받치는 사람이 누군지도 모릅니다. 좋은 매니저는 압니다.
펫 프로젝트는 그만하세요. 그건 스태프 엔지니어의 영역입니다. 매니저에게 모든 프로젝트는 ‘가축(cattle)’입니다: 완료되거나, 자동화되거나, 위임되거나, 취소되어야 합니다.
매니저가 프로젝트를 붙잡는 이유는 많습니다. 때로는 익숙함입니다. 그 시스템을 내가 만들었고, 가까이 있으면 마음이 편하죠. 때로는 정체성입니다. “기술적으로 남고” 감을 잃고 싶지 않습니다. 때로는 두려움입니다. 내가 없으면 제대로 안 될 것 같아서요. 그 어느 것도 붙잡고 있을 좋은 이유가 아닙니다.
“내가 하면 더 빨라”라는 생각이 맞을 수도 있습니다. 하지만 장기적으로 지속 가능하지 않습니다. 당신이 직접 할 때마다, 누군가가 배울 기회를 빼앗고, 결국 당신이 영원히 그 일을 하게 됩니다.
리스크를 회피하되, 리스크에 편집증적으로 반응하지 마세요. 모든 변수를 다 고려할 수는 없습니다. 예측할 수 없는 일도 있고, 과잉 보정이 원래 문제보다 더 나쁠 수 있습니다.
제가 이런 현상을 가장 자주 보는 곳이 채용입니다. 한 번 나쁜 채용을 겪고 나면, 매니저들은 추천(referral)만 받으려 합니다. 하지만 실력이 없거나 정직하지 않은 사람도 누군가에게 보증을 구할 수 있습니다. 어떤 사람들은 면접관을 패널에 더 추가합니다. 더 많은 눈이 더 나은 검증을 의미한다고 생각하니까요.
하지만 실제로는 반대가 일어납니다. 각 면접관은 “누군가가 나쁜 소리 하겠지”라고 생각하며 더 느슨해집니다. 책임이 희석됩니다. 훌륭한 3번의 인터뷰가, 평범한 7번의 인터뷰보다 낫습니다.
2차 효과(second-order effects)도 생각하세요: 7번째 라운드를 잡느라 시간을 끌면, 좋은 후보는 다른 곳에서 오퍼를 수락합니다. 최고의 인재는 빠르게 움직입니다. 느리고 리스크 회피적인 프로세스는, 당신이 뽑고 싶던 정확히 그 사람들을 걸러냅니다.
이 글의 내용이 공감됐다면, 제가 무료로 공개하고 있는 작업 중인 온라인 책에서 더 깊게 다룹니다. 당신도 매니저라면, 무엇을 배웠는지 듣고 싶습니다. 댓글로 남겨주세요!
