평가 중심의 에이전트 개발: 파일럿과 프로덕션을 가르는 5가지 규율

데모에서 실행되는 에이전트와 프로덕션(Production)에서 실행되는 에이전트 사이의 격차는 도구의 격차나 모델 능력(Model-capability)의 격차가 아닙니다. 그것은 규율(Discipline)의 격차입니다. 그 격차를 메우는 규율은 평가(Evaluation)이며, 이는 사후적인 QA(Quality Assurance)가 아니라 나머지 작업이 실제로 사용될 수 있을지를 결정하는 운영 관행입니다.

왜 평가가 프로덕션의 차별점이 되었는가

최근 Databricks의 State of AI Agents 2026 보고서(Lovelytics의 실무자 요약을 통해 확인)에 따르면, 체계적인 평가 프레임워크(Evaluation frameworks)를 사용하는 조직은 프로덕션 성공률이 거의 6배 더 높은 것으로 나타났습니다. 실무자 계층에서는 NAV43의 Frase/Graphed 데이터를 통해 마케팅 조직의 90.3%가 스택 어딘가에 AI 에이전트를 보유하고 있지만, 그 에이전트가 프로덕션 워크플로(Production workflows)에 통합된 비율은 약 13%에 불과하다는 것을 보여줍니다. 두 보고서가 지적하는 근본 원인은 성능이 낮은 모델, 프레임워크, 또는 오케스트레이터(Orchestrator)가 아니라, 파일럿에서 프로덕션으로 넘어가는 과정에서 구축, 테스트 및 재테스트 시스템에 대한 규율이 부족하기 때문입니다.

학술적으로는 이를 평가 중심의 개발 및 운영(evaluation-driven development and operations), 즉 문헌상에서 EDDOps라고 부릅니다. 여기서는 실무자가 더 읽기 쉬운 표현인 **평가 주도 에이전트 개발 (evaluation-led agent development)**이라는 용어를 사용하겠습니다. 각 출판물에서 다루는 규율 자체는 서로 수렴하고 있습니다. InfoQ의 5대 기둥 프레임워크 (five-pillar framework), AWS Strands의 Cases/Experiments/Evaluators 패턴, Microsoft의 온라인 및 오프라인 분리(online-and-offline split), 그리고 Arthur AI의 지도 학습 대 비지도 학습 구분(supervised-versus-unsupervised distinction)은 모두 서로 다른 각도에서 동일한 형태를 설명하고 있습니다. 아래에서는 이 모든 기사들 사이의 공통적인 중첩 영역을 더 깊이 파고드는 한편, 이 주제에 대한 저희의 개인적인 관점과 경험을 함께 제시하겠습니다.

추신: 왜 파일럿 단계가 애초에 실패 지점이 되는지에 대해 더 자세히 알고 싶다면, AI 파일럿이 실패하는 이유 (why AI pilots fail)에 관한 저희의 글이 더 넓은 운영 패턴을 다루고 있습니다.

정확도 계층(Accuracy tier)은 모든 것에 영향을 미치는 사전 결정 사항입니다

단 하나의 테스트가 작성되기 전에, 시스템은 사전에 선언된 허용 가능한 실패율(failure rate)을 정의해야 합니다. 이 결정은 다음과 같은 모든 하위 단계의 선택으로 이어집니다.

• 무엇을 통과하는 테스트로 간주할 것인가?
• 판정자(judge)와 인간 사이의 일치도(agreement)가 어느 수준까지 허용 가능한가?
• 어느 지점에서 샘플링 테스트(spot-test sampling)가 전체 범위 테스트(full-coverage testing)를 대체할 수 있는가?

몇 가지 계층 예시는 다음과 같습니다:

