프로덕션 에이전트가 망각해서는 안 되는 이유: 메모리 감쇠, 복구 패턴, 그리고 장기적 신뢰성

Paul Twist · 2026년 7월 6일 · 6분 읽기

두 번째 달의 벽 (The Month-Two Wall)

에이전트는 처음 2주 동안은 아주 잘 작동합니다. 그러다 무언가 고장 납니다.

에이전트의 Postgres 세션이 충돌합니다. Lambda가 재시작됩니다. 에이전트 실행 중에 예정된 배포(deployment)가 발생합니다. 작업 중간에 리포지토리(repository) 연결이 타임아웃(timeout)됩니다.

시스템이 다시 돌아왔을 때, 에이전트는 모든 것을 잊어버린 상태입니다: 어떤 단계에 있었는지, 사용자가 무엇을 요청했는지, 어떤 컨텍스트(context)가 메모리에 로드되었는지, 어떤 상태(state)가 유지되어야 했는지 말입니다.

그 결과 에이전트는 다음 중 하나를 수행합니다:

• 처음부터 전체 작업을 다시 시작함 (토큰 비용 3배 발생)
• 중간 결과물을 유실함 (상태 오염)
• 오래된 컨텍스트(stale context)로 작업을 계속함 (잘못된 출력 생성)
• 충돌이 발생하고 "신뢰할 수 없음"으로 표시됨

이것이 2026년 7월 현재 프로덕션 팀들이 심하게 맞닥뜨리고 있는 '두 번째 달의 벽'이며, 이는 모델의 문제가 아닙니다. 프레임워크의 문제도 아닙니다. 이것은 에이전트 컨트롤 플레인(control planes)이 해결해야 할 인프라 신뢰성(infrastructure reliability) 문제입니다.

프로덕션 팀에 실제로 필요한 것

Reddit 빌더 커뮤니티(r/AI_Agents, r/Automation, r/n8n)에서는 하나의 패턴이 구체화되고 있습니다: 수익을 창출하는 에이전트는 내구성 있는 복구 경로(recovery paths)를 가지고 있습니다. 프로덕션에서 실패하는 에이전트는 그렇지 않습니다.

신뢰할 수 있는 패턴은 다음과 같습니다:

1. 상태 내구성 (State durability): 에이전트 세션 상태가 내구성이 있는 저장소(durable storage)에 저장됩니다 (프로세스 내 메모리나 포드(pod)의 휘발성 디스크가 아닌 곳에 저장).
2. 복구 체크포인트 (Recovery checkpoint): 인프라가 실패했을 때, 에이전트는 정확한 상태를 재구성하고 중단된 단계를 재개합니다.
3. 메모리 재구성 (Memory reconstruction): 세션 메모리(컨텍스트, 도구 결과, 중간 추론 과정)가 포드 충돌, 예정된 배포, 그리고 제공자 타임아웃(provider timeouts) 상황에서도 살아남습니다.
4. 감사 추적 (Audit trail): 각 실패 지점에서의 정확한 상태가 로그로 기록되고 쿼리(query) 가능해야 합니다. 이는 에이전트가 왜 재시작되었는지 디버깅하는 데 매우 중요합니다.
5. 제공자 독립성 (Provider independence): 메모리가 런타임 변경(Claude → Bedrock → Cursor) 시에도 유지됩니다.

대부분의 에이전트 프레임워크 (LangGraph, CrewAI, Anthropic SDK)는 이러한 속성을 보장하지 않습니다. 이들은 세션 상태 (session state)를 하나의 기능으로 제공할 뿐, **지속 가능한 복구 (durable recovery)**를 제공하지는 않습니다.

그것이 바로 컨트롤 플레인 (control plane)이 차별화되는 지점입니다.

복구 패턴 (The Recovery Pattern)

실제 지속 가능한 복구는 다음과 같은 모습입니다:

T=0:00    에이전트 시작: task = "README 작성"
T=0:15    단계 1: repo 클론 ✓ (상태 저장됨)
T=0:30    단계 2: 기존 문서 읽기 ✓ (상태 저장됨)
...

컨트롤 플레인이 없다면, 에이전트는 전체 워크플로우를 다시 시작하거나 (중간 결과 손실, 도구 호출 재실행), 영구적으로 충돌(crash)하게 됩니다.

컨트롤 플레인이 있다면, 복구는 투명하게 이루어집니다.

인프라가 없을 때 문제가 발생하는 지점

시나리오 1: 재시작 시 메모리 손실

