[AWS SUMMIT 2025] LLM에 실행 엔진을 탑재하다!Tool use와 Agents로 구현하는 엔터프라이즈AI솔루션

들어가며

LLM에 실행 엔진을 탑재하다!Tool use와 Agents로 구현하는 엔터프라이즈AI솔루션

🎙️김기철 솔루션즈 아키텍트

🎙️이유정 솔루션즈 아키텍트

🗂️ 세션 토픽: 생성형AI및머신러닝응용

이번 세션은 LLM이 외부 도구를 활용해 작업을 수행하는 Tool Use와 이를 확장한 에이전트(Agent) 개념에 대해 설명합니다. 이는 LLM이 단순 질의응답을 넘어, 외부 도구와 연동하여 계산, 검색, 코드 실행 등 복잡한 작업을 수행할 수 있도록 하는 방식입니다. 특히, Tool Use의 구조와 한계, 그리고 Bedrock에서 제공하는 Converse API와 Bedrock Agent를 활용한 자동화 방식에 대해 중점적으로 다루고 있습니다.

1. Tool Use란?

LLM은 언어 처리에 뛰어난 능력을 보이지만, 계산과 같은 정밀한 작업에서는 한계가 명확하게 드러납니다. 예를 들어, 2자리 수 계산은 거의 100% 정확도로 수행할 수 있지만, 3자리 수 계산에서는 약 80%, 4자리 수 이상으로 넘어가면 정확도가 25% 수준으로 급격히 떨어지는 것으로 나타났습니다. 이는 모델이 주로 2자리 수 계산식 중심의 데이터로 학습되었기 때문이며, 복잡한 계산식을 자주 접해보지 못한 상황에서는 정확도가 낮아질 수밖에 없습니다. 이런 상황에서 단순히 더 큰 모델이나 더 많은 데이터를 사용한다고 해서 완전한 해결책이 되지는 않습니다.

이러한 한계를 극복하기 위한 방법 중 하나가 바로 Tool Use, 즉 외부 도구의 활용입니다.

예를 들어, LLM에게 계산기와 같은 도구를 사용할 수 있는 능력을 부여하면, 계산 정확도를 크게 높일 수 있습니다. 이는 단순히 언어모델 하나로 모든 것을 해결하려는 기존 방식에서 벗어나, 언어모델을 중심으로 여러 외부 도구와 연동하여 작업을 수행하는 모듈형 시스템( Modular, Reasoning, Knowledge, Language)으로 전환하는 개념입니다.

생성형AI의 Tool Use

LLM은 본질적으로 사전 학습 이후 새로운 정보에 접근하지 못하며, 복잡한 계산이나 특수한 도메인의 전문 지식에 약한 경향이 있습니다. 하지만 이런 약점을 외부 툴과의 연계를 통해 보완할 수 있습니다.

LLM에게 “계산기는 이런 식으로 사용하면 돼”라고 명시적으로 알려주고, 필요할 때 이를 호출하게 만들면, LLM의 활용 가능성은 획기적으로 확장됩니다. 이러한 구조가 바로 Tool Use의 출발점이며, 모델의 한계를 뛰어넘어 실질적인 문제 해결 능력을 높이는 핵심 전략입니다.

2. LLM이 외부 세계와 상호작용하는 방식: Tool Use의 구현 아이디어

LLM이 단순한 텍스트 생성 모델을 넘어 실제 작업을 수행하려면, 외부 세계와 상호작용할 수 있는 구조가 필요합니다.이를 가능하게 하는 방식이 바로 Tool Use이며, LLM이 외부 도구를 호출하고 그 결과를 바탕으로 최종 응답을 생성하는 흐름입니다. 이 방식은 단순히 모델이 가진 내부 지식만으로는 해결할 수 없는 문제들, 예를 들어 실시간 계산, 외부 정보 조회, 문서 검색 등  을 해결하기 위해 고안된 것입니다.

Tool Use 동작은 다음과 같은 흐름으로 이루어집니다:

1. 사용 가능한 툴 정의: 사전에 사용할 수 있는 도구들을 명시해둡니다. 예를 들어 ‘계산기’, ‘문서 검색기’, ‘날씨 API’ 같은 툴 목록이 제공됩니다.
2. 툴 선택: LLM은 사용자의 질문을 분석하여 어떤 툴이 적절한지 스스로 결정합니다.
3. 툴 실행 결과 수신: 선택된 툴이 실행되고, 그 결과가 다시 LLM에게 입력으로 전달됩니다.

최종 응답 생성: LLM은 받은 결과값을 활용해 사용자에게 완성된 답변을 제공합니다.

