AI 코딩 어시스턴트(AI coding assistants)는 그럴듯한 디프(diff)를 생성하는 데 매우 뛰어납니다. 하지만 그 디프가 세 파일 떨어진 곳의 엣지 케이스(edge case)를 조용히 망가뜨렸는지 여부를 알려주는 데는 그리 뛰어나지 않습니다. "괜찮아 보이네, 배포하자, 다시 롤백하자"라는 과정을 몇 차례 반복한 끝에, 저는 생성된 패치(patch)를 눈으로만 검토하는 것을 신뢰하지 않기로 했고, 어떤 AI 생성 변경 사항이라도 병합(merge)하기 전에 반드시 통과해야 하는 작고 반복 가능한 하네스(harness)를 구축했습니다.

이 포스트에서는 해당 하네스에 대해 설명합니다. 즉, 골든 입력(golden-input) 테스트 세트, 디프 인식 체크 스크립트(diff-aware check script), 그리고 무료 호스팅 모델 액세스가 충분한 경우와 자체 인프라가 필요한 경우를 구분하는 결정 테이블(decision table)을 다룹니다. 이 방식은 어떤 모델 제공업체와도 작동하지만, 비용 문제로 인해 모든 변경 사항에 대해 이 루프를 실행하는 것을 주저하는 경우가 많으므로, 무료 티어(MonkeyCode의 무료 모델 액세스 및 무료 서버 옵션 포함)가 자연스럽게 적용되는 지점을 언급하겠습니다.

문제점: 생성된 코드는 지루한 방식으로 실패한다

AI 지원 변경 사항에서 실제로 발생하는 실패는 극적이지 않습니다. 다음과 같은 것들입니다:

• 리팩터링(refactored)된 파서(parser)가 이전에는 보존하던 공백을 이제는 잘라버리는 경우.
• 지터(jitter)를 제거하여 재시도(retry)가 동기화되어 한꺼번에 몰아치는 "단순화된" 재시도 루프.
• 결과 수가 페이지 크기의 정확한 배수일 때만 발생하는 페이지네이션(pagination)의 오프 바이 원(off-by-one) 오류.

이 중 어느 것도 디프를 가볍게 읽어서는 나타나지 않습니다. 하지만 알려진 까다로운 입력값들의 고정된 세트에 대해 변경 사항을 실행하고, 실행 전후의 동작을 비교하면 모두 나타납니다.

결과물: 3부 구성의 하네스

하네스는 세 가지 요소로 구성되어 있으며, 각각은 그 자체로는 지루합니다:

1. 골든 입력(Golden inputs): 과거에 문제를 일으켰던 입력값들을 체크인(checked-in)해 둔 디렉토리와 각 입력에 대한 예상 동작.
2. 러너(A runner): 모든 골든 입력에 대해 현재 코드를 실행하고, 출력값을 예상 결과와 디프(diff) 비교하는 스크립트.
3. 게이트(A gate): 작성자가 명시적으로 승인하지 않은 불일치가 러너(runner)에서 보고될 경우 실패 처리하는 CI(또는 병합 전 스크립트).

다음은 Python으로 작성된 최소한의 러너입니다. 어디서든 작동할 수 있도록 의도적으로 의존성(dependency)을 없앴습니다:

