AI 도구에 빠진 층위: 어시스턴트가 이미 아는 내용을 공유하기

AI 요약

AI가 한 개발자의 코딩 방식과 프로젝트 관례를 익혀도, 같은 저장소를 쓰는 동료의 AI나 다른 AI 도구에는 그 맥락이 전달되지 않습니다. 글쓴이는 계정과 제품 안에 갇힌 AI 기억을 사용자가 소유하고 직접 공유할 수 있도록 memshare를 만들었습니다. 기억은 서비스 전용 기능이 아니라 사용자가 관리하는 데이터로 취급합니다.

기억을 파일로 저장하고 공유합니다

memshare를 설치한 뒤 AI 도구에 MCP(Model Context Protocol) 서버로 연결하면 대화 중 기억을 저장하고 불러옵니다. 예를 들어 “JSONB 지원 때문에 Postgres를 선택했다”고 말하면 AI가 memory_set을 호출해 내용을 저장합니다. 사용자가 프로젝트에 관한 기억을 물으면 memory_get을 호출합니다. 별도 명령이나 복사·붙여넣기 없이 대화 흐름에서 기록하는 방식입니다.

기억 저장소는 ~/.memshare/ 아래의 평문 JSON 파일로 구성합니다. 기억 하나마다 파일 하나를 만들고, 공유 번들은 별도 파일로 둡니다. 데이터베이스나 서버에 의존하지 않아 grep, diff, Git으로 내용을 확인하고 관리합니다. MCP 서버와 CLI는 이 저장소를 다루는 어댑터입니다. MCP가 사라져도 기억 파일은 그대로 남습니다.

팀원에게 맥락을 전달할 때는 태그와 수신자를 지정해 내보낼 항목을 고릅니다. --preview로 실제 공유 번들을 먼저 확인하고, 문제가 없으면 만료 기간을 지정해 파일을 만듭니다. 수신자는 파일을 미리 보고 항목마다 가져올지 선택합니다. 가져온 기억은 기본적으로 비공개로 저장합니다. 다른 사람에게서 맥락을 받았다는 사실만으로 재공유에 동의한 것은 아니기 때문입니다.

공유 전후에 동의를 확인합니다

글쓴이는 공유 통제 절차를 네 가지로 설명합니다. 기억을 만들 때 비공개 또는 공유 가능으로 표시하며, 비공개 기억은 태그가 내보내기 조건에 맞아도 공유하지 않습니다. 내보내기 시에는 이메일, 전화번호, 자격 증명, 정부 발급 신분증 번호 등을 검사하고, 민감 정보가 감지된 항목은 보류합니다. 사용자는 내보내기 전에 정확한 번들을 확인합니다. 수신자도 항목별로 수락하거나 거부하며, 번들의 해시로 전송 중 파일 변경 여부를 검사합니다.

미리 보기와 실제 내보내기는 같은 코드 경로를 사용합니다. 라이브러리의 selectForExport와 planImport가 예상 작업을 계산하고, CLI가 그 결과를 보여준 뒤 실행합니다. 미리 보기와 실제 동작이 서로 다른 코드로 구현되면 사용자가 확인한 내용과 실제 공유 내용이 어긋날 수 있기 때문입니다.

지원 범위와 한계

memshare는 Cursor, Windsurf, GitHub Copilot, Claude Code 등 MCP 클라이언트에 연결할 수 있습니다. 다른 편집기에서 만든 기억도 같은 번들 형식으로 주고받습니다. 오픈소스이며 MIT 라이선스를 따르고, 서버나 가입 절차 없이 사용할 수 있습니다.

글쓴이는 MCP가 모델의 도구 호출을 강제하지 못하므로 기억 저장이 조용히 실패할 수 있다고 밝힙니다. memshare stats는 전체 기억 수, 최근 14일간 저장량, AI가 저장한 기억과 직접 추가한 기억의 수, 공개 범위를 보여줍니다. 기록이 늘지 않는 상태를 사용자가 알아차리도록 돕습니다.

dev.to 반응

• @compoundlabs — 기억을 쓸 때는 공유해도 안전했지만 계약이나 사고 뒤에는 민감해질 수 있습니다. memshare는 내보내기 전에 이전에 공유 가능하다고 표시한 항목도 현재 정책에 맞는지 다시 검사하나요?
  • @uri_shmueli_a403e7acc04a8 — 짧게 답하면 PII는 다시 검사하지만, 임의의 정책은 아직 지원하지 않습니다. 내보낼 때마다 후보 항목 전체에 PII 검사를 실행합니다. 새 자격 증명 형식이나 건강 관련 키워드를 탐지 패턴에 추가하면 몇 달 전에 작성해 공유 가능으로 표시한 항목도 미리 보기에서 걸러집니다. 사용자는 항목마다 정보를 가리고 포함하거나 아예 제외할 수 있습니다. 오탐은 클릭 한 번으로 끝나지만 미탐은 실제 정보 유출로 이어질 수 있어 탐지기는 일부러 넓게 잡습니다. 계약 체결 뒤 특정 프로젝트 언급을 민감 정보로 처리하는 식의 플러그인형 정책 엔진은 아직 없습니다. 현재는 사용자가 정한 공개 범위를 신뢰하고, 그 위에 내보내기 시점의 PII 검사를 추가합니다. 공개 범위 자체를 바뀐 규칙에 맞춰 재평가하는 기능은 만들지 않았지만, 미리 보기와 실제 내보내기가 모두 통과하는 단일 관문인 selectForExport에 정책 검사를 추가하는 구조는 가능합니다.