예를 들어, 모델에게 “세 가지 툴이 주어질 테니 이를 사용해서 문제를 해결하라”는 프롬프트를 주면, 모델은 이 중 하나를 선택하고 결과를 받아 답변에 반영하는 방식입니다. 이 과정을 통해 LLM은 외부 환경과 상호작용하는 능력을 얻게 됩니다.

하지만 이러한 구조에는 새로운 문제점들도 함께 발생합니다:

• 할루시네이션(Hallucination): 모델이 존재하지 않는 툴을 상상해내거나, 사용할 수 없는 툴을 호출하려는 문제가 발생할 수 있습니다.
• 내부 정보 노출 위험: 모델이 툴의 내부 구현 정보나 API의 세부 구조 등을 응답에 포함시키는 경우, 보안상 문제가 될 수 있습니다.
• 프롬프트 길이 증가: 툴 정의, 시스템 메시지, 사용자 요청이 함께 길어지면서 전체 프롬프트 길이가 늘어나고, 이로 인해 모델 성능 저하나 처리 비용 증가가 발생할 수 있습니다.
• 파싱 오류: 툴 호출인지, 모델이 최종 응답을 생성한 것인지 구분이 어려워지는 경우가 있습니다. 예를 들어, 응답 중 함수 호출 형식이 애매하게 포함되어 파싱 로직이 혼동되는 문제 등이 여기에 해당합니다.

따라서 Tool Use를 성공적으로 구현하기 위해서는 단순히 툴을 연결하는 것뿐만 아니라, 정확한 구조 설계, 안정적인 파싱 처리, 모델의 툴 선택 판단력 향상, 그리고 보안 고려까지 포함하는 종합적인 접근이 필요합니다. 이는 LLM의 한계를 극복하고, 실질적인 활용도를 높이는 핵심 기술로 점점 더 중요해지고 있습니다.

3. Tool Use의 동작방식

Tool Use를 안정적으로 구현하기 위해서는 단순히 외부 툴을 연결하는 것을 넘어서, 구조적인 최적화와 명확한 설계가 필수적입니다. 특히, LLM이 도구를 정확하게 호출하고 결과를 반영할 수 있으려면, 시스템 전체의 흐름과 응답 방식에 대해 세밀한 고려가 필요합니다.

Tool Use 최적화된 구조

1. Tool 전용 특수 구문: Tool정의, 사용자 질문, 시스템프롬프트를 명확히 구분하여 모델에게 전달해야합니다.
2. Tool Model: 제공한 툴을 잘사용할 수 있는 모델이 필요합니다.

Stop Sequence: 토큰 생성 중지 시점이 예측가능해야합니다.

Tool Use 동작방식

전체적인 동작 방식은 다음과 같습니다. 모델에게 사전정의된 시스템메세지와 입력된 사용자 메세지를 전달하면 모델은 툴을 호출할 지, 또는 최종 결과를 출력할지 결정합니다. 모델이 툴을 호출할 시, 일반적인 자연어 응답이 아닌 함수 호출 형태로 응답합니다. 이 함수 호출 구문은 미리 정의된 형식으로 파싱할 수 있도록 구성되어 있어, 응답 안에 호출 의도가 포함되었는지를 자동으로 감지할 수 있습니다.

예를들어 함수 호출 구문은 <function_calls> </function_calls>로 정의하여 해당 구문 출력시 토큰 생성을 중지할 수 있도록 중단 규칙을 정의합니다. 따라서, 어시스턴트 메세지 내에 function_calls 구문이 발견되면 이는 툴 호출로 인식하고 외부 도구를 실행하는 트리거가 됩니다. 반대로, 호출 구문이 없으면 그 응답은 최종 사용자 응답으로 처리됩니다.

이후, 툴 실행 결과는 모델에게 다시 사용자 메시지의 형태로 전달되며, 모델은 이를 참고하여 최종 답변을 생성하게 됩니다.

이러한 프로세스를 수작업으로 모두 처리하기에는 복잡성과 반복 작업이 많기 때문에, AWS Bedrock의 Converse API는 이 과정을 표준화된 방식으로 제공합니다. 프롬프트를 일일이 작성하거나 함수 호출 형식을 따로 정의하지 않아도, Converse API를 통해 LLM의 Tool Use 기능을 안정적으로 활용할 수 있게 되는 것입니다.

