고충 (The Pain): GitHub를 검색해 보면 모두가 서로 다른 메모리 저장소 — ChromaDB, PostgreSQL, 일반 Markdown 파일, "SQLite면 10년은 충분해" 등을 사용하고 있는 것을 발견하게 됩니다. 무엇이 정답일까요?
정답 (The Answer): 모두 정답일 수도 있고, 모두 아닐 수도 있습니다. 시나리오를 이해하지 못한 채 선택하는 것은 도로 상태를 확인하지 않고 자동차를 사는 것과 같습니다.

1. 직관에 반하는 질문: 당신의 에이전트에게 실제로 "메모리"가 필요할까요?

제가 대학 입시 데이터 스크래퍼(91개 대학 대상)를 구축할 때, 전형적인 실수를 저질렀습니다. 에이전트에 ChromaDB + 벡터 검색 (vector retrieval) 스택을 통째로 장착하고, 사흘 동안 튜닝을 거친 뒤에야 깨달았습니다. — 에이전트가 사용하는 시간의 95%는 그저 "지난번에 어느 페이지까지 읽었나"를 확인하는 데 쓰이고 있었다는 사실을 말입니다.

불리언 (boolean) 값 하나면 충분했을 것입니다. 저는 의미론적 검색 (semantic search)이 가능한 벡터 데이터베이스 (vector database)를 구축했던 것입니다.

ByteDance의 한 엔지니어 친구는 그들의 내부 에이전트 플랫폼을 6개월간 운영해 본 결과, 벡터 검색 (vector retrieval)이 전체 메모리 저장소 (Memory Store) 요청의 3.7%만을 차지한다는 것을 발견했다고 말해주었습니다. 나머지 96.3%는 무엇이었을까요? 키-값 조회 (Key-value lookups), 상태 읽기/쓰기 (state reads/writes), 오류 중복 제거 (error dedup)였습니다. 당신이 통합하는 데 2주를 소비한 벡터 검색은 전체 쿼리의 4% 미만을 처리할 수도 있습니다.

따라서 "어떤 저장소"를 사용할지 논의하기 전에, 우리는 더 근본적인 질문에 답해야 합니다: 당신의 에이전트가 실제로 기억해야 하는 것은 무엇인가?

저는 메모리를 네 가지 유형으로 분류합니다:

패턴이 보이시나요? 만약 당신의 에이전트가 주로 다단계 자동화 (multi-step automation) (데이터 스크래핑, 보고서 생성, CI/CD 파이프라인)를 수행한다면, 앞의 세 가지 유형이 실제 필요한 것들이며 — 이 중 어느 것도 벡터 데이터베이스를 필요로 하지 않습니다.

핵심 논지: 메모리 선택은 "딱 적당한" 레이어를 찾는 것입니다. 레이어가 하나 더 많으면 낭비이고, 하나가 부족하면 재앙입니다.

2. 다섯 가지 메모리 저장소 옵션 — 데이터 기반 비교

저는 서로 다른 규모의 세 가지 프로젝트에서 이 옵션들을 각각 사용해 보았습니다. "장애 발생 순간(crash moments)"을 표로 정리했습니다:

• memory(): 엄격한 4,000자 제한. 조용한 잘림(Silent truncation) — 에러가 발생하는 것이 아니라, 그냥 이전 메모리를 조용히 삭제해 버립니다. 91개 대학 프로젝트 진행 시 학교당 3개의 메타데이터 항목을 저장했는데, 66번째 학교에 도달했을 때 가장 오래된 기록들이 사라졌습니다. 에러도, 로그도 없었으며 오직 불일치하는 결과만 남았습니다.
• SQLite: 이론적 한계 140TB. 별도의 튜닝 없이 2.3GB 크기의 SQLite 파일(870K 크롤러 기록)을 8ms 미만의 지연 시간(latency)으로 실행했습니다. WAL 모드에서는 읽기 작업이 쓰기 작업을 차단하지 않습니다. Stack Overflow 2024 보고에 따르면 SQLite는 단일 머신에서 100K+ QPS(초당 쿼리 수)를 달성할 수 있으며, 이는 에이전트 프로젝트의 99%를 감당하기에 충분합니다.
• ChromaDB 콜드 스타트 비용 (cold-start tax): M1 Mac에서 100K개의 레코드가 담긴 컬렉션을 로드하는 데 2.7초가 걸립니다. 수명이 짧은 에이전트(Serverless)의 경우, 요청당 2.7초가 소요되는 셈입니다. 반면 SQLite는 2GB 크기의 DB를 18ms 만에 엽니다.
• PostgreSQL 운영 비용 (ops tax): 4인 팀 프로젝트에서 PostgreSQL 유지 관리(커넥션 풀 튜닝, 느린 쿼리 추적, 백업 스크립트, docker-compose)가 전체 프로젝트 시간의 12%를 소비했습니다. PostgreSQL이 나쁘다는 뜻이 아니라, 프로젝트 규모가 그 운영 비용을 감당할 수 없었다는 의미입니다.

