당신의 에이전트는 당신이 잠든 동안에도 작동하는 메모리를 가지고 있습니다

이 포스트는 akm-knowledge 시리즈의 일부입니다. 열 번째 파트에서는 개선 파이프라인(improve pipeline) — 각 단계가 무엇을 하는지, 그리고 이를 어떻게 스케줄링하는지에 대해 소개했습니다. 이 포스트에서는 지속적인 운영(continuous operation)이 실제로는 어떤 모습인지 더 깊이 다룹니다: 하드웨어 수치, 하루 48회 실행 시 마주친 신뢰성 버그(reliability bugs), 그리고 모니터링을 위해 구축한 관찰 가능성 계층(observability layer)에 대해 설명합니다.

대부분의 사람들은 AI 에이전트의 메모리를 세션(session) 중에 발생하는 것으로 생각합니다. 에이전트와 대화하고, 에이전트가 무언가를 배우고, 아마 몇 가지 노트를 저장하면 세션이 종료됩니다. 다음 세션은 다시 초기 상태로 시작됩니다.

akm improve는 다른 모델을 기반으로 구축되었습니다: 당신의 하드웨어에서 실행되고, 로컬 모델(local models)을 대상으로 하며, 당신이 다른 일을 하는 동안 에이전트의 지식 베이스(knowledge base)를 조용히 큐레이션하는 지속적인 백그라운드 프로세스(continuous background process)입니다. 클라우드 API(cloud API)가 필요하지 않습니다. 유지 관리 패스(maintenance pass)를 위한 토큰당 과금(per-token billing)도 없습니다. 이미 소유하고 있는 GPU, 이미 다운로드해 놓은 모델이 스케줄에 따라 실행될 뿐입니다.

이 포스트에서는 24시간의 자율 운영(autonomous operation)이 실제로 어떤 모습인지, 소비자급 GPU(consumer-grade GPUs)가 부하를 어떻게 처리하는지, 지속적인 운영을 가능하게 만드는 신뢰성 작업, 그리고 로그를 지켜보지 않고도 작동 여부를 알 수 있게 해주는 관찰 가능성 계층(observability layer)에 대해 다룹니다.

akm improve가 24시간 동안 수행하는 작업

akm improve는 다단계 파이프라인(multi-phase pipeline)입니다. 핵심 패스인 통합(consolidation) 단계는 메모리 풀(memory pool)을 로드하고, 관련된 메모리들을 청크(chunks)로 그룹화한 뒤, 각 청크를 로컬 LLM(local LLM)으로 보내 통합 계획(유사한 메모리 병합, 신호가 높은 메모리를 저장소로 승격, 중복된 메모리 삭제, 모순점 노출)을 세우고, 그 계획들을 실행합니다. 통합 후에는 메모리 추론(memory inference)이 가벼운 사실 추출(factual extraction) 패스를 실행하며, 그래프 추출(graph extraction)이 엔티티-관계 인덱스(entity-relation index)를 업데이트합니다.

파이프라인은 자동으로 실행되도록 스케줄링되어 있습니다. 다음은 24시간 동안 생성된 결과물입니다:

지표	값
완료된 실행 횟수	48 / 48 — 실패 사례 없음
...

완료된 모든 실행은 시작 전보다 당신의 저장소(stash)를 더 나은 상태로 만듭니다. 수십 번의 에이전트 세션에 걸쳐 축적된 메모리들은 수동 개입 없이 압축(compress), 병합(merge) 및 정리(organize)됩니다. 이 기간 동안 발생한 1,361건의 승격(promotions)은 로컬 LLM(Large Language Model)에 의해 이름이 지정된 저장소 항목(named stash entries)으로 유지될 만큼 충분히 중요하다고 판단된 메모리들을 나타냅니다. 49건의 병합(merges)은 거의 중복되는 콘텐츠를 하나로 합쳤습니다. 211건의 모순(contradictions)은 조용히 덮어쓰여지는 대신 검토를 위해 플래그(flagged) 처리되었습니다.

이것이 루프(loop)입니다. 30분마다 실행됩니다. 당신은 이에 대해 고민할 필요가 없습니다.

소비자용 하드웨어에서 실행하기

