
증강된 LLM: 모든 에이전트의 기반이 되는 빌딩 블록
요약
증강된 LLM(Augmented LLM)은 검색, 도구, 메모리 능력을 갖춘 단일 에이전트 시스템의 핵심 빌딩 블록입니다. Anthropic과 Google의 정의를 바탕으로, 모델이 스스로 쿼리 작성, 도구 선택, 컨텍스트 유지를 주도하는 구조를 설명합니다.
핵심 포인트
- 증강된 LLM의 3대 요소: 검색(Retrieval), 도구(Tools), 메모리(Memory)
- 모델이 스스로 쿼리 생성 및 도구 선택을 주도하는 것이 핵심
- 멀티 에이전트 설계를 위한 필수적인 기초 단계
- Model Context Protocol(MCP)을 통한 도구 연결 표준화 활용 가능
요약 버전: 증강된 LLM (Augmented LLM)은 검색 (Retrieval), 도구 (Tools), 메모리 (Memory)라는 세 가지 추가 능력을 부여받은 단일 모델입니다. Anthropic은 이를 모든 에이전트 시스템 (Agentic system)의 기본 빌딩 블록이라고 부릅니다. Google은 동일한 개념을 단일 에이전트 시스템 (Single-agent system)이라고 부릅니다. 멀티 에이전트 (Multi-agent) 설계를 다루기 전에 이를 반드시 마스터해야 합니다. 왜냐하면 다른 모든 패턴이 이 위에 구축되기 때문입니다.
증강된 LLM이란 무엇인가?
증강된 LLM은 검색 (Retrieval), 도구 (Tools), 메모리 (Memory)로 강화된 언어 모델로, 모델 자체가 이러한 능력들을 주도합니다. 즉, 모델이 스스로 검색 쿼리를 작성하고, 적절한 도구를 선택하며, 컨텍스트 (Context)에 무엇을 유지할지 결정합니다 (Anthropic). Google은 이와 동일한 단일 에이전트 시스템을 하나의 모델, 정의된 도구 세트, 그리고 에이전트가 요청을 해석하고 단계를 계획하며 스스로 도구를 선택할 수 있게 하는 시스템 프롬프트 (System prompt)로 설명합니다 (Google Cloud).
중요한 단어는 '증강된 (Augmented)'입니다. 순수한 모델은 자신의 가중치 (Weights)로부터 답변합니다. 증강된 모델은 새로운 사실을 가져오고, 세상에 작용하며, 대화가 이어지는 동안 기억을 유지할 수 있습니다.
세 가지 증강 요소
검색 (Retrieval)은 모델이 학습하지 않은 정보를 가져올 수 있게 합니다. 모델은 쿼리를 생성하고, 결과를 읽으며, 이를 바탕으로 답변의 근거를 마련합니다. 도구 (Tools)는 모델이 함수와 API를 호출하고, 그 출력을 읽어 다음 행동을 결정할 수 있게 합니다. 메모리 (Memory)는 모델이 컨텍스트를 계속 유지할 수 있게 하여, 같은 말을 반복하거나 흐름을 놓치지 않도록 합니다 (Anthropic).
이 세 가지 모두에 대한 Anthropic의 조언은 동일합니다. 사용 사례(use case)에 맞게 조정하고, 그 앞에 깔끔하고 문서화가 잘 된 인터페이스를 배치하십시오. 도구(tool)를 연결하는 한 가지 방법은 Model Context Protocol (MCP)이며, 이는 모델에 점점 늘어나는 제3자 도구 세트를 위한 표준 클라이언트(standard client)를 제공합니다.
실제 작동 방식
단일 증강 에이전트(augmented agent)는 짧은 루프(loop)를 실행합니다. 요청을 읽고, 도구 또는 검색이 필요한지 결정하며, 이를 호출하고, 결과를 읽은 다음, 답변을 하거나 다음 단계를 수행합니다. 별도의 두 번째 에이전트나 오케스트레이션 계층(orchestration layer)은 없습니다. 모델 자체의 추론(reasoning)이 컨트롤러 역할을 합니다.
그 단순함이 핵심입니다. Google은 품질을 실제로 결정하는 세 가지 요소, 즉 핵심 로직(core logic), 시스템 프롬프트(system prompt), 도구 정의(tool definitions)에 집중할 수 있도록 여기서부터 시작할 것을 권장합니다 (Google Cloud). Anthropic은 도구 인터페이스를 일급 시민(first-class concern)으로 취급하며, 팀이 인간 인터페이스에 쏟는 만큼 에이전트-컴퓨터 인터페이스(agent-computer interface)에 많은 노력을 기울일 것을 제안합니다.
언제 사용하는가
작업에 외부 데이터나 행동이 필요하지만 여전히 하나의 명확한 책임 범위 내에 있을 때 단일 증강 LLM을 사용하십시오. 주문 내역을 조회하는 고객 지원 에이전트나, API를 호출하고 결과를 요약하는 연구 보조 도구 등이 이상적인 사례입니다. 비에이전트형(non-agentic) 시스템은 도구를 사용하거나 다단계 계획(multi-step plan)을 실행할 수 없기 때문에 이러한 작업을 수행할 수 없습니다 (Google Cloud).
또한 이는 모든 프로토타입(prototype)을 위한 올바른 첫 번째 단계입니다. 단일 에이전트를 짧은 시간 내에 출시하여 어디에서 문제가 발생하는지 학습한 다음, 더 무거운 패턴이 그 비용만큼의 가치가 있는지 결정할 수 있습니다.
언제 사용하지 않는가
단일한 일반 모델 호출 (plain model call)만으로 요청에 답변할 수 있다면 증강 (augmentation)을 건너뛰십시오. 문서를 요약하거나, 텍스트를 번역하거나, 피드백을 분류하는 작업은 대개 도구 (tools)나 메모리 (memory)가 필요하지 않으므로, 에이전트 (agent)를 사용하는 것은 아무런 이득 없이 비용만 추가하는 셈입니다 (Google Cloud).
또한, 하나의 에이전트가 여러 개의 서로 다른 작업들을 동시에 처리하기 시작할 때도 다음 단계로 넘어가야 합니다. Google의 자체 가이드라인은 직설적입니다. 도구와 책임이 쌓일수록 단일 에이전트는 '팔방미인(jack of all trades)이지만 무엇 하나 제대로 못 하는(master of none)' 상태가 됩니다 (Google Developers). 이것이 바로 전문화된 에이전트들로 분리해야 한다는 신호입니다.
알려진 문제점들
주된 실패 모드 (failure mode)는 과부하입니다. 도구와 작업의 복잡성이 증가함에 따라 단일 에이전트의 성능은 저하됩니다. 즉, 더 높은 지연 시간 (latency), 잘못된 도구 선택, 또는 결코 끝나지 않는 작업들을 목격하게 됩니다 (Google Cloud). ReAct 루프 (ReAct loop)와 같이 더 나은 추론 구조 (reasoning structure)를 사용하여 한계를 더 밀어붙일 수는 있지만, 이는 여유 공간을 확보할 뿐 한계치 자체를 제거하지는 못합니다.
두 번째 문제는 취약한 도구 인터페이스 (tool interface)입니다. 만약 어떤 도구가 설명만으로는 사람이 사용하기 어렵다면, 모델에게도 어렵습니다. Anthropic은 프롬프트 (prompts)를 다듬는 것보다 도구를 개선하는 데 더 많은 시간을 소비한다는 것을 발견했으며, 상대 경로 대신 절대 파일 경로를 요구하는 것과 같은 작은 수정만으로도 특정 범주의 오류들을 완전히 제거할 수 있었습니다.
시작하기 전에 알아야 할 세 가지
- 시스템 프롬프트(System prompt)가 곧 제품입니다. 시스템 프롬프트는 에이전트의 작업, 페르소나(Persona), 그리고 각 도구를 사용하는 정확한 조건을 정의합니다. 모호한 프롬프트는 모호한 에이전트를 만듭니다.
- 주니어 팀원에게 설명하듯 도구를 문서화하세요. 사용 예시, 예외 케이스(Edge cases), 그리고 명확한 경계(Boundaries)를 포함해야 합니다. 실제 입력을 테스트하고 설명을 반복적으로 개선하세요.
- 확장하기 전에 측정하세요. 두 번째 에이전트를 추가하기 전에, 단일 에이전트가 실제 작업에서 부족하다는 것을 증명해야 합니다. 멀티 에이전트 (Multi-agent) 설계는 실행 및 유지 관리 비용이 훨씬 더 많이 들기 때문입니다.
FAQ
증강된 LLM (Augmented LLM)이 에이전트와 동일한 것인가요?
가장 작은 단위의 에이전트입니다. Anthropic은 이를 기본 빌딩 블록 (Building block)으로 취급하며, Google은 동일한 형태를 단일 에이전트 시스템 (Single-agent system)으로 취급합니다. 더 큰 패턴들은 이러한 요소들을 여러 개 결합하여 구성됩니다.
검색 증강 생성 (RAG)이 증강된 LLM인가요?
RAG는 그중 검색 (Retrieval) 부분에 해당합니다. 완전한 증강된 LLM은 그 위에 도구와 메모리 (Memory)를 추가하며, 모델이 각 도구를 언제 사용할지 스스로 결정하게 합니다.
챗봇 (Chatbot)과는 어떻게 다른가요?
챗봇은 모델 단독으로 답변합니다. 증강된 LLM은 실시간 데이터를 가져오고, API를 호출하며, 행동할 수 있으며, 그 결과를 답변에 활용할 수 있습니다.
언제 여러 개의 에이전트로 전환해야 하나요?
하나의 에이전트가 여러 개의 별개 책임을 처리해야 하거나, 도구를 추가하는 것이 정확도와 지연 시간 (Latency)에 악영향을 미치기 시작할 때입니다. 그때가 바로 전문가 (Specialists)가 승리하는 시점입니다.
Sources
참고 자료 (Sources)
- Anthropic, 효과적인 에이전트 구축하기 (Building Effective Agents): [https://www.anthropic.com/engineering/building-effective-agents]
- Google Cloud Architecture Center, 에이전트형 AI 시스템을 위한 디자인 패턴 선택: [https://docs.cloud.google.com/architecture/choose-design-pattern-agentic-ai-system]
- Google Developers Blog, ADK의 멀티에이전트 패턴 개발자 가이드: [https://developers.googleblog.com/developers-guide-to-multi-agent-patterns-in-adk/]
- Model Context Protocol: [https://modelcontextprotocol.io/]
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기