"이거 왜 이렇게 동작하는 건가요?"

신입 한 분이 내 옆자리로 배정됐다. 온보딩 가이드 역할이 나한테 떨어졌다. 입사한 지 1년 반밖에 안 됐는데 후배라니. 팀 리드가 "너도 이제 좀 됐으니까" 하고 자연스럽게 넘겼는데, 속으로는 당황스러웠다. 나도 아직 모르는 게 많은데.

첫날 개발 환경 세팅을 도와주면서 시작했다. Node 버전, 패키지 매니저, 에디터 설정. 여기까지는 괜찮았다. 문제는 코드베이스 설명이었다. "이 프로젝트 구조가 어떻게 되어 있냐면..." 하고 말을 시작했는데, 내 설명이 횡설수설이었다. 머릿속에서는 다 아는 건데 입으로 설명하려니까 어디서부터 시작해야 할지 모르겠더라.

아는 것과 설명하는 건 다르다#

후배가 두 번째 주에 질문을 했다. "useEffect에서 cleanup 함수가 왜 필요한 거예요?" 나는 매일 useEffect를 쓴다. cleanup도 당연히 쓴다. 근데 "왜"를 설명하려니까 막혔다.

"어... 컴포넌트가 언마운트될 때 정리를 해줘야 하니까." "정리를 안 하면 어떻게 되는데요?" "메모리 릭이 날 수 있어." "어떤 경우에요?"

순간 구체적인 예시가 바로 안 떠올랐다. 대충 알고 있었던 거다. setInterval을 걸어놓고 정리 안 하면 컴포넌트가 사라져도 계속 돌아간다, 이벤트 리스너를 등록하고 해제 안 하면 중복 실행된다, 이런 얘기를 하려면 좀 더 정확하게 알고 있어야 했다. 그날 퇴근하고 React 공식 문서의 useEffect 섹션을 처음부터 다시 읽었다. 1년 반 동안 쓰면서 한 번도 안 돌아봤던 내용이 있더라.

이런 일이 반복됐다. 후배가 질문할 때마다 내가 "감으로 알고 있던 것"과 "정확하게 아는 것"의 차이를 직면하게 됐다. TypeScript의 interface와 type의 차이, Next.js에서 서버 컴포넌트와 클라이언트 컴포넌트의 경계, CSS의 specificity 계산 방법. 전부 매일 쓰면서도 막상 설명하려면 애매한 것들이었다.

코드 리뷰가 달라지다#

후배의 PR을 리뷰하게 됐다. 처음에는 "어디를 어떻게 봐야 하지?"부터 고민이었다.

첫 번째 PR을 봤는데, 동작은 하지만 구조가 좀 아쉬웠다. 하나의 컴포넌트에 API 호출, 상태 관리, 렌더링이 전부 들어가 있었다. 나도 처음에 그렇게 했으니까 이해는 됐다. 근데 이걸 어떻게 말해야 할지 고민이 됐다. "이거 분리해야 해"라고만 하면 감이 안 올 것 같았다.

고민 끝에 이렇게 코멘트를 달았다. "이 컴포넌트가 하는 일이 세 가지인데, 나중에 로직 수정할 때 어디를 고쳐야 할지 찾기 어려울 수 있어요. API 호출하는 부분을 커스텀 훅으로 빼면 컴포넌트는 렌더링에만 집중할 수 있을 것 같은데 어떻게 생각해요?" 지시가 아니라 제안으로. 근데 이게 의외로 어렵다. "~하세요"와 "~하면 어떨까요?"의 차이가 크다는 걸 이때 알았다.

코드 리뷰를 하면서 나도 많이 배웠다. 다른 사람의 코드를 읽고 "왜 이렇게 했을까"를 생각하고, 더 나은 방법을 찾아서 설명하는 과정에서 내 코드도 나아졌다. 후배 PR에서 발견한 패턴을 내 코드에서도 하고 있었다는 걸 깨달은 적이 한두 번이 아니다.

질문을 대하는 자세#

처음에는 후배가 질문할 때마다 바로 답을 알려줬다. "아 그거? 이렇게 하면 돼." 빠르게 해결되니까 효율적이라고 생각했는데, 2주쯤 지나니까 같은 유형의 질문이 반복되더라.

시니어한테 조언을 구했더니 이렇게 말하더라. "답을 바로 알려주면 그 순간은 해결되지만, 답을 찾는 방법을 가르쳐주면 다음번에는 혼자 해결해." 그 뒤로는 질문을 받으면 일단 "어디까지 찾아봤어요?"를 먼저 물어봤다. 그리고 "이 키워드로 검색해보면 나올 거예요" 또는 "이 공식 문서 이 섹션을 보면 돼요" 같은 식으로 방향을 잡아줬다.

물론 이게 항상 맞는 건 아니다. 긴급한 버그가 터졌는데 "먼저 찾아보세요"는 말도 안 된다. 상황에 따라 바로 알려줘야 할 때와 스스로 찾게 해야 할 때를 구분하는 게 멘토링의 어려운 부분이다.