• 6-sigma: 금융, 과학, 규제 대상 및 의료 인접 분야를 위한 계층입니다. 실수에 따른 비용이 매우 크거나 되돌릴 수 없습니다. 따라서 정답(ground truth)에 대한 전체 범위 검증(full-coverage validation)이 필요하며, 종종 외부 자료와의 교차 검증(cross-checks)을 포함합니다.
• 4-sigma: 인사(HR), 일반적인 지식 노동, 그리고 대부분의 내부 생산성 에이전트를 위한 계층입니다. 실수의 비용이 실질적이지만 복구 가능합니다. 업무량이 매우 많기 때문에 철저한 전수 조사를 수행하는 것은 경제적이지 않습니다.
• 80% 계층 (80% tier): 인간을 대체하기보다 인간의 생산성을 증강(augment)하도록 설계된 시스템을 위한 계층입니다. 예를 들어, AI가 신규 잠재 고객 프로젝트를 위한 초기 맞춤형 엔지니어링 솔루션을 설정하는 시스템이나, 자동화된 RFP(제안요청서) 응답 시스템이 이에 해당합니다. 시작 단계에서 인간이 할 일의 80%를 완료해 주는 것은 100% 정확할 필요 없이 측정 가능한 상당한 시간을 절약해 줍니다.

최근 고객 프로젝트의 사례를 들어보겠습니다. 우리는 인간이 작성한 코드가 개입되지 않고 엔지니어링 모델을 생성하는 유압 3D 시뮬레이션 시스템을 작업했습니다. 해당 시스템은 sigma-4 수준의 정확도가 필요했으며, 아주 작은 규모에서의 미세한 결함을 제외하고는 어떠한 오류도 발생해서는 안 되었습니다. 따라서 검증 방법은 작은 골드 셋(gold set)을 사용하는 방식이 아니었습니다. Gemini 3.1 Pro를 사용하여 Anthropic의 Opus 시스템 출력을 발표된 동료 검토(peer-reviewed) 문헌과 교차 검증했습니다. 그 후, 모델이 매 생성 시마다 일관성을 유지할 수 있도록 상당한 양의 생성 명령(generation orders)을 수행했습니다. 검증 방법이 계층을 결정한 것이지, 그 반대가 아니었습니다.

계층 선택은 또한 LLM 판사(LLM judge)의 "통과(passing)\

평가는 단순히 출력(output) 단계가 아닌 하네스(harness) 계층에서 이루어져야 합니다

에이전트(agent)는 출력 단계에서 실패하는 것이 아닙니다. 에이전트는 메모리(memory), 도구 호출(tool call), 종료되지 않는 피드백 루프(feedback loop), 또는 차단 임계치(cutoff)를 트리거하지 않는 API 예산(API budget) 등에서 실패합니다. 출력(output)만을 대상으로 하는 평가(eval)는 무언가 고장 났다는 사실만을 알려줍니다. 반면 계층별로 타겟팅된 평가(layer-targeted eval)는 무엇이 고장 났는지 알려주며, 이것이 바로 경고(alert)와 해결책(fix)의 차이입니다.

에이전트 하네스의 구조(anatomy of an agent harness)는 하네스를 실행 샌드박스(execution sandbox), 인증 및 신원(auth and identity), 메모리 및 컨텍스트(memory and context), 도구 호출(tool calls), 오케스트레이션(orchestration), 비용 거버넌스(cost governance), 그리고 관찰 가능성(observability)의 7가지 구성 요소로 나눕니다. 각 요소는 고유한 실패 모드(failure modes)를 가지며, 각기 다른 테스트 표면(test surface)을 가집니다.

이를 실제로 운영하며 발견한 점은, 계층의 이름이 정해지면 테스트 표면이 빠르게 구체화된다는 것입니다. 다음 목록은 저희가 작업을 계획할 때 가장 먼저 떠올리는 테스트 세트입니다:

