당신의 AI 에이전트가 2달러짜리 작업에 200달러를 써버렸습니다. 아무도 경고하지 않은 이유

그리고 현재 우리가 가진 도구들이 왜 이에 대비되어 설계되지 않았는지에 대해서도 말하고자 합니다.

더 많은 사람들이 자율 에이전트 (autonomous agents)를 프로덕션 환경에 배포함에 따라, 조용히 실제적인 문제로 떠오르고 있지만 아무도 명확하게 이름을 붙이지 않고 있는 무언가에 대해 이야기하고 싶습니다.

우리는 여기서 프롬프트 인젝션 (prompt injection)이나 모델 환각 (model hallucinations)에 대해 말하는 것이 아닙니다. 우리는 더 지루하고 더 비용이 많이 드는 문제, 즉 에이전트가 경로를 이탈하여 실행되고 있는데 청구서가 날아오기 전까지는 당신이 그 사실을 모르는 상황에 대해 이야기하고 있습니다.

아무도 당신에게 경고하지 않은 문제

보통 상황은 다음과 같이 흘러갑니다.

당신은 에이전트를 구축합니다. 테스트 단계에서는 완벽하게 작동합니다. 당신은 이를 배포합니다. 며칠 후 OpenAI 결제 대시보드를 열어보니 무언가... 이상합니다. 한 번의 실행에 47달러가 들었습니다. 고작 2달러짜리 조사 작업이었는데 말이죠. 당신이 파고들어 로그 어딘가에서 원인을 찾아냅니다. 에이전트가 잘못된 도구 호출 (tool call)을 수행했고, 이상한 응답을 받았으며, 재시도 (retrying)를 시작했습니다. 무려 80번이나 말입니다. 아무도 그것을 멈추지 않았습니다.

이것은 당신의 LLM (Large Language Model)에 있는 버그가 아닙니다. 환각도 아닙니다. 그것은 단지 가드레일 (guardrail)이 없을 때 자율 에이전트가 하는 행동일 뿐입니다.

문제는 구조적입니다. 당신이 while (!done) 코드를 작성하고 제어권을 LLM에 넘길 때, 당신은 비결정론적 (non-deterministic) 시스템이 언제 멈춰야 할지를 알 것이라고 믿는 것입니다. 때때로 시스템은 멈추지 못합니다. 그리고 서버 다운이나 500 에러와는 달리, 폭주하는 에이전트는 계속해서 작동합니다. 겉보기에는 건강해 보입니다. 그저 돈을 쓰고 있을 뿐입니다.

왜 "그냥 max_iterations=10으로 설정하세요"가 통하지 않는가

이 답변이 자주 등장하는 것을 보았습니다. 언뜻 보기에는 일리가 있습니다. 루프 (loop)를 제한하면 문제가 해결될 것 같으니까요.

하지만 이 방법이 다루지 못하는 부분이 있습니다:

1. 비용은 반복 (iteration)마다 균일하지 않습니다.
어떤 단계는 0.003달러가 들 수도 있지만, 모델, 프롬프트 크기, 호출된 도구에 따라 다른 단계는 3.00달러가 들 수도 있습니다. 반복 횟수는 돈에 대해 아무것도 알려주지 않습니다.

2. 루프는 루프처럼 보이지 않을 수 있습니다.
갇혀버린 에이전트가 항상 정확히 똑같은 호출을 반복하는 것은 아닙니다. 매번 프롬프트를 약간씩 변형할 수도 있습니다. 의미론적 의도 (semantic intent)는 같지만 토큰 (tokens)은 다를 수 있다는 뜻입니다. max_iterations는 명백한 사례는 잡아내지만, 루프 시그니처 탐지 (loop signature detection)만이 진짜 문제를 잡아낼 수 있습니다.

3. 다중 서비스, 다중 에이전트 (Multiple services, multiple agents).
하나 이상의 에이전트가 실행되는 순간 — 서비스 간, 팀원 간, 환경 간에 — 당신의 max_iterations 설정은 어디에 위치하게 될까요? 각 리포지토리(repo)의 .env 파일에 있나요? 새벽 2시에 핫픽스(hotfix)를 배포할 때 그 설정들을 일관되게 유지하기란 매우 어려울 것입니다.

