ADD(Agent-Driven Development)에서의 터미널 — iTerm2에서 cmux까지

요즘 내 개발은 이렇다.

IntelliJ는 env 한번 확인할 때나 켠다. 그 외엔 터미널만 네 개를 띄워놓고 병렬로 일한다. 한 탭에 에이전트한테 시켜놓고, 그 사이 다른 탭으로 넘어가 또 시키고, 돌아와서 결과를 보고, 다시 시키고. IDE가 주인공이던 시절이 있었는데, 어느새 그 자리를 터미널이 가져가 버렸다.

나는 이걸 (멋대로) ADD — Agent-Driven Development라고 부른다. 공식 명칭이나 표준 용어는 아니지만, 그냥 내 작업 방식을 부르는 내 이름이다. 코드를 내가 한 줄씩 치는 게 아니라, 에이전트 여러 개에게 일을 나눠주고 나는 그 사이를 오가며 판단한다.

그러다 깨달았다. 에이전트를 한 개 돌릴 땐 안 보이던 게, 네 개를 돌리니까 보였다.

병목은 코드도, 모델도 아니고 — 터미널이었다.

바뀐 건 터미널이 아니라, 터미널에게 시키는 일이었다. 그 변화를 못 따라온 도구를 하나씩 버리는 과정이 곧 iTerm2 → tmux → cmux 였다.

iTerm2 — 세션을 브라우저 탭처럼

처음엔 으레 그렇듯 iTerm2를 썼다. 터미널부터 내 취향대로 꾸미고(이른바 '터꾸'), 세션을 여러 개 띄워서 브라우저 탭처럼 왔다갔다 했다. 에이전트 하나당 탭 하나.

문제는 개수가 늘면서 시작됐다. 그리고 여기엔 ADD 특유의 사정이 하나 있다 — 클로드는 끊임없이 허락을 구한다. 이 명령 실행해도 될까요?, 이 파일 고쳐도 될까요?, 이거 지워도 될까요?. 에이전트가 한 개일 땐 옆에서 "응, 응" 눌러주면 그만이다. 그런데 네 개가 되는 순간, 네 놈이 제각각 다른 타이밍에 멈춰 서서 내 "예스"를 기다린다.

탭이 네 개니까 어느 탭이 끝났는지, 어느 탭이 "이거 해도 될까요?" 하고 굳어 있는지 알 길이 없었다. 일일이 클릭해서 들어가 봐야 했다. 들어가 보면 한 놈은 30분 전에 일을 끝내고 놀고 있고, 다른 놈은 5분 전부터 권한 하나를 못 받아 그대로 멈춰 있었다. 나는 일을 시키는 사람이 아니라, 네 개의 에이전트 사이를 뛰어다니며 "예스"를 꽂아주는 수동 교환원이 돼 있었다.

탭은 그냥 창일 뿐이었다. 그 안에서 뭐가 벌어지는지는 내가 직접 열어봐야만 알았다. 병렬로 일을 시켜놓고 직렬로 확인하고 있었던 셈이다. 그게 병목이었다.

tmux — 깔자마자 옛날 것이라는 걸 알았다

회사 동료가 cmux를 추천해줬다. 그런데 나는 무슨 바람이 불었는지 비슷한 이름의 tmux를 먼저 깔았다. 터미널 멀티플렉서, 분할, 세션 유지 — 이름값은 했다.

그런데 깔자마자 알았다. 이건 옛날 것이다.

tmux가 나쁜 도구라는 게 아니다. 분할도 되고, 세션도 살아있고, prefix 키 외우면 강력하다. 다만 그건 사람이 보는 화면을 쪼개는 도구지, 에이전트를 위한 구조는 아니었다. 화면을 4분할 해봤자, 결국 각 칸에서 뭐가 벌어지는지는 내 눈이 직접 훑어야 했다. iTerm2의 문제가 그대로 옮겨왔을 뿐, 칸이 더 작아졌다.

게다가 tmux는 유닉스 토박이다. 윈도우에선 네이티브로 안 돈다 — WSL을 깔고 그 안에서 우회하거나, Cygwin 같은 호환 레이어를 거쳐야 한다. 도구 하나 쓰자고 OS를 우회하는 그림에서, 나는 이게 내가 찾던 미래가 아니라는 걸 확신했다.

깔았다가, 바로 지웠다.

cmux — 에이전트가 여러 탭을 한 번에 읽는다

그래서 결국 동료가 처음부터 말한 cmux로 갔다. cmux는 Ghostty 터미널을 품은 데스크톱 앱인데, 결정적으로 에이전트를 돌리려고 만든 멀티플렉서다. 같은 "여러 탭"인데 전제가 다르다.

