AI 생성 코드의 리뷰는 모든 줄을 읽어야 하나?

이 글의 핵심 요약

• AI가 생성한 코드를 리뷰할 때, 모든 줄을 동일한 밀도로 읽을 필요는 없으며, '계약(contract)'과 '테스트(test)'를 통해 기계적으로 검증 가능한 부분과 사람이 읽어야 할 부분을 분리하는 것이 현실적입니다.
• 계약(입력과 출력에 대한 약속)을 테스트로 고정하면, 사람은 구현의 내용이 아니라 '계약 자체가 올바른지'에 집중할 수 있습니다.
• 인가(authorization), 금전, 데이터 파괴 등 계약으로 표현하기 어려운 영역은 AI 생성 코드라 할지라도 기존처럼 사람이 정독해야 합니다.

서론: AI 생성 코드 리뷰 때문에 지치고 있지는 않으신가요?

AI가 생성한 코드를 모든 줄을 동일한 밀도로 계속 읽는 것은 힘든 작업입니다. 생성량이 늘어날수록, 사람이 읽어야 할 시간이 먼저 넘쳐납니다.

이 글에서는 읽는 범위를 계약과 테스트로 좁히는 설계를 다룹니다. 목표는 '대충 한다'가 아닙니다. '읽을 곳을 선택한다' 것입니다.

참고로, 이 글은 다음 글의 문제 의식을 참고했습니다. 내용 자체를 그대로 옮긴 것이 아니라, 검색하기 쉬운 질문에 맞춰 재구성했습니다.

AI 생성 코드를 전부 동일한 밀도로 읽어야 할까?

결론부터 말하자면, 모든 부분을 동일한 밀도로 읽을 필요는 없다고 생각합니다. 이유는 두 가지입니다.

첫째는 인간의 주의력에는 한계가 있다는 것입니다. 중요한 1줄과 정형적인 10줄을 같은 열정으로 읽으면, 중요한 1줄을 놓치기 쉽습니다.

둘째는 읽지 않아도 지킬 수 있는 속성이 있다는 것입니다. 타입(type), 테스트, 정적 분석(static analysis)으로 검증할 수 있는 부분은 기계에 맡기는 것이 더 확실합니다.

다만 '읽지 않는다'와 '검증되었다'는 별개의 문제입니다. 검증 수단이 없는 부분을 읽지 않는 것은 단순한 방치일 뿐입니다.

계약(Design by Contract)이란 무엇인가?

계약이란 함수나 모듈이 지켜야 할 약속입니다. Design by Contract (DBC, 계약에 의한 설계)에서는 주로 세 가지를 정의합니다.

• 사전 조건(precondition): 호출하는 쪽이 충족해야 하는 입력의 조건
• 사후 조건(postcondition): 함수가 반환하는 결과가 충족해야 하는 조건
• 불변 조건(invariant): 처리 전후로 항상 성립하는 조건

AI에게 구현을 맡길 때, 이 세 가지는 '사양서'처럼 작동합니다. 구현은 매번 바뀌어도 괜찮고, 계약만 변하지 않으면 된다는 생각입니다.

계약을 작성하는 쪽이 인간이라는 의미

계약으로 범위를 좁히는 설계의 약점은 테스트가 취약하면 전체가 무너진다는 것입니다. AI는 '테스트를 통과하는 구현'을 만드는 데 능숙합니다. 취약한 테스트는 쉽게 빠져나갈 수 있습니다.

여기서 효과적인 것이 뮤테이션 테스트(Mutation Test)입니다. 코드를 일부러 조금 망가뜨려 (예: <를 <=로 변경), 테스트가 실패하는지 확인합니다. 망가뜨렸는데도 테스트가 통과한다면, 그 테스트는 취약하다고 판단할 수 있습니다.

실행 시간은 걸립니다. 전체에 돌릴 필요는 없고, 계약으로 지키기로 정한 중요 모듈에 한정하는 것이 현실적입니다.

운영 절차: 좁혀가며 리뷰를 시작하는 5단계

• 변경 사항을 '계약으로 지킬 수 있는 영역'과 '지킬 수 없는 영역'으로 분류한다.
• 지킬 수 있는 영역은 먼저 사람이 계약과 테스트의 초안을 작성한다.
• AI에게 구현을 맡기고, 테스트와 정적 분석(Static Analysis)을 CI에서 통과시킨다.
• 사람은 계약, 테스트, 경계 처리 방식을 리뷰한다.
• 지킬 수 없는 영역은 기존처럼 모든 줄을 읽는다.

분류 기준은 PR 템플릿에 적어두면 운영이 안정됩니다. 예를 들어 '이 PR은 승인/금전/삭제에 관련된가'와 같은 체크란입니다.

단점 · 부적합한 사람 · 잘 안되는 경우

이 설계에는 한계가 있습니다. 도입 전에 확인해 주세요.

잘 안 되는 경우

• 사양이 확정되지 않은 개발: 계약이 매일 바뀌면, 작성하는 비용이 구현 비용을 초과합니다. -
• 부작용(Side Effect) 중심의 코드: 외부 상태를 변경하는 처리는 계약으로 표현하기 어려워집니다. -
• 테스트 기반이 미비한 팀: CI에서 테스트가 돌아가지 않는다면, 좁혀가기의 전제가 성립하지 않습니다.

부적합한 사람

'리뷰를 쉽게 하고 싶을 뿐'이라면 추천하지 않습니다. 계약을 작성하는 작업은 구현을 읽는 작업과는 별도의 부담입니다. 총량은 줄지 않고 이동만 하는 경우가 있을 수도 있습니다.

남는 리스크

계약 자체가 틀렸다면, 올바르게 잘못된 구현이 양산됩니다. 계약의 리뷰만큼은 생략할 수 없습니다.

요약: 다음에 취할 행동

첫걸음은 작아도 괜찮습니다. 다음 PR에서 순수 함수(Pure Function)를 하나 골라, 계약을 3줄로 작성한 후