Claude Code 세션 메시징 사용법과 멀티 에이전트 활용 조건

Claude Code에서 여러 세션을 연결해 서로 메시지를 주고받을 수 있게 됐습니다. 2026년 8월 7일 공개된 v2.1.224에 포함된 기능으로, 핵심은 새로운 모델이 아니라 그동안 tmux나 별도 스크립트로 조립하던 세션 간 통신을 Claude Code 내부 도구로 가져왔다는 데 있습니다.

단순히 에이전트를 여러 개 실행하는 것과는 다릅니다. 각 세션이 독립적인 프로젝트, 권한, 대화 이력을 유지한 채 다른 세션에 질문하거나 결과를 넘길 수 있습니다. 따라서 일회성 작업을 나눠 맡기는 기능보다는, 오래 살아 있는 작업자들을 연결하는 구조에 더 가깝습니다.

세션 메시징은 어떤 방식으로 동작하나

핵심 도구는 ListAgents와 SendMessage 두 가지입니다. 각 Claude Code 세션에는 유닉스 소켓이 연결되며, 실측 경로는 /tmp/cc-socks/ 아래입니다. 세션 프로세스 번호가 소켓 파일 이름으로 사용되므로 별도의 중계 서버나 외부 메시지 시스템이 필요하지 않습니다.

세션을 실행한 뒤 /rename으로 이름을 지정하면 그 이름이 다른 세션에서 사용할 주소가 됩니다. ListAgents로 현재 연결 가능한 세션 목록을 확인하고, SendMessage에 상대 이름과 메시지를 넣으면 해당 세션에 cross-session-message 형태로 전달됩니다.

기본 범위는 같은 컴퓨터 안입니다. Remote Control로 연결된 다른 컴퓨터의 세션도 목록에 표시될 수 있지만, 원격 세션은 먼저 메시지를 보내온 경우에만 답장할 수 있는 단방향 조건이 있습니다. 현재 글의 자료 기준으로 macOS와 Linux에서 사용할 수 있습니다.

작업 인수인계에는 컨텍스트 압축보다 명확하다

세션이 길어지면 보통 /compact로 대화 내용을 압축합니다. 이 방법은 기존 세션을 계속 사용할 수 있다는 장점이 있지만, 어떤 정보가 남고 어떤 내용이 사라질지는 사용자가 세밀하게 통제하기 어렵습니다.

세션 메시징을 이용하면 결정사항, 현재 상태, 남은 작업만 직접 정리해 새 세션에 보낼 수 있습니다. 전체 대화 기록을 복사하는 대신 필요한 요약만 전달하므로 받는 세션은 비교적 깨끗한 컨텍스트에서 시작합니다. 프로젝트를 넘겨받는 사람이 꼭 알아야 할 변경 파일, 이미 시도한 방법, 실패한 접근, 다음 확인 항목을 메시지에 명시하는 방식이 적합합니다.

이 구조는 코드 작업뿐 아니라 조사와 문서 작성에도 유용합니다. 예를 들어 조사 세션이 근거를 모으고, 집필 세션이 원고를 작성한 뒤, 리뷰 세션이 문제를 지적하도록 연결할 수 있습니다.

다른 프로젝트의 결정 과정까지 물어볼 수 있다

코드에는 결과는 남아도 왜 그렇게 구현했는지는 충분히 남지 않는 경우가 많습니다. 특정 설정을 선택한 이유나 이전에 검토했다가 버린 대안은 작업 당시의 대화와 판단에 묻혀 있습니다.

이때 해당 프로젝트를 담당했던 세션에 직접 질문하면, 그 세션은 자신이 읽은 코드와 앞선 작업 이력을 바탕으로 답할 수 있습니다. 사용자가 프로젝트 디렉터리를 옮겨 다니거나 대화 기록을 다시 찾지 않아도 되는 셈입니다.

한 단계 더 나아가면 변경 영향이 예상되는 세션에 알림을 보내는 흐름도 만들 수 있습니다. 다만 이것은 자동으로 모든 의존성을 추적해 주는 기능이라기보다, 에이전트가 적절한 시점에 SendMessage를 호출하도록 작업 규칙을 설계해야 하는 영역입니다.

서브에이전트와 Workflow가 다른 이유

세션 메시징은 서브에이전트와 용도가 겹쳐 보이지만 실행 생명주기가 다릅니다. 서브에이전트는 호출된 작업을 처리한 뒤 종료되고, 다음 호출은 대체로 새로운 컨텍스트에서 시작합니다. 반면 독립 세션은 계속 실행되며 앞선 대화와 판단이 누적됩니다.