• 컨텍스트 변화(Context churn) 상황에서의 메모리 회상 (Memory recall). 컨텍스트 윈도우(Window)가 여러 번 재작성되었을 때, 에이전트가 올바른 이전 컨텍스트를 검색해 오나요? 질문과 답변 사이에 관련 없는 대화(Turns)를 주입하여 변화를 합성한 뒤, 검색 정확도를 측정하세요.
• 도구 호출 스키마 준수 (Tool-call schema adherence). 프롬프트의 변동이 있더라도 에이전트가 선언된 스키마와 일치하는 도구 인자(Arguments)를 생성하나요? 기대하는 도구를 항상 호출하나요? 게이트웨이(Gateway)에 도구 호출 린터(Tool-call linter)를 배치하면 도구에 도달하기 전에 드리프트(Drift)를 잡아낼 수 있습니다.
• API 과다 지출 차단 (API overspend cutoffs). 작업당 예산에 도달했을 때 비용 거버넌스(Cost-governance) 계층이 실제로 실행을 중단시키나요? 의도적으로 낮은 한도를 설정하고 차단 기능이 작동하는지 확인하며 테스트하세요. 많은 시스템이 중단 없이 경고만 보냅니다.
• 피드백 루프 종료 (Feedback-loop termination). 에이전트가 정체된 상태(Stuck state)에서 벗어날 수 있나요? 복구 가능한 실패(첫 번째 호출에서는 실패하고 두 번째 호출에서 성공하는 도구)를 주입하여, 에이전트가 루프에 빠지거나 로그에 실패를 남기지 못한 채 멈추는 대신 재시도하여 진행하는지 확인하세요.
• 환각 제어 게이트 (Hallucination control gates). 조작된 출력을 잡아내는 게이트는 어디에 있으며, 알려진 실패 사례에서 제대로 작동하나요? 유사한 시스템에서 환각을 유발하는 것으로 알려진 프롬프트 세트(Held-out set)를 실행하여 게이트가 이를 잡아내는지 확인하세요.
• 권한 및 정책 경계 (Permission and policy boundaries). 에이전트가 권한 범위를 벗어난 동작을 시도할 때 샌드박스(Sandbox)가 올바르게 거부하나요? 권한이 거부되었을 때 에이전트는 어떻게 반응하며, 데스 스파이럴(Death-spiral)에 빠지지는 않나요? 권한 상승을 시도하는 프롬프트를 실행하여 거부 사실이 로그에 남고 표면화되는지 확인하세요.
• 관측 가능성 완전성 (Observability completeness). 모든 프로덕션 상호작용에 대해 트레이스(Trace)를 재구성할 수 있나요? 사후에 실패 원인을 디버깅할 수 없다면, 관측 가능성(Observability) 계층 자체가 평가를 통해 잡아내야 할 실패 모드(Failure mode)를 가지고 있는 것입니다.

이러한 테스트 중 어느 것도 출력(Output) 단계에 머물지 않습니다. 이들은 실패가 발생하는 계층(Layer)에 존재합니다. 출력 수준의 평가(Output-level evals)는 카나리(Canary)로서 유용하게 유지되며, 계층 수준의 평가(Layer-level evals)는 카나리가 드러낸 문제를 팀이 수정하는 방법입니다.

평가 신호가 어디서 오느냐가 주기(Cadence)를 결정합니다

저희의 경험에 따르면, "평가 크론(Evaluation crons)을 얼마나 자주 실행해야 하는가"라는 질문은 대개 잘못된 질문입니다. 저희가 발견한 올바른 질문은 "평가 신호가 어디에서 오는가?"입니다.

• 프로덕션 관측 가능성 (Production observability). 실제 사용 사례는 가장 강력한 평가 신호입니다. 시스템이 유의미한 규모로 사용되고 있다면, 프로덕션 트래픽 자체가 평가 데이터셋(Eval dataset)이 됩니다. Microsoft의 지속적 개선 루프 (Microsoft’s continuous improvement loop)는 이 메커니즘을 설명합니다. 프로덕션의 관측 가능성(Observability) 데이터가 오프라인 실험 및 개선에 정보를 제공하며, 이 루프는 일회성 게이트(Gate)가 아니라 지속적으로 실행됩니다. 지도 학습 기반 평가(Supervised evaluations, 정답이 알려져 있어야 함)와 비지도 학습 기반 평가(Unsupervised evaluations, 에이전트 자체의 컨텍스트만으로 행동을 평가함) 사이의 Arthur AI의 구분 (Arthur AI’s distinction)이 바로 운영 메커니즘입니다. 비지도 학습 기반 평가는 라벨링된 데이터셋(Labeled set) 없이도 모든 프로덕션 상호작용에 대해 실행될 수 있습니다.

