[요즘 LLM] Ch.1 - Agent

Agent
2025-04-10

OpenAI, DeepSeek, Claude 등등 최근들어 개발자의 생태계를 위협하는 주적(?) 들이 생겼습니다! 아주 무시무시한 친구들이죠.

그렇다면 우리는 무엇을 해야할까요? 가만히 AI 놈들이 생태계를 위협하는 모습을 보아야할까요? 당연히 아닙니다. 우리의 주적을 처리하기 위해서는 요놈들이 어떤 녀석들인지 잘 알아야하겠죠.

유명한 말 “적을 알고 나를 알면, 백전백승” 처럼, 저는 [요즘 LLM] 이라는 시리즈를 통해 LLM이 어떻게 발전하고 있는지. 요즘 AI 놈들은 어떤 모습이 되었는지를 설명하고, 더 나아가 이를 잘 사용하기 위한 최전선 개발자들의 고분분투를 담아보고자 합니다.

(물론 덤으로 직접 해볼 수 있는 사용법도 넣어줄거에요! - 이번 post는 말구 히히)

그 첫번째 글 “Agent”에서는 지난 2024년도 말에 구글에서 나온 Agent 백서를 기반으로 요즘 AI 놈들의 근간이 되는 몸체를 파해쳐 볼 것입니다.

1. Agent란?

Agent. 뭔가 스파이 같고, 첩보 같고… 하지만 여기서 말하는 Agent는 그런 쪽은 아닙니다. 요즘 LLM 세계에서 말하는 "에이전트"란, 단순히 말을 잘하는 모델이 아니라, 스스로 도구를 고르고, 판단하고, 행동하는 존재를 뜻합니다.

어디서부터 시작되었을까? — Agent 개념의 역사

에이전트 개념 자체는 새로운 것이 아닙니다. AI 분야에서의 "Agent"는 1950~60년대 인공지능 논의 초기부터 등장했죠.

초창기에는 ‘지능형 에이전트(intelligent agent)’ 라는 개념으로, 환경을 인식하고 행동을 결정할 수 있는 자율 시스템을 뜻했어요.

  • 예를 들어, 환경을 센싱하고 → 판단하고 → 액션을 취하는 로봇이 전형적인 ‘Agent’의 모습입니다.
  • 이 개념은 1990년대 들어 더욱 구체화되어 에이전트 기반 모델(Agent-based Model, ABM) 로 확장되었고, 다양한 시뮬레이션 시스템(예: 도시 모델링, 생태계 시뮬레이션 등)에서 활용되었습니다.
  • 최근에는 이 흐름이 발전해, 인간처럼 능동적으로 목적을 향해 행동하고 협력하는 존재를 뜻하는 Agentic AI라는 개념까지 등장했죠.

그러니까 오늘날 LLM 기반의 Agent도, 사실은 이 오랜 에이전트 철학의 연장선이라고 볼 수 있어요. 단지, 지금은 그 중심에 GPT나 Gemini 같은 언어모델(LM) 이 들어가 있다는 게 가장 큰 차이일 뿐입니다.

모델이 아닌, 에이전트

우리가 흔히 알고 있는 LLM, 예를 들어 GPT-4나 Gemini 같은 모델들은 대부분 입력에 대한 출력을 잘 만드는 ‘모델’이죠. 하지만 이 친구들에게는 결정적인 한계가 있었습니다. 바로 현실 세계에 작용하지 못한다는 것입니다.

  • 예를 들어, 사용자가 "서울에서 도쿄로 가는 비행기 예약해줘"라고 했을 때, 모델은 그저 "도쿄행 항공편을 확인해보세요~" 정도로 안내할 수밖에 없습니다.
  • 왜냐면 이 모델은 실제 항공편을 검색하거나, API를 호출해 실제로 예약을 하는 기능은 없기 때문이죠.

여기서 등판한 것이 바로 에이전트입니다.

에이전트의 목표는 모델이 추론을 하되, 도구를 쓰고, 상태를 관리하는 등 조금 더 사용자의 요청에 잘 답변할 수 있게 하는 것 입니다. 즉, 모델을 한 단계 더 확장하기 위한 것이죠.

