[태그:] 도구호출

LLM 기반 에이전트 시스템을 구축하는 것과 운영하는 것은 완전히 다른 문제다. 프로토타입은 데이터와 프롬프트로 튜닝되지만, 실제 운영 환경의 에이전트는 신뢰성, 비용, 지연 시간, 보안, 규제 준수 같은 제약 조건들과 싸워야 한다. 따라서 오늘은 LLM 에이전트 아키텍처를 ‘운영 가능한 시스템’으로 재정의하고, 다섯 가지 핵심 레이어와 피드백 루프를 중심으로 설계하는 방법을 상세히 다룬다.

이 글의 목표는 architecture patterns을 기술적으로 설명하는 것이 아니라, 각 레이어가 비용과 신뢰성에 미치는 영향을 명확히 이해하는 것이다. 왜냐하면 아키텍처의 선택이 곧 운영 비용과 장애 시나리오를 결정하기 때문이다. 우리는 각 설계 결정이 가지는 장단점을 명시적으로 파악하고, 조직의 SLA에 맞춰 최적화해야 한다.

목차

• 1. LLM 에이전트의 정의와 운영 관점
• 2. 다섯 가지 아키텍처 레이어 개요
• 3. 레이어 1: 사용자 의도 파싱과 정규화
• 4. 레이어 2: 도구 선택과 계획(Planning)
• 5. 레이어 3: 실행과 오류 처리 메커니즘
• 6. 레이어 4: 상태와 메모리 관리
• 7. 레이어 5: 관측성과 피드백
• 8. 아키텍처와 비용: 각 선택의 대가
• 9. 신뢰성과 복구 전략
• 10. 모니터링과 거버넌스
• 11. 프로덕션 배포 패턴
• 12. 실전 운영: 체크리스트와 90일 로드맵

1. LLM 에이전트의 정의와 운영 관점

LLM 에이전트는 자율적으로 도구를 선택하고 실행하며, 피드백을 받아 다음 행동을 결정하는 시스템이다. 하지만 ‘자율적’이라는 말은 통제 불가능하다는 뜻이 아니다. 오히려 엔드-투-엔드 시스템의 각 지점에서 정책과 제약 조건이 작동해야 한다.

운영 관점에서 보면, 에이전트는 네 가지 부채가 있다. 첫째는 토큰 비용의 증폭인데, 단순 API 호출과 달리 에이전트는 반복적으로 LLM을 호출해서 비용을 곱절로 만든다. 둘째는 예기치 못한 도구 호출 오류로, 권한 없음, 네트워크 오류, 타임아웃 등이 치명적 결과를 낳을 수 있다. 셋째는 상태 불일치로 인한 잘못된 결정인데, 에이전트가 구식 정보로 판단하면 사용자에게 틀린 답을 준다. 넷째는 감시 불가능한 의도 편향으로, 에이전트가 사용자의 진정한 의도를 오해하고 다른 방향으로 갈 수 있다.

이 부채들을 관리하려면, 아키텍처 수준에서 제어점(control point)을 설계해야 한다. In other words, building an agent is not about maximizing capability, but about maximizing controllability while maintaining capability. That is the tension we address in this architecture. 따라서 이 글에서는 각 레이어에서 비용, 신뢰성, 지연을 어떻게 트레이드오프하는지 명확히 제시한다.

2. 다섯 가지 아키텍처 레이어 개요

LLM 에이전트 아키텍처는 다섯 개의 레이어로 구성된다. 각 레이어는 독립적인 설정을 가지고 있으면서도, 전체 루프를 형성한다. 첫 번째 레이어부터 마지막까지 거쳐 다시 처음으로 돌아오는 과정이 하나의 ‘에이전트 턴(turn)’을 이룬다.

레이어의 설계 원칙은 다음과 같다. (1) 각 레이어는 명확한 입력과 출력을 정의한다. 이를 통해 테스트 가능하고 모니터 가능하게 만든다. (2) 각 레이어에서 실패할 수 있다. 따라서 모든 레이어는 실패 처리 로직을 내장해야 한다. (3) 실패 시 대체 경로가 있다. 주 경로가 막혔을 때 부분 성공이라도 제공할 수 있어야 한다. (4) 모든 결정은 기록된다. 이를 통해 사후 분석과 학습이 가능하다.

With this structure, failures are isolated and learning is possible. A failure in one layer does not cascade to destroy the entire agent. Instead, it is handled gracefully and logged for analysis. 이 구조를 따르면, 에이전트는 안정적이면서도 개선 가능한 상태를 유지할 수 있다.