4. 아무도 무슨 일이 일어나고 있는지 볼 수 없습니다.
당신의 console.log 문은 프로세스 재시작(process restart) 시 살아남지 못합니다. 재무 책임자는 이를 쿼리할 수 없습니다. 다른 에이전트를 배포한 팀원은 실행 과정 전반에 걸쳐 어떤 패턴이 나타나고 있는지 확인할 수 없습니다.

반복 횟수 제한(iteration cap)은 임시방편(duct tape)에 불과합니다. 주말 프로젝트에서 한 명의 개발자가 하나의 스크립트를 보호할 때는 작동할지 모릅니다. 하지만 실제 사용자에게 에이전트를 배포하는 팀에게는 작동하지 않습니다.

더 깊은 문제: 에이전트는 함수가 아니라 행위자(Actor)입니다

이것은 제가 완전히 내재화하는 데 시간이 좀 걸렸던 부분입니다.

일반적인 함수를 호출할 때, 함수는 실행되고, 값을 반환하며, 끝납니다. 결정론적인 비용(deterministic cost)이 발생하며, 행동을 예측할 수 있고, 추론하기 쉽습니다.

자율 에이전트(autonomous agent)는 다릅니다. 그것은 함수 호출이 아니라, 결정을 내리는 하나의 '프로세스(process)'입니다. 어떤 도구(tool)를 호출할지, 어떤 순서로 호출할지, 몇 번이나 호출할지를 결정합니다. 작업이 완료되었다고 판단하는 시점도 스스로 결정합니다. 당신은 목표(objective)를 설정하고, 에이전트는 그 경로를 찾아냅니다.

그것이 에이전트형 AI (agentic AI)의 핵심입니다. 그것이 강력한 이유이기도 합니다.

하지만 이는 비용 모델이 완전히 다르다는 것을 의미하기도 합니다. 더 이상 호출당 비용을 지불하는 것이 아닙니다. 당신이 내리지 않은 일련의 결정들에 대해 비용을 지불하는 것입니다. 그리고 그 결정 중 하나가 잘못되었다면 — 잘못된 재시도 전략(retry strategy), 환각(hallucination)에 의한 도구 호출, 추론 루프(reasoning loop) 등 — 당신은 그 비용 또한 지불하게 됩니다.

우리는 API를 호출하고, 비용을 미리 알 수 있으며, 작업이 끝나는 '과거의 세계'를 위한 관측성(observability)과 거버넌스(governance)를 구축해 왔습니다. 우리는 아직 이 '새로운 세계'를 위한 체계를 완전히 구축하지 못했습니다.

실제로 존재해야 하는 것들

이 문제를 진지하게 고민하기 시작했을 때, 저는 에이전트가 프로덕션(production) 환경에서 안전하게 작동하기 위해 반드시 충족되어야 하는 특정 조건들이 있다는 것을 깨달았습니다:

실행당 엄격한 예산 상한선 (Hard budget ceilings). 단순한 소프트 경고(soft warnings)나 "알림을 보내드리겠습니다" 수준이 아닙니다. 에이전트는 상한선에 도달하는 즉시 _중단(stops)_되어야 합니다. 추가 비용이 발생하기 전에, 부분적인 결과라도 남긴 채로 말입니다.

의미론적 수준에서의 루프 탐지 (Loop detection at the semantic level). 단순히 반복 횟수를 세는 것이 아니라, 에이전트가 동일한 추론 패턴(reasoning pattern)을 반복하며 헛돌고 있는지를 실제로 탐지해야 합니다.

코드 외부에 존재하는 킬 스위치 (A kill switch that lives outside your code). 에이전트가 서비스-A(service-A)에서 실행 중이라면, 폭주하는 실행을 멈추기 위해 서비스-A를 다시 배포(redeploy)할 필요가 없어야 합니다. 킬 스위치는 대시보드, API, 웹훅(webhook) 등 무엇이든 통해 호출할 수 있어야 합니다.

지속적인 감사 로그 (Persistent audit logs). 모든 단계, 모든 도구 호출(tool call), 모든 결정 사항은 프로세스가 종료되어도 사라지지 않는 어딘가에 기록되어야 합니다. 이는 디버깅(debugging)을 위한 것이 아니라, _거버넌스(governance)_를 위한 것입니다. 그래야만 "이 에이전트가 실제로 무엇을 했고, 왜 그렇게 했는가?"라고 물을 수 있습니다.

