테스트 주도 AI 에이전트 정의 (TDAD): 행동 명세로부터 도구 사용 에이전트 컴파일하기

기존의 LLM 에이전트 개발은 프롬프트를 수동으로 수정하고 결과를 눈으로 확인하는 시행착오 방식에 의존하여 안정성이 낮았다. 이 논문은 소프트웨어 공학의 TDD(테스트 주도 개발)를 에이전트에 도입해, 요구사항을 자동으로 테스트로 변환하고 프롬프트를 최적화함으로써 배포 후 발생할 수 있는 오작동과 성능 저하를 획기적으로 줄인다.

기존 에이전트 개발은 프롬프트를 수정할 때마다 다른 기능이 망가지는 '회귀(Regression)' 문제에 취약하다. 이는 딥러닝 모델의 확률적 특성 때문에 특정 입력에 대한 출력을 예측하기 어렵고, 프롬프트가 모델의 가중치처럼 작동하지만 명확한 검증 체계 없이 관리되기 때문이다.

TDAD는 프롬프트를 '컴파일된 결과물'로 취급한다. 개발자가 YAML 형식의 행동 명세를 작성하면, TestSmith 에이전트가 이를 실행 가능한 테스트 코드로 변환한다. 이후 PromptSmith 에이전트가 이 테스트를 통과할 때까지 프롬프트를 미세 조정하는데, 이는 손실 함수(Loss Function)를 줄여가는 경사 하강법(Gradient Descent)과 유사한 논리로 프롬프트를 최적화하는 과정이다.

특히 '스펙 게이밍(Specification Gaming)'을 방지하기 위해 모델이 보지 못한 숨겨진 테스트를 활용하고, 의도적으로 결함이 있는 프롬프트를 만들어 테스트가 이를 잡아내는지 확인하는 변이 테스트를 수행한다. 이를 통해 에이전트가 단순히 특정 문구에 최적화되는 것이 아니라, 명세에 담긴 의도를 정확히 학습하도록 유도한다.

TDAD 파이프라인은 네 가지 역할로 구성된다. TestSmith는 YAML 명세를 입력받아 MFT(최소 기능 테스트), INV(불변성 테스트), DIR(방향성 테스트) 등 다양한 유형의 테스트를 생성한다. [YAML 명세 → TestSmith 연산 → 실행 가능한 테스트 세트 출력] 순으로 진행되어 요구사항의 테스트 자동화를 구현한다.

PromptSmith는 생성된 가시적 테스트(Visible Tests)를 기반으로 프롬프트를 반복 수정한다. 각 반복에서 실패한 테스트를 클러스터링하고 근본 원인을 분석하여 프롬프트를 편집한다. [프롬프트 + 실패 로그 → PromptSmith 분석 → 수정된 프롬프트 출력] 과정을 거쳐 테스트 통과율을 높인다.

MutationSmith는 컴파일된 프롬프트에 의도적인 오류(예: 권한 체크 건너뛰기)를 주입한 변이체(Mutant)를 생성한다. 기존 테스트 수트가 이 변이체를 감지(Kill)하는지 측정하여 테스트의 엄격함을 평가한다. [컴파일된 프롬프트 + 오류 의도 → MutationSmith 연산 → 변이된 프롬프트 출력]을 통해 검증 체계의 품질을 보장한다.

SpecSuite-Core 벤치마크 평가 결과, v1 명세에 대해 92%의 컴파일 성공률을 기록했으며, 숨겨진 테스트 통과율(HPR)은 평균 97.3%에 달했다. 이는 에이전트가 학습하지 않은 시나리오에서도 높은 일반화 성능을 보임을 입증한다.

명세가 진화하는 v1 → v2 시나리오에서 회귀 안전 점수(SURS)는 97.2%로 나타났다. 새로운 기능을 추가하더라도 기존의 행동 계약이 파괴되지 않고 유지됨을 수치로 증명했다.

변이 점수(Mutation Score)는 86~100% 범위를 기록했다. 이는 TDAD가 생성한 테스트 수트가 에이전트의 잠재적인 정책 위반이나 도구 오용 시나리오를 매우 효과적으로 포착할 수 있음을 의미한다.

TDAD는 프롬프트를 소스 코드가 아닌 컴파일된 아티팩트로 정의하며, YAML 기반의 행동 명세를 단일 진실 공급원(Single Source of Truth)으로 삼는다. 명세에는 도구 스키마, 우선순위가 지정된 정책, 결정 트리(Decision Tree)가 포함된다.

테스트 생성 시 CheckList 방법론을 차용하여 MFT, INV, DIR 테스트를 구성한다. 특히 도구 호출 추적(Tool-call trace)에 대해 결정론적 검증(Deterministic Evaluation)을 수행하여, 자연어 응답의 모호함 대신 구조화된 데이터 기반의 엄격한 어설션을 적용한다.

안티 게이밍을 위해 컴파일 단계에서는 가시적 테스트만 사용하고, 평가 단계에서만 숨겨진 테스트를 사용하는 '테스트 분할' 전략을 취한다. 또한 변이 테스트 시 '활성화 프로브(Activation Probe)'를 사용하여 주입된 오류가 실제로 모델 행동을 변화시켰는지 확인하는 과정을 거친다.

구현 측면에서는 Docker 컨테이너를 통한 격리 환경에서 pytest를 실행하며, Claude Code와 같은 최신 코딩 에이전트를 활용해 테스트 생성 및 프롬프트 수정을 자동화한다.

명세 자체가 불완전하거나 테스트로 인코딩하기 어려운 주관적인 속성(예: 공감 능력)은 검증하기 어렵다. 또한 변이 테스트 시 비활성 변이체를 제외하더라도 실제 결함과 무관한 변이가 포함될 수 있어 점수가 과대평가될 위험이 있다.