10분 만에 팀을 위한 공유 AI 메모리 구축하는 방법 (노코드)

개인 메모리는 설계상 개인의 영역입니다

그렇지 않을 경우 어떤 일이 일어날지 생각해 보세요. 만약 어시스턴트의 메모리가 동료들과 공유된다면, 초안, 정립되지 않은 의견, 개인의 업무 습관 등 여러분이 어시스턴트에게 말했던 모든 내용이 동료들의 답변에 노출될 것입니다. 모든 벤더가 동일한 결론을 내렸습니다. 메모리는 그것을 생성한 계정의 소유라는 것입니다.

OpenAI는 한 걸음 더 나아가 워크스페이스에 미치는 영향에 대해 다음과 같이 명시하고 있습니다. 워크스페이스 소유자가 워크스페이스의 메모리 기능을 끄면 "해당 워크스페이스 멤버의 기존 저장된 메모리가 삭제됩니다." 메모리는 조직 수준에서 제어되는 멤버별 기능이지, 공유 자산이 아닙니다.

벤더가 팀에 제공하는 레이어는 메모리가 아니라 지침(Instructions)입니다

팀 범위의 메커니즘이 실제로 존재하며, 사용할 가치가 있습니다. 다만 그것은 메모리와는 다른 것입니다. Cursor는 Team 및 Enterprise 플랜의 대시보드에서 관리되는 팀 규칙(team rules)을 지원합니다. GitHub Copilot에는 조직 지침(organization instructions) 레이어가 있으며, 우선순위는 가장 낮지만("개인 지침이 가장 높은 우선순위를 가집니다. 그 다음은 리포지토리 지침이며, 조직 지침이 마지막으로 우선순위를 가집니다") 여전히 모델에 제공됩니다. AGENTS.md와 같은 리포지토리 파일은 버전 관리 시스템에 포함되어 있으므로 정의상 공유됩니다.

이러한 방식은 모두 선언적이고 정적입니다. 누군가 규칙을 작성하면 모두가 그것을 적용받습니다. 이는 컨벤션을 정의하는 데는 이상적이지만, 팀이 실제로 잃어버리는 것, 즉 '축적된 지식'에는 무용지물입니다. 3주 전 회의에서 내린 결정, 임시 방편이 존재하는 이유, 현재 접근 방식을 취하기 전에 시도했던 것들 말이죠. 벤더의 API 속도 제한(rate-limit)이 문서와 다르게 작동한다는 사실을 기록하기 위해 조직 지침 대시보드를 열 사람은 아무도 없습니다.

공유 프로젝트 공간은 양방향으로 벽이 쳐져 있습니다

그 다음으로 생각해 볼 수 있는 것은 공유 워크스페이스 기능입니다. 이 기능은 도움이 되며, 명확한 경계가 문서화되어 있습니다. OpenAI의 Projects 문서에 따르면 "공유 프로젝트는 프로젝트 외부의 개별 멤버의 컨텍스트, 맞춤 지침(custom instructions) 또는 메모리에 액세스할 수 없습니다." 즉, 프로젝트를 공유하면 의도적으로 개인 컨텍스트와 단절됩니다. 또한 프로젝트가 공유되면 메모리 모드가 전환되어 "기본 메모리로 되돌릴 수 없습니다." 이러한 장벽은 클라이언트 작업이나 민감한 프로젝트에는 적절한 조치이지만, 공유 프로젝트가 팀의 두뇌가 아닌 하나의 고립된 섬이 된다는 것을 의미하기도 합니다. 자세한 내용은 왜 ChatGPT Projects가 메모리를 공유하지 않는가에서 확인할 수 있습니다.

그리고 팀이 주로 사용하는 플랜에서는 내보내기 경로가 차단되어 있습니다

최소한 모든 사람의 데이터를 수집하여 수동으로 병합할 수 있을 것이라 생각했다면, 먼저 제공 여부 규칙을 확인해 보세요. OpenAI의 내보내기 문서에 따르면 ChatGPT 설정에서 요청하는 내보내기는 "Free, Plus, Pro 및 대상 ChatGPT Edu 워크스페이스에서 사용 가능"하며, "ChatGPT Business 또는 Enterprise 워크스페이스에서는 사용할 수 없음"이 명시되어 있습니다.

