코드리뷰 에서 시니어 가 코멘트 를 남긴다. “이거 Optional 말고 nullable 로 바꿔 주세요.”

여기서 주니어 앞 에 두 갈래 길 이 있다. 하나 는 “넵 수정 하겠습니다”, 다른 하나 는 “왜요?” — 그리고 이 둘 은 6개월 뒤 완전히 다른 결과 를 만든다. 이 글 은 “왜요?” 가 왜 무례 가 아니라 가장 정중한 요청 인지 에 대한 고찰 이다.


1. 흔한 반사 — “넵 수정 하겠습니다”

대부분 은 첫 번째 길 을 고른다. 시키는 대로 바꾸면 리뷰 는 빨리 닫힌다. 안전 해 보인다. 그런데 그 안전 은 지금 만의 안전 이다.

침묵 순응 시나리오 — "넵 수정하겠습니다" 는 리뷰는 빨리 닫히지만 학습은 0, 6개월 뒤 신입의 같은 질문에 답하지 못하고 "시니어가 그렇게 하라고 했어요"가 입버릇이 된다

  • 빨리 마무리 된다 — 즉시 받아들임.
  • 하지만 다음 에 또 같은 자리 에서 같은 코멘트 를 받는다.
  • 6개월 뒤 신입 이 들어와 “Optional 이 왜 안 되죠?” 하고 물으면 — 답 을 못 한다.
  • 결국 “시니어 가 그렇게 하라고 했어요” 가 입버릇 이 된다.

마무리 는 빠르지만, 학습 은 0 이다. 코드 는 바뀌었는데 이유 는 아무 데도 안 박혔다.

시키는 대로 고친 사람 은 “무엇 을 고쳤는지” 는 알아도 “왜 그래야 했는지” 는 끝내 모른다. 그리고 이유 를 모르는 지식 은 다음 번 에 재현 되지 않는다.


2. 다른 답 — “왜요?” (정중 하게, 살짝 더 길게)

두 번째 길 은 묻는 것 이다. 단, 시비 로 들리지 않게 — 의도 를 궁금해 하는 형태 로.

정중한 "왜요?" 시나리오 — 주니어가 이유를 묻자 시니어가 외부 라이브러리 직렬화 호환 때문임을 설명하고 위키에 정리하겠다고 답함. 결과로 팀 위키 페이지가 생기고 6개월 뒤 신입은 같은 질문을 하지 않는다

주니어: “수정 전 에 짧게 여쭤봐도 될까요? Optional 이 의도 를 더 명확 하게 전달 한다고 배웠는데 — nullable 로 바꾸시는 이유 가 궁금 합니다. 다른 모듈 은 어떤지 보고 맞추는 게 나을까요?”

시니어(15분 뒤): “좋은 질문 이에요. 이 모듈 은 외부 라이브러리 와 직렬화 호환 을 위해 nullable 을 유지 하고 있어요. Optional 은 도메인 객체 엔 권장 이고요. — 정리 해서 위키 에 올릴게요.”

결과 가 완전히 달라진다.

  • 팀 위키 에 1 페이지 가 생긴다.
  • 6개월 뒤 신입 은 같은 질문 을 안 한다 — 이미 문서 가 있으니까.
  • 그리고 그 주니어 는 “왜요 를 안전 하게 묻는 사람” 으로 인식 된다.

같은 5초 짜리 코멘트 가, 한쪽 에선 침묵 속 에 사라지고 다른 쪽 에선 팀 의 자산 이 됐다. 차이 는 딱 하나 — 물었느냐.


3. 재해석 — “왜요?” 는 무시 가 아니다

여기서 오해 를 풀어야 한다. 많은 주니어 가 “왜요?” 를 삼키는 이유 는, 그게 시니어 를 의심 하는 말 처럼 느껴져서다. 하지만 방향 이 반대다.

배운 것 — "왜요?"는 시니어를 무시하는 말이 아니라, 시니어의 머릿속을 공유해 달라는 가장 정중한 요청이다

