잘 기억하는 AI 에이전트 만들기: LangGraph의 State 설계

안녕하세요, 여립입니다! 

 

오늘은 저번 메모리와 온톨로지에 이어, 에이전트 구조에서 잘 기억하는 방법을 정리해보고자 합니다.
기존에 제가 에이전트의 개념에 대해 정리한 글이 있는데 먼저 읽어보고 오시면 이해하는데 도움이 됩니다.

 

메모리와 온톨로지: https://it-ist.tistory.com/390

AI의 지식은 어떻게 연결되는가? - 메모리와 온톨로지

 

Context Engineer과 멀티 에이전트 구조: https://it-ist.tistory.com/380

컨텍스트 엔지니어링 (Context Engineering): 프롬프트를 넘어 AI와 대화하는 새로운 방법

---

기존 글에서 제가 AI 에이전트를 이렇게 설명한 적이 있습니다. 

AI 에이전트는 환경을 감지하고, 그 환경 내에서 자율적으로 행동하며, 특정 목표를 달성하기 위해 의사결정을 수행하는 시스템입니다.
AI 에이전트와 LLM의 관계는 사람의 두뇌와 인체(팔&다리) 관계와 유사합니다. LLM은 AI 에이전트의 '두뇌' 역할을 하며, 에이전트 시스템은 이 두뇌를 활용하여 실제 환경에서 목표를 달성하기 위한 동작을 하게 됩니다.

 

좀 더 기술적인 구현 관점에서 바라보면, 여러가지 사고를 하는 구조를 멀티 에이전트라고 할때, 단일 에이전트는 특정 도메인의 특정 작업을 담당하는 역할이겠죠? 예를 들어 이메일을 자동으로 작성해주는 에이전트면, 내부 동작을 살펴봤을때, 기존 이메일을 파악하고, 그에 맞춰 이메일을 작성하고, 보내는 등, 결과를 만들어내기 위한 작은 작업들을 순차 혹은 병렬로 진행하게 됩니다. 단순히 llm한테 텍스트 생성으로 끝나는게 아니라, 손과 발을 달기 위한 선 후 작업이 존재합니다. 

 

이런 복잡한 구조의 AI 에이전트를 쉽게 구현하고자 등장한 프레임워크 중 제일 대표적인 것이 Langgraph입니다.

https://www.langchain.com/langgraph

LangGraph: Agent Orchestration Framework for Reliable AI Agents

 

LangGraph의 그래프란?

이 랭그래프에서는 DAG(방향성 비순환 그래프; Directed Acyclic graph) 방식으로 에이전트를 구현합니다. 

 

좀 더 간단하게 설명하자면, 그래프 방식은 에이전트가 일을 처리하는 순서를 한 줄로 쭉 실행하는 대신, 상황에 따라 갈림길을 선택하거나 되돌아갈 수 있는 구조로 설계하는 방법입니다.

 

각 작업 단계는 노드(Node)라고 하고, 각 노드를 연결하는 선을 엣지(Edge)라고 합니다. 이 노드는 하나의 작은 일을 담당하는 조각이고, 연결된 엣지를 이동해 다음 노드(작업)가 어디인지 알게 됩니다. 혹은 조건문을 통해 다른 길로 이동하거나 동시에 두개의 일을 처리할 수도 있죠.

 

한 줄로 쭉 실행되는 방식 대신, 상황에 따라 되돌아가거나 갈림길을 선택할 수 있는 유연한 구조를 만드는 것이 핵심입니다.

langgraph 구조 예시

State(상태): 에이전트의 전역 변수이자 공유 기억

여러 단계를 거치다 보면, 어떤 정보를 어떻게 기억하고 관리할지 문제가 됩니다. 위와 같은 형태에서 write assistant가 글쓰기를 끝낼지 판단하기 위해서는 이전 작업 정보와 현재 작업정보를 기억하고 있어야 할 것입니다. 그래서 각 노드가 정보를 공유받고 판단할 수 있도록 State(상태) 를 공유합니다; 일종의 `전역변수 (global variable)`이랄까요?

 

State에서는 지금까지 어떤 자료를 참고했는지, 이미 작성한 초안은 어디까지인지, 추가로 확인해야 할 항목이 남았는지 같은 정보를 기록해두어, 다음 노드가 이를 보고 같은 맥락에서 자연스럽게 다음 작업을 이어갈 수 있게 합니다. 일종의 기억이라고 볼 수 있겠죠.

 

그렇다면 State에 몽땅 다 저장하면 잘 기억하는걸까요?

 

---

 

'잘' 기억하기 위한 State 설계 원칙

결론부터 말하면 그렇지 않습니다.

 

이전 Context Engineering 글에서 설명했다시피, LLM이 받을 수 있는 프롬프트는 제한이 있고, 너무 많은 텍스트가 들어갈수록 오히려 핵심 맥락을 잃어버리는 현상이 생깁니다. 그렇기에 State는 무조건 크게 만드는 것이 아니라, 목적에 맞게 잘 구성하고 구조화하는 설계가 필요합니다.

 

