500명이 넘는 사용자가 존재하지 않는 정책을 사실로 받아들였다. RAG 기반 고객 지원 어시스턴트가 프로덕션에 나간 직후 벌어진 일이다. dev.to에 공개된 사례에 따르면, 이 팀의 테스트 프로세스는 "질문 5개 던지고, 답변 읽고, 엄지 올리기"가 전부였다. 자동화된 평가는 단 하나도 없었다.
이걸 단순한 실수로 보면 곤란하다. 이건 구조의 부재다. LLM을 프로덕션에 올리는 팀 대부분이 지금도 비슷한 방식으로 움직인다. 모델이 그럴듯한 답변을 내놓으면 "잘 되는 것 같다"고 판단하고 배포한다. 문제는 LLM의 실패가 조용하다는 점이다. 예외를 던지지 않는다. 틀린 정보를 자신 있게 출력한다.
왜 '감 체크'는 프로덕션에서 실패하는가
MMIU나 HellaSwag 같은 학술 벤치마크는 당신의 유스케이스를 말해주지 않는다. 프로덕션 평가가 필요한 건 다른 차원이다. 도메인에 특화된 판단 기준, CI/CD 안에서 돌아갈 수 있는 속도, 프롬프트 한 줄 바꿨을 때 즉시 잡히는 회귀 감지, 그리고 품질을 저하시키는 PR을 머지 전에 막는 게이트. 이 네 가지가 빠진 평가 체계는 결국 "감"이다.
같은 맥락에서 AI 에이전트 워크플로우를 다룬 또 다른 글은 더 날카로운 진단을 내린다. "대부분의 에이전트 프로젝트는 모델이 실패하기 전에 팀이 먼저 실패한다." 실패의 원인은 보통 셋 중 하나다. 불명확한 아웃컴, 과도한 권한을 가진 툴, 반복 가능한 pass/fail 테스트가 없는 데모. 모델 문제가 아니라 설계 문제다.
Judge Ensemble: RAGAS를 넘어선 평가 구조
프로덕션 수준의 LLM 평가 파이프라인은 Golden Dataset에서 출발한다. 1,000개로 시작하지 말라. 실제 프로덕션 케이스 50개로 시작하고, 구성은 이렇게 잡는다. 기본/해피패스 40%, 엣지케이스 30%, 어드버서리얼(인젝션·오프토픽) 20%, 멀티링구얼·롱컨텍스트 10%. 그리고 Git으로 버전 관리한다. 프로덕션 장애가 날 때마다 새 테스트 케이스가 추가된다.
평가 판단은 Judge Ensemble로 설계한다. Faithfulness(답변이 검색된 컨텍스트와 모순되는가), Instruction Following(프롬프트의 제약 조건을 모두 충족하는가), JSON Schema(구조화 출력이 유효한가), Safety(PII·유해 콘텐츠·정책 위반), Domain Expert(의료·법률·금융 정확도). 각 Judge는 임계값을 갖는다. JSON Schema는 1.0, Safety는 1.0, Faithfulness는 0.8. 임계값 아래로 떨어지면 배포가 막힌다.
회귀 감지 로직은 단순하지만 명확하다. 이전 베이스라인 대비 5% 이상 점수가 하락하면 회귀로 판정한다. 2% 이상 오르면 개선으로 기록한다. 이 숫자들을 PR 코멘트로 자동으로 달아주는 GitHub Actions 워크플로우를 붙이면, 팀원은 머지 전에 숫자로 판단할 수 있다. 이 구조를 6개월 운영한 결과가 있다. 할루시네이션 감지율이 인간 리뷰 67%에서 자동화 92%로 올라갔고, 프롬프트 이터레이션 사이클은 2시간에서 15분으로 줄었으며, 프로덕션 인시던트는 월 3건에서 0.2건으로 내려왔다.
에이전트 자율성 이전에 먼저 설계할 것
평가 파이프라인이 LLM 출력을 잡는 구조라면, 에이전트 워크플로우에는 그 전 단계의 설계가 필요하다. 자율성을 추가하기 전 7가지 체크가 필요하다는 가이드는 실용적이다. 핵심만 짚으면 세 가지다.
첫째, 모든 스텝을 세 버킷으로 분리하라. 결정론적 작업(API 호출, 스키마 검증, DB 읽기), 모델 판단(분류, 요약, 초안 작성), 인간 승인(메시지 발송, 결제, 권한 변경, 데이터 삭제). 이 분리가 없으면 장애 위치를 특정하기 어렵고, 모델이 코드로 더 안정적으로 할 수 있는 일을 떠맡게 된다.
둘째, 모든 툴에 타입이 있는 계약을 부여하라. 툴은 막연한 기능이 아니라 API처럼 설계되어야 한다. 입력·출력·에러 타입을 명시하고, 타임아웃과 재시도 규칙, 멱등성을 정의한다. "모델이 알아서 해석하겠지"는 프로덕션에서 통하지 않는다.
셋째, 해피패스 전에 실패 케이스를 5개 먼저 설계하라. 필수 데이터 누락, 두 소스의 모순, 툴 타임아웃, 모델의 구조화 출력 실패, 권한 초과 요청. 각 실패마다 시스템이 재시도하는지, 질문하는지, 에스컬레이션하는지, 정지하는지를 명확히 정의한다. 그리고 그 실패 케이스 10개로 pass/fail 평가 스위트를 만들고, 프롬프트·툴·모델이 바뀔 때마다 돌린다.
런 로그: 평가와 운영을 잇는 고리
평가 파이프라인이 배포 전 품질을 잡는 구조라면, 런 로그는 배포 후 운영을 추적하는 구조다. AI 에이전트 런 로그 설계를 다룬 글은 핵심을 이렇게 정리한다. "채팅 히스토리는 런 원장(ledger)이 아니다." 대화가 있었다는 사실이 아니라, 무엇을 아웃컴으로 약속했는지, 어떤 증거가 그것을 뒷받침하는지, 얼마가 들었는지, 무엇이 실패했는지, 누가 최종 결정을 승인했는지를 기록해야 한다.
이 9개 필드(Run ID, Outcome, Role Shape, Status, Evidence, Direct Cost, Operator Time, Failure/Rework, Decision)는 평가 파이프라인의 메트릭과 같은 역할을 한다. "잘 된 것 같다"를 "어떤 증거로, 누가, 얼마를 써서, 어떻게 결정했다"로 바꾸는 구조다. 릴리즈 게이트도 6가지 조건을 통과해야 한다. 아티팩트 버전 일치, 출처·날짜 명시, 미검증 사실 분리, 민감 데이터 제거, 고우선순위 결함 종결, 인간의 최종 승인.
팀에 이 구조를 심는다는 것의 의미
이 세 가지 흐름—LLM 평가 파이프라인, 에이전트 검증 체크리스트, 런 로그—을 하나로 묶으면 하나의 설계 원칙이 보인다. LLM에 대한 신뢰는 모델 성능에서 오는 게 아니라, 팀이 설계한 검증 구조의 크기만큼만 허용된다.
현실적인 조언을 덧붙이자면, 모든 것을 한 번에 만들 필요는 없다. Golden Dataset 50개, Judge 3개(Faithfulness·JSON Schema·Safety), GitHub Actions 트리거 하나. 여기서 시작하면 된다. 에이전트 검증도 마찬가지다. 첫 마일스톤은 하루 안에 끝낼 수 있어야 한다. 입력 1종, 모델 판단 1개, 읽기 전용 툴 1개, 구조화 출력 1개, 승인 화면 1개, 이벤트 로그 1개. 스웜 오브 에이전트로 시작하지 않는다.
학습 곡선에 대해서도 솔직하게 말하자면, Judge Ensemble 설계와 Golden Dataset 유지는 초기에 공수가 든다. LLM-as-Judge를 쓰면 평가 자체에도 API 비용이 발생한다. 하지만 프로덕션 인시던트 하나가 팀에 미치는 비용—신뢰 손실, 대응 공수, 포스트모템—과 비교하면 계산은 단순하다. 500명에게 틀린 정보를 보낸 뒤 치르는 비용보다, 평가 파이프라인을 미리 설계하는 비용이 훨씬 싸다.
궁극적으로 AI-First 팀의 성숙도는 "얼마나 많은 AI 도구를 쓰는가"가 아니라 "AI 출력물을 얼마나 구조적으로 검증하는가"로 드러난다. 감에서 메트릭으로 전환하는 것, 그것이 AI-First 팀 리빌딩의 가장 실질적인 첫 번째 스텝이다.