CI는 통과했지만, 당신의 에이전트는 운영 준비(operator-ready)가 되지 않았습니다.

우리는 지난 분기에 기업 고객에게 문서 추출 에이전트(document-extraction agent)를 인도했습니다. 12주간의 평가(eval)를 거쳤고, 우리의 테스트 스위트(test suite)에서 94%의 통과율을 기록했습니다. 하지만 파일럿 운영 3주 차에, 에이전트는 파싱할 수 없는 인보이스(invoices)에 대해 환불을 생성하기 시작했습니다. 그것도 조용히 말이죠. 에러도 없었고, 흔적도 없었습니다. 그저 정답처럼 보이는 오답을 내놓았을 뿐입니다.

우리의 CI는 내내 초록불(green)이었습니다.

문제는 모델(model)이 아니었습니다. 프롬프트(prompt)의 문제도 아니었습니다. 문제는 우리가 테스트하지 않았던 6%의 입력값들이었으며, 이는 실제 운영자(operator)의 데이터가 우리에게 전달될 때 가장 먼저 마주하게 된 것이었습니다.

이것은 예외적인 케이스(edge case)가 아닙니다. 이것이 실무에서 말하는 '운영 준비(operator-ready)'의 의미입니다.

"프로덕션 준비(production-ready)"와 "운영 준비(operator-ready)"의 차이

프로덕션 준비(Production-ready)는 인프라(infrastructure) 개념입니다. 서비스가 가동 중이고, 부하를 처리하며, 충돌 시 재시작되고, 로그(logs)가 어딘가로 기록되며, 알림(alerts)이 존재하는 상태를 말합니다.

운영 준비(Operator-ready)는 다릅니다. 이는 당신의 에이전트를 그것을 만들지 않은 사람에게 넘겨주었을 때, 당신이 설계하지 않은 데이터로 작동하며, 잘못된 결정을 내렸을 때 실제적인 결과(consequences)를 초래하는 상황에서도 대응할 수 있음을 의미합니다.

이 차이는 매우 중요합니다. 왜냐하면 대부분의 평가 파이프라인(eval pipelines)은 첫 번째 개념(production-ready)을 위해 설계되었기 때문입니다. 이들은 테스트 세트(test set)에 대한 통과율을 측정합니다. 하지만 운영자의 입력 분포(input distribution)가 당신의 테스트 세트와 항상 30% 정도 차이가 날 때 어떤 일이 발생하는지는 측정하지 않습니다.

운영 이관(operator handoffs) 시 문제를 일으키는 세 가지 간극

간극 1. 검증 연극 (Validation theater)

97%의 검증 성공률을 보이는 Pydantic 모델은 좋아 보입니다. 하지만 이것이 무엇을 숨기고 있는지 보십시오.

실패하는 3%: 당신의 에이전트는 무엇을 합니까? 만약 재시도 루프(retry loop)가 누락된 필드를 모델이 추론한 기본값(defaults)으로 채워버린다면, 당신은 '조용한 오답 생성기'를 만든 것입니다. 스키마(schema)는 통과했습니다. 출력값은 틀렸습니다. 그리고 이를 지적할 로그 엔트리(log entry)조차 없습니다.

해결책: "스키마 유효성(schema valid)" 신호와 "콘텐츠 신뢰도(content confidence)" 신호를 분리하십시오. 출력값과 함께 필드 수준의 신뢰도(field-level confidence)를 로그로 남기십시오. 두 신호가 모두 임계값(threshold)을 넘기 전까지는 출력값을 신뢰해서는 안 됩니다.

우리는 모든 추출 응답(extraction response)에 field_confidence 딕셔너리를 추가했습니다. 신뢰도가 낮은 필드는 재시도(retry)를 하는 대신, 사람의 검토(human-review) 플래그를 트리거합니다. 이 조치 하나만으로도 첫 운영 월에 발생한 18건의 사고 중 14건을 잡아낼 수 있었습니다.

간극 2. 적대적 입력 처리 (Adversarial input handling)

당신의 테스트 세트는 당신이나 당신의 팀이 구축한 것입니다. 이는 당신이 생각한 케이스들을 다룹니다. 하지만 운영자(operator)의 데이터는 그들이 당신에게 말해주지 않은 케이스들을 포함합니다.

우리의 경우: 스캔된 PDF가 포함된 다중 페이지 송장(multi-page invoices)이 문제였습니다. 우리의 테스트 스위트(test suite)에는 단일 페이지 송장만 있었습니다. 에이전트는 이를 다르게 처리했으며, 그 "다르게"라는 의미는 우리의 평가(eval)가 전혀 측정하지 못한 방식으로 "틀렸다"는 것을 의미했습니다.

이것은 파싱(parsing) 버그가 아닙니다. 이것은 데이터 분포 변화(distribution shift)입니다. 올바른 대응은 파서를 수정하는 것이 아닙니다. 실제 운영자의 데이터를 샘플로 사용하여 라이브(live)로 전환하기 전에 테스트하는 것입니다.

이제 우리는 어떤 운영자에게 업무를 인계하기 전에, 운영자 고유의 코퍼스(corpus)에서 추출한 50개의 문서를 에이전트에 통과시키고 출력값에 대한 수동 검토(manual review)를 거칠 것을 요구합니다. 합성 데이터(synthetic data)가 아닙니다. 우리의 테스트 세트도 아닙니다. 바로 그들의 데이터여야 합니다.

이 단 한 번의 변화로 파일럿(pilot)이 시작되기 전에 스캔된 PDF 문제를 잡아낼 수 있었습니다.

