AI Agent 검증의 논리와 기법

AI Agent 개발의 가장 큰 적은 **'그럴듯함(Plausibility)'**이다. LLM은 언제나 자신만만하게 답을 내놓는다. 하지만 엔지니어링의 세계에서 "잘 작동하는 것 같아요"라는 말은 통용되지 않는다.

 

우리는 확률적인 AI 모델을 다루지만, 그 검증 과정은 결정론적이어야 하며 수학적으로 견고해야 한다. 본 글에서는 전통적인 테스트 기법이 AI 시대에 어떻게 확장되어야 하는지, 그리고 정답이 없는(Non-deterministic) 에이전트의 행동을 어떻게 **'객관적으로 증명'**할 수 있는지에 대한 방법론을 제시한다.

---

1. 정답이 있는 세계: EBT의 효용과 한계

우선, 우리가 익숙한 영역부터 정리하자. 입력에 대한 정답이 하나로 수렴하는(Convergent) 결정론적 로직에서는 **예시 기반 테스트(Example-Based Testing, EBT)**가 여전히 표준이다.

EBT가 충분한 영역 (The Sweet Spot)

비즈니스 로직이나 데이터 매핑처럼 도메인 규칙이 선명한 경우, EBT는 가장 경제적인 도구다.

• 명확한 비즈니스 규칙: "5만 원 이상 구매 시 배송비 0원"과 같은 로직은 경계값(Boundary Value) 테스트만으로 충분하다.
• 테스트의 문서화 기능: expect(add(1, 2)).toBe(3)과 같은 코드는 그 자체로 직관적인 사용 설명서가 된다.

여기서 핵심은 **'리팩터링 내성(Refactoring Resistance)'**이다. 구현 세부 사항(내부 인덱스 등)이 아닌, **'행동(Behavior)'**을 검증하는 EBT는 코드를 수정해도 테스트가 깨지지 않는 견고함을 제공한다.

EBT의 함정: 개발자의 상상력은 유한하다

하지만 정답이 하나라고 해서 안심할 수는 없다. EBT의 치명적 결함은 **"개발자가 상상한 케이스만 통과한다"**는 점이다.

• 알려진 미지(Known Unknowns): 나눗셈 함수를 만들면서 divide(10, 0)을 테스트 케이스에 넣지 않는 순간, 시스템은 런타임 에러의 시한폭탄을 안게 된다.
• 입력 공간의 비대칭성: 파서(Parser)나 보안 모듈처럼 입력값이 무한대에 가까운 경우, 인간이 작성한 몇 개의 예시는 빙산의 일각일 뿐이다.

EBT의 치명적 함정: "인간은 실패를 상상하지 못한다"

하지만 정답이 하나라고 해서 EBT만으로 시스템을 지킬 수 있다고 생각하는 것은 오만이다. EBT의 가장 큰 약점은 **'작성자가 상상한 시나리오만 통과한다'**는 것이다. 이를 **'테스터의 편향(Tester's Bias)'**이라 한다.

 

개발자는 본능적으로 '성공하는 케이스(Happy Path)'를 먼저 떠올린다. 기껏해야 경계값 몇 개(0, -1, null)를 추가하는 것이 고작이다. 하지만 버그는 개발자의 상식 밖, 즉 **'알려진 미지(Known Unknowns)'**가 아닌 **'알려지지 않은 미지(Unknown Unknowns)'**의 영역에 숨어 있다.

기계적 무자비함으로 '블랙 스완'을 사냥하다: 속성 기반 테스팅(PBT)

이때 필요한 것이 바로 **속성 기반 테스팅(Property-Based Testing, PBT)**이다. PBT는 개발자가 구체적인 입력을 고민하는 대신, **"절대 깨지지 않아야 할 불변의 법칙(Invariant)"**을 정의하면, 프레임워크가 무자비하게 난수를 생성하여 시스템을 공격하는 방식이다.

• 블랙 스완(Black Swan)의 발견: 인간은 문자열 처리 함수를 테스트할 때 "Hello", "123", "" 정도를 입력한다. 하지만 PBT 프레임워크는 인간이 상상조차 하기 싫은 제어 문자(\x00), 4바이트 이모지(😊), 그리고 메모리를 위협하는 1GB짜리 초장문 문자열을 쏟아붓는다. 이것이 바로 시스템을 붕괴시키는 블랙 스완이다.
• 반례의 최소화 (Shrinking): PBT의 진정한 가치는 단순히 에러를 내는 데 그치지 않는다. 에러를 유발하는 입력값이 발견되면, PBT는 그 입력을 사람이 이해할 수 있는 **'최소한의 형태'**로 줄여서 보고한다. "길이 1만의 문자열에서 에러 발생"이 아니라, "특정 특수문자 하나가 포함될 때 에러 발생"이라고 알려주는 것이다.

결국 결정론적 세계에서의 완벽한 검증은, EBT로 비즈니스 로직의 의도를 설명하고, PBT로 입력 공간의 무한성을 방어함으로써 완성된다.

 

