실험 제원 및 비용 지표

GPT-5.6 Sol(Codex) 모델을 사용해 Rust 언어로 Zstd를 구현하는 환경에서 26가지 프롬프트 조건과 4가지 스킬의 효능을 측정했다. 실험 대상에는 TDD, Verus, Alloy, Lean 4, Kani, TLA+ 등 형식적 검증 도구와 QuickCheck, Proptest 같은 속성 기반 테스트 라이브러리가 포함됐다. SMT 솔버의 경우 Z3, cvc5, Yices를 모두 설치해 환경을 제공했으며, 각 조건당 medium과 xhigh 추론 강도에서 80회씩 실행해 숨겨진 테스트를 100% 통과한 비율을 비교했다.

비용 측면에서 가장 두드러진 변화는 Hegel 공식 스킬 적용 시 나타났다. 해당 스킬은 정확도 개선 없이 medium에서 26%, xhigh에서 41%의 비용 증가를 초래했다. 이는 3만 4,000자의 스킬 문서와 4만 5,000자의 Rust 참조 문서를 포함해 초기부터 2만 토큰 이상을 불러오고 반복해서 읽는 구조 때문이다. 캐시 적중률이 99.85%에 달함에도 불구하고, 누적 토큰 사용량은 medium 기준 평균 90만 개, xhigh 기준 180만 개가 증가했다.

검증 기법의 실제 작동 양상과 한계

기법의 이름을 명시하는 것만으로는 에이전트가 실제 버그를 잡는 고품질 테스트를 설계하지 못했다. 가장 빈번한 실패 패턴은 '자신이 만든 테스트는 통과하지만 실제 버그는 놓치는' 현상이다. 예를 들어, 비트스트림 처리 기능에서 순서가 뒤바뀌는 오류를 검사해야 함에도 동일한 입력값 4개를 넣어 테스트를 구성함으로써 오류를 발견하지 못하는 사례가 관찰됐다. 잘못된 기대값을 테스트에 삽입해 오히려 잘못된 동작을 강제하는 경우도 있었다.

형식적 검증 도구들은 실제 구현의 핵심 버그와 연결되지 않은 피상적인 증명에 치우쳤다. Verus는 인코딩·디코딩의 비트 순서 반전 같은 고위험 영역 대신 '유효한 인덱스가 주어지면 범위를 벗어나지 않는다'는 식의 자명한 산술 속성이나 $A \implies A$ 형태의 증명을 수행했다. Alloy 역시 Zstd 알고리즘의 잘못된 부분을 모델링하거나, 실제로는 64비트 usize를 사용해 오버플로가 불가능한 코드임에도 8비트 오버플로 반례에 맞춰 코드를 복잡하게 수정하는 비효율을 보였다.

TDD 지시는 테스트 수를 약 2배 늘리고 코드 작성과의 교대 빈도를 높였으나, 정확도 향상으로 이어지지는 않았다. 특히 네 Huffman 스트림 점프 테이블 구현 시, 테스트 개수는 늘었지만 단순한 스트림을 반복 사용해 까다로운 엣지 케이스를 놓치는 경향이 강했다. 속성 기반 테스트(Property-based Testing) 역시 완전 무작위 입력에 의존해 단순한 입력 거부 경로만 반복 확인하는 수준에 그쳤다.

맞춤형 스킬의 효용과 도입 기준

범용 튜토리얼 방식의 스킬보다 기존의 실패 습관을 교정하는 짧은 맞춤형 스킬이 가장 높은 점수를 기록했다. 효과를 본 지시는 단순히 도구 이름을 지정하는 것이 아니라, 비대칭 입력과 경계값 사례를 우선하고 구현 뒤에 고위험 영역의 결과를 새 컨텍스트에서 독립적으로 도출해 비교하도록 강제하는 방식이었다. 특히 기존 구현의 헬퍼 함수를 재사용하지 않고 독립적인 추론으로 정답을 확인하게 하는 지시가 유효했다.

실행 결과 분석에 따르면, 모든 정보를 프롬프트에 한꺼번에 넣는 것보다 실행 과정을 살피며 몇 문장씩 추가 지시를 내리는 방식이 더 효과적이었다. 이는 모델이 이미 관련 지식을 보유하고 있을 때 전체 사용법을 다시 가르치기보다, 자주 빠지는 비효율적인 행동(예: 단순 무작위 입력 반복)에서 벗어나도록 유도하는 것이 더 생산적이기 때문이다.

실무자가 코딩 에이전트를 도입할 때는 특정 테스트 라이브러리나 기법의 명칭을 지정하기보다, 버그를 드러낼 수 있는 구체적인 입력값의 성격과 올바른 결과를 판별할 독립적인 기준을 먼저 정의하고 이를 에이전트가 준수하도록 실패 분석 구조를 잡아주는 방식으로 운영해야 한다.