상태형 에이전트 워크스페이스를 위한 MCP

AI21 Maestro는 여러 reasoning path를 병렬로 돌리는 test-time compute(TTC) 중심 프레임워크지만, 읽기 전용 작업과 달리 코드처럼 상태를 바꾸는 작업에서는 충돌이 발생했다. 여러 subagent가 같은 파일을 수정하거나 공유 상태를 건드리면 변경 충돌, 파일 손상, 롤백 불가 문제가 생겼다.

이 문제는 코딩에만 국한되지 않았다. database agents는 스키마 변경의 안전한 되돌리기가 필요하고, document agents는 서로의 편집을 덮어쓸 수 있으며, infrastructure agents는 클라우드 리소스를 반쯤만 구성한 채 남길 수 있다. 읽기 전용 에이전트는 환경을 공유해도 되지만, 쓰는 에이전트는 격리가 필요하다는 점이 핵심이었다.

해결책으로 **MCP(Model Context Protocol)**에 workspace layer를 추가했다. MCP가 도구가 무엇인지와 어떻게 호출하는지는 정의하지만, 그 도구가 어디서 실행되고 어떤 상태를 공유하는지는 다루지 못했기 때문이다. 이를 보완하기 위해 initialize, clone, compare, merge, delete의 5가지 도메인-agnostic primitive를 정의해, 상태를 바꾸는 에이전트가 공통 계약 아래에서 격리된 환경을 다룰 수 있게 했다.

코딩 에이전트 구현은 git worktrees로 잡았다. worktree는 빠르게 생성할 수 있고, 각 workspace가 branch와 대응되며, 결과를 자연스럽게 merge할 수 있고, Git objects를 공유해 디스크 부담도 낮다. 덕분에 protocol은 “무엇을 해야 하는가”를, 구현은 “어떻게 격리할 것인가”를 담당하는 구조가 맞아떨어졌다.

이 방식으로 얻은 효과는 분명했다.

• Parallel subagent execution: 각 subagent가 독립 workspace에서 동시에 작업
• Speculative problem-solving: 여러 전략을 병렬로 실행하고 승자만 merge
• Safe experimentation: 실패한 시도는 workspace 삭제로 즉시 rollback
• Domain-agnostic pattern: 코드뿐 아니라 database, 문서, 인프라에도 동일한 구조 적용 가능

결과적으로 active approach 1개에서 16개 병렬 시도로 확장하면서도 coordination overhead 없이 실행할 수 있었다. 저자들은 상태를 읽는 에이전트와 달리, 상태를 바꾸는 에이전트에는 격리라는 프로토콜 수준의 책임이 필요하며, 앞으로 official MCP protocol에도 이 패턴이 포함되길 기대한다고 정리했다.