LLM이 등장한 이후, 시장의 관심은 "모델이 문장을 얼마나 잘 쓰는가"에서 "얼마나 많은 것을 자동화할 수 있는가"로 빠르게 이동했습니다. 그러나 LLM을 실제 업무에 적용하려는 시도가 쌓일수록, 단일 모델 호출만으로는 닿지 않는 영역이 분명해졌습니다. RAG가 그 첫 번째 보완책이었다면, 에이전트는 조회와 판단, 실행과 반성을 하나의 체계 안에 묶는 다음 단계입니다. 그리고 하나의 에이전트로 감당하기 어려운 복잡도에 이르면, 우리는 자연스럽게 멀티 에이전트로 이동하게 됩니다.

• LLM의 한계, 그리고 RAG가 등장한 이유

대규모 언어 모델은 추가 학습 없이도 다양한 도메인의 질문에 답하고 창의적인 결과물을 만들어낼 수 있습니다. 기존의 검색 시스템이나 챗봇이 미리 정의된 키워드와 규칙에 따라 응답을 반환하는 방식이었다면, LLM은 문맥 전체를 이해한 뒤 자연어로 유연하게 답변을 생성합니다. 그러나 활용 범위가 확장될수록 기술적 한계도 함께 드러났습니다. 언어 모델은 사전 학습된 데이터를 바탕으로 다음 단어를 확률적으로 예측하며 문장을 생성하도록 설계되어 있기 때문에, 학습 시점 이후의 최신 정보나 특정 기업의 내부 문서, 폐쇄형 데이터에 직접 접근할 수 없습니다.

이 구조적 제약이 가장 두드러지게 나타나는 현상이 바로 환각(Hallucination)입니다. 환각이란 언어 모델이 사실과 다른 내용을 마치 사실인 것처럼 자신 있게 생성하는 현상을 말합니다. 모델은 정답을 알고 있어서 답하는 것이 아니라, 학습 데이터의 패턴을 바탕으로 가장 그럴듯한 다음 단어를 예측하는 방식으로 동작하기 때문입니다. 금융·의료·법률처럼 정확성이 중요한 분야에서 이 문제는 치명적입니다. 즉, 언어 모델은 높은 표현 능력을 갖추고 있지만, 정보의 최신성·출처 검증·맥락 정합성은 구조적으로 보장되지 않습니다.

이러한 제약을 보완하기 위해 등장한 것이 RAG(Retrieval-Augmented Generation)입니다. RAG는 외부 저장소에서 질의와 관련된 문서를 검색하고, 그 결과를 프롬프트에 포함해 LLM에 전달한 뒤 답변을 생성하는 구조입니다. 모델이 '무엇을 알고 있는가'가 아니라 '무엇을 참조하는가'를 기준으로 응답을 구성하므로, 사내 매뉴얼·정책 문서·계약서·기술 사양서처럼 조직 내부 데이터를 활용해야 하는 업무 환경에서 핵심 메커니즘으로 자리 잡았습니다.

그러나 RAG 역시 고정된 파이프라인이라는 제약이 있습니다. '입력 → 조회 → 생성' 형태로 이어지는 흐름은 단 한 번의 조회로 충분하지 않거나, 결과에 따라 탐색 조건을 바꿔야 하거나, 조회된 내용을 평가해 재시도가 필요한 상황에서 대응력이 떨어집니다. 수치 계산이 동반되거나 외부 API를 호출해야 하는 작업, 여러 단계를 거쳐 결론에 도달해야 하는 복합 과업에서는 단순 조회 방식의 한계가 뚜렷하게 드러납니다.

• 에이전트란 무엇인가: 5가지 핵심 구성 요소

이러한 배경에서 에이전트(Agent) 개념이 다시 주목받기 시작했습니다. 에이전트는 목표 달성을 위해 가용 도구를 선택하고, 수행 순서를 결정하며, 필요시 실행 과정을 반복하는 능동적 체계입니다. 단순히 질문에 답하는 것을 넘어 스스로 계획을 세우고 실행 결과를 평가하며 다음 행동을 결정한다는 점에서, 기존의 LLM·RAG 방식과 본질적으로 다릅니다. LLM이 언어를 이해하고 생성하는 '두뇌' 역할을 한다면, 에이전트는 그 두뇌가 실제 환경과 상호작용하며 목표를 달성할 수 있도록 하는 '행동 체계'입니다.

에이전트를 가능하게 하는 핵심 요소는 다섯 가지입니다.

첫째, 목표(Goal)는 에이전트가 도달해야 할 최종 상태를 의미합니다. 사용자의 자연어 요청을 실행 가능한 상태로 변환하며, 실행 경로를 통제하고 완결성을 검증하는 기준이 됩니다. 둘째, LLM은 추론과 의사결정을 담당하는 핵심 요소입니다. 상태를 해석하고 어떤 도구를 호출할지 판단하며 최종 응답을 구성합니다. 다만 LLM은 컨텍스트 윈도우(Context Window)에 제한이 있어, 필요한 정보만 선별해 전달하는 전략이 중요합니다. 셋째, 도구(Tool)는 에이전트가 외부 환경과 상호작용하기 위한 실행 인터페이스입니다. 데이터 조회·파일 처리·코드 실행·외부 API 호출 같은 구체적 작업은 정의된 도구를 통해서만 실행됩니다. LLM은 판단을 생성하고, 도구는 그 판단을 실제 연산으로 변환합니다.

