Claude Code 세션 간 메시지 사용법: 병렬 세션끼리 작업 결과 전달하기

여러분, Claude Code를 터미널 여러 개에 띄워 병렬로 돌리다 보면 한쪽 세션이 끝낸 작업 결과를 다른 세션에 알려줘야 하는 순간이 꼭 옵니다. 지금까지는 사람이 결과를 복사해 다른 터미널에 붙여넣고 맥락을 다시 설명했죠. 이제는 Claude Code v2.1.224부터 들어간 세션 간 메시지(cross-session messaging)로 이 전달을 Claude에게 맡길 수 있습니다.

결론부터 말하면, 따로 켤 것은 없고 상대 세션 이름을 넣어 시키기만 하면 됩니다. 이 글에서는 세션 이름 관리, 메시지 흐름, 워크트리 시나리오를 정리하고, 2026년 8월 3~7일 주 출시 초기와 10월 3일 기준의 차이를 비교합니다.

Claude Code 세션 간 메시지 핵심 요약

• 세션 간 메시지는 한 Claude Code 세션이 다른 세션에 텍스트를 보내는 기능입니다. macOS·Linux(WSL 2 포함)는 v2.1.224, 네이티브 Windows는 v2.1.234 이상이면 설정 없이 켜져 있고, Amazon Bedrock·Claude Platform on AWS·Google Cloud Agent Platform·Microsoft Foundry나 기능 플래그 조회를 끈 환경에서 같은 컴퓨터 세션끼리 쓰려면 v2.1.248 이상이 필요합니다.
• 세션 이름은 /rename이나 -n 플래그로 정하고(안 정하면 myapp-3f 같은 폴더 기반 이름), /list-agents로 보낼 수 있는 세션을 확인합니다.
• 자연어로 시키면 Claude가 ListAgents로 대상을 찾고 SendMessage로 보냅니다. 필요하다고 판단하면 시키지 않아도 보낼 수 있습니다.
• 워크트리 병렬 작업에서는 마이그레이션을 끝낸 세션이 “리베이스해도 안전하다”를 다른 세션에 알릴 수 있습니다.
• 텍스트만 오가고, 받은 메시지는 권한 프롬프트를 대신 승인하거나 설정을 바꾸지 못합니다.
• 출시 초기에는 다른 컴퓨터 세션에 답장만 할 수 있었지만, v2.1.225부터 먼저 말을 걸 수 있습니다.

세션 간 메시지가 필요한 이유: 병렬 세션의 결과 전달 문제

병렬 세션 사이의 수동 전달 문제

API, 스키마, 테스트를 세션마다 나눠 맡겨도 세션들은 서로를 모릅니다. 스키마 세션이 컬럼을 바꿔도 API 세션은 예전 구조를 가정하고 코드를 씁니다. 결국 사람이 터미널 사이를 오가는 전달자가 되고, 세션이 셋, 넷으로 늘면 이 전달만으로도 꽤 바빠지는 것 같아요.

세션 간 메시지가 맡는 역할

세션 간 메시지는 이 전달자 역할을 Claude에게 넘깁니다. 한 세션의 변경이 다른 세션 작업을 깨뜨리면 Claude가 그 세션에 경고할 수 있고, 다른 세션이 막혀 있던 질문의 답을 찾으면 그 답을 보낼 수 있습니다. 공식 문서도 발견 전달, 병렬 워크트리 조율, 장시간 작업 상태 보고, 머신 간 메시지를 대표 쓰임으로 꼽습니다.

세션 이름 정하기와 /list-agents로 대상 확인하기

메시지는 세션 이름으로 주고받습니다. 그래서 사용법의 절반은 이름 관리라고 봐도 됩니다.

/rename과 -n 플래그로 이름 정하기

실행 중인 세션은 /rename payments처럼, 새 세션은 claude -n payments처럼 시작할 때 이름을 붙입니다. 같은 컴퓨터에서 살아 있는 다른 세션이 이미 쓰는 이름이면 기존 세션이 이름을 유지하고, 새로 붙인 쪽은 두 단어 접미사가 붙은 변형 이름을 받습니다(v2.1.232부터).

이름을 안 정하면 폴더 이름으로 자동 생성