3. 레이어 1: 사용자 의도 파싱과 정규화

첫 번째 레이어는 사용자 입력을 구조화된 의도로 변환하는 과정이다. 자연어 입력은 본질적으로 모호하다. 같은 요청도 여러 해석이 가능하다. 예를 들어, ‘지난 분기 매출 차트를 보여줘’라는 요청은 ‘분기별 매출 추이’를 원할 수도 있고, ‘지역별 매출 분포’를 원할 수도 있고, ‘제품군별 매출’을 원할 수도 있다.

따라서 정규화 단계에서 의도를 명확히 하지 않으면, 이후 모든 결정이 잘못될 수 있다. 도구 선택부터 틀리고, 데이터 쿼리도 틀려진다. 의도 오류가 누적되면, 최종 결과는 사용자가 원한 것과 완전히 다를 수 있다.

정규화는 두 가지 방식으로 나뉜다. 첫째는 LLM 호출을 통한 의도 분류(intent classification)고, 둘째는 규칙 기반 파싱(rule-based parsing)이다. LLM 방식은 유연하지만 비용이 높고 일관성이 낮다. 같은 요청을 두 번 하면 다른 의도로 분류될 수 있다는 뜻이다. 규칙 방식은 확장성이 낮지만 예측 가능하고 비용이 거의 없다. 프로덕션 시스템에서는 둘을 결합한다.

Hybrid approaches work best: use rules for known intents, and fall back to LLM classification for ambiguous cases. This reduces both cost and error rate significantly. 예를 들어, 매출 차트 요청은 규칙으로 처리하고, 복잡한 분석은 LLM에 맡긴다.

또한 이 레이어에서는 의도 거부(intent rejection)도 정의해야 한다. 어떤 요청은 안전하지 않거나 비용 대비 가치가 없을 수 있다. 예를 들어, 전체 고객 데이터 내보내기는 보안 위험이 있고, 매 5초마다 업데이트하는 대시보드는 비용이 너무 높다. 이런 요청을 조기에 거절해야 불필요한 에이전트 턴을 줄일 수 있다. 거절 정책은 문서가 아니라 코드로 표현되어야 한다.

4. 레이어 2: 도구 선택과 계획(Planning)

의도가 명확해지면, 에이전트는 이를 달성하기 위해 어떤 도구를 호출할지 결정해야 한다. 이 선택 과정을 tool selection이라고 하고, 도구들의 순서를 정하는 것을 planning이라고 한다. 둘 다 LLM이 해야 하지만, 제약 조건이 필요하다.

Tool selection의 문제는 다음과 같다. LLM은 사용 가능한 도구를 알고 있지 않거나, 알아도 비용 효율적인 순서를 모른다. 또한 LLM 컨텍스트에 들어가는 도구 설명이 많을수록 토큰 비용이 늘어난다. 100개의 도구 설명을 컨텍스트에 넣으면, 모든 요청의 토큰 비용이 2배가 될 수 있다. 따라서 아키텍처 수준에서 ‘이 의도에는 이 도구 집합만 노출’하는 정책을 두어야 한다.

Planning은 두 가지 전략이 있다. 첫째는 step-by-step planning으로, LLM이 다음 단계를 생각하고, 실행하고, 결과를 보고, 또 다음 단계를 생각한다. 이 방식은 적응력이 높지만 느리고 비용이 많이 든다. 둘째는 multi-step planning으로, 전체 경로를 미리 계획한다. 한 번의 LLM 호출로 일련의 도구 순서를 결정하는 것이다. 이 방식은 빠르지만 오류에 취약하다. Critical workflows에는 전자를, high-volume workflows에는 후자를 사용한다.

Budget-aware planning is critical. Each tool call has a cost (API 비용, 네트워크 지연), and each LLM call to plan also has a cost. Design your planning step to respect cost constraints, not just capability constraints. 즉, 완벽한 계획을 위해 10번의 LLM 호출을 하는 것보다, 80%의 계획으로 2번의 LLM 호출을 하는 것이 나을 수 있다.

5. 레이어 3: 실행과 오류 처리 메커니즘

도구 선택과 계획이 완료되면, 실제로 도구를 호출해야 한다. 이 과정에서 실패는 필연적이다. 도구가 없을 수도 있고, 네트워크가 끊길 수도 있고, 권한이 없을 수도 있고, 타임아웃될 수도 있다. 따라서 실행 레이어는 오류 처리를 최우선으로 설계해야 한다.