한번은 후배가 3시간 동안 혼자 끙끙대고 있었는데 나한테 안 물어보더라. 나중에 물어봤더니 "자꾸 물어보면 귀찮으실까 봐요"라고. 그 말을 듣고 미안해졌다. 내가 "먼저 찾아봐" 모드로만 대응하니까 질문 자체를 부담스러워하게 만든 거다. 그날 커피를 사주면서 말했다. "30분 이상 막히면 바로 물어보세요. 3시간 쓰는 게 더 비효율적이에요."

기대치 조절하기#

가장 어려웠던 건 내 기대치를 조절하는 거였다. 한 번 설명했으면 이해했을 거라고 생각하는데 다음에 또 비슷한 실수를 한다. 한 번 리뷰에서 지적한 부분이 다음 PR에서 또 나온다.

처음에는 좀 답답했다. "이거 저번에 얘기했는데?" 라는 말이 목까지 올라온 적이 있다. 근데 돌이켜보면 나도 그랬다. 시니어한테 같은 피드백을 두 번 세 번 받은 적이 있었다. 한 번 듣는다고 바로 체화되는 건 아니다. 비슷한 상황을 여러 번 겪으면서 서서히 몸에 배는 거다.

그래서 마음을 바꿨다. "같은 피드백을 반복하는 것도 멘토링의 일부"라고. 두 번째로 같은 지적을 할 때는 첫 번째와 다른 각도로 설명해보려고 한다. "저번에는 이렇게 말했는데, 다시 정리하면 이런 이유 때문이에요." 설명을 바꾸면 이해도가 달라질 때가 있다.

후배가 성장하는 걸 보는 느낌#

두 달 정도 지나니까 변화가 보이기 시작했다. PR 크기가 작아졌다. 변수 네이밍이 나아졌다. 질문의 수준이 달라졌다. "이거 어떻게 해요?"에서 "이렇게 하려고 하는데, 이 방법이 맞을까요?"로.

어느 날 후배가 올린 PR을 봤는데, 코멘트 없이 approve를 눌렀다. 진짜 고칠 게 없었다. 깔끔했다. 내가 괜히 뿌듯해했다. 내가 한 건 별로 없는데.

가르치면서 배운다는 말이 진부하게 들렸는데, 직접 겪어보니 정말이었다. 후배 때문에 기초를 다시 공부하게 됐고, 설명하는 능력이 늘었고, 코드 리뷰를 보는 눈이 달라졌다. 무엇보다 "나도 아직 모르는 게 많다"는 걸 인정하게 된 게 가장 큰 성장이었다.

페어 프로그래밍의 효과#

한번 페어 프로그래밍을 해본 적이 있다. 후배가 복잡한 폼 유효성 검사를 구현해야 했는데, 혼자 하기에는 좀 까다로운 케이스였다. "같이 해볼까요?" 하고 화면 공유를 켰다.

나는 네비게이터 역할을 맡고 후배가 드라이버를 했다. 내가 "여기서 먼저 유효성 규칙을 정의하고..."라고 방향을 잡으면, 후배가 직접 코드를 쳤다. 중간에 후배가 "이 부분은 이렇게 하면 어떨까요?"라고 아이디어를 내기도 했다. 2시간 만에 끝났는데, 혼자 했으면 하루 종일 걸렸을 작업이었다.

이때 느낀 건, 가르치는 게 항상 "설명"의 형태일 필요는 없다는 거다. 같이 코드를 짜면서 내 사고 과정을 보여주는 것도 가르침이다. "여기서 나는 이런 순서로 생각했어요"라는 게 교과서보다 더 효과적인 순간이 있다.

나도 아직 배우는 중이라는 것#

멘토링을 하면서 가장 위험한 태도는 "내가 다 알고 있다"는 착각이다.

후배한테 뭔가를 설명하다가 내가 틀린 적이 있다. CSS Grid에서 fr 단위 계산 방식을 잘못 설명했는데, 후배가 "근데 이렇게 해보니까 결과가 다른데요?"라고 했다. 확인해보니 내가 잘못 알고 있었다. 순간 민망했지만 "아 맞다, 내가 잘못 말했다. 고마워"라고 바로 정정했다.

이 순간이 오히려 관계에 좋은 영향을 준 것 같다. 멘토도 틀릴 수 있다는 걸 보여주면 후배도 편해진다. "이 사람도 모르는 게 있구나, 그럼 나도 모르는 게 있어도 괜찮겠다"라는 안도감. 완벽한 멘토보다 솔직한 멘토가 더 좋은 멘토라고 생각한다.

다음에 또 온보딩 담당을 맡게 되면 좀 더 잘할 수 있을까? 잘 모르겠다. 사람마다 다르니까 이번에 통한 방법이 다음에도 통할지는 미지수다. 다만 한 가지 확실한 건, 도망치지 않을 거라는 것. 처음에 느꼈던 "나는 아직 준비 안 됐다"는 감정은, 실제로 해보기 전까지는 절대 사라지지 않는다.