후배가 생겼는데 어떻게 해야 할지 모르는 개발자에게

by 그릿 | GROWTH_ESSAY | 2026-07-13

2년 차가 되고 처음으로 후배가 생겼을 때, 가장 많이 하는 말이 있습니다.

"저도 아직 잘 모르는 게 많은데요."

맞는 말입니다. 그리고 그 말 뒤에 뭔가를 숨기고 있습니다.

선배는 '다 아는 사람'이 아닙니다

200명 넘게 멘토링을 하면서 알게 된 게 있습니다. 선배 역할을 맡고 나서 가장 먼저 무너지는 개발자들은, 선배를 '정답을 주는 사람'으로 정의한 사람들입니다.

2년 반 만에 후배를 처음 받은 한 개발자는, 후배가 "이 코드 왜 이렇게 짰어요?" 물을 때마다 당황했다고 했습니다. 이유를 설명하려다 보면 자신이 관성으로 코드를 짰다는 걸 들킬 것 같아서요. 그래서 후배 질문을 슬슬 피하기 시작했습니다.

선배가 다 알아야 한다는 생각이, 결국 후배를 고립시킵니다.

후배가 묻는 건 '정답'이 아닙니다

처음 들어온 개발자가 가장 힘든 건 기술이 아닙니다. 맥락이 없는 겁니다.

왜 이 라이브러리를 쓰는지, 왜 이 폴더 구조인지, 왜 이 PR은 이런 방식으로 리뷰하는지. 이걸 물으면 대부분의 선배는 "원래 그렇게 해요"라고 답합니다.

그 한마디가 후배를 두 번 막습니다. 다음 질문도 못 하게 되고, 스스로 판단하는 기준도 생기지 않습니다.

후배가 원하는 건 모범 답안이 아닙니다. 어떤 기준으로 이 판단을 했는지, 선배의 사고 과정 자체를 보고 싶은 겁니다.

'모른다'고 말하는 게 신뢰를 만듭니다

저는 멘토링에서 이렇게 말합니다.

"나도 이 부분은 정확히 몰라요. 같이 찾아봐요."

신기하게도 이 한마디가 멘티를 더 열리게 합니다. 모른다고 인정하는 선배는 신뢰를 잃지 않습니다. 오히려 멘티가 "저도 모를 때 말해도 되겠구나"를 배웁니다.

선배가 된다는 건 더 많이 아는 게 아닙니다. 모르는 걸 어떻게 다루는지 보여주는 일입니다.

첫 달에 한 가지만 해도 됩니다

후배가 들어온 첫 달, 해줘야 할 것들을 리스트로 만드는 선배가 있습니다. 온보딩 문서, 코드 리뷰 가이드, 팀 규칙 설명. 다 좋습니다. 근데 한 가지가 빠집니다.

이 사람이 지금 뭘 모르는지, 내가 모른다는 것.

첫 한 달은 가르치려고 하지 말고, 관찰하세요. 어디서 막히는지, 질문을 못 하는 이유가 뭔지, 어떤 방식으로 배우는 사람인지.

그 다음에 뭘 해줄지가 보입니다.

선배가 되는 건 어느 날 갑자기 완성되지 않습니다. 후배를 보면서 자신이 얼마나 관성으로 일했는지를 알게 되는 과정, 그게 선배 역할입니다.