Claude Code의 세션 간 메시지 전송

v2.1.224부터 Mac이나 Linux에서 실행되는 모든 대화형 Claude Code 세션은 시작하는 순간 Unix 소켓을 바인딩합니다. 제 경우 /tmp/cc-socks/38590.sock에 소유자 전용 권한으로 생성되며, 여러분이 실행 중인 다른 세션은 이 소켓에 텍스트 메시지를 넣을 수 있습니다.¹ 이 기능을 움직이는 도구는 두 가지입니다. ListAgents는 어떤 세션에 연결할 수 있는지 찾아내고, SendMessage는 그중 하나에 이름을 지정해 메시지를 전달합니다.² 따로 켤 것도, 설정할 것도 없습니다. 두 세션이 같은 컴퓨터에서 v2.1.224 이상으로 돌아가고 있다면 이미 대화가 가능한 상태입니다.

핵심 요약

이제 Claude Code 세션끼리 메시지를 주고받을 수 있습니다. 같은 컴퓨터 안에서는 Anthropic 서버를 전혀 거치지 않는 로컬 소켓으로, 다른 컴퓨터와는 Remote Control을 통해서 오갑니다. 출시 시점에는 답장만 가능했지만 v2.1.225에서 이름을 지정해 먼저 대화를 시작하는 기능이 추가됐습니다.¹⁵ 오가는 것은 순수한 텍스트뿐이며, 대화 기록이나 파일, 권한은 절대 넘어가지 않습니다. 받는 세션은 메시지를 입력으로 취급할 뿐 권한으로 받아들이지 않습니다. 즉 메시지로는 승인 요청을 대신 처리할 수도, 설정을 바꿀 수도, 명령을 실행할 수도 없습니다.¹ 이 기능은 제각각 돌아가던 터미널 무리를 팀에 가까운 무언가로 바꿔놓습니다. 가장 잘 맞는 쓰임새는 그동안 손으로 날라야 했던 조율용 알림입니다. “마이그레이션 끝났어요”, “그 컬럼 이름 바꿨습니다”, “이제 main에 rebase해도 안전합니다” 같은 것들이죠. 가장 날카로운 함정은 아무 소리 없이 사라지는 경우입니다. 서로 관련 없어 보이는 네 개의 프라이버시 환경 변수가 각각 이 기능을 조용히 꺼버립니다.³

무엇이 출시됐나

v2.1.224 릴리스는 macOS와 Linux에서 세션 간 SendMessage와 ListAgents 탐색 기능을 추가했습니다. 이어진 v2.1.225는 여기서 한 걸음 더 나아가, 다른 컴퓨터의 Remote Control 세션에 대해 먼저 대화를 걸 수 있게 했습니다. 그전까지는 답장만 가능했습니다.⁴⁵

내부 동작을 직접 들여다볼 수 있는 창구는 세 곳입니다.

• /list-agents(별칭 /peers)는 Claude가 닿을 수 있는 모든 세션을 보여줍니다. 현재 세션 안의 서브에이전트, 백그라운드를 포함한 여러분의 다른 로컬 세션, 그리고 Remote Control이 연결된 동안에는 다른 컴퓨터의 세션과 웹의 Claude Code 세션까지 나옵니다.¹
• /status에는 Peer address 행이 있어 해당 세션 자신의 수신함 소켓을 uds: 접두사와 함께 보여줍니다.¹
• CLAUDE_CODE_MESSAGING_SOCKET은 모든 훅과 Bash 명령에 환경 변수로 전달되며, 세션 자신의 소켓 경로를 담고 있습니다.⁶ 이게 왜 중요한지는 아래에서 더 다룹니다.

제 컴퓨터에서 직접 확인해 봤습니다. v2.1.226으로 실행 중인 세션이 다른 두 세션을 상태(“busy”)와 경과 시간과 함께 나열했고, 소켓 파일에는 srw------- 권한이 붙어 있었습니다. 제 계정만 읽고 쓸 수 있다는 뜻이고, 공용 컴퓨터에서는 바로 이 권한이 경계선 역할을 합니다.¹