따라서 대부분의 팀이 사용하는 플랜에서는 병합할 수 있는 셀프 서비스 대량 내보내기 기능이 제공되지 않습니다. 팀이 공동으로 알고 있는 지식은 공유된 어딘가에 기록되거나, 아니면 영원히 만날 일 없는 6개의 개인 메모리에 분산된 채로 남게 됩니다.

위키(Wiki). 사람에게는 정직한 해결책이지만, 에이전트에게는 특정 방식으로 실패합니다. 위키는 서술형 문서로 작성되기 때문에 에이전트는 전체 페이지를 가져오거나 검색된 일부 조각만 받게 되며, 어떤 내용이 최신인지 알 수 없습니다. 또한 위키는 소리 없이 노후화되며, 어시스턴트가 위키를 읽을 때 그 페이지가 지난 3월에 작성된 것인지 알려주지 않습니다.

리포지토리의 긴 `AGENTS.md` 파일. 버전 관리 시스템으로 관리되고 모든 도구가 읽을 수 있으므로 더 나은 방법입니다. 하지만 빠르게 한계에 부딪힙니다. Cursor는 규칙을 500행 미만으로 유지할 것을 권장하고, Claude Code는 파일당 200행 미만을 목표로 삼을 것을 권장하며, 파일이 길어질수록 "더 많은 컨텍스트를 소비하고 준수율을 떨어뜨린다"고 지적합니다. 모든 요청마다 로드되는 파일 하나에 팀의 지식 베이스를 모두 담을 수는 없습니다.

슬랙(Slack) 고정 스레드. 사람은 찾을 수 있지만 어시스턴트에게는 보이지 않으며, 일주일만 지나면 모두의 관심에서 사라집니다.

각자의 맞춤 지침(Custom Instructions). 6개의 복사본이 존재하며 크기도 작습니다. OpenAI는 Free 및 Go 사용자의 경우 1,500자, Plus, Pro, Enterprise, Business, Education 사용자의 경우 5,000자의 제한을 두고 있습니다. 이는 한두 단락의 선호 사항일 뿐, 공유된 지식 체계가 아닙니다. 또한 이를 업데이트하려면 6명에게 동일한 텍스트를 붙여넣으라고 요청해야 합니다.

온보딩 문서. 신규 입사자에게 실제로 무엇이 필요한지 팀이 가장 모르는 시점에 한 번 작성된 후, 이를 업데이트할 수 있는 사람들이 더 이상 자신들이 무엇 때문에 헷갈렸는지 기억하지 못해 절대 업데이트되지 않습니다.

구조적인 해결책은 개인 메모리를 공유하려고 애쓰는 대신, 모든 어시스턴트가 읽을 수 있는 하나의 팀 소유 메모리 레이어를 만드는 것입니다. 개인 메모리는 각 개인이 어떻게 일하기를 선호하는지 파악하는 본연의 역할을 계속 수행합니다. 공유 레이어는 업무 자체에 대한 사실을 보관합니다.

이것이 바로 MemoryLake가 하는 일이며, 코딩 없이 세 단계만으로 설정할 수 있습니다.

1단계: API 키 생성

MemoryLake에 로그인하고 API 키를 생성합니다. 이 키는 팀의 도구들이 공유 메모리를 읽고 쓰는 데 사용하는 인증 정보입니다. 어시스턴트와 독립된 단 하나의 인증 정보이므로, 나중에 도구를 추가하더라도 설정을 처음부터 다시 할 필요가 없습니다.

2단계: 첫 번째 메모리 업로드

문서부터 시작하지 마세요. 팀원들이 평소에 자주 말하는 20개의 문장부터 시작하세요. 실제로 이러한 문장들은 다음 네 가지 영역에서 나옵니다.

