Reviewing AI-Generated Code: Check Boundaries Before Logic

개요

AI가 생성한 코드는 논리적으로는 올바르게 보일 수 있으나, 예상치 못한 계층 간 의존성이나 잘못된 위치에 로직이 삽입될 수 있어 이를 방지하기 위한 구조적 검토 워크플로우가 중요하다.

주요 내용

- AI 코드 검토의 차이점: 동료의 코드와 달리 AI는 아키텍처적 의도를 가지지 않고, 컴파일되고 테스트를 통과하는 코드를 생성하는 데 최적화되어 있어, 코드의 논리적 정확성 이전에 구조적 타당성을 먼저 확인해야 한다.
- 위험한 실패의 본질: AI 코드의 치명적인 오류는 논리 오류가 아닌, 잘못된 계층에 위치하거나 예상치 못한 의존성을 가지는 구조적 문제입니다. 이러한 오류는 즉각적인 테스트 실패로 이어지지 않고 시간이 지난 후에야 발견될 가능성이 높다.
- 권장 코드 검토 순서: 일반적인 코드 검토와 반대로, 파일의 계층, import 문, 인터페이스 계약, 로직 위치, 최종적으로 논리 정확성을 순서대로 확인한다.
- 다섯 가지 구조적 신호:
1. 잘못된 Import: 해당 파일이 속한 계층에서 허용되지 않는 다른 계층의 모듈을 import 하는 경우. (예: application 레이어에서 API 레이어나 infrastructure 레이어의 모듈 import)
2. 잘못된 위치의 로직: API 라우트 핸들러와 같이 표현 계층에서 비즈니스 도메인 규칙이나 로직이 포함된 경우.
3. 새로운 추상화의 도입: 코드베이스 내에 기존 패턴과 일치하지 않는 새로운 패턴이나 추상화가 AI에 의해 생성된 경우.
4. 내부 상태 변경 (Silent State Mutation): 순수 함수처럼 보이나 실제로는 객체의 내부 상태를 변경하고 자신을 반환하는 경우.
5. 누락된 에러 경로: 데이터 조회 후 결과가 없을 경우(예: None 반환)에 대한 예외 처리가 누락된 경우.
- 실제 워크플로우 적용: GET /orders/{order_id} 요청에 대한 AI 생성 코드를 검토할 때, 잘못된 import 신호가 감지되면 로직 검토를 중단하고 프롬프트 수정을 요청하여 구조적 문제를 먼저 해결한다.
- 두 가지 안티패턴:
* 러버 스탬핑 (Rubber-stamping): 구조적 검토 없이 AI 생성 코드를 무조건 수용하는 것.
* 과도한 세부 사항 검토 (Over-scrutinizing style): 코드의 스타일이나 사소한 디테일에 과도하게 시간을 쏟는 것.
- 피드백 루프: 반복적인 검토를 통해 AI에게 제공하는 프롬프트를 개선하여, 특정 신호에서 반복적으로 발생하는 문제(예: 로직 위치 문제)를 해결하기 위한 구체적인 제약 조건을 추가하는 선순환 구조를 만든다.

시사점

AI 코드 생성 시 로직의 정확성뿐만 아니라 코드의 계층 구조, 의존성, 로직의 적절한 위치 등을 체계적으로 검토하는 워크플로우를 구축하는 것이 개발 생산성과 코드 품질 유지에 필수적이다.