본문으로 건너뛰기

© 2026 Molayo

Dev.to헤드라인2026. 06. 28. 18:16

실제로 기억하는 AI 에이전트를 구축하는 방법

요약

다단계 워크플로우를 수행하는 AI 에이전트가 상태를 유지하지 못해 발생하는 문제를 해결하기 위한 계층화된 메모리 아키텍처를 소개합니다. 상태 없는 루프, 무한한 컨텍스트 창, 취약한 인메모리 상태의 한계를 지적하며 구조화된 체크포인팅의 중요성을 강조합니다.

핵심 포인트

  • 단순 컨텍스트 확장은 토큰 비용 폭발과 집중력 저하를 야기함
  • 계층화된 메모리 아키텍처를 통해 단기/장기 기억을 분리해야 함
  • 구조화된 로그를 통한 체크포인팅으로 중단 지점부터 재시작 가능
  • 트리 구조의 상태 전이 기록은 디버깅과 복구에 필수적임

저는 한 에이전트가 15단계의 브라우저 워크플로우(workflow) 중 12단계를 완료한 후, 이미 무엇을 제출했는지 기억하지 못해 충돌(crash)하는 것을 지켜보았습니다. 양식은 절반만 채워져 있었습니다. 데이터는 유실되었습니다. 세션은 무용지물이었습니다.

그것은 2024년 초의 일이었습니다. 그 이후로 저는 이 문제를 다르게 처리하는 프로덕션(production) 에이전트 시스템들을 구축해 왔습니다. 매일 10,000개 이상의 매물을 점수화하는 구인구직 플랫폼, 수십 개의 맞춤형 문서를 병렬로 생성하는 AI 이력서 맞춤 제작 도구, 상태(state)를 잃지 않고 다중 페이지 워크플로우를 탐색하는 브라우저 자동화 에이전트 등이 그 예입니다.

초기의 실패와 오늘날 작동하는 것 사이의 차이점은 단 한 가지로 귀결됩니다. 바로 컨텍스트 지속성(context persistence)을 어떻게 처리하느냐 하는 것입니다.

대부분의 에이전트 메모리 아키텍처가 실패하는 이유

세 가지 패턴이 프로덕션 에이전트를 완전히 망가뜨립니다.

첫째, 상태가 없는 루프(stateless loop)입니다. LLM을 호출하고, 응답을 받고, 그에 따라 행동한 다음, 최종 출력물을 제외한 모든 것을 버립니다. 다음 호출은 제로(zero) 상태에서 시작됩니다. 이는 단발성 작업에는 효과적이지만, 다단계 작업에는 실패합니다.

둘째, 무한한 컨텍스트 창(context window)의 함정입니다. 프롬프트(prompt)에 모든 것을 쏟아붓습니다. 이전의 모든 출력, 모든 관찰(observation), 전체 대화 기록까지 말이죠. 이것은 작동하는 듯 보이다가 결국 한계에 부딪힙니다. 토큰(token) 비용이 폭발합니다. 모델은 소음의 바다 속에서 집중력을 잃습니다. 그리고 긴 세션에서는 컨텍스트 제한(context limits)에 도달하게 됩니다.

셋째, 취약한 인메모리(in-memory) 상태입니다. 실행 중인 객체(object)에 세션 데이터를 보관합니다. 개발 단계에서는 잘 작동합니다. 하지만 프로덕션 환경에서는 서버 재시작, 충돌, 또는 동시 요청(concurrent request)이 발생하면 모든 것이 삭제됩니다.

저는 이 세 가지를 모두 경험했습니다. 해결책은 에이전트가 지금 당장 알고 있는 것과 장기적으로 기억해야 하는 것을 분리하는 계층화된 메모리 아키텍처(layered memory architecture)입니다.

패턴 1: 구조화된 로그를 통한 체크포인팅(Checkpointing)

실질적인 차이를 만드는 가장 간단한 패턴은 의미 있는 모든 상태 전이(state transition)를 데이터베이스에 기록하는 것입니다.

구인구직 플랫폼의 LLM 스코어링 파이프라인(scoring pipeline)의 경우, 각 매물(listing)에 대한 스코어링 호출마다 구조화된 레코드(structured record)가 생성됩니다. 에이전트는 어떤 매물을 스코어링했는지, 어떤 기준(criteria)을 사용했는지, 어떤 점수를 부여했는지, 그리고 그 이유가 무엇인지를 기록합니다. 만약 프로세스가 중단되더라도, 다음 실행 시 모든 것을 다시 스코어링하는 대신 중단된 지점부터 다시 시작할 수 있습니다.

