팀원이 퇴사할 때 팀의 AI 컨텍스트를 유지하는 방법 (2026)

계정이 삭제되는 순간 채팅은 접근 불가능해집니다

이것이 가장 명확한 경계선이며, Anthropic은 이를 명확히 문서화하고 있습니다: "사용자가 Team 또는 Enterprise 조직에서 제거되면, 남은 멤버는 더 이상 해당 사용자의 채팅에 접근할 수 없습니다."

이는 공유된 링크에도 적용됩니다. 헬프 센터에서는 사용자가 마주하게 될 메시지까지 안내하고 있습니다: "대화를 찾을 수 없습니다. 요청한 대화가 존재하지 않거나 접근 권한이 없습니다." 6개월 전에 누군가 티켓에 붙여넣은 링크가 작동을 멈추는 것입니다.

데이터가 완전히 사라진 것은 아닙니다. "제거된 사용자의 데이터는 조직의 Primary Owner가 실행하는 모든 데이터 내보내기(export)에 여전히 포함됩니다." 하지만 관리자 데이터 내보내기는 규정 준수(compliance)를 위한 도구일 뿐, 평범한 화요일에 질문 하나를 해결하기 위한 방법은 아닙니다.

개인 프로젝트는 사람이 떠난 후에도 비공개로 유지됩니다

프로젝트의 공개 여부는 프로젝트가 생성될 때 결정되며, 멤버가 삭제된다고 해서 이 제한이 완화되지 않습니다. "프로젝트의 공개 범위가 비공개(private)로 설정되어 있었다면, 해당 팀원이 계정에서 제거된 후에는 조직의 다른 멤버들이 해당 프로젝트에 접근할 수 없습니다."

문서에 제시된 해결책은 떠나는 사람에게 부담을 지웁니다: "팀원이 전달하고자 하는 비공개 프로젝트에서 작업 중임을 알고 있다면, 조직의 모든 사람이 편집할 수 있도록 프로젝트 권한을 조정하거나, 특정 사용자를 초대하여 '편집 가능' 권한을 부여해야 합니다."

설계상으로는 옳지만, 프로세스 측면에서는 매우 취약합니다. 퇴사 전 마지막 주에 있는 누군가가 다른 사람들에게 어떤 프로젝트가 필요할지 일일이 기억해 내는 것에 의존하기 때문입니다.

개인 메모리는 의도적으로 개인의 영역으로 남습니다

Claude의 메모리는 사용자별 저장소입니다. Team 및 Enterprise 플랜에서 소유자(owner)는 이 기능의 활성화 여부만 제어할 수 있으며, Anthropic의 표현을 빌리자면 "소유자는 사용자의 개별 메모리를 보거나 편집할 수 없습니다."

이는 개인정보 보호를 위한 조치이며 당연히 유지되어야 합니다. 하지만 이는 Claude가 그 사람의 업무가 어떻게 맞물려 돌아가는지 학습한 모든 것(어휘, 반복되는 제약 조건, 관련 인물 등)이 검색 가능한 형태의 조직 지식으로 남지 않음을 의미합니다. 이를 상속받을 수 있는 화면이나 기능은 존재하지 않습니다.

코딩 도구들도 동일하게 나뉘며, 그 구분은 파일 경로에 있습니다

이 패턴은 한 번 눈에 익으면 계속해서 반복되는 것을 볼 수 있으며, 대개 파일 경로에서 명확히 드러납니다.

Claude Code는 프로젝트 지침을 ./CLAUDE.md에서 로드하며, 자체 문서에서는 이를 "소스 제어를 통해 팀 멤버들과 공유"된다고 설명합니다. 개인 지침은 ~/.claude/CLAUDE.md에 위치하며 "나에게만 해당 (모든 프로젝트)"으로 범위가 제한됩니다. 그리고 Claude가 수정 사항과 결정 사항에 대해 스스로 작성하는 노트인 자동 메모리(auto memory)는 ~/.claude/projects/<project>/memory/에 위치하며, "로컬 머신 전용"이고 "파일은 머신 간 또는 클라우드 환경 간에 공유되지 않는다"는 명시적인 경고가 붙어 있습니다. 노트북이 초기화되면 그것으로 끝입니다.

