TuBrief
구독 채널
비디오
커뮤니티

마이그레이션된 에이전트가 무한 루프에 빠질 때 570만 원짜리 토큰 폭탄을 막는 방법

TuBrief 편집팀
2026년 9월 10일
0
컴퓨터/소프트웨어

원본 영상을 바탕으로 AI의 도움을 받아 작성했습니다. 원본 영상이 기준입니다.

한국어EnglishEspañol中文हिन्दीDeutschFrançaisالعربيةPortuguêsBahasa IndonesiaРусский日本語

관련 영상

에이전트는 2015년의 마이크로서비스 위치에 있습니다 — 로베르토 밀레프 & 우다이 카나가라, Navan19:28

에이전트는 2015년의 마이크로서비스 위치에 있습니다 — 로베르토 밀레프 & 우다이 카나가라, Navan

AI Engineer

커뮤니티의 다른 글

사내 시스템에 llm api 붙일 때 마주하는 현실적인 한계와 대응법

2026년 9월 13일

레거시 백엔드에 GPT-6 Astra 붙일 때 예산 승인과 보안 통과를 먼저 끝내는 법이 있습니다

2026년 9월 13일

에이전트끼리 대화하다 6천만 원 청구서가 나오는 이유

2026년 9월 13일

사내 RAG 벡터 검색에 Okta 권한 필터를 직접 거는 방법

2026년 9월 13일

브라우저 에이전트에게 내 구글 계정을 통째로 넘기면 안 되는 이유

2026년 9월 12일

Apple Won the AI Race

2026년 9월 12일

댓글 (0)

Log in to leave a comment

아직 작성된 글이 없습니다

© 2026 . All rights reserved.

TuBrief
구독 채널
비디오
커뮤니티
로그인

마이그레이션된 에이전트가 무한 루프에 빠질 때 570만 원짜리 토큰 폭탄을 막는 방법

MSA 기반 레거시 시스템을 AI 에이전트 아키텍처로 바꿀 때, 결정론적인 제어 흐름이 사라지면서 고통스러운 문제들이 터져 나온다. 하위 서비스가 에러를 뱉을 때 LLM은 이를 해결해야 할 과제로 인식하고 같은 도구를 영원히 호출한다. 밤사이에 야간 6시간 동안 재귀 호출이 돌면서 4200달러짜리 API 요금 청구서를 받아보면 머리가 하얗게 된다. 최신 추론형 모델은 내부 사고 토큰을 엄청나게 소비하므로 단순한 출력 토큰 제한으로는 버틸 수 없다.

1. 재귀 호출 한계를 강제로 걸어두기

ReAct 루프 안에서 에이전트는 에러를 만날 때마다 스스로 수습하려다 무한 루프에 빠진다. 지원 에이전트 배포 과정에서 CRM 도구 연동이 깨지면서 야간 동안 수천 번의 토큰 요청이 발생해 수백만 원의 비용이 순식간에 날아간 사례가 있다. 출력 토큰 제한만 걸어두는 방식은 사고 토큰 폭발을 막지 못한다.

상태 머신 그래프 자체에 하드 리미트를 박아야 한다.

  • 상태 머신 정의 파일에서 recursion_limit을 10 이하로 낮춘다.
  • 남은 허용 스텝 수가 2 이하로 떨어지면 도구 실행 에지를 우회해 폴백 노드로 바로 꺾어버린다.
  • GraphRecursionError를 잡아서 마지막으로 정상 작동했던 체크포인트 기반으로 응답을 돌려주는 반응적 크래시 가드를 심는다.

이 세 가지를 적용하면 무한 루프 비용 폭발을 확실하게 차단할 수 있다.

2. 지연 로딩으로 컨텍스트 비대화 막기

처음 에이전트 코드를 짤 때 가용한 모든 엔드포인트 정의와 대화 히스토리를 시스템 프롬프트에 통째로 때려 넣기 쉽다. 도구 정의만으로 134,000 토큰을 상시 먹고 들어가는 환경에서는 프리필 연산량이 폭증해 첫 토큰 생성 시간인 TTFT가 수 초 이상으로 늘어난다. 노이즈가 늘어나면서 최상위 모델의 도구 선택 정확도가 74퍼센트에서 49퍼센트까지 고꾸라진다.

도구 메타데이터만 먼저 던져주는 지연 로딩 파이프라인을 구축해야 한다.

  • 도구 등록 시 이름과 간략한 설명이 담긴 초경량 메타데이터 인덱스만 초기 시스템 프롬프트에 올린다.
  • 에이전트가 특정 도구를 쓰겠다고 결정할 때만 상세 파라미터 JSON Schema를 동적으로 메모리에 불러온다.
  • 활성화된 스키마만 골라서 실행 페이로드를 조립한다.

이렇게 바꾸면 초기 메모리 소비량을 절반 이하로 줄이고 TTFT를 눈에 띄게 단축할 수 있다.

3. 스키마 검증 레이어로 잘못된 도구 호출 잡기

에이전트끼리 주고받는 환경에서는 오케스트레이터가 만든 자연어 중간 결과물이 하위 서비스의 입력 스키마와 안 맞아서 깨지는 일이 허다하다. 문자열이 들어가야 할 자리에 정수가 박히거나 UUID 필드가 통째로 빠지는 포맷 불일치는 하위 서비스를 바로 다운시킨다. Klarna는 정형화된 상태 그래프와 검증 체계를 도입해 월 230만 건의 대화를 처리하면서 평균 고객 문의 해결 시간을 82퍼센트 줄였다.

모든 도구 호출 지점에 타입 검증 게이트웨이를 박아두어야 한다.

  • Pydantic v2 모델로 주문 식별자, 취소 사유 코드, 환불 승인 금액의 필드 제약 조건을 엄격하게 정의한다.
  • LLM 인자 생성 함수를 감싸는 3회 상한 루프를 돌려 입력 페이로드를 검증한다.
  • ValidationError가 터지면 에러 필드와 원인을 골라내 모델에 다시 집어넣는 자가 교정 예외 핸들링 루프를 실행한다.

이 구조를 만들어두면 엉뚱한 도구 호출로 인한 시스템 다운타임을 깔끔하게 막을 수 있다.

4. 분산 회로 차단기로 연쇄 장애 끊어내기

하위 레거시 API가 뻗어버리면 메인 에이전트의 워커 스레드는 네트워크 타임아웃을 기다리다 그대로 멈춘다. 초당 수백 건이 몰리는 운영 환경에서는 단 6분 만에 워커 풀 커넥션 50개가 전부 바닥나면서 서비스 전체가 먹통이 된다. DoorDash는 중앙 집중식 에이전트 게이트웨이를 세워 200개 이상의 도구 접근을 제어하고 환각 발생률을 90퍼센트 낮췄다.

에이전트 호출 레이어에 분산 회로 차단기를 얹어야 한다.

  • 연속 실패 횟수 임계값을 3회로 잡고 60초 쿨다운 세팅을 포함하는 비동기 회로 차단기 클래스를 짠다.
  • 타임아웃이나 커넥션 거부 같은 인프라 결함일 때만 실패 카운트를 올리고, 단순 클라이언트 에러는 카운트에서 제외한다.
  • 회로가 열린 상태에서는 원격지 호출을 막아버리고 0밀리초 지연으로 캐시된 폴백 응답을 즉시 뱉어낸다.

이렇게 하면 한쪽이 무너져도 전체 시스템이 연쇄적으로 다운되는 참사를 막을 수 있다.