• 트리거 기반, 프로세스 내 평가 (Trigger-based, in-process evaluation). 워크플로우의 일부로서 한 에이전트가 이전 에이전트의 출력을 판단합니다. 이는 정해진 시간에 실행되는 것이 아니라 실행(Execution)에 의해 구동됩니다. 볼륨이 크고 중요도가 낮은 작업의 경우 샘플링(Sampling)을 사용해도 괜찮습니다. 이 경우 판단자(Judge)는 실행된 결과의 무작위 비율을 맛보거나(Tastes), 리스크 모델(Risk model)을 사용하여 위험도가 높은 출력을 엄격한 판단 게이트(Strict judge gate)로 라우팅합니다. 저희는 이를 공장에서 볼트를 테스트하는 방식과 유사하게 생각합니다. 배치(Batch)가 양호하다는 것을 알기 위해 모든 볼트를 검사할 필요는 없지만, 추론(Inference)이 방어 가능할 정도로 충분한 양은 검사해야 합니다.

• 크론 기반 평가 (Cron-based evaluation). 프로덕션 관측치(production observation)를 축적할 만큼 충분히 사용되지 않지만, 호출되었을 때 반드시 제 성능을 발휘해야 하는 시스템의 경우 크론(cron)이 대안이 됩니다. 트래픽이 적은 내부 에이전트, 사용 빈도가 낮은 규제 대상 시스템, 그리고 아직 프로덕션 데이터가 존재하지 않는 출시 전 파일럿(pilot) 단계 등이 정기적인 벤치마크 실행이 필요한 구체적인 사례들입니다. 사용자가 문제를 발견하기 전에 실패 모드(failure modes)를 드러내기 위해 시스템을 통해 수천 개에서 수십만 개의 테스트 상호작용을 합성(synthesizing)하는 파일럿 단계의 배치 테스트(batch testing) 또한 좋은 예시입니다. 다만 이는 진정한 의미의 "크론"이라기보다는 온디맨드 방식의 배치(batch-on-demand)에 가깝습니다.

강력한 프로덕션 트래픽을 보유한 시스템은 다른 방식으로 포착되지 않는 정말 중요한 시나리오가 없는 한, 불필요한 합성 크론(synthetic crons)을 실행해서는 안 됩니다. 반면, 프로덕션 사용량이 없거나 거의 없는 시스템은 트리거 기반 평가(trigger-based evals)가 배치 테스트(batch testing)에서만 발견될 수 있는 문제들을 잡아낼 수 있을 것이라고 착각해서는 안 됩니다.

LLM-as-judge가 실패할 때, 그것은 루브릭(rubric)에서 실패한다

AI 시스템의 품질을 테스트하고 평가하기 위해 LLM을 사용하는 것은 좋은 관행입니다. 우리는 이를 LLM-as-judge라고 부르는데, 이는 LLM이 시스템이나 시스템 내의 특정 에이전트가 실수를 저지르지 않는지 판단하기 위해 테스트하기 때문입니다.

판단자(Judge)의 성능은 그 판단자가 기준으로 삼는 루브릭(Rubric, 평가 기준)만큼만 좋습니다. 팀들은 합격/불합격(pass/fail) 정의를 개선하지 않은 채 판단자 프롬프트(Judge prompt)와 판단자 모델(Judge model)만 반복해서 수정하곤 하며, 이로 인해 잘못된 결과는 계속 합격하고 올바른 결과는 계속 불합격하는 상황이 반복됩니다. 실제 현장에서 나타나는 LLM-as-judge의 지배적인 실패 모드(Failure mode)는 모델의 편향(Bias)이 아닙니다. 그것은 실제 실패 사례(Failure cases)를 바탕으로 날카롭게 다듬어지지 않은 합격/불합격 정의입니다. 기준을 정교화하는 것, 즉 시스템이 증명해야 할 사항별로 나누어 특정 테스트 케이스가 무엇을 충족해야 합격으로 간주할지를 구체화하는 것은 프롬프트를 개선하거나 판단자 모델을 교체하는 것보다 훨씬 더 큰 개선을 가져오는 경우가 많습니다.