결정 사항과 그 이유. "감사인이 상태를 재현해야 하므로 원장에는 이벤트 소싱을 사용합니다." 이유를 설명하는 부분이 핵심입니다. 이유가 없으면 결정이 임의적인 것처럼 보이고 다시 논쟁의 대상이 됩니다.

기각된 사항. "지난 3월에 큐 기반 설계를 검토했으나 보류했습니다. 재시도 시 순서 보장이 유지되지 않았기 때문입니다." 이는 팀 메모리에서 가장 가치 있는 카테고리입니다. 그렇지 않으면 새로운 어시스턴트나 신규 입사자가 이를 다시 제안할 것이기 때문입니다.

외부에서는 잘못되어 보이는 제약 조건. 업무 시간 중에는 재시작할 수 없는 서비스, 아무도 열을 추가할 수 없는 테이블, 보존 기간을 규정하는 고객 계약 등이 이에 해당합니다.

반복되는 수정 사항. 이번 달에 두 사람이 어시스턴트에게 동일한 수정을 지시했다면 여기에 해당합니다. 이는 가장 명확한 신호입니다.

각 항목은 새로운 팀원이 추가 질문 없이 바로 실행할 수 있을 정도로 명확하게 하나의 주장만 담아야 합니다. 10분 동안 타이핑하는 것만으로도 대부분의 가치를 얻을 수 있으며, 나머지는 업무를 진행하면서 자연스럽게 축적됩니다.

3단계: AI 및 에이전트 연결

팀이 이미 사용하고 있는 도구들을 연결하세요. MemoryLake는 MCP 및 API를 통해 액세스할 수 있으므로, Claude Code, Codex, OpenClaw를 포함한 MCP 네이티브 에이전트는 MCP 서버를 가리켜 연결하고, 다른 어시스턴트는 API를 통해 동일한 메모리를 읽습니다. 각 개인은 자신만의 개인 메모리와 선호 설정을 그대로 유지합니다. 달라지는 점은 이제 6개의 어시스턴트 모두가 동일한 소스를 바탕으로 여러분의 프로젝트에 대한 질문에 답변한다는 것입니다.

공유 레이어가 마법의 조직도는 아니므로, 세 가지 솔직한 한계가 존재합니다. 첫째, 누군가의 기존 개인 메모리를 가져오지 않습니다. 이를 내보낼 방법이 없으므로 첫 번째 항목들은 직접 입력해야 합니다. 둘째, 문서 저장소를 위한 권한 관리 시스템이 아닙니다. 말뭉치(corpus)에 대해 파일별 액세스 제어가 필요하다면 엔터프라이즈 커넥터를 사용해야 하며, 이를 유지해야 합니다. 셋째, 강제 수단이 아닙니다. 이는 어시스턴트가 알고 있는 지식일 뿐, 어시스턴트가 절대 어길 수 없는 규칙은 아닙니다.

온보딩이 구전 동화처럼 구두로 전해지지 않습니다. 신규 입사자의 어시스턴트는 첫날부터 코드베이스가 왜 그렇게 구성되어 있는지 알고 있습니다. 이는 보통 대신 작성했을 문서보다 더 가치 있습니다. 아무도 문서로 남기지 않는 부분이기 때문입니다.

수정 사항이 개인의 영역에 머물지 않습니다. 현재는 한 사람이 문제점을 발견하면 하나의 어시스턴트만 학습시킵니다. 공유 레이어에서는 발견된 사실이 다음 질문을 하는 즉시 모든 사람에게 제공됩니다.

사람마다 답변이 달라지지 않습니다. 계정별 메모리를 사용하면 두 동료가 동일한 질문을 하더라도 각자의 이력에 따라 서로 다른 답변을 받게 됩니다. 공유 레이어는 프로젝트에 대해 최소한 동일한 사실을 제공하므로, 누구의 어시스턴트가 무엇을 알고 있었는지가 아니라 본질적인 내용을 두고 의견을 나눌 수 있습니다.

