Hindsight: 에이전트 기억을 저장하고 찾고 활용하기

Hindsight는 에이전트가 세션을 넘어 기억을 활용하도록 정보를 구조화하는 오픈소스 기억 시스템이다. 네 가지 기억 종류와 저장·검색·추론, RAG와의 역할 분담을 살펴보고, 실행하지 않은 세 가지 사용 예시와 다른 기억 기술과의 비교를 개념도·논문 그림과 함께 설명한다.

고친 내용: 본문과 사용 예시, 기술 비교표, 도식·삽화 설명의 번역투와 어색한 용어를 다듬었다. literalism의 의미와 Graphiti의 유효 기간 설명을 바로잡고, 출처·코드·실행하지 않은 예시라는 전제는 유지했다.

Hindsight란 무엇인가

Hindsight는 AI 에이전트가 대화가 끝난 뒤에도 기억을 이어가도록 만든 오픈소스 장기 기억 시스템이다. Vectorize가 MIT 라이선스로 공개했다. 대표 논문은 2026년 7월 전산언어학회(ACL) 시스템 데모 부문에 실렸다. 그보다 앞선 2025년 12월 14일 arXiv 사전 공개판이 나왔다. 문서는 그 뒤로 바뀌었을 수 있으니, 실행 전에는 반드시 최신 공식 문서를 다시 확인한다.

Hindsight는 기억을 추론의 핵심 요소로 취급한다. 기억을 처음부터 구조화된 형태로 쌓고, 객관적 사실과 주관적 믿음을 나눠 둔다. 그래서 개발자는 에이전트가 무엇을 아는지와 무엇을 믿는지를 따로 들여다볼 수 있다. 이를 근거와 추론의 경계가 드러나는 기억을 만들려는 시도로 해석할 수 있다.

문서 0.10의 개요에서는 기억을 네 종류로 나눈다. 세계 사실(World Fact)은 세상에 대한 객관적 사실이고, 경험 사실(Experience Fact)은 에이전트가 겪은 일이다. 관찰(Observation)은 개체별로 사실을 종합한 요약이며, 멘탈 모델(Mental Model)은 자주 쓰는 지식을 다듬어 둔 것이다. 관찰과 멘탈 모델도 이 네 가지 기억 종류에 포함된다. 논문에서 사용한 opinion(변하는 믿음)은 이전 용어이므로 현재 문서의 네 종류와 같은 분류로 취급하지 않는다. 기억을 용도별로 나누면 답의 근거를 확인할 때 출처를 추적할 수 있다.

언제 Hindsight를 쓰는가

Hindsight는 기억을 축적하고 갱신해야 하는 일에 적합하다. 대화를 넘어 상대를 기억해야 하는 비서, 누가 무엇을 맡았는지 따라가야 하는 협업 도우미, 지난 분기나 작년 같은 시간 질의가 잦은 기록 도우미, 일관된 태도로 답해야 하는 고객 응대 시스템이 그 예다. 이 용도 구분은 공식 비교 페이지의 권장 사항을 따른다.

반대로 자료가 고정되고 시간 조건이 없으면 검색 증강 생성 쪽이 간결할 수 있다. 정적 말뭉치에 대한 문서 질의응답이 예다. Hindsight를 도입하면 서버와 데이터베이스, 대규모 언어 모델 API를 운영하는 비용이 들므로 기억이 필요 없는 질의까지 기억 시스템으로 풀 필요는 없다. 무엇을 쓸지는 자료가 정적인지, 시간이 중요한지, 상대에 대한 이해가 쌓여야 하는지에 따라 판단할 수 있다는 것이 이 글의 해석이다.

RAG와의 관계: 대체가 아니라 분업

공식 비교 페이지는 Hindsight를 단순화된 의미 유사도 검색 중심의 RAG 기준선과 견준다. 이 대조는 모든 RAG가 그렇다는 뜻이 아니다. 실제 RAG 시스템도 혼합 검색, 그래프, 시간 필터링, 여러 단계 추론을 갖출 수 있다. 비교표는 특정 기준선에 대한 제작사의 설명으로만 읽는다.