이 설정에서 통합(consolidation)을 담당하는 LLM은 qwen3.5-9b(또는 유사 모델)이며, LM Studio를 통해 OpenAI 호환 엔드포인트(OpenAI-compatible endpoint)로 로컬에서 실행됩니다. 이 모델은 대부분의 최신 게이밍 GPU에서 여유롭게 돌아갑니다. API 키도 필요 없고, 호출당 비용도 들지 않습니다. 추론(inference)은 당신의 책상 위에 놓인 하드웨어에서 직접 이루어집니다.

우리는 두 개의 LM Studio 서버를 실행했습니다 — 두 서버 모두 OpenAI 호환 엔드포인트를 통해 동일한 모델을 제공합니다 — 그리고 이들을 직접 벤치마크(benchmark)했습니다.

Shredder는 RTX 5090이 장착된 데스크톱입니다. Splinter는 299달러에 출시되었으며 중급형 게이밍 빌드에서 흔히 볼 수 있는 RTX 4060 Ti를 실행합니다. 모델 가중치(weights)는 동일합니다. 청크 크기(chunk sizes)도 동일합니다. 다만 VRAM 대역폭(bandwidth)과 텐서 코어(tensor core) 개수가 다릅니다.

	RTX 5090 (Shredder)	RTX 4060 Ti (Splinter)
청크당 지연 시간 (Per-chunk latency)	~6.8s	~22.6s
...

5090이 더 빠르지만, 4060 Ti도 전체 통합 패스(consolidation pass)를 5분 이내에 완료합니다 — 이는 30분의 실행 시간 창(run window) 안에 충분히 들어오는 수치입니다. 두 카드 모두 주기(cycle)를 놓치지 않고 하루에 48회의 실행을 유지합니다.

차이가 나타나는 부분은 꼬리(tail) 부분입니다. 24시간 측정 기간에 두 백엔드(backend)에서의 실행이 모두 포함되었기 때문에, 합계 지연 시간(aggregate latency) 수치는 두 가지를 모두 반영합니다:

단계	중앙값 (Median)	P95	P95를 유발하는 요인
전체 (end-to-end)	7.2분	23.4분	Splinter-routed 통합 실행
...

7.2분의 중앙값은 대부분의 실행이 Shredder로 향함을 반영합니다. 23.4분의 P95는 거의 전적으로 더 큰 청크 윈도우(chunk windows)를 사용하는 Splinter 실행에 의한 것입니다. 4060 Ti에서만 실행되는 설정이라면 중앙값은 약 10~~12분, P95는 약 18~~20분 정도로 더 평탄한 분포를 보일 것이며, 중앙값을 낮추는 5090 실행은 없을 것입니다.

대부분의 설정에서 단일 미드레인지(mid-range) GPU가 적절한 시작점입니다. 통합(consolidation) 패스는 CPU 부하와 네트워크 부하가 적으며, 병목 지점은 GPU의 토큰 생성 처리량(token generation throughput)입니다. 만약 GPU와 여유 VRAM이 있는 두 번째 머신이 있다면, 두 번째 LM Studio 서버를 해당 머신으로 지정하여 우리가 여기서 했던 것과 똑같이 부하를 분산할 수 있습니다.

임베딩(embeddings) 서버는 별도로 분리되어 있으며 — localhost에서 실행되는 nomic-embed-text-v1.5 — 시맨틱 검색 인덱스(semantic search index)를 처리합니다. 이 서버는 실행 사이에 '웜(warm)' 상태를 유지하므로, 승격(promotions) 이후에 다시 임베딩을 수행하더라도 지연 시간(latency)은 무시할 수 있는 수준입니다. 여유 공간이 있다면 4GB 이상의 VRAM을 가진 어떤 GPU라도 통합 모델과 함께 이를 호스팅할 수 있으며

메모리 추론 (memory inference)에서의 69.3% 수율 (yield rate) 또한 같은 이야기를 해줍니다. 사실 추출 (factual extraction)을 위해 새롭게 시도한 166번의 사례 중 115번이 사용 가능한 원자적 사실 (atomic facts)을 생성했습니다. 이 모델은 지속적으로 실행할 가치가 있는 수준의 비율로 유용한 추론을 수행하고 있습니다.