2. 정답이 없는 세계: 입력의 복잡함을 넘어 출력의 모호함으로

PBT를 통해 우리는 '입력의 다양성'이라는 문제를 엔지니어링적으로 해결했다. 하지만 AI Agent의 시대로 넘어오면서 우리는 전혀 다른 차원의 벽에 부딪힌다. 바로 **'출력(Output)의 비결정성'**이다.

 

기존의 PBT는 "입력은 무작위라도 정답(Property)은 명확하다"는 전제 위에 서 있다. *"정렬(Sort) 함수의 결과는 항상 오름차순이어야 한다"*는 명제는 참/거짓이 분명하다.

 

하지만 다음과 같은 AI Agent의 과업을 보자.

"이 30페이지짜리 회의록을 핵심만 요약해서, 부드러운 어조의 이메일로 작성해줘."

• 정답이 없다: 이 요청에 대한 '유일한 정답'은 존재하지 않는다. 100명의 비서가 있다면 100개의 다른 이메일이 나온다.
• 불변식이 없다: 결과물에 반드시 포함되어야 할 단어를 지정하기도 어렵고, 글자 수 제한 같은 단순한 규칙만으로는 '잘 쓴 글'인지 판단할 수 없다.

입력이 복잡한 것은 PBT로 해결할 수 있었다. 하지만 출력 자체가 확률적으로 흔들리고, 정답의 기준이 주관적인 상황에서는 기존의 assert equals 방식이 무용지물이 된다. 이것이 AI 엔지니어링이 직면한 **'검증의 딜레마'**다.

 

정리해보자.

 

주관적 검증 vs 객관적 검증

대다수의 AI 개발자는 **주관적 검증(Forward Check)**에 머물러 있다.

• $x \rightarrow y$ ("입력을 넣으니 결과가 그럴듯하네?")
• 이것은 평가자의 기분이나 편향에 좌우되는, 엔지니어링이 아닌 '감상'의 영역이다.

우리는 이것을 **객관적 검증(Round-Trip Check)**으로 전환해야 한다.

• $x \rightarrow y \rightarrow x'$ ("결과를 다시 되돌렸을 때, 원본과 일치하는가?")
• 평가는 '느낌'이 아니라 **거리(Distance)**와 **일치 여부(Equality)**라는 수학적 측정의 영역이 된다.

즉 그럴듯해 보인다"는 주관적 감상을 배제하고, AI의 행동을 수학적으로 증명하기 위해 우리는 검증의 패러다임을 **'정답 확인'**에서 **'논리적 완결성 측정'**으로 전환해야 한다.

 

이를 위한 구체적이고 객관적인 4가지 엔지니어링 방법론을 제시한다.

 

3. AI Agent 검증을 위한 4가지 방법론: 주관을 수치로 환원하다

정답이 없는 문제(Non-deterministic Problem)에서 "제대로 동작함"을 증명한다는 것은 모순처럼 들린다. 하지만 우리는 검증의 대상을 '결과값 자체'가 아닌 '관계', '복원력', **'제약 조건'**으로 치환함으로써 이를 수학적으로 검증 가능한 문제로 바꿀 수 있다.

 

다음은 AI의 출력을 객관적 지표로 환원하는 4가지 엔지니어링 방법론이다.

① 왕복 엔지니어링 (Round-Trip Verification)

수학적 원리: f−1(f(x))≈x (역함수를 통한 원본 복원성 증명)

이 기법이 가장 객관적인 이유는 평가의 기준이 모호한 생성물(y)이 아니라, **불변하는 원본(x)**이기 때문이다. 우리는 x→y (순방향 생성)가 잘 되었는지 알 수 없다. 하지만 y→x′ (역방향 복원)을 수행했을 때, x와 x′ 사이의 **거리(Distance)**를 측정하는 것은 수학적으로 명확하다. 여기서 $x \approx x'$이 성립한다면, 중간 과정인 $f(x)$가 정보의 손실 없이 의미를 보존했음을 입증하는 것이다.

• 객관적 검증인 이유:
  • 인간의 개입 없이 $Input(x)$와 Restored(x′) 간의 유사도(Cosine Similarity, Levenshtein Distance)를 계산하여 수치화할 수 있다.
  • 허용 오차(ϵ) 범위 내에 들어오는지(Distance < ϵ)를 판단하는 결정론적 알고리즘이 된다.
• 언제 사용해야 하는가? (The Sweet Spot):
  • Text-to-SQL/Code: 자연어 질문을 SQL로 변환하고, 그 SQL을 다시 자연어로 설명하게 하여 원본 의도와 비교할 때.
  • 번역 및 요약: 한글 → 영어 → 한글로 번역했을 때 의미가 유지되는지 확인할 때.
