본문으로 건너뛰기

3부: 빌드 검증

진짜 엔지니어링을 하는지, 아니면 단순히 도박을 하는지를 가르는 기준선이 있습니다. 출력 결과를 어떻게 검증하느냐입니다. "실행해 봤더니 잘 되는 것 같다"가 답이라면, 아무리 정교한 프롬프트를 사용하더라도 그것은 바이브 코딩입니다. 검증은 AI 출력을 프로덕션 수준에서 신뢰할 수 있게 만드는 규율입니다.

두 가지 메커니즘이 함께 작동합니다. 테스트는 결정론적인 부분을 다루고, 평가(evals)는 그렇지 않은 부분을 다룹니다.

테스트: 결정론적 계약

테스트는 특정 입력이 반드시 특정 출력을 만들어야 하는 시스템의 부분을 검증합니다. 어차피 작성해야 할 테스트와 동일하지만, AI 워크플로우에서는 두 번째 역할이 추가됩니다. 어떤 프롬프트보다 정확하게 에이전트에게 의도를 전달합니다.

테스트는 기계가 검사할 수 있는 명세입니다. 에이전트에게 실패하는 테스트와 "이것을 통과시켜라"를 건네면, 명확한 목표와 함께 완료 시점을 스스로 알 수 있는 수단을 준 것입니다. 그러므로 먼저 작성하십시오.

def test_refund_over_threshold_requires_approval():
charge = make_charge(amount=600_00)
with pytest.raises(ApprovalRequired):
refund_service.issue(charge.id, amount=600_00, approved_by=None)

def test_refund_writes_ledger_entry():
charge = make_charge(amount=50_00)
refund_service.issue(charge.id, amount=50_00, approved_by="alice")
assert ledger.last_entry().type == "refund"

이제 에이전트는 임계값 규칙과 원장 요구사항을 산문으로 설명받지 않아도 알 수 있습니다. 테스트 자체가 설명입니다.

평가: 비결정론적 부분 판단하기

에이전트 동작의 상당 부분은 결정론적이지 않기 때문에 테스트만으로는 모든 것을 다룰 수 없습니다. 에이전트가 답에 이르는 합리적인 경로를 취했습니까? 올바른 도구를 선택했습니까? 최종 출력이 문법적으로 유효한 것을 넘어 실제로 좋은 결과입니까? 이것이 바로 **평가(evals)**가 측정하는 것입니다.

평가는 레이블이 붙은 데이터셋, 채점 루브릭, 그리고 때로는 판정자 역할을 하는 모델을 통해 수행됩니다. 두 가지 유형이 있으며, 둘 다 필요합니다.

  • 출력 평가 — 최종 결과물을 판정합니다. 코드가 컴파일됩니까? 테스트가 통과됩니까? 요약이 정확합니까?
  • 궤적 평가어떻게 도달했는지를 판정합니다. 에이전트가 적절한 순서로 올바른 도구를 호출했습니까, 아니면 우연히 통과 결과를 얻었습니까?

궤적은 보이는 것보다 훨씬 중요합니다. 검증 단계를 건너뛰고 나온 유창한 출력은 명백한 오류가 있는 출력보다 위험합니다. 위험을 숨기기 때문입니다. 테스트 스위트를 무시하면서 우연히 올바른 코드를 만들어낸 에이전트는 결국 같은 방식으로 잘못된 코드를 만들어낼 것입니다.

구체적인 평가 루브릭

문서에서 질문에 답변하는 에이전트에 대한 평가 세트는 케이스 목록과 루브릭으로 구성됩니다.

- question: "How do I rotate an API key?"
must_mention: ["settings page", "revoke old key", "24h grace period"]
must_not: ["email support"] # we have self-serve rotation now
tool_path: ["search_docs"] # should retrieve, not answer from memory

- question: "What's the refund window?"
must_mention: ["30 days"]
tool_path: ["search_docs"]

각 실행마다 점수를 매깁니다. 필수 사실을 언급했습니까, 금지된 내용을 피했습니까, 예상 도구 경로를 따랐습니까? 모델 판정자는 여러분이 작성한 루브릭을 기준으로 "이 답변이 명확하고 정확한가"라는 더 유연한 차원을 평가할 수 있습니다. 핵심은 "좋음"이 이제 명시적으로 정의되고 자동으로 검사된다는 것입니다. 눈으로 대충 확인하는 것이 아닙니다.

품질 플라이휠

테스트와 평가는 복리처럼 쌓이는 루프에 연결될 때 진정한 가치를 발휘합니다.

  1. 평가 — 벤치마크 스위트에 대해 평가합니다.
  2. 진단 — 개별 실패를 수정하는 것이 아니라 근본 원인으로 클러스터링하여 실패를 진단합니다.
  3. 최적화 — 클러스터의 원인이 된 프롬프트, 규칙, 또는 도구를 최적화합니다.
  4. 검증 — 수정 사항이 유지되도록 회귀 스위트에 대해 검증합니다.
  5. 모니터링 — 새로운 실패 패턴을 찾기 위해 프로덕션 트래픽을 모니터링하고, 이를 1단계로 피드백합니다.

이 루프를 한 번 돌릴 때마다 다음 루프는 더 높은 기준선에서 시작됩니다. 이것이 모델 자체를 변경하지 않고도 에이전트가 시간이 지남에 따라 안정적으로 개선되는 방법입니다.

자신만의 워크플로우 구성하기

  • 다음 기능 개발 시, 에이전트가 코드를 생성하기 전에 먼저 테스트를 작성하십시오.
  • 관심 있는 에이전트 동작 하나에 대해 소규모 평가 세트를 구축하십시오. 열 개의 케이스만으로도 충분합니다.
  • 각 평가 케이스에 대해 출력이 반드시 포함해야 할 내용과 예상 도구 경로를 모두 정의하십시오.
  • 모든 수정 사항을 재실행하는 회귀 스위트를 추가하십시오.
  • 이번 주 프로덕션 실패 하나를 골라 근본 원인 클러스터를 찾고, 증상이 아닌 원인을 수정하십시오.