실제 운영 환경에서 AI 에이전트의 도구 호출(Tool Calls)은 어떤 모습인가 (반드시 확인해야 할 3가지 계층)

에이전트의 도구 호출(Tool Calls)을 읽을 수 없다면, 디버깅(Debug)할 수 없습니다. 비용을 청구할 수도 없습니다. 그리고 고객에게 "네, 그 이메일이 발송되었습니다"라고 확신을 가지고 말할 수도 없습니다.

대부분의 팀은 에이전트를 출시하고 한 가지 계층, 즉 보통 LLM API 요청/응답(Request/Response)에 대해서만 계측(Instrument)을 수행하고 이를 관측성(Observability)이라고 부릅니다. 그러다 3주 차가 되면 고객은 왜 동일한 Slack 메시지가 11번이나 나갔는지 묻게 되고, 트레이스(Trace)에는... 유용한 정보가 아무것도 나타나지 않습니다.

다음은 제가 AI Ops 점검을 수행할 때 사용하는 3계층 모델입니다. 이 계층 중 어느 것도 선택 사항이 아닙니다. 이 중 하나라도 누락된다면, 설명할 수 없는 장애 모드는 바로 그 간극 사이에 숨어 있을 것입니다.

계층 1 — LLM 호출 엔벨로프 (LLM call envelope) (대부분의 팀이 보유함)

이것은 쉬운 부분입니다. 2026년의 모든 관측성(Observability) 벤더들—LangSmith, Langfuse, Helicone, Arize Phoenix, Braintrust, Maxim, Galileo—은 이를 기본적으로 제공합니다. 여러분은 다음을 기록합니다:

• 모델 이름 + 버전
• 시스템 프롬프트 해시 (System prompt hash) (프롬프트 변경 사항과 상관관계를 파악하기 위함)
• 입력 메시지 (또는 비식별화된 버전)
• 출력 텍스트 + 종료 사유 (Finish reason)
• 토큰 수 (Prompt / Completion / Cached)
• 지연 시간 (Latency)
• 예상 비용

이 계층이 답하는 질문: 모델이 우리가 예상한 대로 동작했는가?

이 계층이 답하지 못하는 질문: 에이전트가 실제로 세상에서 무엇을 했는가?

계층 2 — 도구 호출 시도 (The tool-call attempt) (대부분의 팀이 건너뛰는 계층)

이곳이 바로 간극입니다. 모델은 "이러한 인자(Arguments)로 send_email을 호출하겠습니다"라고 말했습니다. 도구가 실제로 실행되었나요? 성공했나요? 모델이 반환되었다고 생각하는 것과 동일한 값을 반환했나요?

모든 도구 호출에 대해 기록해야 할 사항:

• tool_name + 버전 (도구는 변경됩니다 — send_email v1은 v3와 동일하지 않을 수 있습니다)

• arguments (해시값이 아닌 전체 페이로드 — 새벽 2시에 저에게 감사하게 될 것입니다)

• result (모든 에러 코드/메시지를 포함한 전체 응답)

• latency_ms (지연 시간)

