AI 가 만든 코드는 동작해도 설명할 수 없으면 채택하지 않는다

AI 코딩 도구는 코드를 쓰는 비용을 크게 낮춘다. 대신 그 코드를 읽고, 이해하고, 책임지는 비용은 줄지 않고 오히려 늘 수 있다. 이 글은 CI 가 통과하고 로컬에서 동작하는 코드를 받아들일지 판단할 때 쓰는 기준을 정리한다. 거절 신호 다섯 가지와 리뷰 자리에서 던지는 질문 다섯 가지, 자동 검증과 사람 판단의 역할 분담을 다룬다.

이 글은 Vinicius Brasil 의 When I reject AI code even if it works(2026-06-20)를 요약하고, 하네스 설계 관점에서 덧붙인 것이다.

병목이 작성에서 판단으로 옮겨 간다

기능 하나를 구현하는 시간은 AI 도구 덕분에 짧아졌다. 그러면 남는 시간은 변경을 이해하고, 팀원에게 설명하고, 나중에 고장 났을 때 책임지는 데 쓰인다. Brasil 은 AI 생성 코드의 첫 번째 비용이 작성이 아니라 리뷰라고 주장한다.

작업을 작은 단계로 나누고 plan mode 를 써도 이 비용은 사라지지 않는다. 스스로 충분히 생각하지 않은 변경을 리뷰하면 인지 부하가 커지기 때문이다. 같은 모델을 쓰더라도 결과의 차이는 모델보다 화면 뒤에 앉은 사람의 이해도에서 난다고 그는 말한다. 문제를 오래 소화한 사람은 에이전트가 내놓은 방향에 끌려가지 않고, 더 나은 방향으로 에이전트를 이끈다.

여기서 "동작한다" 와 "좋은 해결책이다" 를 분리하는 관점이 나온다. CI 가 통과하고 로컬에서 돌아가는 코드도 부적절하거나, 확장하기 어렵거나, 추론 비용이 큰 해결책일 수 있다.

거절 신호

Brasil 은 코드가 동작해도 다음 경우에는 거절한다고 정리한다.

• 접근 방식을 자기 언어로 설명할 수 없다.
• diff 가 실제 문제보다 크다.
• 필요성이 증명되기 전에 새 추상화를 도입한다.
• 로컬에서는 동작하지만 시스템을 더 이해하기 어렵게 만든다.
• 자신의 이해보다 AI 산출물을 더 신뢰하게 된다.

다섯 번째 신호가 가장 눈에 띄지 않는다. 앞의 네 가지는 diff 를 보면 드러나지만, 마지막은 리뷰어 자신의 상태를 관찰해야 한다. "AI 가 만들었으니 맞겠지" 라는 생각이 들기 시작하면 검토를 멈추고 있다는 신호다.

리뷰 자리에서 던지는 질문

AI 가 만든 변경을 리뷰할 때는 "무엇이 바뀌었는가" 보다 먼저 "왜 이 접근이 맞는가" 를 설명해 본다. 설명이 되지 않으면 코드를 더 읽거나, 변경을 줄이거나, 작업을 다시 계획한다.

설명을 시도하는 데 쓰는 질문은 다섯 가지로 압축된다.

이 질문은 "추론 비용을 낮추거나 최소한 늘리지 않는다" 는 하나의 기준에서 나온다. 시스템을 이해하는 데 드는 비용이 늘어난다면 기능이 늘어도 채택하지 않는다.

자동 검증은 필요조건이다

CI, 테스트, 자동 리뷰 봇의 통과는 채택 조건의 일부일 뿐이다. 이들은 코드가 정해진 기준을 만족하는지를 확인하지만, 그 기준이 이 문제에 맞는 기준인지는 말해 주지 않는다.

둘의 역할은 다음과 같이 나뉜다.

자동 리뷰 워크플로를 만드는 방법은 GitHub Actions 로 PR 마다 AI 코드 리뷰를 자동으로 돌리는 워크플로 설계에 있다. 검증을 이진 검사, 정량 지표, 정성 루브릭으로 나누는 방법은 AI 가 만든 결과는 전부 읽지 않고 검증 레이어로 신뢰한다에서 다룬다.

두 글은 "어떻게 자동으로 검증할까" 를 다루고, 이 글은 그 뒤에 사람이 남는 이유를 다룬다. 검증 레이어가 아무리 잘 만들어져 있어도, 어떤 검증을 통과했기에 이 코드를 믿는지는 사람이 설명할 수 있어야 한다. 설명할 수 없다면 앞의 글에서 말하는 인지부채가 쌓인다.

정리