클로드코드, 텔레그램·디스코드로 옮겨 쓰는 세 갈래 길

공식 기능 Channels가 이미 로컬 세션을 메신저에 연결한다

클로드코드 세션을 텔레그램이나 디스코드 창에서 조작할 수 있느냐는 질문이 클코단 방에서 나왔다. 답은 가능하다, 다만 방법이 하나가 아니다. 앤트로픽이 만든 공식 기능부터 개발자가 직접 짜야 하는 브릿지까지 층위가 나뉘고, 층위마다 안정성과 비용 부담이 다르다.

앤트로픽은 2026년 3월 클로드코드에 Channels라는 기능을 연구 프리뷰로 공개했다. Channels는 클로드코드가 서브프로세스로 띄우는 MCP 서버로, 표준 입출력(stdio)을 통해 세션과 통신한다. 텔레그램 봇이나 디스코드 채널에 메시지를 보내면 이 서버가 받아 로컬 세션에 밀어 넣고, 세션의 응답을 다시 메신저로 돌려보낸다.

연구 프리뷰 단계에서 공식 지원 플랫폼은 텔레그램·디스코드·iMessage 세 곳이다. 슬랙은 아직 포함되지 않았다. 클로드코드 공식 문서는 이벤트를 한쪽으로만 흘리는 원웨이 채널과, 클로드가 답장 도구를 호출해 메시지를 되돌려 보내는 투웨이 채널을 구분해 정의한다. 툴 실행 승인 요청을 원격 기기로 전달하는 권한 릴레이 기능도 같은 문서에 계약으로 담겨 있다.

방에서 쓴다는 슬랙 연동은 공식 기능이 아니다

방 논의에서는 슬랙과 디스코드 TUI에 연동해 쓴다는 사례가 나왔다. 디스코드는 공식 채널로 설명되지만 슬랙은 사정이 다르다. Channels의 연구 프리뷰 허용 목록에는 텔레그램·디스코드·iMessage와 테스트용 페이크챗만 올라 있고, 슬랙은 없다.

슬랙에서 클로드코드를 쓰는 길은 두 갈래다. 하나는 앤트로픽이 2025년 12월 별도로 내놓은 슬랙용 클로드코드 베타다. 슬랙에서 @Claude를 태그하면 그 메시지를 바탕으로 새 세션이 자동으로 열린다. 이미 떠 있는 로컬 세션에 메시지를 밀어 넣는 Channels와는 목적 자체가 다르다. 다른 하나는 직접 만든 채널 서버다. 클로드코드는 MCP SDK로 알림 규격만 맞추면 어떤 플랫폼이든 붙일 수 있도록 계약을 공개해 뒀다. 개발 단계 플래그로 로컬에서 바로 테스트할 수도 있다. 방에서 나온 슬랙 연동 사례는 이 방식으로 직접 짠 브릿지였을 가능성이 크다.

SDK·headless 모드는 다른 문제를 푼다

방에서 나온 또 다른 답은 SDK나 headless 모드였다. 이건 Channels와 성격이 다른 도구다. Channels가 이미 떠 있는 로컬 세션에 말을 거는 다리라면, headless 모드(claude -p)와 클로드 에이전트 SDK는 UI 없이 에이전트 루프 전체를 통째로 실행하는 방식이다.

기존 세션에 말을 거는 게 아니라, 별도 프로그램이 클로드를 불러 완전히 새로운 작업을 처리하고 결과만 받는 구조다. 커스텀 챗봇이나 서버형 자동화, CI 파이프라인에 물릴 때 주로 쓴다. 한 자동화 가이드는 대화형 세션이 미리 읽어 두는 컨텍스트를 headless 모드가 매번 새로 불러오는 탓에, 빈 저장소에서 명령 한 줄만 실행해도 토큰 15만 개 안팎이 소모된 사례를 보고했다. 클로드 에이전트 SDK는 2026년 6월부터 구독 요금과 별도로 월 단위 크레딧이 붙는 종량제로 바뀌었다.

코덱스와 비교하면 구조 차이가 드러난다