Cursor는 프로젝트 규칙(Project Rules)을 .cursor/rules에 저장하며 "버전 관리 대상"이라고 명시합니다. 사용자 규칙(User Rules)은 개인용입니다. 팀 규칙(Team Rules)은 중앙에서 관리되며 "해당 팀의 모든 레포지토리 및 프로젝트에 걸쳐 Agent (Chat)의 모델 컨텍스트에 포함"됩니다. 그리고 Plan Mode에는 알아둘 만한 기본값이 있습니다: "계획(Plan)은 기본적으로 홈 디렉토리에 저장됩니다. 향후 참조, 팀 공유 및 문서화를 위해 워크스페이스로 이동하려면 'Save to workspace'를 클릭하세요." 아무도 그 버튼을 누르지 않은 모든 계획은 개인 파일로 남게 됩니다.

Cline은 그 의도를 이례적일 정도로 직접적으로 밝히고 있습니다. 가이드라인에 따르면 프로젝트 구성은 "레포지토리와 함께 이동해야 하는 팀 공유 동작을 위해" 사용하고, "팀과 공유하려는 .cline/ 파일을 커밋"하라고 권장합니다. 글로벌 규칙은 레포지토리 외부인 ~/.cline/ 및 ~/Documents/Cline/Rules에 위치합니다.

Kiro는 워크스페이스 스티어링(.kiro/steering/)과 글로벌 스티어링(~/.kiro/steering/)을 분리하며, Crew 메모리 레이어는 ~/.kiro/crew/workspace/memory/ 아래에 위치합니다. Kiro Web의 학습된 메모리는 범위가 더욱 좁습니다: "태스크를 생성한 사용자인 귀하의 피드백만이 에이전트가 학습하는 내용에 영향을 미칩니다."

이 네 가지 도구 모두를 관통하는 규칙은 다음과 같습니다: 레포지토리에 있으면 살아남고, 홈 디렉토리나 계정에 있으면 떠납니다.

더 긴 퇴사 인터뷰. 유용하며 퇴사자가 말하고자 하는 바를 포착할 수 있습니다. 하지만 그들이 수년 전부터 무의식적으로 받아들여 더 이상 인지하지 못하는 수십 개의 사소한 제약 조건들까지 포착하지는 못합니다.

마지막 날 전에 모든 것을 내보내기(Export). 이는 아카이브를 제공할 뿐, 활용 가능한 리소스가 되지 못합니다. Anthropic은 제거된 사용자의 데이터가 조직 내보내기에 유지된다고 명시하고 있으며, 대부분의 도구에는 내보내기 경로가 있습니다. 하지만 대화 내용이 담긴 zip 파일은 질문이 생겼을 때 아무도 검색해 보지 않는 무용지물이 되기 십상입니다.

프로젝트를 공유해 달라고 요청하기. 올바른 방법이며 문서화된 해결책입니다. 하지만 이는 퇴사자가 가장 바쁜 마지막 2주 동안, 다음 분기에 다른 사람에게 어떤 비공개 프로젝트가 필요할지 미리 예측해야 한다는 한계가 있습니다.

"혹시 모르니" 계정을 열어두기. 흔히 쓰이지만 비용이 많이 들며, 대개 오프보딩 체크리스트에서 누락되어 소유자 없는 로그인 계정으로 방치되곤 합니다.

일시적으로 다시 추가하기. Claude에서는 실제로 작동하는 방식입니다: "팀원이 제거된 후 나중에 동일한 이메일 주소를 사용하여 동일한 조직에 다시 추가되면 이전 채팅, 프로젝트 및 스킬이 복원됩니다." 이는 비상 상황을 위한 실제 복구 경로가 될 수 있습니다. 하지만 이는 지속 가능한 계획이 아니며, 이미 다른 곳에서 일을 시작한 사람에게 부탁하기에는 다소 어색한 일입니다.

더 많은 문서 작성하기. 직관은 맞았으나 대상이 잘못되었습니다. 문서는 페이지 단위로 답하지만, 질문에는 구체적인 답변이 필요합니다. 이 둘 사이의 간극은 how to turn project docs into AI memory에서 다루고 있습니다.

이 문제를 해결 가능한 수준으로 재정의하자면, 누군가 떠난 후에 그들의 컨텍스트를 복구하려고 애쓰는 것이 아닙니다. 애초에 조직의 자산이어야 했던 부분이 처음부터 조직의 공간에 보관되도록 보장하는 것입니다.

이러한 구분은 존중받아야 마땅한 경계선의 올바른 편에 서게 해줍니다. 퇴사하는 동료의 개인 메모리, 비공개 프로젝트, 공유되지 않은 스킬은 그들의 소유입니다. Anthropic은 공유되지 않은 스킬이 "그들의 계정에 유지되며 복구 가능한 상태로 남는다"고 명시하고 있으며, 소유자는 개별 메모리를 읽을 수 없습니다. 이러한 것들을 강제로 가져오려 해서는 안 됩니다. 여러분이 원하는 것은 팀의 지식, 즉 결정 사항, 제약 조건, 이유, 그리고 개인이 아닌 프로젝트 자체에 유효했던 사실들입니다.

