AI Memory OSS를 프롬프트가 아니라 백엔드 시스템으로 읽는 10가지 질문

AI memory를 처음 보면 prompt, embedding, vector search부터 눈에 들어옵니다. 하지만 기능을
운영 가능한 서비스로 만들려면 그 앞뒤의 상태와 실패를 함께 봐야 합니다. 원문은 언제 저장되는지,
느린 추론은 어디서 실행되는지, 파생된 기억은 무엇을 근거로 하는지, 검색 인덱스와 DB가 어긋나면
어떻게 복구하는지까지 답해야 합니다.

이 글은 AI memory OSS인 Honcho를 pinned source와 변경 이력으로 읽으면서 만든 질문 지도입니다.
Honcho의 모든 설계를 설명하거나 평가하려는 글이 아니라, 기능 설명을 실제 backend contract로
내려가기 위해 무엇을 물어야 하는지 정리합니다.

Scenario

사용자와 Agent가 오랫동안 대화하는 서비스를 생각해 보겠습니다.

사용자가 메시지를 보낸다.
-> 원문이 저장된다.
-> 느린 LLM 작업이 기억 후보를 만든다.
-> Agent가 나중에 필요한 기억을 검색한다.
-> 사용자는 말을 바꾸거나 삭제를 요청한다.

짧은 demo라면 최근 대화와 vector search만으로도 동작할 수 있습니다. 하지만 서비스가 오래
실행되면 질문이 달라집니다.

LLM 호출 중 API와 DB resource는 어떻게 되는가?
원문과 LLM이 만든 주장은 같은 데이터인가?
worker가 죽으면 어떤 상태부터 다시 시작하는가?
같은 기억이 중복 생성되면 무엇을 기준으로 막는가?
DB에는 있는데 vector index에는 없는 기억을 누가 복구하는가?
삭제는 DB row만 지우면 끝나는가?

그래서 AI memory를 다음과 같은 lifecycle로 읽었습니다.

write                                      (Q1)
-> durable raw state                       (Q2)
-> queue / worker                          (Q3)
-> derived claim + provenance              (Q2, Q4)
   provenance = 원본까지의 근거 연결
-> vector index sync                       (Q7)
-> scoped retrieval                        (Q5, Q6)
-> correction / deletion                   (Q8)
-> observability / cost control            (Q9)

schema evolution은 이 lifecycle 전체를 가로지른다. (Q10)

각 화살표는 구현 단계인 동시에 실패할 수 있는 경계입니다.

1. API boundary: 요청 안에서 어디까지 끝낼 것인가?

HTTP 응답 전에 반드시 저장해야 하는 상태는 무엇인가?
느린 embedding/LLM 호출은 어디서 끊어야 하는가?
외부 호출을 기다리는 동안 DB transaction이나 connection을 점유하는가?
요청 실패와 background 작업 실패를 어떻게 구분하는가?

비동기 API를 사용한다고 resource가 자동으로 짧게 유지되는 것은 아닙니다. Honcho의 한 변경을
추적했을 때도 핵심은 async 문법이 아니라 외부 호출과 DB session/transaction scope를 분리한
것이었습니다. 이 사례는 첫 번째 글에서 자세히 다뤘습니다.

2. State model: 원문과 파생된 기억의 grain(한 row가 의미하는 단위)은 무엇인가?

message와 memory document는 왜 분리되는가?
어떤 row가 원본이고 어떤 row가 LLM이 만든 claim인가?
claim은 어떤 source를 가리키는가?
사실, 추론, 패턴, 모순을 같은 상태로 취급하는가?

AI가 만든 문장을 원문과 같은 진실로 저장하면 나중에 수정, 재계산, 설명이 어려워집니다.
Honcho의 pinned model도 Message와 Document를 분리하고, document에 level과 source_ids를
둡니다. 여기서 가져갈 일반적인 질문은 특정 테이블 이름이 아니라 다음 계약입니다.

derived claim은 raw record와 다른 identity와 provenance를 가져야 하는가?

3. Queue/worker: queue item보다 논리적 작업의 identity가 있는가?

retry해도 같은 일임을 어떻게 식별하는가?
같은 사용자나 session의 작업은 어디까지 직렬화하는가?
다른 작업은 병렬로 실행할 수 있는가?
처리 중 worker가 죽으면 어떤 claim과 checkpoint가 남는가?

