예산 초과 없이 에이전트 네이티브 앱 구축하기: 격리된 AI 에이전트 아키텍처를 위한 실용적 패턴

Originally published on tamiz.pro.

AI agents는 현대 소프트웨어에서 가장 강력하고 가장 비용이 많이 드는 기본 요소(primitive)입니다. 탐색(explores), 계획(plans), 도구 호출(calls tools), 재시도(retries), 합성(synthesizes)을 수행하는 단일 에이전트 루프가 몇 시간 만에 한 달치 API 예산을 소진할 수 있으며, 청구서가 도착하기 전까지는 모니터링으로 이를 포착하기 어렵습니다. 핵심 엔지니어링 과제는 역량이 아니라 격리(containment)입니다. 어떻게 하면 에이전트에게 복잡한 작업을 완수할 자율성을 부여하면서도, 통제 불능의 루프가 운영 예산(runway)을 액화시키지 않도록 보장할 수 있을까요?

본 심층 분석은 격리되고(sandboxed), 예산 인식이 가능한 AI 에이전트 아키텍처를 구축하기 위한 5가지 실제 검증된 패턴들을 다루며, 완벽한 구현 코드, 아키텍처 다이어그램, 그리고 비용을 예측 가능하게 유지하면서도 에이전트의 효과성을 보존하는 데 필요한 운영 지표(operational metrics)까지 제공합니다.

목차

• 1. 에이전트 비용 문제: 예산이 실제로 소진되는 곳
• 2. 패턴 1: 계층적 컴퓨팅 격리 (Tiered Compute Isolation)
• 3. 패턴 2: 회로 차단기(Circuit Breakers)를 사용한 토큰 예산 책정
• 4. 패턴 3: 격리된 도구 실행 (Sandboxed Tool Execution)
• 5. 패턴 4: 시맨틱 캐싱 및 중복 제거 (Semantic Caching and Deduplication)
• 6. 패턴 5: 점진적 에스컬레이션 (Progressive Escalation)
• 7. 참조 아키텍처: 모든 것을 하나로 통합하기
• 8. 구현: 샌드박스 오케스트레이터 (The Sandbox Orchestrator)
• 9. 운영 지표 및 경고 알림 (Operational Metrics and Alerting)
• 10. 자주 묻는 질문 (Frequently Asked Questions)

1. 에이전트 비용 문제: 예산이 실제로 소진되는 곳

해결책을 깊이 파고들기 전에, 에이전트 비용이 어디에 축적되는지에 대한 정확한 정신 모델(mental model)이 필요합니다. 단순한 요청-응답 API 호출과 달리, 에이전트는 루프를 수행합니다: 계획 → 행동 → 관찰 → 재계획. 각 반복은 여러 채널을 통해 비용을 동시에 증폭시킵니다.

비용 곱셈 분류법 (The Cost Multiplication Taxonomy)

해결책은 에이전트의 능력을 줄이는 것이 아니라, 에이전트가 엄격한 재정적 경계 내에서 자율적으로 작동할 수 있도록 하는 격리 계층(containment layers)을 구축하는 것입니다.

2. 패턴 1: 단계별 컴퓨팅 격리 (Tiered Compute Isolation)

개념 (Concept)

모든 에이전트 작업이 동일한 컴퓨팅 자원을 누릴 필요는 없습니다. 단순 요약 작업과 다단계 연구 작업은 근본적으로 다른 비용 프로파일을 가집니다. 단계별 컴퓨팅 격리는 작업 복잡도에 따라 각 에이전트 호출을 리소스 계층(resource tier)에 할당하며, 각 계층마다 엄격한 상한선(hard ceilings)을 설정합니다.

                    ┌─────────────────────────┐
                    │   작업 복잡도 (Task Complexity)       │
                    │   분류기 (Classifier)            │
... 

구현 (Implementation)

이 분류기 자체는 경량 모델 호출입니다. 작은/빠른 모델에게 작업을 분류하도록 요청하는 단일 프롬프트만 필요합니다. 이는 실제 작업 비용의 극히 일부만을 차지하므로 경제적으로 타당합니다.

from dataclasses import dataclass
from enum import Enum
import time
...

핵심 통찰은 다음과 같습니다: 분류 호출 자체는 약 50100 토큰의 비용이 들지만, 이는 이 호출이 관리하는 2,00050,000 토큰 예산에 비해 무시할 만한 수준입니다. 달러를 태우지 않기 위해 페니(pennies)만 지출합니다.

계층 기반 모델 라우팅 (Tier-Based Model Routing)

각 계층은 에이전트가 사용할 수 있는 모델을 제한합니다. 마이크로 작업(Micro tasks)은 가장 저렴하면서도 충분한 능력을 가진 모델로 이동합니다. 확장된 작업(Extended tasks)은 프리미엄 모델에 접근할 수 있지만, 오직 에이전트의 추론이 실제로 그로부터 이익을 얻는 경우에만 가능하며 — 이는 모델 출력을 비교하는 품질 게이트(quality gate)를 통해 강제됩니다.

