Claude Code 세션 간에 컨텍스트를 공유하는 방법 (2026)

세션 간 메시징을 사용하려면 Claude Code v2.1.224 이상이 필요하며, WSL 2 내부의 Linux를 포함한 macOS 및 Linux에서 실행됩니다. 네이티브 Windows에서는 제공되지 않습니다. 문서에 따르면 세션이 요구 사항을 충족하면 "별도로 활성화할 필요 없이 메시징 기능이 켜집니다."

이 기능은 두 가지 도구로 작동합니다. Claude가 도달할 수 있는 에이전트를 찾는 ListAgents와, 이름으로 에이전트 중 하나에 메시지를 전달하는 SendMessage입니다. 사용자가 직접 호출할 필요는 없습니다. "Claude가 ListAgents로 대상을 찾고 SendMessage로 전송하므로, 사용자가 직접 도구를 호출할 일은 없습니다." 예를 들어 "다른 터미널에서 실행 중인 세션에 마이그레이션이 끝났는지 물어봐 줘"라고 프롬프트를 입력하면, Claude가 실제 메시지를 작성합니다.

도착한 메시지는 다음과 같은 형태이며, 이는 공식 문서의 예시입니다:

`` Schema migration finished: the new column is tenant_id, and rebasing on main is safe now. ``

이것이 이 기능의 전체적인 모습이며, 실제로 매우 유용합니다. 한 세션이 다른 세션이 빌드 중인 내용을 깨뜨리는 변경을 수행하면, 사용자가 알아차리기 전에 Claude가 해당 세션에 경고할 수 있습니다. 한 세션이 다른 세션의 진행을 막고 있던 문제를 해결하면 그 답변이 전달됩니다. 문서에 기록된 사용 사례로는 발견한 사실 전달하기, 병렬 worktree 조율하기, 장시간 실행되는 작업의 상태 가져오기, 다른 기기 간에 회신하기 등이 있습니다.

한계를 정확히 아는 것이 중요합니다. 왜냐하면 그 한계가 사용자가 직접 해결해야 할 영역을 정의하기 때문입니다:

• 텍스트 전용. 한계 사항 섹션에는 "일반 텍스트만 가능"이라고 명시되어 있습니다. 그리고 핵심 문장은 다음과 같습니다. "메시지는 한 Claude가 다른 Claude에게 작성하는 텍스트 조각일 뿐이며, 대화 기록이나 파일이 아닙니다. 전체 대화나 컨텍스트를 이동하려면 대신 세션을 재개(resume)하십시오." 수신 세션은 "해당 텍스트만 받으며, 송신자의 대화 기록이나 파일은 절대 받지 못합니다."
• 기기 간 메시징은 회신만 가능. 동일한 기기 내의 메시지는 세션별 소켓을 통해 전송되며 Anthropic 서버를 거치지 않습니다. 다른 기기나 웹에 있는 세션으로 보내는 메시지는 Remote Control을 통해 Anthropic 서버를 거쳐 전송되며, 이 경우 Claude는 "회신만 할 수 있으며, 대화를 먼저 시작할 수는 없습니다."
• 에이전트 검색은 파일 시스템 기반. 각 세션은 디스크의 파일에 자신을 등록하고 그곳에 인박스 소켓을 바인딩하므로, 두 세션은 동일한 파일을 볼 수 있을 때만 서로에게 도달할 수 있습니다. 컨테이너 내부의 세션과 호스트의 세션은 서로 도달할 수 없지만, 동일한 컨테이너 내부의 두 세션은 도달할 수 있습니다.
• 전송이 보장되지 않음. 각 메시지는 수신 세션의 수신 제어 규칙에 따라 확인되며, crossSessionInbound (accept / hold / refuse) 설정에 따라 Delivered(전송됨), Held(보류됨) 또는 Refused(거부됨) 상태가 됩니다. 보류된 메시지는 만료 시간이 있는 승인 대화 상자를 띄우며(dialogExpiry 기본값은 5분), Claude Code는 최대 100개의 메시지만 보류하고 이를 초과하면 가장 오래된 메시지부터 삭제합니다. 세션당 읽기를 대기하는 수락된 메시지는 최대 50개로 제한됩니다.
• 메시지에는 권한이 없음. 메시지는 "아무것도 승인할 수 없으며" 구성을 변경할 수 없습니다. Claude는 다른 세션의 요청으로 인해 권한 설정, CLAUDE.md 또는 기타 구성을 변경하지 않도록 지시받았습니다. 텍스트에 포함된 /compact는 "일반 텍스트로 도착"할 뿐 결코 실행되지 않으며, 수신 측에서는 여전히 권한 승인 프롬프트가 실행됩니다.
• 전송 완료 시 비용 발생. 전송된 메시지는 "사용자가 입력하는 프롬프트와 마찬가지로 사용량에 반영됩니다."

