Antigravity Agent
4.4 KiB
4.4 KiB
상태 관리 (State Management)
📌 Brief Summary
에이전트 하네스에서 상태 관리(State Management)는 기본적으로 무상태(Stateless)인 대규모 언어 모델(LLM)이 다중 세션 및 장기 작업을 수행할 수 있도록 맥락과 작업 진행 상황을 보존하는 핵심 인프라 기능이다 [1-3]. 이는 모델이 이전 세션의 기억을 잃지 않고 작업을 재개할 수 있도록 세션 상태를 디스크나 파일 시스템에 기록(Session Persistence)하는 것을 포함한다 [4-6]. 상태 관리를 통해 에이전트는 도구 실행 결과, 하위 작업 완료 여부, 진행 노트 등을 영구적으로 추적하며, 시스템 충돌이 발생해도 처음부터 다시 시작하지 않고 이전 상태를 복구할 수 있다 [2, 4, 7].
📖 Core Content
- 상태 비저장성(Statelessness) 극복: LLM은 본질적으로 무상태이므로 하네스가 개입하지 않으면 에이전트는 매 세션마다 이전 작업의 지식 없이 백지상태에서 시작하게 된다 [1-3]. 에이전트 하네스는 이러한 모델의 한계를 극복하기 위해 메모리를 저장, 검색, 복구하며 장기 작업(Long-running tasks)을 가능하게 하는 제어 평면의 역할을 수행한다 [2, 3].
- 파일 시스템 및 영구 저장소 기반 상태 관리: 하네스는 파일 시스템을 활용하여 중간 상태를 디스크에 지속시키고, 컨텍스트 윈도우의 한계를 넘어 정보를 오프로딩(Offloading)한다 [5, 6, 8]. 일례로 초기화-실행자 분리(Initializer-executor split) 패턴을 사용하면 폴더 구조, 기능 목록, 진행 파일 등 내구성 있는 프로젝트 환경 상태가 설정되며, 후속 세션은 이 상태를 읽어 점진적으로 작업을 수행한다 [9].
- 세션 상태(Session State)와 체크포인팅: 에이전트의 상태 관리는 현재 작업 기간 동안의 도구 실행 결과, 완료된 하위 작업, 진행 노트 등에 대한 내구성 있는 로그를 관리하는 과정을 포함한다 [7]. LangGraph와 같은 오케스트레이션 프레임워크는 그래프 기반 상태 모델과 체크포인팅(Checkpointing) 기능을 제공하여, 실패 후에도 장기 작업을 재개할 수 있도록 에이전트 상태에 대한 명시적이고 세밀한 제어력을 제공한다 [10, 11].
- 관찰적 메모리 및 상태 압축 관리: Mastra와 같은 프레임워크는 백그라운드 에이전트를 통해 대화를 실시간 모니터링하고, 이를 구조화된 관찰 결과로 지속 압축하는 관찰적 메모리(Observational memory) 시스템을 사용하여 상태의 밀도와 품질을 자동 유지한다 [12, 13]. 더불어 컨텍스트 윈도우가 채워짐에 따라 이전 단계를 요약본으로 압축(Auto-summarization)하여 중간 상태를 관리하기도 한다 [8, 14].
⚖️ Trade-offs & Caveats
- 데이터 출처 및 계보 추적 상실: 컨텍스트 압축 및 자동 요약을 통해 상태를 관리할 경우 데이터의 출처(Provenance)가 조용히 손실될 수 있다 [8]. 에이전트가 요약·압축된 상태(컨텍스트)를 읽을 때 해당 정보의 기원이나 데이터 계보(Lineage)를 연결하는 추적 메커니즘이 끊어지기 때문에, 잘못된 결과가 도출될 경우 근본 원인을 파악하기 어려워진다 [8].
- 오염된 데이터 유입에 따른 상태 중독: 대부분의 오케스트레이션 프레임워크는 상태에 주입되는 입력 데이터가 깨끗하다고 가정할 뿐 이를 직접 검증하지는 않는다 [11, 15, 16]. 스키마 드리프트나 인증되지 않은 출처의 '오염된 데이터'가 하네스의 컨텍스트로 유입되면, 에이전트가 잘못된 기억을 바탕으로 연쇄 장애(Cascading failures)를 일으키거나 모델 스스로는 제거할 수 없는 '좀비 메모리' 문제를 겪을 수 있다 [17-19].
- 인프라 및 운영 복잡성 증가: 중간 상태를 유지하기 위해 파일 시스템 백엔드에 맥락을 오프로딩하는 방식은 컨테이너화된 배포 환경에서 운영 복잡성을 크게 증가시킨다 [20]. 또한 AutoGen과 같은 특정 프레임워크의 경우 대화형 상태(컨텍스트)가 누적될 때 자동화된 관리 기능이 없어 토큰 윈도우가 가득 차면 수동으로 상태를 가지치기(Pruning)해야 하는 제약 사항이 존재한다 [21].
Last updated: 2026-05-05