「여기, 왜 이렇게 작성했나요?」

리뷰에서 예전부터 자주 들어왔던 질문이다. 대답하지 못하는 부하 직원이 있다. 동작하는 코드는 작성할 수 있다. 하지만 왜 그런 설계를 했는지, 그 자리에서 설명하지 못한다.

「이해할 때까지 생각해서 오라」고 되돌려준다. 이것을 수년째 해왔다.

그리고 지금, AI의 등장으로 이 문제가 한층 더 악화되고 있다.

AI 시대에 「설명할 수 없는 제출」이 늘었다

이전에는 자신이 작성한 코드라면, 서툴더라도 본인 나름의 이유가 있었다. 「일단 이렇게 작성했다」 하더라도 생각한 흔적은 있다.

AI가 작성하게 되면서 그 점이 변했다. AI의 출력을 그대로 제출하는 케이스가 늘었다. 동작한다. 테스트도 통과한다. 하지만 「왜 이 구현인가」라고 물으면 대답하지 못한다. 본인이 작성하지 않았으니 당연하다.

이것이 까다로운 이유는 표면상으로는 문제가 없어 보인다는 점이다. 코드는 깔끔하고 동작한다. 리뷰에서 처음으로 「아, 이거 본인이 이해하지 못하고 있구나」라고 깨닫게 된다.

무엇이 문제인가

설명할 수 없는 제출에는 두 가지 실질적인 해악이 있다.

버그의 온상이 된다

이해하지 못한 채 머지(Merge)된 코드는 나중에 아무도 원인을 추적할 수 없다. 무슨 일이 생겼을 때 「여기, 어떤 의도로 작성했었지?」라는 질문에 아무도 대답할 수 없다. AI가 쓰고 사람이 이해하지 못한 코드는 블랙박스(Black box) 상태로 운영 환경에 쌓여간다.

부하 직원이 성장하지 않는다

더 근본적인 것은 이것이다. AI에게 통째로 맡겨버리면 생각하는 힘이 자라지 않는다. 「설계를 판단한다」, 「트레이드오프 (Trade-off)를 선택한다」라는 엔지니어의 핵심 (Core) 부분이 단련되지 않은 채, 표면적인 아웃풋(Output)만 계속해서 나온다.

편리한 도구를 가진 결과로 성장이 멈춘다. 이는 본인에게도 조직에게도 손실이다.

lint로는 잡아낼 수 없다

여기서 곤란한 점은, 「이해하고 있는가」는 기계적으로 검출할 수 없다는 것이다.

타입 에러는 lint로 잡을 수 있다. 규약 위반도 정적 분석으로 걸러낼 수 있다. 하지만 「본인이 이 코드를 이해하고 있는가」는 코드만 봐서는 알 수 없다. 이해하고 있든 아니든 나오는 코드는 같기 때문이다.

오랫동안 이것은 「리뷰에서 사람이 구두로 확인할 수밖에 없다」고 생각했다. 자신이 병목(Bottleneck)이 되면서 한 명 한 명에게 「왜 이렇게 했나?」라고 물으며 돌아다닐 수밖에 없다고.

발상의 전환: AI에게 설명시키지 말고, 질문하게 하라

시스템화의 힌트는 자신이 구두로 했던 일 —— 「의도를 묻는 것」 —— 그 자체에 있었다.

보통 AI를 사용하면 「이 코드를 설명해줘」라고 부탁한다. 하지만 그렇게 하면 AI가 유창한 설명을 생성해버리기 때문에, 본인이 이해하고 있는지는 여전히 알 수 없다. 오히려 「AI가 작성한 설명을 그대로 읽는」 이중의 떠넘기기가 된다.

반대다. AI에게 코드를 설명하게 하는 것이 아니라, 질문만을 생성하게 한다.

「이 변경 사항에 대해 리뷰어가 물어볼 법한 '왜'를 10개 생성해라. 코드 해설은 일절 하지 마라. 질문만 내라.」