2. Agent의 구조

자 그러면 Agent가 그렇게 확장되기 위해서 필요한 것은 무엇일까요? 당연히 LLM은 있어야 할 것 같은데 추가적으로 필요한 요소는 무엇일까요?

구글 Agent 백서를 통해 Agent가 어떻게 구성되는지를 먼저 봅시다.

General agent architecture and components

  1. Model
    • Agent의 두뇌입니다. ReAct, Chain-of-Thought 등 다양한 reasoning 프레임워크를 사용할 수 있는 LLM이 여기에 해당하죠.
  2. Tool
    • Agnet를 위한 도구상자입니다. 목표를 달성하기 위한 도구인 API, 코드 실행기, 데이터 저장소 등이 여기에 해당하죠.
  3. Orchestration Layer
    • 사고하고 계획하고 반복하는 루프입니다. 사용자의 목표를 이해하고, 어떤 도구를 언제 어떻게 쓸지 결정하는 중추 역할을 하죠.

1) Model

앞에서 소개했듯 Agent의 ‘두뇌’ 역할을 하는 건 바로 언어모델(Large Language Model) 입니다.

이 모델은 사용자의 질문을 이해하고, 어떤 작업이 필요한지를 스스로 판단합니다. 여기서 중요한 건, 에이전트에 쓰이는 모델은 단순히 ‘좋은 문장을 뽑는 모델’이 아니라,

추론(reasoning)과 계획(planning) 을 수행할 수 있어야 한다는 거예요.

예를 들어, "서울에서 도쿄까지 가는 가장 싼 항공편을 찾아줘"라는 요청이 들어왔을 때,
모델은 내부적으로 다음과 같은 과정을 밟을 수 있죠:

도시 정보를 파악하고
→ 날짜를 추론하고
→ API를 통해 항공편을 검색하고
→ 가격을 비교해서
→ 가장 저렴한 옵션을 알려주기

그리고 이런 과정을 통해 결과를 추론할 수 있도록 과정을 계획하는 것까지 Model의 역할입니다.

2) Tool

모델이 아무리 똑똑해도, 대화만 가능하다면 언젠가 한계가 올 것입니다.
그래서 필요한 것이 바로 Tool(도구) 입니다.

Tool은 에이전트가 외부 시스템과 상호작용할 수 있도록 도와주는 API, 기능, 데이터 저장소 같은 것들을 말합니다.

  • Extension: 에이전트가 직접 API 호출을 수행 (예: 항공편 조회, 날씨 확인 등)
  • Function: 모델이 실행할 코드를 제안하고, 실행은 클라이언트 쪽에서 담당
  • Data Store: 외부 문서, 데이터베이스 등에서 정보를 찾아주는 벡터 검색 기반 저장소 (RAG)

Tool을 어떻게 사용하냐에 따라 Agent는 다양한 역할을 할 수 있습니다.
(각 Tool에 대한 소개는 아래에 나와요!)

3) Orchestration Layer

모델과 도구가 있으면 충분할 것 같지만,
어떻게 순서를 정해서 일할지를 조율해주는 존재가 필요합니다.

이게 바로 Orchestration Layer입니다.

  • 어떤 도구를 먼저 쓸지?
  • 언제 사용자에게 중간 질문을 할지?
  • 결과가 부족하면 다시 검색해야 할지?

이런 모든 흐름을 계획하고 제어하는 역할이죠. 흔히 말하는 Agent Framework(LangChain, AutoGPT 등)가 여기에 해당됩니다.

모델이 생각하고, 도구가 일하고, 오케스트레이션 레이어는 “이 일을 어떻게 순서대로 할지 계획하고 관리하는 존재”인 셈이에요.

3. 조금 더 자세하게! – 다양한 agent Tool에 대해

앞서 에이전트의 세 가지 핵심 구성 중에서 Tool은 외부 세계와 연결해주는 팔과 다리라고 했었죠.