오류 처리의 전략은 다음과 같다. (1) Retry with backoff: 일시적 실패는 exponential backoff와 함께 재시도한다. (2) Graceful degradation: 완전한 해결책이 없으면 부분 해결책을 제시한다. 예를 들어, 실시간 데이터를 못 가져오면 캐시된 데이터를 제시한다. (3) Fallback execution: 주 도구가 실패하면 대체 도구를 호출한다. 예를 들어, API가 느리면 캐시를 사용한다. (4) Human escalation: 시스템이 해결할 수 없으면 사람에게 넘긴다.

각 전략은 비용과 신뢰성의 트레이드오프를 만든다. Retry는 시간과 토큰을 낭비한다. Degradation은 품질을 낮춘다. Fallback은 복잡성을 높인다. Human escalation은 신뢰도를 올리지만 스케일에서 떨어진다. SLO에 맞춰 이들을 조합해야 한다.

Execution layer must also track cost per tool. If a tool call exceeds a cost threshold, it should be rejected automatically before it executes, saving both money and latency. 이를 위해 각 도구마다 최대 비용을 정의하고, 예상 비용이 그를 초과하면 경고하거나 거절해야 한다.

6. 레이어 4: 상태와 메모리 관리

에이전트가 여러 도구를 호출하고 결과를 받으면, 그 결과들을 어디에 저장할 것인가? 메모리 관리는 생각보다 복잡하다. 단기 메모리(작업 중 결과)와 장기 메모리(학습할 값어치 있는 정보)를 분리해야 한다.

단기 메모리는 주로 컨텍스트 윈도우에 저장된다. 하지만 컨텍스트 윈도우는 유한하고, 토큰 비용도 증가한다. 따라서 어떤 정보를 컨텍스트에 유지할지 선택해야 한다. 중요한 정보는 유지하고, 반복되는 정보는 요약하거나 제거한다. 예를 들어, 데이터베이스 쿼리 결과는 중요하지만, 쿼리 실행 로그는 필요 없다.

장기 메모리는 벡터 데이터베이스나 그래프 데이터베이스에 저장된다. 여기서 중요한 것은 ‘언제 저장할 것인가’다. 모든 상호작용을 저장하면 데이터가 증폭되고, 검색 성능이 떨어진다. 따라서 ‘학습할 가치’를 판단하는 필터가 필요하다. 예를 들어, 빈번하게 묻는 질문만 저장하고, 일회성 질문은 버린다.

State consistency is the hardest part. If you have distributed memory (cache, database, vector store), you need reconciliation logic. If you have a single source of truth, you need careful locking and eventual consistency handling. 상태 불일치가 생기면, 에이전트는 오래된 정보로 잘못된 결정을 할 수 있다.

7. 레이어 5: 관측성과 피드백

다섯 번째 레이어는 피드백 루프다. 에이전트가 실행한 결과를 측정하고, 그 측정값을 기반으로 다음 턴을 개선한다. 이 루프가 없으면 에이전트는 같은 실수를 반복한다.

피드백은 여러 채널에서 나온다. 첫째는 자동 지표(예: 작업 완료율, 비용, 지연 시간)고, 둘째는 사용자 피드백(예: 만족도, 거부, 수정 요청)이고, 셋째는 감시자의 피드백(예: 정책 위반, 안전 문제)이다. 이 셋을 모두 수집해야 유의미한 개선이 가능하다.

Observability at this layer is not just logging, it is causal inference. You need to understand not only what happened, but why it happened and what caused the outcome. This requires structured logging and cross-layer correlation. 즉, ‘왜 이 의도가 이 도구를 선택했는가’, ‘왜 이 도구 호출이 실패했는가’, ‘왜 최종 결과가 틀렸는가’를 추적할 수 있어야 한다.

또한 피드백이 수집되면, 그것을 정책이나 모델에 반영해야 한다. Policy reflection은 빠르지만 범위가 좁다. 예를 들어, ‘이 도구는 너무 느리니까 사용하지 말자’라는 정책을 빠르게 적용할 수 있다. Model fine-tuning은 느리지만 광범위하다. 예를 들어, 모델을 재학습하면 전반적인 의사결정이 개선될 수 있다. 프로덕션 환경에서는 정책 먼저, 필요하면 모델을 튜닝한다.

8. 아키텍처와 비용: 각 선택의 대가