도구의 확산이 지식 파편화 문제로 이어지지 않습니다. 사람들이 서로 다른 어시스턴트를 사용하는 것은 막을 필요가 없습니다. 해결해야 할 문제는 지식이 각 어시스턴트에 갇히는 현상입니다. 이는 지식 근로자를 위한 교차 도구 메모리 및 여러 도구 간 AI 메모리 동기화에서 설명한 형태입니다.

에이전트의 작업이 덜 반복적입니다. 여러 에이전트가 동일한 코드베이스에서 작업할 때, 각 에이전트가 아무것도 없는 상태에서 시작하면 동일한 오해가 배가됩니다. 이는 멀티 에이전트 메모리에서 나타나는 실패 패턴이며, 규모만 다를 뿐 동일한 방식으로 해결할 수 있습니다.

항목당 하나의 주장만 담으세요. 항목이 길어지면 검색 효율이 떨어지고 쉽게 노후화됩니다. 하나의 항목에 두 가지 아이디어가 들어가면, 그중 하나가 먼저 잘못되더라도 알아차리기 어렵습니다.

항목에 항상 이유를 기록하세요. "X 라이브러리를 사용하지 마세요"라는 규칙은 누군가 사용 사례를 찾는 순간 무시됩니다. 반면 "X 라이브러리를 사용하지 마세요. 메인테이너가 2025년에 아카이브했으며 우리가 의존하는 포크 버전도 관리되지 않고 있습니다"라는 규칙은 살아남습니다.

컨벤션은 리포지토리에, 지식은 레이어에 두세요. 버전 관리되는 파일은 매번 컨텍스트에 포함되어야 하는 규칙을 두기에 적합한 곳입니다. 공유 레이어는 계속 늘어나는 사실들을 위한 곳입니다. 이 둘을 섞으면 둘 다 비효율적이 됩니다.

위원회가 아닌 담당자 한 명을 지정하세요. 매달 오래된 항목을 정리할 사람 한 명이면 충분합니다. 한 달에 10분만 투자하면 지식 베이스가 단순한 아카이브로 전락하는 것을 막을 수 있습니다.

과감하게 삭제하세요. 오래된 항목은 누락된 항목보다 나쁩니다. 누락된 항목은 질문을 유도하지만, 오래된 항목은 잘못된 작업을 확신을 가지고 수행하게 만들기 때문입니다.

비밀 정보를 넣지 마세요. 인증 정보는 비밀 관리자(secret manager)에 보관해야 합니다. 메모리 레이어는 지식을 보관하는 곳입니다.

개인적인 선호도는 개인의 영역으로 남겨두세요. 코드가 어떻게 설명되기를 원하는지는 팀의 지식이 아닙니다. 이는 개인 메모리와 맞춤 지침이 처리하도록 하세요. 그것이 원래 목적이며, 공유 레이어를 깔끔하게 유지하는 방법입니다.

팀에 공유 AI 메모리가 없는 이유는 도구가 미성숙해서가 아닙니다. 모든 벤더가 메모리를 개별 계정에 종속시키기로 올바른 결정을 내렸기 때문입니다. 즉, 어떤 설정을 하더라도 6개의 개인 메모리를 하나의 팀 두뇌로 병합할 수는 없습니다. 현재 존재하는 팀 범위의 기능들(Cursor의 팀 규칙, Copilot의 조직 지침, 리포지토리 파일)은 규칙을 위한 선언적 레이어일 뿐, 지식이 축적되는 공간이 아닙니다.

따라서 공유 레이어는 여러분이 직접 만들기로 결정해야 하는 영역입니다. 20개의 문장, 하나의 API 키, 그리고 팀이 이미 사용하고 있는 도구들만 있으면 됩니다. 지금 10분을 투자하면 사람들이 원래 기대했던 수준의 AI 어시스턴트를 얻을 수 있습니다. 한 번에 한 사람이 아니라 모두를 위해 실제 업무가 어떻게 돌아가는지 알고 있는 어시스턴트 말이죠. 만약 조직 내에서 나타나는 증상이 단일 팀보다 더 광범위하다면, 엔터프라이즈 AI 망각에서 동일한 문제를 더 큰 규모에서 다루고 있습니다.