그러나 이러한 구조가 아무리 정교해도, 결국 중요한 것은 모델이 도메인 지식(domain knowledge)을 얼마나 갖추고 있느냐에 달려 있습니다. 도메인지식이 부족한 모델은 적절한 툴을 선택하지 못하거나, 잘못된 파라미터로 호출해 오류를 유발할 수 있습니다. 반면, 도메인지식이 충분한 모델은 문맥을 이해하고, 툴을 선별적으로 사용하며, 올바른 방식으로 조합하는 능력을 발휘할 수 있습니다.결국, Tool Use는 구조적 설계와 기술적 구현에 더해, 모델의 지식 기반과 추론 능력까지 함께 고려될 때 비로소 실질적인 성과를 발휘할 수 있는 강력한 방식입니다.

4. Agent란?

에이전트(Agent)란 단순히 주어진 질문에 답하는 수준을 넘어, 스스로 판단하고 행동할 수 있는 AI 시스템을 의미합니다. 에이전트의 핵심 개념은 크게 두 가지로 요약됩니다:

1. 자율성 (Agency)
   • 에이전트는 어떤 작업을 수행할지, 언제 시작하고 멈출지, 그리고 어떤 결과를 사용자에게 제공할지를 스스로 판단할 수 있는 능력을 가집니다. 이는 단순한 반응형 챗봇과 구별되는 중요한 차이점으로, 사람이 전부 지시하지 않아도 목표를 달성하기 위한 행동 경로를 계획하고 실행할 수 있다는 의미입니다.
2. 외부 영향력 (Influence)
   • 에이전트는 외부 시스템과의 연동을 통해 실제 행동을 수행합니다. 예를 들어, 캘린더에 일정을 추가하거나 이메일을 발송하거나, 데이터베이스에 접속하여 정보를 불러오는 등 물리적 또는 디지털 세계에 실질적 영향을 미칠 수 있는 능력을 갖추고 있어야 합니다.

이러한 자율성과 영향력의 조합에 따라, LLM 기반 시스템은 아래 세 가지 유형으로 구분됩니다:

1. 단일 응답모델 : 단순 질문-응답. 명령을 주면 그에 반응하는 수동형 챗봇 (자율성 없음 + 외부영향력 없음)
2. 업무 수행 챗봇 : 특정 상황에서는 툴을 호출하거나 작업을 수행할 수 있지만, 주도적으로 행동하지 않음 (제한된 자율성 + 제한된 외부영향력)
3. 가상 직원 : 목표를 스스로 이해하고, 필요한 툴을 선별해 복수의 단계를 처리함. 진정한 의미의 ‘에이전트’ (완전한 자율성 + 완전한 외부영향력)

에이전트는 단순한 Tool Use를 넘어서, 복잡한 의사결정이 필요한 업무를 다단계로 처리할 수 있어야 합니다. 이에 따라 AI 시스템의 진화는 다음과 같은 흐름을 따릅니다:

• 과거: 툴이 제한적이고, 단일 단계를 처리하는 단순한 작업 위주
• 현재: 여러 개의 툴을 선택해 사용할 수 있으며, 복잡한 작업과 여러 단계를 처리
• 미래: 제한 없이 다양한 툴을 활용하고, 고도로 복잡한 작업을 스스로 조정하며, 다단계 작업을 유기적으로 연계해서 처리

이러한 에이전트는 단순한 언어모델이 아니라, 실제 업무 수행을 위한 주체로 진화하고 있습니다. 특히 기업 환경에서는 단순한 챗봇이 아닌, 비즈니스 프로세스를 자동으로 조율하고 실행하는 디지털 가상 직원으로서 그 역할이 커지고 있습니다.따라서 미래의 LLM 시스템은 단지 “지식에 기반한 답변”을 넘어, 상황을 이해하고 판단하며, 적절한 조치를 능동적으로 수행하는 에이전트 구조로 진화하게 될 것입니다.

5. Bedrock Agent

Amazon Bedrock의 에이전트(Agent) 기능은 단순한 질문-응답을 넘어서, 사용자의 요청을 이해하고 필요한 작업을 능동적으로 수행할 수 있도록 설계된 고도화된 에이전트 프레임워크를 제공합니다. 특히 고객 맞춤형 에이전트를 손쉽게 만들 수 있는 구조를 제공하며, 다음과 같은 단계적 처리 능력을 기반으로 동작합니다:

1. 사용자의 요청 분석
   • 에이전트는 입력된 자연어 요청을 이해하고, 이를 해결하기 위해 어떤 단계가 필요한지를 스스로 파악합니다.
2. 적절한 계획 수립
   • 단일 호출로 끝나는 Tool Use와는 달리, 에이전트는 여러 단계를 순차적으로 계획하고 실행합니다. 즉, 응답을 완성하기 위해 필요한 다음 행동을 계속 이어나가는 방식입니다. 이는 사람처럼 “지금 무엇을 해야 할지” 판단하며 일처리를 한다는 점에서 매우 중요한 차이점입니다.
