2026년 2월 21일 · 아샬

AI 시대, 코드 리뷰는 어떻게 바뀌어야 하는가

AI가 코드를 쓰기 시작하면서 코드 리뷰가 이상해졌습니다.1

리뷰어가 PR을 열었습니다. 코드가 있습니다. 수백 줄입니다. 개발자가 AI에게 요청했고, AI가 작성했습니다. 개발자는 결과를 확인하고 PR을 올렸습니다.

예전 방식대로 한 줄씩 읽습니다. 코드는 깔끔합니다. 변수명도 명확합니다. 중복도 없습니다. 그런데 뭔가 이상합니다. 이 코드가 왜 이렇게 됐는지, 어떤 판단으로 이 구조를 선택했는지 알 수가 없습니다. 물어보면 개발자도 잘 모릅니다. AI가 이렇게 만들었다고 합니다.

승인해야 할까요, 반려해야 할까요.

기존 코드 리뷰는 이런 것들을 봤습니다. 코드가 의도대로 동작하는가. 예외 처리가 빠진 곳은 없는가. 변수명이 명확한가. 중복이 있는가. 더 나은 구조가 있는가. 코드를 쓴 사람의 판단을 검증하는 과정이었습니다.

AI가 코드를 쓰면 이 구조가 흔들립니다.2

문법, 스타일, 중복 제거, 패턴 적용. AI가 작성한 코드는 대체로 이런 면에서 꼼꼼하고 일관성이 있습니다. 사람보다 나을 때도 많습니다.

반면 AI가 하지 못하는 것들이 있습니다. 이 기능이 지금 만들어야 하는 게 맞는가. 이 접근 방식이 제품의 방향과 일치하는가. 6개월 후 이 코드를 다른 사람이 유지보수할 수 있는가. 이런 판단은 코드 안에 없습니다.

검증해야 할 판단의 위치가 바뀝니다. 코드 안의 판단이 아니라, 코드를 요청하는 시점의 판단입니다. 개발자가 AI에게 무엇을 요청했는가. 그 요청이 올바른 방향이었는가. 충분한 맥락을 전달했는가. 스펙이 명확했는가.

이제 코드 리뷰에서 집중해야 할 부분은 코드가 아니라 판단입니다.

코드 리뷰

그렇다면 그 판단을 어디서 봐야 하는가. 코드에서는 볼 수 없습니다. 코드는 AI가 선택한 결과를 보여줄 뿐입니다. 왜 그 선택을 했는지는 코드에 없습니다.

판단을 기록한 문서가 필요합니다. 기능이 어떻게 동작해야 하는지를 코드보다 먼저 정의해야 합니다. 그게 바로 스펙입니다.3 스펙이 있어야 코드가 그것과 일치하는지 볼 수 있습니다. 스펙이 없으면 리뷰어는 코드가 뭘 하는지 파악하는 데 대부분의 시간을 씁니다. 맞는지 판단하는 데는 시간이 없습니다.

테스트가 있으면 리뷰가 달라집니다. 테스트를 먼저 작성했다면, “이 코드가 맞게 동작하는가”는 테스트를 통해 이미 확인한 상태일 겁니다. 리뷰어는 다른 것을 볼 수 있습니다. “이 테스트로 충분한가.” “중요한 테스트 케이스가 빠진 건 아닌가.” “성공의 기준이 제대로 정의됐는가.”

리뷰의 무게중심이 코드에서 기준으로 이동합니다. 코드를 리뷰하는 것에서 기준을 리뷰하는 것으로.

코드 리뷰가 불편해졌다면, 대부분 이것 때문입니다. 코드는 있는데 의도가 없습니다. 코드를 사람이 직접 작성했든 AI가 작성했든 상관없습니다. 의도가 기록으로 남아 있지 않은 것이 문제입니다.

스펙을 먼저 작성하세요. 코드가 그 스펙을 구현했는지 확인하세요. 코드 리뷰는 코드가 아니라 판단을 검증하는 것입니다.

DAL-LAB Services

우리 팀에 맞는 AI 도입과 개발 전략이 필요하신가요?

상황에 맞는 실행 계획을 함께 정리해드립니다.

서비스 보러 가기