로컬 9B 모델의 실질적인 한계는 그래프 추출 (graph extraction)에서 나타납니다. 24시간 범위 내에서 발생한 2건의 절단 (truncations)은 모델의 컨텍스트 윈도우 (context window)를 초과한 청크 (chunks)가 있었음을 나타냅니다. 이는 추출 실패가 아닌 부분적인 추출을 생성합니다. 즉, 모델은 자신이 볼 수 있는 범위 내에서 처리합니다. 더 큰 모델은 이 한계치를 높여줍니다. 예를 들어 5090은 VRAM에 더 큰 양자화 (quantizations) 모델을 담을 수 있습니다.

지속적인 작동을 신뢰할 수 있게 만들기

하루에 48번을 실행한다는 것은, 수동 워크플로우에서는 사소했을 신뢰성 문제가 시스템적인 문제로 변한다는 것을 의미합니다. 두 가지 버그가 통합 단계 (consolidation pass)에 영향을 미치며 영향을 받는 모든 실행에서 추론 (inference) 자원을 낭비하고 있었습니다.

오래된 데이터베이스 (stale database) 문제. 파일을 삭제하는 실행이 수행된 후, 데이터베이스에는 디스크에 더 이상 존재하지 않는 파일을 가리키는 항목들이 남아 있었습니다. 다음 실행 시 이러한 유령 항목 (ghost entries)들이 로드되었고, LLM은 이를 바탕으로 병합 계획 (merge plans)을 생성했으며, 파일이 발견되지 않을 때 Phase B가 조용히 실패했습니다. 해당 계획에 포함된 모든 영향받는 보조 항목 (secondary)들은 낭비된 추론 호출 비용을 발생시켰습니다.

해결책은 LLM이 무엇인가를 보기 전에 실행되는 사전 점검 필터 (pre-flight filter)입니다:

memories = memories.filter((m) => fs.existsSync(m.filePath));

오래된 항목들은 모델에 절대 도달하지 않습니다. 필터가 무언가를 잡아낼 경우 상태 출력 (health output)에서 확인할 수 있도록 경고가 로그로 기록됩니다:

Pre-flight: filtered 3 stale DB entries (file absent on disk) from memory pool before chunking.

환각 (hallucination) 문제. 특정 청크 구성 시 — 특히 세션 체크포인트 메모리 (session checkpoint memories)와 이름이 지정된 세션 (named sessions)이 동일한 윈도우에 나타날 때 — 로컬 모델이 명명 규칙 (naming conventions)을 혼합하여 풀 (pool)에 존재하지 않는 기본 참조 (primary ref)를 포함한 병합 계획을 생성하곤 했습니다.

전형적인 예시: 동일한 청크 (chunk) 내에 memory:opencode-session-20260529-a1b2와 memory:checkpoint-20260529T214550가 있으면, memory:opencode-session-20260529T214550-ses_18a4라는 환각된 기본 참조 (hallucinated primary)를 생성합니다. 이 계획은 청크 레벨 (chunk level)에서는 합리적으로 보입니다. 하지만 해당 참조는 풀 레벨 (pool level)에는 존재하지 않습니다.

수정 전에는, 이 환각된 기본 참조가 Phase B에 도달하여 모든 실제 보조 참조 (secondary, 일반적으로 4~8개의 참조)에 대해 실패한 병합 건너뛰기 (failed merge skip) 비용을 발생시켰습니다. 수정 후에는 mergePlans()가 실행 전에 로드된 풀 (pool)을 기준으로 모든 기본 참조 (primary ref)를 검증합니다:

const knownRefs = new Set(memories.map((m) => `memory:${m.name}`));
const { ops: allOps, warnings: mergeWarnings } = mergePlans(chunkOpsArrays, knownRefs);

실제 병합 계획은 진행됩니다. 환각된 루트 (hallucinated roots)는 폐기됩니다. 이 경고는 오래된 DB 경고 (stale-DB warning)와 구별되므로, 상태 지표 (health metrics)를 통해 두 가지를 구분할 수 있습니다:

mergePlans: primary memory:... not in loaded memory pool (LLM hallucination) — dropping op before execution.

두 가지 수정 사항 모두 낭비되는 추론 (inference)을 제거합니다. 청크당 22.6초가 걸리는 4060 Ti 환경에서, 6개의 보조 참조 (secondaries)에 비용을 발생시켰을 단 하나의 환각된 기본 참조만으로도 발생 시마다 2분 이상의 추론 시간을 절약할 수 있으며, 이 시간은 대신 실제 통합 작업 (consolidation work)에 투입될 수 있습니다.