#!/usr/bin/env python3
"""golden_run.py — 골든 입력(golden inputs)을 실행하고, 예상 출력(expected outputs)과 비교합니다.

...

blessed_changes.json 파일이 중요한 부분입니다. AI의 변경 사항이 의도적으로 동작을 변경할 때, 단순히 예상 파일을 업데이트하는 것이 아니라, 케이스 이름과 한 줄짜리 이유를 추가합니다. 이렇게 하면 코드 리뷰 과정에서 사람이 동작의 차이(behavioral delta)를 반드시 인지하도록 강제할 수 있습니다:

{
  "case_014": "공백 트리밍(Whitespace trim)은 의도된 사항임; docs/parser.md의 파서 계약(parser contract)이 업데이트됨"
}

루프(loop) 내에서 AI의 역할

이 하네스(harness)는 제가 어시스턴트를 사용하는 방식을 바꿉니다. "수정 사항을 생성하면 제가 검토하겠습니다" 대신, 다음과 같은 루프로 변합니다:

1. 버그를 설명하고 모델에게 **수정 사항과 더불어 이를 재현할 수 있는 새로운 골든 입력(golden input)**을 요청합니다.
2. 하네스를 실행합니다. 새로운 케이스는 기존 코드에서는 실패하고, 새로운 코드에서는 통과해야 합니다. 만약 양쪽 모두에서 통과한다면 재현 케이스(repro case)가 잘못된 것입니다. 이는 매우 흔한 일이며, 여기서 이를 잡아내는 것이 잘못된 병합(merge)을 방지합니다.
3. 만약 다른 케이스들이 실패한다면, 불일치하는 출력(mismatch output)을 모델에 다시 입력하여 반복하거나, 수동으로 수정합니다.

2단계는 반복 비용(iteration cost)이 중요한 지점입니다. 재현 케이스가 실제로 재현되는지 확인하는 과정은 종종 모델과 서너 번의 왕복(round trips)을 필요로 하며, 이는 사용량 기반 API(metered APIs) 비용을 누적시킵니다. 바로 이 지점에서 무료 티어(free-tier) 액세스가 진정으로 유용합니다. 저는 이러한 탐색적 반복(exploratory iterations)을 무료 모델 액세스와 무료 서버 옵션을 제공하는 MonkeyCode를 통해 처리하여, 유료 용량은 다른 용도로 아껴둡니다. 검증 루프에는 가장 강력한 모델이 필요하지 않습니다. 주저 없이 다시 실행할 수 있는 저렴하고 빠른 모델이 필요할 뿐입니다.

고지 사항: 이 기사는 MonkeyCode의 제품 홍보의 일환으로 작성되었습니다.

실무적인 참고 사항 하나: 무료 서버는 공유 인프라이기 때문에, 제공업체와 관계없이 골든 입력에는 비밀 정보(secrets)나 고객 데이터를 포함하지 않습니다. 이는 어쨌든 갖춰야 할 습관입니다.

무료 호스팅 액세스가 충분한 경우와 그렇지 않은 경우

마지막 두 행이 실제적인 한계점입니다. 공유 서버나 무료 서버는 타이밍에 민감한 벤치마크(benchmarks)를 수행하기에 적절한 장소가 아니며, "무료"는 보통 당신이 정확히 어떤 모델 버전에 접속했는지에 대한 보장을 제공하지 않으므로, 출력을 몇 주에 걸쳐 재현 가능한 것으로 취급하지 마세요. 행동 차이(behavior-diff) 테스트를 위한 용도라면 괜찮습니다. 모델이 아니라 당신의 골든 기대값(golden expectations)이 진실의 근원(source of truth)이기 때문입니다. 모델의 출력이 곧 결과물(artifact)이 되는 모든 경우에는 당신이 제어할 수 있는 어딘가에 버전을 고정(pin)하세요.

또한: 만약 당신의 골든 세트(golden set)가 12개 미만의 케이스로 구성되어 있다면, 이 하네스(harness)는 형식적인 절차에 불과합니다. 보상은 세트가 수십 개로 늘어나고 수동 재검토가 더 이상 현실적이지 않게 될 때부터 시작됩니다.

솔직한 한계점

• 이 하네스는 당신이 생각한 케이스들에 대한 행동 차이(behavioral diffs)를 포착합니다. 당신이 생각하지 못한 케이스에 대해서는 아무것도 말해주지 않습니다. 속성 기반 테스트(Property-based tests)가 이를 잘 보완해 줍니다.
• 행동이 빈번하게 변하면 골든 기대값 파일(Golden expected files)은 노후화됩니다. 축복(blessing) 메커니즘이 이를 완화해주지만, 이는 리뷰어가 실제로 그 이유를 읽는다는 것에 의존합니다.
• 무료 티어는 변경됩니다. "오늘은 비용이 들지 않는다"라는 전제하에 구축된 모든 것은 유료 또는 로컬 폴백(fallback)으로 우아하게 전환(degrade gracefully)될 수 있어야 합니다.

마무리

AI 생성 코드를 제가 신뢰할 수 있을 만큼 만들 수 있었던 변화는 더 나은 모델이 아니었습니다. 그것은 모든 생성된 변경 사항이 고정되고 점진적으로 확장되는 까다로운 입력 세트에 대해 스스로를 증명하게 만들고, 의도적인 행동 변화에 대해 인간의 승인(sign-off)을 거치게 만든 것이었습니다. 예산을 투입하지 않고 이 루프를 시도해보고 싶다면, MonkeyCode의 무료 티어가 반복적인 단계를 실행하기에 합리적인 장소입니다. 하네스 자체는 제공업체에 구애받지 않으며(provider-agnostic), 어떤 경우든 당신의 소유로 남습니다.