LLM을 공부하다 보면 Agent라는 용어를 매우 자주 접하게 된다. 하지만 처음에는 Agent가 하나의 라이브러리인지, LangGraph의 기능인지, 아니면 특정 모델인지 혼동하기 쉽다.
결론부터 말하면 Agent는 특정 라이브러리가 아니라 '의사결정(Decision Making) 방식' 또는 '워크플로 패턴'이다.
일반적인 프로그램은 미리 정해진 순서대로 동작한다.
예를 들어 가장 단순한 RAG(Retrieval-Augmented Generation)는 다음과 같다.
질문
↓
Retriever
↓
LLM
↓
답변
코드로 표현하면 다음과 비슷하다.
docs = retriever.invoke(question)
answer = llm.invoke(question, docs)
이 구조에서는 항상
이라는 동일한 순서를 수행한다.
검색이 충분한지, 다시 검색해야 하는지, 다른 도구를 사용할지에 대한 판단은 존재하지 않는다.
반면 Agent는 다음 행동을 스스로 결정한다.
예를 들어
질문
↓
검색이 필요한가?
├── Yes → 검색
└── No → 바로 답변
또는
검색 결과가 충분한가?
├── Yes → 답변 생성
└── No → 다시 검색
처럼 현재 상황을 판단하여 다음 행동(Action)을 선택한다.
즉,
Agent란 LLM이 현재 상태를 바탕으로 다음 행동을 결정하는 방식이다.
많은 사람들이
라고 생각하지만 이는 정확하지 않다.
LangChain과 LangGraph는 Agent를 구현하기 위한 프레임워크이다.
즉,
라고 이해하는 것이 가장 정확하다.
LangGraph는 Node와 Edge로 이루어진 그래프를 만든다.
예를 들어
START
↓
Retrieve
↓
Generate
↓
END
이 역시 하나의 그래프이다.
하지만 Agent가 들어가면 조건이 생긴다.
START
↓
Retrieve
↓
Generate
↓
Groundedness Check
├── PASS → END
└── FAIL → Retrieve
여기서 중요한 점은
Groundedness Check가 다음 행동을 결정한다는 것이다.
즉,
를 판단한다.
이러한 의사결정 Node가 바로 Agent 역할을 수행한다.
Node는 하나의 작업(Task)이다.
예를 들어
등은 모두 Node가 될 수 있다.
반면 Agent는
여러 Node 사이에서 다음에 어떤 Node를 실행할지를 결정하는 역할
을 한다.
즉,
Node는 작업이고,
Agent는 의사결정 로직이다.
기본적인 RAG는 항상 같은 순서로 동작한다.
Question
↓
Retriever
↓
LLM
↓
Answer
하지만 실제 서비스에서는 다음과 같은 문제가 발생한다.
이때 Agent를 추가하면
Question
↓
Planner
↓
어디를 검색할 것인가?
↓
Retriever
↓
검색 결과가 충분한가?
├── Yes
│ ↓
│ Generate
│ ↓
│ END
│
└── No
↓
Query Rewrite
↓
다시 검색
처럼 상황에 따라 검색 전략을 변경할 수 있다.
Self-RAG는 새로운 검색 엔진이 아니라
검색 결과를 평가하여 필요하면 다시 검색하는 Agent 패턴
이다.
흐름은 다음과 같다.
Question
↓
Retrieve
↓
Generate
↓
Groundedness Check
├── PASS → END
└── FAIL
↓
Query Rewrite
↓
Retrieve
Groundedness Check가
를 결정한다.
즉, Groundedness Check가 Agent 역할을 수행한다.
ReAct(Reasion + Act)는 가장 유명한 Agent 패턴 중 하나이다.
LLM이
을 반복한다.
예를 들면
Question
↓
LLM
↓
검색
↓
검색 결과
↓
LLM
↓
계산
↓
계산 결과
↓
LLM
↓
최종 답변
처럼 여러 Tool을 상황에 맞게 선택한다.
Localization 프로젝트에서는
등 여러 종류의 데이터가 존재한다.
사용자가
Save는 어떻게 번역해야 하나요?
라고 질문했다고 가정하자.
단순한 RAG라면 모든 데이터를 한꺼번에 검색한다.
하지만 Agent를 사용하면
Question
↓
Planner
↓
용어 질문인가?
├── Yes → Glossary 검색
└── No
Glossary에 없으면
TM 검색
그래도 없으면
Style Guide 검색
마지막으로
QA Database 검색
처럼 필요한 데이터만 순차적으로 검색할 수 있다.
검색 비용도 줄어들고 정확도도 높아진다.
LangGraph에서는 다음과 같은 그래프를 쉽게 만들 수 있다.
START
│
▼
Planner
│
▼
Glossary Retriever
│
▼
TM Retriever
│
▼
Style Guide Retriever
│
▼
Generate
│
▼
Groundedness Check
├── PASS → END
└── FAIL → Query Rewrite → Retriever
여기서
이라고 볼 수 있다.
Agent는 특정 라이브러리나 모델이 아니다.
LLM이 현재 상황을 바탕으로 다음 행동을 결정하는 의사결정 방식이다.
LangGraph는 이러한 Agent를 Node와 Edge로 구현하는 프레임워크이며, Agent는 그래프 안에서 "다음에 무엇을 할 것인가"를 결정하는 로직으로 동작한다.
특히 RAG에서는 검색 전략을 동적으로 변경하거나 여러 Retriever를 선택하고, 검색 결과를 평가하여 재검색하는 등의 기능을 구현하기 위해 Agent 패턴이 널리 사용되고 있다.