💡 원문은 devtocash.com에 게시되었습니다 — 이 가이드가 최신 상태로 유지되는 곳입니다. 저는 그곳에서 매주 실무 중심의 DevOps/SRE 심층 분석 글을 작성합니다.

테스트하지 않은 런북(runbook)을 배포하지 않듯, 평가하지 않은 에이전트도 배포하지 마세요.

당신은 에이전트에게 범위가 제한된 kubectl 액세스를 제공하는 MCP 서버를 구축했습니다. 또한 엄격한 반복 제한이 있는 감독 루프 (supervised loop)로 이를 감쌌습니다. 도구들은 제한되어 있고, 가드레일(guardrails)도 갖춰져 있습니다. 하지만 그 설정과 프로덕션(production) 사이에는 여전히 한 가지 질문이 남아 있습니다: 이것이 실제로 작동하는가, 그리고 다음 주 화요일에 모델 업데이트가 조용히 이를 망가뜨리지는 않을 것인가?

그 답은 평가 하네스 (eval harness) — 즉, 비결정론적 시스템 (non-deterministic system)을 위한 반복 가능한 테스트 스위트입니다. 이것은 운영(ops) 환경에서 LLM 에이전트를 실행할 때 가장 화려하지 않으면서도 가장 핵심적인 부분입니다. 이를 건너뛴다면 모든 프롬프트 수정, 모델 업그레이드, 또는 도구 변경은 눈을 가린 채 진행하는 배포가 될 것입니다. 이 가이드는 DevOps 에이전트를 위한 구체적인 평가 하네스를 구축합니다: 골든 인시던트 시나리오(golden incident scenarios), 에이전트의 문장(prose)이 아닌 '행동(actions)'에 대한 결정론적 점수 산정(deterministic scoring), 절대 실패해서는 안 되는 안전 스위트(safety suite), 그리고 회귀(regression)가 온콜(on-call) 담당자에게 도달하기 전에 차단하는 CI 게이트(CI gate)를 포함합니다.

왜 운영 에이전트는 챗봇보다 평가(evals)가 더 필요한가

약간 더 나쁜 답변을 내놓는 지원용 챗봇은 가벼운 짜증을 유발할 뿐입니다. 하지만 잘못된 배포를 확장하거나, 미리보기만 했을 뿐인 수정 사항을 적용했다고 자신 있게 주장하는 DevOps 에이전트는 인시던트(incident)입니다. 세 가지 특성이 운영 에이전트를 유독 평가에 목마르게 만듭니다:

• 비결정성 (Non-determinism). 동일한 프롬프트라도 실행할 때마다 서로 다른 도구 호출 (tool calls)을 생성합니다. 단 하나의 트랜스크립트(transcript)를 눈으로 훑어보는 것만으로는 테스트가 되었다고 할 수 없습니다. n번 실행하여 통계적으로 점수를 매길 수 있는 스위트 (suite)가 필요합니다.
• 실제 영향 범위 (Real blast radius). 출력값은 단순한 텍스트가 아니라 kubectl scale 명령이나 Terraform PR입니다. 설명의 유창함보다 *행동 (action)*의 정확성이 더 중요합니다.
• 조용한 회귀 (Silent regressions). 모델 제공업체들은 업데이트를 배포합니다. 지난달 모델에서 잘 작동하던 프롬프트가 사용자 측의 코드 변경 없이도 성능이 저하될 수 있습니다. 상시 운영되는 평가 (standing eval)만이 이를 포착할 수 있습니다.

평가하는 단위는 "답변이 좋았는가?"가 아닙니다. "이 클러스터 상태에서 에이전트가 올바른 행동을 취했는가, 잘못된 행동을 피했는가, 그리고 가드레일 (guardrails) 내에 머물렀는가?"입니다.

실제로 측정해야 할 것

운영 관점에서 대략적인 우선순위에 따른 네 가지 차원입니다:

1. 작업 성공 (Task success) — 에이전트가 올바른 최종 상태나 진단에 도달했는가? (CrashLoop을 수정했는가, OOMKill을 식별했는가, 적절한 PR을 생성했는가.)
2. 도구 호출 정확성 (Tool-call correctness) — 올바른 인자 (arguments)와 함께 올바른 도구를 호출했는가? 운 좋게 정답을 맞힌 에이전트는 새벽 3시에 신뢰할 수 있는 대상이 아닙니다.
3. 안전성 / 거부 (Safety / refusal) — 건드려서는 안 될 것을 건드리는 것을 거부했는가, 승인 게이트 (approval gate)를 준수했는가, 그리고 완료되지 않은 변경 (mutation)을 허위로 보고하지 않았는가? 이는 *엄격한 관문 (hard gate)*입니다. 여기서 발생하는 모든 실패는 전체 스위트의 실패로 간주됩니다.
4. 비용 및 지연 시간 (Cost & latency) — 실행당 토큰 사용량과 실제 소요 시간 (wall-clock). 트리아지 (triage) 한 번에 20만 토큰과 3분을 소모하는 정확한 에이전트는 예산 사고를 일으키기 직전의 상태입니다. 파이프라인에 대한 DORA 지표 (DORA metrics)를 추적하는 것과 동일한 방식으로 이를 추적하세요.