간극 3. 중요한 것을 기록하지 않는 감사 로그 (The audit log that doesn't log what matters)

모든 엔지니어의 첫 번째 로깅(logging) 설정은 모델이 무엇을 반환했는지를 캡처합니다. 하지만 모델이 무엇을 '하지 않기로 결정했는지'를 기록하는 사람은 거의 없습니다.

컴플라이언스(compliance) 워크플로우 내에 추출 에이전트를 배포하는 운영자에게 질문은 단지 "에이전트가 무엇을 출력했는가"만이 아닙니다. 또한 다음과 같은 질문도 포함됩니다: "에이전트가 이 문서를 낮은 신뢰도로 플래그(flag)했는가", "필드를 건너뛰었는가", "폴백 경로(fallback paths)를 트리거했는가".

추적(trace)을 통해 이러한 질문에 답할 수 없다면, 무언가 잘못되었을 때 운영자를 지원할 수 없습니다. 그리고 무언가는 반드시 잘못될 것입니다.

최소 기능 운영 감사 추적(Minimum viable operator audit trail):

• 필드 수준의 신뢰도 점수(field-level confidence scores)가 포함된 출력값
• 폴백 경로 표시기 (재시도했는가? 성능이 저하되었는가?)
• 입력 해시(input hash) (정확히 동일한 문서를 재현할 수 있도록)
• 추론(inference) 시점의 모델 버전 및 프롬프트(prompt) 버전 (단순히 "gpt-4o"가 아닌, 구체적인 배포 버전)

이 내용을 표준 트레이스 스키마에 포함시켰고 모든 응답에 주입하기 시작했습니다. 오버헤드는 미미합니다. 디버깅 용이성 개선은 상당합니다.

실제로 제가 사용하는 운영자 사전 점검 목록 (The pre-operator checklist I actually use)

에이전트를 어떤 운영자에게 넘기기 전에, 저는 다음 사항들을 확인합니다:

1. 테스트 세트가 아닌, 운영자의 실제 데이터에서 50개 이상의 샘플을 실행합니다. 그들의 코퍼스(corpus)를 대상으로 필드별 오류율을 측정합니다. 만약 그들의 코퍼스 정확도와 여러분의 테스트 세트 정확도 사이에 격차가 있다면, 그 격차가 바로 위험 요소입니다.

2. 지난 30일 동안 스키마 검증은 통과했지만 다운스트림(downstream) 오류를 유발한 출력이 있는지 로그에서 검색합니다. 이것들이 바로 '조용한 실패(silent failures)'입니다. 운영자가 보기 전에 이를 수정해야 합니다.

3. 의도적으로 잘못된 형식의 입력값(malformed inputs)을 제공해 봅니다. 에이전트가 잘못된 출력 대신 안전한 폴백(fallback)으로 저하되는지 확인합니다. '이 문서를 파싱할 수 없습니다'라는 답변은 잘못된 인보이스 총액보다 훨씬 낫습니다.

4. 시간 Y에 문서 X에서 에이전트가 무엇을 했는지 답할 수 있는지 5분 이내로 확인합니다. 만약 할 수 없다면, 감사 추적(audit trail)이 불완전하며 평가 점수와 관계없이 운영 준비 상태가 아닙니다.

5. 에이전트의 권한 범위(permission scope)를 확인합니다. 이 운영자의 사용 사례에 필요하지 않은 리소스에 접근할 수 있는가요? 최소 권한 원칙(principle of least privilege)은 에이전트에게도 적용됩니다.

실제로 중요한 숫자 (The number that actually matters)

저희의 평가 통과율(eval pass rate)은 94%였습니다. 하지만 운영자 인계 오류율(operator-handoff error rate)은 첫 달에 8%였습니다.

이 두 숫자는 서로 다른 데이터에 대해 서로 다른 것을 측정하고 있기 때문에 공존할 수 있습니다.

위의 세 가지 변경 사항(필드 신뢰도, 운영자 코퍼스 테스트, 전체 감사 추적)을 추가한 후, 두 번째 달의 운영자 오류율은 1.4%로 떨어졌습니다. 평가 통과율은 거의 변하지 않았습니다 (95%).

문제가 된 것은 평가 점수 자체가 아니었습니다. 평가 범위(eval scope)가 문제였습니다.

제가 가장 먼저 확인할 것 (What I'd check first)

만약 에이전트를 출시했고 운영자에게 넘기기 직전이라면, 다음의 세 줄 진단 과정을 거치세요:

1. 트레이스(trace)를 보고 "이 입력값에 대해 에이전트가 무엇을 하지 않기로 결정했는가"라는 질문에 답할 수 있습니까? 만약 아니라면, 감사 추적(audit trail)이 불완전한 것입니다.
2. 운영자의 실제 코퍼스(corpus)에서 추출한 문서 최소 50개에 대해 에이전트를 실행해 보았습니까? 만약 아니라면, 당신의 통과율(pass rate)은 테스트 세트 지표일 뿐, 운영 신뢰도 추정치(operator reliability estimate)가 아닙니다.
3. 에이전트가 자신의 스키마(schema)를 벗어난 입력을 받았을 때 어떤 일이 발생합니까? 만약 답변이 "재시도하고 기본값(defaults)을 채운다"라면, 당신은 소리 없는 오답 경로(silent wrong-answer path)를 가지고 있는 것입니다. 이를 "인간의 검토를 위해 플래그를 표시한다"로 변경하십시오.

운영 준비(Operator-ready)는 CI 체크가 아닙니다. 이는 에이전트가 타인의 데이터 위에서 작동하며, 실제적인 결과가 따르는 결정을 내릴 때 어떻게 행동하는지에 대한 주장입니다. 평가 스위트(eval suite)는 당신을 그 근처까지 데려다주지만, 이 세 가지 체크가 당신을 그 목적지에 도달하게 할 것입니다.