이렇게 하면 제출자는 자신의 차이점(Diff)에 대한 날카로운 질문 리스트를 받게 된다. 그리고 대답할 수 없는 질문 = 이해하지 못한 부분이 스스로 가시화된다.

이를 제출 전의 셀프 게이트(Self-gate)로 삼는다. 대답할 수 없다면 제출하지 마라.

/explain-check ── 질문만을 생성하는 커맨드

Claude Code의 커스텀 커맨드로 구현한다면 다음과 같다.

---
description: 자신의 PR에 리뷰어가 물어볼 「왜」를 생성. 대답할 수 없으면 제출하지 마라
allowed-tools: Read, Grep, Glob, Bash
...

포인트는 「코드 해설을 하지 마라, 질문만 내라」라는 제약이다. 이것이 없으면 AI는 친절하게 해설해버려 게이트로서 기능하지 않게 된다. 질문에 철저하게 집중하게 함으로써 제출자의 이해도를 드러내는 도구가 된다.

PR 템플릿과 조합하기

셀프 게이트를 「했는지 여부」도 시스템에 포함시킨다. 풀 리퀘스트(Pull Request) 템플릿에 신고란을 만든다.

## 무엇을・왜 (자신의 언어로. AI 생성 문장 그대로는 불가)
- 해결하는 과제 / 왜 이 방침인가 (검토한 대체안과 기각 이유)
## AI 지원 신고
...

「자신의 언어로」, 「AI 생성 문장 그대로는 불가」라고 명기한다. 체크박스를 통해 본인에게 확인 의사 표시를 하게 한다.

목적은 「단속」이 아니다

이 부분이 가장 중요하다.

이 시스템은 AI 이용을 금지하거나 감시하는 것이 아니다. 만약 「AI를 쓰지 마라」고 단속하면 사람들은 AI를 숨겨서 사용한다. 들키지 않게 사용하고, 결과적으로 품질이 더 떨어지게 된다. 최악의 패턴이다.

목표는 반대다. 「AI는 써라. 단, 이해한 상태에서 내라」를 시스템으로 담보하는 것이다.

AI는 강력한 도구다. 사용해야 한다. 금지하는 것은 시대에 역행하는 일이다. 하지만 이해하지 못한 채 출력을 쏟아내는 것은 별개의 문제다. 「사용하기」와 「이해하기」를 양립시킨다. 그 경계선을 사람의 선의나 근성이 아닌, 시스템(仕組み)으로 긋는다.

/explain-check 는 그 경계선을 긋는 장치다. AI를 사용했는지 여부는 묻지 않는다. 오직 「설명할 수 있는가」만을 묻는다.

구두로 하던 일을 시스템으로 승격시키기

돌이켜보면, 내가 줄곧 구두로 해왔던 "왜 이렇게 했지?", "대답하지 못하겠다면 다시 생각해 와라"를, 제출 전에 본인이 스스로 할 수 있는 형태로 만든 것뿐이다.

차이점은 내가 병목(Bottleneck)이 되지 않는다는 것이다. 한 명 한 명에게 물어보러 다니지 않아도, 제출자가 스스로 게이트(Gate)를 통과한다. 나는 정말로 필요한 설계 판단 리뷰에 집중할 수 있다.

"목표는 내가 한가해지는 것"이라고 줄곧 말해왔다. 이해도 확인조차 시스템에 맡길 수 있다면, 또 하나 내 손을 떠나보낼 수 있다.

이것은 아직 설계 단계다. 실제로 팀에 전개하는 것은 이제부터다. 하지만 AI를 그대로 내놓는 문제에 대해, 「금지」도 「포기」도 아닌 제3의 길이 보인 것 같다. AI에게 설명하게 하는 것이 아니라, 질문하게 한다. 답은 본인 안에만 있다.

다른 기사도 읽기 → taka-techblog.com

X에서도 발신 중 → @_taka_tech

Discussion