하룻밤 사이에 소모된 4억 개의 토큰

5,080건의 API 요청. 모든 것이 정상적으로 보였습니다.

오전 8시 3분에 심장이 멎었습니다

2026년 5월 24일 일요일.

API 대시보드를 열었을 때 가슴이 철렁 내려앉았습니다.

단 하루 만에 2억 6,200만 개의 입력 토큰 (input tokens)이 소비되었습니다.

참고로 말씀드리자면: NATS를 통해 4개의 AI 에이전트 (AI agents)가 협업하며 설정을 처리하고, 파일을 이동시키고, 모델을 학습시키며, 오케스트레이션 (orchestration) 작업을 수행하는 저의 멀티 에이전트 시스템 (multi-agent system)의 일반적인 과부하 상태에서는 보통 약 1억 개의 토큰이 소모됩니다.

이번에는 그 거의 세 배에 달했습니다.

게다가 그날은 아직 끝나지도 않은 상태였습니다.

다음 날 아침인 5월 25일, 커피를 마시기도 전에 다시 확인했습니다.

하룻밤 사이에 또 다른 1억 3,400만 개의 입력 토큰 (input tokens)이 소비되어 있었습니다.

총 피해 규모:

지표	값
입력 토큰 (Input tokens)	~4억 개
...

저의 첫 번째 생각은:

"비용이 얼마나 나왔을까?"

저의 두 번째 생각은:

"제발 운영 환경 (production)에 연결된 것이 DeepSeek이 아니기를. 제발."

무슨 일이 일어났는가

Mac Mini M4에서 실행 중이던 오케스트레이터 에이전트 (orchestrator agent)가 네트워크에서 새로운 에이전트를 발견했습니다.

보조 에이전트가 RTX 3090 GPU가 장착된 Linux 머신에서 막 온라인 상태가 된 것이었습니다.

표준 온보딩 프로토콜 (onboarding protocol)에 따라, 오케스트레이터는 NATS를 통해 온보딩 문서 및 초기화 컨텍스트 (initialization context)와 함께 환영 메시지를 보냈습니다.

그 메시지는 정확했습니다.

문제는 다음과 같습니다:

메시지 전송이 멈추지 않았다는 점입니다.

60~90초마다 오케스트레이터는 동일한 온보딩 페이로드 (onboarding payload)를 다시 전송했습니다.

NATS-to-Hermes 브리지 서비스 (bridge service)는 들어오는 모든 메시지를 처리를 위해 Hermes로 충실히 전달했습니다.

전달된 각 메시지는 새로운 에이전트 세션 (agent session)을 생성했습니다.

그리고 모든 세션은 전체 시작 컨텍스트 (startup context)를 로드했습니다:

• HARNESS
• 시스템 프롬프트 (system prompt)
• 헌법 (constitution)
• 에이전트 메모리 (agent memory)
• 도구 레지스트리 (tool registry)
• 온보딩 가이드 (onboarding guides)
• 기술 매니페스트 (skill manifests)
• 런타임 지침 (runtime instructions)

매번 수천 개의 토큰이 소모되었습니다.

매번 말입니다.

세션은 메시지를 처리하고, 응답을 생성한 뒤, 종료하고 다음 이벤트를 기다렸습니다.

그 후 또 다른 동일한 온보딩 (onboarding) 메시지가 도착했습니다.

또 다른 세션이 생성되었습니다.

또 다른 전체 컨텍스트 (context) 로드가 발생했습니다.

또. 그리고 또. 그리고 또 말입니다.

약 15시간 동안 5,080번 발생했습니다.

무서운 점

겉보기에는 아무것도 고장 난 것처럼 보이지 않았습니다.

에이전트 (agents)들은 정상적으로 응답했습니다. 충돌도 없었습니다. 빨간색 경고도 없었습니다. 상태 확인 (health checks) 실패도 없었습니다.

외부에서 보기에 시스템은 건강해 보였습니다.

아무도 눈치채지 못한 이유

15시간 동안, 루프 (loop)는 백그라운드에서 조용히 토큰을 태워 없앴습니다.

몇 가지 요인이 이 현상을 탐지하기 유난히 어렵게 만들었습니다:

1. 시스템이 기술적으로는 "작동"하고 있었습니다

메시지는 올바르게 흐르고 있었습니다. 에이전트들은 올바르게 답변했습니다. 작업들은 성공적으로 완료되었습니다. 눈에 띄게 실패한 것은 아무것도 없었습니다.

2. 에이전트 시작 비용이 기만적일 정도로 비쌌습니다

토큰 소모의 대부분은 모델의 출력 (outputs)이 아니라, 거대한 컨텍스트 윈도우 (context windows)를 반복적으로 로드하는 데서 발생했습니다. 모든 새로운 세션은 작업을 수행하기 전에 전체 오케스트레이션 (orchestration) 환경을 로드했습니다. 아주 작은 온보딩 핑 (onboarding ping) 하나가 수만 개의 입력 토큰을 유발했습니다. 반복해서 말입니다.

3. 세션 예산 (session budgets)도 도움이 되지 않았습니다

각 개별 세션은 제한 범위 내에 머물렀습니다. 하지만 루프가 끊임없이 완전히 새로운 세션들을 생성해냈습니다. 실수로 무한한 세션을 생성하게 된다면, 세션당 토큰 제한은 무용지물입니다.

