AI 에이전트의 도구 사용 제한: 아키텍처 선택에 따른 비용

제조업 ERP에서 AI 에이전트를 사용하여 공급망 통합을 자동화하려고 시도했을 때, 처음에는 모든 것이 완벽해 보였습니다. 에이전트는 들어오는 주문을 분석하고, 재고 수준을 확인하며, 필요한 경우 새로운 원자재 주문을 위해 공급업체 API를 호출하고, 생산 계획을 업데이트해야 했습니다. 서류상으로는 이 흐름을 통해 수동 개입을 70% 줄일 수 있었습니다.

하지만 도구 사용 (Tool-use) 부분, 즉 에이전트가 외부 세계와 상호 작용해야 하는 상황에 직면했을 때, 기대했던

우리가 이 기능에 대해 갖는 일반적인 기대치는 에이전트가 인간처럼 사고하고, 적절한 시점에 적절한 도구를 사용하여 문제를 해결할 수 있다는 것입니다. 하지만 현실에서는 에이전트에게 제공되는 도구의 품질, 도구에 대한 설명(description), 그리고 에이전트가 이러한 도구들을 어떻게 해석하느냐가 성공의 기초가 됩니다. 만약 도구 설명이 불완전하거나 에이전트가 문맥(context)을 올바르게 이해하기 위한 충분한 정보가 부족하다면, 에이전트는 "환각 (hallucinate)"을 일으켜 잘못된 매개변수(parameter)로 잘못된 도구를 호출할 수 있습니다. 한 번은 사이드 프로젝트의 금융 계산기에서, 도구 설명이 충분히 구체적이지 않았기 때문에 에이전트가 get_dollar_exchange_rate 대신 get_euro_exchange_rate 도구를 호출하여 잘못된 계산을 수행한 적이 있습니다.