이름을 안 정하면 작업 폴더 이름에 두 글자 접미사를 붙인 기본 이름이 붙습니다. myapp 폴더라면 myapp-3f 같은 식이죠. 다만 기억하기 어렵고 플랜을 수락해도 목록의 기본 이름이 바뀌니, 메시지를 주고받을 세션이라면 직접 이름을 붙이는 편이 낫다고 봅니다.

/list-agents로 보낼 수 있는 세션 확인하기

/list-agents(별칭 /peers)를 실행하면 첫 줄에 내 세션 이름이, 그 아래에 서브 에이전트, 에이전트 팀 팀원, 같은 컴퓨터의 다른 세션(백그라운드 세션 포함)이 나옵니다. 지금 세션이 Remote Control에 연결돼 있으면 클라우드 세션과 다른 컴퓨터의 Remote Control 세션도 보입니다. 첫 줄의 내 이름과 팀원 행은 v2.1.239 이상에서 보입니다.

세션 간 메시지 사용법: 이름을 넣어 자연어로 요청하기

ListAgents와 SendMessage로 보내는 흐름

상대 세션 이름을 넣어 자연어로 시키면 됩니다.

payments 세션한테 마이그레이션 끝났는지 물어봐줘

그러면 Claude가 알아서 ListAgents로 payments 세션을 찾고 SendMessage로 메시지를 보냅니다. 두 도구 모두 사용자가 직접 호출하지 않고, 메시지 문구도 Claude가 쓰니 내용만 맡겨도 됩니다.

v2.1.232부터는 프롬프트에 @와 이름 앞글자를 입력해 자동완성으로 대상을 고를 수도 있습니다. 이름에 공백이 있으면 @"release notes"처럼 큰따옴표로 감쌉니다.

메시지가 도착하는 방식

받는 쪽 Claude는 턴을 진행 중이면 도구 호출 사이에 메시지를 읽으니, 실행 중인 도구가 끊기지 않습니다. 쉬고 있던 세션이면 그 메시지로 새 턴을 시작합니다. 화면에는 보낸 세션 이름과 첫 줄이 담긴 한 줄 미리보기가 뜨고, 전체 내용은 Ctrl+O로 봅니다. 전달된 메시지는 직접 입력한 프롬프트처럼 사용량에 포함됩니다.

워크트리 병렬 작업 시나리오: 마이그레이션 결과를 다른 세션에 알리기

이 기능이 가장 빛나는 곳은 워크트리 여러 개로 나눠 병렬 작업할 때입니다. Git 워크트리가 처음이라면 Cursor와 Git Worktree로 멀티 에이전트 병렬 개발하기를 먼저 보시면 좋습니다.

세션 구성

테넌트 기능을 두 세션으로 나눠 만든다고 해보겠습니다. 세션 A는 API를, 세션 B는 스키마 마이그레이션을 맡습니다. -w(--worktree) 플래그로 워크트리를 만들면서 이름까지 붙여둡니다.

# 터미널 1: 세션 A (API)
claude -w tenant-api -n api

# 터미널 2: 세션 B (스키마)
claude -w tenant-schema -n schema

메시지가 오가는 흐름

1. 세션 B가 마이그레이션을 먼저 끝냅니다. tenant_id 컬럼을 추가하는 작업입니다.
2. Claude가 세션 A에 알릴 필요가 있다고 판단합니다. API 작업에 영향을 주는 변경이니까요. api 세션을 찾아 메시지를 보냅니다.
3. 세션 A에 메시지가 도착합니다. “tenant_id 컬럼 추가했고 main에 리베이스해도 안전하다” 같은 내용입니다.
4. 세션 A의 Claude가 메시지를 읽습니다. 다른 세션에서 온 메시지로 표시되고, 리베이스 같은 다음 작업은 세션 A에서 이어가며 필요한 권한 프롬프트는 평소처럼 뜹니다.

반대로 세션 A가 기다리는 쪽이라면 “schema 세션이 지금 하던 작업을 끝내면 알려줘”라고 걸어둘 수도 있습니다. SendMessage의 notify_when_idle 기능으로, 같은 컴퓨터의 세션이 턴을 마치고 쉬거나 종료될 때 알림을 한 번 받습니다. 두 세션 모두 v2.1.236 이상이어야 하고, 12시간 안에 알림이 없으면 구독이 해제됩니다.

