#오프라인 평가는 전부 통과했는데 왜 프로덕션에서 자주 터지나

← 전체 목차 · 이전: 답은 전부 맞는데 몰래 DB를 지웠다면 — 결과·경로 이중 평가

이 질문은 평가셋을 묻는 것처럼 보이지만 실제로는 "오프라인 지표"와 "프로덕션의 실제 작업" 사이의 간극을 묻는 것이다.

"프로덕션은 트래픽이 더 많으니 데이터를 더 추가하겠다"는 불합격 답변이다. 곧바로 추궁이 따라온다 — 사용자가 변한 것인가, 도구가 변한 것인가, 아니면 평가가 애초에 과정을 측정한 적이 없는 것인가?

답은 하나의 클로즈드 루프다. 오프라인 평가는 회귀와 비교를 담당하고, 프로덕션 모니터링은 분포 변화 발견을 담당하며, 그 사이에 계층화된 작업 세트, 실제 궤적 리플레이, 도구 장애 주입, 안전 게이트를 반드시 보충해야 한다. 하나의 총 성공률로 전체 품질을 대표해서는 안 된다.

#간극의 출처: 실험실 환경 vs 프로덕션 실제 환경

Agent가 마주하는 것은 완전한 시스템이다. 평가가 "입력 → 최종 답변"만 커버하면 프로덕션에서 실제로 무너지는 층을 반드시 놓친다.

#1단계: 지표를 쪼갠다 (안전 일표 부결 포함)

동시에 봐야 할 차원:

• 최종 답변이 정확한가
• 검색이 적중했는가, 도구 파라미터가 정확한가
• 작업이 완수되었는가, 월권했는가, 중복 실행했는가
• 지연과 비용이 초과했는가

가장 강한 판정 규칙:

답변 정확  +  도구 월권 호출   →   실패 판정 (안전 지표 일표 부결)
이유: 안전 결론이 「최종 텍스트」에 가려져서는 안 된다

#2단계: 샘플을 지속 갱신해 평가셋이 프로덕션을 따라 자라게 한다

프로덕션에 새로 나타난 실패 궤적
   → 마스킹
   → 후보 집합에 편입
   → 사람이 확인 + 분류
   → 회귀 테스트에 추가

회귀를 발동시키는 시스템 변경 네 종류: 모델 업데이트, 프롬프트 조정, 도구 버전, 권한 정책. 변경마다 핵심 샘플과 인접 샘플을 돌린다.

핵심 목표: Bad Case 수정이 다른 시나리오를 망가뜨리는 것을 방지한다.

#3단계: 선행 지표를 모니터링한다

많은 실패는 불만이 접수되기 전에 이미 나타나 있다. 사용자 불만만 주시하면 영원히 사후 소방이다.

그리고 슬라이스 분석이 필요하다 — 버전, 테넌트, 작업 유형, 모델 라우팅별로 따로 볼 것이며 총 곡선 하나만 봐서는 안 된다.

#오류 귀인과 회귀 수정 경로

작업 실패를 보고 전부 모델 탓으로 돌리면 안 된다. 버전별로 세 가지를 쪼개서 본다: 입력 분포 / 도구 성공률 / 사람 인계 사유. 쪼개야 수정 경로가 어긋나지 않는다.

프로덕션에서 회귀가 발견되면 실패 샘플을 한 번 다시 돌리는 것으로 끝내지 말 것. 3단계 흐름:

1. 정밀 위치 파악  →  데이터 분포? 도구 응답? 모델 라우팅?
                      (프롬프트, 권한 정책 변화도 포함)
2. 샘플 보충      →  인접 샘플 + 반례 샘플
3. 양방향 검증    →  구 샘플 실행 + 신 샘플 실행
                      「향상」이 다른 작업을 망가뜨리지 않았는지 확인

3단계가 핵심이다. 신 샘플만 돌리면 회귀를 가리고, 구 샘플만 돌리면 수정을 볼 수 없다.

#재현 가능성과 슬라이스 분석

• 작업 컨텍스트와 도구 버전을 보존하지 않으면 같은 실패 샘플을 재현할 수 없고 모든 분석이 공허해진다.
• 분포 변화 분석: 신규 사용자, 신규 도메인, 극단 입력을 따로 볼 것.
• 업데이트 영향 분석: 모델 / 프롬프트 업데이트에 대해 최초 오류 노드와 사람 인계 사유를 비교할 것.

**"최초 오류 노드"**가 이 절에서 가장 실용적인 개념이다. 궤적 전체에서 어디가 틀렸는지가 아니라 처음 틀린 노드만 봐야 진짜 병소를 짚을 수 있다.

#평가의 최종 목적: 채점이 아니라 다음에 어디를 고칠지 지목하는 것

평가는 버전에 점수를 매기는 것만이 아니라 엔지니어링 팀에게 다음에 어느 모듈을 건드릴지 알려줘야 한다. 후보 방향 넷: 검색(Retrieval) / 도구(Tools) / 권한(Auth) / 상태 관리(State).

"다음에 어느 부분을 고칠지"에 답하지 못하는 평가 리포트는 하지 않은 것과 같다.

#배포 절차와 데이터 클로즈드 루프

배포 버전 바인딩(네 버전을 함께 못 박는다): 모델 버전, 프롬프트 버전, 도구 버전, 데이터 버전.

카나리 배포 전략:

