'데모에서 잘 됐으니 배포하자.' 팀이 AI 에이전트를 프로덕션에 올리기 전에 가장 자주 하는 실수가 이것이다. 최종 답변이 그럴듯하면 통과, 틀리면 재시도—이게 전부인 팀이 생각보다 많다. 문제는 AI 에이전트의 실패가 명시적이지 않다는 것이다. 함수가 반환값을 뱉는지 확인하는 유닛 테스트로는 출력이 사실과 다르거나, 톤이 틀렸거나, 핵심 단계가 빠져 있는지를 검출할 수 없다. 그리고 배포 이후에 그걸 발견하면, 디버깅할 증거조차 남아 있지 않을 수 있다.
이 글은 그 간극을 메우기 위한 3층 검증 구조를 다룬다. 1층: LLM Eval 파이프라인(출력 품질 검증), 2층: 관찰성 기반 릴리스 게이트(행동 추적 검증), 3층: 비용 실측(운영 지속 가능성 검증). 세 층이 동시에 설계되어야 비로소 '에이전트가 믿을 만하다'는 말을 팀 안에서 근거 있게 할 수 있다.
1층: LLM Eval 파이프라인—출력이 '맞는가'를 자동으로 판단하라
dev.to에 공개된 LLM Eval 파이프라인 구축 가이드(2026)는 AI 테스팅이 기존 소프트웨어 테스팅과 왜 다른지를 명확히 짚는다. 온도(temperature) 기반 비결정성 때문에 동일한 입력이 매번 다른 유효한 출력을 만든다. 문자열 일치는 무의미하다. '파리는 프랑스의 수도다'와 '프랑스 수도는 파리다'는 의미상 동일하지만 string match로는 다르다. 모델이나 프롬프트가 조금만 바뀌어도 품질이 서서히 떨어지는데, 이건 규모가 커져야 표면에 드러난다.
이 가이드가 제안하는 Eval은 세 종류다. 휴리스틱 Eval은 JSON 유효성, 단어 수, PII 포함 여부 같은 측정 가능한 속성을 검사한다. 빠르고 객관적이어서 PR마다 돌리는 회귀 게이트로 적합하다. LLM-as-Judge는 두 번째 LLM이 rubric에 따라 출력을 채점한다. 코드로 판단하기엔 너무 주관적이고, 수동 리뷰하기엔 양이 너무 많을 때 쓴다. 휴먼 Eval은 ground truth다. 골든 데이터셋을 만들고, LLM 심사자를 캘리브레이션하고, 주요 릴리스 전 최종 판단에 사용한다.
실행 전략은 간단하다. 프로덕션에서 실제 요청 100개를 뽑고, 그 중 50개를 수동으로 검토해 ground truth 베이스라인을 만든다. 여기에 엣지 케이스와 어드버서리얼 프롬프트를 포함한 500~1000개 규모의 골든 데이터셋을 구성하고, 분기마다 갱신한다. GitHub Actions에 eval 하네스를 붙여 pass rate가 90% 아래로 떨어지면 배포를 차단한다. PR마다 휴리스틱 테스트, 야간에 LLM-judge 전체 eval을 돌리는 것이 현실적 시작점이다. 도구로는 오픈소스 PromptFoo(YAML 기반, CLI 내장)와 호스팅 플랫폼 Braintrust 중 팀 상황에 맞게 선택하면 된다. 한 가지 주의할 점: Anthropic과 OpenAI는 모델을 조용히 업데이트한다. 코드 변경이 없어도 정기적으로 전체 eval을 돌려야 provider drift를 잡을 수 있다.
2층: 관찰성 기반 릴리스 게이트—'올바른 답'이 '올바른 경로'를 보장하지 않는다
Eval 파이프라인이 출력의 품질을 검증한다면, 2층은 에이전트가 그 출력에 도달하는 과정이 신뢰할 수 있는지를 검증한다. dev.to에 공개된 TraceGate 프로젝트가 이 문제를 정면으로 건드린다. 개발자는 환불 질문에 답하고, 정책 툴을 호출하고, 프롬프트 인젝션을 피하는 서포트 에이전트를 만들었다. 데모는 통과했다. 그런데 스스로에게 물었다. "이 에이전트가 프로덕션에서 실패하면, 나는 실제로 무슨 일이 있었는지 알 수 있을까?"
그 질문의 답이 없었다. 툴이 세 번 재시도하고도 성공한 답을 반환할 수 있다. LLM 호출이 비용 메타데이터 없이 일어날 수 있다. 프롬프트 인젝션 테스트가 통과해도, 어떤 안전 경로가 사용됐는지 흔적이 없을 수 있다. 이것들은 제품 실패가 아니다. 관찰성 실패다. TraceGate는 이 문제를 다루기 위해 OpenTelemetry와 SigNoz를 기반으로 에이전트 릴리스 게이트를 구현했다.
핵심 개념은 관찰성 계약(observability contract)이다. YAML로 정의한 계약에는 필수 스팬, 필수 어트리뷰트, 비용 예산, 레이턴시 P95, 툴 재시도 최대 횟수가 명시된다. 에이전트가 시나리오를 실행하면 OpenTelemetry가 스팬을 기록하고, SigNoz가 텔레메트리를 수집하며, TraceGate가 계약을 평가해 통과/차단을 결정한다. 데모에서는 trace.lookup 툴이 세 번 재시도했는데 계약 한도는 1회였다—릴리스가 차단되고, 그 이유가 명시됐다. '내 머신에서는 됐는데'가 아니라, 체크리스트로 검증하는 구조다.
이 접근이 중요한 이유는 에이전트 신뢰를 두 개의 질문으로 분리하기 때문이다. "에이전트가 기대한 결과를 만들었는가?"(Eval 파이프라인의 영역) vs "에이전트가 그 결과를 디버깅하기에 충분한 증거를 남겼는가?"(관찰성 게이트의 영역). 두 질문에 모두 Yes를 받아야 배포 가능하다. 현재 TraceGate는 GitHub Actions 통합이 없지만, 개발자는 이를 다음 버전 우선순위로 명시했다—에이전트 릴리스 게이트가 CI에 들어가는 것이 자연스러운 종착점이다.
3층: 비용 실측—구독 선택 전, 팀의 에이전트 워크플로우를 먼저 정의하라
3층은 운영 지속 가능성이다. 에이전트가 품질과 추적 가능성을 모두 통과해도, 비용 구조가 맞지 않으면 프로덕션에서 오래 살아남지 못한다. 2026년 AI 구독 시장을 분석한 케이스 스터디는 이 판단이 생각보다 복잡하다는 것을 보여준다.
요약하면 이렇다. Cursor Ultra는 월 200달러에 API 가격 기준 약 400달러 상당의 모델 사용량을 제공해 측정 가능한 인퍼런스 풀 기준으로 가장 크다. GitHub Copilot Max는 100달러 플랜에 200달러 크레딧을 명시해 투명성이 가장 높다. Claude Max, ChatGPT Pro는 실질적 가치는 크지만, 상대적 배율이나 쿼터 방식으로 표현돼 정확한 달러 환산이 어렵다. OpenRouter는 구독 없이 수백 개 모델에 종량제로 접근하는 구조로, 에이전트 실험 단계나 비용 예측이 중요한 팀에게 유리하다.
팀 입장에서 실용적인 판단 기준은 하나다. 어떤 구독이 '가장 많은 크레딧'을 주는가가 아니라, 우리 팀의 에이전트 워크플로우에서 실제로 소비되는 토큰 패턴이 어디와 맞는가다. 자율 에이전트를 많이 돌린다면 Devin이나 Cursor Ultra의 에이전트 실행 용량을, 코드 리뷰와 PR 자동화가 주라면 GitHub Copilot Max의 크레딧 투명성을, 멀티모델 실험이 잦다면 OpenRouter의 종량제를 기준으로 평가해야 한다. 구독을 고르기 전에 팀의 에이전트 사용 패턴을 먼저 측정하는 것이 순서다.
3층 구조를 팀 워크플로우에 심는 법
세 층을 개념으로만 갖고 있으면 소용없다. CI/CD 파이프라인에 실제로 심어야 한다. 현실적인 순서는 이렇다.
1주차: 프로덕션 로그에서 실제 요청 100개를 추출하고, 50개를 수동 검토해 ground truth를 만든다. 휴리스틱 Eval 하나(JSON 유효성이나 필수 필드 존재 여부)를 PR 게이트에 붙인다.
2~3주차: OpenTelemetry를 에이전트 런너에 연결하고, SigNoz(또는 동급 관찰성 백엔드)로 텔레메트리를 수집한다. YAML로 최소 관찰성 계약을 작성한다—필수 스팬, 비용 예산, 재시도 한도 세 가지만 먼저.
4주차 이후: LLM-as-Judge를 야간 eval에 추가하고, 비용 실측 데이터를 기반으로 구독 플랜 적합성을 분기마다 재검토한다.
이 구조가 갖춰지면 팀이 AI 에이전트에 대해 할 수 있는 대화의 수준이 달라진다. '데모에서 잘 됐다'가 아니라 '휴리스틱 pass rate 94%, LLM-judge 91%, 관찰성 계약 7/8 통과, 평균 비용 요청당 $0.004'—이런 숫자로 배포 여부를 논의할 수 있게 된다. AI 에이전트의 신뢰는 선언이 아니라 설계다. 그리고 그 설계는 배포 버튼을 누르기 전에 완성되어 있어야 한다.