공식 페이지는 용도를 다음과 같이 구분한다. 변하지 않는 말뭉치에 대한 문서 질의응답이나 시간 조건이 없는 검색에는 RAG 쪽을, 여러 세션에 걸친 비서의 지속 기억과 개체 추적, 일관된 성향, 시간 질의에는 Hindsight 쪽을 권한다. 검색 전략·여러 단계 추론·시간 질의·개체 이해·지식 종합·성향의 여섯 갈래에서 차이를 설명한다.

이 글에서는 두 기술을 역할에 따라 함께 사용할 수 있다고 해석한다. 근거 문서를 읽고 답하는 일은 RAG의 강점이고, 시간을 넘나들며 상대를 알아가고 믿음을 다듬는 일은 기억 시스템의 강점이다. Hindsight가 RAG를 보완할 수는 있지만 모든 검색을 대체하는 기술은 아니다.

핵심 동작: 저장·검색·추론

기억을 다루는 세 연산은 각각 별도의 API로 호출한다. 저장(retain)은 정보를 저장하고, 검색(recall)은 필요한 기억을 찾고, 추론(reflect)은 기억을 활용해 답을 생성한다. 대화에서 얻은 정보는 시간을 인식하는 기억 계층을 거쳐 메모리 뱅크에 구조화된 형태로 쌓이므로 질의로 찾아볼 수 있다. 추론은 이 뱅크에서 검색한 기억을 바탕으로 답을 생성한다. 이 설명이 추론할 때마다 결과를 뱅크에 자동으로 다시 저장한다는 뜻은 아니다.

검색은 벡터 검색, 키워드 매칭, 그래프 탐색, 시간 필터링을 함께 사용하며 PostgreSQL과 pgvector를 기반으로 동작한다. 질의에서 시간 표현과 개체를 추출한 다음 여러 검색 결과를 통합하고 관련성에 따라 재정렬한다. 그 결과에서 요청한 토큰 예산에 맞는 구조화된 사실을 골라 돌려준다. 검색은 답을 생성하지 않으며, 답을 생성하는 일은 추론의 몫이다. 질의 사이에도 상태가 남아 다음에 이어진다는 점이 한 번의 검색으로 끝내는 흐름과의 차이다.

메모리 뱅크는 기억의 네임스페이스다. 공식 문서는 사용자, 에이전트, 프로젝트마다 각자의 뱅크를 두는 방식으로 설명한다. 뱅크에는 배경 맥락과 세 성향에 관한 설명이 있어 추론이 답을 생성할 때 이를 참고한다. 세 성향은 회의적인 태도(skepticism), 문자 그대로 해석하는 성향(literalism), 공감(empathy)이다. 네임스페이스 분리와 접근 통제는 별개이므로, 격리가 필요하다면 인증·인가 설정을 따로 갖추고 검증해야 한다. 뱅크를 나누는 것만으로 정보 유출을 막는다는 설명은 아니다.

뱅크 안의 네 가지 기억은 계층을 이룬다. 하위 계층에는 저장한 세계 사실과 경험 사실이 있다. 관찰은 이 사실들을 종합하고, 상위 계층의 멘탈 모델은 자주 쓰는 지식을 정리해 둔다. 관찰과 멘탈 모델은 네 가지 기억 종류에 포함된다. 추론은 멘탈 모델, 관찰, 원시 사실 순으로 상위 계층부터 살핀다. 자주 묻는 질문에는 정리된 지식부터 확인하고, 낯선 질문에는 그 근거가 되는 사실까지 살피는 방식이다.

설치와 서버 실행

아래 절차와 예시는 공식 Quick Start의 흐름을 따랐으며 마탑 환경에서 직접 실행하지 않았다. 문서 버전 0.10을 2026년 9월 28일에 확인했으며, 버전이 오르면 절차가 바뀔 수 있다. 예시 코드는 공식 저장소의 MIT 라이선스로 공개된 패턴을 각색한 것으로, 식별자와 문장은 이 글용으로 바꿨다.

