AI 코딩 에이전트를 쓸 때 가장 답답한 건 ‘창을 갈아타는 일’이다. Claude Code가 뭔가 작업하는 동안 코드를 보려면 VS Code로, 결과를 확인하려면 브라우저로, git diff를 보려면 터미널로. 이걸 하루에 수십 번 반복한다.

GeekNews에서 한 개발자(zendy)가 이 문제를 해결하려고 만든 도구를 올렸다. 이름은 Orch term — 터미널·에디터·브라우저·Git을 한 창에 담고, 그 위에서 Claude Code, Codex, Gemini CLI 같은 AI 코딩 에이전트 여러 개를 동시에 돌려 조율하는 데스크톱 앱이다.

처음엔 그냥 “와, 대단하네” 하고 넘길 뻔했다. 그런데 상세 내용을 읽으면서 등골이 오싹해졌다. 이 사람이 설계한 구조가 내가 Drewgent에 심어놓은 것과 거의 같았기 때문이다.

Orch term이 뭘 하는 도구인가

zendy는 혼자 이걸 만들었다. Tauri 2(Rust 백엔드) + TypeScript로 개발했고, 터미널은 xterm.js, 저장소는 SQLite. Windows와 macOS를 둘 다 지원한다. 핵심 기능은 셋으로 요약된다.

올인원 워크스페이스: 화면을 자유롭게 분할(이진 분할 트리)하고 각 칸에 터미널·에디터·브라우저 탭을 섞어 배치. “Space”라는 단위로 작업 묶음을 전환할 수 있다. 멀티 에이전트 오케스트레이션: 각 워커 에이전트를 격리된 git worktree에 띄워 병렬 작업. 한 워커가 막히면 다른 워커에게 위임하고 결과를 되돌린다. 공유 칸반 보드: 각 Space에 칸반식 TODO 보드가 있고, AI 에이전트가 MCP로 이 보드를 직접 읽고 쓴다. 에이전트가 자기 작업 진행 상태를 TODO로 갱신하면, 사람은 그걸 그대로 보면서 조율한다.

그리고 한 가지 더. 앱 안의 AI 에이전트를 로컬 HTTP API(OpenAI 호환)로 노출해서 외부 스크립트·도구가 에이전트를 호출할 수 있게 했다. 모든 요청/응답은 날짜별 감사 로그로 기록된다.

내가 이걸 보면서 느낀 것

이 구조, 내가 6월 한 달 동안 짜놓은 것과 놀랍도록 닮았다.

Orch termDrewgent

워커 에이전트를 git worktree에 격리GJC Coordinator MCP — worktree isolation + tmux 병렬 실행 한 워커 막히면 다른 워커에 위임Kanban pipeline — explorer→implementer→reviewer, 실패 시 자동 escalate MCP로 칸반 보드 읽고 쓰기 (사람↔에이전트 공유)kanban.db를 Discord + opencode로 연결 — 사람과 에이전트의 공통 작업판 로컬 HTTP API로 에이전트 노출opencode serve (:8642) + Discord bot gateway 감사 로그P2-hippocampus/sessions + kanban complete metadata

같은 문제를 겪은 사람이 독립적으로 같은 해결책에 도달했다. 이건 우연이 아니다. 구조 자체가 문제에 강제된 결과다.

왜 이 구조로 수렴하는가

AI 에이전트를 여러 개 돌리다 보면 반드시 마주치는 문제들이 있다.

격리: 에이전트 A가 main 브랜치를 망가뜨리면 에이전트 B도 같이 죽는다. worktree로 격리하지 않으면 병렬 작업이 불가능하다. 조율: 누가 지금 뭘 하고 있는지, 누가 막혔는지, 누가 완료했는지. 중앙에서 추적하지 않으면 엔트로피가 폭발한다. 인터페이스: 에이전트끼리, 그리고 사람과 에이전트 사이에 공통의 소통 채널이 필요하다. Orch term은 MCP + 칸반을, Drewgent는 Discord + kanban.db를 썼다. 감사: 에이전트가 무슨 일을 했는지 모르면, 시스템을 신뢰할 수 없다.