세션 간 메시지는 일을 나누는 기능이 아니라, 이미 나눈 일 사이로 결과를 흘려보내는 연락망입니다.

받은 메시지가 할 수 없는 일: 권한과 설정의 경계

텍스트만 전달되는 범위

파일이나 대화 히스토리는 통째로 넘어가지 않습니다. 오가는 건 Claude가 상대 세션을 위해 쓴 텍스트뿐이고, 메시지 속에서 @로 파일을 언급해도 첨부되지 않습니다.

승인·설정 변경·슬래시 명령 제한

받는 쪽 Claude가 할 수 있는 일은 이렇게 제한됩니다.

제한	내용
승인 불가	사용자 동의로 치지 않아 대기 중인 권한 프롬프트에 대신 답하지 못함
설정 변경 불가	다른 세션이 요청했다는 이유로 권한 설정이나 CLAUDE.md를 바꾸지 않음
슬래시 명령 실행 안 됨	메시지 속 /compact 같은 명령은 일반 텍스트로만 도착
권한 프롬프트 유지	필요한 권한 프롬프트는 받는 세션에서 평소처럼 뜸

보내는 쪽도 자기 세션에서 거부된 작업을 다른 세션에 대신 시키지 않도록 지시받습니다. 왜 이렇게 막아뒀을까요? 권한이 느슨한 세션 하나가 다른 세션의 확인 절차를 우회하는 통로가 되지 않게 하려는 설계로 보입니다.

권한 모드에 따른 기본 수신 정책

crossSessionInbound를 따로 정하지 않으면 두 세션의 권한 모드로 전달 여부가 정해집니다. 권한 프롬프트를 건너뛰는 세션(bypassPermissions, bypass를 쓸 수 있는 대화형 터미널 세션의 plan 모드)과 나머지로 나누고, auto 모드, acceptEdits, dontAsk는 프롬프트를 띄우는 쪽으로 칩니다.

• 받는 세션이 권한 프롬프트를 띄우는 쪽: 메시지를 바로 전달하고, 보내는 세션이 건너뛰는 쪽일 때만 승인 대기로 보류합니다.
• 받는 세션이 건너뛰는 쪽: 메시지마다 승인 대기로 보류하고, 보내는 세션도 건너뛰는 쪽일 때만 바로 전달합니다.

대화형 터미널 세션에서는 보류된 메시지가 승인 대화상자로 뜨고, 기한(dialogExpiry, 기본 5분)까지 답하지 않으면 대화상자가 닫히며 메시지는 버려집니다. 권한 확인 방식이 다른 세션 사이에서 요청이 확인 없이 그대로 넘어가지 않게 하려는 장치라고 봅니다.

기본값을 바꾸려면 crossSessionInbound를 설정합니다. accept는 메시지마다 전달하고, hold는 알림만 띄우고 전달하지 않다가 나중에 accept가 적용되면 풀어주며, refuse는 전달하지 않고 버립니다. v2.1.232부터는 /config의 Messages from your other sessions 항목에서도 고릅니다. 조직 단위로 아예 끄려면 관리형 설정에 이렇게 넣습니다.

{
  "permissions": {
    "deny": ["SendMessage", "ListAgents"]
  },
  "crossSessionInbound": "refuse"
}

SendMessage를 deny하면 같은 도구를 쓰는 서브 에이전트와 에이전트 팀 팀원 대상 메시지까지 함께 막힙니다.

지원 환경과 제약: 출시 초기와 2026년 10월 기준 비교

출시 초기와 비교해 달라진 항목은 이렇습니다.

항목	출시 초기	2026년 10월 3일 기준
운영체제	macOS, Linux(WSL 2 포함)	네이티브 Windows 추가 (2026년 8월 17~21일 주, 문서상 v2.1.234 이상)
다른 컴퓨터의 세션	답장만 가능	v2.1.225부터 먼저 말 걸기 가능 (양쪽 Remote Control 필요)
다른 제공자, 기능 플래그 조회 끔	미지원	Amazon Bedrock, Claude Platform on AWS, Google Cloud Agent Platform, Microsoft Foundry에서도 같은 컴퓨터 세션끼리 가능 (v2.1.248 이상)

텍스트만 오가고 승인·설정 변경이 막힌 점, 같은 컴퓨터 세션끼리 먼저 말을 걸 수 있는 점은 출시 초기와 같습니다.

