LLM을 활용한 애플리케이션이 점점 정교해지면서, 이제 중요한 것은 단순히 답변을 생성하는 능력만이 아닙니다. 사용자의 요청을 목표로 이해하고, 필요한 판단과 실행을 연결하는 에이전트 구조가 중요해지고 있습니다. 싱글 에이전트의 개념과 장점을 먼저 살펴보고, 복잡한 문제 앞에서 왜 역할 분리와 조율이 필요해지는지, 그리고 왜 멀티 에이전트 구조로 이어지게 되는지를 차례로 살펴봅니다.

LLM 기반 시스템에서 에이전트는 주어진 목표를 달성하기 위해 스스로 판단하고 실행하는 지능형 프로그램입니다. 일반적인 LLM이 질문에 대한 텍스트를 생성하는 데 머무른다면, 에이전트는 사용자의 요청을 달성해야 할 목표로 받아들이고, 필요한 작업을 계획하며, 필요하면 도구를 호출해 정보를 수집하고, 이전 결과를 바탕으로 다음 행동을 결정합니다. 즉, 에이전트의 핵심은 단순한 응답 생성이 아니라 목표 달성을 위한 판단과 실행에 있습니다. 이러한 구조는 ChatClient, Prompt, Advisor, Tool 같은 요소가 서로 맞물리며 구현됩니다.

• 싱글 에이전트란 무엇인가

싱글 에이전트는 하나의 명확한 역할을 중심으로 판단하고 행동하도록 설계된 구조입니다. 하나의 에이전트가 특정 목표를 맡고, 그 목표를 달성하기 위해 LLM의 추론과 Tool 호출을 반복하며 결과를 만들어냅니다. 역할이 분명하기 때문에 시스템 프롬프트를 선명하게 정의할 수 있고, 어떤 도구를 어떤 상황에서 사용해야 하는지도 비교적 명확하게 설계할 수 있습니다.

이 구조의 장점은 분명합니다. 역할이 명확할수록 판단 기준이 흔들리지 않고, 구조가 단순하기 때문에 유지보수가 쉽고 응답도 빠릅니다. 하나의 전문 영역을 일관되게 처리하도록 설계하면, 많은 업무 자동화 시나리오에서 충분히 효과적인 결과를 얻을 수 있습니다. 명확한 임무를 수행하는 싱글 에이전트는 단순하면서도 강력한 구조입니다.

싱글 에이전트는 단순한 챗봇과도 다릅니다. 필요한 경우 Tool을 호출해 외부 정보를 활용할 수 있고, Advisor를 통해 입력 검증이나 호출 흐름 제어도 할 수 있습니다. 또한 대화 메모리를 적용하면 사용자의 이전 질문 맥락을 기억해 후속 질문에도 자연스럽게 응답할 수 있습니다. 즉, 싱글 에이전트는 하나의 역할에 집중하면서도 판단, 제어, 도구 활용, 맥락 유지를 함께 담을 수 있는 구조입니다.

• 싱글 에이전트의 한계는 어디서 시작되는가

싱글 에이전트의 한계는 문제의 복잡성이 커질 때 드러납니다. 하나의 질문 안에 서로 다른 판단 기준과 전문성이 동시에 들어오기 시작하면, 하나의 에이전트가 감당해야 할 책임 범위가 급격히 넓어집니다. 예를 들어 여행 일정을 만든다고 하면 관광지 선정, 맛집 추천, 숙소 선택, 동선 고려, 예산 계산처럼 성격이 다른 판단이 한꺼번에 필요해집니다.

이때 가장 먼저 발생하는 문제는 프롬프트의 비대화입니다. 하나의 에이전트가 여러 전문가 역할을 동시에 맡게 되면 규칙은 길어지고, 도구 선택 조건은 복잡해지며, 서로 다른 판단 기준이 한 구조 안에 뒤섞이게 됩니다. 그 결과 특정 영역의 판단 품질이 떨어지거나 일관성이 무너질 수 있고, 유지보수도 어려워집니다. 새로운 역할을 추가할수록 기존 로직에 영향을 주기 쉬워지고, 책임 범위도 점점 불분명해집니다. 결국 하나의 에이전트에 너무 많은 책임을 몰아주면, 처음의 장점이었던 단순성과 명확성이 오히려 약점으로 바뀌게 됩니다.

하지만 이것이 싱글 에이전트의 효용이 사라진다는 뜻은 아닙니다. 명확한 목표를 가진 문제에는 여전히 싱글 에이전트가 매우 효과적입니다. 다만 복합적인 문제를 하나의 구조로 모두 감당하려는 순간, 한계가 분명해진다는 점이 중요합니다.

