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

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은 무엇인가?

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은 실제 실패 경계와 테스트를 확인한 뒤에만 공개 글로 승격할 예정이다.