AI가 코드를 쓰고 AI가 리뷰한다면, 개발자는 무엇을 검증해야 할까요?

AI 요약

AI가 기능을 구현하고 테스트를 작성한 뒤 pull request를 열어 리뷰하고, 리뷰 지적까지 수정하는 개발 흐름이 나타나고 있습니다. GitHub에 따르면 Copilot 코드 리뷰는 GitHub 전체 코드 리뷰의 5분의 1 이상을 차지합니다. 저자는 이 과정이 효율적일 수 있지만, AI가 작성한 코드를 AI가 리뷰하는 일은 독립적인 검증과 다르다고 지적합니다.

일관성과 정확성은 다릅니다

요구사항을 잘못 이해하면 그 오해가 구현과 테스트, 리뷰에 그대로 이어질 수 있습니다. 예를 들어 환불 조건이 ‘결제가 성공적으로 승인된 경우’인데 AI가 ‘결제 기록이 존재하는 경우’로 해석하면, 구현도 테스트도 리뷰도 모두 그 잘못된 해석에 맞춰질 수 있습니다. 코드 구조가 깔끔하고 테스트가 통과하며 리뷰가 긍정적이어도, 요구사항을 잘못 이해한 사실은 바뀌지 않습니다. 여러 단계가 서로 같은 판단을 내렸다는 사실은 독립적으로 옳음을 확인했다는 뜻이 아닙니다.

코드보다 먼저 요구사항을 확인합니다

AI 리뷰어는 명백한 버그, null 처리, 안전하지 않은 패턴, 검증 누락, 의심스러운 로직, 중복 코드, 테스트 공백을 찾아낼 수 있습니다. 하지만 제품 의도는 고객과 나눈 대화, 제품 회의, 지원 티켓, 법적 요구사항, 문서화되지 않은 예외, 과거 결정에 담겨 있을 수 있습니다. 모델이 이 맥락을 보지 못하거나 잘못 이해할 수 있으므로, 리뷰어는 “코드가 괜찮은가?”에 앞서 “요구한 문제를 해결하는가?”를 확인해야 합니다.

원래 요구사항이 무엇인지, 사용자가 실제로 어떤 동작을 봐야 하는지, 어떤 업무 규칙이 중요한지, 절대 일어나면 안 되는 일이 무엇인지 살펴봅니다. AI가 어떤 가정을 했는지도 찾아 그 가정이 맞는지 검토합니다. 구현을 이해하는 일과 올바른 문제를 풀고 있는지 확인하는 일을 구분해야 합니다.

테스트를 독립적인 비판자로 만듭니다

구현을 만든 AI에게 곧바로 “이 구현의 테스트를 작성하라”고 하면 테스트도 구현과 같은 사고방식을 따를 수 있습니다. 둘이 같은 가정을 공유하면 테스트 통과는 서로의 일치만 보여줄 뿐입니다. 저자는 테스트 생성 단계에 회의적인 QA 엔지니어 역할을 부여하라고 제안합니다. 구현이 옳다고 가정하지 말고 요구사항을 토대로 실패 사례, 악용 사례, 경계 조건, 경쟁 상태, 잘못된 상태, 예상 밖의 사용자 행동을 찾아 테스트하도록 합니다.

구현과 비판 역할을 분리해도 사람의 검토를 대신하지는 않습니다. 다만 생성과 검토가 같은 가정을 반복하는 단순한 동의 절차를 줄이는 데 도움이 됩니다. 원래 요구사항, 구현, 테스트를 나란히 놓고 세 가지가 모두 일치하는지 확인해야 합니다. 구현과 테스트만 서로 맞고 요구사항과 어긋날 수도 있습니다.

사람이 확인할 일곱 가지

첫째, 코드가 프롬프트에 맞는지만 보지 말고 사용자나 사업이 실제로 요청한 일을 해결하는지 확인합니다. 둘째, 사용자 행동과 데이터, 권한, API, 인프라, 실행 순서와 시점에 관한 AI의 가정을 모두 살펴봅니다. 셋째, 네트워크 실패, 일부 데이터베이스 쓰기 성공, 반복 요청, 외부 API 시간 초과, 동시 요청, 예상 밖의 입력을 점검합니다.

넷째, 변경이 실패하면 영향이 한 구성요소에 그치는지, 고객 전체나 결제·인증·데이터 무결성까지 번지는지 따집니다. 다섯째, 새 추상화나 의존성을 더했는지, 기존 기능을 중복 구현했는지, 아키텍처 경계를 우회했는지, 시스템을 이해하기 어렵게 만들었는지 확인합니다. 여섯째, 테스트가 통과했는지만 보지 말고 실제로 무엇을 검증하는지 읽습니다. 요구사항이 틀렸다면 테스트가 그 사실을 알아챌 수 있는지도 질문합니다. 일곱째, “왜 이렇게 구현했나요?”라는 질문에 AI가 만들고 Copilot이 승인했다는 답보다 나은 설명을 할 수 있어야 합니다.

AI는 기계적 결함을, 사람은 의미와 위험을 봅니다

저자는 AI 코드 리뷰 자체를 반대하지 않습니다. AI는 사람이 놓치는 문제를 찾고 반복적인 리뷰 부담을 줄이며 큰 변경을 빠르게 살필 수 있습니다. 다만 AI가 구현하고 테스트하고 리뷰한 뒤 사람이 승인 버튼만 누르는 방식은 피해야 합니다. 사람이 코드의 기계적 정확성만 확인하면 자동화된 절차의 마지막 버튼에 그칠 수 있습니다.

개발자는 요구사항을 이해하고, 가정을 따져 묻고, 시스템을 설계하며, 동작과 위험을 검증하고 결과를 책임지는 데 더 많은 시간을 써야 합니다. 코드가 맞는지만 확인하는 대신 AI가 알지 못할 고객 의도, 과거 장애, 운영 환경, 조직 제약, 문서화되지 않은 의존성이 무엇인지 묻습니다. AI는 구현을 검토하지만, 개발자는 현실과 요구사항을 검토해야 합니다.

dev.to 반응

• @kanunilabs — 여기서 더 흥미로운 질문은 AI가 올바른 코드를 쓸 수 있느냐가 아니라, 원래 요구사항을 제대로 이해했는지 어떻게 검증하느냐고 생각합니다. 같은 모델이 코드를 쓰고 테스트를 만들고 pull request를 리뷰하면, 독립적인 검증은 부족한데 자신감만 커질 수 있습니다. 개발자의 역할은 모든 줄을 확인하는 일에서 코드 뒤에 있는 가정과 업무 규칙, 결정을 따져 묻는 일로 옮겨갈지도 모릅니다. 좋은 내용이었습니다. 잘 읽었습니다.

원문: dev.to / 번역·요약: Trawling