다른 컴퓨터 세션의 Remote Control 요건

같은 컴퓨터의 세션끼리는 macOS·Linux는 세션별 소켓, 네이티브 Windows는 세션별 named pipe로 주고받아 Anthropic 서버를 거치지 않습니다. 다른 컴퓨터나 클라우드 세션으로 가는 메시지는 Anthropic 서버를 거치고, 대상을 찾으려면 지금 세션이 Remote Control에 연결돼 있어야 합니다(claude.ai 로그인 필요). 다른 컴퓨터의 세션도 Remote Control로 실행 중이어야 하고, API 키나 Bedrock 같은 다른 제공자로는 찾지 못합니다.

컴퓨터 밖으로 나가는 메시지마다 승인을 받고 싶다면 설정에 "isolatePeerMachines": true를 넣습니다. bypassPermissions 모드에서도 승인을 묻고, 같은 컴퓨터 안의 메시지는 묻지 않습니다.

같은 컴퓨터 안의 예외와 메시지 제한

같은 컴퓨터여도 컨테이너 안 세션과 호스트 세션, WSL 2 세션과 네이티브 Windows 세션은 서로 닿지 않습니다. 같은 컴퓨터로 보내는 메시지는 약 100만 자를 넘으면 거부됩니다. 짧은 시간에 몰아 보내 상대 수신함 한도에 닿으면 보내는 쪽이 추가 전송을 거부합니다. 받는 쪽은 보낸 세션별로 반복 메시지 속도를 제한하고, 짧은 시간 안에 온 똑같은 메시지는 버리며, 수락한 메시지는 최대 50개까지만 대기시킵니다. 그래서 두 세션 사이에 메시지 루프가 생겨도 스스로 멈춥니다.

실전 운용 팁: 세션 이름 규칙과 비슷한 기능 구분

세션 이름은 역할 기준으로 짧게

문서에서 확인한 동작을 바탕으로 정리한 권장 운용 기준입니다.

• 역할 이름을 씁니다. api, schema, payments처럼 맡은 일이 바로 보이는 이름이 좋습니다. 메시지를 시킬 때 그 이름을 그대로 말하게 되니까요.
• 워크트리 이름과 짝을 맞춥니다. 위 시나리오처럼 맞춰두면 어느 세션이 어느 브랜치인지 헷갈리지 않습니다.
• 메시지에는 결론을 담게 합니다. 파일이 넘어가지 않으니 무엇이 바뀌었고 상대가 무엇을 해도 되는지가 메시지만으로 전달돼야 합니다.

비슷한 기능과 구분해서 쓰기

세션 간 메시지는 내가 직접 띄우고 조종하는 독립 세션끼리 쓰는 기능입니다.

하고 싶은 일	맞는 기능
대화 맥락 전체를 다른 터미널에서 이어가기	세션 재개(resume)
한 세션 안에서 곁가지 작업을 맡기고 요약 받기	서브 에이전트
백그라운드 세션 여러 개를 한 화면에서 관리하기	agent view (리서치 프리뷰)
Claude가 작업을 계획·배분하고 작업자 그룹을 감독하기	에이전트 팀 (실험 기능, 기본 비활성)
내가 띄운 세션끼리 발견과 상태 주고받기	세션 간 메시지

이 기능들은 함께 쓸 수 있습니다. 예를 들어 agent view에서 띄운 백그라운드 세션도 /list-agents에 나타나니 메시지를 보낼 수 있습니다. 사용법은 Claude Code Agent View로 멀티 에이전트 관리하기에 정리해뒀습니다.

마무리

정리하면, Claude Code 세션 간 메시지는 병렬 작업에서 마지막까지 사람 손에 남아 있던 결과 전달을 Claude에게 넘기는 기능입니다. 텍스트만 오가고 권한 경계는 세션마다 그대로라, 편해진 만큼 위험해지지는 않게 설계됐다고 봅니다.

시작은 간단합니다. 병렬로 띄우는 세션마다 역할 이름을 붙이고, /list-agents로 서로 보이는지 확인한 뒤, 첫 메시지는 직접 시켜보세요. 터미널 사이를 오가던 복붙을 꽤 줄여주는 꿀 기능이니, 바로 한 번 활용해보세요.