LangGraph에서의 Agent

Soogyung Gwon·1일 전

구름을잡아라

목록 보기
76/76

Agent란 무엇인가?

LLM을 공부하다 보면 Agent라는 용어를 매우 자주 접하게 된다. 하지만 처음에는 Agent가 하나의 라이브러리인지, LangGraph의 기능인지, 아니면 특정 모델인지 혼동하기 쉽다.

결론부터 말하면 Agent는 특정 라이브러리가 아니라 '의사결정(Decision Making) 방식' 또는 '워크플로 패턴'이다.


Agent의 개념

일반적인 프로그램은 미리 정해진 순서대로 동작한다.

예를 들어 가장 단순한 RAG(Retrieval-Augmented Generation)는 다음과 같다.

질문
 ↓
Retriever
 ↓
LLM
 ↓
답변

코드로 표현하면 다음과 비슷하다.

docs = retriever.invoke(question)
answer = llm.invoke(question, docs)

이 구조에서는 항상

  1. 검색
  2. 답변 생성

이라는 동일한 순서를 수행한다.

검색이 충분한지, 다시 검색해야 하는지, 다른 도구를 사용할지에 대한 판단은 존재하지 않는다.


반면 Agent는 다음 행동을 스스로 결정한다.

예를 들어

질문
 ↓
검색이 필요한가?
 ├── Yes → 검색
 └── No  → 바로 답변

또는

검색 결과가 충분한가?
 ├── Yes → 답변 생성
 └── No  → 다시 검색

처럼 현재 상황을 판단하여 다음 행동(Action)을 선택한다.

즉,

Agent란 LLM이 현재 상태를 바탕으로 다음 행동을 결정하는 방식이다.


Agent는 라이브러리가 아니다

많은 사람들이

  • LangGraph = Agent
  • LangChain = Agent

라고 생각하지만 이는 정확하지 않다.

LangChain과 LangGraph는 Agent를 구현하기 위한 프레임워크이다.

즉,

  • Agent는 개념 또는 패턴
  • LangChain은 Agent를 구현하는 라이브러리
  • LangGraph는 Agent를 그래프로 구현하는 프레임워크

라고 이해하는 것이 가장 정확하다.


LangGraph와 Agent의 관계

LangGraph는 Node와 Edge로 이루어진 그래프를 만든다.

예를 들어

START
 ↓
Retrieve
 ↓
Generate
 ↓
END

이 역시 하나의 그래프이다.

하지만 Agent가 들어가면 조건이 생긴다.

START
 ↓
Retrieve
 ↓
Generate
 ↓
Groundedness Check
 ├── PASS → END
 └── FAIL → Retrieve

여기서 중요한 점은

Groundedness Check가 다음 행동을 결정한다는 것이다.

즉,

  • 종료할 것인가?
  • 다시 검색할 것인가?

를 판단한다.

이러한 의사결정 Node가 바로 Agent 역할을 수행한다.


Node와 Agent의 차이

Node는 하나의 작업(Task)이다.

예를 들어

  • 검색
  • LLM 호출
  • 데이터 저장
  • 번역

등은 모두 Node가 될 수 있다.

반면 Agent는

여러 Node 사이에서 다음에 어떤 Node를 실행할지를 결정하는 역할

을 한다.

즉,

Node는 작업이고,

Agent는 의사결정 로직이다.


RAG에서 Agent가 필요한 이유

기본적인 RAG는 항상 같은 순서로 동작한다.

Question
 ↓
Retriever
 ↓
LLM
 ↓
Answer

하지만 실제 서비스에서는 다음과 같은 문제가 발생한다.

  • 검색 결과가 부족하다.
  • 검색 결과가 틀렸다.
  • 여러 데이터베이스를 검색해야 한다.
  • 어떤 Retriever를 사용할지 결정해야 한다.

이때 Agent를 추가하면

Question
 ↓
Planner
 ↓
어디를 검색할 것인가?
 ↓
Retriever
 ↓
검색 결과가 충분한가?
 ├── Yes
 │      ↓
 │    Generate
 │      ↓
 │     END
 │
 └── No
        ↓
   Query Rewrite
        ↓
    다시 검색

처럼 상황에 따라 검색 전략을 변경할 수 있다.


Self-RAG는 Agent의 한 종류이다

Self-RAG는 새로운 검색 엔진이 아니라

검색 결과를 평가하여 필요하면 다시 검색하는 Agent 패턴

이다.

흐름은 다음과 같다.

Question
 ↓
Retrieve
 ↓
Generate
 ↓
Groundedness Check
 ├── PASS → END
 └── FAIL
        ↓
   Query Rewrite
        ↓
   Retrieve

Groundedness Check가

  • 답변이 충분한지
  • 다시 검색해야 하는지

를 결정한다.

즉, Groundedness Check가 Agent 역할을 수행한다.


ReAct Agent

ReAct(Reasion + Act)는 가장 유명한 Agent 패턴 중 하나이다.

LLM이

  1. 생각(Reason)
  2. 행동(Action)
  3. 결과 관찰(Observation)

을 반복한다.

예를 들면

Question
 ↓
LLM
 ↓
검색
 ↓
검색 결과
 ↓
LLM
 ↓
계산
 ↓
계산 결과
 ↓
LLM
 ↓
최종 답변

처럼 여러 Tool을 상황에 맞게 선택한다.


Localization RAG에서의 Agent 예시

Localization 프로젝트에서는

  • Glossary
  • Translation Memory
  • Style Guide
  • QA Database
  • Email

등 여러 종류의 데이터가 존재한다.

사용자가

Save는 어떻게 번역해야 하나요?

라고 질문했다고 가정하자.

단순한 RAG라면 모든 데이터를 한꺼번에 검색한다.

하지만 Agent를 사용하면

Question
 ↓
Planner
 ↓
용어 질문인가?
 ├── Yes → Glossary 검색
 └── No

Glossary에 없으면

TM 검색

그래도 없으면

Style Guide 검색

마지막으로

QA Database 검색

처럼 필요한 데이터만 순차적으로 검색할 수 있다.

검색 비용도 줄어들고 정확도도 높아진다.


LangGraph에서의 구현 예시

LangGraph에서는 다음과 같은 그래프를 쉽게 만들 수 있다.

START
  │
  ▼
Planner
  │
  ▼
Glossary Retriever
  │
  ▼
TM Retriever
  │
  ▼
Style Guide Retriever
  │
  ▼
Generate
  │
  ▼
Groundedness Check
  ├── PASS → END
  └── FAIL → Query Rewrite → Retriever

여기서

  • Retriever는 검색을 수행하는 Node
  • Generate는 답변 생성 Node
  • Groundedness Check는 의사결정을 수행하는 Agent 역할

이라고 볼 수 있다.


정리

Agent는 특정 라이브러리나 모델이 아니다.

LLM이 현재 상황을 바탕으로 다음 행동을 결정하는 의사결정 방식이다.

LangGraph는 이러한 Agent를 Node와 Edge로 구현하는 프레임워크이며, Agent는 그래프 안에서 "다음에 무엇을 할 것인가"를 결정하는 로직으로 동작한다.

특히 RAG에서는 검색 전략을 동적으로 변경하거나 여러 Retriever를 선택하고, 검색 결과를 평가하여 재검색하는 등의 기능을 구현하기 위해 Agent 패턴이 널리 사용되고 있다.

profile
오랜시간 망설였던 코딩을 다시 해보려고 노력하고 있는 사람

0개의 댓글