이것이 바로 MemoryLake가 제공하는 역할입니다. 개별 계정이 아닌 워크스페이스가 소유하며, 여러분의 도구들이 쿼리할 수 있는 공유 메모리 레이어입니다. 설정은 다음 세 단계로 진행됩니다.

1단계: API 키 생성

로그인 후 워크스페이스용 API 키를 생성합니다. 이 인증 자격 증명은 팀에 귀속되므로 사람이 떠나도 함께 사라지지 않습니다.

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

각각 하나의 사실만을 담은 짧은 항목들로 구성합니다. 가장 가치 있는 방법은 한 사람과 마주 앉아 오직 그 사람만 알고 있는 내용을 적어 내려가는 것입니다. 기록해야 할 내용은 다음과 같습니다:

이유가 첨부된 결정 사항. "우리는 리전이 아닌 테넌트별로 샤딩합니다. 1분기 규정 준수 검토에서 리전 간 복제가 제외되었기 때문입니다." 결정은 코드에 있지만, 그 이유는 한 사람의 머릿속에만 있습니다.

이미 기각된 접근 방식. 가장 자주 다시 논쟁의 대상이 되지만, 어떤 문서나 커밋 메시지에도 나타나지 않는 영역입니다.

아무도 알려주지 않는 환경적 사실. 다른 작업보다 먼저 실행되어야 하는 작업, 아무도 문서화하지 않은 벤더 제한 사항, CI에서만 실패하는 테스트 등입니다.

명확한 용어로 정리된 주체와 대상. 고장 난 부분을 담당하는 팀, 특이한 임시 방편이 존재하는 대상 고객, 내부 서비스 이름이 실제로 가리키는 대상 등입니다.

시스템을 지탱하고 있는 임시 방편(Workaround)들. 모든 팀에는 두세 개씩 존재합니다. 이를 유지 관리하던 사람이 떠나기 전까지는 눈에 보이지 않습니다.

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

팀이 사용하는 도구들을 연결합니다. MemoryLake는 MCP 및 API를 통해 접근할 수 있으므로, Claude Code, Cursor, Cline, Codex, OpenClaw 등 MCP 네이티브 에이전트들은 MCP 서버를 가리키도록 설정하여 연결하고, 다른 어시스턴트들은 API를 통해 동일한 메모리를 읽을 수 있습니다. 즉, 신규 입사자의 첫 주가 퇴사자의 계정에 접근할 필요 없이 퇴사자가 가지고 있던 것과 동일한 답변으로 시작될 수 있음을 의미합니다. 이러한 도구 간 연동 형태는 cross-tool memory for knowledge workers에서 다루고 있습니다.

세 가지 명확한 한계가 있습니다. MemoryLake는 벤더 측에 저장된 개인의 메모리, 채팅 또는 비공개 프로젝트를 읽거나 복구하거나 가져올 수 없습니다. 이러한 데이터는 각 벤더의 제품 내에서 자체 액세스 제어 하에 보관되며, 그것이 맞습니다. MemoryLake는 사용자나 에이전트가 직접 입력한 내용만 보관하므로, 2단계는 사람이 직접 수행해야 하는 의도적인 작업입니다. 또한 오프보딩 규정 준수 도구가 아닙니다. 퇴사하는 직원의 활동에 대한 공식 기록이 필요한 경우, 이는 메모리 레이어가 아니라 데이터 보존 정책에 따른 관리자 데이터 내보내기를 통해 해결해야 합니다.

오프보딩이 지식을 쥐어짜내는 과정이 되지 않습니다. 지식은 이미 팀이 소유한 공간에 기록되어 있습니다.

노트북 초기화가 더 이상 문제가 되지 않습니다. 로컬 머신 전용 자동 메모리가 유일한 사본이 아니었기 때문입니다.

"왜 이런 방식으로 처리했지?"에 대한 답을 얻을 수 있습니다. 누구에게 물어봐야 할지 아는 사람뿐만 아니라, 질문하는 모든 사람이 답을 얻을 수 있습니다.

온보딩 기간이 실질적으로 단축됩니다. 신규 입사자가 네 명의 팀원을 방해하는 대신 동일한 메모리 레이어에 질문할 수 있습니다.

