멘토링 해보니까 나도 배우더라

멘토를 맡게 됐다

4년 차 때 신입 개발자의 멘토를 맡았다. "내가 남을 가르칠 수준인가?"가 첫 반응이었다. 2년 전에 rebase를 잘못해서 팀 브랜치를 날린 사람이 멘토라니. 근데 팀에서 "네가 해봐"라고 했고, 거절할 명분이 없었다.

첫 1:1 미팅에서 멘티가 "JavaScript에서 호이스팅이 뭔가요?"라고 물었다. 나는 "음... var는 올라가고..." 하다가 멈췄다. 써본 적은 많은데 정확하게 설명하려니까 말이 안 나왔다.

(그 자리에서 "잠깐, 정리해서 내일 알려줄게"라고 했다. 솔직히 창피했다.)

가르치려면 3배는 알아야 한다

멘티 질문에 답하려면 내가 정확히 이해해야 했다. "대충 아는" 상태로는 설명이 불가능하다. 그래서 매주 멘티가 물어볼 만한 주제를 미리 공부하기 시작했다. 클로저, 프로토타입 체인, 이벤트 루프, async/await의 동작 원리.

3년 동안 실무에서 잘 썼는데, 원리를 설명하라고 하면 막히는 것들이 수두룩했다. Promise.all과 Promise.allSettled의 차이? 쓸 줄은 아는데 왜 이렇게 동작하는지 내부 로직을 설명하지 못했다. 멘토링 때문에 이런 것들을 하나하나 파게 됐다.

질문의 힘

멘티가 "왜요?"라고 물을 때마다 나도 같이 생각하게 됐다. "우리 팀은 왜 Redux 대신 Zustand를 쓰나요?" — 사실 나도 이유를 제대로 생각해본 적이 없었다. 선임이 결정한 걸 따라갔을 뿐이었다. 멘티 질문 덕에 기술 선택의 근거를 다시 정리하게 됐다.

"왜 이 컴포넌트를 이렇게 분리했나요?" 같은 질문도 좋았다. 습관적으로 하던 것들의 이유를 돌아보게 해줬다.

실수: 답을 너무 빨리 줬다

처음엔 멘티가 막히면 바로 답을 알려줬다. 기다리는 게 힘들었다. 15분 동안 삽질하는 걸 보면 "여기 이렇게 하면 돼"라고 말하고 싶은 충동이 계속 올라왔다. 근데 이렇게 하면 멘티가 스스로 문제를 해결하는 경험을 못 한다.

3개월쯤 되니까 답을 주는 대신 질문을 하기 시작했다. "에러 메시지가 뭐라고 나와?", "어디까지 확인해봤어?", "비슷한 코드가 다른 파일에 있는데, 찾아볼 수 있어?" 이렇게 하니까 멘티가 스스로 답을 찾는 비율이 확 올라갔다.

1년 뒤 달라진 것

멘티는 6개월 차에 혼자서 기능 개발을 할 수 있게 됐다. 1년 차에는 코드 리뷰에서 좋은 피드백을 주는 수준이 됐다. 성장 속도에 놀랐다.

근데 놀라운 건 내 성장이었다. 멘토링 전보다 기초가 훨씬 탄탄해졌다. 설명하는 능력이 늘면서 기술 문서 작성이나 팀 발표도 편해졌다. 코드 리뷰할 때도 "이건 이래서 안 좋다"가 아니라 "이렇게 바꾸면 이런 이유로 더 좋다"고 설명할 수 있게 됐다.

멘토링은 시간 투자가 아니라 학습 투자

매주 1:1에 1시간, 질문 대응에 30분, 코드 리뷰에 1시간. 합치면 주 2~3시간을 멘토링에 쓴다. 처음엔 "이 시간에 코드를 더 짤 수 있는데"라고 생각했다. 지금은 이 시간이 나한테도 가장 효율적인 학습 시간이라는 걸 안다.

사실은 "가르치는 것이 최고의 학습"이라는 말이 클리셰처럼 들리지만, 직접 해보니까 진짜다. 근데 멘토링이 잘 되려면 멘티와의 관계가 중요하고, 이건 사람마다 케미가 있어서 항상 좋은 결과가 나오는 건 아니다.