자율적인 AI 에이전트들은 서로 대화하는 것을 좋아하지만, 결국 순환 피드백 루프 (cyclic feedback loop)에 빠져 10분 만에 API 예산을 바닥내버리곤 합니다. 여기 SpaceAI360에서 사용하는 결정론적 오케스트레이션 (deterministic orchestration) 패턴을 소개합니다.

개발자들이 멀티 에이전트 (multi-agent) AI 시스템을 구축하기 시작할 때, 데모는 언제나 마법처럼 보입니다.

콘텐츠 초안을 작성하는 에이전트 A (Researcher), 이를 비평하는 에이전트 B (Reviewer), 그리고 실행을 라우팅하는 코디네이터 (Coordinator)를 설정합니다. 3번의 테스트 실행을 거친 로컬 터미널에서는 완벽하게 작동합니다.

그러다 이를 프로덕션 (production) 환경에 배포하게 됩니다.

SpaceAI360에서 우리는 LLM (Large Language Model)에게 상태 실행 (state execution)에 대한 완전한 자율성을 부여하면, 모델이 문제를 해결할 뿐만 아니라 무한히 협상(negotiate)을 시도한다는 사실을 고통스러운 경험을 통해 배웠습니다.

예외 케이스 페이로드 (edge case payload)가 도착하면, 에이전트 A는 모호한 응답을 생성하고, 에이전트 B는 모호한 피드백과 함께 이를 거절하며, 에이전트 A는 정확히 동일한 페이로드를 다시 보내며 이를 수정하려고 시도합니다.

알림 모니터링이 이를 감지하기도 전에, 에이전트들은 4분 동안 120번의 루프를 돌며 제3자 API의 속도 제한 (rate limits)에 걸리고, 토큰 비용으로 40달러를 태워버립니다.

만약 당신이 2026년에 에이전트 워크플로우 (agentic workflows)를 구축하고 있다면, 에이전트가 스스로 "알아서 해결하도록" 맡겨두어서는 안 됩니다. 결정론적인 안전 경계 (deterministic safety boundaries)가 필요합니다.

다음은 우리가 프로덕션 시스템에서 에이전트 데드락 (agent deadlocks)과 무한 루프를 제거한 방법입니다.

1. 에이전트가 루프 종료를 제어하게 두지 마세요. 초기 에이전트 아키텍처에서 가장 큰 실수는 LLM이 작업이 "끝났는지"를 결정하게 만드는 것입니다.

만약 당신의 코드가 다음과 같다면:

// 나쁜 예: LLM이 중단 신호를 출력하기를 기대함
while (!response.includes("TASK_COMPLETE")) {
...

이는 프로덕션 장애를 자초하는 일입니다. 만약 모델이 환각 (hallucination)을 일으키거나 출력 형식을 약간 변경한다면 (예: "TASK_COMPLETE" 대신 "Task Completed"라고 작성), 당신의 while 루프는 서버가 타임아웃되거나 지갑이 비워질 때까지 계속 실행될 것입니다.

해결책: 엄격한 상태 머신 경계 (Hard State-Machine Boundaries)

모든 멀티 에이전트 워크플로우 (multi-agent workflow)는 결정론적 상태 머신 (deterministic state machine)으로 감싸져야 합니다 (LangGraph 또는 커스텀 TypeScript red/green 실행 그래프와 같은 도구 사용).

// GOOD: 엄격한 실행 제한 및 명시적 상태 전이 (explicit state transitions)
const MAX_AGENT_HOPS = 5;
...

만약 에이전트가 3~5회의 홉 (hops) 내에 작업을 해결하지 못한다면, 10회의 홉을 더 준다고 해서 문제가 해결되는 경우는 거의 없습니다. 실행을 조기에 중단하고 폴백 (fallback) 처리하십시오.

1. 모호한 비판 루프 (Vague Critique Loops) 제거
   "이 출력을 검토하고 필요하면 수정을 요청하세요"와 같은 지침을 사용하여 "검토자/비판자 (Reviewer/Critic)" 에이전트를 사용할 경우, 끝없는 핑퐁 매치 (ping-pong matches)가 발생합니다.

에이전트 B가 사소한 서식 문제를 지적하면, 에이전트 A가 전체 페이로드 (payload)를 다시 작성하게 되고, 이 과정에서 다른 제약 조건이 깨지면서 에이전트 B가 다시 거부하는 상황이 반복됩니다.

해결책: 구조화된 스키마 거부 (Structured Schema Rejection) (Zod / JSON Schema)
검토자가 자유 형식의 텍스트 피드백을 작성하게 두는 대신, 검토 단계에서 엄격한 Zod 스키마를 반환하도록 강제하십시오:

import { z } from "zod";

...

approved가 false인 경우, errorCode와 specificFixRequired만 에이전트 A에게 다시 전달하십시오. 전체 대화 기록 (conversational history)을 컨텍스트 윈도우 (context window)에 다시 넣지 마십시오. 컨텍스트를 깨끗하게 유지하는 것이 혼란을 방지합니다.

2. API 게이트웨이에 서킷 브레이커 (Circuit Breaker) 구현
   애플리케이션 코드가 훌륭하더라도, 높은 동시성 (high concurrency) 상황에서 처리되지 않은 프로미스 거부 (unhandled promise rejections)나 레이스 컨디션 (race conditions)이 에이전트 스레드 (agent threads)를 얼려버릴 수 있습니다.

우리는 모든 에이전트 파이프라인에 대해 Redis에서 계정 수준의 서킷 브레이커 (Account-Level Circuit Breaker)를 강제합니다:

• 실행당 토큰 캡 (Token Cap per Execution): 단일 트리거 이벤트가 참여하는 모든 에이전트를 통틀어 총 25,000 토큰 이상을 소비할 수 없습니다.
• 비용 가드레일 (Cost Guardrails): 실행 스레드의 누적 API 호출 비용이 $0.15를 초과하면, 게이트웨이는 즉시 소켓을 차단하고 진단 트레이스 (diagnostic trace)를 로그에 남깁니다.

요약 아키텍처 체크리스트

올해 멀티 에이전트 워크플로우를 프로덕션 환경으로 전환하려 한다면:

• 엄격한 재귀 제한 (recursion limits)을 설정하십시오 (maxHops <= 5).
• 에이전트 간에 가공되지 않은 채팅 기록 (raw chat histories)을 절대 전달하지 마십시오. 대신 검증된 JSON 상태 페이로드 (validated JSON state payloads)를 전달하십시오.

리뷰어 에이전트 (reviewer agents)에 Zod 스키마를 사용하여 피드백이 결정론적 (deterministic)이고 실행 가능하도록 (actionable) 만드십시오.

네트워크 또는 Redis 레벨에서 엄격한 토큰/비용 차단기 (circuit breakers)를 강제하십시오.

에이전트 (Agents)는 추론 (reasoning)에 뛰어나지만, 실행 흐름 (execution flow)에 대한 제어권은 항상 순수 코드 (pure code)가 유지해야 합니다.

귀하의 팀은 에이전트 워크플로 (agentic workflows)에서 제어 불능의 실행 루프 (runaway execution loops)를 어떻게 방지하고 있습니까? LangGraph, 커스텀 상태 머신 (custom state machines), 또는 큐 기반 워커 (queue based workers)를 사용하고 계신가요? 아래 댓글에서 함께 논의해 봅시다!

Shahdin Salman

SpaceAI360 창립자

우리는 고성능 웹 애플리케이션, 회복 탄력성이 있는 백엔드 아키텍처 (resilient backend architectures), 그리고 프로덕션급 자동화 시스템을 구축합니다.