[
  {
    "name": "get_stock_level",
...

위와 같이 명확한 도구 정의는 에이전트가 올바른 도구를 선택하는 것을 더 쉽게 만듭니다. 그렇지 않으면, 에이전트가 "주문하기 (place order)" 명령을 감지했을 때 재고를 확인하지 않고 직접 주문을 시도할 수 있으며, 이는 제조 환경에서 심각한 오류로 이어질 수 있습니다. 따라서 도구는 기술적 측면뿐만 아니라 워크플로 (workflow) 관점에서도 올바르게 정의되어야 하며, 모든 예외 상황 (edge case)이 고려되는 것이 매우 중요합니다.

아키텍처 선택 1: 모놀리식 (Monolithic) vs. 마이크로서비스 (Microservice) 도구 아키텍처

AI 에이전트에게 제공할 도구를 설계할 때 제가 직면한 첫 번째 주요 아키텍처 결정은 이 도구들을 어떻게 구성하느냐였습니다. 즉, 이들을 모놀리식 (monolithic) 구조 아래 그룹화해야 할까요, 아니면 각 도구를 개별적인 마이크로서비스 (microservice)로 실행해야 할까요? 이 결정은 운영 비용, 특히 크고 복잡한 엔터프라이즈 시스템에서 직접적인 영향을 미칩니다.

처음에 제조 ERP (manufacturing ERP)를 구축할 때, 저는 모든 내부 API (API)와 데이터베이스 (database) 작업을 단일 RESTful 엔드포인트 (endpoint) 아래로 통합하여 에이전트에게 "하나의 커다란 도구"를 제공하는 방식을 고려했습니다. 모든 도구가 동일한 코드베이스 (codebase) 내에서 정의되고 관리되기 때문에 개발 속도가 빨라질 것처럼 보였습니다. 하지만 저는 이것이 확장성 (scalability)과 유지보수 (maintenance) 측면에서 병목 현상 (bottleneck)이 될 것이라는 사실을 곧 깨달았습니다. 예를 들어, 하루에 10,000번 호출되는 get_stock_level 도구가 거의 사용되지 않는 "신규 공급업체 추가" 도구와 동일한 모놀리식 서비스 (monolithic service) 내에 존재했습니다. 재고 조회 서비스의 속도 저하(예: N+1 쿼리 오류로 인한 발생)는 모든 도구 사용 능력에 영향을 미쳤습니다.

ℹ️ 경험 (Experience)

한 고객 프로젝트에서, 모놀리식 도구 서비스의 응답 시간은 약 1.5초였습니다. 재고 조회 서비스를 별도의 FastAPI 마이크로서비스 (microservice)로 분리하고 PostgreSQL의 인덱스 (index)를 최적화한 후, 응답 시간을 150ms로 단축했습니다. 이를 통해 에이전트는 더 빠르게 의사결정을 내릴 수 있었고, 전체 워크플로 (workflow)를 25% 더 빠르게 완료했습니다.

마이크로서비스 (microservice) 접근 방식을 사용하면, 각 도구 또는 관련 도구 그룹이 자체적인 독립 서비스에서 실행됩니다. 이를 통해 각 서비스는 고유한 리소스 (resource)를 가질 수 있고, 독립적으로 확장 (scale)할 수 있으며, 오류를 격리 (isolate)할 수 있습니다. 예를 들어, StockManagementService와 SupplierOrderService는 별도로 실행됩니다. 이러한 분리는 하나의 서비스가 충돌하거나 느려지더라도 다른 서비스에 영향을 주지 않도록 방지합니다. 제 개인 사이드 프로젝트의 백엔드 (backend)에서도 사용자 데이터를 관리하는 도구와 금융 계산 도구는 별도의 서비스에서 실행됩니다. 이렇게 하면 금융 계산에 과부하가 걸리더라도 기본적인 사용자 작업에는 영향을 주지 않습니다. 하지만 이 방식은 더 많은 운영 관리 및 모니터링 오버헤드 (overhead)를 수반합니다. 즉, 분산 시스템 (distributed systems)의 복잡성을 다뤄야 합니다. 각 서비스는 자체적인 CI/CD 파이프라인 (pipeline), 자체적인 로깅 (logging) 및 메트릭 (metrics) 시스템을 갖게 됩니다.

아키텍처 선택 2: 도구 오케스트레이션 (Tool Orchestration) 및 상태 관리 (State Management)

AI 에이전트가 도구를 순차적으로 호출하고 그 사이의 상태(State)를 관리하는 방식은 에이전트가 복잡한 작업을 성공적으로 완료하기 위한 핵심적인 아키텍처 결정 사항입니다. 이 결정은 오류 관리(Error Management), 디버깅 비용, 그리고 에이전트의 전반적인 "추론 (Reasoning)" 능력에 직접적인 영향을 미칩니다. 여기에는 두 가지 주요 접근 방식이 있습니다: LLM 자체가 오케스트레이션 (Orchestration)을 처리하거나, 외부 오케스트레이터 (External Orchestrator)를 사용하는 것입니다.

LLM 주도형 오케스트레이션 (LLM-driven orchestration)은 에이전트가 도구 호출 과정에 자신의 "사고" 능력을 직접 반영함을 의미합니다. 프롬프트 엔지니어링 (Prompt Engineering)을 통해 에이전트에게 "계획 (Planning)" 능력을 부여하며, 에이전트는 어떤 도구를 언제 호출할지 스스로 결정합니다. 예를 들어, 생산 계획을 수립할 때 get_stock_level을 호출한 다음, get_supplier_prices를 호출하고, 이어서 calculate_production_plan 도구를 순차적으로 호출할 것으로 기대됩니다. 이 방식은 유연성을 제공하지만, 에이전트가 내용을 "망각"하거나 "환각 (Hallucination)"을 일으킬 위험도 수반합니다. 한 고객 프로젝트에서는 에이전트가 이전 단계의 문맥(Context)을 놓치는 바람에 4단계에서 호출해야 할 도구를 건너뛰고 바로 결과를 생성하려고 시도한 사례가 있었습니다. 이는 LLM의 토큰 제한 (Token Limits)이나 프롬프트의 복잡성으로 인해 발생할 수 있습니다.

반면, 외부 오케스트레이터를 사용하는 것은 에이전트가 "어떤 도구를 어떤 파라미터 (Parameters)로 호출할지"만 제안하도록 하고, 실제 호출 순서와 상태 관리 (State Management)는 별도의 서비스나 워크플로 엔진 (Workflow Engine)에 맡기는 것을 의미합니다. 예를 들어, ProductionWorkflowService가 에이전트로부터 제안을 받으면, 비즈니스 규칙에 따라 이를 순서화하고, 도구를 호출하며, 그 결과를 에이전트에게 반환합니다. 이 접근 방식은 더욱 견고하고 결함 허용 (Fault-tolerant) 능력이 있는 시스템을 구축할 수 있게 해줍니다. 트랜잭션 아웃박스 (Transaction Outbox) 패턴을 사용하면 도구 호출이 멱등성 (Idempotent)을 갖도록 보장할 수 있습니다. 즉, 동일한 도구가 여러 번 호출되더라도 시스템 상태가 변하지 않음을 의미합니다.

# 간단한 외부 오케스트레이터 의사 코드 (Pseudo-code)
def orchestrate_production_plan(agent_suggestion):
    if agent_suggestion.tool_name == "get_stock_level":
...

이러한 외부 오케스트레이터 (external orchestrator) 접근 방식은 복잡한 워크플로 (workflows)에서 에이전트가 오류를 범할 가능성을 줄여주지만, 오케스트레이션 로직 자체가 유지보수와 테스트가 필요한 별도의 코드베이스가 되어야 한다는 비용을 발생시킵니다. 하지만 제 경험상, 특히 금융 거래와 같은 중요한 흐름에서는 이러한 추가 비용이 에이전트의 예측 불가능한 행동으로 인해 발생할 수 있는 잠재적 비용보다 훨씬 낮았습니다.

보안 및 격리: 도구 사용의 어두운 면

AI 에이전트의 도구 사용 (tool-use) 능력은 의심할 여지 없이 강력한 힘을 제공하지만, 이 힘은 상당한 보안 리스크도 동반합니다. 에이전트가 외부 시스템과 상호작용하는 과정은 악의적이거나 잘못된 도구 호출 (tool calls)로 이어지는 통로를 열어줄 잠재적 위험이 있습니다. 따라서 프로덕션 (production) 환경에서는 에이전트의 도구 호출을 안전하게 관리하는 것이 매우 중요합니다.

가장 단순한 시나리오에서도, 에이전트는 실수로 또는 프롬프트 인젝션 (prompt injection)으로 인해 권한이 없는 API에 접근을 시도할 수 있습니다. 저는 한 은행의 내부 플랫폼에서 분석 에이전트가 읽기 권한만 가지고 있어야 함에도 불구하고 update_user_data 도구를 호출하려고 시도하는 것을 목격했습니다. 이러한 상황을 방지하기 위해, 우리는 모든 도구 호출에 대해 인가 메커니즘 (authorization mechanisms, OAuth2/JWT)을 엄격하게 적용해야 합니다. 에이전트가 어떤 도구를 호출하기 전에, 필요한 권한을 가지고 있는지 확인하는 것은 기본적인 보안 계층입니다.

⚠️ 중요 참고 사항

LLM (Large Language Models)의 내재적인 "환각 (hallucination)" 위험으로 인해, AI 에이전트의 도구 사용 능력은 예상치 못하고 잠재적으로 해로운 도구 호출을 초래할 수 있습니다. 따라서 모든 도구 호출은 마치 악의적인 사용자가 보낸 것처럼 취급되어야 하며, 엄격한 입력 검증 (input validation) 및 인가 확인 (authorization checks)을 거쳐야 합니다.

나아가, DDoS(분산 서비스 거부 공격) 또는 리소스 고갈 (resource exhaustion)의 위험도 존재합니다. 에이전트가 잘못된 파라미터 (parameters)를 사용하여 API에 과도한 요청을 보냄으로써 서비스를 다운시킬 수도 있습니다. 제가 진행했던 사이드 프로젝트 중 하나에서는, 개발 단계에서 한 AI 에이전트가 내부 서비스에 초당 150회의 속도로 요청을 보내 약 28초 만에 서비스를 다운시킨 사례가 있었습니다. 저는 이를 fail-safe 메커니즘으로 해결했습니다. 즉, 5분 이내에 특정 IP 또는 에이전트 ID (agent ID)로부터 5번의 실패가 발생하면 1시간 동안 차단하는 규칙을 구현했습니다. 이를 통해 서비스를 보호하는 동시에, 에이전트가 오류를 범할 때 발생하는 비용을 줄일 수 있었습니다.

커널 모듈 블랙리스트 (kernel module blacklisting)와 같은 더 깊은 수준의 보안 조치도 고려해야 합니다. 예를 들어, 에이전트가 코드 실행 (code execution) 능력을 갖추고 있다면, algif_aead와 같은 특정 모듈을 블랙리스트에 등록함으로써 잠재적인 CVE (취약점)로부터 추가적인 보호 계층을 제공할 수 있습니다. 또한, Docker 컨테이너를 사용하여 에이전트가 실행되는 환경을 격리하고 cgroup 제한 (cgroup limits)을 설정함으로써, 에이전트의 리소스 소비를 제한하여 다른 시스템 구성 요소를 보호할 수 있습니다. 제가 memory.high를 사용하여 컨테이너의 소프트 메모리 제한 (soft memory limit)을 2GB로 설정했을 때, 에이전트가 결함이 있는 동작으로 4GB의 메모리를 소비하려고 시도하는 것을 방지하여 OOM-kill (Out Of Memory kill)이 발생하게 했고, 결과적으로 메인 애플리케이션의 안정성을 유지하는 데 도움이 되었습니다.

비용 최적화: LLM 제공업체 선택 및 폴백 (Fallback) 전략

도구 호출 (tool calls)을 해석하고 의사 결정을 내리는 AI 에이전트용 LLM (대규모 언어 모델)의 선택은 성능과 비용 모두에 있어 매우 중요합니다. 시장에는 Gemini Flash, Groq, Cerebras, OpenRouter와 같이 각기 다른 장단점을 가진 다양한 LLM 제공업체들이 있습니다. 제 경험상, 단일 제공업체에만 의존하는 대신 이러한 제공업체들을 전략적으로 조합하는 것이 비용을 절감하고 시스템 회복 탄력성 (resilience)을 높이는 데 도움이 되었습니다.

예를 들어, AI 기반 금융 계산기에서 저는 사용자의 자연어 질의(예: "100,000 TL에 대해 5년 기간의 인플레이션 조정 수익률을 계산해줘")를 도구 호출 (tool calls)로 변환하기 위해 LLM을 사용합니다. 이 시나리오에서는 사용자가 즉각적인 응답을 기대하기 때문에 지연 시간 (latency)이 매우 중요했습니다. Groq의 높은 처리 속도와 낮은 비용($0.0002/1k tokens)은 이러한 시나리오에 이상적이었습니다. 저는 일반적으로 300ms 이내에 응답을 받았습니다. 하지만 더 복잡하고 빈도가 낮은 생산 계획 최적화의 경우에는 Gemini Pro($0.002/1k tokens)를 선호했습니다. 이는 더 비싸지만 더 포괄적인 모델로, 여기서는 지연 시간보다 정확도와 복잡한 추론 (reasoning)이 더 중요했기 때문입니다.

💡 멀티 제공업체 전략 (Multi-Provider Strategy)

특정 워크로드에 따라 서로 다른 LLM 제공업체를 할당하면 비용을 최적화하고 단일 제공업체에 대한 의존도를 낮출 수 있습니다. 한 제공업체를 사용할 수 없게 되면, 자동 폴백 (fallback) 메커니즘이 작동하여 중단 없는 서비스를 보장합니다.

멀티 제공업체 전략의 또 다른 중요한 장점은 회복 탄력성 (resilience)입니다. 한 제공업체를 사용할 수 없게 될 경우를 대비해, 저는 다른 제공업체로 자동 전환되는 폴백 메커니즘을 구현했습니다. OpenRouter와 같은 플랫폼은 이러한 종류의 오케스트레이션 (orchestration)을 용이하게 합니다. 제 시스템에서는 기본 제공업체로부터 500ms 이내에 응답을 받지 못하거나 API 오류가 반환되면, 자동으로 보조 제공업체로 전환하는 로직이 마련되어 있습니다. 이러한 방식을 통해 저는 금융 계산기의 99.99% 가동 시간 (uptime) 목표를 달est할 수 있었습니다. 이 폴백 메커니즘 덕분에 Groq이 2시간 동안 짧게 중단되었을 때도 사용자들은 서비스 중단을 경험하지 않았으며, 응답 시간이 평균 500ms 증가했을 뿐이었습니다.

이러한 아키텍처 선택은 초기에 약간 더 많은 통합 노력이 필요했지만, 장기적으로 운영 비용(토큰 비용이 약 70% 감소하는 것을 확인했습니다)과 시스템의 전반적인 신뢰성을 크게 향상시켰습니다.

운영 과제 및 관찰 가능성 (Observability)