interface AgentCheckpoint {
  sessionId: string;
  stepNumber: number;
...

핵심적인 통찰은 parentStep 필드에 있습니다. 이는 단순히 평면적인 리스트(flat list)가 아닌, 작업(actions)의 트리(tree) 구조를 생성합니다. 에이전트가 되돌아가거나(backtracks) 재시도(retries)할 경우, 에이전트가 거쳐온 정확한 경로를 추적할 수 있습니다. 이는 디버깅(debugging)과 복구(recovery)를 위해 매우 중요합니다.

실제로 저는 모든 LLM 호출 전후에 체크포인트(checkpoint)를 작성합니다. 비용은 단계(step)당 데이터베이스 쓰기(write) 한 번입니다. 이점은 에이전트가 충돌(crash)하더라도 처음부터 다시 시작하는 대신 몇 초 만에 복구된다는 것입니다.

패턴 2: 장기 기억을 위한 벡터 스토어 (Vector Stores)

체크포인트는 단기적인 작업 상태(short-term task state)를 처리합니다. 하지만 에이전트는 세션(session)을 넘나들며 기억해야 할 것들도 필요합니다. 선호도(preferences), 과거의 결정(past decisions), 반복되는 패턴(recurring patterns) 같은 것들 말입니다.

이 지점에서 벡터 스토어(vector stores)의 진가가 발휘됩니다.

AI 이력서 맞춤화(resume tailor) 서비스에서, 에이전트는 여러 번의 맞춤화 작업 동안 사용자의 기본 이력서 내용을 기억해야 합니다. 각 프롬프트(prompt)에 전체 문서를 다시 불러오는 대신, 이력서 섹션의 임베딩(embeddings)을 저장하고 각 새로운 작업에 관련 있는 내용만 검색(retrieve)합니다.

import { OpenAIEmbeddings } from '@langchain/openai';
import { PineconeStore } from '@langchain/pinecone';

...

요령은 무엇을 저장할지 의도적으로 결정하는 것입니다. 모든 관찰(observation)이나 모든 출력(output)을 저장해서는 안 됩니다. 재사용 가치가 있는 결정, 선호도, 사실(facts)을 저장하세요. 읽기 시점(read time)이 아니라 쓰기 시점(write time)에 공격적으로 필터링해야 합니다.

패턴 3: 하이브리드 아키텍처 (The Hybrid Architecture)

이것이 제가 실제로 프로덕션(production) 환경에서 실행하는 방식입니다. 두 가지 패턴을 하나의 에이전트 루프(agent loop)로 결합한 형태입니다.

단기 작업 상태는 구조화된 체크포인트 로그(checkpoint log)에 저장됩니다. 에이전트는 시작 시 최신 체크포인트를 읽고 거기서부터 재개합니다. 손실될 위험이 있는 인메모리 상태(in-memory state)는 존재하지 않습니다.

장기 지식(Long-term knowledge)은 벡터 스토어(vector store)에 저장됩니다. 에이전트는 새로운 작업이 시작될 때마다 이를 쿼리(query)하고 그 결과를 시스템 프롬프트(system prompt)에 추가합니다. 이를 통해 컨텍스트 윈도우(context window)가 즉각적으로 관련 있는 내용에 집중할 수 있도록 유지합니다.

또한 에이전트는 각 작업이 완료된 후 새로운 관찰(observations) 내용을 벡터 스토어에 다시 기록하므로, 시간이 지남에 따라 메모리가 성장합니다.

async function agentLoop(task: Task, sessionId: string) {
  // 마지막 체크포인트에서 재개
  const checkpoint = await loadCheckpoint(sessionId);
...

이 루프는 단순합니다. 그것이 핵심입니다. 복잡성은 그 무엇보다도 에이전트의 신뢰성을 빠르게 무너뜨립니다.

프로덕션의 현실 (The Production Reality)

컨텍스트 지속성(Context persistence)은 나중에 추가하는 기능이 아닙니다. 그것은 첫날부터 내려야 하는 구조적 결정입니다.

구직 게시판 플랫폼의 스코어링 파이프라인(scoring pipeline)은 매일 수천 건의 LLM 호출을 실행합니다. 체크포인팅(checkpointing)이 없다면 단 한 번의 충돌(crash)로 몇 시간 분량의 작업이 손실될 것입니다. 벡터 스토어가 없다면 시스템은 동일한 리스팅 패턴을 반복해서 재분석할 것이며, 그 비용은 터무니없이 높아질 것입니다.

12단계에서 충돌했던 그 에이전트요? 저는 이 아키텍처(architecture)로 그것을 다시 구축했습니다. 그 이후로는 세션을 놓친 적이 없습니다. 만약 여러분의 팀이 작업 도중 컨텍스트를 잃어버리는 에이전트 때문에 고군분투하고 있고, 그로 인해 배포 속도가 늦어지고 있다면, 그것이 바로 제가 도와드리는 영역입니다. 대규모 환경(at scale)에서 무엇이 효과적인지에 대해 의견을 나눌 수 있다면 기쁘겠습니다.

작성자: Abdul Rehman, 프로덕션 SaaS, MVP 및 AI 자동화를 구축하는 풀스택 AI 엔지니어. 더 자세한 내용은 PrimeStrides에서 확인하세요.

AI 자동 생성 콘텐츠

본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.

원문 바로가기
0

댓글

0