AI가 생성한 코드를 사람이 직접 읽지 않고 자동으로 검증하는 방법

TL;DR Highlight

Property-based testing과 mutation testing의 결합은 코드 리뷰 패러다임을 '읽기'에서 '검증하기'로 전환했으나 FizzBuzz 수준의 단순 문제에만 적용 가능하다.

Who Should Read

AI 코딩 에이전트를 실무에 도입하고 싶은데 코드 품질과 안전성이 걱정되는 개발자. 특히 테스트 자동화에 관심 있고 AI 생성 코드를 프로덕션에 배포하는 워크플로우를 설계 중인 팀.

Core Mechanics

저자는 '리뷰(코드를 한 줄씩 읽기)'와 '검증(코드가 올바른지 확인하기)'을 개념적으로 분리했다. 검증은 사람이 직접 읽는 것 외에도 자동화된 제약 조건으로 대체할 수 있다는 게 핵심 주장이다.
검증 방법 4가지를 조합해서 사용했다: (1) property-based testing으로 요구사항 충족 여부 확인, (2) mutation testing으로 불필요한 코드 없음 보장, (3) 사이드 이펙트 없음 강제, (4) Python 타입 체킹 + 린팅. 이 4가지를 모두 통과하면 코드를 직접 안 읽어도 된다고 판단했다.
Property-based testing은 특정 입출력 쌍을 테스트하는 대신, 코드가 만족해야 할 '속성(property)'을 정의하고 Python의 Hypothesis 라이브러리로 100개 이상의 랜덤 입력을 자동 생성해 테스트한다. 경계값(0, 매우 큰 수 등 '흥미로운' 케이스)을 자동으로 찾아주는 게 장점이다.
Mutation testing은 mutmut 같은 도구가 코드를 조금씩 변형(연산자 교체, 상수 조정 등)해서 테스트가 이 변형된 코드를 걸러내는지 확인한다. 테스트가 통과해버리면 '살아남은 뮤턴트'로 간주해 코드나 테스트에 문제가 있다고 판단한다. 요구사항 이상의 불필요한 코드가 없는지 검증하는 데 효과적이다.
저자는 AI 생성 코드의 가독성·유지보수성을 더 이상 신경 쓰지 않아도 된다고 주장한다. 컴파일된 바이너리처럼 다루면 된다는 발상인데, 이 관점 자체가 기존 소프트웨어 개발 문화와 상당히 다른 접근이다.
현재는 이 검증 체계를 세팅하는 오버헤드가 코드를 직접 읽는 것보다 크다고 솔직히 인정한다. 하지만 에이전트와 툴링이 발전할수록 이 오버헤드가 줄어들 것이라는 기대로, 지금은 베이스라인을 잡는 실험으로 의미를 둔다.
GitHub에 fizzbuzz-without-human-review 레포를 공개해서 직접 실험해볼 수 있게 해뒀다. 공식 검증(formal verification)보다 가벼우면서도 '오류율이 수면을 취할 수 있을 만큼 낮은' 중간 지점을 목표로 한다.

Evidence

가장 많은 반응을 얻은 비판은 'FizzBuzz는 너무 단순해서 현실 대표성이 없다'는 것이다. 메모리 얼로케이터나 복잡한 시스템을 AI에게 짜게 하면 자동 검증이 모든 실패 모드를 커버할 수 없고, 이건 AI 문제가 아니라 소프트웨어 복잡도 자체의 문제라는 의견이 많았다.
'에이전트가 코드도 쓰고 테스트도 쓰면 같은 멘탈 모델에서 나온 버그가 테스트에도 반영된다'는 지적이 설득력 있게 제기됐다. 실제로 AI가 자체 생성한 테스트를 모두 통과했는데도 엣지 케이스에서 틀린 로직이 배포된 경험을 공유한 댓글이 있었다. 이에 대해 '코드가 아니라 스펙/속성을 꼼꼼히 검토하는 게 맞는 방향'이라는 대안 프레임이 제시됐다.
Anthropic이 에이전트로 C 컴파일러를 만들려 했는데, 수천 개의 잘 작성된 테스트가 있었음에도 버그 하나를 고치면 다른 버그가 생기는 수렴 실패를 겪었다는 사례가 언급됐다. 이는 '테스트 통과'와 '실제로 발전 가능한 코드베이스'가 다르다는 점을 보여준다는 의견이다.
실무에서 TUI SQL 쿼리 도구를 에이전트로 처음부터 만들어봤다는 경험담도 있었다. 실제로 유용한 도구가 만들어졌지만, 여러 기능이 서로 상호작용하는 엣지 케이스에서 버그가 많이 나왔고, UI 전체의 일관성 유지가 어려웠다고 한다. 가장 큰 원인은 '느슨한 프롬프팅'과 시스템 전반의 아키텍처 가이드 부재라고 진단했다.
'테스트를 충분히 작성하면 결국 테스트가 곧 코드가 되는 것 아니냐'는 철학적 반론도 나왔다. 관련 블로그 포스트(softwaredoug.com)가 링크됐는데, 이는 '검증을 위한 오버헤드가 커질수록 차라리 그냥 코드를 읽는 게 낫지 않느냐'는 현실적인 반문과도 이어진다.