넷째, 메모리(Memory)는 에이전트가 연속적인 과업을 수행할 수 있도록 상태를 유지하는 구성 요소입니다. 단기 기억(Short-Term Memory)은 현재 세션의 맥락을 유지하며, 장기 기억(Long-Term Memory)은 세션이 종료된 이후에도 유지되어야 하는 정보를 저장합니다. 장기 기억은 일반적으로 벡터 데이터베이스와 연동해 구현되며, RAG의 지식 저장소와 유사한 원리로 작동합니다. 다섯째, 플래너(Planner)는 상위 목표를 실행 가능한 하위 과제로 분해하고, 각 단계의 수행 순서를 정의하는 구성 요소입니다. 중간 실행 결과를 반영해 계획을 동적으로 수정하는 것이 핵심 기능입니다.

이 다섯 요소가 유기적으로 결합될 때, 에이전트는 단순한 응답 생성기를 넘어 목적 지향적으로 동작하는 실행 구조로 기능합니다. 에이전트의 동작은 '목표 수립 → LLM 판단 → 도구 실행 → 메모리 반영 → 계획 수정'의 순환 구조를 목표 달성이 확인될 때까지 반복합니다. 이 구조 덕분에 에이전트는 초기 계획이 불완전하더라도 실행 과정에서 스스로 경로를 수정하며 최종 목표에 도달할 수 있습니다.

• 에이전트는 왜 여러 개여야 하는가: 멀티 에이전트 5가지 유형

하나의 에이전트가 모든 판단과 실행을 처리하는 싱글 에이전트 구조는 단순한 업무에는 충분합니다. 구조가 단순하기 때문에 초기 설계와 구현이 비교적 수월하고 전체 동작 과정을 추적하기도 용이합니다. 그러나 과업이 복잡해질수록 조건 분기·예외 처리·상태 관리 로직이 하나의 내부 흐름에 누적됩니다. 기능이 추가될 때마다 내부 의존성이 증가하고, 특정 로직의 수정이 전체 동작에 영향을 줄 가능성이 커집니다. 이는 소프트웨어 설계에서 말하는 모놀리식(Monolithic) 구조의 한계와 유사합니다.

멀티 에이전트는 전체 목표를 여러 역할 단위로 분해하고, 각 역할을 개별 에이전트에 할당해 실행하는 구조입니다. 각 에이전트는 자신의 역할 범위 안에서만 판단과 실행을 수행하므로 내부 로직이 단순해지고, 기능 확장 시 새로운 역할을 추가하거나 특정 에이전트를 교체하는 방식으로 구조를 확장할 수 있습니다. 멀티 에이전트는 시스템의 목적과 복잡도에 따라 다음 다섯 가지 전형적인 패턴으로 구성됩니다.

역할 분업형(Sequential Workflow)은 가장 기본적인 구조로, 각 에이전트가 특정 기능을 담당하며 순차적으로 과업을 수행합니다. 검색 에이전트가 자료를 수집하고, 분석 에이전트가 해석한 뒤, 요약 에이전트가 결과를 정리하는 방식입니다. 

계층형(Hierarchical Control)은 상위 에이전트가 전체 목표를 하위 작업으로 분해하고 각 하위 에이전트에 할당하며, 실행 결과를 수집·통합합니다.

 협업형(Joint Collaboration)은 결과의 품질 향상을 목적으로 에이전트 간 상호 검증을 반복하는 방식으로, 생성 에이전트가 초안을 작성하고 평가 에이전트가 정확성을 점검한 뒤 개선 에이전트가 수정하는 구조가 대표적입니다.

경쟁형(Competitive Generation)은 동일한 목표에 대해 여러 에이전트가 독립적으로 결과를 생성하고, 별도의 평가 단계에서 그중 하나를 선택하는 방식입니다. 협업형이 과정 중심이라면, 경쟁형은 결과 선택 중심입니다.

이벤트 기반형(Event-Driven Reactive)은 특정 조건이 충족되거나 외부 신호가 감지되었을 때, 사전에 정의된 에이전트가 자동으로 실행되는 구조입니다. 실행이 사용자 요청이 아니라 시스템 내부 상태 변화나 외부 이벤트에 의해 트리거된다는 점이 특징입니다.

실제 운영 환경에서는 이 패턴들이 단독으로 적용되는 경우는 드뭅니다. 역할 분업형 구조 안에 협업 루프를 포함하거나, 계층형 구조의 하위 단계에서 에이전트들이 경쟁적으로 결과를 생성하도록 설계하는 방식이 일반적입니다. 핵심은 패턴의 이름을 암기하는 것이 아니라, 각 패턴이 어떤 실행 논리를 가지며 어떤 문제 상황에 적합한지를 이해하는 것입니다.

단순한 질의응답이나 문서 요약처럼 입출력 구조가 단순한 작업은 기본 모델이나 RAG만으로도 충분합니다. 에이전트, 그리고 멀티 에이전트는 다양한 도구의 연동, 복합적인 실행 흐름, 반복 피드백 체계, 외부 시스템 결합이 동시에 요구되는 환경에서 진가를 발휘합니다. LLM에서 RAG로, RAG에서 에이전트로, 그리고 에이전트에서 멀티 에이전트로 이어지는 흐름은 '문제를 작은 판단으로 나누어 협업하게 한다'는 발상이 구체화된 결과입니다. 이 개념을 이해했다면, 다음 단계로 이 에이전트들이 실제로 어떻게 연결되고 통신하는지 알아보시는 것을 권해드립니다.

위 컨텐츠는 서지영 저자님의
『이것이 멀티 에이전트다』의 내용을 재구성하여 제작되었습니다.