AI 에이전트 여러 개를 한 화면에서 지휘하기 — tmux 기반 오픈소스 agent-manager

AI 코딩 에이전트한테 작업을 맡겨본 분들은 다 아실 텐데요. Claude Code 같은 도구에 일을 시키면 몇 분씩 혼자 코드를 읽고 고치는 동안 사람은 멀뚱멀뚱 기다리게 되잖아요. 그래서 요즘 파워 유저들 사이에서는 '기다리지 말고 에이전트를 여러 개 동시에 돌리자'는 흐름이 확실하게 자리 잡았는데요. 이번에 소개할 agent-manager는 딱 그 흐름에서 나온 오픈소스 도구예요. tmux 위에서 Claude Code, Codex, OpenCode 같은 CLI 코딩 에이전트들을 여러 개 띄워놓고 한 화면에서 관리하게 해주는 TUI거든요.

tmux랑 TUI, 이게 뭐냐면요

먼저 용어부터 짚고 갈게요. tmux는 '터미널 멀티플렉서'라는 도구인데, 쉽게 말해 터미널 하나를 여러 개의 가상 창으로 쪼개서 쓰게 해주는 프로그램이에요. 창을 쪼개는 것보다 더 중요한 능력은 '세션 유지'인데요. tmux 안에서 돌던 작업은 터미널을 꺼도, SSH 연결이 끊겨도 백그라운드에서 계속 살아 있어요. 그리고 TUI는 Terminal User Interface의 약자로, 마우스로 클릭하는 GUI 대신 터미널 안에서 키보드로 조작하는 인터페이스를 말해요. htop이나 lazygit 써보셨다면 바로 감이 오실 거예요.

왜 이런 도구가 필요해졌을까

에이전트를 두세 개만 병렬로 돌려도 금방 문제가 생기거든요. 터미널 창이 대여섯 개로 늘어나면 어느 창에서 무슨 작업을 시켰는지 헷갈리기 시작하고, 어떤 에이전트가 '이 명령 실행해도 될까요?' 하고 승인을 기다리며 멈춰 있는지 놓치기 일쑤예요. 에이전트 하나가 10분째 놀고 있는데 모르고 있었다면 병렬화의 의미가 없죠. agent-manager 같은 도구는 이 지점을 파고들어요. 흩어진 에이전트 세션들을 목록으로 한눈에 보여주고, 키 몇 번으로 세션 사이를 오가게 해주는 일종의 관제탑 역할을 하는 거예요. 특히 이 도구는 특정 회사 제품에 묶이지 않고 Claude Code, Codex, OpenCode를 모두 지원한다는 점이 눈에 띄어요. 에이전트마다 잘하는 게 달라서 섞어 쓰는 분들이 많아진 요즘 상황에 잘 맞는 설계죠.

병렬 작업의 진짜 핵심은 '격리'예요

여기서 하나 꼭 알아둬야 할 게 있는데요. 에이전트 여러 개를 같은 폴더에서 동시에 돌리면 서로 파일을 고치다가 충돌이 나요. 그래서 병렬 에이전트 워크플로우에는 보통 git worktree가 같이 등장해요. 이게 뭐냐면, 저장소 하나를 여러 개의 독립된 폴더로 동시에 체크아웃하는 git 기능이에요. 브랜치 A는 폴더 A에, 브랜치 B는 폴더 B에 펼쳐놓고 각 에이전트에게 방을 하나씩 내주는 거죠. 이렇게 하면 에이전트끼리 발을 밟을 일이 없고, 결과물은 나중에 브랜치 머지로 합치면 돼요. tmux 기반 매니저와 worktree 격리를 합치면 혼자서도 작은 개발팀을 지휘하는 듯한 워크플로우가 만들어져요.

업계 흐름에서 보면

이런 오케스트레이션 도구는 요즘 정말 쏟아지고 있어요. tmux 세션으로 에이전트를 관리하는 Claude Squad, 칸반 보드 형태로 에이전트 작업을 배치하는 Vibe Kanban 같은 프로젝트들이 비슷한 문제를 각자의 방식으로 풀고 있거든요. 재미있는 건 무게중심의 이동이에요. 한동안은 Cursor처럼 IDE 안에 AI를 넣는 방향이 대세였는데, 에이전트가 점점 자율적으로 오래 일하게 되면서 'IDE 화면을 지켜볼 필요가 없다면 굳이 IDE일 이유가 있나?'라는 질문이 나왔고, 터미널 기반 에이전트와 그 위의 관리 레이어가 새로운 격전지가 된 거예요. 에디터가 아니라 '에이전트 함대 지휘소'가 개발자의 메인 화면이 될 수 있다는 거죠.

한국 개발자에게 주는 시사점

당장 써볼 수 있느냐 하면, tmux에 익숙하다면 진입장벽은 낮아요. 오히려 이 기회에 tmux를 배워두는 걸 추천하고 싶어요. 에이전트 시대에 다시 몸값이 오른 20년 된 도구거든요. 그리고 더 본질적인 변화는 일하는 방식이에요. 에이전트를 병렬로 굴리려면 작업을 서로 안 겹치는 독립적인 단위로 쪼개는 능력이 필요한데, 이건 사실 좋은 시니어가 팀원에게 일을 나눠주는 능력과 같아요. 코드를 치는 속도보다 일을 설계하고 결과물을 리뷰하는 속도가 병목이 되는 시대가 오고 있는 거죠.

정리하면, agent-manager는 'AI 에이전트 여러 개를 어떻게 지휘할 것인가'라는 새로운 문제를 tmux라는 검증된 도구 위에서 풀어낸 사례예요. 여러분은 에이전트를 몇 개까지 동시에 굴려보셨나요? 병렬로 돌릴 때 쏟아지는 결과물 리뷰는 어떻게 감당하고 계세요?