• 에이전트가 50개의 문서를 세션 메모리 (session memory)에 읽어들임
• Pod 충돌
• 에이전트 재시작, 메모리 소멸
• 에이전트가 50개의 문서를 모두 다시 읽음 (토큰 비용 3배 발생)
• 또는: 에이전트가 컨텍스트 없이 계속 진행 (잘못된 출력)

시나리오 2: 부분적 상태 오염 (Partial State Corruption)

• 에이전트가 단계 5를 완료 (결과 저장됨)
• 단계 6 진행 중, 메모리에 부분적인 결과가 있음
• 단계 6 도중 Pod 재시작
• 컨트롤 플레인이 단계 6을 재시도할 수 있는지, 아니면 수동 검토가 필요한지 판단할 수 없음
• 에이전트가 작업을 중복 수행하거나 건너뜀

시나리오 3: 멀티 에이전트 핸드오프 (Multi-Agent Handoff)

• 에이전트 A가 작업을 마치고 에이전트 B에게 컨텍스트를 전달
• 에이전트 B가 수신 확인을 하기 전에 충돌
• 에이전트 B가 컨텍스트를 가지고 있는지 여부를 아무도 모름
• 작업이 분할되거나 중복됨

시나리오 4: 예정된 배포 (Scheduled Deployment)

• 에이전트가 작업 중간 단계임 (7단계 중 3단계)
• 배포가 발생함 (제로 다운타임이 중단 없는 것을 의미하지는 않음)
• 에이전트 Pod들이 교체됨
• 새 Pod는 진행 중인 작업에 대해 알지 못함
• 작업이 유실되거나 실패로 표시됨

LiteLLM 에이전트 플랫폼의 접근 방식

LiteLLM Agent Platform은 몇 가지 아키텍처적 선택을 통해 이 문제를 해결합니다:

1. 일급 객체로서의 세션 (Session as first-class object)
세션은 포드 (pod) 내부의 일시적인 상태가 아닙니다. 세션은 Postgres에 저장되어 쿼리가 가능하며, 런타임 (runtime)이 아닌 컨트롤 플레인 (control plane)이 소유하는 내구성이 있는 리소스입니다.

2. 단계별 체크포인팅 (Step-level checkpointing)
모든 에이전트 단계 (프레임워크 결정, 도구 호출, 모델 호출, 메모리 업데이트)는 단계가 실행되기 전에 세션 저장소에 체크포인트 (checkpoint)로 기록됩니다.

만약 단계가 실패하거나 포드가 충돌할 경우, 플랫폼은 다음 사항을 파악합니다:

• 어떤 단계가 실패했는지
• 정확한 입력 상태 (input state)
• 정확한 모델/도구 파라미터 (parameters)
• 해당 단계가 재시도 가능한지 또는 수동 검토가 필요한지

3. 선언적 복구 (Recovery is declarative)
포드가 충돌하거나 예정된 배포 (deployment)가 발생할 때, 컨트롤 플레인은 다음과 같이 동작합니다:

• 세션 상태를 쿼리합니다.
• 마지막으로 완료된 단계를 식별합니다.
• 체크포인트로부터 에이전트 메모리를 재구성합니다.
• 정확히 그 지점에서 재개합니다.
• 재시작도, 상태 손실도, 중복도 발생하지 않습니다.

4. 멀티 런타임 컨텍스트 핸드오프 (Multi-runtime context handoff)
에이전트 A (Claude)가 에이전트 B (Cursor)에게 작업을 전달할 때, 세션 메모리와 컨텍스트 (context)는 에이전트 A의 런타임이 아닌 컨트롤 플레인에 존재합니다.

만약 에이전트 B가 충돌하더라도, 컨트롤 플레인은 에이전트 A로부터 전달받은 전체 컨텍스트를 여전히 보유하고 있습니다.

이것이 장기적 에이전트 (Long-Horizon Agents)에게 중요한 이유

2026년에 수익을 창출하고 있는 프로덕션 에이전트들은 대개 다음과 같은 특성을 가집니다:

• 장기 실행 (수 시간 또는 수일간의 비동기 작업)
• 다단계 (8~20단계 이상의 결정)
• 도구 집약적 (리포지토리 작업, API 호출, 데이터베이스 쓰기)
• 멀티 런타임 (일부 단계는 Claude에서, 다른 단계는 Bedrock에서 실행)
• 고비용 (실패 시 토큰 비용이 누적됨)

이러한 에이전트들에게 인프라 장애는 예외적인 상황이 아니라 반드시 발생하는 일입니다. 24시간 동안 에이전트가 실행되는 동안 다음과 같은 일들이 반드시 발생합니다:

