세션 간 메시징

영상이 시킨 대로 하면 제 PC에서는 무조건 실패합니다 — 그리고 그게 이 편의 시작일 뿐입니다. 1분 53초짜리 릴이 Claude Code 세션끼리 메시지를 주고받는 기전을 파일시스템에서 직접 파냈습니다. 소켓 디렉터리 하나가 곧 세션 목록이라는, 꽤 깔끔한 발견입니다. 다만 영상은 자기가 어느 OS에서 찍었는지 한 번도 말하지 않았고, 그 경로는 Windows에 없습니다. 명명 파이프 600개를 전수 조회해서 세션 소켓 0개를 확인했습니다. 그런데 정작 제가 원했던 것 — 세션끼리 대화하고 남의 세션 로그를 읽는 것 — 은 이 PC에서 이미 라이브였고, 그걸 확인하는 과정에서 제 판정이 두 번 뒤집혔습니다.

무엇을 주장한 영상인가

Claude Code v2.1.224에서 세션끼리 직접 메시지를 주고받는 기능이 열렸다는 것, 그리고 그 사실을 발표문이 아니라 파일시스템을 직접 뒤져 확인했다는 것이 골격입니다. 화면은 ls -la /tmp/ 로 시작해 /tmp/cc-socks/ 를 찾아내고, 소켓 3개를 보여주고, 권한이 소유자 전용인 것을 짚고, 버전 2.1.223에서는 소켓이 0개라는 대조까지 보여줍니다.

그리고 반전이 하나 있습니다. 완전히 없던 기능이 생긴 게 아닙니다. 메시지 전송 도구 자체는 145일 전부터 서브에이전트 재개용으로 존재했고, 2.1.224가 새로 연 것은 도달 범위입니다 — 서브에이전트 안에서만 닿던 것이 독립 세션까지 닿게 됐습니다. “기능이 아니라 경계가 움직였다” 는 프레이밍은 정확합니다. 실제로 지금 이 세션의 도구 목록에도 그 도구가 독립적으로 존재합니다.

화면에 뜬 공식 문서 원문은 이렇습니다.

When a change in one session breaks what another is building on, Claude can warn that session before you notice.

그 전까지 왜 안 됐는지도 이슈 원문으로 보여줍니다 — “Sessions are completely isolated, even when running on the same machine working on the same codebase.”

영상을 깨본 결과

치명적 누락은 플랫폼입니다. 영상은 /tmp/cc-socks 를 아무 전제 없이 제시하고, macOS나 Linux라고 한 번도 말하지 않습니다. Windows에는 /tmp 가 없고, Node가 경로를 리슨하면 파일이 아니라 명명 파이프가 됩니다. “터미널 열고 ls /tmp/cc-socks 쳐보세요” 를 그대로 따라 한 Windows 사용자는 무조건 실패합니다.

날짜 산술이 이틀 다 +1일씩 밀려 있습니다. 144일을 145일로, 139일을 140일로 적었습니다. 시작일 포함 계산으로 보이고 결론은 안 바뀝니다. 다만 “직접 실측했다” 를 간판으로 건 콘텐츠라 정확도 표본으로는 남습니다.

제일 약한 고리는 「다른 머신까지」입니다. 영상이 슬라이드로만 주장하는데, 유닉스 도메인 소켓은 로컬 전용이라 원격은 다른 기전이어야 합니다. 그 기전을 제시하지 않았습니다. 공식 문서 URL·이슈 실재 여부·릴리스 노트 기재 여부도 화면 캡처만 봤고 1차 출처로 대조하지 않았습니다 — 인용할 때는 여기까지 한정해야 합니다.

내 환경에 대봤다

기능 코드는 Windows 빌드에 실려 있는데 런타임에 안 뜹니다. 실행 파일 안에 세션 목록 조회 도구의 문자열이 세 번 나오고, CLI 버전도 게이트를 넘습니다(2.1.226). 그런데 그 CLI 프로세스가 두 개 떠 있는 상태에서도 소켓도 파이프도 0개였습니다. 한정을 붙이면 “Windows에서 영원히 안 된다” 가 아니라 “이 날짜 이 PC에서 관측되지 않는다” 입니다.

