더 많은 글은 radarlog.kr에서.
MCP만으로는 부족했다.
Claude Code에 MCP가 붙으면서 세상이 많이 바뀌었다. 클로드가 직접 GitHub에 커밋을 치고, Slack에 메시지를 보내고, DB를 조회한다. 근데 이 모든 게 한 방향이다. 클로드가 도구를 호출하는 것. 클로드가 "나 이거 해야 하니까 도구 줘"라고 요청하는 구조다.
그런데 반대 방향은? 외부에서 클로드한테 "야, 이거 해"라고 던지는 건?
그게 없었다.
...정말로?
사실 가능은 했다. 근데 그게 문제다.
Claude Code는 오픈소스다. 소스를 뜯을 수 있다. 그 말은 stdin 파이프라인을 뚫거나, 웹소켓 리스너를 직접 붙이거나, 포크해서 외부 입력을 받게 개조하는 게 이론적으로 가능하다는 뜻이다.
실제로 오픈소스 커뮤니티에서 비슷한 시도가 있었다. 텔레그램 봇을 Claude Code 프로세스에 붙여서 원격 제어하는 해킹 같은 구현들. 되긴 된다.
근데 이건 비공식 모드다.
업데이트가 나올 때마다 머지 충돌이 터진다. 보안은 온전히 본인이 챙겨야 한다. 다른 사람이 갖다 쓰려면 같은 삽질을 또 해야 한다. 플러그인 생태계? 없다. 그냥 각자 포크해서 각자 고치는 거다.
게임 개발자라면 이 상황이 익숙하다. 메모리 후킹으로 모드를 만들던 시대. 됐다. 근데 게임 패치 나올 때마다 깨졌다. 오프셋 바뀌면 처음부터 다시 찾아야 했다. 그래서 공식 Mod SDK가 나온 거다. 할 수 있었던 걸 "해도 되는 것"으로 만든 거다.
Channels가 정확히 그거다. 플러그인 설치 한 줄, 설정 몇 줄이면 끝나는 공식 인터페이스. 표준화된 이벤트 주입 경로. 보안 정책이 내장돼 있고, 업데이트에도 깨지지 않고, 남이 만든 플러그인을 그냥 가져다 쓸 수 있다.
# 오픈소스 해킹 방식
git clone claude-code → 소스 수정 → stdin 파이프 구현 → 보안 직접 구현 → 업데이트마다 rebase
# Channels 공식 방식
/plugin install telegram@claude-plugins-official → claude --channels plugin:telegram@claude-plugins-official → 끝
이 차이가 "가능하다"와 "실용적이다" 사이의 간극이다.
게임 개발자라면 바로 이해되는 구조
게임 서버를 만들어본 사람이라면 이 구조가 익숙하다.
MCP는 클라이언트가 서버에 RPC를 요청하는 패턴이다. 클라이언트(클로드)가 필요할 때 서버(외부 도구)를 호출한다. REST API 콜이랑 같다. 요청이 있어야 응답이 온다.
[Claude] ---RPC 요청---> [GitHub API]
[Claude] ---RPC 요청---> [Slack API]
[Claude] ---RPC 요청---> [DB]
Channels는 정반대다. 서버가 클라이언트에게 이벤트를 푸시하는 패턴. 게임에서 서버가 클라이언트한테 "몬스터 스폰됐어", "매칭 잡혔어" 하고 밀어넣는 그 구조다. Socket.IO로 치면 socket.emit('event', data)를 외부에서 클로드 세션으로 쏘는 거다.
[Telegram] ---이벤트 푸시---> [Claude 세션]
[CI 서버] ---이벤트 푸시---> [Claude 세션]
[Discord] ---이벤트 푸시---> [Claude 세션]
UE5로 비유하면 더 와닿는다. MCP는 ServerRPC — 클라이언트가 서버에 요청을 보내는 거다. Channels는 ClientRPC — 서버가 클라이언트한테 명령을 내리는 거다. 게임 넷코드를 짜본 사람이라면 이 두 방향이 왜 둘 다 필요한지 본능적으로 안다.
한쪽만 있으면 절반짜리다. MCP만 있던 시절이 딱 그랬다.
Channels가 뭘 바꾸는가
핵심은 하나다. 클로드 세션이 리스너가 된다.
기존에는 내가 터미널 앞에 앉아서 클로드한테 말을 걸어야 했다. "이 파일 수정해줘", "테스트 돌려줘". 내가 없으면 클로드도 멈춘다. 이벤트 루프가 돌고 있긴 한데, 입력이 없으니 아무것도 안 하는 상태.
Channels를 켜면 클로드 세션에 외부 이벤트 리스너가 등록된다. 텔레그램 봇이 연결되면, 텔레그램에서 메시지가 올 때마다 클로드가 그걸 프롬프트로 받아서 실행한다. 내가 터미널 앞에 없어도 된다.
# 채널 기능 활성화와 함께 세션 시작 (Bun 런타임 필요)
claude --channels plugin:telegram@claude-plugins-official
이 한 줄이면 클로드 세션이 텔레그램으로부터 외부 입력을 받을 준비가 된다. 내 폰에서 텔레그램으로 "auth 모듈 테스트 돌려줘"라고 보내는 순간 로컬 머신의 클로드가 테스트를 돌린다. 단, 세션이 떠 있는 동안만 동작한다. 아직 백그라운드 데몬은 없다.
게임 서버로 치면 Dedicated Server가 24시간 떠 있고, 외부에서 커맨드를 원격으로 쏘는 것과 같다. RCON(Remote Console)을 열어둔 셈이다.
뭐가 가능해지는가
방향이 뒤집히면 할 수 있는 게 완전히 달라진다.
CI/CD 파이프라인 연동. 빌드가 실패했다. 기존에는 내가 로그를 보고, 원인을 파악하고, 클로드한테 "이 에러 고쳐줘"라고 말해야 했다. Channels가 있으면 CI 서버가 실패 로그를 직접 클로드 채널에 던진다. 클로드가 로그를 분석하고, 수정 제안을 만들고, 내 텔레그램으로 "이거 수정하면 될 것 같은데 적용할까?"라고 물어본다. 내가 한 건 폰에서 "ㅇㅇ"이라고 답한 것뿐이다.
[CI 빌드 실패] → [에러 로그를 Claude 채널에 푸시]
→ [Claude가 분석 + 수정 코드 생성]
→ [Telegram으로 "적용할까?" 확인]
→ [개발자가 "ㅇㅇ" 답장]
→ [Claude가 로컬에서 코드 수정 + 커밋]
모바일 원격 코딩. 퇴근 후 카페에서 폰만 들고 있는데 갑자기 버그 리포트가 올라왔다. 노트북을 꺼낼 필요 없다. 텔레그램 봇에 "UserService.cpp 237번째 줄 null 체크 빠진 거 수정해줘"라고 보내면 된다. 집에 켜둔 PC의 클로드 세션이 해당 파일을 열고 수정한다.
이전에는 상상만 했던 시나리오다. SSH 터널 뚫고, tmux 세션 붙고, 모바일 터미널 앱에서 한 글자씩 쳐야 했다. 이제는 카카오톡 보내듯이 지시를 날린다.
팀 협업 채널. 여기가 진짜 재밌는 부분이다. 팀 공용 개발 서버에 클로드 세션을 하나 띄워놓고, 팀원들이 공유 채널을 통해 작업을 지시한다. "프론트에서 쓸 API 스펙 만들어줘", "이 테스트 케이스 추가해줘". 클로드가 하나의 코드베이스를 보면서 여러 사람의 요청을 처리한다.
게임 개발에서 비유하면, 공용 빌드 머신에 원격 콘솔을 열어둔 것이다. 아티스트가 "이 텍스처 리사이즈 스크립트 돌려줘"라고 던지고, 기획자가 "밸런스 테이블 검증해줘"라고 던지고, 프로그래머가 "이 함수 리팩터링해줘"라고 던진다. 클로드가 큐에 넣고 순서대로 처리한다.
MCP + Channels = 양방향 완성
MCP와 Channels를 같이 놓고 보면 그림이 완성된다.
MCP (아웃바운드): Claude ---요청---> 외부 도구
Channels (인바운드): 외부 서비스 ---이벤트---> Claude
게임 넷코드에서 ServerRPC와 ClientRPC가 둘 다 있어야 제대로 된 멀티플레이어가 되는 것처럼, 클로드도 이제 양방향 통신이 된다. 요청도 하고, 요청도 받는다.
LAMDiceBot을 만들 때 Socket.IO로 양방향 통신을 구현한 기억이 난다. 서버가 클라이언트한테 주사위 결과를 푸시하고, 클라이언트가 서버한테 배팅을 요청하고. 한쪽만 있으면 게임이 안 된다. 양쪽이 있어야 실시간 인터랙션이 완성된다.
클로드도 마찬가지다. MCP만으로는 "내가 시키면 하는" 도구였다. Channels가 붙으면서 "스스로 이벤트를 받고 반응하는" 에이전트에 한 발 더 가까워졌다.
보안은 어떻게 되는가
원격으로 내 로컬 머신의 클로드에 명령을 쏠 수 있다는 건, 잘못되면 아무나 내 코드를 건드릴 수 있다는 뜻이다. 당연히 신경 써야 한다.
Channels에는 액세스 정책(access policy) 설정이 있다. 텔레그램 예시로 보면 allowlist 방식으로 허용된 사용자만 접근 가능하게 잠근다.
/telegram:access policy allowlist
페어링 코드 방식도 있다. 클로드 세션이 생성한 일회용 코드를 텔레그램 봇에 입력해야 세션이 연결된다. 코드를 모르면 연결 자체가 안 된다. 게임 서버의 RCON 패스워드와 비슷한 개념이다.
그래도 프로덕션 환경에서 쓸 때는 주의가 필요하다. 클로드 세션이 sudo 권한을 가진 채로 외부 입력을 받으면 위험하다. 최소 권한 원칙은 여기서도 적용된다. 게임 서버 운영할 때 RCON을 아무 포트에 열어두지 않는 것처럼.
2편 예고
이번 글에서는 Channels가 뭔지, 왜 필요한지, 뭘 할 수 있는지를 다뤘다. 다음 편에서는 진짜로 손을 더럽힌다.
텔레그램 봇을 BotFather로 만들고, 플러그인을 설치하고, 토큰을 등록하고, 보안을 걸고, 페어링까지 — 실제로 작동하는 채널을 처음부터 끝까지 세팅한다. 커스텀 채널을 직접 구축하는 방법도 다룬다.
"MCP가 손이었다면, Channels는 귀다. 이제 클로드가 듣는다."
Top comments (0)