• @mihai_leanzero — 비슷한 형태로 에이전트의 결정을 시간순으로 기록하는 장부를 만들고 있습니다. 기억에 “Postgres를 선택했다”고 적혀 있어도 팀이 6개월 뒤 다른 데이터베이스로 옮기면, 현재 상태와 대조하지 않는 한 다음 독자는 결정이 낡았다는 사실을 모릅니다. memshare는 기억마다 버전을 관리하나요, 아니면 UUID마다 파일 하나를 두고 마지막 쓰기만 남기나요? 오래된 번들이 이미 폐기된 결정을 동료에게 전달할 수도 있습니다. 내보내기 전 PII 검사는 좋은 선택입니다. 대부분의 기억 도구는 이 단계를 건너뛰고 버퍼에 있는 내용을 그대로 보냅니다.
  • @uri_shmueli_a403e7acc04a8 — 결정이 시간이 지나며 낡는 문제는 실제로 있으며 지적이 맞습니다. 지금은 UUID마다 파일 하나를 두고 마지막 쓰기가 이전 내용을 대체합니다. 각 기억에 createdAt과 updatedAt을 기록하고, 예를 들어 다시 검토할 시기를 아는 아키텍처 결정에는 --expires 90d처럼 선택적으로 expiresAt을 설정할 수 있습니다. 하지만 “8개월 된 기억이니 다시 확인하세요” 같은 적극적인 오래된 기억 경고는 없습니다. 번들에도 같은 시각 정보와 변조 탐지용 콘텐츠 해시를 넣어 수신자가 결정이 언제 기록되고 수정됐는지 확인할 수는 있습니다. 그래도 오래된 번들이 이미 효력을 잃은 결정을 전달할 수 있다는 점은 실제 빈틈입니다. 읽기만 해도 갱신되는 시각과 구별되도록, 기억을 다시 확인했을 때 갱신하는 “확인 시각”을 생각하고 있습니다. 내보내기 미리 보기에 “6개월 넘은 항목 3개, 아직 유효한가요?” 같은 경고를 붙이면 버전 관리 부담 없이 가장 큰 문제를 줄일 수 있습니다. 아직 구현하지 않았지만 목록에 있습니다. PII 검사는 처음부터 양보할 수 없는 조건이었습니다. 비슷한 도구를 만든다면 어떤 탐지 패턴이 효과적이었고 오탐은 어디서 생겼는지 기꺼이 공유하겠습니다.
  • @mihai_leanzero — “확인 시각”이 맞는 방향입니다. 단순히 읽었을 때가 아니라 명시적으로 다시 검증했을 때 시간을 갱신하면 두 사실을 구별할 수 있습니다. “마지막으로 건드린 때”와 “마지막으로 정확성을 확인한 때”는 다릅니다. 둘을 한 값으로 섞으면 아무도 다시 확인하지 않은 결정을 계속 신뢰하게 됩니다. 그 위에 오래된 항목을 내보내기 전에 경고하는 방식은, 도구가 안다고 가장하지 않고 수신자에게 의심할 지점을 알려주는 간단하고 솔직한 버전 관리로 보입니다. PII 패턴 비교 제안은 받아들이겠습니다. 미리 밝히자면 저도 Sentinel Vault라는 비밀 정보·PII 스캐너를 만들었습니다. 맥락 없이 식별자처럼 보이는 내부 티켓 번호나 짧은 영숫자 코드가 실제 비밀 정보가 아닌데 오탐으로 잡히는 경우가 가장 까다롭습니다. memshare도 비슷한 오탐을 내는지, 아니면 다른 유형이 문제인지 궁금합니다.
• @izgorodin — 동의 절차에서 빠진 부분은 보내는 쪽이 아니라 받는 쪽에 있습니다. 가져온 항목은 원본과 연결되지 않은 복사본입니다. 발신자가 나중에 기억을 수정해도 수신자에게는 이전 버전이 남고 바뀐 사실을 알릴 방법이 없습니다. 앞서 나온 오래된 항목 경고는 나이를 기준으로 문제를 찾지만, 최근 작성됐어도 원본에서 이미 대체된 항목은 잡지 못합니다. 번들 형식은 이 문제를 다루기에 가까워 보입니다. 가져온 항목마다 발신자 저장소의 ID를 유지하면 같은 발신자가 다음 번들을 보낼 때 항목 X가 Y를 대체한다고 표시할 수 있습니다. 수신자 미리 보기에서 기존 가져오기 항목에 새 버전이 생겼음을 보여주고, 똑같이 항목별 수락·거부를 받으면 됩니다. 동의가 최초 공유뿐 아니라 수정 내용에도 적용됩니다. 수신자는 수정본을 가장 필요로 하면서도 먼저 요청할 가능성은 가장 낮기 때문입니다.

원문: dev.to / 번역·요약: Trawling