세션은 이름으로 서로를 부릅니다. /rename이나 --name 플래그로 직접 지정할 수 있고, 그러지 않으면 Claude Code가 작업 디렉터리에서 myapp-3f 같은 이름을 만들어 냅니다.¹ 두 세션의 이름이 겹치면 목록에서 작업 디렉터리와 짧은 식별자로 구분해 줍니다.¹

진짜 재미있는 부분은 신뢰 모델

Anthropic의 설계는 대부분의 멀티 에이전트 시스템이 얼버무리는 질문에 답을 내놓습니다. 다른 에이전트가 보낸 메시지는 과연 어느 정도의 무게를 갖는가? 여기서의 답은 명확합니다. 메시지는 정보일 뿐, 결코 권한이 아닙니다.¹

세션 A가 세션 B에 메시지를 보낼 때, 도착한 내용은 네 가지 규칙에 묶입니다.¹

1. 무엇도 승인할 수 없습니다. B에 떠 있는 권한 요청은 A가 무슨 말을 하든 무시합니다. 요청에 답하는 것은 오직 사람입니다.
2. 설정을 바꿀 수 없습니다. 받는 쪽 Claude는 다른 세션이 요청했다는 이유로 권한 설정이나 CLAUDE.md, 그 밖의 어떤 설정도 건드리지 말라는 지시를 받습니다.
3. 명령은 텍스트로 도착합니다. 메시지 본문에 적힌 /compact는 실행되는 명령이 아니라 그냥 네 글자짜리 문장일 뿐입니다.
4. 권한 요청은 여전히 뜹니다. 메시지 내용대로 움직이려는데 B에게 없는 권한이 필요하다면, 다른 작업과 똑같이 요청 창이 나타납니다.

수신 쪽에도 별도의 관문이 있습니다. 도착하는 메시지는 전달, 사용자 승인 대기, 거부 중 하나의 결과로 처리되며, 이는 crossSessionInbound 설정(accept, hold, refuse)으로 제어합니다.¹ 아무것도 지정하지 않으면 Claude Code가 두 세션의 권한 모드를 보고 메시지마다 판단하는데, 그 기본 논리가 꽤 우아합니다. 권한 요청을 건너뛰는 세션이 한 부류, 나머지가 다른 한 부류가 됩니다. 요청을 띄우는 세션은 메시지를 자유롭게 받되 건너뛰는 세션에서 온 것은 보류하고, 건너뛰는 세션은 같은 부류에서 온 메시지를 빼면 전부 보류합니다.¹ 이 비대칭은 의도된 설계입니다. 메시지가 관대한 세션의 권한에 편승해서는 안 된다는 원칙이고, v2.1.222가 auto 모드의 발신 쪽에 적용한 것(권한 분류기가 전송 전에 모든 발신을 검토합니다)을 v2.1.224가 수신 쪽에도 적용한 셈입니다.⁷

보류된 메시지는 발신자와 미리보기를 보여주는 승인 창을 띄웁니다. 답하지 않은 창은 5분 뒤 만료되고(dialogExpiry로 조정 가능) 메시지는 버려집니다.¹ 동시에 보류할 수 있는 메시지는 최대 100건입니다.¹ 범위를 더 좁히는 장치도 두 가지 있습니다. isolatePeerMachines: true는 bypassPermissions 모드에서조차 메시지가 컴퓨터 밖으로 나가기 전에 명시적 승인을 요구하며, 어느 설정 범위에서든 true 하나면 그 값이 이깁니다. 그래서 저장소에 커밋된 프로젝트 설정 파일은 이 조임쇠를 더 죌 수는 있어도 풀 수는 없습니다.¹ 조직 차원에서는 SendMessage와 ListAgents에 거부 규칙을 걸고 관리 설정에 crossSessionInbound: "refuse"를 넣어 기능을 통째로 차단할 수 있습니다.¹

