다른 CLI에 작업을 맡기고 싶은데, 보낼 곳이 없다

이 단계에서 만든 것은 tmux-relay입니다. 사용 가능한 tmux pane에 명령을 보내고, task와 role, 완료 신호와 결과를 읽는 경로를 남깁니다. tmux pane은 ‘마우스로 전환해서 들여다보는 창’에서 ‘프로그램으로 호출할 수 있는 worker’가 됐습니다.이전 글에서 아직 이름을 붙이지 않았던 dispatcher입니다.

직접 만들게 된 이유는 사용량 한도에 자주 부딪혔기 때문입니다. 주로 Claude Code를 쓰면서 여러 모델의 요금제를 구독하고 몇몇 API도 연결했지만 여전히 부족했습니다. 그때 처음 든 생각은 더 강한 모델로 바꾸자는 것이 아니라 ‘이런 잡무가 왜 주 에이전트의 context를 차지해야 하지?’였습니다. 당시 context window는 20만 token뿐이었고 1M은 나중에야 열렸습니다. 주 에이전트가 grep 결과를 잔뜩 한 글자도 빠짐없이 읽는 것은 너무 낭비였습니다.

Claude Code가 sub-agent를 내놓았을 무렵 ‘일을 밖으로 넘긴다’는 생각이 처음으로 구체화됐습니다. 하지만 sub-agent는 Claude 내부의 worker라서 Codex나 다른 CLI로 보낼 수 없었습니다. 찾아봤지만 바로 쓸 수 있는 방법은 없었습니다. CLI를 가로질러 작업을 배정하려면 먼저 실제로 실행 중인 terminal에 작업을 보낼 곳이 있어야 하고, 작업이 끝났는지와 결과가 어디 있는지도 알아야 했습니다.

worker는 돌아가지만 서로 말을 못 한다

이 단계에서 보완한 것은 session-channel(이전 글에서도 다뤘습니다). 이를 통해 pane끼리 직접 통신하므로 매번 메시지를 같은 대화로 다시 전달할 필요가 없습니다.

tmux-relay 작업을 배정할 수 있게 되자 바로 다음 문제가 나타났습니다. 한 에이전트가 일을 마쳐도 다른 에이전트에게 알릴 곳이 없었습니다. Claude의 Team Agent는 같은 모델 계열 내부에서만 메시지를 주고받으므로 Codex가 끝낸 일을 Claude 쪽에서 받아볼 수 없었습니다.

로컬 컴퓨터는 바쁜데 다른 컴퓨터 두 대는 놀고 있다

이 단계에서 보완한 것은 fleet으로, 컴퓨터의 성능에 따라 작업을 배정합니다. 그래픽 카드가 달린 Windows는 TTS와 ASR처럼 학습이나 추론이 필요한 일을 맡고, 오래된 Intel MacBook에는 가벼운 작업만 주며, 일상적인 주력 작업은 Mac mini M4에 남겨 둡니다.

작업 배정과 pane 간 통신이 모두 가능해지자 다음 병목은 모델이 아니라 컴퓨터였습니다. 로컬 컴퓨터는 에이전트를 돌리느라 뜨거워졌는데 다른 두 대는 대부분 놀고 있었습니다. 당시 제가 본 몇몇 multi-agent 도구는 대체로 모든 것을 한 컴퓨터에서 실행하도록 되어 있었습니다.

worker의 정의는 fleet 를 보완하고 나서야 완성됐습니다. 처음에는 tmux 안의 다른 pane이라고 생각했지만, 나중에는 다른 모델이나 session, 심지어 다른 컴퓨터도 worker가 될 수 있다는 걸 알았습니다. 여기서 worker는 이전 글의 ‘저렴한 모델을 실행하는 계층’보다 넓은 뜻으로 씁니다.

같은 작업이라도 CLI마다 실행 방법이 다르다

이 단계에서 보완한 것은 cli-rosetta입니다. 각 CLI의 차이를 선언형 registry 하나에 모았고, 2026년 8월까지 Claude Code, Codex, Copilot, Antigravity, Qwen Code, Kimi Code, OpenCode, Hermes, Pi, Grok까지 열 개를 등록했습니다.