작동 여부 확인하기

백그라운드에서 자율적으로 실행되는 것은 무언가 잘못되었을 때를 알 수 있어야만 도움이 됩니다. akm health는 최근 개선 활동에 대한 구조화된 뷰 (view)를 제공합니다:

akm health --since 4h
akm health --since 24h --format text

이 명령 하나로 실행 횟수, 건너뛰기 사유 분류, 통합 결과, 메모리 추론 수율 (memory inference yield), 그리고 단계별 지연 시간 (phase latencies)을 확인할 수 있습니다. 동일한 JSON 출력은 자동화 시스템에 입력값으로 제공됩니다.

지속적인 모니터링을 위해, 우리는 매시간 Discord에 지난 4시간 동안의 상태 보고서를 게시하는 cron 태스크를 구축했습니다:

# ~/akm/tasks/akm-health-report.yml
schedule: 0 * * * *
command: akm env run fwdslsh -- bash ~/akm/scripts/akm-health-discord.sh
...

해당 스크립트는 akm health --since 4h 및 --since 8h를 호출하여 트렌드 문맥(trend context)을 위한 차이(deltas)를 계산하고, Discord 임베드(embed)를 게시합니다:

akm tasks sync   # cron 등록

임베드에는 세 개의 인라인 필드 — 출력(Output: 승격됨, 병합됨, MI 수율), 실패(Failures: 청크 실패, 건너뛰기 이유 이상), 지연 시간(Latency: 중앙값, P95, 이전 윈도우와의 비교) — 와 더불어, 실제로 문제가 발생했을 때만 나타나는 '주의 필요(Needs Attention)' 섹션이 포함되어 있습니다. 푸터(footer)에는 호스트 이름(hostname)과 타임스탬프(timestamp)가 포함되어 있어, 여러 대의 머신에서 오는 보고서를 한눈에 구분할 수 있습니다.

결과적으로: 파이프라인에서 30분마다 상태 확인(health check)이 실행되고, 매시간 Discord로 가시성 보고서(visibility report)가 전송됩니다. 문제는 누적되기 전에 미리 파악할 수 있습니다.

전체 그림

자율적인 로컬 모델 메모리 큐레이션(autonomous local-model memory curation)이 하루 동안 어떻게 진행되는지 보여주는 모습은 다음과 같습니다:

48회의 실행이 개입 없이 완료됨
14,189개의 메모리가 검토, 정리 및 큐레이션됨
1,361개가 영구 저장소(permanent stash)로 승격됨
더 빠른 GPU 기준 통합(consolidation) 패스당 중앙값 1.4분; 4060 Ti에서는 5분 미만 소요
API 호출 0회 — 모든 추론(inference)은 소유한 하드웨어에서 로컬로 실행됨
매시간 Discord 보고서 — 수동 상태 확인이 필요 없음

이를 지속적으로 실행하기 위한 하드웨어 요구 사항은 중급형 게이밍 GPU입니다. 모델 요구 사항은 4~~8비트로 양자화(quantized)된 7~~9B 파라미터의 지시어 튜닝(instruction-tuned) 모델입니다. 두 가지 모두 많은 개발자가 이미 보유하고 있는 것들입니다.

가치는 복리로 쌓이는 부분에 있습니다. 각 실행은 저장소를 조금 더 정확하게, 조금 더 통합되게, 조금 더 일관되게 만듭니다. 48회의 실행 후에는, 수동으로 했다면 몇 시간이 걸렸을 14,000개의 메모리가 큐레이션 패스를 거치게 됩니다. 일주일이 지나면, 저장소는 차원이 다른 자산이 됩니다. 단순한 메모리 더미가 아니라, 에이전트가 세션 전반에 걸쳐 신뢰할 수 있는 지속적으로 유지 관리되는 지식 베이스(knowledge base)가 됩니다.

akm improve는 akm 0.8.x의 일부입니다. 전체 파이프라인 설정(pipeline configuration) 및 로컬 모델 설정(local model setup) 문서는 설정 참조(configuration reference)에 있습니다. 하드웨어 요구 사항(Hardware requirements) 및 LM Studio 설정은 시작 가이드(getting started guide)에서 다룹니다.