회의록과 이력 전부를 프롬프트에 밀어 넣는 팀을 자주 본다. 초반엔 그럭저럭 맞춘다. 곧바로 응답 지연이 커지고 비용이 튄다. 더 근본적인 문제는 반복 작업에서 같은 실수를 다시 한다는 점이다. 맥락은 매번 새로 입력되고, 배운 것은 저장되지 않는다.
컨텍스트 확장은 지연을 키울 뿐, 잊힘은 남는다
OpenAI GPT-4는 128K, o1은 200K, Anthropic Claude 3.7 Sonnet도 200K, Google Gemini는 10M+ 컨텍스트를 지원한다. 수치는 인상적이지만 근본 이슈는 해결이 아니라 지연이다. 창고를 키우면 적재는 쉬워지지만, 필요한 순간에 꺼내 쓰는 시간이 늘어난다. 그리고 결국 “잊어버리는 지점”은 사라지지 않는다. 컨텍스트 창은 고정되어 있고, 무언가는 밀려난다.
컨텍스트 윈도우 확대는 캐시 증설이다. 메모리 문제는 아키텍처로 푼다.
따라서 “윈도우만 키우면 된다”는 접근은 운영 단계에서 한계를 드러낸다. 요청 지연과 비용 곡선이 급격히 궤도를 바꾸는 순간, 팀은 요약·선별·검색의 정책을 뒤늦게 도입한다. 이때부터가 진짜 메모리 설계의 시작이다.
2-tier 메모리: Core와 Archival이 표준이다
2025년 기준 에이전트 메모리는 두 층으로 나눈다. Core/In-context는 지금 답을 내는 데 필요한 최소 맥락이다. External/Archival은 장기 보관된 경험과 이력이며, 필요할 때 검색해 Core로 불러온다. 운영체제의 RAM과 Disk 계층과 같은 원리다.
이 구조를 시스템 차원에서 강제하는 것이 Memory-Augmented Generation(MAG) 계열이다. 상호작용 이력을 지속적으로 기록하고, salient information만 동적으로 추출해 재통합한다. Letta(구 MemGPT)는 core/archival 간 이동을 강제하는 흐름을 제공하고, Mem0는 memory-centric 아키텍처로 대화에서 중요한 정보를 추출·통합·검색한다. A-Mem, ByteRover는 계층적·선별적 컨텍스트 구성을 뒷받침한다. 핵심은 모델이 아니라 메모리 모듈이 “무엇을 언제 Core로 올릴지”를 결정하는 점이다.
아래 비교는 왜 ‘컨텍스트 확장만’으로는 운영 품질을 담보하지 못하는지 보여준다.
| 항목 | 컨텍스트 확장만 | 2-tier 메모리 설계 |
|---|---|---|
| 지연/비용 프로파일 | 입력이 늘수록 지연 누적, 비용 변동성 큼 | Core 최소화로 지연 안정, 비용 예측 가능 |
| 잊힘 관리 | 창 끝에서 무작위 탈락 | 정책적 요약·에비션으로 통제된 탈락 |
| 장기 학습 | 세션 종료 시 사실상 초기화 | Archival 축적·재통합로 경험 지속 |
| 운영 안정성/재현성 | 프롬프트 길이에 민감, 결과 변동 폭 큼 | 검색·요약 파이프라인으로 변동성 흡수 |
| 스케일 전략 | 모델 교체·윈도우 증설 의존 | 파이프라인·정책 튜닝으로 선형 확장 |
Context Engineering은 프롬프트를 대체했다
2025년 현장에서는 “적절한 시점에 적절한 정보를 주는 아키텍처 설계”가 독립 과업이 됐다. Context Engineering은 프롬프트 기법이 아니라, 메모리와 검색·요약·선별의 파이프라인을 설계·운영하는 일이다. 실무 스펙트럼은 단순 마크다운 파일부터 임베딩 벡터 스토어, 시간적 지식 그래프(temporal knowledge graph)까지 이어진다. 복잡도와 재현성 사이의 트레이드오프가 분명하다. 화려한 그래프가 항상 정답이 아니다. 재현 가능한 최소 파이프라인에서 시작해 필요에 따라 확장한다.
체크리스트를 간결히 적는다.
- 정보 수집: 대화·문서·이벤트에서 salient signal만 추출한다.
- 요약·정규화: 거친 텍스트를 정책 기반 요약과 스키마로 압축한다.
- 검색·선별: 작업 목적에 특화된 retrieval policy를 둔다.
- 에비션·버전: Archival 요약·스냅샷으로 잊힘을 통제한다.
- 평가·가드레일: 지연, 회수율, 오답 비용을 주기적으로 측정한다.
여기서 프레임워크 선택은 부차적이다. Letta, Mem0, A-Mem, ByteRover 같은 구성 요소는 원리를 구현하는 수단이다. 조직은 “정책과 관찰 지표”를 소유해야 한다. 그 위에 어떤 툴을 얹든 운영은 흔들리지 않는다.
마무리와 다음 단계
요지는 단순하다. 컨텍스트를 키우는 것은 캐시 증설일 뿐이고, 운영 가능한 에이전트는 2-tier 메모리와 Context Engineering으로만 만들어진다. 지연과 잊힘을 정책으로 다루지 않으면, 모델을 아무리 바꿔도 결과는 요행에 의존한다.
다음 단계는 명확하다. 현재 파이프라인에서 Core와 Archival의 경계를 정의하고, 요약·검색·에비션 정책을 문서화하라. 그리고 지연·정확도·재현성 지표를 주단위로 관찰해 조정하라. 마지막으로, 팀이 소유할 메모리 정책과 운영 리듬을 AX Ops로 정립하자. AX Ops 방법론 →