• 도서: Agents in Production — Building, Tracing, and Shipping Multi-Step AI You Can Trust
• 저자의 다른 저서: Observability for LLM Applications — The AI Engineer's Library (2권 시리즈)의 동반 도서
• 내 프로젝트: Hermes IDE | GitHub — Claude Code 및 기타 AI 코딩 도구를 사용하여 배포하는 개발자를 위한 IDE
• 나에 대하여: xgabriel.com | GitHub

2024년 2월, 한 법정은 Air Canada가 지원 챗봇이 즉석에서 지어낸 환불 정책을 준수하도록 명령했습니다. 항공사는 자사의 봇이 말한 내용에 대해 책임이 없다고 주장했습니다. 법정은 이에 동의하지 않았습니다. 봇은 회사를 대변하며, 따라서 회사가 그 답변에 대한 책임을 집니다.

그 사례는 에이전트(Agent)를 배포할 때 발생하는 문제 전체를 한 문장으로 요약해 줍니다. 에이전트는 실제 사용자와 대화하고, 실제 시스템을 건드리며, 실제 돈을 사용합니다. 그리고 문제가 발생했을 때 그 사고의 책임은 당신에게 있습니다. CPU는 정상입니다. 지연 시간(Latency)도 정상입니다. 모든 것이 200 상태 코드를 반환합니다. 봇은 답변했고, 그 답변은 틀렸습니다.

따라서 트래픽 플래그(traffic flag)를 전환하기 전에, 처음부터 끝까지 훑어보며 정직하게 '예'라고 답할 수 있는 목록이 필요합니다. 성숙도 모델(maturity model)이 아닙니다. 6가지 체크 항목입니다. 각 항목은 속이기 어려운 것이며, 각 항목은 이미 특정 팀을 곤경에 빠뜨렸던 구멍들을 메워줍니다.

1. 모든 실행이 열어볼 수 있는 트레이스(trace)를 생성해야 함

새벽 3시에 에이전트 문제로 호출(paged)을 받았을 때, 당신의 첫 번째 행동은 메트릭 대시보드를 보는 것이 아닙니다. 궤적 뷰어(trajectory viewer)를 보는 것입니다. 트레이스(trace)가 곧 실행 지침서(runbook)입니다.

이는 트레이스가 존재하고 결정을 재구성할 수 있을 만큼 충분한 정보를 담고 있을 때만 유효합니다. 모든 실행 시 트레이스 ID(trace ID)를 생성하고, 지원을 위해 이를 사용자에게 노출하며, 모든 스팬(span)에 모델, 프롬프트 버전, 호출된 도구(tools), 토큰(tokens), 비용을 포함시키세요.

시작하는 데 무거운 프레임워크가 필요하지는 않습니다. 스팬 (span)은 시작(start), 종료(end), 그리고 몇 가지 속성(attributes)을 가진 딕셔너리 (dict)입니다.

import time
import uuid
import json
...

모델 호출을 래핑 (wrap)하여 사용량 (usage)이 자동으로 스팬에 기록되도록 하세요. Anthropic SDK는 모든 응답에서 토큰 (token) 수를 반환합니다.

from anthropic import Anthropic

client = Anthropic()
...

데이터 형식이 안정되면 OpenTelemetry 호환 파이프라인 (pipeline)을 통해 스팬을 내보내세요. 첫 번째 체크의 핵심은 페이지가 로드되었을 때, 시청자에게 보여줄 무언가가 있어야 한다는 점입니다.

2. 평가 세트 (eval set)는 출시 후에가 아니라 출시 전에 고정해야 합니다

새벽 4시에 배포하는 수정 사항이 4시 30분에 새로운 회귀 (regression)를 일으켜서는 안 됩니다. 그것이 바로 평가 세트 (eval set)가 제공하는 가치이며, 첫 번째 사용자가 유입된 후가 아니라 첫 번째 사고가 발생하기 전에 이미 갖춰져 있어야 합니다.

최소 50개의 실제 궤적 (trajectories)을 고정하세요. 매 배포 시마다 이들을 대상으로 두 가지 종류의 체크를 실행합니다. 하나는 결정론적 (deterministic) 체크로, 문자열 일치, 도구 호출 (tool-call) 일치 또는 단위 테스트 (unit test)를 수행합니다. 다른 하나는 모호한 부분인 정확성 (correctness)과 톤 (tone)을 확인하기 위한 LLM-as-judge 체크입니다.

결정론적 체크는 비용이 저렴하며 어처구니없는 회귀 (regression)를 잡아냅니다.