그런데 이 Tool이 모두 같은 방식으로 동작하는 건 아닙니다.

구글에서는 대표적인 세 가지 형태의 Tool을 제시합니다:

Extension, Function, Data Store

각각의 특징을 하나씩 살펴볼게요!

1) Extension – “내가 직접 API 부를게!”

Extension은 에이전트가 직접 API를 호출할 수 있도록 연결해주는 도구입니다. 마치, 에이전트가 스마트폰을 들고 “야 구글, 항공편 좀 찾아줘!” 하고 말하는 느낌이에요.

  • Model이 사용자의 요청을 이해하고
  • 어떤 API(예: Google Flights)를 사용할지 결정하고
  • API를 호출하고, 받은 응답을 바탕으로 다시 Orchestration해서 최종 응답을 생성하는 방식이죠.

image.png

예를 들어,
사용자가 “서울에서 도쿄 가는 비행기 찾아줘”라고 하면,
에이전트는 Google Flights Extension을 통해 API를 호출해서 실시간 항공편 데이터를 받아오고,
그 결과를 요약해서 사용자에게 보여줍니다.

💡 특징:

  • 에이전트(서버)가 직접 API를 호출함
  • Tool 사용 예시가 포함된 "예제(prompt)"를 통해 학습 가능
  • LangChain이나 Gemini Extensions 등에서 자주 쓰이는 방식

2) Function – “API는 내가 안 불러, 대신 파라미터는 줄게!”

Function은 Extension과 비슷해 보이지만,
실제 API 호출은 에이전트가 아닌 클라이언트(프론트엔드 등) 에서 이뤄집니다.

(이를 기반으로 Function Calling이라는 기술이 발전했습니다! 이건 따로 다룰게요 ㅎㅎ)

image.png

예를 들어 요청이 들어왔을 때 Agent는 이렇게 말하는 거죠:

내가 생각해봤는데, 이 API를 이런 값으로 부르면 될 것 같아. 직접 호출은 네가 해줘!

image.png

즉, 모델이 함수명 + 인자값(JSON 형태) 을 생성하면, 클라이언트가 그걸 받아서 API를 호출하고 결과를 처리하는 구조예요.

ex)

{
  "function_call": {
    "name": "display_cities",
    "args": {
      "cities": ["Aspen", "Whistler"],
      "preferences": "skiing"
    }
  }
}

💡 특징:

  • 호출은 클라이언트가 담당, 모델은 ‘무엇을 호출해야 할지’ 판단
  • 보안이 중요하거나, API 호출 타이밍을 세밀하게 제어할 때 유리
  • "모델은 지시하고, 실행은 사람이" 방식의 구조

3) Data Store – “나한테 참고 자료 줘!”

LLM이 아무리 똑똑해도, 훈련 시점 이후의 정보를 모른다는 한계는 여전히 있죠. 이걸 보완하기 위해 나온 게 바로 Data Store, 즉 외부 지식창고입니다.

image.png

  • 사용자가 문서를 업로드하거나
  • 웹사이트, PDF, CSV 같은 자료를 연결하면
  • 이를 벡터화(embedding)해서, 모델이 RAG 방식으로 실시간 검색해 활용할 수 있게 만드는 구조예요.

image.png

예를들어,
사용자가 “우리 회사 2023년 매출 요약해줘”라고 말하면,
모델은 연결된 재무보고서 PDF에서 관련 내용을 벡터 검색으로 찾아 요약해주는 방식이죠.

💡 특징:

  • 데이터를 미리 가공해두면, 실시간으로 검색해 응답에 활용
  • RAG (Retrieval Augmented Generation)의 핵심
  • LangChain / Vertex AI의 핵심 컴포넌트 중 하나

4. 정리

위의 내용을 하나로 정리하면 다음과 같습니다.

Model이 생각하고, Tool을 통해 행동하고, Orchestration이 모든 걸 관리한다.

이제 다음 글 부터는 이 Agent를 둘러싼 다양한 기술들을 이야기 해볼꺼에요!