3. 3계층 메모리 아키텍처: 최소 비용으로 95% 커버리지 달성

다음은 세 가지 프로젝트를 통해 검증된 아키텍처입니다. 새로운 의존성(dependencies) 없이, "세션 상태(session state) + 도메인 지식(domain knowledge) + 에러 히스토리(error history)"를 모두 커버할 수 있는 조합입니다.

┌──────────────────────────────────────────┐
│ 3계층 메모리 아키텍처 (Three-Layer Memory Architecture) │
│ │
...
└──────────────────────────────────────────┘

L1: memory() — 에이전트의 "포스트잇 (Sticky Note)"

가장 적합한 용도: 사용자 선호도 ("중국어로 답변해줘"), 프로젝트 컨벤션 ("출력물은 /outputs/로 이동"), 환경 정보 ("Python 3.11").

치명적인 함정: 4,000자의 엄격한 제한. 해결책은 이를 피하는 것이 아니라, L1을 캐시 (cache)로 취급하고 중요한 데이터는 L2로 밀어내는 것입니다.

L2: STATE.md — 에이전트의 "내비게이션 지도 (Navigation Map)"

3계층 메모리의 중추입니다. 세션 시작 시 읽고, 작업 완료 후 업데이트되는 단일 Markdown 파일입니다. 핵심 코드는 80줄 미만입니다:

# state_manager.py — 자동 STATE.md 읽기/쓰기 도구
"""에이전트의 작업대 — 매 세션마다 읽고, 각 작업 후에 업데이트"""
from pathlib import Path
...

L3: ERROR_LOG.md — 에이전트의 "함정 기록 (Pitfall Record)"

중복 제거 기능이 포함된 에러 전용 추가 기록(append-only) 로그입니다. 핵심 메커니즘은 다음과 같습니다: 각 에러는 지문(fingerprint, 예: 에러 메시지의 해시값)을 가집니다. 동일한 지문이 나타나면 중복 항목을 생성하지 않고 건너뜁니다.

# error_log.py — 중복 제거 기능이 있는 에러 로깅
from pathlib import Path
import hashlib
...

세 계층은 서로를 보완합니다: L1은 빠르지만 용량이 작고 / L2는 구조화되어 있고 읽기 쉬우며 / L3는 중복 제거가 가능하고 쿼리(query)가 가능합니다.

4. 의사결정 흐름: 언제 어떤 계층을 사용할 것인가?

저장해야 할 내용...
├── 사용자 선호도 / 프로젝트 컨벤션?  → L1 memory()
├── 작업 진행 상황 / 상태(state)?     → L2 STATE.md
...

경험 법칙: 작동하는 가장 단순한 계층부터 시작하세요. 구체적인 한계에 부딪혔을 때만 복잡성을 추가하세요.

5. 당신의 현재 위치

당신은 이제

다음: 품질은 우연히 만들어지지 않습니다 — Maker/Checker 분리와 자동화된 검증.

저자 소개: Wu Ji (无记) — 에이전트 엔지니어링 (Agent engineering), 루프 엔지니어링 (Loop Engineering), 그리고 디지털 전환 (digital transformation)에 집중하는 AI 및 디지털화 실무자. 실용적이고 직접 따라 할 수 있는 튜토리얼을 제공합니다 — 함께 따라오시면 바로 작동합니다.