에이전트 하나를 쓰는 건 단순하다. 문제는 두 개, 세 개가 동시에 돌기 시작하는 순간이다. Claude Code가 한 브랜치에서 리팩토링을 끝내기를 기다리면서, Codex는 다른 프로젝트 디렉터리에서 승인을 요청하고 있고, 어제 열어뒀던 유용한 세션은 어느 터미널 탭 뒤에 묻혀 있다. 에이전트의 능력이 문제가 아니다. 워크스페이스가 그 병렬성을 감당하지 못하는 것이 문제다.
dev.to에 올라온 한 개발자의 사례는 이 현상을 정확하게 짚는다. 그는 Claude Code와 Codex를 나란히 돌리다가, 어떤 에이전트가 작업 중인지, 어떤 게 승인을 기다리는지, 어제 세션이 어느 경로·브랜치·터미널에 속했는지를 기억하는 일 자체가 인지 부하가 됐다고 말한다. 결국 그는 Termexo라는 로컬 워크벤치를 직접 만들었다. 이 도구의 핵심 철학은 한 줄이다: "The agents were capable. My workspace was not." 에이전트를 교체하거나 프롬프트를 고치는 게 아니라, 조율 레이어 자체를 재설계한 것이다.
같은 시기, VS Code July 2026 릴리스는 Copilot에 멀티 채팅 세션을 추가했다. 디버깅 스레드와 기능 기획 스레드를 컨텍스트 손실 없이 독립적으로 유지할 수 있게 된 것이다. 두 소식을 겹쳐 읽으면 패턴이 보인다. 툴링이 멀티 에이전트 운용을 기본 전제로 진화하고 있다는 것. 이제 질문은 "어떤 에이전트를 쓸까"가 아니라 "여러 에이전트를 동시에 제어하는 구조를 어떻게 설계할까"로 바뀌고 있다.
멀티 에이전트 DX가 무너지는 지점은 크게 세 가지다. 첫째는 컨텍스트 단절—세션이 어느 프로젝트, 브랜치, 모델 프로필에 속했는지 재조립하는 비용. 둘째는 주의 분산—모든 터미널을 동시에 응시해야 하는 감시 피로. 셋째는 세션 비복구성—앱을 재시작하거나 터미널을 닫는 순간 사라지는 진행 상태. Termexo가 PTY 기반 네이티브 CLI를 유지하면서 그리드 레이아웃, 승인 알림, 세션 복구를 조율 레이어로 얹은 것, VS Code가 독립 채팅 세션으로 스레드 분리를 지원하기 시작한 것—둘 다 이 세 가지 문제를 각자의 방식으로 풀고 있다.
여기서 DX 설계 원칙 하나를 뽑을 수 있다. 에이전트를 교체하지 말고, 에이전트를 둘러싼 조율 레이어를 설계하라. 네이티브 CLI나 IDE 기능을 래핑하거나 대체하는 게 아니라, "어떤 에이전트가 지금 무엇을 하고 있는가"와 "언제 내가 개입해야 하는가"를 명확하게 드러내는 레이어가 필요하다. Termexo가 승인 요청을 시스템 알림으로 노출하고, VS Code가 채팅 스레드를 분리한 것은 모두 이 '개입 타이밍의 가시화'를 구현한 사례다.
실무에서 바로 적용할 수 있는 설계 힌트는 세 가지다. ①세션에 레이블을 붙여라: 프로젝트명·브랜치·담당 에이전트를 터미널 탭 제목이나 채팅 스레드 이름에 명시하면 컨텍스트 재조립 비용이 줄어든다. ②승인 게이트를 비동기로 만들어라: 에이전트가 사람의 승인을 기다리는 동안 다른 에이전트를 진행시키려면, 승인 요청이 별도 채널(알림, 슬랙 등)로 빠져나와야 한다. ③세션 상태를 직렬화하라: 워크스페이스를 닫아도 "어디까지 했는가"를 복원할 수 있는 구조—CLAUDE.md 계층 설계든, Termexo의 워크스페이스 영속성이든—가 없으면 병렬 운용은 매번 처음으로 돌아간다.
전망은 명확하다. VS Code가 멀티 세션 Copilot을 IDE 기본 기능으로 통합했다는 것은, 멀티 에이전트 운용이 파워유저의 실험 영역을 벗어나 일반 개발 워크플로우의 기본값이 되고 있다는 신호다. 동시에 MCP가 스테이트리스 아키텍처로 전환하면서 서버 간 세션 공유 방식도 바뀌고 있어, 조율 레이어의 설계 복잡도는 더 높아질 것이다. 에이전트 성능 경쟁은 계속되겠지만, 다음 병목은 모델 품질이 아니라 그 에이전트들을 동시에 제어하는 개발자 경험의 설계 수준에서 생길 가능성이 높다. 워크스페이스를 설계하지 않으면, 에이전트가 아무리 유능해도 그 능력은 터미널 탭 더미 속에 묻힌다.