Antigravity Agent
c24165b8bc
에이전트 8종(대화형/프로그래머 C·S/디자이너/설계자/기획자/QA/PD/PM)에게 [공통 기본 능력 + 롤별 Specialty] 2층으로 지식을 주입하기 위한 재분류. 문서 내용·포맷은 무수정, 폴더 이동만 (6,372개 문서 수 보존 확인). - Topic_Programming → Domain_Programming (내부 구조 보존) - Topic_Graphic → Domain_Design - Topic_Business → Domain_Product - Topic_General → Domain_General - _Common 신설: Math(구 Topic_Math_Specialty), Reasoning(구 General/From_Thinking & Reasoning), Reasoning_Creativity(구 General/From_창의성), Communication(Poetic_Blog_Writing + From_writing) - 타 도메인의 From_* 폴더는 유지 (출처 표기일 뿐, 이미 도메인에 맞게 분류된 문서) - 빈 폴더 정리 (memory/procedures) - 에이전트→폴더 매핑은 workspace의 .astra/agent-knowledge-map.json (9개 에이전트) Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
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