오픈AI 코덱스 CLI는 codex app-server라는 별도 프로세스가 JSON-RPC를 표준 입출력이나 웹소켓으로 노출한다. TUI는 이 프로토콜에 붙는 클라이언트 중 하나일 뿐이라, 다른 프런트엔드를 붙이기가 상대적으로 쉬운 구조다. 클로드코드는 엔진과 UI가 하나의 타입스크립트 프로세스 안에 묶여 있어, 외부 창을 붙이려면 Channels 같은 별도 계약이나 SDK가 필요했다.

방에서 함께 공유된 구글 Antigravity의 사이드카 문서도 같은 문제의식을 담고 있다. Antigravity는 백그라운드에서 도는 사이드카 프로세스에 agentapi라는 오픈소스 HTTP API를 붙여, send-message 명령으로 진행 중인 대화에 프롬프트를 밀어 넣는다. agentapi는 코더(Coder)가 만든 프로젝트로, 클로드코드·코덱스·에이더 같은 터미널 기반 에이전트를 터미널 에뮬레이션으로 감싸 똑같은 HTTP API로 다루게 해준다. 클로드코드 전용인 Channels보다 범용적이지만, 공식 지원이나 보안 검증은 그만큼 얕다.

Channels와 커뮤니티형 대안 사이 선택

Channels와 자주 비교되는 대안이 오픈클로(OpenClaw)다. 오픈클로는 텔레그램·디스코드·왓츠앱·슬랙·시그널·iMessage까지 더 많은 플랫폼을 지원하고, 컴퓨터가 잠겨 있어도 계속 돈다. 대신 24시간 켜 둘 전용 장비가 필요하고 보안 관리를 사용자가 직접 떠안아야 한다.

Channels는 반대로 세션이 살아 있을 때만 동작한다. 노트북이 잠들거나 터미널을 닫으면 연결이 끊기고, 그사이 온 메시지는 쌓이지 않고 사라진다. 대신 페어링 코드와 허용 목록으로 보내는 사람을 검증하고, 전용 장비 없이 플래그 하나로 켤 수 있다. 앤트로픽은 오픈클로 같은 서드파티 하네스가 자사 구독 요금제 위에서 도는 것을 정책으로 막아 뒀다. 안정성보다 자유도를 우선하던 오픈클로 진영에서도 설정을 다시 점검하는 분위기가 생겼다.

개인 개발자가 오늘 당장 시도할 수 있는 것

클코단 방에서 나온 결론처럼, 구독형 요금만 있으면 어디서든 클로드에 말을 걸 수 있다는 방향 자체는 맞다. 다만 목적에 따라 고를 방법이 다르다.

출퇴근길에 진행 상황을 확인하고 짧게 답장만 하고 싶다면 Channels로 충분하다. 텔레그램은 봇파더에서 봇을 만드는 절차가 가장 오래 걸릴 뿐, 나머지는 명령어를 복사해 붙이는 수준이라 5분 안팎이면 끝난다. Pro 이상 요금제에서 쓸 수 있고, 팀·엔터프라이즈는 관리자가 먼저 켜 줘야 한다. 세션이 끊기지 않도록 tmux나 screen 위에서 돌리고, 자리를 비울 때 승인이 막히지 않도록 권한 릴레이 기능을 켜 두는 편이 낫다.

슬랙이나 왓츠앱처럼 아직 목록에 없는 채널을 붙이고 싶다면 MCP SDK로 채널 계약에 맞춰 직접 서버를 짜야 한다. 메신저 알림이 아니라 컴퓨터를 켜기만 하면 리포트가 자동으로 만들어져 메신저로 도착하는 완전 자동화를 원한다면, headless 모드나 에이전트 SDK로 별도 프로그램을 짜는 쪽이 맞다. 써본 사람들 사이에서는 이런 조합을 이미 개인 업무 브리핑에 붙여 쓰는 사례가 나온다는 반응도 있다. 다만 이 경로는 구독 요금과 별개로 SDK 크레딧이 소모되고, 컨텍스트를 매번 새로 불러오는 값도 감안해야 한다.

메신저에서 클로드를 부르는 일 자체는 이제 특별한 해킹이 아니다. 남는 건 어디까지 직접 만들고 어디서부터 공식 기능에 맡길지를 정하는 선택뿐이다.