• attempt_number (1, 2, 3 — 재시도 횟수는

• 별도의 검증 작업 (separate verification job): 부수 효과(side-effect) 대상에 핑을 보냄 (예: "지난 60초 동안 전송된 이메일 목록을 나열하고, 우리가 보낸 이메일이 나타나는지 확인")

• 합성 사용자 (synthetic user): 실제 동작을 수행하고 세상의 상태(world state)가 변했는지 확인

• 명시적인 고객 확인 (explicit customer confirmation): 위험도가 높은 작업에 대해 확인 요청 ("Milo가 이 이메일을 보냈습니다 — 받으셨나요?")

• 부수 효과 원장 (side-effect ledger): 의도(intent) → 주장된 결과(claimed_result) → 검증된 결과(verified_result) → 차이(delta)를 기록하는 작은 저장소. 차이(delta)가 비어 있지 않으면 담당자에게 알림(page)을 보냄.

이 계층이 답하는 질문: 사용자가 우리가 하겠다고 말한 것을 실제로 경험했는가?

이 계층이 답하지 못하는 질문: 없음 — 이 세 가지를 모두 갖추고 있다면, 지난 14개월 동안 제가 목격한 그 어떤 에이전트 실패 사례도 디버깅할 수 있습니다.

10분 감사(audit): 당신의 에이전트는 어떤 계층을 갖추고 있습니까?

코드베이스를 열고 각 항목에 대해 예/아니오로 답해 보세요:

1. 계층 1 (Layer 1) — 모델 버전과 토큰 비용을 포함하여, 지난 30일 동안의 모든 사용자 턴(user turn)에 대한 정확한 프롬프트(prompt) + 응답(response)을 찾을 수 있습니까? (예 / 아니오)
2. 계층 1.5 (Layer 1.5) — 특정 턴이 제공될 때 어떤 프롬프트 버전이 활성화되어 있었는지 알 수 있습니까? (예 / 아니오 — 여기서는 시스템 프롬프트의 버전 해시(version hash)가 중요합니다)
3. 계층 2 (Layer 2) — 지난 30일 동안의 모든 도구 호출(tool call)에 대해 인자(arguments), 결과(result), 지연 시간(latency), 그리고 재시도 횟수(retry attempt number)를 찾을 수 있습니까? (예 / 아니오)
4. 계층 2.5 (Layer 2.5) — 중복처럼 보이는 실패가 발생했을 때, 도구가 실제로 두 번 호출되었는지 아니면 두 번 호출될 의도였는지만 알 수 있습니까? (예 / 아니오 — 이것은 중복 이메일 조사를 3시간이 아닌 3번의 클릭만으로 끝낼 수 있느냐의 문제입니다)
5. 계층 3 (Layer 3) — 지난 30일 동안의 모든 사용자 가시적 동작(user-visible action)에 대해, 도구가 아닌(non-tool) 신호를 통해 사용자가 실제로 결과를 확인했음을 확증할 수 있습니까? (예 / 아니오)

점수 산정:

• 5/5 — 당신은 2026년에 에이전트를 출시하는 팀 중 상위 5% 안에 듭니다. 이를 강점으로 내세우세요.

• 3-4/5 — 중간 수준입니다. 격차는 실재하며 구체적입니다. 그 격차의 이름을 명확히 정의할 수 있습니다.

• 0-2/5 — 무언가 고장 나면, 당신은 추측만 하게 될 것입니다. 고객이 당신보다 먼저 문제를 알게 될 것입니다.

실제 트레이스(traces)를 읽을 때의 모습

실제 점검(checkup) 데이터에서 나타나는 세 가지 전형적인 형태 (실제 데이터를 익명화함):

형태 A — "루프에 빠진" 에이전트. 레이어 1(Layer 1)은 정상적으로 보입니다. 레이어 2(Layer 2)를 보면 에이전트가 90초 동안 동일한 인자(arguments)로 search_kb를 14번 호출한 뒤, 포기하고 인용(citation)이 전혀 없는 확신에 찬 답변을 내놓았습니다. 레이어 3(Layer 3)은 이를 절대 잡아낼 수 없었을 것입니다. 사용자는 환각(hallucination)된 응답을 받았습니다. 해결책은 모델 레이어(model layer)가 아닌 도구(tool) 레이어에 최대 반복 횟수 가드(max-iterations guard)를 설정하는 것이었습니다. 레이어 1만 있었다면 이 문제는 절대 발견할 수 없었을 것입니다.

형태 B — "스테이징에서는 작동하지만, 운영 환경에서는 침묵하는" 에이전트. 레이어 1은 동일한 프롬프트(prompt), 동일한 모델, 유사한 지연 시간(latency)을 보여줍니다. 레이어 2는 crm.upsert_contact 호출이 200(성공)을 반환하는 것을 보여줍니다. 레이어 3 — 검증 작업(verification job) — 은 해당 연락처가 고객의 CRM에 없음을 보여줍니다. 원인은 운영(production) API 키의 권한 범위(scope)가 스테이징(staging) 키와 다른 조직(org)으로 설정되어 있었기 때문입니다. 도구의 200 응답은 거짓이었습니다. 레이어 3이 없었다면 이 문제는 절대 발견할 수 없었을 것입니다.

형태 C — "분명히 보냈는데요" 에이전트. 레이어 1은 모델이 전송을 결정하는 것을 보여줍니다. 레이어 2는 이메일 도구가 첫 번째 시도에서 성공을 반환하는 것을 보여줍니다. 레이어 2.5 — 재시도 카운터(retry counter) — 는 첫 번째 시도를 보여줍니다. 레이어 3 — 편지함 검증 작업(inbox verification job) — 은 전달된 이메일이 0건임을 보여줍니다. 원인은 SES 계정이 운영 모드가 아닌 샌드박스(sandbox) 모드였기 때문입니다. 고객은 아무것도 받지 못했습니다. 에이전트가 자신의 도구를 믿었기 때문에

이 3계층 모델은 이론이 아닙니다. 제가 모든 AI Ops Checkup 프로젝트에 참여할 때 가장 먼저 살펴보는 것입니다. 고객의 "왜 X가 발생했나요?"라는 질문에 대한 답은 약 60%의 경우 레이어 2 또는 레이어 3에 있으며, 팀은 그곳을 살펴봐야 한다는 사실조차 모르고 있었습니다. 약 30%의 경우는 프롬프트 문제(레이어 1)이지만 증상은 도구 실패(tool failure)처럼 보였습니다. 나머지 약 10%의 경우는 로그를 읽는 것이 아니라 평가 세트(eval set)가 필요한 실제 모델 동작(model behavior) 문제입니다.

이 모델을 사용하면 어떤 레이어가 고장 났는지에 대해 논쟁하는 일을 멈출 수 있습니다. 세 개의 테이블을 읽기만 하면 바로 알 수 있습니다.

만약 여러분의 에이전트에서 이러한 격차(gap)를 목격하고 있고, 트레이스(traces)에 대해 제2의 시각이 필요하다면, 그것이 바로 AI Ops Checkup입니다. 24시간 이내에 처리되며, 비용은 149달러입니다. 여러분이 로그를 보내주시면 제가 보고서를 보내드립니다.

만약 여러분이 에이전트 관측성(agent observability)을 구축하고 있으며, 이 내용이 여러분의 도구가 이미 다루어 주기를 바라는 레이어와 일치한다면, 무엇이 부족한지 꼭 듣고 싶습니다. 댓글 창은 열려 있습니다.