LLM 에이전트를 운영하는 비용은 예상보다 높다. 왜냐하면 각 레이어에서 LLM을 호출할 수 있기 때문이다. 의도 분류(1회), 계획(1회 이상), 행동 평가(선택적), 재계획(재시도할 때)… 이렇게 하면 단일 사용자 요청이 수십 번의 LLM 호출로 변할 수 있다. 만약 한 번의 호출이 $0.01이라면, 수십 번의 호출은 $0.30이 되고, 이는 일반 API의 100배다.

비용 관점에서의 아키텍처 선택은 다음과 같다. (1) 더 강한 모델을 쓰면 레이어를 줄일 수 있다. 예를 들어, GPT-4는 한 번의 호출로 의도 분류와 계획을 동시에 할 수 있지만, GPT-3.5는 각각 분리해야 한다. (2) 더 약한 모델을 쓰면 레이어가 늘어난다. (3) 규칙을 추가하면 LLM 호출을 줄일 수 있지만 유연성이 떨어진다. (4) 캐싱을 추가하면 반복 호출을 줄일 수 있지만 메모리가 필요하다.

The key insight: architecture is not about technical elegance, it is about balancing capability, cost, and latency. Make trade-offs explicit and measure them constantly. 즉, ‘왜 이 디자인을 선택했는가’를 비용 수치로 설명할 수 있어야 한다.

9. 신뢰성과 복구 전략

신뢰성은 에이전트가 ‘성공할 확률’이 아니라 ‘실패에서 복구할 확률’이다. 왜냐하면 어떤 도구든 실패할 수 있고, 어떤 계획도 틀릴 수 있고, 어떤 사람도 실수할 수 있기 때문이다.

복구 전략은 세 가지다. 첫째는 자동 복구(retry, fallback)고, 둘째는 부분 성공(우리가 할 수 있는 것은 제공)이고, 셋째는 인간 개입(operator or user review)이다. 각 전략의 비용과 효과를 측정해야 한다. Automatic recovery는 빠르고 저렴하지만 신뢰도가 낮다. Partial success는 중간 수준이다. Human intervention은 느리고 비싸지만 신뢰도가 높다.

또한 신뢰성은 누적이다. 레이어 1의 오류율이 1%이고 레이어 3의 오류율도 1%이고 레이어 5의 오류율도 1%이면, 전체 오류율은 약 2-3%다(정확히는 수학적으로 계산해야 함). 따라서 각 레이어의 오류율을 낮게 유지해야 전체 신뢰성이 높아진다. 이는 각 레이어에서 엄격한 검증이 필요하다는 뜻이다.

Reliability targets should be set at the service level, not at the agent level. An 99% reliable agent might still deliver 95% service reliability if the integration is poor. 즉, 에이전트 신뢰성 99%라고 해서 사용자 입장에서 신뢰성이 99%인 것은 아니다.

10. 모니터링과 거버넌스

에이전트 시스템은 모니터링이 없으면 운영 불가능하다. 왜냐하면 각 상황이 고유하고, 각 오류도 새로울 수 있기 때문이다. 따라서 모니터링은 문제 탐지가 아니라 일상적인 의사결정을 위한 신호다. 에이전트가 어떤 의도를 자주 오해하는가, 어떤 도구가 가장 실패하기 쉬운가, 어디서 비용이 가장 많이 들어가는가를 알아야 한다.

핵심 지표는 다음과 같다. (1) Intent resolution rate: 의도가 정확히 이해되는 비율. (2) Tool success rate: 도구 호출이 성공하는 비율. (3) End-to-end success rate: 사용자가 원하는 결과를 얻는 비율. (4) Cost per user request: 평균 비용. (5) Latency: 응답 시간.

거버넌스는 누가 에이전트의 행동을 제어할 수 있는가를 정의한다. 정책 변경, 도구 추가, 모델 업데이트 같은 결정을 누가, 어떤 절차로 승인할 것인가. 이를 명문화하지 않으면 운영은 카오스가 된다. 예를 들어, 누구든 도구를 추가할 수 있다면, 위험한 도구가 실수로 추가될 수 있다.

Governance is not bureaucracy, it is accountability. Design approval workflows that prevent cascading failures while allowing rapid iteration on non-critical changes. 즉, 중요한 변경은 신중하게, 마이너한 개선은 빠르게 하는 구조를 만들어야 한다.

11. 프로덕션 배포 패턴