worker의 종류를 모두 갖추자 문제의 방향이 바뀌었습니다. 작업은 보낼 수 있지만 같은 작업을 Codex와 Copilot에 맡길 때 headless 실행법, 모델 지정법, 사용 가능한 도구가 전부 달랐습니다. 실행할 CLI를 바꿀 때마다 문서를 다시 뒤져야 했습니다.

cli-rosetta 이 registry는 나중에 plugin으로 묶었고 형식은 Codex CLI의 plugin 규격을 따랐습니다. 요구하는 metadata는 제가 처음 생각한 것보다 훨씬 자세했습니다. 표시 이름, 분류, 기능 목록, 사용자에게 보여 줄 기본 prompt까지 적어야 해서 ‘이게 대체 무엇을 할 수 있는가’를 분명히 설명할 수밖에 없었습니다. 채우고 나니 같은 skill과 command를 Claude Code와 Antigravity에도 설치할 수 있었습니다. 이 여러 단계 중 처음으로 직접 형식을 만들지 않고 남이 정한 규격을 따른 것이었는데, 생각보다 훨씬 많은 수고를 덜었습니다.

같은 종류의 작업이 반복되는데 매번 수동으로 흐름을 짠다

이 단계에서 보완한 것은 agentctl입니다. 일회성 목표와 재실행 가능한 흐름을 나누고 checkpoint, 예산 상한, 권한 게이트, 독립적인 judge를 추가했습니다. 독립적인 judge를 둔 이유는 ‘끝났다고 한다’는 말만으로 검증하지 않기 위해서입니다.

작업을 배정하는 횟수가 늘자 같은 종류의 작업이 반복됐고, 매번 수동으로 흐름을 짜는 것이 점점 비효율적이었습니다. 이 부분을 보완할 당시 workflow라는 개념은 막 논의되기 시작했고, 바로 적용할 수 있는 것은 찾지 못했습니다.

최근에 막혔을 때는 먼저 기존 도구를 찾았습니다

이번 단계에서는 직접 만들지 않았습니다. 2026년 8월에 찾아보니 이전 네 번보다 기존 도구가 많았고 제가 보완한 버전보다 문제를 더 완전하게 해결하고 있었습니다. 그래서 아이디어를 빌려 기존의 것을 보완했습니다.

Claude Squad tmux session과 git worktree로 여러 작업을 격리하고 TUI에서 한꺼번에 관리하고 전환합니다.Herdr 여러 coding agent를 실제 terminal pane에 배치하고, 전경 process와 화면 내용 등 여러 신호로 blocked, working, done, idle 상태를 판단합니다.Orca worktree, agent terminal, diff, browser를 하나의 task 범위에 넣어 완전한 Agent Development Environment를 만듭니다. Claude 공식 서비스도 2026년에 클라우드 remote 모드를 내놓아 작업을 그쪽 컴퓨터에서 직접 실행할 수 있게 했습니다.

작업을 격리하고, 상태를 볼 수 있고, 컴퓨터에서 떠나도 다시 이어서 할 수 있어야 합니다. Claude Squad, Herdr, Orca는 이 문제들을 모두 해결했습니다. 에이전트를 쓰는 방식은 원래 몇 가지로 한정돼 있어서 막히는 지점도 자연히 비슷합니다. 이번에는 운 좋게도 제가 막혔을 때 이미 누군가 만들어 놓았습니다. 따라서 기존 도구를 찾은 뒤에는 ‘무엇을 그대로 가져다 쓸 수 있는가’만 물으면 됐습니다. 범용 terminal 격리, pane 상태 감지, 원격 접속은 남의 도구를 쓰는 편이 직접 다시 만드는 것보다 효율적입니다. 남은 것은 제 작업 습관에 밀접한 규칙들, 즉 서로 다른 모델에 작업을 어떻게 배정할지, CLI 간 의미를 어떻게 맞출지, 긴 작업을 어떻게 검증하고 이어서 실행할지입니다. 아직 꼭 맞는 도구를 보지 못해서 일단 직접 유지하고 있습니다.