이 중 어느 것도 불평할 만한 점이 아닙니다. 이는 경계가 잘 정의된 조율 채널이며, 이러한 경계는 의도된 것입니다. 권한을 승인하거나 CLAUDE.md를 다시 작성할 수 있는 메시지는 기능이 아니라 보안 문제가 될 것이기 때문입니다.

메시지 전달은 메모리 공유가 아닙니다

이 차이가 핵심입니다. 메시지는 한 Claude가 특정 시점에 요약한 내용을 다른 하나의 세션으로 일회성 전송하는 것입니다. 공유 메모리(Shared memory)는 여러 세션이 동일한 지속성 있는 기록을 읽는 것을 의미합니다. 즉, 한 번 기록하면 아직 존재하지 않는 세션을 포함하여 모든 세션이 이를 사용할 수 있게 됩니다.

메시징은 전자만을 제공합니다. 이는 사무실 건너편에서 소리를 지르는 것과 공유 문서에 기록하는 것의 차이와 같습니다. 둘 다 유용하지만, 내일까지 남아 있는 것은 하나뿐입니다.

메시지는 요약본이며, 요약은 의도적으로 정보 손실을 동반합니다

Claude는 메시지를 직접 작성합니다. 문서에 따르면 동일한 프롬프트에 대해서도 "Claude가 보내는 내용은 달라질 수 있습니다." 이는 조율을 위한 핑(ping)으로는 올바른 설계이지만, 지식 전달에는 적합하지 않습니다. 사용자가 원했던 주의 사항이 압축 과정에서 누락될 수 있으며, 이후에 무엇이 누락되었는지 확인할 방법이 없습니다.

동일한 패턴이 한 단계 아래인 서브에이전트(subagents)에서도 나타납니다. 각 서브에이전트는 "자체 컨텍스트 창에서 실행"되며 "요약만 반환"합니다. 요약은 Claude Code가 컨텍스트 예산을 보존하는 방식입니다. 또한 지식이 누적되지 않는 이유이기도 합니다.

세션이 종료되면 아무것도 남지 않습니다

터미널 세 개를 모두 닫으면, 지난 목요일에 세션들이 아무리 대화를 잘 나누었더라도 그 대화와 함께 주고받은 모든 메시지가 사라집니다. 다음 주의 세션은 이전과 똑같이 파일에서 다시 시작됩니다. 이것이 바로 Claude Code가 여전히 프로젝트 컨텍스트 없이 각 세션을 시작하는 이유입니다.

세 가지 기능이 하나로 혼동됩니다

문서에서는 이 기능들을 신중하게 구분하고 있으며, 잘못된 기능을 사용하는 것이 사람들이 실망하게 되는 가장 흔한 원인입니다:

• 세션 재개(Resume a session) — 다른 곳에서 하나의 대화를 이어가거나, 새 세션과 해당 컨텍스트를 공유합니다. 이는 컨텍스트를 이동하는 문서화된 방법이며, 단일 대화의 컨텍스트를 이동합니다.
• 세션 간 메시징(Cross-session messaging) — 사용자가 시작하고 제어하는 독립적인 세션들이 텍스트를 주고받습니다.
• 에이전트 팀(Agent teams) — Claude가 생성하고 감독하는 조율된 세션 팀으로, 팀 내에서만 유지되는 구조화된 프로토콜 메시지를 사용합니다.

여기에 여러 세션을 관찰하기 위한 에이전트 뷰(agent view), 다른 기기에서 제어하기 위한 Remote Control, CI 결과와 같은 외부 이벤트를 세션에 밀어 넣기 위한 채널(channels)이 추가됩니다. 총 6가지 메커니즘이 있지만, 그 중 어느 것도 프로젝트가 알고 있는 지식을 보관할 수 있는 장소는 아닙니다.

메시징 대신 세션 재개하기. 실제로 컨텍스트를 원할 때 올바른 선택이며, 문서에서도 권장하는 방법입니다. 이는 세 개의 세션이 기반을 공유하는 것이 아니라, 하나의 대화를 이어가게 해줍니다.

모든 것을 `CLAUDE.md`에 넣기. 표준적인 답변이자 고정된 규칙을 두기에 가장 적합한 곳입니다. 모든 세션이 이를 로드하기 때문입니다. 하지만 요청당 비용이 발생하므로 짧게 유지해야 하며, 어제 배운 내용이 아니라 명시적으로 기록하기로 결정한 내용만 담게 됩니다.

터미널 간 복사 및 붙여넣기. 메시징 기능이 대체하기 위해 만들어진 방식이며, Anthropic도 "터미널 간에 복사하여 붙여넣는 대신"이라고 표현합니다. 이전보다 나아졌지만, 여전히 요약본을 수동으로 전달하는 방식입니다.