중앙 집중화된 정책 (Policy that's centralized). 서비스별 설정 파일(config files)이 아닙니다. 규칙을 정의하는 단 한 곳이 있어야 하며, 팀이 배포하는 모든 에이전트는 그 규칙을 상속받아야 합니다.

마지막 항목이 핵심적인 통찰입니다. "프로젝트에 예산 라이브러리를 추가하는 것"과 "실질적인 거버넌스를 갖추는 것"의 차이는 정책이 코드 위에 존재하는가(lives above the code) 아니면 코드 내부에 존재하는가에 달려 있습니다.

이해를 도운 비유

Datadog이 애플리케이션 메트릭(application metrics)과 어떤 관계를 맺는지 생각해 보십시오.

로컬에서 Prometheus를 사용하여 앱에 계측(instrument)을 수행하고 메트릭을 표준 출력(stdout)에 기록할 수 있습니다. 하나의 앱이라면 작동할 것입니다. 하지만 여러 서비스가 생기는 순간, 코드 _위(above)_에 계층이 필요해집니다. 모든 서비스의 메트릭이 수렴하고, 알림을 설정하며, 팀 전체가 무슨 일이 일어나고 있는지 볼 수 있는 장소 말입니다.

그것이 바로 에이전트 거버넌스(agent governance)가 갖춰야 할 형태입니다. 각 프로젝트에 추가하는 라이브러리가 아니라, 그 모든 것 위에 자리 잡은 제어 평면(control plane)이어야 합니다.

라이브러리는 귀하의 프로세스 내에서 실행됩니다. 프로세스가 멈추면 함께 멈춥니다. 하나의 리포지토리(repo)에 존재합니다.

제어 평면은 귀하의 코드 위에서 실행됩니다. 배포(deploys)가 이루어져도 지속됩니다. 팀이 배포하는 모든 에이전트에 걸쳐 적용됩니다.

이 분야에서 무언가를 만들었습니다 — 디자인 파트너를 찾습니다

저는 정확히 이 문제를 해결하기 위해 작업해 왔습니다. 이것의 이름은 Thskyshield로, 자율 에이전트 (autonomous agents)를 위한 런타임 거버넌스 계층 (runtime governance layer)입니다.

아이디어는 간단합니다. 에이전트 루프 (agent loop)를 세 가지 SDK 호출인 beginRun, beforeStep, afterStep으로 감싸기만 하면, 컨트롤 플레인 (control plane)이 나머지를 처리합니다. 엄격한 예산 상한선 (budget ceilings), 루프 탐지 (loop detection), 킬 스위치 (kill switch), 단계별 감사 추적 (step-by-step audit trail)을 제공합니다. 10ms 미만의 강제 적용 (enforcement) 성능을 갖추고 있어 실제 LLM 호출에 지연 시간 (latency)을 추가하지 않습니다. LangGraph, CrewAI, OpenAI Agents SDK 또는 여러분이 사용 중인 어떤 도구와도 함께 작동합니다.

정책은 코드가 아닌 대시보드 (dashboard)에 존재합니다. 배포를 건드리지 않고도 제한 사항을 변경할 수 있습니다. 팀이 배포한 모든 에이전트가 실제로 무엇을 했는지 확인할 수 있습니다.

const run = await shield.beginRun({
  agent: 'research-agent',
  budgetLimitUsd: 2.00,
...

단 다섯 줄입니다. 어떤 에이전트 루프에도 바로 적용할 수 있습니다.

MVP가 출시되었습니다. 저는 에이전트 SDK의 형태를 잡아나가기 위해 소수의 팀과 적극적으로 협력하고 있습니다. 특히 실제 에이전트를 배포하며 실제 문제에 직면해 있는 분들과 이야기 나누고 싶습니다. 처음 5팀의 디자인 파트너 (design partners)에게는 평생 무료로 제공합니다.

만약 이 분야에서 제품을 만들고 있고 이 문제가 익숙하게 들린다면, 진심으로 이야기를 나누고 싶습니다. 댓글을 남겨주시거나 thskyshield.com/contact로 연락해 주세요.

에이전트 시대는 현실입니다. 이를 안전하게 관리할 도구들은 아직 따라잡는 중입니다. 저는 그 간극을 메우는 작업을 하고 있습니다.

만약 프로덕션 환경에서 에이전트를 구축하고 있으면서 아직 이 문제를 생각해보지 않았다면, 지금이 바로 그때입니다.

#ai #agents #llm #devops #opensource #typescript #buildinpublic #webdev