에이전트를 프로덕션에 배포하는 방법은 여러 가지다. Canary deployment는 작은 트래픽으로 시작해 점진적으로 늘리는 방식이다. 예를 들어, 처음 1% 사용자에게만 새 에이전트를 사용하게 하고, 문제가 없으면 10%, 50%, 100%로 늘린다. Shadow mode는 실제 프로덕션 트래픽을 에이전트에 보내지만 결과를 반영하지 않는 방식이다. 사용자는 여전히 구 에이전트의 결과를 보지만, 새 에이전트의 성능을 측정할 수 있다. Blue-green deployment는 두 개의 프로덕션 환경을 번갈아 사용하는 방식이다.

각 방식의 장단점은 명확하다. Canary는 안전하지만 느리다. 새 버전으로 전환하는 데 몇 시간이 걸릴 수 있다. Shadow mode는 실제 성능을 측정할 수 있지만 리소스가 필요하다. 새 에이전트와 구 에이전트를 동시에 실행해야 하기 때문이다. Blue-green은 빠르지만 리스크가 크다. 새 환경에 버그가 있으면 한 번에 모든 사용자에게 영향을 미친다.

또한 배포 이후에는 rollback 계획이 있어야 한다. 문제가 생기면 얼마나 빨리 이전 버전으로 돌아갈 수 있는가? 이를 위해 버전 관리와 상태 백업이 필수다. 예를 들어, 새 에이전트가 잘못된 결과를 줬다면, 그 결과를 받은 사용자들에게 알림을 보내고 정정해야 한다.

Deployment is not an event, it is a process. Plan for failures, test recovery paths, and automate rollback procedures. The speed of recovery matters more than the speed of deployment. 즉, 배포 속도가 중요한 것이 아니라, 문제가 생겼을 때 얼마나 빨리 대응하는가가 중요하다.

12. 실전 운영: 체크리스트와 90일 로드맵

LLM 에이전트를 운영하기 위한 실전 체크리스트는 다음과 같다. (1) 각 레이어의 입력/출력이 명확한가? 테스트 할 수 있는가? (2) 각 레이어에서 실패 처리가 정의되어 있는가? 혼자 복구할 수 없으면 어떻게 되는가? (3) 모든 결정이 기록되고 감시되는가? 사후 분석이 가능한가? (4) 정책 변경 절차가 있는가? 누가 승인하고, 얼마나 빨리 적용되는가? (5) 롤백 계획이 있는가? 문제가 생기면 몇 분 안에 되돌릴 수 있는가?

90일 운영 로드맵은 이렇다. 첫 30일: 기본 아키텍처 구축, 모니터링 설정, 수동 오류 처리. 목표는 시스템이 동작하고 문제를 파악할 수 있도록 하는 것이다. 다음 30일: 비용 최적화, 자동 오류 처리 강화, 정책 엔진 구축. 목표는 불필요한 비용을 줄이고 흔한 오류는 자동으로 복구하는 것이다. 마지막 30일: 자동화 고도화, 정책 고도화, 프로덕션 배포 자동화. 목표는 운영 부담을 최소화하고, 지속적 개선을 가능하게 하는 것이다.

Most importantly, remember that architecture decisions are reversible until you scale. Start simple, measure carefully, and optimize based on data, not predictions. 즉, 완벽한 설계를 미리 하지 말고, 충분한 설계로 시작해서 데이터를 보며 개선해야 한다.

마지막으로, 에이전트 운영의 성공은 기술이 아니라 문화에서 온다. 모두가 오류를 학습의 기회로 보고, 데이터를 기반으로 의사결정하고, 지속적으로 개선하는 문화 말이다. 아키텍처는 이 문화를 가능하게 하는 구조일 뿐이다. 좋은 도구와 프로세스가 있어야 좋은 문화도 가능하고, 좋은 문화가 있어야 좋은 도구를 제대로 쓸 수 있다.

LLM 에이전트 아키텍처는 기술 문제가 아니라 운영 문제다. 각 레이어의 선택, 각 정책의 규정, 각 지표의 해석이 모두 운영의 안정성과 비용을 결정한다. 따라서 설계 단계에서 운영을 생각하고, 운영 단계에서 설계를 다시 본다는 마음가짐이 필요하다.

The architecture we described is not the only way, but it is a proven way. Adapt it to your constraints, measure your results, and iterate relentlessly. That is how you build agent systems that actually work in production, not just in demos.

---

Tags: LLM에이전트, 에이전트아키텍처, 도구호출, planning-agentic, cost-optimization, 신뢰성운영, observability-agents, 상태관리, tool-execution, agent-governance