여러 세션 대신 하나의 거대한 세션 사용하기. 조율 문제는 피할 수 있지만 압축(compaction) 문제를 다시 유발합니다. 세션이 길어지면 자체 컨텍스트의 중간 내용을 잃어버리게 됩니다.

worktree별 노트를 포함한 worktree 구성. 체계적이고 실행 가능한 방법입니다. 하지만 이제 서로를 알지 못하는 N개의 노트 세트를 유지 관리해야 하므로, 파일 형태로 동일한 파편화 문제가 발생합니다.

모든 작업에 에이전트 팀 사용하기. 하나의 목표를 위해 감독을 받는 팀을 원할 때는 적합하지만, 일반적인 컨텍스트 공유 메커니즘으로는 적합하지 않습니다. 팀 프로토콜 메시지는 팀 내에만 머물며, 팀이 종료되면 사라집니다.

조율 채널은 조율용으로만 유지하고, 지식은 모든 세션이 읽을 수 있는 곳에 두십시오.

이것이 바로 6가지 기능 중 어느 것도 다루지 못하는 레이어입니다. 모든 세션보다 오래 지속되며, 어떤 세션이든 발견한 사실을 기록할 수 있고 다른 어떤 세션이든 이를 읽을 수 있는 저장소입니다. 여기에는 다른 기기, 컨테이너 내부, 네이티브 Windows 또는 완전히 다른 도구에 있는 세션도 포함됩니다. 소비되어 사라지는 메시지도 아니고, 로드 비용이 비싸질 때까지 커지는 파일도 아닙니다.

MemoryLake는 바로 이 작업을 위해 구축되었습니다. 세션과 에이전트가 MCP 또는 API를 통해 읽는 단일 메모리 레이어로, 작업 결과로 생성된 결정 사항과 문서를 보관합니다. 메시징은 지금 세션 B에 스키마 변경 사항을 알려주지만, 저장소는 다음 주에 세션 D가 이를 알 수 있게 해주는 이유입니다.

두 가지 명확한 경계가 있습니다. 이것은 세션 간 메시징을 대체하지 않으며, 대체해서도 안 됩니다. 작업 중간에 변경 사항이 무언가를 깨뜨렸다는 경고는 지금 도착해야 하며, 그것이 바로 메시징의 목적입니다. 또한 공유 저장소가 세션이 읽은 내용에 따라 작동할 것임을 보장하지는 않습니다. 그것은 모델의 행동에 달린 문제입니다. 저장소가 바꾸는 것은 지식이 대화 내부뿐만 아니라 지속 가능하고 검색 가능한 곳에 존재하게 된다는 점입니다.

1단계: API 키 생성

키를 생성하고 약 30초 만에 첫 번째 요청을 완료하세요. 환경 변수나 비밀 관리자(secret manager)에 보관하십시오. 다른 세션의 메시지는 사용자의 구성을 변경하는 것이 명시적으로 금지되어 있으며, 사용자의 자격 증명도 동일하게 보호되어야 합니다.

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

세션들이 계속해서 재발견하는 내용(아키텍처 결정 사항, 스키마 노트, 지난주에 누군가 겪었던 제약 조건 등)이 담긴 문서, 이미지, 파일을 업로드하세요. 가능한 한 요약본보다는 원본 소스를 업로드하십시오. 전달된 메시지의 가장 큰 문제는 그것이 이미 요약본이라는 점이었습니다.

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

Claude, Codex, OpenClaw 및 기타 AI 에이전트가 MCP 또는 API를 통해 메모리에 액세스할 수 있도록 하세요. Claude Code는 MCP 서버를 지원하므로, 메시징이 도달할 수 없는 세션(예: 네이티브 Windows 또는 호스트와 격리된 컨테이너 내부의 세션)을 포함하여 각 세션이 자체 구성에서 동일한 저장소를 읽을 수 있습니다.

첫 번째 차이점은 발견한 사실이 메시지에 머무르지 않고 '사실(fact)'이 된다는 점입니다. 세션 A가 벤더 API가 실패 시 200을 반환한다는 것을 발견했을 때, 세션 B에 핑을 보내고 두 세션이 닫힐 때 이를 잃어버리는 대신, 저장소에 저장되어 향후 모든 세션이 이를 활용할 수 있게 됩니다.

두 번째는 메시징이 연결할 수 없는 기기와 컨테이너가 더 이상 문제가 되지 않는다는 점입니다. 기기 간 메시징은 회신만 가능하고 컨테이너로 격리된 세션은 서로의 소켓을 볼 수 없지만, 모두 API에는 도달할 수 있습니다. 업무용 노트북과 컨테이너가 모두 동일한 지식을 읽게 되며, 이는 여러 기기 간에 컨텍스트를 잃지 않는 실질적인 방법입니다.

