LLM 에이전트 아키텍처: Memory, Planning, Tool Routing을 하나의 설계로 묶는 방법
LLM 에이전트 설계는 더 이상 “모델을 붙이면 끝”이 아니다. 하나의 에이전트가 안정적으로 작동하려면 기억, 계획, 도구 실행이 서로 끊기지 않는 흐름으로 연결되어야 한다. 이 글은 Memory, Planning, Tool Routing을 각각의 기능이 아니라 하나의 설계 축으로 묶는 방법을 정리한다. The core idea is simple: architecture is about interfaces and feedback, not just components. 구성요소를 잘 고르는 것보다, 그 구성요소가 어떤 신호를 주고받는지, 어떤 지점에서 실패가 복구되는지, 어떤 지표로 건강 상태를 측정하는지가 훨씬 중요하다.
특히 최근의 에이전트는 다양한 작업을 동시에 수행한다. 고객 응대, 데이터 검색, 보고서 생성, 내부 승인 프로세스까지 하나의 흐름에 묶이는 경우가 많다. 이때 설계를 단순화하면 오히려 운영 비용이 폭발한다. A scalable agent is not the one that handles more tasks, but the one that fails gracefully and learns quickly. 아래의 내용은 시스템 관점에서 구조를 정리하고, 실무에서 적용 가능한 설계 원리로 연결한다.
목차
- 아키텍처의 기본 축: Memory, Planning, Tool Routing을 하나로 보기
- Memory 설계: 저장 구조, 회수 전략, 신뢰성 레이어
- Planning 설계: 의사결정 그래프와 실행 제어
- Tool Routing 설계: 선택, 검증, 실행의 통합 파이프라인
- 운영 관점 통합: 관측성, 평가, 개선 루프
1. 아키텍처의 기본 축: Memory, Planning, Tool Routing을 하나로 보기
Memory, Planning, Tool Routing은 종종 서로 다른 문제로 취급된다. 그러나 실제 에이전트는 이 세 가지가 하나의 루프를 이룬다. 메모리는 과거를 저장하지만, 그 구조는 계획의 입력 형식을 규정한다. 계획은 실행의 우선순위를 정의하지만, 실행 결과는 다시 메모리의 질을 결정한다. Tool Routing은 실행의 기술적 경로이지만, 잘못된 라우팅은 계획의 타당성을 무너뜨린다. This is a closed loop, and every loop has a control theory dimension. 제어 루프에서 핵심은 입력과 출력의 안정성이다. 입력이 불안정하면 계획이 흔들리고, 출력이 불안정하면 메모리가 오염된다.
따라서 설계의 출발점은 “각 모듈이 무엇을 하느냐”가 아니라 “각 모듈이 어떤 신호를 보내고 어떤 신호를 받느냐”에 있다. 예를 들어 Memory는 단순 저장소가 아니라 “의사결정에 필요한 신뢰 가능한 요약”을 제공해야 한다. Planning은 단순 스텝 나열이 아니라 “실행 리스크를 관리하는 정책”이 되어야 한다. Tool Routing은 단순 API 호출 경로가 아니라 “실행 실패를 흡수하고 재시도 전략을 설계하는 레이어”가 되어야 한다. In other words, you are designing contracts, not just functions. 이 관점이 없으면 시스템은 기능적으로는 돌아가도, 운영 환경에서 불안정해진다.
한 가지 중요한 원칙은 “모듈 간 정보의 형태를 표준화하는 것”이다. Memory가 아무리 풍부해도 Planning이 소화하지 못하는 형태면 의미가 없다. Planning이 아무리 정교해도 Tool Routing이 해석할 수 없는 정책이라면 실행으로 연결되지 않는다. 그래서 아키텍처는 데이터 스키마, 우선순위 규칙, 실패 기준 같은 “공통 언어”를 만들어야 한다. This shared language is what makes a multi-agent system coherent. 결국 이 공통 언어가 운영의 속도를 높이고, 장애 복구 시간을 줄인다.
2. Memory 설계: 저장 구조, 회수 전략, 신뢰성 레이어
Memory는 흔히 벡터 DB나 로그 저장소로 단순화되지만, 실제로는 세 층의 구조가 필요하다. 첫째는 원천 기록층이다. 사용자 입력, 시스템 이벤트, 도구 결과 등 사실 기반 데이터가 저장된다. 둘째는 요약층이다. 원천 기록을 그대로 쓰면 맥락이 과잉이 되고, 요약이 없으면 Planning의 입력이 비효율적이 된다. 셋째는 정책층이다. 어떤 정보를 얼마나 오래 유지할지, 어떤 정보를 어떻게 폐기할지 결정하는 규칙이 필요하다. This is the data lifecycle in practice, not theory. 이 세 층이 분리되지 않으면, 메모리는 시간이 갈수록 노이즈가 축적되고 결국 신뢰성을 잃는다.
회수 전략도 중요하다. 많은 시스템이 semantic search만으로 회수를 해결하려 하지만, 실제 에이전트는 시간순 맥락과 작업 흐름의 맥락을 동시에 필요로 한다. 따라서 retrieval은 “질의 기반”과 “세션 기반”이 결합되어야 한다. 예를 들어, 고객 요청에 대한 응답은 최신 세션 로그를 우선적으로 가져오고, 그다음 유사 사례를 참고하는 구조가 안정적이다. The order of retrieval matters more than the retrieval itself. 또한 회수 결과를 그대로 Planning에 주입하면 안 된다. 회수된 정보는 신뢰도 점수와 함께 제공되어야 하고, 불확실성이 높은 경우에는 Planning 단계에서 추가 검증을 유도해야 한다.
신뢰성 레이어는 Memory 설계의 핵심이다. 정보가 저장되었다고 해서 그것이 정확하다는 보장은 없다. 특히 외부 도구에서 가져온 정보나, 모델이 생성한 요약은 오류를 포함할 수 있다. 이를 관리하려면 provenance, freshness, and validation status를 메타데이터로 남겨야 한다. 예를 들어 “이 정보는 2시간 전 크롤링됨, 원천 URL 검증됨” 같은 신호가 있어야 한다. Without metadata, memory becomes a rumor mill. 메모리를 신뢰할 수 없다면 Planning도 신뢰할 수 없다. 이 이유로 Memory 설계는 단순 저장이 아니라 검증과 관리의 체계를 포함해야 한다.
3. Planning 설계: 의사결정 그래프와 실행 제어
Planning은 에이전트의 뇌다. 하지만 “생각을 길게 한다”는 의미가 아니다. Planning은 실행을 위한 구조화된 의사결정이다. 이때 핵심은 단순한 단계 나열이 아니라 의사결정 그래프를 설계하는 것이다. 그래프는 분기 조건, 중단 조건, 그리고 복구 조건을 포함한다. 예를 들어 “외부 API가 실패하면 대체 경로로 전환한다”라는 규칙은 그래프의 복구 경로다. The agent must know not only what to do, but what to do when it cannot do it. 이 복구 경로가 없으면, 에이전트는 불필요한 재시도와 비용 낭비를 반복하게 된다.
Planning의 또 다른 중요한 요소는 “리스크 관리”다. 도구 호출은 비용과 리스크를 발생시키며, 특히 고위험 도구는 실패 시 큰 손실을 만든다. 따라서 계획 단계에서 도구 호출의 위험도를 분류하고, 위험도가 높은 경우 추가 검증을 요구해야 한다. 예를 들어 금융 데이터 수정이나 고객 정보 삭제 같은 작업은 자동 실행이 아니라 승인을 요구하도록 설계한다. This is not a limitation; it is a safety feature. 에이전트가 언제 자동으로 움직이고, 언제 멈추는지를 명확히 하는 것이 운영 신뢰성을 만든다.
또한 계획은 “정책 레이어”와 연결되어야 한다. 정책 레이어는 시스템 전체의 규칙, 예를 들어 예산 제한, 호출 횟수 제한, 프롬프트 길이 제한 같은 조건을 담는다. Planning은 이 정책을 고려하여 최적 경로를 선택해야 한다. 그렇지 않으면 특정 작업은 성공하더라도 시스템 전체가 비용 폭발로 이어진다. A good plan is one that respects global constraints. 계획이 단순히 작업을 성공시키는 것이 아니라, 시스템의 지속 가능성을 유지하는 방향으로 설계되어야 한다.
4. Tool Routing 설계: 선택, 검증, 실행의 통합 파이프라인
Tool Routing은 종종 “어떤 도구를 쓸 것인가”로만 이해된다. 하지만 실제로는 선택, 검증, 실행, 결과 처리의 전체 파이프라인이다. 도구 선택은 단순히 기능 매칭이 아니라, 비용, 지연, 신뢰도, 접근 권한을 고려해야 한다. 예를 들어 동일한 정보를 얻을 수 있는 두 도구가 있다면, 더 느리더라도 더 신뢰할 수 있는 도구를 우선하는 것이 장기적으로 안전하다. In routing, trust often beats speed. 이러한 선택 기준이 없으면 시스템은 단기 성능을 위해 장기 신뢰를 잃는다.
검증 단계는 필수다. 도구 호출 결과는 항상 오류 가능성을 내포한다. 따라서 결과에 대한 sanity check가 필요하다. 예를 들어 수치 데이터는 범위를 검증하고, 텍스트 데이터는 출처를 확인하며, 작업 상태는 재확인한다. 검증 로직이 없으면, 에이전트는 잘못된 결과를 Memory에 기록하고 Planning을 오염시킨다. Verification is the gate between action and memory. 도구 결과를 검증하지 않는 시스템은 결국 잘못된 루프를 강화하게 된다.
실행 파이프라인은 재시도 전략과 예외 처리를 포함해야 한다. 단순 재시도는 비용을 낭비할 뿐 아니라 장애를 악화시킬 수 있다. 따라서 재시도는 제한된 횟수로, 그리고 백오프 정책과 함께 이루어져야 한다. 또한 실패 시에는 대체 경로를 제공하거나 사용자에게 명확한 오류를 전달해야 한다. Failure is data, not just a problem. 실패를 기록하고, 다음 Planning에 반영하는 체계가 있어야 시스템은 학습한다. Tool Routing은 단순한 호출 경로가 아니라 운영 학습 루프의 핵심 입력이다.
5. 운영 관점 통합: 관측성, 평가, 개선 루프
아키텍처가 실제로 동작하려면 운영 관점이 통합되어야 한다. Memory, Planning, Tool Routing은 각각의 로그가 아니라 하나의 관측성 프레임으로 묶여야 한다. 예를 들어 특정 사용자 요청이 실패했을 때, 우리는 “어떤 메모리가 회수되었는지, 어떤 계획이 만들어졌는지, 어떤 도구가 호출되었는지”를 하나의 흐름으로 추적할 수 있어야 한다. This is the equivalent of tracing in distributed systems. 분절된 로그는 운영 속도를 늦추고, 근본 원인 분석을 어렵게 만든다.
평가 루프도 중요하다. 에이전트의 성능을 평가하는 것은 단순한 정확도 측정이 아니라, 의사결정 품질과 운영 비용을 함께 측정하는 것이다. 예를 들어 “작업 성공률”과 “작업당 비용”을 동시에 추적해야 한다. 또 “실패했을 때 복구까지 걸린 시간”을 측정해야 한다. These metrics turn architecture into operational reality. 지표가 없으면 설계는 가설에 머무르고, 지표가 있으면 설계는 개선된다.
마지막으로 개선 루프는 조직의 리듬으로 통합되어야 한다. 일주일 단위의 리뷰, 월간 성능 분석, 정책 업데이트 주기 같은 운영 리듬이 없다면, 아키텍처는 시간이 갈수록 붕괴된다. 에이전트 설계는 일회성 프로젝트가 아니라 운영 모델이다. The system must be designed to learn as much as it is designed to act. Memory, Planning, Tool Routing의 결합은 결국 “지속 가능한 학습과 실행”을 가능하게 한다. 이 관점이 있을 때, 에이전트는 단순한 자동화 도구가 아니라 조직의 안정적인 운영 자산이 된다.
6. 적용 시나리오: 제품, 운영, 조직의 접점에서 설계가 작동하는 순간
실무 적용에서 가장 흔한 오류는 설계를 특정 팀의 문제로만 보는 것이다. 예를 들어 제품팀은 “사용자 경험”을, 운영팀은 “안정성”을, 데이터팀은 “정확도”를 따로 최적화한다. 하지만 Memory, Planning, Tool Routing은 분리된 최적화를 견디지 못한다. The architecture is a shared contract across teams. 한 팀이 메모리 정책을 바꾸면 Planning의 입력이 달라지고, 그 변화는 Tool Routing의 오류율로 나타난다. 따라서 적용 시나리오는 기능 구현이 아니라 조직 간 인터페이스 정의로 시작해야 한다. 이를 위해서는 공통 지표와 공통 용어를 먼저 합의해야 한다.
또 다른 시나리오는 “규모 확장”이다. 초기에는 단일 모델과 단일 도구로 운영하더라도, 사용자 트래픽이 늘면 멀티 모델, 멀티 도구 환경으로 이동한다. 이때 기존 설계를 그대로 확장하면 실패한다. 모델 라우팅, 비용 분산, 신뢰도 차이를 고려한 정책이 필요하다. A multi-model agent is a policy system, not just a routing table. 특히 고비용 모델과 저비용 모델의 혼합은 “언제 고성능을 쓰고 언제 충분히 좋은 결과를 선택할 것인가”를 명확히 정의해야 한다. 그렇지 않으면 비용은 증가하고, 사용자 만족도는 떨어진다.
마지막으로 조직의 학습 구조가 시나리오의 핵심이다. 에이전트는 데이터가 축적될수록 좋아질 수 있지만, 그 전제는 실패와 성공이 구조적으로 기록되고 해석되는 것이다. 운영 로그가 단순한 이벤트 나열에 머무르면 학습이 되지 않는다. Instead, logs must be decision-aware. 어떤 계획이 어떤 결과를 만들었는지, 어떤 메모리 조회가 성공률을 높였는지, 어떤 도구가 반복적으로 실패했는지 분석 가능한 형태로 남겨야 한다. 이렇게 해야만 “개선이 가능한 설계”가 된다. 이 과정이 정착되면, 조직은 에이전트를 기술이 아니라 운영 체계로 다루게 된다.
Tags: LLM아키텍처,에이전트메모리,플래닝,툴라우팅,컨텍스트관리,오케스트레이션,에이전트디자인,시스템설계,tool-routing,agent-memory