3. 툴을 활용한 작업 실행
   • 에이전트는 필요에 따라 다양한 툴을 활용합니다. 특히 Bedrock은 툴 사용을 위한 표준화된 인터페이스를 제공하고 있어, 복잡한 프롬프트나 코드 작성 없이도 강력한 툴 유즈가 가능합니다.

Bedrock 에이전트는 사용자가 미리 업로드한 문서 또는 외부 지식 저장소를 대상으로 자연어 기반 검색이 가능한 지식기반 툴(Knowledge Base Tool) 기능을 제공합니다.

1. 사용자가 질문하면, 시스템은 관련 문서를 검색하여 가장 관련성 높은 정보를 추출합니다.
2. 이 검색 결과는 다시 LLM에게 전달되어, 보다 정확하고 맥락 있는 답변 생성에 사용됩니다.

이를 통해, 단순한 추론이 아닌, 사용자 데이터에 기반한 맞춤형 지식 응답이 가능합니다.

또한, Bedrock 에이전트는 복잡한 금융 문제와 같은 고차원 업무도 처리할 수 있도록, 코드 생성 및 실행 기능과 개발자 정의 액션(Action Group)을 지원합니다.

• Code Interpreter (코드 실행기):
  • 예를 들어, “연간 변동성을 계산해줘”라는 요청이 들어오면, 에이전트는 이를 위해 필요한 수식을 자동으로 생성하고, 직접 실행합니다. 필요한 날짜 계산 → 수익률 계산 → 변동성 도출 같은 일련의 과정을 자동화합니다.
• Action Group (사용자 정의 함수 호출):
  • 사용자가 구현한 Lambda 함수나 외부 API 등을 툴로 등록하면, 에이전트가 이를 직접 호출하여 필요한 데이터를 가져옵니다.
    예: 주식 데이터 API를 호출해 시가/종가를 가져오거나, 포트폴리오 수익률 계산을 수행하는 등 실제 개발자 코드와 연동된 고급 작업이 가능합니다.

6. 정리:LLM에 실행엔진을 탑재하는 방법

툴유즈(Tool Use)는 필요한 외부 툴을 선택해 단순하고 정확한 작업을 수행하는 방식입니다. 주어진 툴을 호출해서 문제를 해결하고, 결과를 바로 반환하는 단순한 흐름이 특징입니다.

반면, 에이전트(Agent)는 작업을 수행하기 위한 전체 계획을 스스로 수립하고, 그 과정에서 여러 툴을 적절히 활용해 복잡한 작업을 자동화하는 고도화된 방식입니다. 에이전트는 다단계 의사결정을 하며, 반복적으로 툴을 호출하고 응답을 완성해 나갑니다.

Amazon Bedrock은 이 두 방식을 모두 지원합니다.

• Converse API를 통해 툴유즈를 안정적이고 표준화된 방식으로 구현할 수 있으며, 별도 복잡한 프롬프트 작성 없이도 쉽게 외부 툴을 활용할 수 있습니다.
• 또한, Bedrock Agent 기능을 통해 에이전트 기반 애플리케이션을 완전 관리형으로 개발 및 운영할 수 있도록 지원하여, 고객 맞춤형 복잡한 자동화 솔루션 구축이 가능합니다.

즉, Bedrock은 단순 작업부터 복잡한 다단계 업무까지 모두 포괄하는 AI 툴 사용과 에이전트 운영의 통합 플랫폼을 제공하는 것입니다.

마무리하며

이번 세션에서는 LLM의 한계를 극복하기 위해 외부 툴을 활용하는 Tool Use 개념과 이를 보다 확장한 에이전트 시스템에 대해 다루었습니다. Tool Use는 LLM이 직접 처리하기 어려운 계산이나 정보 검색을 외부 툴을 통해 보완하는 방식이며, 이를 위해 명확한 툴 정의와 함수 호출 방식이 중요합니다. 에이전트는 자율성과 외부 영향력을 갖추어 복잡한 의사결정과 다단계 작업 수행이 가능하며, 여러 툴을 연계해 보다 정교한 자동화를 실현합니다. Bedrock 플랫폼은 Tool Use를 위한 Converse API와 에이전트 개발을 위한 완전 관리형 기능을 제공하여 두 방식을 모두 지원합니다. 이를 통해 사용자는 간단한 작업부터 복잡한 금융 문제 해결까지 폭넓은 AI 활용이 가능해집니다.

글 │ │메가존클라우드, AI&Data 부문 / AI Innovation, 유수경 Manager