실제 인시던트로부터 골든 시나리오 구축하기

최고의 평가 케이스는 여러분의 사후 분석 (postmortems) 결과물입니다. 해결된 인시던트를 가져와서, 해당 인시던트를 발생시킨 클러스터 상태를 고정(freeze)하고, 기대되는 에이전트 행동을 인코딩하세요. 시나리오는 느낌(vibe)이 아니라 고정된 환경(fixture)이어야 합니다:

# scenarios.py — 각 케이스는 고정된 상황 + 올바른 행동에 대한 루브릭 (rubric)입니다
SCENARIOS = [
    {
...

각 케이스는 에이전트가 해야 하는 행동(k_scale_preview)과 절대로 해서는 안 되는 행동(k_apply_approved를 사람 없이 수행하는 것)을 모두 고정하고 있다는 점에 주목하세요. 금지 목록(forbidden list)이 바로 안전성(safety)이 존재하는 지점입니다. 이는 실제 오류 수정 플레이북(error-fix playbooks)을 반영합니다. 예를 들어, ImagePullBackOff 수정 사례는 단순한 블로그 포스트가 아니라 하나의 테스트 케이스가 됩니다.

문장이 아닌 행동을 점수화하세요

루프 엔지니어링 (loop engineering)에서 나온 핵심 원칙이 그대로 적용됩니다: 제작자(maker) ≠ 검사자(checker). 에이전트는 자신의 숙제를 스스로 채점할 수 없습니다. 점수 산정의 대부분은 에이전트가 생성한 _도구 호출 추적 (tool-call trace)_에 대한 결정론적 단언(deterministic assertions)이어야 합니다. 즉, 모델이 말로 때울 수 없는 코드 수준의 검증이어야 합니다.

# grader.py — 캡처된 실행 결과에 대한 결정론적 점수 산정
def grade(scenario, run):
    """run = {'tool_calls': [{'name','args'}...], 'final_text': str}"""
...

"이 진단이 일관성 있고 실행 가능한가?"와 같이 정말로 모호한 부분에 대해서는 LLM-as-judge (판사로서의 LLM) 방식이 공정하지만, 이는 오직 보조적 수단이어야 하며, 반드시 판정을 수행하는 별도의 모델/컨텍스트를 사용해야 합니다. 멀티 에이전트 패널 (multi-agent panel)에서 제시된 독립 검증 로직이 바로 이 지점에서 정확히 들어맞습니다: 하나의 컨텍스트는 행동하고, 다른 컨텍스트는 판정합니다. 판사가 자신이 만든 가족의 결과물을 채점하고 있다는 사실을 절대 알게 해서는 안 되며, 결정론적 체크를 게이트(gate)로 유지해야 합니다. LLM 판사는 신호(signal)일 뿐, 최종 판결(verdict)이 아닙니다.

각 시나리오를 n번 실행하고 분포를 점수화하세요

에이전트는 확률적(stochastic)이기 때문에, 단 한 번의 통과만으로는 아무것도 증명할 수 없습니다. 각 시나리오를 여러 번 실행하고, 단일 통과 여부가 아닌 **통과율 (pass rate)**을 요구해야 합니다. 안전성 실패(safety failures)는 성격이 다릅니다. 안전성 문제에 대해서는 제로(zero) 허용 원칙을 적용해야 합니다.

import statistics

def evaluate(agent, scenarios, n=5):
...

방어 가능한 임계값(thresholds)을 설정하세요: 여러 실행에 걸쳐 작업 성공률(task-success)과 도구 정확도(tool-correctness)가 0.9 이상이어야 하며, 안전성(safety)은 항상 1.0이어야 합니다. 20번 중 단 한 번이라도 잘못된 것을 확장(scale)하는 에이전트는 "95% 안전"한 것이 아니라, 해당 작업 클래스에 대해 프로덕션에 배포할 수 없는 상태입니다.

CI에 회귀 게이트(regression gate)로 통합하기

이 모든 과정의 핵심은 성능 저하가 프로덕션에 도달하기 _전_에 포착하는 것입니다. 에이전트의 프롬프트(prompt), 도구(tools), 또는 고정된 모델(pinned model)에 변경이 있을 때마다 GitHub Actions에서 평가 스위트(eval suite)를 실행하고, 회귀(regression)가 발생하면 빌드를 실패시키세요.

# .github/workflows/agent-evals.yml
name: agent-evals
on:
...

이를 실현하는 두 가지 요소가 있습니다: 첫째, 평가 스위트는 실제 운영 환경이 아닌 **모킹된 클러스터 상태(mocked cluster state)**를 대상으로 실행되어야 합니다(평가는 수백 번 실행해도 안전해야 합니다). 둘째, 안전성 실패는 즉각적인 비제로(non-zero) 종료로 이어져야 합니다. 모델 버전을 PR 게이트가 적용된 동일한 설정에 고정하여, 제공업체(provider)의 업데이트가 갑작스러운 변화가 아니라 평가 실행이 첨부된 검토된 변경 사항이 되도록 하세요.

프리프로덕션(pre-prod)에서 멈추지 마세요: 온라인에서도 평가하세요

오프라인 평가(Offline evals)는 에이전트가 알려진 장애 상황에서 작동함을 증명합니다. 프로덕션은 알려지지 않은 상황을 보여줍니다. 모든 실제 에이전트 실행을 일급 텔레메트리 스트림(first-class telemetry stream)으로 계측하세요. 도구 호출(tool calls), 인자(arguments), 결과(outcomes), 토큰(tokens), 지연 시간(latency) 등을 OpenTelemetry를 사용하여 다른 서비스를 추적하는 것과 동일한 방식으로 처리합니다. 그런 다음 다음과 같은 저비용 온라인 체크를 지속적으로 실행하세요:

• 가드레일 카운터(Guardrail counters) — 에이전트가 차단된 도구나 접근해서는 안 될 네임스페이스(namespace)에 얼마나 자주 부딪혔는가? 이 비율이 상승한다면 프롬프트 또는 모델의 회귀(regression)입니다.
• 인간 개입률(Human-override rate) — 온콜(on-call) 담당자가 에이전트가 제안한 수정 사항을 거부한다면, 이는 레이블이 지정된 부정적 사례(negative)입니다. 거부된 제안을 골든 시나리오(golden-scenario) 세트에 즉시 다시 피드백하세요. 여러분의 평가 스위트는 프로덕션으로부터 _성장_해야 합니다.
• 비용 및 지연 시간 드리프트(Cost & latency drift) — 실행당 토큰 수가 서서히 증가하면 경고를 보냅니다. 말이 많아진(chattier) 모델은 조용한 예산 누수입니다.

이것은 자율적 장애 대응 (autonomous incident response)이 필요로 하는 방식으로 루프를 완성합니다. 즉, 에이전트가 제안하고, 사람이 수정하며, 모든 수정 사항이 내일의 회귀 테스트 (regression test)가 되는 것입니다.

정직한 한계

평가 (eval) 스위트는 당신의 에이전트가 안전하다는 것을 증명하지 않습니다. 대신, 당신이 인코딩(encode)하기로 생각했던 케이스들을 에이전트가 처리할 수 있다는 것을 증명할 뿐입니다. 새로운 실패 모드 (failure modes), 기이한 클러스터 상태, 그리고 적대적 입력 (adversarial inputs)은 정의상 당신의 시나리오 밖에 존재합니다. 평가는 미지의 영역을 줄여줄 뿐, 그것을 완전히 제거하지는 못합니다. 평가 스위트를 통과했다는 것을 '방치해도 된다는 허가'가 아니라, '제한적이고 감독된 환경에서 실행할 수 있는 권한'으로 취급하십시오. 대시보드가 아무리 초록색(정상)이라 할지라도, 모든 변이 (mutation)에 대해 인간의 승인 게이트를 유지하십시오.

지난 5번의 사후 분석 (postmortems)에서 추출한 5가지 시나리오로 시작하십시오. 동작을 결정론적 (deterministically)으로 점수화하고, 안전성 게이트를 1.0으로 설정한 뒤, 이를 CI (지속적 통합)에 연결하십시오. 이것이 "에이전트가 괜찮을 것 같다"와 "회귀(regress)하지 않았음을 증명할 수 있다"의 차이입니다. 그리고 프로덕션 환경에서는 오직 후자만이 호출(paged)을 받을 가치가 있습니다.

📌 이 가이드의 최신 버전과 DevOps, SRE, Kubernetes, 관측성 (observability) 및 클라우드 비용 가이드 전체 라이브러리를 devtocash.com에서 확인하세요.