여러 세션과 탭을 한 데서 관리하는 건 기본이고 — 여기서 처음으로 "아, 이래서 쓰는구나" 했던 건 에이전트가 여러 탭을 한 번에 읽을 수 있다는 점이었다. 한 탭의 에이전트에게 "옆 탭에서 뭐 하고 있는지 보고 맞춰서 작업해"라고 시키면, 그게 된다. 탭이 더 이상 격리된 창이 아니라 에이전트가 가로질러 볼 수 있는 작업 공간이 됐다.

왼쪽 사이드바를 보면 워크스페이스마다 색을 입혀 구분해 뒀다. 초록은 글, 노랑은 디버그, 파랑은 인프라 — 네 개를 동시에 굴려도 어느 게 뭘 하는 칸인지 한눈에 들어온다. iTerm2에서 탭을 일일이 클릭해 확인하던 그 직렬 확인이, 여기선 그냥 사라졌다.

멈추면, 알림이 손을 든다

앞에서 iTerm2의 가장 큰 고통이 "어느 탭이 '이거 해도 될까요?' 하고 멈춰 있는지 모른다"였다고 했다. 멈춘 걸 내가 발견해야 했으니까.

cmux는 이걸 뒤집는다. 에이전트가 권한이 필요한 순간, 알림이 먼저 손을 든다.

git push origin main 실행을 허가할까요? 하고 알림이 뜨는 이 순간이, 솔직히 나는 제일 좋다. 백그라운드에서 조용히 돌던 에이전트가 벽에 부딪히면, 그놈이 나를 부른다. 내가 탭을 돌며 찾아다닐 필요가 없다.

클로드는 위험할 수 있는 동작마다 허락을 구하도록 설계돼 있다 — 그게 안전장치다. 문제는 그 "구함"이 탭마다 흩어질 때다. cmux는 그걸 알림 하나로 끌어올려 준다. 그래서 네 개를 굴려도 무섭지 않다. 발견하던 일이, 알림받는 일로 바뀌었다.

Feed — 손 든 놈들을 한눈에

알림이 하나씩 어깨를 두드리는 거라면, Feed는 그 손든 놈들을 한 목록에 모아 펼쳐준다.

지금 어느 에이전트가 승인을 기다리는지, 누가 질문을 던졌는지, 누가 권한을 요청하는지 — 전부 한 화면이다. 알림이 '푸시(push)'라면, Feed는 '한눈에 내려다보는 관제판(pull)'이다.

이제는 탭을 돌아다니지 않는다. Feed만 본다. "13분 전부터 권한 기다리는 놈", "방금 질문 던진 놈"이 목록으로 쌓이고, 키 하나로 승인하거나 거부한다. 네 개의 에이전트를 직렬로 들여다보던 일이, 하나의 목록을 내려다보는 일로 바뀌었다.

이 한 줄이 cmux를 쓰는 이유의 전부다.

그리고 — 손에 맞게 꾸민다

여기까진 "기능" 얘기지만, 솔직히 매일 들여다보는 도구라면 예뻐야 한다. 이건 편의성이 아니라 지속 가능성의 문제다.

cmux는 Ghostty 기반이라 터미널 꾸미기가 전부 열려 있다. 폰트, 테마, 투명도, 블러 — Ghostty 설정 파일에 쓰던 걸 그대로 쓴다. 테마는 수백 개가 들어 있어서, 명령 한 줄로 갈아끼운다.

위 화면은 라이트 테마(Catppuccin Latte)를 입힌 모습이다. 앞의 어두운 화면들과 같은 cmux라는 게 안 믿길 만큼 분위기가 다르다. 기분 따라, 시간대 따라, 그날 작업 따라 갈아끼우면 된다. 도구를 내 손에 맞추는 이 사소한 자유가, 하루 종일 그 안에서 사는 사람에겐 사소하지 않다.

터미널의 역할이 바뀌었다

정리하면, 내가 도구를 갈아탄 진짜 이유는 성능도 단축키도 아니었다.

터미널의 역할이 바뀌었기 때문이다.

• iTerm2 시절의 터미널은 내가 타이핑하는 창이었다.
• ADD 시대의 터미널은 여러 에이전트를 내려다보는 관제탑이어야 한다.

tmux는 화면을 쪼개는 데까진 갔지만 거기서 멈췄다. cmux는 탭을 에이전트가 가로지를 수 있는 공간으로 만들고, Feed로 모든 에이전트의 상태를 한 곳에 끌어모았다. 내가 직렬로 확인하던 일을, 도구가 병렬로 펼쳐서 보여준다.

에이전트를 한 개 돌릴 땐 어떤 터미널을 쓰든 상관없다. 그런데 네 개를 돌리는 순간, 터미널은 타이핑하는 창에서 관제탑으로 바뀐다. 그 전환을 받아주는 도구가 cmux였고, 나는 당분간 여기 머물 것 같다.