Claude Code 세션끼리 메시지 주고받는 기능, 보안 걱정 없이 쓰는 법 4가지 (2026년 기준)
Free Resource
PDF · Free
여러 AI를 동시에 쓸 때 생기는 문제, 이렇게 풀렸다: 비개발자를 위한 쉬운 가이드
Get the practical guide first, before diving into the full article.
Claude Code 세션 메시징 실측기: 2026 로컬 소켓부터 v2.1.224 보안 설정까지 4가지
Claude Code 세션끼리 이제 직접 대화해요. v2.1.224부터 유닉스 소켓으로 메시지를 주고받고, 권한 설정으로 껐다 켤 수 있습니다.
결론부터 말하면, Claude Code 세션들이 이제 서로에게 말을 걸어요. 같은 컴퓨터에서 세션 여러 개를 띄워 두고 일하는 분이라면 한 번쯤 이런 질문이 떠올랐을 거예요. "다른 세션이 보낸 메시지를 그대로 믿어도 되나요?" 창을 여러 개 오가며 결과를 복사해 붙여넣던 분이라면 이 걱정, 낯설지 않으실 거예요. 이 글에서는 실제 소켓을 직접 열어 확인한 결과부터, 기존 서브에이전트·Agent teams와 뭐가 다른지, 메시지가 가는 경로, 껐을 때 생기는 부작용까지 정리했어요.
Claude Code 세션 메시징이란, 소켓까지 직접 확인해봤습니다
크로스 세션 메시징이란?: 같은 컴퓨터 또는 다른 컴퓨터에서 실행 중인 서로 다른 Claude Code 세션이
SendMessage·ListAgents도구로 직접 메시지를 주고받는 기능입니다. v2.1.224(2026-08-07, 오늘 기준 1일 전)에 추가됐고, 원래 서브에이전트 전용이던 통신 채널을 독립 세션까지 넓힌 것이 핵심입니다.
말로만 듣고 넘어가지 않았어요. 이 기능이 정말 로컬에서 작동하는지 직접 소켓을 뒤져봤거든요. macOS는 /tmp가 /private/tmp로 이어지는 심링크라, find /tmp -name "*.sock"로는 아무것도 안 잡히더라고요. 실행 중인 세션 PID를 lsof로 역추적하고 나서야 진짜 경로가 보였어요.
실제로 확인한 내용은 다음과 같아요.
- 세션마다
/tmp/cc-socks/{PID}.sock형태로 소켓 파일이 하나씩 생겨요. - 권한은
drwx------·srw-------로, 소유자 본인만 접근 가능합니다. - v2.1.224 이상 세션에만 소켓이 있고, 같은 시각 v2.1.223으로 켜져 있던 세션들은 소켓이 하나도 없었어요. 버전 게이트가 실제로 걸려 있다는 뜻이죠.
- 이 리서치를 진행한 세션 자체도 v2.1.223이었는데, 바이너리를 2.1.225로 올린 뒤에도 세션을 새로 시작해야만 기능이 켜지더라고요.
- 종료된 세션의 소켓 파일 2개(PID 13555·90202)가 그대로 남아 있었어요. 버그인지 의도된 동작인지는 확인하지 못했어요.
기존 병렬 실행 방식과 뭐가 다른가
Claude Code에는 이미 여러 개의 AI 에이전트 협업 방식이 있었어요. 그런데 세션 메시징이 나오기 전까지는, 독립된 세션끼리 서로의 존재를 아는 방법 자체가 없었죠.
| 방식 | 범위 | 한계 |
|---|---|---|
| 서브에이전트 | 한 세션 안에서만 | 부모 세션이 결과를 모을 뿐, 관련 없는 다른 세션은 존재 자체를 모릅니다 |
| Agent teams | 리더가 관리하는 팀 안에서만 | 팀 밖과는 소통 불가, 기본값이 실험적 비활성 상태입니다 |
| Agent view | 백그라운드 세션 지켜보기 | 진행 상황을 보는 화면일 뿐 메시지를 주고받지는 못합니다 |
| Worktree | git 체크아웃 분리 | 파일 충돌만 막아줄 뿐 세션 간 조율 기능은 없습니다 |
이 답답함을 가장 잘 보여주는 게 GitHub Issue #37213이에요. 2026-03-21(오늘 기준 140일 전) 작성자가 이렇게 적었어요. "같은 머신에서 같은 코드베이스로 작업 중이어도, 세션들은 완전히 격리돼 있다." 이 사람은 결국 tmux MCP로 우회했는데, 세팅 마찰이 만만치 않았다고 하네요.
세션 메시징은 이 넷을 대체하는 게 아니라 빈틈을 메우는 쪽에 가까워요. 공식 문서도 "병렬 worktree 조율"을 대표 활용 사례로 꼽고 있으니, worktree와 짝지어 쓰라는 의도로 보여요.
메시지가 가는 3가지 경로
받는 세션이 어디 있느냐에 따라 전달 방식과 답장 가능 여부가 달라져요.
| 상황 | 전달 방식 | 답장 가능 여부 |
|---|---|---|
| 같은 컴퓨터의 세션 | 세션별 유닉스 소켓, Anthropic 서버를 거치지 않음 | 새 메시지·답장 모두 가능 |
| 다른 컴퓨터의 내 세션 | Anthropic 서버 + Remote Control 연결 | 답장만 가능 |
| 웹의 Claude Code | Anthropic 서버 경유 | 답장만 가능 |
같은 컴퓨터라고 해서 무조건 되는 것도 아니에요. 컨테이너 안에 있는 세션은 호스트 쪽 세션을 보지 못합니다. 반대로 컨테이너끼리는 서로 볼 수 있고요. 결국 핵심 조건은 "같은 파일시스템을 공유하는가"예요.
받은 메시지, 자동으로 처리할지 정하기
메시지를 받는 쪽 세션은 crossSessionInbound 설정으로 수락(accept)·보류(hold)·거절(refuse) 중 하나를 고를 수 있습니다. 기본값은 양쪽 세션의 권한 모드로 자동 결정되는데, bypassPermissions 모드로 켜둔 세션은 기본이 보류라 사용자 승인이 필요합니다. 보류 대화상자는 dialogExpiry 설정(기본 5분)이 지나면 자동으로 닫히더라고요.
보안 우려가 걱정되실 텐데, 공식 문서가 명시한 안전장치는 네 가지입니다.
- 받는 쪽 세션에 승인 권한을 넘기지 않습니다.
- 메시지로 설정을 바꿀 수 없습니다.
- 메시지 안의 명령어는 자동 실행되지 않고 평문 텍스트로만 도착합니다.
- 받는 세션 본래의 권한 규칙이 그대로 적용됩니다.
메시지 폭주를 막는 장치도 있습니다. 발신자별 속도 제한, 중복 메시지 억제, 세션당 미확인 메시지 50개 상한, 대기 메시지 100개 상한(초과 시 오래된 것부터 삭제)이 함께 걸려 있습니다.
끄고 싶다면, 그런데 서브에이전트 통신까지 같이 꺼집니다
세션 메시징을 아예 막고 싶다면 설정 파일에 이렇게 넣으면 됩니다.
{
"permissions": { "deny": ["SendMessage", "ListAgents"] },
"crossSessionInbound": "refuse"
}
여기서 꼭 알아두셔야 할 게 있어요. SendMessage는 서브에이전트와 Agent teams가 결과를 주고받을 때도 쓰는 바로 그 도구예요. 그러니 이 도구를 deny 목록에 넣으면 크로스 세션 메시징만 꺼지는 게 아니라, 서브에이전트에게 작업을 위임하는 기능까지 함께 멈춥니다. 커뮤니티 코멘트와 공식 문서 양쪽에서 같은 경고가 확인됐어요. 크로스 세션 메시징만 딱 막고 싶다면 crossSessionInbound를 refuse로만 설정하는 편이 안전합니다.
왜 지금 "드디어"라는 말이 나왔을까
세션 메시징이 갑자기 튀어나온 기능은 아니에요. CHANGELOG를 따라가 보면 5개월 가까이 걸친 흐름이 보여요.
| 날짜 | 버전 | 내용 | 오늘(2026-08-08) 기준 |
|---|---|---|---|
| 2026-03-16 | v2.1.77 | 서브에이전트 재개용 SendMessage({to: agentId}) 도입 | 145일 전 |
| 2026-06-02 | v2.1.161 | $TMPDIR 유닉스 소켓 EADDRINUSE 오류 수정 | 67일 전 |
| 2026-06-03 | v2.1.162 | 깊은 경로에서 세션 간 메시징이 조용히 끊기던 문제 수정 | 66일 전 |
| 2026-06-05 | v2.1.166 | 중계 메시지가 사용자 권한을 그대로 갖지 않도록 보강 | 64일 전 |
| 2026-08-07 | v2.1.224 | 세션 간 SendMessage 추가, crossSessionInbound·dialogExpiry 설정 신설 | 1일 전 |
| 2026-08-07 | v2.1.225 | 헤드리스 세션 보류 알림 누락 수정, Remote Control 대상 지정 발송 추가 | 1일 전 |
이 흐름만 보면 "단계적으로 준비해오다 8월 7일 정식 공개"라는 이야기가 그럴듯해 보이죠. 다만 Anthropic이 이걸 단계적 롤아웃이었다고 명시한 문장은 찾지 못했어요. 다만 위 타임라인은 CHANGELOG 기록을 근거로 한 추정이라는 점을 미리 밝혀둘게요. 안전하게 표현하자면 "서브에이전트에만 쓰이던 메시징이 독립 세션과 다른 머신까지 열렸다"고 보는 게 정확해요.
마무리
정리하면, Claude Code 세션 메시징은 서브에이전트에게만 열려 있던 통신을 독립 세션과 다른 컴퓨터까지 넓힌 기능이에요. 로컬 소켓을 직접 열어보니 버전 게이트도 실제로 걸려 있었고, 끄고 켜는 권한도 세밀하게 나뉘어 있었어요. 다만 서브에이전트 통신과 도구를 공유하기 때문에, 끄기 전에는 영향 범위를 먼저 확인하는 게 안전합니다.
우리 팀 상황에 맞는지부터 따져보셔도 충분하죠. 판단에 필요한 기준은 위에 정리해 뒀어요.
자주 묻는 질문 (FAQ)
Q: SendMessage 권한을 끄면 서브에이전트도 못 쓰게 되나요?
네, 그렇습니다. 서브에이전트와 Agent teams는 세션 간 메시징과 같은 SendMessage 도구를 공유하기 때문에, 이 도구를 deny 목록에 넣으면 서브에이전트에게 작업을 맡기는 기능까지 함께 꺼집니다. 크로스 세션 메시징만 막고 싶다면 crossSessionInbound를 refuse로 설정하는 편이 낫습니다.
Q: 다른 컴퓨터에 있는 세션에도 메시지를 보낼 수 있나요?
먼저 말을 거는 건 안 돼요. 답장만 가능합니다. 같은 컴퓨터 안 세션끼리는 유닉스 소켓으로 직접 연결돼 새 메시지와 답장이 모두 오가지만, 다른 컴퓨터의 세션이나 웹의 Claude Code는 Anthropic 서버와 Remote Control 연결을 거치며 이때는 답장만 됩니다.
Q: 다른 세션이 보낸 메시지를 그대로 믿어도 되나요?
메시지 안에 담긴 명령은 자동으로 실행되지 않고 평문 텍스트로만 도착하며, 받는 세션의 권한 규칙이 그대로 적용됩니다. 다만 세션이 읽은 텍스트를 바탕으로 행동하는 구조라, 커뮤니티에서는 프롬프트 인젝션 경로가 하나 더 늘었다는 우려도 나오고 있어요.

