범용 AI를 특정 업무에 맞게 줄이는 일은 모델 선택보다 품질을 판정하는 기준에서 시작된다. 평가가 안정되지 않은 채 학습을 자동화하면 오류도 함께 강화된다.
일관성과 타당성을 분리하라
Shopify가 Sidekick의 판정 모델을 처음 측정했을 때 코헨 카파는 0.02였다. 사람의 판단과 거의 무관한 수준이었다. 평가 기준을 완성도, 실행, 응답 품질, 안전성으로 나누고 점수별 조건을 정하자 카파는 0.61까지 올랐다. 사람끼리의 일치도는 0.69에 이르렀다.
기준이 모호하면 사람끼리도 판단이 엇갈리고 그 라벨로 만든 보상도 흔들리므로, 자동 평가에서는 정답 자체보다 사람과 비슷한 수준의 일관성을 목표로 삼는다.
그래서 평가에는 별도로 만든 예제보다 실제 대화에서 무작위로 뽑은 GTX(Ground Truth Set, 실제 운영 분포에서 뽑아 정답 기준으로 삼는 평가 세트)가 유용하다. 제품 전문가 최소 3명이 무작위로 뽑은 대화를 검토하고 점수와 근거를 함께 남긴다. 사람 간 판단이 크게 엇갈리는 상태(예: 카파 0.2 안팎)라면 반복 보정을 거쳐야 판정 모델도 안정된다.
또한 평가자는 과거 A/B 테스트의 승패를 재현하고 일부러 성능을 낮춘 모델에는 낮은 점수를 줘야 한다. 단, 높은 일치도가 곧 올바른 판단을 뜻할까. 같은 오류를 반복해도 신뢰도는 높게 나올 수 있다. 그렇다면 일관성과 타당성은 서로 다른 잣대로 나뉜다.
프롬프트로 고칠 수 있는 데까지
툴이 늘면 프롬프트 관리도 어려워진다. 20개를 넘으면 조합이 급증하고 50개 이상에서는 같은 요청을 처리할 경로도 여러 갈래가 된다. Shopify 역시 예외 규칙이 늘어나면서 시스템 프롬프트가 비대해졌다.
해결책은 모든 지시를 처음부터 넣지 않는 것이었다. 툴이 결과를 돌려줄 때 필요한 지시도 함께 전달했다. 덕분에 캐시를 유지하면서 기능 플래그와 모델별 규칙을 바꿀 수 있었다. 결국 지시의 양보다 언제 전달하느냐가 더 크게 작용했다.
그래도 수작업 튜닝이 한계에 닿으면 탐색을 자동화하는 방법도 있다. 에이전트가 프롬프트와 툴 정의, 오케스트레이션(여러 단계와 툴의 실행 순서를 조정하는 구성) 코드를 고치고 평가 점수가 오른 변경만 남기는 방식이다. 이 방법은 Shopify의 Polaris 빌드 시간을 65%, Liquid의 파싱, 렌더 시간을 53% 줄였다.
따라서 지시로 해결되는 문제라면 파인튜닝보다 프롬프트 탐색이 먼저다. 도메인 필드(해당 업무 시스템에서만 쓰는 데이터 항목)의 의미처럼 규칙만으로 익히기 어려운 문제가 반복될 때 가중치 학습을 검토하면 된다. 다만 긴 프롬프트는 매 요청마다 고정 비용을 발생시킨다. Sidekick의 시스템 프롬프트도 약 6,000토큰까지 늘었다.
값싼 검사로 보상 해킹을 막아라
점수가 낮은 대화는 그대로 학습에 넣지 않는다. 여러 추론 모델이 실패 원인을 분석하고 중재 모델이 수정 지시로 정리한 뒤 대화를 다시 실행한다. 재실행 결과가 평가 기준을 통과해야 학습 데이터로 채택된다. 자동으로 고치지 못한 사례만 인간 전문가에게 넘어갔다.
학습은 두 단계로 나뉜다.
- SFT(지도 미세 조정)는 정답 궤적으로 모델을 먼저 학습시키고, GRPO는 여러 응답의 상대 점수를 비교해 더 나은 행동을 강화하는 학습법이다.
- SFT에는 최종 답변뿐 아니라 툴 호출 순서와 중간 판단을 담은 전체 궤적을 쓴다.
- 이후 GRPO에는 보정된 판정 점수를 보상으로 준다.
이 보상은 가중치 갱신에 반영되어 판정 점수가 높은 응답의 확률을 끌어올린다. 새 데이터는 과거 데이터와 섞어야 망각을 줄일 수 있다.
보상에 빈틈이 있으면 모델은 어떻게 반응할까. 지름길을 찾는다. 활성 고객을 찾으라는 요청에 정식 필드 대신 customer_tags CONTAINS 'enabled'를 만든 사례가 대표적이다. 이런 오류는 문법, 스키마, 열거형 검사로 먼저 거르고 통과한 결과만 비싼 판정 모델로 보낸다.
오프라인 점수만으로는 부족하다. 실제로 Shopify Flow 에이전트는 벤치마크에서 프론티어 모델과 비슷했지만 실제 트래픽에서는 워크플로 활성화율이 35% 낮았다. Shopify Flow는 자동화 워크플로를 짜는 데 특정 업무에 맞춰 만든 제한된 프로그래밍 언어인 DSL을 쓴다. 반면 출력 형식을 JSON DSL에서 Python DSL로 바꾸자 구문 정확도는 22점, 의미 정확도는 13점 올랐다. 알고리즘 못지않게 표현 형식과 실제 사용 분포도 결과를 좌우한다. 또한 프로덕션 대화를 학습에 쓰려면 익명화도 먼저 거친다.
트래픽이 임계점을 넘을 때 특화하라
Sidekick의 GraphQL 에이전트는 분당 최대 2,000건을 처리한다. 이 규모에서 프론티어 모델의 연간 추정 비용은 2,700만 달러였지만 자체 모델은 약 100만 달러였고 품질도 더 높았다.
6,000토큰짜리 프롬프트 역시 약 1,500개의 gist 토큰(긴 프롬프트의 핵심을 학습해 담은 요약 토큰)으로 압축했다. 전체 프롬프트를 보는 교사와 gist만 보는 학생의 출력을 맞추자 첫 토큰 지연은 19%, 전체 지연은 38%, 동일 트래픽에 필요한 GPU 대수는 14% 줄었다.
그러나 자체 호스팅이 항상 저렴할까. GPU뿐 아니라 추론 엔지니어와 지속적인 데이터 운영 비용까지 따져야 한다. 채굴, 수리, 학습, 평가를 계속 운영할 팀이 없다면 자체 모델은 금세 낡는다.
전환 조건은 세 가지다.
- 재현 가능한 평가 체계가 있고 프롬프트와 하네스(프롬프트, 툴 정의, 실행 제어 코드를 묶은 에이전트 실행 틀) 최적화가 한계에 닿았으며 비용을 회수할 만큼 트래픽이 많아야 한다.
특히 카파 0.6 이상의 평가 체계가 없으면 모델은 판정 오류부터 학습한다.
다만 이 공정은 문법과 스키마를 자동으로 검사하는 GraphQL이나 DSL에 잘 맞는다. 개방형 상담은 값싼 검증 게이트를 만들기 어렵다. 그래서 프론티어 모델도 사라지지 않는다. 평가와 실패 수리는 프론티어 모델이 맡고 특화 모델은 검증을 통과한 도메인 궤적을 늘려갈 것이다.
이 구조에서 조직의 자산은 특정 모델보다 판정 기준과 수정 이력이 된다. 모델 세대가 바뀌어도 무엇을 실패로 보고 어떻게 고쳤는지는 다음 학습 공정에 남는다.