작업 배정 쪽은 한 번 더 찾아봤습니다. 2026년 8월 GitHub에서 검색했을 때 이름에 agentmux 가 들어간 repo는 50여 개, amux 가 들어간 repo는 80여 개였고 서로 관련이 없었습니다. 그중 thevibeworks/amux 의 README에는 동기가 적혀 있었습니다. 즉,claude -p 이 추가 과금 방식으로 바뀌어 실제 tmux session으로 대화형 TUI를 구동하고, 사용량을 기존 구독 한도 안에 남겨 두려 했다는 것입니다. 이 글 앞부분에서 막혔던 것과 같은 문제입니다. 제가 실제로 열어 본 것들 중 작업 배정, task 기록, 완료 감지, 결과 읽기 네 가지를 모두 갖춘 repo는 별이 수십 개 이내였고, 여러 개는 업데이트가 끊긴 지 반년이 넘었습니다. 이 분야에서 별이 정말 많은 도구들은 사실 다른 일을 합니다. prompt로 움직이는 에이전트가 직접 키보드를 두드리는 것도 있고, 반대로 AI가 화면을 보며 사람에게 명령을 알려 주는 것도 있습니다.

그래서 이번에는 아이디어를 빌렸지, 새로 한 벌을 만들지 않았습니다

저는 tmux-webui 에 Herdr와 Orca에서 각각 가져온 두 가지를 보완했습니다. Herdr에서는 트리 형태의 pane 상태를 빌려 workspace, tab, pane의 계층을 나열했습니다. 누가 바쁜지, 누가 사람의 확인을 기다리는지, 누가 끝냈는지 한눈에 볼 수 있어 일일이 열 필요가 없습니다. Orca에서는 dash window를 빌려 agent deck과 session log를 한 화면에 놓았고, 탭을 전환할 필요가 없게 했습니다.tmux-webui 원래는 tmux pane을 브라우저로 옮겨, 컴퓨터 앞에 없어도 원래 terminal 화면을 볼 수 있게 하는 한 가지 일만 했습니다.

Orca와 다른 점은 선택입니다. Orca는 완전한 개발 환경을 만들어서 이를 쓰면 작업 인터페이스도 바꾸게 됩니다.tmux-webui 는 별도의 화면 방식을 만들지 않았습니다. deck과 log는 추가된 개요 계층이고, 들어가 보면 여전히 원래 pane에서 실제로 실행 중인 화면이 보입니다. 두 방식 모두 타당하고, 차이는 terminal을 넘겨줄 의향이 있느냐입니다.

operonlab 아래의 tmux 도구 중 계획해서 만든 것은 하나도 없습니다. 모두 구체적인 불편에 부딪혀 보완한 것입니다. 바닥나는 사용량 한도 때문에 tmux-llm-usage을 만들었고, 파악하기 어려운 에이전트 상태 때문에 tmux-agent-status을 만들었으며, 재부팅 뒤 대화 연결이 끊기는 문제 때문에 tmux-agent-resume을, 한 프로젝트에 창을 잔뜩 열어야 하는 문제 때문에 tmux-workdesk을, 컴퓨터 앞에 없으면 pane을 볼 수 없는 문제 때문에 tmux-webui를 만들었습니다. operonlab 아래에서 tmux- 로 시작하는 공개 프로젝트는 이 글을 쓴 2026년 8월에 열세 개였고, session-channel 까지 합치면 열네 개였습니다.

상황을 바꾸면 같은 논쟁이 nginx를 두고 벌어집니다

그래서 제 판단 기준에 한 가지가 더해졌습니다. 그 도구는 정말 더 좋아야지, 단지 더 새로워서는 안 됩니다. 이 생각은 〈I Replaced Nginx With Caddy… And I'm Never Going Back〉라는 영상 아래의 댓글 하나에서 왔습니다.

그 댓글의 ‘20년 동안 존재했다는 것은 단점이 아니라 장점이다’라는 말은 제가 tmux를 두고 마주한 문제와 같은 형태였습니다. tmux도 거의 20년을 살아왔습니다. 인터페이스는 낡았고 설정은 읽기 어렵지만 send-keys 와 capture-pane 같은 기본 요소는 몇 년째 변하지 않았습니다. 바로 그 안정성 덕분에 그 위에 쌓은 것들을 계속 고칠 필요가 없습니다. 새로운 ADE는 worktree, terminal, diff, browser를 한 화면에 모아 훨씬 좋은 경험을 주지만, 그 대가로 전체 작업 인터페이스가 그 도구의 수명 주기에 묶입니다.

