첫 주에 발생하는 AI 워크플로우 실패의 대부분은 예상치 못한 일이 아니다. 예측 가능한 일이다. 팀이 출시 전에 그것을 기록하지 않았을 뿐이다.
평가 팩은 그 문제를 해결한다. 평가 팩은 워크플로우가 실제 운영에 투입되기 전에 구성하는, 대표적인 입력값·예상 출력값·합격/불합격 기준의 구조화된 집합이다. 유닛 테스트 스위트가 아니다. 공개 데이터셋 대상 벤치마크도 아니다. 실제 프로덕션 환경을 반영하는 소규모의 의도적인 케이스 모음이다.
구축하는 데 몇 시간이 걸린다. 건너뛰면 며칠이 낭비된다.
평가 팩이란 무엇인가
유닛 테스트는 코드가 올바르게 실행되는지 확인한다. 벤치마크는 표준화된 태스크 대비 성능을 측정한다. 평가 팩은 그 두 가지 중 어느 것도 하지 않는다.
평가 팩은 하나의 질문에 답한다: 이 워크플로우가 실제로 받게 될 입력값에 대해 올바르게 동작하는가?
팩은 각 케이스에 대해 세 가지를 포함한다:
- 입력값: 워크플로우가 처리할 실제적인 프롬프트, 레코드, 또는 문서
- 예상 출력값: 올바른 동작이 어떤 모습인지 — 분류 레이블, 구조화된 필드, 특정 필수 요소가 포함된 요약
- 합격/불합격 기준: 출력값이 적합한지 판단하는 구체적인 규칙
기준은 대부분의 팀이 건너뛰는 부분이다. "충분히 좋다"는 기준이 아니다. "계정 이름과 다음 단계 권고사항을 포함한다"가 기준이다.
올바른 15~20개 케이스를 선택하는 방법
15~20개 케이스가 배포 전 팩에 적합한 규모다. 더 적으면 실제 분산을 놓친다. 더 많으면 팩을 유지하는 비용이 커지고 실행 속도가 느려진다.
목표는 그 케이스들로 프로덕션 분산의 80%를 커버하는 것이다. 찾는 방법은 다음과 같다.
정상 케이스부터 시작하라
모든 필수 필드가 존재하고 입력값이 명확한 케이스 한두 개. 이것이 기준선이다. 워크플로우가 여기서 실패하면 다른 것은 의미가 없다.
엣지 입력값을 추가하라
기술적으로는 유효하지만 비정상적인 입력값. 특수 문자가 포함된 회사명. 예상치 못한 형식의 날짜 필드. 일반적인 것보다 10배 긴 자유 텍스트 필드. 이것들은 취약한 파싱과 프롬프트 민감성을 드러낸다.
누락 필드 케이스를 추가하라
실제 프로덕션 데이터는 불완전하다. 누락될 가능성이 가장 높은 세 개의 필드를 선택하고 각각에 대해 케이스를 하나씩 만들어라. 워크플로우는 해당 필드가 없을 때 정의된 동작이 필요하다 — 크래시도, 환각된 값도 아닌.
모호한 분류 케이스를 추가하라
워크플로우가 분류 결정을 내린다면 — 산업, 의도, 우선순위, 감정 — 카테고리 경계에 위치한 입력값 두세 개를 찾아라. 이것들이 모델의 판단이 가장 중요하고 드리프트가 가장 먼저 나타나는 케이스다.
알려진 적대적 패턴을 추가하라
모든 도메인에는 그런 패턴이 있다. 아웃바운드 영업 워크플로우라면 직함은 "CEO"지만 직원이 두 명인 회사의 연락처 레코드일 수 있다. 문서 처리라면 관련 데이터가 테이블 푸터에 있는 PDF일 수 있다. 배포 후가 아니라 배포 전에 팀으로부터 이것들을 수집하라.
배포 게이트로서 팩 실행하기
평가 팩은 필수일 때만 작동한다. 선택 사항이라면 마감 압박 하에 건너뛰게 된다 — 그것이 가장 중요한 순간이 바로 그때다.
통합은 간단하다. 워크플로우가 프로덕션으로 이동하기 전에 체크리스트 항목으로 평가 실행을 추가하라. 체크리스트 항목에는 두 개의 필드가 있다:
- 기준선 점수: 첫 번째 실행에서 워크플로우가 통과한 케이스의 비율
- 최소 임계값: 출시에 필요한 점수
팩을 실행하기 전에 임계값을 설정하라. 점수를 확인한 후에 설정하면 의미가 없다.
대부분의 워크플로우에 대한 합리적인 시작 임계값은 85%다. 즉 20개 케이스 중 17개가 통과한다는 의미다. 세 개의 실패는 문서화된다 — 반드시 수정하는 것이 아니라 문서화 — 팀이 워크플로우가 아직 처리하지 못하는 것을 알 수 있도록.
실패에 대해 할 일
모든 실패가 배포를 막는 것은 아니다. 일부 실패는 워크플로우가 처리하도록 설계되지 않은 엣지 케이스를 드러낸다. 그것들은 알려진 한계로 기록된다.
일부 실패는 워크플로우가 처리해야 할 케이스에서 잘못되었음을 드러낸다. 그것들은 배포를 막는다.
그 구분은 팩이 실행되기 전에, 팀이 어떤 케이스가 범위 내이고 어떤 것이 범위 외인지 결정할 때 이루어진다. 그 결정은 결과를 해석하는 것이 아니라 팩을 구축하는 것의 일부다.
팩 재실행
팩은 일회성 산출물이 아니다. 프롬프트 변경, 모델 업데이트, 또는 업스트림 데이터 스키마 변경 후에 다시 실행하라. 첫 번째 실행의 기준선 점수가 하한선이 된다. 이후 실행에서 점수가 낮아지면 무언가 회귀한 것이다.
이것이 매번 변경될 때마다 전체 감사를 요구하지 않고 워크플로우를 시간이 지나도 안정적으로 유지하는 피드백 루프다.
운영상의 이점
배포 전에 평가 팩을 구축하는 팀은 프로덕션 문제를 며칠이 아닌 몇 시간 만에 발견한다. 또한 워크플로우가 무엇을 대상으로 테스트되었는지에 대한 구체적인 기록을 갖게 된다 — 이해관계자가 특정 케이스가 왜 특정 방식으로 처리되었는지 물을 때 유용하다.
팩은 완벽한 워크플로우를 보장하지 않는다. 실제 데이터에 닿기 전에 실제 조건에 대해 검증된 워크플로우를 보장한다.
그것은 대부분의 팀이 가진 것과는 다른 출발점이다.
AI 워크플로우를 구축하거나 감사하면서 평가 접근 방식에 대해 다른 시각이 필요하다면, 대화를 시작하세요 →