26개 AI 도구가 기억을 공유하는 메모리 층

같은 설명을 도구를 옮길 때마다 다시 하는 일. AI 도구를 두세 개 붙여 쓰는 사람의 하루에서 의외로 큰 비중을 차지하는 작업이다. 오픈소스 프로젝트 이츠키(Itsuki)는 이 반복을 없애겠다고 나섰다. 도구 26개 아래에 공용 기억 저장소를 하나 깔아, 어디서 말하든 나머지 전부가 그 사실을 되받게 하는 방식이다.

무슨 일인가

이츠키는 키 하나로 연결하는 메모리 계층을 표방한다. 연결 방식은 MCP 링크, 노드(Node), 파이썬(Python), 레스트 API(REST API) 네 갈래이고, 설치 경로는 38가지가 안내돼 있다. 얼리 액세스 기간에는 무료다.

연결 대상이 넓다. 대화형 도구로는 클로드(Claude)와 챗지피티(ChatGPT), 코딩 에이전트로는 클로드 코드(Claude Code), 코덱스(Codex), 커서(Cursor), 오픈코드(OpenCode), 안티그래비티(Antigravity)가 들어간다. 여기에 랭체인(LangChain), 크루에이아이(CrewAI), 오토젠(AutoGen), 라마인덱스(LlamaIndex), 마스트라(Mastra) 같은 에이전트 프레임워크와 워크플로 자동화 도구인 엔에이트엔(n8n), 디파이(Dify), 컨벡스(Convex)까지 같은 저장소를 바라본다. 코딩 도구와 업무 자동화 도구가 하나의 기억을 공유한다는 뜻이다.

핵심 짚어보기 — 전문을 다시 읽히지 않는다

기존 방식 상당수는 지난 대화를 통째로 다시 넣고 모델이 알아서 요점을 찾기를 기대한다. 이츠키는 대화에서 남길 것만 뽑아 구조로 바꾼다. 공개된 예시에서는 18턴짜리 대화가 지속 객체 4개로 정리되고, 14줄은 의도적으로 버려진다. 인사말이나 일정 잡담처럼 나중에 쓸모가 없는 부분이 폐기 대상이다.

남는 객체는 네 종류다. 사실, 사건, 개체, 그리고 개체 사이의 관계다. 각 객체는 그 말이 나온 원문 한 곳을 계속 가리키고 있어서, 여섯 달 뒤에 누가 언제 그렇게 정했느냐고 물으면 근거까지 함께 돌려준다. 수정은 리비전으로 쌓이고 이전 판으로 되돌릴 수 있다.

운영 규칙도 명시돼 있다. 삭제는 리콜과 내보내기, 그래프에서 한 번에 제거하고 벡터와 원본까지 정리한다. 모든 쓰기에는 무엇을 저장했고 어디서 왔는지 남는 감사 기록이 붙는다. 저장한 기억은 모델 학습에 쓰지 않으며, 메모리 공간 전체를 제이슨(JSON)으로 내보낼 수 있다.

1인기업 실전 적용 포인트

• 프로젝트 불변 규칙부터 넣는다. 데이터베이스는 무엇을 쓰는지, 배포는 어디로 하는지, 금지된 라이브러리는 무엇인지 같은 다섯 줄이 가장 자주 반복 설명되는 항목이다.
• 코딩 도구와 자동화 도구를 한 기억으로 묶는다. n8n 워크플로가 아는 고객 응대 규칙을 클로드 코드도 알게 되면, 같은 규칙을 두 곳에 따로 관리하던 작업이 사라진다.
• 버릴 것을 정하는 규칙을 먼저 손본다. 무엇이든 저장하면 나중에 검색 품질이 떨어진다. 결론과 결정만 남기고 진행 중 대화는 폐기하는 쪽이 안전하다.
• 내보내기부터 시험한다. JSON 내보내기가 실제로 쓸 만한 형태로 나오는지 초기에 확인해두면, 서비스를 바꿔야 할 때 기억을 통째로 잃지 않는다.

전망 / 주의점

기억을 한곳에 모으면 편의와 위험이 같이 커진다. 프로젝트 규칙과 고객 정보, 의사결정 이력이 한 저장소에 쌓이므로 그곳이 뚫리면 잃는 범위도 그만큼 넓다. 연결 키 하나로 26개 도구가 접근한다는 구조는 편의성의 근거인 동시에 사고 시 피해 범위의 근거이기도 하다. 가격도 변수다. 지금은 얼리 액세스라 무료지만 이후 정책은 정해지지 않았고, 유료 전환 시점에 이미 여러 도구가 이 저장소에 의존하고 있다면 협상력은 사용자 쪽에 없다. 도입한다면 민감도가 낮은 프로젝트 규칙부터 올려보고, 내보내기와 삭제가 설명대로 동작하는지 확인한 뒤 범위를 넓히는 순서가 현실적이다.

출처: Itsuki (https://itsuki.app/)