메시지가 오가는 경로

상대 세션이 어디에서 돌아가느냐에 따라 전송 경로와 보낼 수 있는 내용이 함께 달라집니다.¹

문서상 충돌 하나는 짚어둘 만합니다. 이 글을 쓰는 시점에 Anthropic의 세션 간 메시지 문서 페이지는 컴퓨터를 넘나드는 메시지를 여전히 답장만 가능하다고 설명하는 반면, v2.1.225 릴리스 노트는 SendMessage가 “이제 다른 컴퓨터의 Remote Control 세션에 이름을 지정해 대화를 시작할 수 있다”고 밝힙니다. 릴리스 노트가 더 최신이고, 문서 페이지가 릴리스를 따라가지 못한 상태입니다.¹⁵

같은 컴퓨터인지 아닌지를 가르는 기준은 파일 시스템의 가시성입니다. 세션은 디스크의 파일에 자신을 등록하므로, 두 세션은 같은 파일을 볼 수 있을 때만 서로에게 닿습니다. 컨테이너 안의 세션과 호스트의 세션은 대화할 수 없지만, 같은 컨테이너 안의 두 세션은 가능합니다.¹

전달은 받는 세션의 호흡을 존중합니다. 메시지는 작업이 진행 중일 때는 도구 호출 사이에 읽히고, 실행 중인 도구를 중간에 끊는 일은 없으며, 세션이 놀고 있을 때는 새 차례를 시작합니다.¹ 전달된 메시지는 여러분이 직접 입력한 프롬프트와 마찬가지로 사용량에 잡힙니다.¹

만들어 볼 만한 다섯 가지 패턴

1. 워크트리 조율. 가장 뻔하면서도, 공식 문서가 예시 메시지로 직접 보여주는 사례이기도 합니다. 같은 저장소를 각자의 워크트리에서 다루는 세션들이 무엇이 반영됐는지 서로 알려주는 것입니다.¹ “스키마 마이그레이션 완료: 새 컬럼은 tenant_id이고, 이제 main에 rebase해도 안전합니다.”가 문서에 실린 예시 메시지인데, 이런 종류의 소식은 원래라면 여러분이 직접 눈치채고, 터미널을 옮기고, 다시 타이핑해야 전달됩니다. 워크트리 대신 여러 세션이 하나의 체크아웃을 공유한다면 조율 메시지의 가치는 한층 더 커집니다. “지금 content/guides/를 커밋할 참이니 스테이징하지 마세요” 한 줄이, 한 세션이 다른 세션의 미완성 작업을 커밋해 버리는 고전적인 공유 트리 충돌을 막아줍니다.

2. 감시자와 작업자. 배포나 테스트 스위트, 로그를 지켜보는 감시 세션을 하나 띄워두고, 무언가 깨지는 즉시 수정을 맡은 세션에 알리게 하는 방식입니다. 받는 세션은 그 발견을 명령이 아니라 맥락으로 받아들이며, 무엇을 할지는 여전히 자기 권한 안에서 스스로 판단합니다. 여기에 백그라운드 세션과 알림 훅을 엮으면, 정말 필요할 때만 사람에게 도달하는 단계적 에스컬레이션 사슬이 만들어집니다.

3. 보고하는 장기 실행 세션. 한 세션에서 마이그레이션이나 긴 테스트를 돌려놓고, 여러분이 실제로 보고 있는 세션에 결과를 보고하게 하는 방식입니다.¹ 상태 정보가 잊힌 터미널 안에서만 머무르는 일이 사라집니다. 반대 방향도 됩니다. 지켜보는 쪽에서 물으면 되니까요. “다른 터미널의 세션에 마이그레이션이 끝났는지 물어봐 줘”라고 한 줄 던지면 Claude가 상대를 찾고, 주소를 지정하고, 문장을 다듬는 일까지 알아서 처리합니다.¹