3. 패턴 두 가지: 회로 차단기를 이용한 토큰 예산 책정 (Token Budgeting with Circuit Breakers)

개념 (Concept)

회로 차단기(circuit breaker)는 분산 시스템에서 발생하는 연쇄적인 실패를 방지하는 신뢰성 패턴입니다. 이를 에이전트의 토큰 예산에 적용하면, 소비 속도를 모니터링하고 지출액이 안전 임계값을 초과할 경우 작동하여, 예산이 고갈되기 전에 에이전트 루프를 중단시킵니다.

회로 차단기는 세 가지 상태를 가집니다:

1. CLOSED (닫힘) — 정상 작동 상태입니다. 토큰은 추적되지만 개입(intervention)은 발생하지 않습니다.
2. HALF-OPEN (반개방) — 예산 임계값에 도달한 경우(예: 70%). 에이전트는 계속 진행할 수 있지만, 기능이 축소됩니다(더 적은 도구, 더 작은 컨텍스트 창).
3. OPEN (열림) — 하드 예산을 초과한 경우입니다. 에이전트 루프가 즉시 종료됩니다. 부분적인 결과는 상태 플래그와 함께 반환됩니다.

구현 (Implementation)

import time
from dataclasses import dataclass, field
from enum import Enum
...

속도 기반 제한 (Velocity-Based Throttling)

속도 확인(velocity check)은 보호의 두 번째 축을 추가합니다. 전체 예산에 도달하지 않았더라도, 갑작스러운 토큰 소비 급증(통제 불능 루프를 나타냄)이 발생하면 스로틀링(throttling)이 트리거됩니다. 이는 에이전트가 몇 초 만에 큰 예산을 고갈시킬 수 있는 병리적인 재시도 루프(pathological retry loop)에 진입하는 시나리오를 포착합니다.

4. 패턴 세 가지: 샌드박스 도구 실행 (Sandboxed Tool Execution)

개념 (Concept)

에이전트 도구는 비용 초과가 발생할 수 있는 가장 위험한 구성 요소입니다. 대용량 페이로드(예: HTML 50KB를 반환하는 웹 검색)를 반환하는 도구, 외부 부작용을 유발하는 도구(예: 이메일 전송), 또는 내부적으로 루프를 반복하는 도구(예: 재귀적 파일 프로세서)는 각각 독립적으로 예산 한도를 초과할 수 있습니다.

샌드박스 도구 실행은 모든 도구 호출에 리소스 제약 조건(output size limits, execution time limits, retry limits, side-effect gates)을 래핑합니다.

구현 (Implementation)

import asyncio
import hashlib
import json
...

부작용 게이팅 (Side-Effect Gating)

영구적인 부작용(이메일 전송, 결제 처리, 데이터베이스 수정 등)을 발생시키는 도구의 경우, 확인 게이트(confirmation gate)를 추가해야 합니다. 에이전트는 도구가 실행되기 전에 예상되는 동작과 일치하는 구조화된 확인 응답을 생성해야 합니다:

class SideEffectGate:
    """부작용 도구를 실행하기 전에 명시적인 확인을 요구합니다."""

...

5. 패턴 네 개: 의미론적 캐싱 및 중복 제거 (Semantic Caching and Deduplication)

개념 (Concept)

에이전트는 유사한 프롬프트로 반복적인 LLM 호출을 자주 수행합니다. 특히 에이전트가 새로운 정보를 수집한 후 비슷한 질문을 다시 하는 다단계 워크플로우에서 이러한 현상이 두드러집니다. 의미론적 캐싱(Semantic caching)은 이러한 호출을 가로채어, 들어오는 프롬프트가 이전에 답변된 프롬프트와 충분히 유사할 경우 캐시된 결과를 반환합니다.

정확 일치 기반 캐싱(exact-match caching)(프롬프트가 단어 하나만 달라도 실패함)과 달리, 의미론적 캐싱은 임베딩 유사도(embedding similarity)를 사용하여 의미적으로 동등한 쿼리를 매칭합니다.

구현 (Implementation)

import hashlib
import time
from collections import OrderedDict
from dataclasses import dataclass
from typing import Optional

import numpy as np

@dataclass
class CacheEntry:
    embedding: np.ndarray
    response: str
    model: str
    timestamp: float
    hit_count: int = 0
    tokens_saved: int = 0

class SemanticCache:
    """LLM 응답을 위한 임베딩 기반 캐시."""

    def __init__(
        self,
        embedding_model: str = "text-embedding-3-small",
        similarity_threshold: float = 0.92,
        max_entries: int = 1000,
        ttl_seconds: int = 3600,
    ):
        self.embedding_model = embedding_model
        self.similarity_threshold = similarity_threshold
        self.max_entries = max_entries
        self.ttl_seconds = ttl_seconds
        self._cache: OrderedDict[