당신이 겪어본 두 명의 매니저를 생각해 보세요 — 당신을 더 낫게 만든 사람과 그렇지 않은 사람. 그렇지 않은 사람은 아마도 당신을 바쁘게 만들었을 것입니다: 할당된 티켓, 완료된 리뷰, 참석한 스탠드업. 당신을 실제로 더 낫게 만든 사람은 아마도 더 미묘한 무언가를 했을 것입니다. 당신에게 약간 너무 큰 문제를 주고, 당신이 넘어지면 잡을 수 있을 만큼 가까이 있으면서, 당신이 스스로 알아내는 것을 지켜봤습니다. 그것이 멘토링의 전체 기술입니다.
저는 스타트업과 스케일업에서 8명에서 11명에 이르는 엔지니어링 팀을 이끌었으며, 빠르게 성장한 팀과 정체된 팀의 차이는 거의 항상 하나로 귀결되었습니다: 시니어들이 주니어들에게 투자하고 있었는가. 그들을 돌봐주는 것이 아닙니다. 그들의 일을 하는 것도 아닙니다. 투자 — 시간, 신뢰, 신중하게 설계된 어려움으로.
이 글은 엔지니어를 멘토링하는 첫 번째 시도 전에 누군가 내게 말해줬으면 했던 모든 것입니다. 솔직히 말하면, 내가 했고 배워야 했던 실수들의 기록이기도 합니다. 멘토링을 맡게 된 시니어 엔지니어이거나 팀을 구축 중인 테크 리드라면, 그 교훈들을 절약해 드리길 바랍니다.
멘토링이 레버리지인 이유
개인 기여자로 성장했다면 — 멘토링을 비용으로 생각하는 유혹이 있습니다. 개념을 설명하는 데 쓰는 시간은 코드를 작성하지 않는 시간입니다. 하지만 이 틀은 수학을 거꾸로 갖고 있습니다.
팀에 8명의 엔지니어가 있다면, 팀 산출물은 8명 분량의 작업입니다. 60% 용량으로 운영하던 사람이 80%에 도달하도록 돕는 순간, 채용, 온보딩 오버헤드, 신규 채용이 효과적이 되는 데 걸리는 세 달 없이 팀 산출물에 20%의 사람을 추가한 것입니다. 팀 전체와 한 해에 걸쳐 곱하면, 멘토링은 만들 수 있는 가장 높은 레버리지 투자 중 하나입니다.
천장 올리기 효과도 있습니다. 내가 함께했던 최고의 팀은 스타 플레이어가 가장 많은 팀이 아니었습니다 — 바닥이 가장 높은 팀이었습니다. 팀의 모든 엔지니어가 어려운 문제를 독립적으로 처리하도록 믿을 수 있을 때, 모든 것을 한두 명의 시니어에게 통과시키는 팀보다 훨씬 빠르게 이동할 수 있습니다. 멘토링은 그 바닥을 올립니다.
그리고 사람들이 인정하는 것보다 더 중요한 유지 측면이 있습니다. 엔지니어들은 직업을 그만두지 않습니다 — 정체를 그만둡니다. 팀을 떠나는 엔지니어들로부터 들은 첫 번째 이유는 "성장이 멈췄습니다"의 어떤 버전입니다. 시니어들이 주니어들에게 투자하는 문화는 사람들이 머물고, 기관 지식이 18개월마다 문 밖으로 나가지 않는 문화입니다.
있는 곳에서 만나세요
내가 가장 많이 보는 — 그리고 초반에 직접 만든 — 가장 큰 멘토링 실수는 잘못된 수준에서 도전을 제시하는 것입니다. 잠자면서도 할 수 있는 작업을 주면 지루해집니다. 진정으로 그들의 능력을 넘어서는 것을 주면 허우적거립니다. 마법은 그 둘 사이의 어느 구역에서 일어납니다.
발달 심리학자 Lev Vygotsky는 이것을 근접 발달 영역이라고 불렀습니다. 아이디어는 단순합니다: 독립적으로 할 수 있는 것들, 도움을 받아도 할 수 없는 것들, 그리고 — 그 사이에 — 올바른 지원이 있다면 거의 할 수 있는 것들이 있습니다. 그 중간 구역이 학습이 실제로 일어나는 곳입니다. 공황 없는 스트레치가 사는 곳입니다.
실제로, 이것은 그들이 이전에 한 것보다 한 단계 앞의 작업을 찾는 것을 의미합니다, 열 단계가 아닌. 간단한 API 엔드포인트를 처리한 주니어는 중간 복잡도의 기능을 소유할 준비가 되어 있습니다, 전체 시스템 재설계가 아닌. 솔로로 여러 기능을 전달한 미드레벨 엔지니어는 팀 간 조정을 포함하는 것을 리드할 준비가 되어 있습니다, 테크 리드가 하룻밤에 되는 것이 아닙니다.
누군가의 영역이 어디에 있는지 어떻게 알 수 있을까요? 물어보고 관찰합니다. 어떤 부분이 명확하고 어떤 부분이 흐릿한지 물어보세요. 페어링 세션에서 어디서 느려지는지 지켜보세요. 그들이 어떤 종류의 질문을 하는지 알아채세요 (큰 아키텍처 질문들은 보통 가장자리에 있다는 것을 신호합니다; 작은 문법 질문들은 보통 그렇지 않습니다). 주의를 기울이면 빠르게 보정할 것입니다.
구체적인 교수 도구들
제가 계속 돌아오는 몇 가지 기술들이 있습니다. 이국적인 것은 하나도 없습니다.
제대로 하는 페어 프로그래밍
페어링은 암묵적 지식 — 문서에 없는 종류, 문제가 보통 어디에 숨어 있는지 또는 그 패턴이 나중에 고통을 주는 이유에 대한 직관 — 을 전달하는 가장 빠른 방법입니다. 하지만 페어링은 주니어가 드라이빙할 때만 가르칩니다, 시니어가 아닌. 앉아서 그들이 지켜보는 동안 타이핑하기 시작하면, 능력을 시연한 것입니다. 그들이 어떤 것도 구축하도록 돕지 않은 것입니다.
실제로 효과가 있는 페어링 버전: 키보드를 그들 앞에 두고, 옆에 앉아서, 알아채는 것을 내레이션하세요. "여기서 먼저 엣지 케이스를 살펴볼 것 같습니다 — 이 리스트가 비어 있으면 어떻게 될까요?" 기다리세요. 그들이 생각하게 하세요. 틀릴 수 있게 하세요. 뛰어들지 않는 불편함이 실제로 무언가를 가르치기 위한 입장료입니다.
가르침 채널로서의 코드 리뷰
대부분의 코드 리뷰는 코드에 집중합니다. 좋은 멘토링은 그것을 생각에 대한 대화로 바꿉니다. 함수가 너무 길다고 지적하는 것 대신, 이유를 설명하세요 — 무엇이 이해하기 어려워지는지, 코드베이스가 성장하면서 무엇이 먼저 깨지는지. 친절하게 코드 리뷰하는 방법에서 이것을 친절하고 효과적으로 하는 역학에 대해 더 썼지만, 멘토링 각도가 여기에 추가할 가치가 있습니다: 리뷰는 누군가의 추론을 포착하고 습관이 되기 전에 재지시할 수 있는 몇 안 되는 장소 중 하나입니다.
배운 것 하나: 수정을 내리는 대신 리뷰에서 질문을 하세요. "두 요청이 동시에 이것을 건드리면 어떻게 될까요?"는 "이것은 스레드에 안전하지 않습니다"보다 더 유용합니다. 문제를 생각하도록 초대합니다; 그냥 답을 건네지 않습니다.
추론을 소리 내어 설명하기
시니어 엔지니어들은 엄청난 양의 압축된, 보이지 않는 지식을 갖고 있습니다 — 그것을 갖고 있다는 것을 그냥 잊어버렸을 뿐입니다. 결정을 내릴 때, 내레이션하세요. "이 규모에서는 추가적인 복잡성이 아직 가치 없기 때문에 Redis에 손을 뻗지 않고 여기서 간단한 인메모리 맵으로 가겠습니다." 말하는 데 3초가 걸리는 그 문장은 주니어 엔지니어가 스스로 배우는 데 몇 달이 걸릴 수 있습니다.
모든 것을 내레이션할 필요는 없습니다. 하지만 추론을 눈에 보이게 만드는 것 — 특히 답이 명확하지 않은 결정 포인트에서 — 은 누군가의 기술을 배우는 데 할 수 있는 가장 높은 수익을 내는 일 중 하나입니다.
안전망이 있는 스트레치 과제
내가 아는 가장 효과적인 교수 움직임은 약간 너무 큰 것을 할당하고, 그런 다음 가까이 있는 것입니다. 맴돌지 않고 — 그들은 허우적거릴 공간이 필요합니다 — 하지만 이용 가능하게. 자연스러운 이정표에서 확인하세요. 차단 요인을 예측하는 것이 아닌 그들이 당신에게 오도록 하세요. 목표는 안전망이 있는데도 독립적이라고 느끼게 하는 것입니다.
중요한 가드레일 하나: 스트레치 과제는 실제 이해관계가 있는 실제 마감일이 필요하지만, 실패가 치명적인 이해관계는 아닙니다. 준비되지 않은 작업으로 온콜 주말을 온전히 소진한 주니어 엔지니어는 더 위험 회피적이 될 것이지, 더 유능해지지 않습니다. 스트레치 크기를 시스템이 잘못될 것을 얼마나 허용할 수 있는지에 맞추세요.
스스로 해결하게 하기
이것이 가장 어려운 것입니다. 누군가가 막혀 있고 답을 알 때, 주지 않는 것은 진짜 규율이 필요합니다. 하지만 그 순간 줘버리면, 가르치는 것에서 하는 것으로 전환한 것입니다. 다음에 비슷한 문제에 부딪히면, 스스로 해결하기보다 당신에게 돌아올 것입니다.
대신 효과가 있는 것: 올바른 안내 질문을 하세요. "오류 메시지가 실제로 무엇을 말하나요?" "결제 모듈에서 비슷한 케이스를 어떻게 처리했는지 봤나요?" 목표는 그들 자신의 생각에서 다음 단계를 주는 것이지, 답이 아닙니다.
누군가가 문제를 가져오면, 아무 말도 하기 전에 30초를 기다리세요. 종종 그 시간에 자신의 질문에 답할 것입니다. 그렇지 않다면, 첫 번째 응답은 해결책이 아닌 질문이어야 합니다.
자율성 사다리
멘토링을 위해 발견한 가장 명확한 정신 모델 중 하나는 자율성을 사다리로 생각하는 것입니다. 사다리에서 어디에 있는지는 얼마나 많은 맥락을 줘야 하는지, 얼마나 자주 확인하는지, 어떤 종류의 작업을 할당하는지를 결정합니다. 멘토링의 목표는 항상 누군가를 한 칸 위로 이동시키는 것입니다 — 꼭대기까지 하룻밤에 당기는 것이 아니라, 계속 움직이게 하는 것.
| 단계 | 운영 방식 | 당신의 참여가 어떻게 보이는가 |
|---|---|---|
| 1 — 지시받음 | 단계별 지시가 필요하고; 대부분의 결정에 불확실합니다. 거의 모든 것에 행동하기 전에 묻습니다. | 작업을 자세히 정의하고, 모든 PR을 면밀히 리뷰하고, 매일 확인하며, 추론을 지속적으로 내레이션합니다. |
| 2 — 안내받음 | 친숙한 일을 독립적으로 처리할 수 있고; 새로운 상황에서는 입력이 필요합니다. 추측하는 것이 아니라 차단 요인을 당신에게 가져옵니다. | 명확한 목표를 설정하고, 범위를 정의하며, 주요 결정을 리뷰합니다. 매일이 아닌 며칠마다 확인합니다. |
| 3 — 협력적 | 자체 접근법을 제안하고, 트레이드오프를 생각하며, 위험을 사전에 지적합니다. 문제만이 아닌 옵션을 가져옵니다. | 안내자라기보다 사운딩 보드로 더 많이 역할합니다. 실행 전에 접근법을 리뷰하지만 실행을 신뢰합니다. |
| 4 — 위임됨 | 문제의 전체 소유권을 가집니다: 범위 지정, 실행, 이해관계자 소통. 진정으로 필요할 때만 에스컬레이션합니다. | 이정표에서 확인합니다. 두 번째 의견을 원할 때 이용 가능하지만, 그들이 전적으로 주도합니다. |
| 5 — 신뢰됨 | 어떤 문제든 맡길 것입니다, 스스로 어떻게 해결할지 확신하지 못하는 것들도 포함해서. | 동료 관계. 서로에게서 배웁니다. 당신의 역할은 범위를 주고 길을 비켜주는 것입니다. |
대부분의 신입 졸업생은 1단계에서 시작합니다. 2~3년의 경험으로 채용된 대부분의 엔지니어들은 2단계에 안착합니다. 거기서의 여정은 매니저와 팀이 그들을 위로 이동시키는 데 얼마나 의도적으로 투자하는지에 크게 달려 있습니다.
가장 흔한 실수는 누군가가 벌어들인 것보다 낮은 단계에 있는 것처럼 대우하는 것입니다. 누군가가 3단계에서 기능하고 있지만 1단계처럼 관리하고 있다면 — 모든 PR을 자세히 리뷰하고, 매일 확인하면 — 속도를 늦추는 것이지 돕는 것이 아닙니다. 신뢰는 점진적으로 확장하는 것입니다; 누군가가 결정적으로 "스스로를 증명했을" 때 주는 보상이 아닙니다.
신뢰는 확실성 전에 확장됩니다 — 그것이 신뢰를 신뢰이게 만드는 것입니다. 누군가에게 어려운 것을 맡기기 전에 완벽한 실적이 있을 때까지 기다린다면, 그 실적을 쌓는 데 필요한 조건을 거부한 것입니다.
티켓 닫기가 아닌 시니어 성장시키기
많은 멘토링 주의가 주니어에게 갑니다 — 당연히, 왜냐하면 주니어에서 미드레벨로의 델타가 가파르고 지원의 필요성이 명확하기 때문입니다. 하지만 티켓 클로저로 정체하고 결코 시니어에 도달하지 못하는 미드레벨 엔지니어들은 엔지니어링 팀에서 가장 흔하고 가장 예방 가능한 손실 중 하나입니다.
미드레벨과 시니어 사이의 간격은 대부분의 사람들이 생각하는 것보다 기술적 기술에 관한 것이 덜합니다. 기술적으로 강한 미드레벨 엔지니어들은 범위와 함께 오는 판단을 개발할 기회를 갖지 못했기 때문에 정체됩니다.
시니어를 성장시키는 것은 그들에게 다음을 주는 것을 의미합니다:
- 작업이 아닌 범위. 일련의 티켓이 주어진 미드레벨 엔지니어는 그 티켓들을 완료하고 그 외에는 아무것도 하지 않을 것입니다. 문제 — 소유할 시스템의 영역, 구축할 기능 — 를 주면, 분해하고, 순서를 정하고, 트레이드오프를 만드는 판단을 개발해야 합니다. 그 판단이 시니어를 정의합니다.
- 눈에 보이는 소유권. 영역에 대한 결정이 내려지는 방에 그들을 두세요. 이해관계자들에게 접근법을 발표하게 하세요. 도전받을 때 방어하게 하세요. 처음에는 불편하고 시간이 지나면서 귀중합니다.
- 멘토링 책임. 미드레벨 엔지니어를 주니어와 페어링해 멘토링하게 하는 것은 성장에 가장 좋은 촉진제 중 하나입니다. 가르치는 것은 하는 것과 다른 수준의 이해를 요구합니다. 또한 그들이 미드레벨에서 시니어로 가는 단계인, 본능적으로 만들고 있는 판단을 명확히 표현하게 합니다.
- 직접적인 일을 넘어서는 기술적 영향력. 표준 결정을 주도하고, ADR을 작성하고, 기술 포스트모템을 이끌게 하는 것 — 이 모든 것이 시니어 엔지니어가 가질 필요가 있는 영향력의 폭을 구축합니다.
명명할 가치 있는 멘토링 실수들
이것들의 대부분을 만들었습니다. 직접 만들지 않은 것들은 다른 좋은 엔지니어들이 인식하지 못한 채 만드는 것을 지켜봤습니다.
- 너무 일찍 구조. 누군가가 허우적거리는 순간 뛰어드는 것은 도움처럼 느껴집니다. 그렇지 않습니다. 생산적인 허우적거림이 성장이 사는 곳입니다. 구조는 누군가가 앞으로 나아갈 길 없이 너무 오래 막혀 있을 때를 위한 것입니다 — 첫 번째 어려움의 신호에서가 아닙니다.
- 모호한 피드백. "더 깔끔할 수 있습니다"는 아무것도 알려 주지 않습니다. "이 함수가 세 가지를 합니다 — 그 중 어느 것에 이름을 붙여도 오해를 유발할 것이고, 테스트하기 어렵습니다"는 실행할 수 있는 피드백입니다. 구체성이 친절함입니다.
- 지루한 작업만 위임하기. 주니어 엔지니어에게 할당하는 작업이 항상 가장 낮은 이해관계, 가장 낮은 가시성, 가장 기계적인 작업이라면, 자신을 위해 흥미로운 학습을 남겨두고 그들에게 단조로운 일의 커리어를 주고 있는 것입니다. 그들은 알아챕니다. 떠납니다. 스트레치 과제에는 좋은 것들도 포함되어야 합니다.
- 실제로 시간을 투자하지 않기. "질문이 있으면 이용 가능합니다"는 멘토링이 아닙니다. 멘토링은 예약된, 보호된 시간이 필요합니다 — 상태 업데이트가 아닌 멘토링 안건이 있는 정기적인 일대일; 의도적인 코드 리뷰; 의도적인 페어링 세션. 제대로 하고 있다면, 주당 2~3시간이 듭니다. 비용이 들지 않는다면, 아마도 의미 있는 방식으로 하고 있지 않을 것입니다.
- 자신에 관한 것으로 만들기. 목표는 그들의 성장이지, 사려 깊은 멘티를 가진 것에 대한 당신의 만족이 아닙니다. 때로는 그들에게 올바른 움직임이 다른 팀의 기회를 포함하거나, 코드베이스에 그들의 학습을 더 어렵게 만드는 문제가 있다는 피드백을 포함합니다. 좋은 멘토는 멘티를 먼저 둡니다.
다른 규모에서의 멘토링
핵심 원칙은 회사 규모에 따라 변하지 않지만, 그 주변 인프라는 엄청나게 변합니다.
| 회사 단계 | 멘토링이 일반적으로 작동하는 방식 | 주의할 점 |
|---|---|---|
| 스타트업 (<30명 엔지) | 비공식적이고 관계 중심적입니다. 멘토링은 업무 흐름에서 일어납니다 — 페어링, 리뷰, 그리고 일상적인 근접성. 공식 프로그램은 없지만, 작업 자체가 스트레치 과제이기 때문에 종종 매우 집중적입니다. | 산출물에 너무 묻혀 있어 다른 사람들에게 투자할 수 없는 시니어 엔지니어들. 긴박감에 의해 멘토링이 밀려납니다. |
| 스케일업 (30–150명 엔지) | 커리어 사다리를 갖기에 충분히 크지만 공식 멘토링 인프라를 구축하지 못한 경우가 많습니다. 멘토링 품질이 팀마다 크게 다릅니다. 일부 시니어들은 탁월하고; 다른 사람들은 그것에 대해 한 번도 생각해 본 적이 없습니다. | 불일치한 결과. 한 팀의 주니어는 빠르게 성장하고; 다른 팀의 주니어는 2년 동안 정체합니다. 형평성이 실제 문제가 됩니다. |
| 기업 (150명+ 엔지) | 공식 프로그램: 멘토십 페어링, 구조화된 커리어 프레임워크, 학습 예산, 전용 시간 할당. 더 많은 프로세스, 이것이 때로는 도움이 되고 때로는 실제 관계를 밀어내는 서류 작업입니다. | 진정한 투자를 대체하는 프로세스. 서류상의 멘토십 페어링이 월간 커피와 실제 도전 없음에 해당합니다. |
제가 참여한 한 스타트업에서는 공식 멘토링 프로그램이 없었지만, 팀의 세 명의 시니어들이 암묵적인 동의를 갖고 있었습니다: 모든 주니어 엔지니어는 첫 6개월 내에 최소 하나의 중요한 기능의 주요 소유자가 될 것입니다. 기능들은 지원을 받아 달성 가능하도록 범위가 지정되었고, 사소하지 않았습니다. 시니어들은 까다로운 부분에서 페어링하고 모든 것을 면밀히 리뷰했지만, 주니어가 주도했습니다. 1년이 끝날 때, 그 주니어 엔지니어들은 타이틀만 빼고 미드레벨의 모든 면에서였습니다.
나중에 합류한 큰 회사에서는 매우 정교한 멘토링 프로그램이 있었습니다 — 공식 페어링, 분기별 체크인, 목표를 위한 공유 문서 템플릿. 그리고 대부분 효과가 없었습니다, 왜냐하면 문서 템플릿이 멘토링이 되었기 때문입니다. 아무도 주니어 엔지니어들이 실제로 더 나은 일을 하고 있는지 추적하지 않았습니다 — 단지 더 나은 서류 작업인지. 제가 얻은 교훈: 관계와 의도적인 도전이 중요한 것입니다. 다른 모든 것은 발판입니다.
핵심 요약
- 멘토링이 레버리지입니다. 한 엔지니어의 역량을 성장시키는 것은 팀 산출물과 유지에 복리 수익을 갖습니다 — 드는 시간보다 훨씬 많이.
- 스트레치 영역이 학습이 사는 곳입니다. 작업은 현재 능력보다 한 단계 앞이어야 합니다, 열 단계가 아닌. 너무 쉬우면 지루함을 낳고; 너무 어려우면 마비를 낳습니다.
- 효과가 있는 교수 도구들: 주니어가 드라이빙하는 페어링, 코드 리뷰에서 수정이 아닌 질문, 추론을 소리 내어 내레이션하기, 안전망이 있는 스트레치 과제, 스스로 해결하도록 저항하기.
- 자율성 사다리는 누군가가 어디에 있는지와 어디로 가는지에 대한 공유된 언어를 줍니다. 확실한 곳보다 한 단계 앞서 신뢰를 확장하세요.
- 미드-시니어 성장은 범위, 소유권, 다른 사람 멘토링, 그리고 기술적 영향력을 통해 일어납니다 — 더 어려운 티켓이 아닌.
- 흔한 함정: 너무 일찍 구조, 모호한 피드백, 지루한 작업만 위임하기, 실제 시간을 투자하지 않기.
- 관계가 프로그램입니다. 공식 구조는 규모에서 도움이 되지만, 발판입니다. 실제 일은 의도적인 도전, 솔직한 피드백, 그리고 확실성 전에 확장된 신뢰입니다.
이것은 엔지니어링 문화에 관한 작은 시리즈의 두 번째 글입니다. 아직 읽지 않으셨다면, 친절하게 코드 리뷰하는 방법에 관한 첫 번째 글은 사기를 꺾지 않으면서 가르치는 방식으로 피드백을 주는 역학을 다룹니다 — PR 수준에서 적용된 같은 기술입니다. 문화, 채용, 그리고 팀이 실제로 작동하는 방식에 대한 더 많은 글이 올 예정입니다.