파이썬으로 서버를 직접 실행하려면 세 단계를 거친다. hindsight-api 패키지와 hindsight-client 패키지를 설치하고 대규모 언어 모델 키를 환경 변수(HINDSIGHT_API_LLM_API_KEY)에 비공개로 설정한 뒤 hindsight-api 명령으로 서버를 실행한다. 서버를 실행하면 API는 로컬 8888번 포트에서 응답한다. Docker로 같은 환경 변수를 주고 공식 이미지를 실행하는 방법과 서버를 직접 운영하지 않는 관리형 서비스도 문서에 있다. 공통 전제는 구조화 출력을 지원하는 대규모 언어 모델이 필요하다는 점이다.

pip install hindsight-api hindsight-client
export HINDSIGHT_API_LLM_API_KEY="..."  # 실제 키는 비공개로 설정
hindsight-api
# API: http://localhost:8888

최소 사용 예시

서버를 실행한 뒤에는 클라이언트에서 같은 뱅크 이름으로 세 연산을 각각 호출한다. 아래 예시는 탑 읽기 모임이라는 가상의 네임스페이스에 모임 장소를 저장했다가 찾는 흐름이다. 실행하지 않은 예시이므로 정확한 반환값은 제시하지 않는다. 저장 단계는 저장한 기록의 확인 정보를, 검색 단계는 질의에 맞춰 순위를 매긴 기억 후보를, 추론 단계는 내부에서 검색한 기억을 바탕으로 생성한 답을 돌려준다. 검색만 따로 사용할 수도 있고, reflect에 질의를 보내 기억 검색과 답변 생성을 함께 처리할 수도 있다.

Node.js·Go·명령줄 클라이언트도 같은 세 연산을 제공한다. 운영 환경에서는 워커 식별자를 고정해 재시작 후에도 같은 워커로 인식되게 하고, 데이터를 저장할 볼륨을 구성한다. 외부 PostgreSQL 같은 선택지는 공식 문서를 따른다.

from hindsight_client import Hindsight

client = Hindsight(base_url="http://localhost:8888")
bank = "tower-reading-group"

client.retain(bank_id=bank, content="탑 읽기 모임은 6층 서가에서 열린다.")
found = client.recall(bank_id=bank, query="읽기 모임은 어디에서 열리나?")
answer = client.reflect(bank_id=bank, query="이번 주 모임 장소를 알려줘.")

사용 예시: 선호하는 연락 방법이 바뀔 때

이 절부터 소개할 세 가지 사용 예시는 모두 가상의 이름과 시간을 사용했으며 실행하지 않았다. 실제 서버에 보내지 않았으며, 정확한 반환값은 제시하지 않는다. 입력과 질의, 기대하는 결과의 종류만 제시한다. 식별자와 문장은 이 글용으로 지었으며, 공식 블로그의 이름·시각 표기와 문서 ID·기준 시각·대화 맥락 사용법을 각색했다.

첫 예시는 단골 고객이 선호하는 연락 방법을 바꾸는 상황이다. 2026년 3월 2일 오전 9시(UTC) 상담에서 고객 서아가 앞으로는 문자보다 이메일로 연락해 달라고 했다고 하자. 상담 기록을 한 문서로 묶어 저장한다. 문서 ID는 contact-2026-03-02-seoa-01처럼 대화마다 따로 부여하고 기준 시각에는 상담 시작 시각 2026-03-02T09:00:00Z를, 대화 맥락에는 고객 서아가 상담원과 이야기 중이라는 취지를 적는다. 2026년 4월 15일 오후 2시 30분(UTC) 상담에서 서아가 다시 전화로 연락해 달라고 했다고 하자. 이 대화는 다른 독립 문서 ID contact-2026-04-15-seoa-02로 묶고, 기준 시각 2026-04-15T14:30:00Z와 같은 대화 맥락을 함께 준다. 각기 다른 시각에 이루어진 두 대화를 별도 문서로 저장한다. 같은 문서 ID의 내용을 교체하는 흐름과 구분해야 한다. 이렇게 하면 서아의 1인칭 말이 상담원 자신의 경험이 아니라 서아에 대한 세계 사실로 저장되도록 유도할 수 있다는 것이 공식 블로그의 설명이다.

