AI 에이전트의 메모리를 LLM 컨텍스트 윈도우에 넣지 마세요
Stop putting your AI agent’s memory inside the LLM context window
핵심 요약
LLM 컨텍스트 윈도우 대신 외부 데이터베이스와 결정론적 제어 흐름을 사용하여 에이전트 상태를 관리하라는 조언입니다.
- 상태 분리 — 에이전트 메모리는 LLM 내부가 아닌 Postgres 같은 외부 DB에 저장함
- 결정론적 제어 — 비즈니스 로직은 시스템 프롬프트가 아닌 코드나 상태 그래프로 구현함
- 판단 레이어 — LLM은 상태 저장소가 아닌 비정형 데이터 처리 및 도구 매개변수 생성에 집중함
- 운영 효율성 — 외부 DB 사용으로 에이전트 실행의 일시 정지, 재실행, 단위 테스트가 가능해짐
여러분 안녕하세요. 최근 에이전트 워크플로우를 프로덕션에 몇 개 배포하면서, 사람들이 계속해서 저지르는 엄청난 아키텍처 실수를 보고 한마디 하려고 합니다. LLM 컨텍스트 윈도우나 거대한 벡터 임베딩을 에이전트의 장기 기억 장치로 취급하지 마세요.
에이전트가 상태를 유지해야 하거나, 과거의 오탐(false positive)을 기억해야 하거나, 인간 개입 워크플로우를 처리하거나, 감사 추적을 유지해야 할 때, 거대한 JSON 덩어리를 세션 기록으로 프롬프트에 계속 주고받는 건 조용한 실패와 엄청난 토큰 비용을 초래하는 지름길입니다.
현재 저희가 프로덕션에서 실제로 성공적으로 운영 중인 유일한 아키텍처는 엄격한 관심사 분리에 의존합니다.
첫째, 지속 가능한 상태와 메모리는 에이전트 외부의 지루하지만 구조가 잘 잡힌 트랜잭션 데이터베이스(Postgres나 Lakebase 등)에 완전히 저장되어야 합니다. 에이전트는 부팅 시 이를 읽고 도구 실행 시 여기에 기록하기만 하면 됩니다. 에이전트 자체가 데이터베이스가 되어서는 안 됩니다.
둘째, 결정론적 제어 흐름을 사용하세요. "데이터를 쓰기 전에 항상 인간에게 물어볼 것"과 같은 명시적인 비즈니스 제약 조건이 있다면, 그 로직을 파이썬 코드나 Langgraph 같은 상태 그래프 프레임워크에 구현하세요. 안전 경계를 강제하기 위해 시스템 프롬프트에 의존하지 마세요.
마지막으로, LLM을 판단 레이어로 취급하세요. 모델은 비정형 입력 처리, 도구 매개변수 생성, 또는 증거 요약에만 엄격하게 사용하세요.
상태 레이어를 전용 DB로 옮기면 컨텍스트 드리프트나 환각이 에이전트의 기록을 지워버릴 걱정 없이 에이전트 실행을 실제로 일시 정지, 재실행, 단위 테스트할 수 있습니다.
다들 며칠씩 걸리는 워크플로우를 위해 영구 상태를 어떻게 처리하고 계신지 궁금합니다. 전부 커스텀 SQL 테이블로 감싸고 계신가요, 아니면 프레임워크의 메모리 기능을 믿고 계신가요?
.