4. 속도 제한 (Rate limiting) 역시 도움이 되지 않았습니다

요청 스로틀링 (request throttling)을 적용하더라도, 모든 요청은 여전히 컨텍스트 토큰을 소비했습니다. 느린 무한 루프도 결국 무한 루프일 뿐입니다.

5. 모니터링이 현실을 따라가지 못했습니다

우리는 사용량 대시보드를 수동으로 확인했습니다. 하루에 한 번씩 말입니다. 우리가 급증을 확인했을 때, 루프는 이미 밤새도록 실행된 상태였습니다.

6. 프로세스를 종료해도 멈추지 않았습니다

브릿지 데몬 (bridge daemon)은 launchd에 의해 관리되고 있었습니다. 프로세스를 종료하면 단순히 자동으로 재시작될 뿐이었습니다. 루프가 마침내 멈추기 전까지 우리는 데몬을 완전히 언로드 (unload)해야 했습니다.

근본 원인

이 문제는 다음 요소들 사이의 지저분한 상호작용에서 비롯되었습니다:

• 네트워크 디스커버리 (network discovery)
• 온보딩 재시도 (onboarding retries)
• 그리고 중복 제거 레이어 (deduplication layer)가 없는 브릿지

보조 에이전트(secondary agent)가 온보딩(onboarding) 과정에서 불안정한 연결 상태를 보였습니다. 네트워크에서 나타났다 사라지기를 반복했습니다. 재발견(rediscovery)이 일어날 때마다 새로운 "환영(welcome)" 이벤트가 트리거되었습니다. 브릿지(bridge)는 모든 이벤트를 맹목적으로 전달했습니다. Hermes는 각각의 이벤트를 완전히 새로운 것으로 처리했습니다.

양의 피드백 루프 (Positive feedback loop):

온보딩 이벤트 (Onboarding event)
    ↓
NATS 메시지 (NATS message)
...

이 과정이 15시간 동안 반복되었습니다.

해결책 (The Fix)

실제 해결책은 놀라울 정도로 간단했습니다. 세 가지 변경 사항이 전체 연쇄 반응을 멈췄습니다.

1. 메시지 중복 제거 (Message deduplication)

가장 결정적인 해결책입니다. 이제 브릿지는 들어오는 온보딩 페이로드(payload)를 해싱(hash)하고, 쿨다운(cooldown) 기간 내의 중복 항목은 무시합니다.

2. 세션 생성 보호 (Session spawn protection)

동일한 에이전트로부터 발생하는 반복적인 온보딩 이벤트는 이제 하나의 활성 세션(active session)으로 병합됩니다.

3. 실시간 토큰 모니터링 (Real-time token monitoring)

일일 대시보드 확인 대신 실시간 토큰 속도(token-rate) 알림을 추가했습니다. 토큰 속도가 비정상적으로 급증하면 브릿지가 즉시 알림을 보냅니다.

전체 구현 코드: github.com/nerudek/nats-agent-state-sharing/tree/main/bridge

비용 (The Cost)

이제 저를 진심으로 겁먹게 했던 부분입니다.

저는 정확히 동일한 버그가 서로 다른 제공업체(provider)를 사용했을 때 각각 얼마의 비용을 발생시켰을지 계산해 보았습니다.

버그는 동일했습니다. 오직 API 제공업체만 달랐을 뿐입니다.

제공업체 (Provider)	예상 비용 (Estimated Cost)
Anthropic Claude Sonnet	~$1,245
...

그 순간 저는 마침내 안도의 한숨을 내쉬었습니다.

엔지니어링 실수는 실재했습니다. 토큰 소모도 실재했습니다. 4억 개의 토큰은 매우 실재했습니다.

하지만 제공업체의 선택은 다음 두 상황의 차이를 만들었습니다:

"음... 정말 끔찍했네"

와

"이걸 회계팀에 설명해야 해."

교훈 (Lessons Learned)

AI 에이전트 시스템은 전통적인 소프트웨어와는 다르게 실패합니다.

위험한 버그가 항상 시스템 충돌(crash)로 이어지는 것은 아닙니다. 때로는 시스템이 완벽하게 작동하는 것처럼 보이면서, 소리 없이 돈을 불태우고 있을 수도 있습니다.

그리고 자율 에이전트 (autonomous agents), 브리지 (bridges), 재시도 (retries), 온보딩 프로토콜 (onboarding protocols), 데몬 재시작 (daemon restarts), 그리고 거대한 컨텍스트 윈도우 (context windows)를 하나씩 연결하기 시작하면, 아주 작은 논리적 실수가 놀라울 정도로 빠르게 인프라 규모의 문제로 변질됩니다.

누락된 단 한 번의 중복 제거 (deduplication) 체크가 다음과 같은 결과를 초래했습니다:

• 5,080개의 요청 (requests)
• 약 4억 개의 입력 토큰 (input tokens)
• 그리고 15시간 동안의 보이지 않는 비용 소모 (invisible burn)

가장 무서운 점은 무엇일까요?

외부에서 보기에는 모든 것이 정상적으로 보였다는 것입니다.

이 글이 도움이 되었다면: PayPal.me/nerudek
GitHub: github.com/nerudek

Hermes 루프 방지 수정 사항: github.com/nerudek/nats-agent-state-sharing/tree/main/bridge

증거 자료 (The Receipts)