'기본 비공개' 설정이 더 이상 지뢰밭이 되지 않습니다. 퇴사자가 마지막 주에 권한 변경을 기억해 내는 것에 의존하지 않기 때문입니다.

벤더 메모리는 개인용으로 유지되며, 그래도 괜찮습니다. 더 이상 이를 조직의 자산으로 만들 필요가 없어졌기 때문입니다. 이에 대한 일반적인 구분은 what persistent memory actually means에서 다루고 있습니다.

사용 중인 기술 스택에서 경계선이 어디인지 한 번만 점검해 보세요. 각 도구별로 무엇이 레포지토리에 있고 무엇이 홈 디렉토리나 계정에 있는지 명시합니다. 한 시간이면 충분하며, 이것이 진단의 전부입니다.

프로젝트 공개 범위의 기본값을 조직(organization)으로 설정하세요. 비공개는 합당한 이유가 있어 내린 결정이어야지, 아무도 선택하지 않아서 발생하는 결과여서는 안 됩니다.

"Save to workspace"를 구제 수단이 아닌 습관으로 만드세요. Cursor 계획은 기본적으로 홈 디렉토리에 저장됩니다. 다른 많은 도구들도 마찬가지입니다.

공유 레이어를 커밋하세요. .cursor/rules, .cline/, .kiro/steering/, ./CLAUDE.md — 이들은 모두 설계상 레포지토리 내에 존재하도록 되어 있습니다. 설계된 대로 활용하세요.

규칙뿐만 아니라 이유도 함께 기록하세요. 규칙은 버전 관리를 통해 살아남습니다. 하지만 규칙이 존재하는 이유는 대개 사라지며, 그 이유야말로 내년에 해당 규칙이 다시 되돌려지는 것을 막아주는 핵심 요소입니다.

지식 전달은 퇴사 통보 기간의 시작 시점에 진행하세요. 마지막 주가 아닙니다. 마지막 주는 행정적인 처리를 위한 시간입니다.

그들이 더 이상 인지하지 못하는 부분에 대해 질문하세요. "어디에도 적혀 있지 않은데 알고 있는 지식이 무엇인가요?"라고 물으면 어깨를 으쓱할 뿐입니다. 하지만 "가장 최근에 들어온 신입 사원에게 무엇을 설명해 주어야 했나요?"라고 물으면 목록이 쏟아져 나옵니다.

그들의 소유권을 존중하세요. 개인 메모리, 공유되지 않은 스킬, 비공개 프로젝트는 개인의 자산입니다. 팀에 필요한 것을 공유해 달라고 정중히 요청하되, 그들의 계정을 조직의 자산처럼 취급하지 마세요.

퇴사로 인해 막대한 컨텍스트 손실이 발생하는 이유는 삭제 때문이 아닙니다. 바로 접근 권한 때문입니다. 계정이 삭제되는 순간 채팅은 접근 불가능해집니다. Anthropic은 이를 직접적으로 명시하고 있으며 사용자가 보게 될 에러 메시지까지 문서화해 두었습니다. 개인 프로젝트는 비공개로 유지되며, 문서화된 해결책은 퇴사자가 직접 권한을 변경하도록 요구합니다. 개인 메모리는 개인의 영역으로 남으며, 소유자는 명시적으로 이를 읽을 수 없습니다. Claude Code의 자동 메모리는 로컬 머신 전용이므로 노트북과 함께 사라집니다. Cursor 계획은 기본적으로 홈 디렉토리에 저장됩니다. Kiro의 Crew 메모리는 사용자의 홈 경로 아래에 위치합니다. Kiro Web은 태스크 생성자의 피드백을 통해서만 학습합니다.

이 모든 것은 타당한 설계이며, 그중 일부는 제거되어서는 안 될 개인정보 보호 조치입니다. 이 모든 사실이 가리키는 결론은 하나입니다. 레포지토리에 보관된 팀의 컨텍스트는 퇴사 후에도 살아남지만, 계정이나 노트북에 보관된 컨텍스트는 살아남지 못한다는 것입니다.

그러므로 이 구분을 의도적으로 명확히 하십시오. 사용하는 각 도구에서 경계선이 어디에 있는지 점검하고, 프로젝트 공개 범위의 기본값을 조직으로 설정하고, 공유 레이어를 커밋하고, 결정 사항, 이유, 기각된 접근 방식을 워크스페이스가 소유한 메모리 레이어에 저장하십시오. 사람이 아직 그곳에 있을 때 실행하십시오. 누군가 떠나기 때문이 아니라, 그때가 유일하게 쉬운 시기이기 때문입니다.