State를 개념적으로 보면 “기억”의 한 요소지만, 기술적으로(특히 LangGraph 관점에서) 보면 State는 다음 노드의 작업에 데이터를 넘겨주고 관리하기 위한 데이터 구조체, 즉 하나의 모델 스키마에 가깝습니다.

• 어떤 값들이 반드시 존재해야 하는지
• 그 값들이 어떤 형태로 저장되는지(문자열인지, 리스트인지, 객체인지)
• 어떤 노드가 어떤 값을 변경하는지

State에는 현재 진행 중인 작업의 핵심 맥락, 결정된 사항, 다음 단계로 가기 위한 값만 엄격하게 담아야 합니다. Python의 TypedDict나 Pydantic을 활용해 데이터의 형식을 고정하고 검증하는 과정이 반드시 필요한 이유입니다.

 

> 그렇지 않으면 혼란에 빠지게 되겠죠!

 

노드 안에서의 동작

그렇다면 이런 State 구조가 실제 노드에서 어떻게 동작하게 될까요?

 

노드는 LLM에게 답변을 생성할 뿐만 아니라, 상태를 업데이트하는 함수로 동작합니다.

예를 들어 글쓰기 과정에서 에러가 났을 때, LLM이 “죄송합니다” 같은 문장을 생성하는 것만으로는 시스템이 안정적으로 움직일 수 없습니다. 노드는 State에 실패의 흔적을 남겨야 다음 경로를 결정할 수 있기 때문입니다.

 

예를 들면 이런 값들이 필요합니다.

• `error_log`: 어떤 단계에서 왜 실패했는지
• `retry_count`: 몇 번 시도했는지
• `next_step`: 다음에는 어떤 경로로 우회할지

이렇게 남겨진 상태를 바탕으로 엣지에서 조건에 따라 재시도할지, 종료할지, 혹은 다른 경로로 분기할지를 판단할 수 있게 됩니다.

 

업데이트 방식의 중요성

 

이런식으로 값을 기록하면, 여러 노드를 거치며 상태(State)가 비대해집니다. 그렇기에 단순히 값을 추가하기보단, 값을 어느시점에 어떻게 변경했는지 기록하는게 중요합니다.

 

값을 변경할 때 대표적으로 두 가지 방식이 있습니다.

• Append (추가): 대화 기록(History)처럼 데이터를 차곡차곡 쌓는 방식
• Overwrite (덮어쓰기): 현재 단계의 최종 결과물처럼 최신값으로 교체하는 방식

이 변경 방식이 명확하지 않으면, 시스템은 어느 순간 '무엇이 최신 정보인지' 알 수 없는 늪에 빠지게 됩니다. 운영 레벨에서는 특히 실행 과정(실행 결과 등)를 구조화해서 남겨야 에이전트가 시점을 구분해, 최신 데이터를 기반으로 판단할 수 있게 됩니다.

 

Persistence: 기억이 지속되게 하기

여기까지 보면 “과정 중에 발생한 결과를 잘 기록하는 것”까지는 정리가 된 것 같습니다.

그런데 실제 서비스에서는 중요한 것이 하나 더 있습니다. 바로 지속성(Persistence) 입니다.

 

실제 서비스 환경에서 에이전트는 단 한 번의 실행으로 끝나지 않습니다.

사용자가 며칠에 걸쳐 대화할 수도 있고, 중간에 사람이 개입(Human-in-the-loop)해 승인을 기다려야 할 때도 있습니다. 또는 외부 API 응답이 늦게 도착해서, 지금은 멈춰두고 나중에 이어서 실행해야 할 수도 있죠.

 

LangGraph의 Checkpointer 기능은 주요 분기점마다 State의 스냅샷을 저장하여, 상태를 어느 시점이든 지속할 수 있게 합니다.

• 사용자가 어제 대화하던 맥락을 오늘 그대로 이어갈 수 있게 합니다. 
• 특정 시점의 상태로 돌아가 다른 선택지를 시도하거나, 과거 결정 과정을 복기할 수도 있습니다.
• 외부 API의 응답이나 사람의 피드백이 올 때까지 에이전트를 '잠시 멈춤' 상태로 두었다가, 데이터가 채워지는 순간 그 시점부터 다시 깨어날 수 있게 합니다.

결국 잘 기억하는 에이전트는 단순히 정보를 많이 가진 에이전트가 아니라, 기억의 선후 관계를 명확히 하고 필요에 따라 그 기억의 어느 지점으로든 유연하게 연결될 수 있는 에이전트입니다. 결국 에이전트를 잘 설계한다는 것은, 단순히 기억하는데 끝나지 않고, 정교한 데이터 구조 상태를 설계하는 일에 가깝습니다. LLM은 그 안에서 추론과 결정을 돕는 매우 똑똑한 부품이고요.

---

 

오늘은 LangGraph의 Graph와 State를 개념적으로 살펴보았습니다. “에이전트가 내부적으로 어떻게 흘러가고, 어떤 방식으로 기억을 관리하는지”를 이해하는 데 조금이나마 도움이 되었길 바랍니다.

 

이상 글을 마치겠습니다. 읽어주셔서 감사합니다.