Queue를 도입했다는 사실만으로 중복 처리와 순서 문제가 해결되지는 않습니다. payload보다 먼저
이 시스템에서 같은 일은 무엇인가?를 정의해야 합니다. Honcho의 queue model에는
work_unit_key(같은 논리적 작업임을 식별하는 key)가 있고, 일부 pending 작업에는 이 key를
기준으로 한 unique constraint가 있습니다. 다만 enqueue부터 recovery까지의 전체 계약은 후속
source audit 대상으로 남겨뒀습니다.

4. LLM boundary: 모델이 판단하는 것과 코드가 강제하는 것은 무엇인가?

LLM은 어떤 판단만 맡는가?
출력이 비어 있거나 구조가 깨지면 어떻게 하는가?
source 없는 claim을 허용하는가?
성공은 API 응답 수신인가, schema 통과인가, 저장 완료인가?

LLM에게 유연한 판단을 맡기더라도 identity, 허용 상태, provenance, checkpoint 같은 계약은
결정적으로 검증할 필요가 있습니다. 모델의 좋은 답을 기대하는 것과 시스템이 잘못된 상태를
거부하는 것은 다른 책임입니다.

5. Identity/authz: actor, tenant, resource, subject가 같은가?

여기서 tenant는 고객 또는 workspace 단위의 격리 경계를 뜻합니다.

요청을 보낸 actor는 누구인가?
어느 workspace의 resource에 접근하는가?
누가 누구에 대해 만든 기억인가?
DB query와 vector search에 같은 tenant scope가 적용되는가?

Agent와 사용자를 하나의 identity model로 표현하면 도메인 모델은 유연해질 수 있습니다. 반면
요청자, 기억의 관찰자, 기억의 대상, resource owner가 서로 다른 축이 될 수 있습니다.
편리한 도메인 모델이 권한 검증까지 자동으로 단순화한다고 가정하면 안 됩니다.

6. Retrieval: 저장된 기억 중 무엇이 실제 답변 후보가 되는가?

semantic search 전에 어떤 tenant/session/level filter를 적용하는가?
원문 기반 claim과 상위 추론을 같은 우선순위로 검색하는가?
deleted, stale, sync-pending 상태는 후보에서 제외되는가?
응답에 source와 reasoning path를 함께 전달할 수 있는가?

기억을 만드는 pipeline과 Agent가 사용하는 serving path는 별개의 계약입니다. 저장 품질이 좋아도
retrieval filter가 잘못되면 다른 tenant의 기억, 삭제된 기억, 근거가 약한 추론이 답변에 들어갈
수 있습니다. Honcho의 retrieval filter 구성은 아직 별도 source audit 전입니다.

7. Index consistency: DB와 vector store의 반쪽 성공을 어떻게 복구하는가?

DB commit 후 vector upsert가 실패하면 무엇이 남는가?
DB에는 있지만 index에는 없는 row를 어떻게 찾는가?
재시도 횟수와 마지막 성공 시점을 기록하는가?
vector backend를 바꿔도 serving contract가 유지되는가?

Honcho의 pinned source에는 document의 sync_state, last_sync_at, sync_attempts와 DB와
vector index 사이의 어긋난 상태를 맞추는 background 작업인 reconciler가 존재합니다. 이 작업은
미동기 항목의 재시도와 삭제 잔여물 정리를 담당합니다. 이것은 중요한 조사 단서지만, 모든 crash
window와 복구 의미를 확인했다는 뜻은 아닙니다. DB-vector consistency는 별도의 teardown으로
검증할 예정입니다.

8. Deletion/retention: 언제 삭제가 완료됐다고 말할 수 있는가?

message를 삭제하면 파생된 document도 함께 처리되는가?
DB, vector index, cache, backup 중 어디까지 삭제해야 하는가?
soft delete와 hard delete 사이의 상태는 누가 소유하는가?
외부 index 삭제가 실패하면 DB row를 보존하는가?

AI memory에서 삭제는 개인정보 문제이면서 분산 상태 정합성 문제입니다. Honcho source에는
deleted_at으로 표시한 뒤 reconciler가 외부 vector 삭제와 DB hard delete를 처리하는 경로가
있습니다. 이 경로 역시 lifecycle 전체를 별도 audit하기 전에는 설계 완료 여부를 단정하지
않습니다.