4. 무인 작업자 집단. 헤드리스 claude -p 세션도 수신함 소켓을 바인딩하므로, 오래 도는 -p 작업자가 메시지를 받을 수 있고 목록에도 나타납니다.⁸ 다만 걸리는 지점이 있습니다. -p 세션은 승인 창을 띄울 수 없어서, 보류된 메시지는 설정이나 모드를 바꾸지 않는 한 전달될 길 없이 보류 상태로 남습니다(v2.1.225는 이런 메시지가 아무 안내도 만료도 없이 방치되던 문제도 함께 고쳤습니다). 메시지를 받는 무인 작업자를 띄우려면 그 세션의 --settings 값에 crossSessionInbound: "accept"를 넣어 시작하세요. 사용자 설정에 accept를 넣어 실행하는 모든 세션에 적용해 버리는 대신, 작업자별로 권한을 주는 방식입니다.⁸ bare 모드 세션은 소켓 자체를 건너뛰므로 아예 닿을 수 없습니다.⁸

5. 스크립트가 넣는 수신함. 조용한 실세는 이쪽입니다. CLAUDE_CODE_MESSAGING_SOCKET이 훅과 Bash 명령에 전달되기 때문에, 스크립트가 세션 자신의 수신함에 직접 글을 넣을 수 있습니다.⁶ Claude Code는 자기 자식 프로세스가 보낸 메시지를 검증합니다. 훅이나 명령이 자기 세션으로 되돌려 보내는 메시지는 명시적인 crossSessionInbound 설정이 없다면 별다른 절차 없이 전달됩니다.¹ 야간 배치 작업, git 훅, CI 래퍼까지, Unix 소켓에 쓸 수 있는 것이라면 무엇이든 자신을 띄운 세션에 맥락 한 줄을 밀어 넣을 수 있게 된 것입니다. Linux에서는 글을 넣은 프로세스가 종료된 뒤에도 검증이 동작하지만, macOS에서는 그 프로세스가 살아 있는 동안에만 가능합니다. Claude Code가 PID 1인 컨테이너에서는 검증이 실패하고 메시지는 일반 수신 규칙으로 되돌아갑니다.¹ 샌드박스에서 실행되는 명령은 sandbox.network.allowUnixSockets로 해당 소켓을 허용해 줘야 합니다.¹

이 기능이 되기를 거부하는 것들

여기서의 한계는 모두 설계상의 결정이며, 그것을 존중하면 엉뚱한 것을 만드는 일을 피할 수 있습니다.

승인 통로가 아닙니다. 신뢰 모델의 모든 요소는 한 세션이 다른 세션의 행동을 허가하는 것을 막기 위해 존재합니다. “세션 A가 승인하면 세션 B가 실행한다” 형태의 흐름은 명시적으로 배제된 설계입니다. 권한은 언제나 사람을 거쳐야 합니다.¹

맥락 이전이 아닙니다. 메시지는 한 Claude가 다른 Claude에게 쓰는 텍스트일 뿐, 대화 기록이나 파일이 아닙니다. Anthropic 문서는 이를 분명히 말합니다. 대화를 옮기고 싶다면 그 세션을 이어서 실행하라는 것입니다.¹ 요약해서 전하세요. 통째로 쏟아붓지 마세요.

에이전트 팀이 아닙니다. 독립된 세션들이 서로 메시지를 주고받는 것은 대등한 관계의 사례입니다. Claude가 직접 만들고 감독하는 조직된 팀, 즉 정해진 형식의 프로토콜 메시지와 명단, 공유된 작업 상태를 갖춘 구조는 에이전트 팀 기능의 몫이고, 형식을 갖춘 팀 메시지는 의도적으로 팀 내부에만 머무릅니다.¹ 세션 간 텍스트 위에 나름의 메시지 프로토콜을 설계하고 있다면, 여러분에게 필요한 것은 에이전트 팀입니다.

