도입 — 한 터미널에 AI 한 대로는 부족하다
Claude Code, Codex, Gemini CLI 같은 코딩 에이전트를 매일 붙여 쓰는 개발자라면 한 번쯤 부딪히는 벽이 있습니다. "터미널 하나에 에이전트 하나"라는 1:1 모델이 실제 작업 흐름과 맞지 않는다는 점입니다. 백엔드 코드 리뷰는 codex에게 맡기면서 동시에 프론트엔드 리팩토링은 claude에게 부탁하고, 그 사이 git 변경분은 사람이 직접 봐야 합니다. 탭 5개를 오가며 컨텍스트를 잃지 않는 것 자체가 일이 됩니다.
2026년 6월 29일 긱뉴스에 소개된 Orch term (zendy 작성) 은 이 문제를 "한 창에 다 모아보자"는 방향으로 푼 데스크톱 앱입니다. Tauri 2 (Rust 백엔드) + TypeScript/Vite, xterm.js (WebGL), SQLite 저장소를 기반으로, Windows·macOS를 지원합니다. 단순히 탭을 많이 띄워주는 것이 아니라 에이전트 여러 대를 격리된 워커로 띄워 협업시키는 로컬 멀티에이전트 관제탑을 표방합니다.
핵심 개념 — 지휘자/워커 모델
Orch term의 설계는 두 개의 역할로 나뉩니다.
- 지휘자(commander): 사용자가 직접 대화하는 에이전트 (예: claude)
- 워커(worker): 지휘자의 지시를 받아 격리된 git worktree 위에서 작업하는 서브 에이전트 (예: codex, agy)
지휘자는 MCP (Model Context Protocol) 게이트웨이(:9611 포트) 로 워커의 세션을 열고(open_session), 메시지를 보내고(send), 종료(close) 합니다. 사용자는 지휘자에게 "백엔드 SSH 터널 모듈 리뷰해줘"와 같은 자연어 한 줄을 던지면, 지휘자가 codex 워커를 worktree 위에 띄워 작업을 분담하고, 결과만 다시 받아 사용자에게 보고합니다. 한 워커가 막히면 다른 워커에게 위임하는 에이전트 간 핸드오프도 표준 시나리오로 설계되어 있습니다.
흥미로운 점은 워커가 각자의 격리된 git worktree에서 작업한다는 것입니다. 여러 워커가 같은 파일을 동시에 수정해도 작업 디렉터리가 다르므로 충돌이 발생하지 않고, 메인 브랜치는 워커 작업이 끝난 뒤에 사람이 검토 후 머지하는 구조입니다. 사실상 사람의 코드 리뷰 단계가 에이전트 오케스트레이션의 종착점에 자연스럽게 놓이게 됩니다. 워커의 진행 상황은 Space별 칸반 보드에 todo 단위로 반영되어, 사람은 "지금 두 명이 동시에 작업 중이고 한 명은 막힘" 같은 상태를 한눈에 파악할 수 있습니다.
다섯 기둥 — 워크스테이션의 5대 핵심 기능
Orch term을 단순 터미널이 아닌 "멀티에이전트 워크스테이션"으로 만드는 다섯 기능을 정리하면 다음과 같습니다.
| 기둥 | 핵심 기능 | 인터페이스 |
|---|---|---|
| 워크스테이션 | 터미널·에디터·브라우저 탭을 이진 분할 트리로 자유 배치 | GUI |
| 오케스트레이션 | 지휘자가 워커를 띄워 다중 턴 협업 | MCP :9611 |
| AI 게이트웨이 | 앱 내 AI를 OpenAI 호환 HTTP API로 외부 노출 | HTTP :9610 |
| SSH·SFTP | native russh로 인-탭 접속, SFTP 편집, 포트 포워딩 | 인앱 |
| CDP 브라우저 미러 | chrome-devtools-mcp 브라우징을 인앱 패널에 실시간 미러링 | 인앱 |
여기에 더해 칸반식 할 일 보드가 Space(독립 레이아웃) 별로 붙고, 앱 안의 AI 에이전트가 MCP로 같은 보드를 직접 읽고 쓸 수 있습니다. 즉, 사람의 TODO와 에이전트의 작업 진행 상황이 하나의 보드에서 합쳐집니다. 단순 "에이전트 자동화"가 아니라 "사람과 에이전트가 같은 작업판을 공유"하는 형태입니다.
실용 팁 — 일단 어떻게 시작하나
원본 페이지와 quickstart 가이드 의 흐름을 따라가면 다음과 같습니다.
- 설치: Windows는 MSI 설치 관리자, macOS는 DMG 또는 한 줄 설치 명령. (아직 코드 서명 전이라 SmartScreen / Gatekeeper 경고가 뜸)
- 지휘자 지정: Space 1에 claude를 띄우고, Space 2에 codex를 띄워 워커로 둡니다.
- 워크트리 분기: 지휘자에게 "backend(codex) 워커를 worktree:feature-x에 띄워줘"라고 지시.
- 에이전트 미러링: 에이전트가 chrome-devtools-mcp로 브라우저를 조작하면, 인앱 CDP 미러 패널에서 그 흐름이 그대로 보입니다.
- 로컬 자동화: 다른 스크립트/도구가 OpenAI 호환 호출(예:
curl http://localhost:9610/run -H 'Authorization: Bearer ...')로 AI를 호출할 수 있습니다. 모든 요청/응답은 날짜별 감사 로그에 남습니다.
MCP 포트와 HTTP 포트가 분리되어 있다는 점이 중요합니다. :9611은 에이전트 간 핸드오프용, :9610은 외부 머신→머신 자동화용입니다.
# OpenAI 호환 호출 예시 (apps/sdk/python/openai 호환)
curl -X POST http://localhost:9610/run \
-H "Authorization: Bearer $ORCH_TOKEN" \
-H "Content-Type: application/json" \
-d '{"messages":[{"role":"user","content":"README 요약해줘"}]}'
기술적 도전 — 왜 직접 만들었나
zendy는 긱뉴스 글에서 "개발하며 어려웠던 점" 세 가지를 강조합니다.
- Tauri 네이티브 자식 웹뷰 (unstable) 로 인앱 브라우저 구현. 동기 커맨드가 메인 스레드를 데드락시키는 함정, 창 복귀 후 키보드 입력이 끊기는 포커스 버그가 있었고, 결국
wry를 직접 패치. - conpty 환경의 한글 IME·이모지 입력, alt+tab 복귀 시 중복 입력 같은 입력단 버그.
- Windows·macOS 양립 — 한 OS를 고치면 다른 OS가 깨지는 일이 많아 모든 분기를 게이트 처리.
즉 "단순히 터미널을 더 잘 만든 것"이 아니라 Tauri 2 + conpty + wry + MCP 의 미성숙 지점들을 직접 패치하면서까지 "에이전트 워크스테이션"을 완성한 사례입니다.
전망 — 멀티에이전트 IDE의 한 갈래
Orch term의 방향성은 흥미로운 분기점을 보여줍니다. VS Code의 Copilot, Cursor의 Composer, JetBrains의 Junie 같은 에이전트가 IDE 안에 사는 형태와 달리, Orch term은 에이전트 여러 대가 격리 worktree에서 협업하고 그 위에 사람이 관제탑으로 앉는 형태입니다. 한 명의 개발자가 동시에 진행할 수 있는 작업의 상한을 끌어올린다는 점에서, 멀티에이전트 오케스트레이션이 IDE 레이어 아래의 별도 워크스테이션으로 자리 잡을 가능성을 시사합니다.
다만 코드 미서명, Linux 미지원 (댓글에서도 "왜 linux가 빠지나" 라는 지적 등장), 그리고 wry 직접 패치의 업스트림 반영 여부 같은 리스크는 단기적으로 따라옵니다. 1인 개발 프로젝트의 현실적 한계이기도 합니다. 그럼에도 불구하고 "에이전트를 부리는 도구"가 에이전트 자체보다 먼저 복잡해지는 현상 을 잘 보여주는 사례입니다. 앞으로 1년 안에 비슷한 컨셉의 제품이 몇 개 더 나올 가능성이 높고, MCP + git worktree + 칸반 보드의 조합은 사실상 표준 패턴이 될 가능성이 있습니다. 그 시작점에 Orch term이 있다는 점에서, 한 번 직접 띄워볼 만한 프로젝트입니다.
비교 — Orch term vs 기존 멀티에이전트 도구
| 도구 | 워커 격리 | 에이전트 협업 | 워크스테이션 통합 | 자체 git UI |
|---|---|---|---|---|
| Orch term | git worktree | MCP 핸드오프 | 한 창 통합 | ✓ |
| tmux + 스크립트 | 세션 단위 | 수동 스크립트 | 없음 (외부) | ✗ |
| VS Code Multi-root | 워크스페이스 단위 | 확장 의존 | IDE 안에 한정 | 부분 |
| Cursor Background Agent | 원격 컨테이너 | 백그라운드 task | IDE 안에 한정 | ✗ |
Orch term의 차별점은 터미널·에디터·브라우저·Git이 모두 한 네이티브 앱 안에 통합 되어 있다는 점입니다. tmux 스크립트로 비슷한 워크플로를 구성할 수는 있지만, 통합 UI의 편의성과는 차원이 다릅니다. VS Code의 Multi-root 워크스페이스로 여러 워커를 띄울 수도 있지만, 워크트리 자동 격리·에이전트 간 핸드오프·칸반 보드 동기화 같은 기능은 따로 만들어 붙여야 합니다. Orch term은 그 조합을 처음부터 같이 설계한 점이 강점입니다.
요약
'AI 뉴스' 카테고리의 다른 글
| AI 시대의 다섯 가지 일하는 사람의 원형 — 클로드 코드 창시자의 통찰 (0) | 2026.06.30 |
|---|---|
| Compute-adjusted LTV(연산 비용 반영 LTV) 계산하는 방법 — AI SaaS 단위 경제의 새 기준 (0) | 2026.06.30 |
| GLM 5.2, Semgrep IDOR 벤치마크에서 Claude 앞서 — 모델 자체 vs 하네스 효과 분리 실험 (0) | 2026.06.30 |
| 아시아 AI 스타트업, Mythos 대체 모델 출시 — Sakana AI 'Fugu'와 360 'Tulongfeng' 심층 분석 (0) | 2026.06.30 |
| 결정과 돈: 회사가 "앤트로픽이 이걸 만든다면?" 질문에서 살아남는 법 (0) | 2026.06.29 |