AI 에이전트를 위한 섀도 배포(Shadow Deployments): 프로덕션 환경을 망치기 전에 프롬프트 변경 사항을 카나리(Canary)

에이전트를 배포했습니다. 평가(Evals) 결과는 녹색(Green)이었습니다. 일주일 후, 당신은 하나의 짜증 나는 엣지 케이스(edge case)를 해결하기 위해 시스템 프롬프트(system prompt)를 수정했습니다. CI 평가 스위트(eval suite)를 통과했고, 머지(merge)했습니다. 그리고 다음 날 아침, 고객 지원 대기열은 불타오르고 있습니다. 에이전트가 이전에는 처리하던 정당한 요청의 절반을 거부하기 시작했기 때문입니다.

이것은 아무도 이야기하지 않는 부분입니다: 머지 전 평가(pre-merge eval)를 통과하는 것이 프로덕션(production) 환경에서 변경 사항이 안전하다는 것을 아는 것과 같지는 않습니다. 당신의 평가 스위트는 당신이 작성하기로 생각했던 케이스들을 채점합니다. 프로덕션에는 당신이 생각하지 못한 케이스들이 있습니다. 이 두 세트 사이의 간극이 바로 에이전트의 변경 사항이 실패하는 지점입니다.

해결책은 "더 많은 테스트를 작성하는 것"이 아닙니다. 웹 인프라(web infra)가 15년 동안 보유해 왔지만 에이전트 팀은 거의 사용하지 않는 것을 빌려오는 것입니다: 바로 **섀도 배포(shadow deployments)와 카나리 평가(canary evals)**입니다.

에이전트 팀이 건너뛴 배포 모델

일반적인 서비스를 배포할 때, 당신은 트래픽의 100%를 새 버전으로 전환하고 기도하지 않습니다. 카나리(canary)를 실행합니다 — 1%, 그다음 5%, 그다음 25% — 그리고 각 단계에서 에러율(error rates), 지연 시간(latency), 포화도(saturation)를 관찰합니다. 새 버전에서 퇴보(regress)가 발생하면, 대부분의 사용자가 접하기 전에 중단하고 롤백(roll back)합니다.

에이전트 팀은 이 과정을 완전히 건너뛰었습니다. 전형적인 에이전트 "배포"는 다음과 같습니다: 프롬프트 수정, 오프라인 평가(offline evals) 실행, 머지, 전체 배포(full rollout). 카나리로 삼을 만한 명확한 지표가 없기 때문에 카나리 단계가 없습니다. HTTP 500 에러는 쉽습니다. "에이전트의 답변이 미묘하게 나빠졌다"는 쉽지 않습니다.

하지만 측정은 가능합니다 — 만약 당신이 두 가지를 함께 연결해 두었다면 말이죠: 지속적으로 **출력 품질을 점수화(score output quality)**하는 방법, 그리고 나쁜 점수가 미스터리하게 남지 않고 디버깅 가능하도록 각 답변이 정확히 어떻게 생성되었는지 확인하는 방법입니다. 그것이 바로 agent-eval과 AgentLens가 나중에 덧붙이는 두 개의 별개 도구가 아니라, 하나의 단위로 출시된 전체적인 이유입니다.

• agent-eval은 에이전트의 _출력(output)_을 점수화하고 게이트(gate) 역할을 합니다: 결정론적 검사(deterministic checks), 베이스라인 대비 드리프트 탐지(drift detection), 환각/근거 확인(hallucination/grounding checks). 즉, "이 답변이 좋은가?"라는 질문에 답합니다.
• AgentLens는 그 답변이 어떻게 생성되었는지에 대한 _트레이스(trace)_를 캡처합니다 — 모든 모델 호출(model call)과 도구 단계(tool step), 해결된 입력값(resolved inputs), 가공되지 않은 출력값(raw outputs). 즉, "왜 답변이 이런 식으로 나왔는가?"라는 질문에 답합니다.

트레이스(trace)가 없는 카나리 점수(canary score)는 새 버전이 더 나쁘다는 것은 알려주지만, 어디가 나쁜지는 알려주지 않습니다. 점수가 없는 트레이스는 무슨 일이 일어났는지는 알려주지만, 그것이 중요한지는 알려주지 않습니다. 동일한 요청에 대해 두 가지가 모두 필요합니다. 그렇지 않으면 카나리 테스트는 그저 퍼센트 기호가 붙은 '느낌(vibe)'에 불과할 뿐입니다.

섀도 모드(Shadow mode): 실제 트래픽으로 사용자에게 서비스를 제공하기 전에 새 버전을 평가하세요

가장 저렴하고 안전한 첫 번째 단계는 **섀도 배포(shadow deployment)**입니다. 실제 프로덕션 요청을 가져와 현재의 에이전트(champion)와 새로운 에이전트(challenger) 모두에 실행하되, 사용자에게는 챔피언의 답변만 반환합니다. 챌린저는 어둠 속에서 실행됩니다. 두 에이전트 모두를 agent-eval로 점수화하고, AgentLens로 트레이스하며, 사용자 리스크 없이 실제 트래픽을 기반으로 비교합니다.

import { evaluate } from "agent-eval";
import { trace } from "agentlens";

...

수천 개의 실제 요청에 대해 하루 동안 이를 실행하면, 오프라인 스위트(offline suite)가 절대 제공할 수 없는 것을 얻게 됩니다: 즉, 당신의 상상이 아닌 _당신의 실제 트래픽_에 대한 챌린저의 점수 분포입니다. 챌린저가 특정 구간(예: 다단계 도구 요청)에서 성능이 저하될 때, 당신은 그것에 대해 논쟁할 필요가 없습니다. 해당 요청 ID에 대한 AgentLens 트레이스 쌍을 추출하여 두 실행이 정확히 어느 지점에서 갈라졌는지 확인하면 됩니다: 어떤 도구가 다른 입력을 받았는지, 어떤 모델 단계에서 성능 저하(regression)가 발생했는지를 말입니다.

카나리(Canary): 달력이 아닌 점수 게이트(score gate)를 기준으로 승격시키세요

섀도 모드를 통해 챌린저가 최소한 기존만큼 좋다는 것이 확인되면, 실제 트래픽의 작은 일부를 처리하도록 허용합니다. 이때 승격(promotion) 여부는 "일주일이 지났고 아무 일도 터지지 않았다"가 아니라, 실시간 점수를 기준으로 게이트를 통과해야 합니다.

interface CanaryGate {
stage: number; // 현재 트래픽 비율
minScore: number; // 도전자가 유지해야 하는 최소 점수
...
}

중요한 세부 사항은 다음과 같습니다. 모든 롤백(rollback) 결정에는 실패한 challengerTraceId 세트가 첨부됩니다. 게이트는 단순히 '아니오'라고 말하는 것이 아니라, '아니오'를 유발한 정확한 트레이스들을 제공합니다. 이것이 바로

실제 트래픽을 대상으로 새로운 버전을 섀도 배포(Shadow deployment)하세요. 프로모션(Promotion) 여부는 달력이 아닌 실시간 점수(Live score)를 기준으로 결정해야 합니다. 그리고 모든 점수가 해당 점수를 생성한 트레이스(Trace)와 결합되어 있는지 확인하세요. 즉, 변경 사항이 안전한지 알려주는 agent-eval과 그 이유를 알려주는 AgentLens가 함께 있어야 합니다. 왜냐하면 디버깅할 수 없는 카나리(Canary) 테스트는 결국 동일한 회귀(Regression)를 더 느린 방식으로 배포하는 것에 불과하기 때문입니다.