연식 자체는 중립적입니다. 같은 20년도 부담이 될 수 있습니다. 아무도 건드리지 못하는 설정 파일, 겹겹이 쌓인 우회책, 왜 이렇게 했는지 이해하지 못하는 후임자가 남을 수 있습니다. 반대로 자산이 될 수도 있습니다. 문제는 이미 수없이 겪어 봤고 코드도 셀 수 없이 review를 받았을 수 있습니다. 차이는 그 시간을 축적에 썼는지, 부채를 떠안는 데 썼는지에 있습니다.

harness를 바꾸는 것은 모델만 바꾸는 일이 아닙니다

결과물의 품질을 결정하는 것은 모델 자체만이 아닙니다.Wisely Chen의 글에서는 이 차이를 수치로 보여 줬습니다. 같은 Kimi K3 모델이 공식 harness인 KCode에서는 59.6%를 기록했지만 오픈 소스 Maka로 바꾸자 69.7%에 도달했습니다. harness는 모델을 감싸는 껍데기가 아니라 실제 성능을 결정하는 변수입니다.

Pi 와 Claude Code는 서로 다른 두 방향을 보여 줍니다. Claude Code는 모델과 harness를 묶어 바로 쓸 수 있고, Pi는 provider와 모델을 바꿀 수 있어 유연하지만 직접 조립해야 합니다.

앞의 단계에서 보완한 것들은 ‘harness는 변수다’라는 말을 한 걸음 더 확장한 것입니다. 모델이 하나일 때 harness는 그 모델이 어떻게 일할지를 결정합니다. 모델이 여럿이면 작업을 어떻게 나누고, 이어 붙이고, 검증할지를 결정할 무언가가 더 필요합니다. 모델마다 잘하는 일이 다르니 기계적인 일괄 수정은 저렴한 모델에 맡겨도 충분합니다.그보다 앞선 글에서 계획, worker, 검증의 세 계층으로 일을 나누어 서로 다른 모델에서 실행한 것이 이 방식의 첫 버전입니다.

직접 보완한 단계들의 청구서는 늦게 왔습니다

먼저 대가를 말해야겠습니다. 그렇지 않으면 이 글이 직접 만들기를 권하는 것처럼 읽힐 수 있습니다. 이 단계들의 유지보수 비용은 조금 늦게 찾아왔습니다. 상위 CLI의 flag가 한 번 바뀔 때마다 cli-rosetta 의 registry를 다시 맞춰야 합니다. Claude Code가 TUI 버전을 바꾸면tmux-webui 의 에이전트가 바쁜지 사람을 기다리는지 판단하는 규칙이 틀릴 수 있습니다. 이 도구들에는 호환성을 지켜봐 줄 커뮤니티가 없으므로 고장 나면 저 혼자 고쳐야 합니다. 오래 쓸수록 유지보수에 드는 노력이 처음 만드는 데 들인 비용을 넘어갑니다.

따라서 상황이 달라지면 결론도 완전히 달라질 수 있습니다. 에이전트를 한두 개만 쓰고 컴퓨터 간 작업 배정도 필요 없다면 Claude Squad나 Orca 같은 성숙한 도구를 바로 고르는 편이 직접 조립하는 것보다 훨씬 효율적입니다. 그런 도구는 유지보수하는 사람이 있지만 제가 보완한 단계들은 그렇지 않습니다.

제가 직접 만든 것은 막힌 지점이 충분히 아팠고 당시에는 마침 쓸 만한 것을 찾지 못했기 때문입니다. 이제 커뮤니티에 답이 많아졌으니 한 단계라도 덜 만들 수 있으면 그렇게 하려 합니다.

먼저 자신의 상황을 가늠한 뒤 직접 만들지 결정하기

아래의 두 판단 도구는 직접 입력해야 결과가 나옵니다.첫 번째는 증상에 따라 어느 단계에서 막혔는지 찾고, 두 번째는 공개된 실측 자료의 기준점 두 개로 이번 작업을 맡기는 것이 경제적인지 추정합니다. 두 계산 모두 브라우저 안에서 이뤄지며 어떤 데이터도 밖으로 보내지 않습니다.

더 읽어 볼 자료