• 제공업체 타임아웃 (provider timeout)
• 포드 충돌 (pod crash)
• 예정된 배포 (scheduled deployment)
• 네트워크 일시 오류 (network blip)
• 메모리 제약 (memory constraint)

내구성이 있는 복구 기능이 없는 에이전트는 다음 중 하나를 겪게 됩니다:

• 작업을 다시 수행하며 비용을 낭비함
• 잘못된 출력 생성 (오래된 컨텍스트 사용)
• 신뢰할 수 없는 것으로 간주되어 비활성화됨

내구성이 있는 복구 기능을 갖춘 에이전트는 이러한 상황을 우아하게 처리합니다.

평가 프레임워크 (Evaluation Framework)

장기적 신뢰성 (long-horizon reliability)을 위해 에이전트 플랫폼을 평가할 때는 다음 질문들을 던져보아야 합니다:

다음 질문들을 확인하세요:

1. 포드 (pod) 충돌 시, 에이전트가 실패한 정확한 단계에서 복구됩니까, 아니면 재시작됩니까?

   • 재시작 (Restart) = 중복 발생 가능성, 토큰 낭비, 데이터 일관성 문제 발생
   • 단계별 복구 (Recover at step) = 애플리케이션에 영향을 주지 않음

2. 인프라 변경(포드 교체, 예정된 배포 등) 시에도 세션 상태 (session state)가 지속됩니까?

   • 휘발성 상태 (Ephemeral state) = 롤아웃 (rollout) 시 에이전트가 메모리를 상실함
   • 지속성 상태 (Durable state) = 에이전트가 중단 없이 계속 작동함

3. **에이전트가 상태를 잃지 않고 런타임 (runtime) 간에 컨텍스트 (context)를 전달할 수 있습니까? (예: Claude → Bedrock → Cursor)

   • 프레임워크 내부의 메모리 = 해당 런타임에 종속됨
   • 컨트롤 플레인 (control plane) 내의 메모리 = 런타임 간 이동 가능

4. 각 실패 지점에서의 정확한 상태를 보여주는 감사 추적 (audit trail)이 있습니까?

   • 프로덕션 장애 디버깅을 위해 필수적임
   • 컴플라이언스 (compliance) 및 거버넌스 (governance)를 위해 필수적임

5. 무슨 일이 일어났는지, 그리고 에이전트가 왜 실패했는지 이해하기 위해 세션 히스토리를 쿼리할 수 있습니까?

   • 이것이 없다면, 프로덕션 에이전트의 디버깅은 수동적인 시행착오의 반복이 됩니다.
   • 이것이 있다면, 실패 사례를 재현하고 추적할 수 있습니다.

패턴 (The Pattern)

프로덕션 에이전트의 신뢰성은 자율성이나 모델의 성능에 관한 것이 아닙니다. 그것은 상태를 유지하고, 실패로부터 우아하게 복구하며, 팀이 에이전트의 작업을 디버깅하고 다시 재생(replay)할 수 있게 해주는 인프라에 관한 것입니다.

이것이 바로 컨트롤 플레인 (control plane)이 선택 사항이 아닌, 기본 요건 (table-stakes)이 되고 있는 이유입니다.

LiteLLM 에이전트 플랫폼은 정확히 이 패턴을 기반으로 구축되었습니다: 포드를 위한 Kubernetes CRD, 세션 상태를 위한 Postgres, 팀별 격리, 단계별 체크포인팅 (step-level checkpointing), 그리고 완전한 감사 추적 (audit trails).

이것은 지루한 인프라입니다. 하지만 이것이 바로 프로덕션에 필요한 것입니다.

2주 이상 실행될 운명을 가진 에이전트라면, 이러한 인프라 격차 문제를 초기에 진지하게 다룰 가치가 있습니다.

주요 리소스:

• LiteLLM Agent Platform 문서: https://docs.litellm-agent-platform.ai
• 신뢰성 평가 (Reliability evaluation): https://github.com/BerriAI/litellm-agent-platform
• 세션 복구 아키텍처 (Session recovery architecture): https://docs.litellm-agent-platform.ai/architecture

에이전트 신뢰성에 대한 여러분의 경험은 어떠신가요? 여러분의 에이전트 인프라에서 상태 지속성 (state persistence)이나 장애 발생 후 복구 (recovery) 과정 중 어디에서 어려움을 겪고 계신가요? 댓글로 공유해 주세요.