이 네 가지는 ‘있으면 좋은 것’이 아니라 ‘없으면 작동하지 않는 것’이다. 그래서 독립적으로 개발된 두 시스템이 거의 같은 모양으로 수렴한다.

다른 점: 데스크톱 앱 vs 인프라

둘이 닮았지만, 차이가 없는 건 아니다.

Orch term은 데스크톱 앱이다. 화면 분할, 탭 전환, 웹뷰 브라우저 — 모든 걸 하나의 GUI 안에 담았다. zendy는 Tauri의 네이티브 자식 웹뷰를 구현하면서 wry를 직접 패치할 정도로 UI 레이어에 진심이다.

Drewgent는 인프라다. CLI 기반이고, launchd cron으로 24/7 돌아가고, Discord 봇을 게이트웨이로 쓴다. “예쁜 화면” 대신 “절대 안 죽는 파이프라인”을 선택한 쪽이다.

둘 다 옳다. 단지 해결하려는 문제의 스코프가 다를 뿐이다. zendy는 “내가 직접 보고 조작하는 환경”을 만들었고, 나는 “내가 자는 동안에도 돌아가는 환경”을 만들었다.

나에게 던져진 질문

Orch term을 보면서 든 생각 하나: “Drewgent에도 GUI가 필요할까?”

내 대답은 아직은 아니다. 이유는 이렇다:

Drewgent의 핵심 가치는 자율성이다. 내가 없어도 cron이 깨우고, kanban이 분배하고, GJC가 실행한다. GUI는 오히려 “내가 보고 있을 때만 작동한다”는 전제를 강화한다. 하지만 관측(observability) 레이어는 필요하다. 지금은 Discord 알림 + kanban dashboard(Flask) + 로그 파일로 충당하고 있지만, Orch term 같은 시각적 오케스트레이션 뷰는 분명 탐난다.

이건 언젠가 작업할 taste question이다. 지금은 “안 만드는 게 더 나은 것”이지만, 패턴 자체는 기억해둘 가치가 있다.

혼자서도 이걸 만들 수 있다는 것

마지막으로, 이걸 혼자 만들었다는 사실에 감탄했다. Tauri 2의 미성숙한 API, Windows/macOS 크로스 플랫폼 호환성, 한글 IME 입력 버그, alt+tab 복귀 시 중복 입력 — zendy는 이 모든 걸 혼자 디버깅하며 돌파했다.

AI 시대에 솔로 개발자의 무기가 얼마나 강력해졌는지 보여주는 사례다. VS Code보다 무거운 Electron 앱을 만들 필요 없이, Tauri + Rust + TypeScript 조합으로 네이티브 성능의 멀티 에이전트 오케스트레이션 도구를 혼자 출시했다.

리눅스 지원이 아직 없는 건 아쉽지만, 본인도 “혼자 하다 보니 능력이 못 미친다”고 솔직하게 말했다. 이런 솔직함이 오히려 신뢰를 준다.

마치며

Orch term은 멀티 에이전트 오케스트레이션이라는 패턴이 이제 개인 개발자 레벨까지 내려왔다는 신호다. 6개월 전만 해도 “에이전트 여러 개를 동시에 돌린다”는 말은 연구실이나 빅테크 이야기였다. 지금은 한 사람이 Tauri로 만들어서 GitHub Pages에 올리는 수준이 됐다.

나도 Drewgent를 만들면서 느낀 건데, 이 패턴은 모델이 아니라 구조에서 나온다. Claude든 Gemini든 Codex든, 격리된 worktree에서 kanban을 바라보며 작업하는 패턴은 동일하다. 승부는 “어떤 모델을 쓰느냐”가 아니라 “어떤 구조로 조율하느냐”에서 갈린다.

zendy에게 박수를. 그리고 나 자신에게도 — 나 혼자 짜놓은 아키텍처가 틀리지 않았다는, 독립적인 검증을 받은 기분이다.

Orch term 다운로드: zendy00.github.io/orch-term-pages