그리고 제가 물었던 것은 이미 답이 있었습니다. 질문은 “세션끼리 대화 가능하지 않을까, 실시간 로그 보듯이” 였는데, 그 기능은 소켓이 아니라 데스크톱 앱의 세션 관리 도구 다섯 종에 이미 있었습니다. 다른 세션 목록을 보고, 다른 세션의 트랜스크립트를 그대로 읽고, 전 세션 본문을 전문검색하고, 다른 세션에 메시지를 배달합니다. 파일 로그를 tail 하는 것보다 한 단계 위입니다 — 로그가 아니라 대화 자체를 읽습니다.

판정 — 그리고 제가 두 번 틀렸습니다

첫 번째 오판: “자는 세션은 못 깨운다.” 도구 설명을 읽고 “클로드 세션은 턴이 끝나면 자니까 진짜 빈틈은 트리거다” 라고 적었습니다. 확인하려고 대역 외 오라클을 썼습니다 — 배달됐는지가 아니라 실행했는지를 봐야 하니까, 대상 세션에 파일 하나를 쓰게 시키고 그 파일을 제가 직접 확인했습니다. 결과는 사람 개입 0으로 idle 세션이 스스로 깨어나 실행. 판정이 뒤집혔습니다. 푸시가 되는데 폴링용 게시판을 깔 이유가 없습니다.

두 번째 오판: “메시지가 사람이 친 것으로 위장된다.” 인젝션 통로가 된다고 적었는데, 수신 세션의 원문을 직접 열어 보니 발신 세션 ID와 제목이 명시된 봉투에 담겨 옵니다. 사용자 턴으로 도착하는 건 맞지만 출처가 라벨링되어 있어서, 수신 측이 “이건 채팅이 아니라 다른 세션에서 온 것” 이라고 정확히 판별했습니다.

그리고 예상 못 한 게 둘 나왔습니다. 수신 세션이 시키는 대로 하면서 스스로 게이트를 걸었습니다 — 로컬 임시 파일 쓰기는 그냥 했지만, 바깥으로 나가는 발신은 사람 승인 없이는 안 하겠다고 멈췄습니다. 위험도로 등급을 가른 겁니다. 방향은 옳지만 ⚠ 이건 모델의 판단이지 코드로 강제된 경계가 아닙니다 — 다른 세션은 순순히 응할 수 있습니다.

두 번째가 더 중요합니다. 이 채널의 실전 실패 모드는 보안이 아니라 오배송이었습니다. 제가 보낸 메시지에서 수신 세션이 오류를 두 개 잡아냈습니다 — 날짜를 하루 착각한 것, 그리고 답장 대상을 지목하면서 제 세션 제목을 잘못 기억한 것. 그대로 따랐다면 엉뚱한 세션으로 갔습니다. 발신자가 자기 자신을 잘못 식별할 수 있다는 게 이 채널의 진짜 위험이고, 수신 측 검증이 없었으면 오배송이 났습니다.

안	판정
세션 인수인계를 기존 도구로 처리	채택 · 즉시. 구축 비용 0
세션 전용 파일 버스 신규 구축	기각. 채널이 이미 넷인데 푸시까지 되면 게시판은 불필요
폴링 데몬 · 무인 상시 루프	기각. 푸시가 되는데 폴링할 이유가 없다
영상 절차 재현 시도	기각. 런타임에 안 뜬다
세션 간 수신 지시를 안전 경계에 등재	신규 검토. 수신 측 게이트가 코드 강제가 아니라 재현 미보장

이 편에서 값을 치른 교훈 하나만 남기면 — 도구 설명을 읽고 내린 판정은 실측 한 번에 뒤집힙니다. 두 번 다 그랬습니다. 그리고 뒤집힌 판정을 지우지 않고 남겨 두는 편이, 다음에 같은 자리에서 같은 추정을 하는 걸 막아 줍니다.