서아의 연락 방법을 물을 때는 시점을 분명히 한다. recall에 “서아가 3월에 말한 연락 방법은?”이라고 물으면, 3월을 기준으로 순위를 매긴 구조화된 사실 후보를 기대할 수 있다. 답 문장을 생성하는 일은 추론의 몫이다. 서아의 현재 연락 방법을 물을 때 기대하는 결과는 최신 시각을 기준으로 순위를 매긴 구조화된 사실 후보들이다. 같은 주제의 질문을 reflect에 보내면 내부에서 검색한 기억을 바탕으로 최신 정보를 우선 반영한 답을 생성하는 흐름을 기대한다. 어느 단계에서도 실제 반환값을 단정하지 않는다. 시간에 따라 질의해야 한다면 기준 시각을 빠뜨리지 않아야 한다.

# 실행하지 않은 가상 예시. 실제 서버에 보내지 않았으며 반환값은 제시하지 않음.
client.retain(
    bank_id="support-seoa",
    content=(
        "Seoa (2026-03-02T09:00:00Z): 앞으로는 문자보다 이메일로 연락해 주세요.\n"
        "Agent (2026-03-02T09:01:00Z): 네, 이메일로 연락드리겠습니다."
    ),
    context="Customer Seoa is speaking with the support agent",
    timestamp="2026-03-02T09:00:00Z",
    document_id="contact-2026-03-02-seoa-01",
)
client.retain(
    bank_id="support-seoa",
    content=(
        "Seoa (2026-04-15T14:30:00Z): 앞으로는 전화로 연락해 주세요.\n"
        "Agent (2026-04-15T14:31:00Z): 네, 전화로 연락드리겠습니다."
    ),
    context="Customer Seoa is speaking with the support agent",
    timestamp="2026-04-15T14:30:00Z",
    document_id="contact-2026-04-15-seoa-02",
)
found_march = client.recall(bank_id="support-seoa", query="서아가 3월에 말한 연락 방법은?")
# 기대하는 결과: 3월을 기준으로 순위가 매겨진 구조화된 사실 후보 (답 문장 아님)
found_now = client.recall(bank_id="support-seoa", query="서아의 현재 연락 방법은?")
# 기대하는 결과: 최신 시각을 기준으로 순위가 매겨진 구조화된 사실 후보 (답 문장 아님)
answer = client.reflect(bank_id="support-seoa", query="서아에게 어떤 방법으로 연락해야 하나?")
# 기대하는 결과: 내부 검색 결과를 종합해 최신 연락 방법을 반영한 답

사용 예시: 프로젝트에서 기억 공유하기

두 번째 예시는 기획자·조사자·작성자가 한 보고서를 함께 만드는 흐름이다. 세 역할이 같은 프로젝트 뱅크 project-atlas를 사용한다고 하자. 기획자가 마감이 4월 15일이라는 사실을 저장하면 조사자와 작성자도 같은 뱅크에서 그 사실을 찾을 수 있다. 공식 Strands 가이드는 이를 팀이 축적한 조직 기억이라고 부르며, 뱅크 ID를 같이 쓰면 기억을 나누고 다르게 쓰면 서로 보이지 않는다고 설명한다. 이 글의 예시는 뱅크를 나누는 개념을 설명하며 실제 Strands SDK 호출을 제시하지는 않는다.

다른 의뢰인의 일은 다른 뱅크에 둔다. 예를 들어 project-atlas와 client-baker-01은 서로 다른 네임스페이스이므로 한쪽에 쌓은 사실이 다른 쪽 검색에 섞이지 않도록 나눈 구성이다. 다만 네임스페이스 분리와 접근 통제는 별개다. 뱅크 ID를 나누는 것만으로 접근 권한이 제한되지는 않으며, 격리가 필요하면 인증·인가·네트워크·키 관리를 따로 갖추고 검증해야 한다. 뱅크 분리만으로 정보 유출이 방지된다고 해석해서는 안 된다.

공유 기억과 개인 기억을 함께 사용하는 방식도 있다. 공유 뱅크는 읽기로만 참고하고, 각자 메모는 자기 뱅크에 쓰는 방식이다. 공식 가이드는 공유 쪽을 읽기 경로로, 쓰기 쪽을 자기 뱅크 ID의 저장 도구로 나누는 구성을 소개한다. 어느 구성이든 저장한 기억을 다른 역할이 검색할 수 있는지 직접 검증해야 한다.