따라서 결과만 받으면 되는 한 번짜리 조사나 파일 분석에는 서브에이전트가 더 간단합니다. 단계가 정해져 있고 실행·검증·재실행 흐름을 코드로 고정할 수 있다면 Workflow가 관리하기 좋습니다.

	서브에이전트	Workflow	세션 메시징
수명	작업 후 종료	스크립트 실행 동안	계속 살아 있음
맥락	매 호출마다 새로 시작	단계별로 전달	앞선 대화가 누적
맞는 일	일회성 조사·파일 분석	단계가 정해진 실행·검증	역할이 유지되는 협업
권한	호출한 쪽을 따름	스크립트가 정의	세션마다 독립

반대로 리서치, 집필, 리뷰처럼 담당 역할이 계속 유지되고 여러 결과물을 순차적으로 검토해야 하는 작업에는 세션 메시징이 맞습니다. 세 번째 원고를 검토할 때 리뷰 세션이 앞선 두 원고의 맥락을 기억해야 한다면, 매번 새 에이전트를 호출하는 방식보다 지속 세션의 이점이 커집니다.

오케스트레이션과 에이전트 회의 구성

관제 세션 하나가 여러 워커 세션에 작업을 배분하고 결과를 모으는 구조도 가능합니다. 여기서 중요한 점은 단순한 병렬 실행이 아닙니다. 워커마다 다른 프로젝트, 권한, 작업 이력을 유지하면서 관제 세션이 이들을 조율한다는 점입니다.

에이전트 회의

여러 세션을 회의 참가자로 두는 방식도 시도할 수 있습니다. 한 사례에서는 사회자 한 명과 참가자 세 명, 총 네 세션이 논의를 진행했고 두 라운드 만에 합의에 도달했습니다. 참가자 중 한 세션은 상대의 근거를 확인한 뒤 자신의 주장을 11주차에서 12주차로 바꿨습니다.

다만 모델을 여러 개 띄우고 역할 이름만 붙인다고 의미 있는 회의가 만들어지지는 않습니다. 서로 다른 프로젝트 컨텍스트나 역할별 판단 기준을 제공해야 실제 이견이 생길 가능성이 높습니다.

회의를 안정적으로 끝내려면 사회자가 발언 순서를 지정해야 합니다. 자유롭게 메시지를 주고받도록 두면 각 세션이 상대의 응답을 기다리면서 멈출 수 있습니다. 최대 라운드 수와 종료 조건도 미리 정해야 합니다. 매 라운드마다 합의 여부와 남은 이견을 보고하게 하면 회의가 끝났는지 판단하기 쉽습니다.

실제 사용 시 확인할 제한 사항

현재 가장 불편한 부분은 메시지를 보낸 뒤 상대 세션의 진행 상황이 화면에 표시되지 않는다는 점입니다. 상대가 무엇을 하고 있는지는 즉시 보이지 않고, 결과 메시지를 보내야 작업이 끝났음을 알 수 있습니다. 실시간 화면을 함께 보는 방식보다는 비동기적으로 답장을 기다리는 방식에 가깝습니다.

또한 상대 세션에서 권한 확인이나 사용자 선택지가 나타나면 그 지점에서 작업이 멈춥니다. 관제 세션이 대신 승인 버튼을 누르거나 선택을 처리할 수는 없습니다. 한 세션에서 거부된 권한을 다른 세션을 통해 우회하지 못하도록 막은 안전장치로 볼 수 있지만, 자동화 파이프라인에서는 중단 원인이 됩니다.

따라서 세션을 연결하기 전에 각 세션의 권한 범위와 승인 지점을 확인해야 합니다. 특히 여러 프로젝트를 동시에 다룰 때는 메시지를 보낼 대상의 이름을 명확히 정하고, 요청 내용에 작업 범위와 결과 형식을 포함하는 편이 안전합니다. 세션 메시징은 멀티 에이전트 구조를 쉽게 만들지만, 진행 상태 표시나 권한 자동 처리를 해결해 주는 기능은 아닙니다.

이번 변화는 Claude Code에 멀티 에이전트가 처음 등장했다는 의미보다, 외부 도구로 조립하던 연결 계층이 내부 기능으로 들어왔다는 의미가 더 큽니다. 일회성 결과가 필요하면 서브에이전트, 정형화된 실행 흐름이면 Workflow, 각자 다른 이력과 프로젝트를 가진 작업자를 오래 유지해야 한다면 세션 메시징을 선택하는 식으로 구분하면 됩니다.