def eval_tool_choice(trajectory, expected_tool):
    calls = [s for s in trajectory["spans"]
             if s["name"] == "tool_call"]
...

판단 (judge) 체크는 궤적 (trajectory)을 모델에 전달하고 스키마 (schema)가 포함된 좁은 범위의 질문을 던짐으로써, 출력이 산문 (prose)이 아닌 파싱 가능한 (parseable) 형태가 되도록 합니다.

def judge_correctness(question, answer):
    resp = client.messages.create(
        model=MODEL,
...

첫 출시 전에 사람이 20~50개의 실제 트레이스 (traces)를 직접 읽어보게 하세요. 그 어떤 평가 세트 (eval set)도 에이전트가 실제로 무엇을 했는지 엔지니어가 직접 읽어보는 것을 대체할 수 없습니다.

3. 가드레일 (Guardrails)은 프롬프트가 아니라 코드에 존재해야 합니다

교묘한 프롬프트 (prompt)로 논쟁하여 무력화할 수 있는 가드레일은 가드레일이 아닙니다. 그것은 제안 (suggestion)일 뿐입니다. 진짜 가드레일은 모델의 추론 (reasoning) 외부에 위치하는 결정론적 (deterministic) 체크입니다. 범위를 벗어난 요청을 거부하는 입력 필터 (input filter), 응답이 나가기 전 개인정보 (PII)를 스캔하는 출력 스캔 (output scan), 그리고 동일한 인자 (arguments)로 동일한 도구 호출이 반복될 때 중단하는 루프 탐지기 (loop detector)가 바로 그것입니다.

루프 탐지기 (loop detector)는 사람들이 흔히 건너뛰고 나중에 후회하는 요소입니다. 고장 난 도구를 영원히 호출하는 데 즐거워하는 에이전트는 정확히 그런 행동을 할 것입니다.

def make_loop_guard(limit=3):
    seen = {}

...

각 가드레일 (guardrail)은 테스트 가능하고 로그 (log)에 기록되도록 유지하세요. 가드레일이 작동하면, 해당 이벤트는 첫 번째 체크부터의 트레이스 (trace)에 기록되어야 합니다. 그래야 사후 분석 (postmortem) 시 에이전트가 왜, 어떻게 중단되었는지 확인할 수 있습니다.

4. 모든 지출 축에는 상한선 (cap)이 있어야 합니다

개발자들은 도구가 오작동하고 루프에 제한이 없을 때, 수만 달러의 크레딧을 태워버리는 폭주하는 에이전트 루프 (runaway agent loops) 사례를 설명해 왔습니다. 그 양상은 전형적입니다. 예산이 없는 자율 루프는 어떤 속도로든 작업과 무관하게 돈을 쓰는 방법을 찾아낼 것입니다.

모든 축에 상한선을 설정하세요. 궤적 (trajectory)당 최대 스텝 수, 궤적당 최대 토큰 수, 궤적당 최대 달러 금액을 설정하십시오. 여기에 추가로 사용자당 일일 예산과 테넌트 (tenant)당 일일 예산을 설정하세요. 호출이 끝난 후가 아니라 호출 전에 예산을 확인해야 합니다. 호출 후 확인한다는 것은 이미 예산을 초과하게 만든 호출에 대해 비용을 지불했다는 의미이기 때문입니다.

from dataclasses import dataclass

@dataclass
...

이유를 예외 (exception)가 아닌 값 (value)으로 반환하세요. 모델이 작업을 완료했을 때와 상한선에 걸려 중단되었을 때 사용자에게 보여주는 답변은 달라야 합니다. 하나는 정답을 보여주고, 다른 하나는 "계속할까요?"라는 해치 (hatch)가 포함된 부분적인 결과물을 보여줍니다.

5. 위험한 삼각 관계를 형성하는 도구 조합은 없어야 합니다

Meta의 Agents Rule of Two는 현재 에이전트 보안에 관한 가장 명확하고 실질적인 지침입니다. 하나의 세션 내에서 에이전트는 다음 세 가지 중 최대 두 가지만 충족해야 합니다: 신뢰할 수 없는 입력 (untrusted input)을 처리함, 개인 데이터 또는 민감한 시스템에 접근함, 그리고 상태를 변경하거나 외부와 통신할 수 있음. 이 세 가지가 동시에 발생하는 것은 2025년 에이전트 침해 사례들의 전형적인 패턴이며, 이는 인간 참여 (human in the loop)가 필요함을 의미합니다.

코드에서 이를 감사 (audit)하고, 도구가 추가될 때마다 감사를 다시 실행하세요.

def rule_of_two_violation(tools):
    props = {"untrusted_input", "sensitive_access",
             "external_effect"}
...

각 도구(tool)에 해당 도구가 가진 속성을 태그로 지정하세요. 웹 페치(web-fetch) 도구는 신뢰할 수 없는 입력(untrusted input)을 처리합니다. 데이터베이스 읽기(database read)는 개인 데이터(private data)에 접근합니다. 이메일 전송(email send)은 외부와 통신합니다. 감사(audit) 결과 이 세 가지가 모두 나타난다면, 출시 결정은 "주의해서 배포하라"가 되어서는 안 됩니다. "확인 단계에 사람을 배치하거나, 세션 간에 도구를 분리하라"가 되어야 합니다.

6. 런북(runbook)이 존재하며, 이는 트레이스(trace)를 가리킨다

에이전트 사고(incident)는 인프라 사고와는 전혀 다릅니다. 깨지는 것은 의미론(semantics)입니다. 따라서 런북은 메트릭 대시보드(metrics dashboard)로 시작해서는 안 됩니다.

출시 전에 기록해 두세요. 첫 줄에는 다음과 같이 적습니다: "어떤 대시보드보다 먼저 궤적 뷰어(trajectory viewer)를 열 것." 지연 시간(latency)과 에러율(error rate)뿐만 아니라, 저지 스코어(judge-score) 하락과 비용 p99(cost-p99) 급증에 대해 페이지를 넘기며 확인하세요. 킬 스위치(kill switch)를 사고가 발생했을 때 작동하지 않는다는 것을 발견하기보다, 정기적인 일정에 따라 테스트하세요. 그리고 모든 사후 분석(postmortem)에 두 가지 필드를 요구하세요: 궤적 발췌본(trajectory excerpt)과 실패를 재현하는 새로운 평가 세트(eval-set) 케이스입니다.

마지막 항목이 이 리스트를 복리로 만드는 요소입니다. 첫 다섯 가지 체크리스트를 통과해 버린 모든 사고는 24시간 이내에 고정된 평가(eval) 케이스가 되므로, 동일한 실패가 두 번 배포될 수 없습니다. 이 리스트는 한 번 통과하면 끝나는 관문이 아닙니다. 당신이 지켜보는 것을 멈춘 후에도 에이전트가 정직함을 유지하게 만드는 루프(loop)입니다.

대화처럼 실행하라

여섯 가지 체크리스트를 출력하세요. 서비스 시작 일주일 전, 다른 엔지니어와 함께 이를 검토하세요. 각 항목에 대해 '완료됨', '서면 사유와 책임자를 명시하여 면제됨', 또는 '차단됨(blocking)' 중 하나로 분류하세요. 리스트가 깨끗해지면, 소규모 코호트(cohort)에 플래그를 설정하고 다른 탭에서 궤적 뷰어를 열어두세요.

핵심은 체크박스를 채우는 것이 아닙니다. "이것이 준비되었는가"라는 질문을 '느낌(vibes)'에 의존하는 질문에서 답변이 존재하는 일련의 질문들로 바꾸는 것입니다. 느낌은 배포를 원하는 쪽의 편을 듭니다. 리스트는 누군가가 어떤 항목을 면제하는지 말하게 만들고, 다른 누군가가 '아니오'라고 말할 수 있게 해줍니다.

작게 시작하세요. 아무도 당신을 고소하지 않을 내부용 에이전트를 선택하세요. 트레이스(trace)를 연결하고, 평가(evals)를 고정하며, 예산을 제한하고, 도구를 감사하고, 런북을 작성하세요. 일주일 동안 지켜보세요. 그런 다음 변호사들이 신경 쓰는 에이전트를 만드세요.

이 여섯 가지 중 어느 하나라도 더 자세한 내용을 원하신다면, 두 권의 책이 있습니다. _Agents in Production_은 기계 장치에 관한 책입니다: 루프 (loop), 가드레일 (guardrails), 킬 스위치 (kill switch), 그리고 사후 분석 (postmortem) 템플릿에 대해 다룹니다. _Observability for LLM Applications_는 그 아래에 있는 측정 도구들에 관한 책입니다: 스팬 (spans), 트레이스 (traces), 평가 (evals), 그리고 호출당 비용 (cost per call)을 다룹니다. 이 두 권은 _The AI Engineer's Library_의 두 축이며, 이들이 합쳐져 이 체크리스트의 근거가 됩니다.