“왜요?” 는 시니어 를 무시하는 말 이 아닙니다. 시니어 의 머릿속 을 공유 해 달라는 가장 정중한 요청 입니다.

시니어 의 코멘트 한 줄 뒤 에는 대개 수년 치 의 맥락 이 압축 돼 있다 — 예전 에 터진 장애, 외부 라이브러리 의 함정, 도메인 의 규칙. “왜요?” 는 그 압축 파일 을 풀어 달라 는 요청 이다. 무시 가 아니라 존중 이다. “당신 이 그렇게 판단 한 데는 이유 가 있을 텐데, 그 이유 를 저도 갖고 싶습니다” 라는 뜻 이니까.


4. 왜 이게 팀 을 바꾸는가 — 암묵지 가 형식지 로

이 작은 습관 이 중요한 건, 조직 의 지식 대부분 이 시니어 의 머릿속 에만 있는 암묵지(tacit knowledge) 이기 때문이다.

시니어 머릿속(암묵지)  ──"왜요?"──▶  대화  ──"위키에 올릴게요"──▶  팀 문서(형식지)
        │                                                              │
        └──────────  묻지 않으면 여기서 영원히 갇힌다  ◀──────────────┘

“넵 수정 하겠습니다” 는 이 파이프 를 막는다. 지식 은 시니어 가 퇴사 하는 날 같이 나간다. “왜요?” 는 이 파이프 를 연다. 한 번 의 질문 이 한 번 의 대화 를 낳고, 그 대화 가 영구 문서 로 굳는다. 개인 의 궁금증 이 팀 의 자산 으로 환전 되는 순간 이다.

덤 으로, 이렇게 묻는 문화 는 심리적 안전 을 만든다. 주니어 가 안전 하게 물을 수 있는 팀 에서는, 신입 도 안전 하게 묻는다. 그렇게 “묻는 사람” 이 늘어날수록 암묵지 는 계속 형식지 로 흘러나온다.


5. 그래서 — “왜요?” 를 잘 묻는 법

물론 “왜요?” 를 무뚝뚝 하게 던지면 시비 가 된다. 위 시나리오 가 통한 건 형식 때문이다. 정중한 “왜요?” 에는 네 가지 가 들어 있다:

  1. 허락 을 먼저 — “짧게 여쭤봐도 될까요?” (상대 의 시간 을 존중)
  2. 내 근거 를 밝히고 — “Optional 이 의도 를 더 명확 히 한다고 배웠는데” (반대 가 아니라 배움 의 지점 임을 드러냄)
  3. 의도 를 물은 뒤 — “바꾸시는 이유 가 궁금 합니다” (사람 이 아니라 결정 에 대한 질문)
  4. 협업 으로 닫는다 — “다른 모듈 은 어떤지 보고 맞추는 게 나을까요?” (지적 이 아니라 정렬 이 목적)

이 네 가지 가 갖춰지면, “왜요?” 는 도전 이 아니라 초대 가 된다. 시니어 입장 에서도 — 무시 당한 게 아니라 가르칠 기회 를 받은 것 이니, 기꺼이 15분 을 쓴다.


6. 마무리

두 답 은 같은 5초 에서 갈라진다. “넵” 은 코드 를 고치고, “왜요?”사람 과 팀 을 고친다.

시키는 대로 하는 주니어 는 오늘 의 리뷰 를 닫는다. 이유 를 묻는 주니어 는 6개월 뒤 의 신입 까지 구한다. 전자 는 지식 을 소비 하고, 후자 는 지식 을 퍼 나른다.

“왜요?” 는 항명 이 아니라 존경 의 다른 이름 이다. — 당신 의 판단 을, 나도 이해 하고 싶다는.

가장 빨리 배우는 사람 은 가장 정중 하게 묻는 사람 이다.


관련: AX 시대 의 문제정의 능력 · 실무 AI 사용법 8 원칙