주니어 멘토링 1년, 가르치다 시니어 개발자가 더 배운 5가지

 

주니어 멘토링 1년 동안 가장 많이 성장한 건 멘티가 아니라 저였어요. 가르치려 준비하는 과정에서 제 사고 과정의 구멍이 다 드러나더라고요.

 

5년 넘게 손에 익은 코드 패턴이었는데, 옆자리 신입이 "이거 왜 이렇게 돼요?" 한마디 던졌을 때 5초 넘게 입이 막혔습니다. 그제야 알았어요. 제가 "안다"고 생각했던 것들 중 절반은 그냥 "익숙한" 것에 불과했다는 사실을요.

 

"이거 왜 이렇게 돼요?" 주니어 멘토링 첫 3개월의 침묵

첫 달 즉답률을 노션에 적어보니 후배 질문에 즉답 못한 비율이 38% 정도 나왔습니다. 5년간 손에 익은 기술을 "관습이에요" 한 마디로 넘겼고, 그게 부끄러워 그다음엔 그냥 PR 위에 손 얹고 "이렇게 고치세요" 식으로 마무리했어요. 마이크로매니징이라기보다는 도망이었어요.

 

이걸 심리학에선 지식의 저주(Curse of Knowledge)라고 부르는데, 1990년 스탠퍼드에서 박자를 손으로 두드리고 듣는 쪽이 노래를 맞추는 실험을 한 적이 있다고 해요. 두드린 쪽은 정답률을 50%로 예측했지만 실제는 2.5%였다고 합니다. 제 머릿속 박자가 후배 귀엔 안 들리고 있었던 거지요.

 

 

가르치려 준비할 때 켜지는 시니어 개발자의 메타인지

신기한 건 멘티가 질문할 때보다 멘티에게 설명할 자료를 만들 때 제가 더 많이 배웠다는 점이에요. 트랜잭션 격리 수준 같은 건 5년 내내 외워 쓰던 개념인데, 그걸 그림 한 장으로 그리려니까 손이 멈추더라고요. 외운 거랑 설명할 수 있는 거랑은 완전히 다른 능력이었어요.

 

그래서 '내가 설명 못 하는 개념 리스트'를 사내 슬랙 개인 채널에 따로 모았어요. 한 달 모아보니 신기하게도 시니어 면접 단골 질문이랑 거의 겹치더라고요. 멘토링이 곧 제 약점 지도였던 셈이에요. 교육 심리학에선 이걸 protégé effect, 우리말로는 가르치며 배우기 효과라고 부른다고 해요.

 

 

답 대신 질문을 돌려주자 달라진 주니어 PR

마이크로매니징을 반성한 다음엔 반대로 손을 너무 떼서 멘티 PR이 한 주 묵는 일도 있었습니다. 균형을 잡은 건 답이 아니라 질문을 돌려주기 시작하면서였어요.

 

"이 코드가 실패할 수 있는 3가지 경우는요?" 같은 소크라테스식 질문 하나만 던져도 멘티가 스스로 리팩토링해 다시 가져오는 비율이 처음 18%에서 반년쯤 지나니 54%까지 올라왔습니다. 작은 PR은 머지 권한까지 넘겨서 "안전한 실패"를 허용했고요.

 

개인적으로는, 시니어 역할이 후배 PR을 막아주는 차단기가 아니라 후배가 안전하게 실패하고 복구하는 회로를 설계하는 사람에 가깝다고 봅니다. 답 빨리 주는 시니어보다, 질문 잘 돌려주는 시니어가 팀의 누적 학습량을 훨씬 키운다고 보고 있어요.

 

 

후배 코드에서 시니어가 리버스 멘토링으로 다시 배우는 것

리버스 멘토링이라는 게 거창한 말이 아니라, 후배가 가져온 도구 하나 깔아보면 바로 체감됩니다. 멘티가 Biome 과 Bun 으로 갈아끼우자고 제안했을 때 솔직히 처음엔 회의적이었는데, 적용 후 CI 시간이 거의 70% 가까이 줄었어요. 제가 6년째 손에 익은 도구를 못 놓고 있었던 거였습니다.

 

근본 질문은 더 셌어요. "이 레거시 함수 왜 아직 살아 있어요?"라는 한 줄에 코드를 뒤져보니 3년 전 제가 미리 막아둔 과설계가 그대로 남아 있었습니다. 그 자리에서 200줄 정도 지웠어요.

 

신입 시선으로 들어오니 보이는 사각지대도 있었습니다. "사내 용어가 정의 없이 쓰여서 어디서부터 봐야 할지 모르겠다"는 피드백 하나에 첫 설정 문서를 새로 정리했더니, 신규 입사자 적응 기간이 평균 9일에서 4일로 줄었어요.

 

 

시니어 개발자에게 멘토링은 시간 봉사가 아닌 자기 투자

1년 돌아보니 멘토링이 제 커리어에 남긴 흔적이 꽤 구체적입니다. 사내 기술 발표 4회, 외부 컨퍼런스 발표 1회, 인사 평가의 리더십 항목 점수 상승. 가르치려고 정리한 자료가 그대로 발표 슬라이드가 됐던 게 컸어요.

 

물론 모든 멘토링이 잘 풀리지는 않습니다. 조직적 보상 없이 시니어에게 멘토링만 얹으면 marginal mentoring, 그러니까 형식적 피드백만 던지고 끝나는 번아웃 상태로 가기 쉽다는 연구들이 있어요. 멘토링을 "착한 사람의 봉사"로 자리잡게 만든 조직에선 시니어가 빠르게 갈려나갑니다.

 

그래서 저는 멘토링 시간을 일정에 명시적으로 박아둡니다. 매주 금요일 오전 2시간을 멘토링 슬롯으로 잡고, 그 시간엔 다른 회의를 받지 않아요. 이게 멘티를 위한 시간이라기보다 제 사고 과정을 디버깅하는 시간이라고 생각하면 우선순위 잡기가 쉬워지거든요.

 

주니어 멘토링 1년이 시니어 개발자에게 남긴 흔적

가르침은 후배의 빈 곳을 채우는 작업이 아니라 제 빈 곳을 발견하는 작업이었습니다. 시니어 개발자한테 진짜로 필요한 능력은 코드를 빨리 짜는 게 아니라 막혔을 때 멈춰서 설명할 줄 아는 사고의 해상도라는 걸, 멘티 옆자리에서 1년 앉아보고서야 알았어요.

 

올해 하반기에 신입 한 명이 더 들어옵니다. 그때 첫 PR 리뷰 자리에 "이렇게 고치세요" 대신 "이게 실패할 3가지 경우는요?"가 먼저 나오면, 1년 전 38%였던 그 침묵이 제 안에서 다른 모양으로 남은 흔적입니다.