# 실행하지 않은 개념 예시: 별도 뱅크 사용. 실제 SDK 호출이 아님.
SHARED = "project-atlas"      # 기획자·조사자·작성자가 함께 읽고 쓰는 프로젝트 기억
PLANNER_ONLY = "planner-memo" # 기획자만 쓰는 메모 (다른 역할과 분리)
CLIENT_OTHER = "client-baker-01"  # 다른 의뢰인. project-atlas와 분리

# 기대하는 결과: 같은 bank_id를 쓰는 역할끼리는 서로 저장한 사실을 찾을 수 있음.
# 기대하는 결과: 다른 bank_id에 저장한 사실은 검색 결과에 섞이지 않음.
# 주의: bank_id는 네임스페이스를 구분함. 접근 통제를 위한 인증·인가는 따로 설계.

사용 예시: 수정한 문서 다시 저장하기

세 번째 예시는 문서가 바뀌었을 때다. 공식 Documents API는 같은 문서 ID로 다시 저장하면 옛 내용을 교체한다고 설명한다. 예를 들어 문서 ID tower-report-plan에 보고서 마감 2027년 3월 31일을 저장한 뒤 같은 ID로 보고서 마감 2027년 4월 15일(연장)을 다시 저장한다. 그러면 기존 사실을 지우고 새 내용에서 다시 추출하는 방식이다. 공식 블로그는 문서 ID를 일정하게 유지하면 다시 저장하는 작업에 멱등성이 생긴다고 설명한다.

대화가 계속 이어질 때는 덧붙이기 방식이 있다. 전체를 다시 보내지 않고 새로 추가된 몇 턴만 덧붙이면 서버가 기존 문서에 이어 붙이고 바뀌지 않은 부분에서는 사실을 다시 추출하지 않는다는 설명이다. 어느 방식을 쓰든 관리 API로 문서별 원문·기억 수·생성 시각을 조회하거나 문서와 연결된 기억을 함께 삭제할 수 있다. 삭제는 되돌릴 수 없으니 운영에서는 보관 기간과 함께 설계한다.

이 예시는 처리 순서를 개념적으로 설명한다. 저장할 내용과 문서 ID를 입력하고, 현재 계획의 마감이 언제인지 질의한다. 기대하는 결과는 최신 문서에서 추출한 사실 후보와 이를 종합해 생성한 답이다. 정확한 반환 필드나 개수는 적지 않으며, 실행 전에는 반드시 최신 공식 문서를 다시 확인한다.

# 실행하지 않은 가상 예시: 같은 문서 ID로 다시 저장.
client.retain(bank_id="tower-atlas", content="보고서 마감: 2027년 3월 31일", document_id="tower-report-plan")
client.retain(bank_id="tower-atlas", content="보고서 마감: 2027년 4월 15일(연장)", document_id="tower-report-plan")
# 기대하는 결과: 기존 사실을 지우고 새 내용에서 추출한 사실로 교체 (실제 반환값은 제시하지 않음)

다른 기억 기술과 비교하기

아래 비교는 각 공식 문서에서 소개하는 주요 기능을 옮긴 것으로, 우열을 매기지 않는다. 어떤 기술이 부족하다는 식의 단정도 하지 않는다. 비교할 항목은 기억을 소유 주체에 따라 나누는 방식, 시간 처리, 답변 생성, 연동과 운영 방식이다. 확인일은 2026-09-28이며, 최신 정보임을 보증하지 않는다.

Hindsight(문서 0.10 기준)는 뱅크마다 네 기억 종류(세계 사실·경험 사실·관찰·멘탈 모델)를 둔다. 기준 시각, 날짜 해석, 범위 필터링으로 시간을 다룬다. 검색은 순위를 매긴 구조화된 사실을 반환하고 추론은 기억을 종합해 답을 생성한다. 서버·PostgreSQL·대규모 언어 모델 키를 함께 운영하는 구성이며, 뱅크는 네임스페이스다.