채팅 루프가 아닙니다. Claude Code는 발신자별로 반복 메시지에 속도 제한을 걸고, 짧은 시간 안에 도착한 똑같은 메시지는 버리며, 읽지 않은 수신 메시지를 세션당 50건으로 제한합니다. 그래서 두 세션 사이의 메시지 루프는 설계상 저절로 굶어 죽습니다.¹ 대화가 아니라 요청과 응답의 교환을 만드세요.

함정들

프라이버시 환경 변수가 조용히 기능을 꺼버립니다. 세션 간 메시지는 기능 플래그 평가에 의존하는데, CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC, DISABLE_TELEMETRY, DO_NOT_TRACK, DISABLE_GROWTHBOOK 중 어느 하나만 있어도 그 평가가 꺼지고, 메시지 기능도 아무 말 없이 함께 내려갑니다.³ 진단은 /list-agents로 합니다. 명령 자체가 인식되지 않으면 그 세션에는 기능이 아예 없는 것이고, 명령은 동작하는데 보낸 메시지가 도착하지 않는다면 더 좁은 원인입니다. 거부 규칙이거나, 받는 쪽의 수신 설정이거나, 답장만 받는 다른 컴퓨터의 대상이거나 셋 중 하나입니다.¹

플랫폼과 제공자의 공백. Windows 네이티브 지원은 없습니다(WSL 2 안의 Linux는 됩니다). Amazon Bedrock, AWS의 Claude Platform, Google Cloud의 Agent Platform, Microsoft Foundry에서는 사용할 수 없습니다.¹

한쪽으로만 열린 답장. 답장을 보내는 세션이 Remote Control에 연결되어 있지 않은 상태에서 다른 컴퓨터의 세션에 답장을 보내면, 메시지는 도착하지만 회신 주소가 없어 받는 쪽에서는 답할 수 없습니다. Claude는 메시지를 보낼 때 그 사실을 안내받으며, v2.1.225의 수정으로 주소 지정이 한층 엄격해져서 확인된 원격 수신자가 같은 이름의 로컬 세션으로 조용히 바꿔치기되는 일은 없어졌습니다.⁵

헤드리스 보류. 영문 모르게 메시지를 무시하는 -p 작업자는 십중팔구 보류 메시지 문제입니다. 창이 없으니 전달도 없는 것이죠. 메시지를 받아야 하는 작업자에는 crossSessionInbound: "accept"를 설정하세요.⁸

핵심 정리

Claude Code를 매일 쓰는 사용자라면: - /list-agents를 한 번 실행해 지금 여러분의 세션들이 어디까지 닿을 수 있는지 확인하세요. 중요한 세션은 /rename으로 이름을 붙여두면 메시지 주소 지정이 깔끔해집니다. - 메시지는 평범한 말로 시키면 됩니다(“결제 작업 중인 세션에 우리가 뭘 바꿨는지 알려줘”). 문장을 다듬는 일은 Claude가 알아서 합니다.¹

자동화를 만드는 사람이라면: - CLAUDE_CODE_MESSAGING_SOCKET을 통해 훅과 스크립트에서 세션으로 메시지를 넣으세요. 자기 자식 프로세스가 보낸 메시지는 Linux에서 승인 절차 없이 전달됩니다.¹⁶ - 무인 -p 작업자에게는 전역 설정이 아니라 각자의 --settings에 crossSessionInbound: "accept"를 주세요.⁸

팀과 보안 검토자라면: - 이 기능은 올바른 기본값을 갖고 출시됐습니다. 메시지에는 아무 권한도 실리지 않고, 권한 요청을 건너뛰는 세션은 기본적으로 격리되며, isolatePeerMachines와 관리 설정의 거부 규칙이 컴퓨터 단위와 조직 전체의 차단 스위치를 제공합니다.¹ - 메시지 기능이 고장 났다고 결론 내리기 전에 네 개의 프라이버시 환경 변수부터 점검하세요. 그리고 메시지를 거부하는 세션은 상대편에게 아무런 차이도 보여주지 않는다는 점을 기억해 두세요.¹

참고 자료