9. Observability/cost: 운영자는 어떤 질문에 답할 수 있는가?

queue backlog와 stale work를 볼 수 있는가?
workspace별 memory 생성 지연을 알 수 있는가?
LLM latency, token usage, retry 비용을 추적하는가?
특정 memory가 왜 생성됐는지 source까지 추적할 수 있는가?
DB connection pool과 외부 provider 장애를 구분할 수 있는가?

관측성은 dashboard 제품명을 고르는 문제가 아닙니다. 먼저 운영자가 복구와 비용 판단을 위해
답해야 할 질문을 정하고, 그 질문에 필요한 durable state와 event를 남겨야 합니다. Honcho의
pinned source에도 message별 token_count와 sync 재시도 횟수 같은 단서 상태가 있지만, 운영
관측 전체는 아직 검증하지 않았습니다.

10. Schema evolution: 처음 정한 memory model이 틀리면 어떻게 바꾸는가?

새 identity나 document level을 기존 데이터에 어떻게 적용하는가?
old API/worker와 new schema가 동시에 존재할 수 있는가?
vector namespace나 ID 규칙 변경을 어떻게 backfill하는가?
rollback하면 새로 생성된 data shape을 어떻게 읽는가?

Agent 제품의 개념은 계속 바뀔 수 있습니다. 따라서 모델을 잘 정하는 능력만큼, 기존 데이터를
잃지 않고 계약을 바꾸는 migration 경로도 중요합니다. Honcho에는 migration 이력이 존재하지만
이 글에서는 그 경로를 검증하지 않았습니다.

질문을 실제 조사로 내리는 방법

이 질문들을 모든 기능에 한꺼번에 적용하면 거대한 체크리스트만 남습니다. 저는 다음 순서로
범위를 줄였습니다.

1. 지금 보는 기능의 actor를 정한다.
2. durable state transition을 시간순으로 적는다.
3. 그 전이에서 실제로 발생하는 pressure 하나를 고른다.
4. 코드, migration, test, commit에서 현재 답을 찾는다.
5. 내 시스템에는 copy / simplify / avoid 중 무엇을 할지 결정한다.

예를 들어 dream scheduling을 볼 때는 AI가 기억을 만든다에서 멈추지 않습니다.

actor: scheduler / worker
input: source-like explicit documents
in-flight owner: pending queue item
completed progress: success checkpoint
pressure: 비용, retry, source/derived feedback loop

이렇게 상태의 owner를 나누자, 파생된 출력이 다음 실행의 eligibility를 키우는 문제와 enqueue
시점에 checkpoint를 먼저 전진시키는 문제가 보였습니다. Honcho가 이를 어떻게 변경했는지는
두 번째 글에서 추적했습니다.

이 지도가 증명하지 않는 것

• 이 글은 Honcho의 공개 코드와 변경 이력을 읽으며 만든 분석 틀입니다. Honcho를 직접 구현, 운영하거나 기여한 경험이 아닙니다.
• 분석 기준은 85239a69b262c944de3c35900b91c88ba9b84f1a로 고정했습니다.
• 열 가지 질문이 모든 AI memory 서비스에 동일한 우선순위로 필요하다고 주장하지 않습니다.
• DB-vector consistency, deletion, observability, migration은 source에서 조사 단서를 확인했지만, 아직 lifecycle 전체와 runtime behavior를 검증하지 않았습니다.
• 이 질문 지도는 security review, privacy review, production load test를 대체하지 않습니다.

다음 teardown에서는 현재 source evidence가 충분한 주제부터 multi-tenant authz와 work-unit
serialization을 검토합니다. Retrieval, index consistency, deletion은 실제 실패 경계와 테스트를
확인한 뒤에만 공개 글로 승격할 예정입니다.

Sources

• Honcho repository
• Pinned Honcho source tree
• Pinned message, document, queue state models
• Pinned message write and enqueue boundary
• Pinned document retrieval paths
• Pinned vector sync reconciler
• Pinned soft-delete cleanup path
• 느린 LLM 호출 중 DB connection을 잡지 않는 이유
• AI memory가 자기 출력을 다시 입력으로 세지 않게 하는 법