
최근 AI를 활용한 서비스가 빠르게 늘어나면서,
“에이전트(Agent)” 라는 용어를 자주 접하게 됩니다.
그렇다면 에이전트는 일반적인 챗봇과 다른 점이 무엇일까요?
이번 글에서 에이전트의 개념과 동작 원리, 그리고 왜 필요한지에 대해 알아보고자 합니다.
챗봇의 한계
현재 우리는 ChatGPT, Gemini, Claude와 같은 챗봇에 익숙합니다.
질문을 입력하면 답변을 생성해 주는 형식입니다.
하지만 현실에선 질문 하나, 답 하나로 끝나지 않는데요!
예를 들어, 고객이 쇼핑몰에서
“기계식 키보드 재고 있어? 3개 사면 얼마야?” 라는 질문을 처리하려면 다음과 같은 여러 단계의 작업이 필요합니다.
- 기계식 키보드 상품 검색
- 현재 재고 확인
- 할인 정책 적용
- 최종 가격 계산
사람은 자연스럽게 이러한 과정을 머릿속에서 처리하지만,
단순한 LLM(Large Language Model)은 사람만큼 사고가 이루어지지는 않죠.
만약 위 질문을 그대로 단순 LLM에게 던진다면 다음과 같이 답할 수 있습니다.
“기계식 키보드는 보통 재고가 충분하며, 3개 구매 시 약 8만 원 정도입니다.”
문제는 이 답변이 실제 쇼핑몰 데이터와 아무 관련이 없다는 것입니다.
단순한 LLM은:
- 실제 재고 데이터베이스를 볼 수 없음
- 현재 가격 정보를 알 수 없음
- 할인 정책을 확인할 수 없음
- 계산 결과를 보장할 수 없음
즉, LLM은 말은 잘하지만 혼자서 다른 행동은 하지 못합니다.
실제 업무에서는 데이터를 조회하고, 계산하고, 외부 시스템과 상호작용하는 능력이 꼭 필요로 합니다.
이러한 문제를 해결하기 위해 등장한 개념이 바로 AI 에이전트(Agent) 입니다.
에이전트의 핵심 구조는 다음 한 줄로 정리할 수 있습니다.
Agent = LLM + Tools + Loop
즉,
- LLM : 무엇을 해야 할지 판단하는 두뇌
- Tools : 실제 작업을 수행하는 손발
- Loop : 작업이 끝날 때까지 반복하는 구조
를 의미합니다.
에이전트의 3가지 핵심 구성 요소
1. LLM (두뇌)
LLM은 사용자의 요청을 이해하고 다음에 어떤 행동을 해야 하는지 결정합니다.
예를 들어: “재고 확인이 필요하네.”, “가격 계산도 해야겠네.” 와 같이 작업 계획을 세웁니다.
2. Tools (손발)
도구는 실제 행동을 수행합니다.
- 상품 검색
- 재고 조회
- 가격 계산
- 웹 검색
- 데이터베이스 조회
LLM은 직접 행동하지 않고, 필요한 도구를 호출합니다.
3. Loop (반복)
에이전트는 작업이 끝날 때까지 반복적으로 판단하고 실행합니다.
사용자 질문
↓
LLM
↓
도구 필요?
↓
Yes
↓
도구 실행
↓
결과 전달
↓
LLM
↓
도구 필요?
↓
No
↓
최종 답변
즉, “생각 → 행동 → 결과 확인” 과정을 계속 반복하는 구조입니다.
에이전트는 실제로 어떻게 동작할까?
앞서 본 질문인 .“기계식 키보드 재고 있어? 3개 사면 얼마야?”를 다시 살펴보면,
에이전트 내부에서는 다음과 같은 과정이 일어납니다.
단계수행 내용
| 1 | LLM이 필요한 도구 판단 |
| 2 | 재고 조회 도구 실행 |
| 3 | 가격 계산 도구 실행 |
| 4 | 결과를 종합 |
| 5 | 사용자에게 최종 답변 |
중요한 점은 LLM은 실행을 담당하지 않는다는 것입니다.
LLM은 “재고를 확인해야 한다.” 라고 판단만 하고, 실제 재고 조회는 개발자가 만든 코드가 수행합니다.
이러한 역할 분리가 에이전트 구조의 핵심입니다.
추가로, 많은 사람들이 에이전트를 사용하면 GPT 같은 llm 모델이 한 번만 호출된다고 생각하지만 실제로는 그렇지 않습니다.
예시를 보면 다음과 같은 흐름이 발생합니다.
단계수행 작업
| GPT 호출 1 | 어떤 도구를 사용할지 결정 |
| 도구 실행 | 재고 확인, 가격 계산 |
| GPT 호출 2 | 결과를 자연어로 정리 |
첫 번째 호출
GPT: “check_stock과 calc_price를 호출하자.”
도구 실행
재고 : 5개
가격 : 27,000원
두 번째 호출
GPT: “현재 재고는 5개이며, 3개 구매 시 총 가격은 27,000원입니다.”
이처럼 에이전트는 작업을 수행하기 위해 LLM을 여러 번 호출할 수 있습니다. 복잡한 작업일수록 호출 횟수는 더 늘어나겠죠.
모든 문제에 에이전트가 필요한 것은 아니다!
에이전트가 강력한 것은 사실이지만, 모든 상황에서 사용하는 것이 정답은 아닙니다.
예를 들어: “회사 규정집에서 휴가 규정을 찾아줘.” 이런 경우에는 문서를 검색해서 보여주기만 하면 됩니다.
즉,
- 검색 한 번이면 끝나는 문제 → RAG
- 상황에 따라 처리 순서가 달라지는 문제 → Agent
가 적합하다고 보면 될 것 같아요.
만약, 에이전트가 복잡해질수록 다음과 같은 문제가 발생합니다.
1. 비용 증가
에이전트는 매번 대화 전체를 다시 LLM에게 전달합니다.
따라서,
- 호출 횟수 증가
- 토큰 사용량 증가
- 비용 증가
- 응답 시간 증가
가 발생합니다.
2. 디버깅의 어려움
에이전트가:
- 어떤 도구를 호출했는지
- 어떤 인자를 사용했는지
- 왜 실패했는지
확인하기 어려워집니다. 심한 경우 동일한 도구를 계속 호출하는 무한 루프에 빠질 수도 있어요.
이러한 문제를 해결하기 위해 사용하는 도구가 LangSmith 입니다.
LangSmith는 에이전트의 모든 동작을 추적합니다.
- LLM 호출 횟수
- 사용한 도구
- 전달된 인자
- 응답 시간
- 토큰 사용량
- 에러 발생 위치
다음과 같은 동작 추적 덕분에 에이전트가 어떤 과정을 거쳐 답변을 생성했는지 한눈에 파악할 수 있습니다!
Insights
이번 학습을 통해 에이전트가 단순히 GPT에 질문을 한 번 보내고 답을 받는 구조가 아니라는 점을 알게되었습니다.
이전에는 AI 에이전트가 하나의 LLM 호출로 동작한다고 생각했지만,
실제로는 “도구를 선택하기 위한 호출 → 도구 실행 → 결과를 바탕으로 답변 생성” 과 같이 L
LM이 여러 번 호출되며 작업을 수행한다는 것을 처음 알게 되었습니다.
또한 LLM은 단순히 답변을 생성하는 역할만 하는 것이 아니라,
어떤 도구를 사용할지 판단하고 다음 행동을 결정하는 의사결정자(Decision Maker) 의 역할을 수행한다는 점도
새롭게 이해할 수 있었습니다.
특히 에이전트의 핵심이 단순한 모델 성능이 아니라 LLM + Tools + Loop 의 조합에 있다는 점이 흥미로웠습니다.
앞으로 LangChain, LangGraph, MCP 등을 활용해 더 복잡한 에이전트를 설계하게 되더라도,
이번에 배운 에이전트의 기본 구조와 동작 원리가 중요한 기반이 될 것이라고 생각합니다.
'개발' 카테고리의 다른 글
| [Web] 웹(Web), HTTP, REST API 이해하기 - 웹 서비스의 기본 구조 정리 (0) | 2026.06.26 |
|---|---|
| [LLM] 에이전트 시대의 표준 프로토콜, MCP (0) | 2026.06.26 |
| [LLM] LangGraph&LangSmith — 에이전트 워크플로우 구축과 실행 추적 (0) | 2026.06.24 |
| [NLP] OCR — 이미지 속 글자를 데이터로 바꾸기 (0) | 2026.06.24 |
| [머신러닝] 하이퍼 파라미터 튜닝하기 - Optuna (0) | 2026.06.02 |