• 한계 (Limitations):
  • 비가역성(Irreversibility): 요약(Summarization)과 같이 정보 손실이 의도된 작업에서는 원본을 완벽히 복원할 수 없다. (손실된 정보가 의도된 것인지 오류인지 구분 필요)
  • 비용(Cost): 추론을 최소 2번(생성+복원) 해야 하므로 토큰 비용과 대기 시간이 2배로 증가한다.

 

② 메타모픽 테스팅 (Metamorphic Testing)

수학적 원리: f(T(x))=R(f(x)) (변환에 대한 대칭성 및 관계 보존)

정답(y)을 몰라도, 입력(x)이 변했을 때 출력(y)이 어떻게 변해야 하는지 그 **'관계(Relation)'**는 정의할 수 있다. 이는 물리학의 대칭성 원리와 유사하다.

• 객관적 검증인 이유:
  • 출력값의 절대적인 정확성은 따지지 않지만, 입력 변화에 따른 **출력의 변화 양상(기울기, 순서, 집합 관계)**이 논리적 규칙을 따르는지 True/False로 판별한다.
• 언제 사용해야 하는가?:
  • 검색 및 추천 엔진: "강남 맛집"의 결과 집합(A)은 "강남 고기 맛집"의 결과 집합(B)을 포함해야 한다(A⊇B).
  • 경로 탐색: "A에서 B로 가는 최적 경로"의 거리는 "B에서 A로 가는 최적 경로"와 같거나 비슷해야 한다.
  • 랭킹 시스템: 데이터의 가중치를 2배로 늘리면, 점수도 선형적으로 증가하거나 순위가 유지되어야 한다.
• 한계:
  • 관계 정의의 어려움: 도메인에 맞는 적절한 메타모픽 관계(Metamorphic Relation)를 찾아내는 것 자체가 고난이도 엔지니어링이다.
  • 일관된 오류(Consistent Error): 모델이 모든 입력에 대해 일관되게 틀린 답을 내놓을 경우(예: 모든 계산 결과에 +1을 함), 관계는 유지되므로 테스트를 통과해버리는 '위음성(False Negative)' 가능성이 있다.

 

③ 형식 검증과 제약 조건 (Formal Verification & SAT Solver)

수학적 원리: ∀y,Constraints(y)=True (논리적 충족 가능성 증명)

확률적 AI 모델의 출력을 결정론적 논리(Logic)의 틀에 가두는 방법이다. 답이 '최적'인지는 몰라도, 적어도 **'물리적/논리적으로 불가능한 답'**은 아님을 수학적으로 보장한다.

• 객관적 검증인 이유:
  • Z3 Solver와 같은 수학적 도구를 사용하여, 생성된 결과물이 제약 조건을 위배하는지(UNSAT)를 100% 확실하게 잡아낸다. 여기에는 오차가 존재하지 않는다.
• 언제 사용해야 하는가?:
  • 스케줄링/자원 할당: "한 직원이 동시에 두 장소에 존재할 수 없다", "예산의 총합은 100을 넘을 수 없다"와 같은 하드(Hard) 제약 조건이 있는 경우.
  • 보안 프로토콜: 생성된 코드가 메모리 릭이나 권한 우회 가능성을 가지지 않음을 증명할 때.
• 한계:
  • 구현 복잡도: 자연어 요구사항을 수학적 제약 조건 수식으로 변환하는 과정이 매우 복잡하다.
  • 유효성 vs 정답: "규칙을 어기지 않았다"는 것이 곧 "가장 좋은 답"임을 보장하지는 않는다. (예: 근무표를 짰는데 규칙은 다 지켰지만, 효율성이 엉망인 경우)

 

④ 속성 기반 테스팅 (Property-Based Testing)

수학적 원리: ∀x,Invariant(f(x)) (불변식 검증)

구체적인 예시값(Example) 대신, 무작위로 생성된 수많은 입력에 대해 시스템이 반드시 지켜야 할 **'성질(Property)'**이 깨지지 않는지 확인한다.

• 객관적 검증인 이유:
  • 개발자가 예시를 선택하는 주관을 배제하고, 프레임워크(Hypothesis 등)가 엣지 케이스를 무작위로 주입한다.
  • 검증 기준이 '특정 값'이 아니라 '절대적 불변식(Invariant)'이므로 판정이 명확하다.
• 언제 사용해야 하는가?:
  • 데이터 파이프라인: 어떤 데이터를 입력하더라도 출력 데이터의 스키마는 유지되어야 한다.
  • 금융/수치 계산: 환율 계산 결과는 음수가 될 수 없다.
  • 견고성(Robustness) 테스트: 특수 문자, 이모지, 대용량 텍스트를 넣어도 에이전트가 멈추지 않고 응답해야 한다.
• 한계:
  • 약한 속성 문제: "출력은 문자열이어야 한다"와 같이 너무 당연하고 약한 속성만 테스트하면 버그를 잡지 못한다. 의미 있는 강한 속성을 정의하기 어렵다.
  • 오라클 문제: 결과값이 정확히 무엇이어야 하는지 모르는 상태에서 속성만으로 정답을 유추하기엔 한계가 있다.