> 같은 문제, 다른 전제. 2025년 말부터 2026년 초에 걸쳐 agent memory 카테고리에 두 개의 선명한 답이 나왔다. 하나는 "기억이란 무엇인가"라는 인식론적 질문에서 시작했고, 다른 하나는 "기억을 어떻게 운영하는가"라는 공학적 질문에서 시작했다. 둘을 나란히 놓고 들여다본다.
프롤로그: 카테고리가 분화한 순간
2025년까지 "AI 메모리"라는 말은 대체로 RAG의 연장이었다. 벡터 DB에 청크를 넣고, 쿼리 시점에 top-k로 끄집어내고, 프롬프트에 붙인다. 이 방식의 한계는 누구나 알고 있었다. 장기 세션에서 모순이 누적되고, 시간 축이 없고, 의견과 사실이 섞인다. 하지만 그럴싸한 대안이 나오기 전까지는 "조금 더 정교한 RAG"들의 경쟁이었다.
2025년 12월 14일, Vectorize.io가 Virginia Tech과 The Washington Post 공동연구로 Hindsight 논문(arXiv 2512.12818, _"Hindsight is 20/20: Building Agent Memory that Retains, Recalls, and Reflects"_)을 공개하면서 상황이 바뀌었다. 같은 시기, 한국에서는 Nunchi AI가 Synapsis Engine을 기반으로 Nexus와 AMCP(Agent Memory Continuity Protocol) 오픈 스펙을 발표하고 있었다.
두 시스템은 같은 문제, LLM 에이전트가 세션을 넘어 일관된 기억을 갖게 한다는 문제를 풀지만, 그 뿌리의 질문이 다르다. 그 차이가 구조 전체를 결정한다.
Part 1. Hindsight의 접근: 인식론적 분리
Hindsight의 출발점은 이 문장이다.
> _"Current memory systems blur the line between evidence and inference."_ > Hindsight 논문 abstract
사실(evidence)과 추론(inference)의 경계가 흐려진 채 기억이 축적되면, 에이전트는 자기가 왜 그렇게 믿는지 설명하지 못하고, 모순이 생겼을 때 어느 쪽을 우선할지 판단 근거가 없다. Hindsight의 답은 기억을 인식론적으로 분리한 네 개의 네트워크다.
네 개의 네트워크
| 네트워크 | 역할 | 예시 |
|---|---|---|
| World | 객관적 세계 사실 | "ACME의 본사는 Seoul에 있다" |
| Experience (Bank) | 에이전트가 직접 경험한 것 (1인칭) | "지난 금요일 CEO와 제품 리뷰를 진행했다" |
| Opinion | 주관적 신념 + 신뢰도 점수 | "사용자는 Python보다 TypeScript를 선호하는 것으로 보임 (confidence 0.7)" |
| Observation | 엔티티별 중립 요약 | "CEO Alice: 기술 배경 엔지니어, 의사결정 빠름, 세부 지표에 민감" |
핵심은 Opinion이 confidence score를 갖고, 그 의견을 만든 evidence(raw memories)를 역추적할 수 있다는 점이다. "왜 그렇게 생각하나?"를 물으면 에이전트가 증거 체인을 제시할 수 있다.
세 개의 연산: Retain, Recall, Reflect
메모리 위에서 동작하는 연산도 세 개로 분화된다.
- Retain: 대화 스트림에서 사실 단위(narrative fact)로 추출, 엔티티 해결, 네 개 네트워크 중 하나로 분류.
- Recall: 쿼리에 대해 4-way 병렬 검색(semantic + BM25 + graph traversal + temporal filtering). Reciprocal Rank Fusion으로 통합하고 cross-encoder로 재랭킹.
- Reflect: 검색된 기억 + behavioral profile Θ(skepticism, literalism, empathy 같은 성향 변수)로 응답 생성. 이 과정에서 의견 네트워크가 진화한다.
Reflect가 특히 인상적이다. 기존 memory 시스템은 retain/recall만 갖고 있었다. 즉 "저장"과 "꺼냄"만 있었다. Reflect는 기억 위에서 추론하고, 그 추론이 다시 기억을 업데이트한다. 이게 논문이 "memory as first-class substrate for reasoning"이라고 부르는 이유다.
한 문장 요약
Hindsight = "기억을 사실/경험/의견/요약으로 쪼개고, 추론을 일급 시민으로 승격시킨 인식론적 메모리 아키텍처"
Part 2. Synapsis Engine의 접근: 운영 원칙
Synapsis Engine의 출발점은 다른 문장이다.
> _"Memory systems fail in production not because they lack sophistication, but because they violate operational discipline."_
Synapsis Engine을 만들면서 확인된 경험적 사실은 이랬다. 구조가 복잡해져도 기본 법칙을 어기면 메모리는 무너진다. 우리는 이걸 수개월 동안 6회 반복한 LongMemEval 벤치마크에서 반복 확인했다. 그래서 Synapsis Engine의 뿌리는 "더 정교한 구조"가 아니라 "지켜야 할 법칙"에서 시작한다.
3대 설계 법칙
Synapsis Engine의 코어에 박혀있는 세 가지 원칙은 이렇다.
1. 원자를 삭제하지 않는다 (Never delete atoms) 기억은 contradict되어도 overwrite되지 않는다. 구 정보는 superseded_by 관계로 링크되고 남는다. 왜냐하면 시간 축을 잃으면 에이전트는 "언제부터 그렇게 생각했는지"를 설명하지 못하기 때문이다.
2. 원자를 재정렬하지 않는다 (Never reorder atoms) 시간 순서는 메모리의 기본값이다. 중요도로 재정렬하는 순간 시간 추론이 깨진다. 우선순위는 검색 결과에서만 반영하고, 저장은 항상 시간 순서로 둔다.
3. 검색 점수에 비유사도 신호를 주입하지 않는다 (Never inject non-similarity signals into retrieval scores) "최근이니까", "confidence가 높으니까" 같은 2차 신호를 유사도 점수에 섞으면 retrieval이 편향된다. 시간이나 신뢰도는 필터로 쓰되, 점수에는 쓰지 않는다. 이 법칙은 단순해 보이지만, 대부분의 RAG 시스템이 이걸 어긴다.
Atom과 7가지 관계
Synapsis Engine은 기억을 단일 타입 atom으로 다루고, atom 사이의 관계를 atom_relations 테이블에 7가지 타입으로 명시한다. Nexus는 이 구조를 저장하고 서빙하는 레퍼런스 백엔드에 가깝다.
| 관계 타입 | 의미 |
|---|---|
updates | 새 정보가 구 정보를 대체 |
contradicts | 두 정보가 충돌 (둘 다 보존) |
supports | 한 정보가 다른 정보를 뒷받침 |
belongs_to | 계층 관계 |
causes | 인과 관계 |
temporal_sequence | 시간 순서 |
same_entity | 동일 엔티티 지시 |
이 관계들은 검색 시점에 graph traversal로 활용된다. "Alice가 지난번에 뭐라고 했지?"라는 질문에 Alice 엔티티의 atoms를 temporal_sequence로 따라가며 contradict/updates 관계를 해결하는 식이다.
AMCP — 표준 레이어
이 구조에서 가장 덜 알려졌지만 가장 중요한 부분은 AMCP(Agent Memory Continuity Protocol)다. 이건 Synapsis Engine 내부 구조라기보다 에이전트 간 메모리 교환을 위한 오픈 스펙이다. Apache 2.0으로 공개됐고, MCP가 도구 계층의 표준이 된 것처럼 AMCP는 메모리 계층의 표준을 노린다.
이 선택은 단순한 기술 결정이 아니라 시장 포지션 결정이다. "우리가 카테고리를 정의한다"는 선언이다.
한 문장 요약
Synapsis Engine = "원자를 지키는 세 법칙 + 관계 그래프 + 오픈 프로토콜로 운영 규율을 코드화한 메모리 엔진"
Part 3. 차이의 뿌리: 두 개의 질문
기술 구조의 차이는 사실 처음 던진 질문의 차이에서 온다.
| Hindsight | Synapsis Engine | |
|---|---|---|
| 첫 질문 | 기억이란 무엇인가? | 기억을 어떻게 운영하는가? |
| 출발 비유 | 인간 인지 구조 (cognitive architecture) | 데이터베이스 운영 원칙 (operational discipline) |
| 핵심 추상 | 4개 네트워크 + 3개 연산 | 3대 법칙 + 7개 관계 + 프로토콜 |
| 갈등 해결 방식 | Opinion의 confidence 재계산 | Atom 관계로 명시적 링크 |
| 추론 위치 | Reflect가 first-class | 추론은 외부 계층 (엔진은 저장/검색만) |
| 표준화 관점 | 자체 아키텍처가 곧 표준 | 프로토콜이 표준, 구현은 교체 가능 |
Hindsight는 인간처럼 기억하는 에이전트를 목표로 삼았다. 그래서 인식론적 구분, 신념의 진화, 성격 변수, 반성(reflect) 같은 인지 구조의 용어로 세워졌다. 논문 곳곳에 "biomimetic", "human-like", "epistemic"이라는 단어가 등장한다.
Synapsis Engine은 프로덕션에서 망가지지 않는 메모리 엔진을 목표로 삼았다. 그래서 "삭제 금지", "재정렬 금지", "신호 주입 금지" 같은 운영 원칙의 용어로 세워졌다. 6번의 벤치마크 반복에서 얻은 경험적 법칙들이다.
어느 쪽이 옳은가? 둘 다 자기 질문에 정확히 답했다. 질문이 다를 뿐이다.
Part 4. 서로에게 배울 것
솔직하게 쓰자. 나란히 놓고 보면 각자의 공백이 드러난다.
Hindsight가 Synapsis Engine에게 주는 지적
① 단일 atom 타입은 부족하다. Synapsis Engine에서는 "사용자 주소는 서울"(world fact)와 "사용자는 Python 선호"(opinion)가 같은 신뢰도로 취급된다. 두 정보는 수명도, 검증 방식도, 모순 처리 방식도 달라야 한다. atom은 type 필드가 있지만, opinion/world/experience 구분은 하고 있지 않다. 인식론적 분화가 필요하다.
② Evidence chain이 약하다. Synapsis Engine의 confidence 필드는 있지만, 그 신뢰도가 어떤 raw atoms에서 도출됐는지 역추적하는 구조가 없다. "왜 이렇게 믿나?"에 답할 수 없다면 감사 가능한 메모리가 아니다.
③ Reflect 연산이 없다. Synapsis Engine은 retain + recall에 강하고, 의견이 시간에 따라 진화하는 메커니즘은 아직 약하다. 이건 "memory that learns"라는 약속을 절반밖에 못 지키는 것이다.
Synapsis Engine이 Hindsight에게 주는 지적
① 운영 원칙이 명문화되어 있지 않다. Hindsight 논문은 아키텍처 설계는 선명하지만 "무엇을 절대 하지 말라"는 법칙은 없다. 삭제/재정렬/점수 오염 같은 failure mode가 어떻게 다뤄지는지 모호하다. 구현자마다 다르게 해석할 여지가 크다.
② 시스템 간 호환 표준이 없다. Hindsight는 자체 아키텍처가 잘 작동하면 그걸로 끝이다. 하지만 에이전트 A의 기억이 에이전트 B에게 넘어가야 할 때는? 회사가 에이전트 공급자를 바꿀 때는? AMCP 같은 계층이 없으면 락인이 된다.
③ Self-host 단일 노드 전제가 프라이버시 보수 기업에게 부족하다. Hindsight는 Docker 한 방으로 돌아가는 대신, raw data와 vector index가 한 노드에 있다. 반면 Nunchi AI 쪽 스택은 raw 로컬과 vector 서버를 더 분리해 가져갈 수 있다. 한국/유럽처럼 데이터 주권이 중요한 시장에서는 이 차이가 더 크게 보인다.
교차점: 수렴 가능한가?
기술적으로는 가능하다. 두 접근은 보완적이다.
- Synapsis Engine에 인식론적 atom 분화(world/experience/opinion/observation) + evidence chain을 도입하면 Hindsight의 강점을 흡수할 수 있다.
- Hindsight에 3대 법칙 + AMCP 호환을 도입하면 Synapsis Engine의 운영 규율을 얻을 수 있다.
하지만 전략적으로는 수렴하지 않을 것이다. 두 팀이 서로 다른 시장, Hindsight는 영어권 Fortune 500, Nunchi AI 쪽은 비영어권 + 개발자 커뮤니티 + 표준을 향하고 있기 때문이다. 경쟁보다는 병행 진화가 자연스러운 결말이다.
Part 5. 우리의 선택
Synapsis Engine 개발자로서 Hindsight를 며칠간 정독한 뒤 내린 결론은 이렇다.
① 벤치마크 숫자 경쟁은 접는다. Hindsight의 91.4%는 큰 backbone을 쓴 결과이고, 우리가 Opus 4.7로 돌려도 넘을 수 있다. 하지만 Hindsight도 같은 조건에서 더 나올 것이다. 이 경쟁은 의미 없다. 같은 backbone에서의 아키텍처 기여로 숫자를 말해야 한다.
② Synapsis Engine의 공백을 메운다. 다음 분기 로드맵:
- Atom 타입 분화 (world/experience/opinion/observation)
- Evidence chain 도입 (atom derivation DAG)
synapsis.reflect()프리미티브 추가- Retrieval에 4-way fusion 확장 (현 anchoring을 5번째 전략으로 포함)
③ 3대 법칙은 더 세게 민다. Hindsight가 가진 것 중 우리가 흡수할 게 있듯, 우리가 가진 것 중 Hindsight가 흡수할 게 있다. 그중 가장 선명한 자산이 3대 법칙이다. 이건 계속 우리의 이론적 정체성으로 가져간다.
④ AMCP는 Synapsis Engine이나 Nexus보다 더 큰 포지션이다. Hindsight와 경쟁하는 게 아니라 Hindsight도 AMCP를 구현할 수 있는 구조로 가야 한다. MCP의 성공 공식, "Anthropic이 만들었지만 OpenAI도 쓴다"를 메모리 레이어에서 재현한다.
⑤ 오픈소스로 간다. AMCP는 이미 오픈이다. Synapsis 코어도 오픈한다 (MIT). 엔터프라이즈 기능, MaaS의 SSO/audit/SLA, Nexus Cloud의 관리형 운영은 상용으로 유지한다. 오픈 코어 전략이다. 닫혀 있을 이유가 없다. Hindsight가 이미 증명했듯 오픈이 구현 복제 리스크보다 신뢰 획득 이득이 크다.
결론: 두 길
Agent memory라는 카테고리가 분화하는 순간을 우리가 살고 있다.
Hindsight는 "기억이란 무엇인가"를 물었고, 인지 구조의 언어로 답했다. Synapsis Engine은 "기억을 어떻게 운영하는가"를 물었고, 운영 원칙의 언어로 답했다.
둘은 같은 산을 다른 면에서 오른다. 정상이 같을지 다를지는 아직 모른다. 하지만 확실한 건 한 쪽만의 답은 완전하지 않다는 것이다.
Nunchi AI는 이 두 갈래 길의 교차점에서 우리 몫을 찾는다. 운영 원칙을 유지하면서 인식론적 깊이를 더하고, 한국어와 비영어권에서 표준을 정의하고, 오픈 소스로 카테고리 리더십을 가져간다.
길게 보면, 우리 둘 다 지는 시나리오는 "closed RAG as-a-service"가 이 카테고리를 뒤덮는 경우다. 그래서 Hindsight 팀에게는 경쟁보다 건강한 경쟁의 감사가 앞선다. 같은 카테고리에서 서로 다른 답을 내는 팀이 있다는 건, 카테고리 자체가 살아있다는 증거다.
---
참고
- Hindsight 논문: arXiv 2512.12818
- Hindsight 코드: github.com/vectorize-io/hindsight (MIT)
- AMCP 스펙: github.com/goldberg-aria/amcp (Apache 2.0)
- Nexus: nunchiai.com
---
_이 글은 Nunchi AI의 관점에서 쓰여졌다. Hindsight 팀의 기여에 대한 존중을 담아, 두 아키텍처를 병치해 본다._