세 번째는 메시지가 더 짧고 명확해진다는 점입니다. 공유된 기반이 이미 존재하므로, 메시지는 마이그레이션이 무엇이었는지 다시 설명하는 긴 문단 대신 "이제 main에 리베이스해도 안전합니다"와 같이 새로운 내용만 전달하면 됩니다.

또한 도구의 수명보다 오래 지속됩니다. 스키마 결정 사항은 Codex와 Cursor에서도 유효합니다. Claude Code 세션 간의 대화에 보관되면 그것은 Claude Code의 결과물일 뿐이지만, 저장소에 보관되면 MCP를 지원하는 모든 에이전트에서 접근할 수 있습니다.

세션에 이름 지정하기

세션은 /rename 또는 --name 플래그로 설정한 이름에 응답합니다. 이름을 지정하지 않으면 Claude Code는 작업 디렉터리의 폴더에서 myapp-3f와 같은 이름을 파생시킵니다. 두 세션의 이름이 같아질 수 있으며, 이 경우 /list-agents에서 작업 디렉터리로 구분됩니다. 수행 중인 작업에 따라 migration, payments-api 등으로 이름을 지정하면 Claude의 주소 지정이 안정적이고 나중에 메시지를 읽기도 쉬워집니다.

전송이 아닌 진단을 위해 /list-agents 사용하기

Claude가 대상을 직접 찾기 때문에 전송을 요청하기 전에 이 명령을 실행할 필요는 없습니다. 이 명령이 유용한 곳은 문제 해결입니다. 만약 /list-agents가 인식되지 않는다면 해당 세션에 이 기능이 없는 것이므로 먼저 claude --version을 확인하세요. 명령은 작동하지만 메시지가 도착하지 않았다면 권한 거부 규칙, 수신자의 수신 제어, 또는 이 기기 외부 세션에 대한 회신 전용 제한 등 더 구체적인 문제가 적용된 것입니다.

무인 워커를 위한 수신 정책을 신중하게 결정하기

claude -p 워커는 인박스 소켓을 바인딩하고 목록에 나타나지만, 승인 대화 상자를 표시할 수 없으므로 보류된 메시지는 계속 보류 상태로 남습니다. 헤드리스(headless) 워커가 메시지를 수락하도록 하려면, 실행하는 모든 세션에 적용되는 사용자 설정이 아니라 해당 워커의 --settings에서 crossSessionInbound를 accept로 설정하십시오.

결정 사항은 저장소로, 상태는 세션으로 보내기

좋은 지침: 지금 이 순간에만 유효한 사실("테스트 실행 완료", "리베이스 중")이라면 메시지로 보내세요. 다음 달에도 여전히 유효할 사실("공유 스키마 제약 조건 때문에 org_id 대신 tenant_id를 선택함")이라면 저장소에 기록하십시오. 상태는 만료되지만, 결정 사항은 만료되어서는 안 됩니다.

메시징을 사용할 수 없는 환경에서는 메시징에 의존하지 않기

OS 요구 사항 외에도, 세션 간 메시징은 Amazon Bedrock, AWS 기반 Claude Platform, Google Cloud의 Agent Platform 또는 Microsoft Foundry에서 사용할 수 없으며, CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC, DISABLE_TELEMETRY, DO_NOT_TRACK 또는 DISABLE_GROWTHBOOK과 같은 환경 변수가 이 기능이 의존하는 기능 플래그(feature-flag) 평가를 비활성화하는 경우에도 꺼진 상태로 유지됩니다. 설정이 이러한 경우에 해당한다면, 공유 저장소가 유일한 채널입니다.

Claude Code 세션 간의 메시징은 진정한 개선이며 워크플로우에 도입할 가치가 있습니다. 이는 한 세션이 작업 중간에 다른 세션에 무언가를 전달해야 하는 경우 터미널 간의 복사 및 붙여넣기를 없애줍니다. 다만 문서 자체의 설명을 참고하십시오. 메시지는 텍스트일 뿐 "대화 기록이나 파일이 아니며", 대화의 컨텍스트를 이동하려면 세션을 재개해야 합니다.

따라서 채널을 목적에 맞게 사용하십시오. 조율은 메시징을 통해 이루어지고, 단일 대화는 재개를 통해 이동하며, 감독을 받는 그룹은 에이전트 팀을 사용합니다. 그리고 다음 달에도 여전히 유효해야 할 지식은 모든 세션이 읽는 저장소에 저장됩니다. 이 마지막 레이어는 Claude Code가 기본으로 제공하지 않는 부분이며, 세 개의 터미널을 하나의 프로젝트처럼 느끼게 만드는 핵심 요소입니다.