여러 AI 코딩 에이전트를 한 화면에, chatmux는 왜 나왔나

Claude Code, Codex, Cursor CLI를 동시에 켜놓고 작업하는 개발자가 늘면서 여러 터미널 창을 하나로 묶어주는 도구가 잇따라 나오고 있다. 최근 커뮤니티에 공유된 chatmux도 그 흐름 위에 있는 프로젝트다. tmux에서 이미 돌아가는 여러 코딩 에이전트 세션을 브라우저 하나에 모아 보여준다. 아직 정리 중인 초기 저장소지만 왜 지금 이런 도구가 필요해졌는지, 화면 하나에 몰아넣는 방식이 실제로 도움이 되는지를 짚어봤다.

이미 열려 있는 여러 창을 왜 또 묶으려 하나

Anthropic은 2026년 2월 6일 Opus 4.6과 함께 Claude Code에 Agent Teams 기능을 내놓았다. 여러 Claude 에이전트가 작업을 나눠 맡고 서로 메시지를 주고받는 기능이다. 화면을 나눠 보여주는 방식으로는 tmux와 iTerm2를 공식 백엔드로 채택했다. ~/.claude/settings.json에서 teammateMode를 tmux로 지정하면 팀원마다 독립된 pane을 갖는다. 클릭하면 바로 개입할 수 있다.

문제는 이 방식이 아직 거칠다는 점이다. 기존 tmux 창을 갈라서 팀원을 새로 띄우다 보니 사용자가 짜둔 레이아웃이 깨진다. 여러 에이전트가 동시에 시작될 때 입력이 꼬이는 문제도 깃허브 이슈로 올라와 있다. chatmux는 이 틈을 메우려는 쪽에 가깝다. Gajae Code, Claude Code, Codex CLI, Cursor CLI, OpenCode, Oh My Pi 등 tmux에서 이미 실행 중인 에이전트 세션을 별도 등록 없이 자동으로 찾아내 사이드바에 띄운다. 알아본 세션은 구조화된 대화로 보여주고 나머지는 원시 터미널 그대로 띄운다. 둘 다 입력이 가능해서 필요하면 터미널로 바로 내려가 명령을 칠 수 있다.

chatmux는 왜 Rust로 만들어졌나

방에서 개발자는 Rust를 고른 이유로 속도와 메모리 사용량을 들었다. 근거 없는 이야기는 아니다. 저장소를 보면 native/chatmux-core라는 이름으로 Rust 코어가 따로 있고, 그 위에 TypeScript로 짠 웹 인터페이스가 얹혀 있다. 이런 구조를 쓰는 이유는 chatmux가 하는 일의 성격과 맞닿아 있다. 여러 tmux pane의 출력을 실시간으로 붙잡아 파싱하고 세션 상태를 계속 감시하는 데몬을 사용자 systemd 서비스로 상시 띄워두는 구조다. 이런 백그라운드 프로세스는 CPU와 메모리를 적게 먹을수록 실사용 부담이 준다.

Node.js 기반 도구가 많은 이 카테고리에서는 흔치 않은 선택이다. 그 구조 자체가 실행 속도보다 상주 메모리 절감에 무게를 둔 선택임을 보여준다.

아직 정리 중인 저장소, 개발자가 남긴 말

방에 링크가 올라왔을 때는 마침 저장소를 정리하고 리뷰하던 시점이라 한동안 접근이 매끄럽지 않았다. 개발자는 아직 쓸 만한 사용 사례가 더 쌓여야 한다고 인정했다. 문제가 생기면 직접 제보를 받겠다는 뜻도 밝혔다. 취재 시점 기준으로 저장소는 스타 10여 개, 포크 5개, 커밋 200여 개 규모로 이제 막 형태를 갖춰가는 프로젝트다.

라이선스는 AGPL-3.0이다. 수정한 코드를 네트워크 서비스로 내놓을 때만 소스 공개 의무가 발생한다고 자유소프트웨어재단(FSF)은 설명한다. 로컬 컴퓨터에 그대로 설치해 혼자 쓰는 개인 개발자나 소규모 팀 입장에서는 이 의무가 사실상 걸리지 않는다. 코드를 고쳐서 다른 사람들에게 서비스로 열어줄 때만 신경 쓰면 된다.

이미 여럿 나와 있는 비슷한 도구들

tmux 위에 코딩 에이전트를 몰아넣는 시도는 chatmux 하나만이 아니다. ccmux는 이미 켜져 있는 세션을 그대로 인식해 전환·위임하는 백그라운드 데몬과 TUI를 제공한다. tmux와 git worktree를 묶은 Claude Squad는 SSH로 접속한 서버에서도 문제없이 돌아가도록 설계됐다. Conductor는 격리된 작업공간에서 여러 에이전트를 동시에 굴리고 결과를 리뷰·병합하는 데 초점을 맞췄고, agent-dashboard는 tmux capture-pane 위에 제어판을 얹어 PWA로 브라우저 알림까지 지원한다.

이런 도구가 한꺼번에 쏟아지는 배경에는 Anthropic이 tmux를 공식 채택하면서 생긴 표준화 효과가 있다. 에이전트를 다루는 방식이 제각각이던 시절과 달리 이제는 tmux pane 하나가 곧 에이전트 하나라는 규약이 자연스럽게 자리 잡았다.

chatmux는 이 붐비는 카테고리에 자동 감지와 모바일 PWA를 앞세워 뒤늦게 뛰어든 쪽에 가깝다. 등록 절차 없이 이미 떠 있는 세션을 그대로 찾아내는 방식은 다른 도구들도 채택하는 방향이다. 차별화 지점은 아직 뚜렷하지 않다.

화면 하나로 몰아넣는 게 실제로 편한가

여러 에이전트를 한 화면에 모으는 목적은 어디서든 확인하고 개입하려는 데 있다. chatmux는 Tailscale 로그인이나 LAN 비밀번호로 휴대폰에서도 접속하도록 설계됐다. 백엔드는 루프백에만 열어두고 HttpOnly·SameSite=Strict 쿠키로 접근을 관리하며, tmux 프로세스 계층을 확인해 세션을 검증하는 절차도 뒀다.

편의가 늘어난 만큼 대가도 따른다는 반응은 이 카테고리 전반에서 공통적으로 나온다. 보스턴컨설팅그룹(BCG) 컨설턴트들은 AI 도구를 감독하는 데 쓰는 시간이 늘면서 생기는 탈진 상태를 'AI 브레인 프라이'라 부른다. 침대에서도 세션을 열어보고 알림이 오면 바로 확인하게 되면서 업무와 일상의 경계가 흐려졌다는 경험담도 적지 않다. 에이전트 서너 개를 동시에 굴리다 보면 어느 터미널이 무슨 브랜치를 작업 중인지 놓치기 시작한다는 의견도 있다.

방에서 나온 '유즈케이스가 더 쌓여야 한다'는 말은 겸손한 인사치레가 아니라 이 도구들이 공통으로 처한 상황이기도 하다. 세션을 한 화면에 모으는 기술은 이미 여럿 나와 있지만, 그렇게 모아놓은 다음 무엇을 어떻게 위임해야 할지 답은 도구 쪽에도 쓰는 사람 쪽에도 아직 없다. chatmux가 그 답을 먼저 찾아낼지는 제보로 쌓일 다음 몇 달의 사용 사례에 달려 있다.