How to Apply

독립적이고 순수 함수로 표현 가능한 비즈니스 로직(계산, 변환, 파싱 등)을 AI로 생성할 때, Python이라면 Hypothesis로 property-based test를 먼저 작성하고 AI에게 이 테스트를 통과하는 코드를 생성하게 시키면 직접 코드를 읽는 시간을 줄이면서도 정확성을 높일 수 있다.
AI가 생성한 코드에 불필요한 사이드 이펙트(로깅, 전역 상태 변경 등)가 숨어있는지 걱정된다면, mutmut 같은 mutation testing 도구를 CI에 추가해서 테스트가 이런 사이드 이펙트를 감지하는지 자동으로 확인하는 파이프라인을 구축할 수 있다.
팀에서 AI 코딩 에이전트 도입을 검토 중이라면, 이 글의 접근법을 그대로 프로덕션에 적용하기보다 '리뷰에서 검증으로'라는 사고 전환의 참고 자료로 활용하고, 현재 단계에서는 스펙과 테스트 속성 자체를 사람이 꼼꼼히 검토하는 것을 코드 리뷰의 새로운 초점으로 삼는 게 현실적이다.

Code Example

snippet

# Property-based testing 예시 (Hypothesis 사용)
from hypothesis import given, strategies as st

@given(n=st.integers(min_value=1).map(lambda n: n * 3 * 5))
def test_returns_fizzbuzz_for_multiples_of_3_and_5(n: int) -> None:
    assert fizzbuzz(n) == "FizzBuzz"

# Mutation testing 예시 - 사이드 이펙트가 있으면 뮤턴트가 살아남음
# 아래 코드에서 print(f"DEBUG n={n}")를 print(None)으로 바꿔도
# test_doubles_input이 통과해버린다 → 뮤턴트 생존 = 문제 있음
def double(n: int):
    print(f"DEBUG n={n}")  # 이 사이드 이펙트를 테스트가 잡지 못함
    return n * 2

def test_doubles_input():
    assert double(3) == 6

# 수정 방법: print 제거하거나 해당 출력을 테스트에 포함

Terminology

property-based testing특정 입력·출력 쌍을 하드코딩하는 대신, '3과 5의 공배수를 넣으면 항상 FizzBuzz가 나온다'처럼 코드가 만족해야 할 규칙을 정의하고 수백~수천 개의 랜덤 입력을 자동 생성해 그 규칙이 깨지는 경우를 찾는 테스트 방식.

mutation testing테스트가 얼마나 빈틈없는지 확인하기 위해 코드를 일부러 조금씩 망가뜨려보는 기법. 망가진 코드(뮤턴트)를 테스트가 잡아내면 '뮤턴트 제거'(좋음), 테스트가 통과해버리면 '뮤턴트 생존'(테스트나 코드에 문제 있음).

side effect함수가 반환값 외에 외부 상태(파일 시스템, 전역 변수, 콘솔 출력, DB 등)를 변경하는 것. 사이드 이펙트가 없는 순수 함수는 같은 입력에 항상 같은 출력을 내서 테스트와 검증이 훨씬 쉽다.

formal verification수학적 증명을 통해 코드가 특정 속성을 반드시 만족함을 100% 보장하는 기법. 안전성이 극도로 중요한 시스템(항공, 의료기기 등)에 쓰이지만, 설정과 작성 비용이 매우 크다.

mutmutPython용 mutation testing 도구. 코드에서 연산자 변경, 상수 조정 등 작은 변형을 자동으로 만들어내고 기존 테스트 스위트가 이를 감지하는지 검사해준다.

coding agent사람이 자연어로 요구사항을 주면 스스로 코드를 작성하고 실행하며 반복 수정까지 하는 AI 시스템. Claude, Cursor, Devin 같은 도구들이 여기에 해당한다.