Mem0(공식 저장소 문서 기준)는 앱과 모델 사이에서 add로 사실을 저장하고 search로 검색하는 흐름을 설명한다. 추출·중복 제거·임베딩·개체 연결을 거쳐 SQL·벡터·개체 저장소에 나누어 둔다. 네 신호(의미·키워드·개체·시간)를 함께 보는 융합 검색은 Platform 관리 서비스의 설명이며, 개체 신호는 내장 Graph Memory로 동작한다. OSS 쪽은 구성한 벡터 저장소와 선택적 재정렬에 따르며 개체가 겹치는 정도에 따라 가중치를 적용한다고 설명한다. 범위 지정으로 섞임을 막고, 돌려받은 기억 중 무엇을 프롬프트에 넣을지는 앱이 고른다고 설명한다.

Graphiti(Zep 공식 문서 기준)는 시간 지식 그래프를 사용한다고 설명한다. 두 개체와 그 사이의 관계를 삼중항으로 표현하며, 정보는 에피소드 단위로 입력받는다. valid_at/invalid_at으로 사실이 유효한 기간을 기록해 관계의 변화를 추적한다. 공식 Quick Start의 graphiti.search() 예시에서는 의미 유사도와 BM25를 결합해 순위를 매긴 사실·관계와 유효 시각을 검색 결과로 돌려준다. 의미 검색과 전문 검색의 결합, 그래프 거리 기반 재정렬·노드 검색 레시피를 둔다고 하며, 여러 그래프 백엔드와 대규모 언어 모델·임베딩 제공자를 연결할 수 있다고 한다.

Letta(공식 문서 기준)는 상태를 유지하는 에이전트를 제공한다고 설명한다. 기억 블록·메시지·도구가 함께 저장되며, 연결한 기억 블록은 시스템 프롬프트에 들어가고 에이전트가 도구로 기억을 고칠 수 있다고 설명한다. 여러 에이전트가 한 블록을 공유할 수도 있으며 오래된 메시지도 API·검색 도구로 찾을 수 있다고 한다.

LangGraph(공식 문서 기준)는 단기와 장기를 나눈다. 단기는 스레드별 체크포인터로 여러 턴 대화를 잇고, 장기는 네임스페이스별 저장소에 사용자·앱 단위 자료를 여러 대화에 걸쳐 보존한다고 설명한다. 노드에서 저장소를 읽고 쓰는 흐름이며, 운영 환경에서는 데이터베이스 백엔드의 체크포인터·저장소를 쓴다고 한다.

각 기술이 설명하는 기능을 자신의 용도와 대조해 볼 수 있다. 팀이 축적한 조직 기억과 시간 질의가 중요하다면 Hindsight를, 앱에서 검색한 기억을 골라 활용하려면 Mem0를 살펴볼 만하다. 관계가 시점에 따라 어떻게 달라졌는지 추적하려면 Graphiti가, 에이전트가 블록과 도구로 자신의 기억을 수정하는 구성이 필요하면 Letta가 관련 기능을 설명한다. 그래프 실행 중 스레드별 상태와 여러 대화에 걸친 저장소를 구분하려면 LangGraph의 설명을 살펴볼 수 있다. 이 비교는 우열을 매기지 않으며, 도입 전에는 각 원문을 직접 대조한다.

한계와 다음 읽기

기억의 품질은 저장한 사실과 이를 종합하는 과정에 달려 있다. 엉뚱한 사실을 저장하면 그럴듯한 오답의 재료가 늘어날 뿐이다. 사실과 믿음을 나눈다고 해서 믿음이 저절로 옳아지지 않는다. 믿음을 수정하는 과정을 관찰할 수 있다는 사실이 정답을 보장하지는 않는다. 문서 버전 0.10 기준으로 아직 초기 단계의 프로젝트라 인터페이스와 동작이 바뀔 수 있다. 기억의 충돌 해소·삭제·보존 기간·개인정보 취급은 도입자가 운영 정책으로 설계해야 한다.

이 글은 벤치마크 수치를 인용하지 않는다. 수치는 모델과 설정에 묶인 스냅샷이며, 이 글에서 검토한 범위를 벗어나기 때문이다. 다음으로는 AI의 기억과 컨텍스트, 검색 증강 생성, 에이전트와 도구 사용을 다룬 주제 글을 권한다. AI 기억의 발전 과정을 다룬 글도 함께 읽으면 기술이 어떻게 달라졌는지 이해하는 데 도움이 된다.