1. 먼저 소량 트래픽으로 카나리
2. 신구 버전의 핵심 지표와 실패 궤적 비교
3. 고위험 회귀 발생 → 트래픽 확대를 자동 중단
   (불만이 쌓이기를 기다리지 않는다)

평가셋 관리: 평가셋 자체에 시간 분할과 오염 검사를 해서 모델이 이미 답을 본 상황을 피한다. 프로덕션 샘플링은 마스킹하고 실제 실패를 작업 유형별로 되돌려 붓는다.

#핵심 통찰

1. 오프라인 평가가 재는 것은 "안정적 비교"이지 "출시 안전"이 아니다 — 실험실의 입력 고정·도구 안정·정답 명확 세 가지가 하필 프로덕션에서 가장 성립하지 않는 세 가지다. 오프라인 만점은 "신 버전이 구 버전 대비 퇴보하지 않았다"만 말해줄 뿐 "프로덕션에서 안 터진다"를 말해주지 않는다.
2. Agent의 실패는 대개 "답이 틀린 것"이 아니라 "과정이 틀린 것"이다 — 검색 적중 여부, 도구 파라미터 정확성, 월권 여부, 중복 실행 여부를 봐야 한다. 최종 답변만 보는 평가는 과정성 장애 한 부류를 통째로 통과 판정한다.
3. 안전은 일표 부결 항목이어야 하고 가중 평균에 들어가면 안 된다 — "답변 정확 + 도구 월권 호출"을 실패로 판정하는 것은 안전을 "지표 중 하나"에서 "부결 조건"으로 격상시키는 것이다. 안전 점수가 높은 정확률에 희석되도록 허용하는 평가 체계는 프로덕션에서 사고가 난다.
4. 귀인의 입도가 수정 효율을 결정한다 — "작업 실패율 상승"은 행동할 수 없는 정보다. 입력 분포 / 도구 성공률 / 사람 인계 사유로 쪼개고 다시 "최초 오류 노드"까지 위치를 잡아야 특정 팀에게 배정할 수 있는 정보가 된다. 평가의 산출물은 점수가 아니라 방향(검색/도구/권한/상태 관리)이어야 한다.
5. 수정은 반드시 양방향 검증을 거쳐야 하며, 그렇지 않으면 수정 자체가 회귀의 원천이다 — 실패 샘플만 돌리면 고쳤다고 착각하고, 인접 샘플과 반례 샘플을 보충해 신구 샘플을 함께 돌려야 "Bad Case 하나를 고치고 다른 시나리오를 망가뜨린" 것을 발견한다.
6. 선행 지표의 가치는 시간차에 있다 — 재시도 횟수, 도구 거절, 거부 응답률, 궤적 길이, 사람 인계, 근거 인용은 사용자 불만보다 먼저 움직인다. 불만을 알람 신호로 삼는 것은 발견 시점을 손실이 이미 발생한 뒤로 미루는 것이다.
7. 재현 불가능한 실패는 실패 기록이 없는 것과 같다 — 작업 컨텍스트와 도구 버전 보존이 모든 회귀 작업의 전제다. 이것이 없으면 샘플이 회귀 집합에 들어가도 당시의 그 실패를 재현할 수 없다.
8. 믿을 수 있는 평가에는 데이터 위생이 필요하다 — 시간 분할과 오염 검사는 "모델이 이미 답을 본" 부류의 위양성을 겨냥한다. 평가셋은 프로덕션 되돌림과 함께 계속 커지고 오염 리스크도 함께 커지므로 위생 검사는 상시화되어야 한다.

#엔지니어링 실전 Tips

• 하나의 총 성공률로 전체 품질을 대표하지 말 것: 총 성공률은 과정 오류·월권·비용 초과 세 부류를 동시에 가려주는, 심사는 가장 쉽게 통과하면서 가장 쓸모없는 지표다.
• 안전 지표는 별도 출구로: "월권 호출"을 감점 항목이 아니라 하드 실패 비트로 만들어 최종 텍스트의 정확성에 가려지지 않게 할 것.
• 최초 오류 노드가 전체 궤적 diff보다 우선: 모델이나 프롬프트를 업데이트한 뒤에는 처음 틀린 노드를 비교하는 편이 궤적 전체를 비교하는 것보다 병인을 빠르게 짚는다.
• 인접 샘플 + 반례 샘플은 기본 사양: 실패 샘플 자체만 보충하면 수정이 그 케이스 하나에 과적합된다.
• 알람은 선행 지표 위에 세우고 불만 위에 세우지 말 것: 불만은 후행 지표이며, 많은 실패는 불만보다 먼저 나타난다.
• 슬라이스 차원을 미리 정해둘 것: 버전, 테넌트, 작업 유형, 모델 라우팅. 집계 곡선은 평온한데 특정 테넌트는 이미 무너져 있는 것이 가장 전형적인 미보고 형태다.
• 카나리에 자동 제동을 달 것: 고위험 회귀 시 트래픽 확대를 자동 중단해야지, 사람이 불만 건수를 지켜보며 판단하게 하면 안 된다.
• 답변 순서: 오프라인은 안정적 비교용, 프로덕션은 실제 궤적·분포 모니터링·작업 계층화로 새 문제 발견 → 결과·과정·안전·비용·지연을 함께 평가 → 프로덕션에서 확인된 실패 케이스를 회귀 집합에 편입 → 평가 통과는 출시 통행증이 아니다.