• 그래서 멀티 에이전트가 필요하다

이 지점에서 필요한 것이 멀티 에이전트입니다. 멀티 에이전트는 하나의 에이전트에 몰려 있던 책임을 역할별로 나누고, 여러 에이전트가 각자의 전문성과 책임을 맡아 협업하는 구조입니다. 관광지 추천은 관광지 추천 에이전트가 맡고, 맛집 추천은 맛집 추천 에이전트가 맡고, 숙소 추천은 숙소 추천 에이전트가 맡는 식으로 역할을 분리합니다. 각 에이전트는 자신의 역할 범위 안에서만 판단하고 행동하기 때문에 더 정교하고 안정적인 결과를 기대할 수 있습니다. 전문성 강화, 유지보수 용이성, 프롬프트 최적화, 유연한 모델 조합도 이 구조의 장점입니다.

멀티 에이전트 구조에서는 역할 분리만으로 끝나지 않습니다. 여러 에이전트가 언제, 어떤 순서로, 어떤 방식으로 협업할지 조율하는 상위 구성 요소가 필요합니다. 이 역할을 오케스트레이터가 담당합니다. 오케스트레이터는 지금 어떤 에이전트를 실행해야 하는지, 하나만 써도 되는지 여러 에이전트를 함께 써야 하는지, 순차 실행이 맞는지 병렬 실행이 맞는지를 결정하며 전체 작업 흐름을 관리합니다. 전문가 에이전트가 각자의 분야에서 판단과 실행을 맡는다면, 오케스트레이터는 전체 문제를 해결하기 위한 협업의 흐름을 조율하는 역할을 맡습니다.

멀티 에이전트의 핵심에는 공유 상태가 있습니다. 여러 에이전트가 협업하려면 각 단계의 결과가 다음 단계에 자연스럽게 전달되어야 하기 때문입니다. 사용자 요구사항, 관광지·맛집·숙소 정보, 예산 분석, 최종 일정 같은 정보를 하나의 상태 객체에 저장하면, 각 에이전트는 필요한 정보를 읽고 자신의 결과를 다시 그 상태에 채워 넣을 수 있습니다. 이 덕분에 에이전트의 독립성은 유지하면서도 전체 시스템은 유기적으로 협업할 수 있습니다.

또한 서로 독립적인 작업은 병렬로 실행해 속도를 높일 수 있고, 계획 생성 뒤에는 예산 검증을 거쳐 문제가 있으면 다시 더 저렴한 선택지로 재계획하는 자기 보정 구조도 만들 수 있습니다. 이처럼 멀티 에이전트는 단순한 역할 분담을 넘어, 복잡한 문제를 실제로 해결할 수 있는 협업 시스템으로 확장됩니다.

• 결국 중요한 것은 역할 분리와 조율

싱글 에이전트는 하나의 역할에 집중할 때 강력합니다. 책임이 선명하고, 구조가 단순하며, 많은 문제를 빠르고 안정적으로 해결할 수 있습니다. 하지만 하나의 질문 안에 여러 전문 영역과 판단 기준이 함께 들어오는 순간, 하나의 에이전트에 모든 책임을 몰아주는 방식은 곧 한계에 부딪힙니다.

그래서 필요한 것이 멀티 에이전트입니다. 역할을 분리하고, 각 에이전트가 자기 분야에 집중하게 하며, 오케스트레이터가 전체 협업을 조율하는 구조는 복잡한 문제를 더 안정적이고 유연하게 다룰 수 있게 만듭니다. 여기에 공유 상태, 병렬 실행, 검증과 재계획 같은 메커니즘이 더해지면, 멀티 에이전트 구조는 단순 응답을 넘어 실제 업무를 수행하는 형태로 확장됩니다. 결국 중요한 것은 에이전트의 수가 아닙니다. 문제의 복잡도에 맞게 역할을 나누고, 각 에이전트의 책임과 협업 흐름을 분명하게 하는 일이 핵심입니다. 작은 문제에는 선명한 싱글 에이전트가 강하고, 복잡한 문제에는 역할이 분리된 멀티 에이전트가 강합니다.

위 콘텐츠는 『이것이 Spring AI다(개정판)』의 내용을 재구성하여 작성되었습니다.

『이것이 Spring AI다(개정판)』은 Spring AI 개발 환경 구축부터 Chat API, 프롬프트 엔지니어링, 구조화된 출력, RAG, Tool Calling, MCP Server까지단계적으로 다루는 실전 입문서입니다. 개정판에는 에이전트 개발과 멀티 에이전트 협업 챕터가 새롭게 추가되어, 스스로 판단하고 협업하는 AI 시스템 설계까지 확장해 배울 수 있습니다.