메타가 이번 주 Muse Code를 출시했을 때, 헤드라인을 장식한 건 경쟁적 포지셔닝이었다. 즉 Claude Code, Codex, Cursor와 함께 개발자 워크플로우 경쟁에 뛰어든 또 하나의 터미널 기반 코딩 에이전트라는 것. 하지만 마크 저커버그가 이 도구를 설명하며 슬쩍 흘린 말 속에는, 코드를 작성하거나 리뷰하는 것을 업으로 삼는 사람이라면 누구나 주목할 만한 더 흥미로운 신호가 숨어 있다.
"작업 규모가 충분히 크면, 격리된 워크트리에서 병렬로 작동하는 별도의 서브 에이전트들로 확산됩니다." 저커버그는 Muse Code가 대규모 작업을 처리하는 방식을 이렇게 설명했다. "당신의 작업 사본은 절대 건드려지지 않습니다. 테스트에서는 게임용 기능 여섯 개를 동시에 만들게 했는데도 충돌이 전혀 없었습니다."
이건 기능 설명이 아니다. 당신을 위한 직무 기술서다.
"격리된 워크트리"가 실제로 의미하는 것
git 워크트리를 쓰면 같은 저장소의 여러 브랜치를 동시에 각각 별도의 디렉터리로 체크아웃할 수 있어서, 여러 작업 라인이 서로를 건드리지 않고 동시에 진행될 수 있다. 메타의 설명에 따르면 Muse Code는 이 메커니즘을 이용해 여러 서브 에이전트가 당신의 실제 작업 사본이나 서로의 파일을 건드리지 않고 동시에 코드를 작성하게 한다. 이는 합리적인 엔지니어링 선택이다. 파일 단위 충돌은 멀티 에이전트 충돌 중에서도 기계적으로 예방하기 가장 쉬운 종류이므로, 그것을 기계적으로 예방해 두고 모델이 실제 코딩에 집중하도록 자유롭게 풀어주는 것이다.
주목해야 할 단어는 "확산된다(fans out)"이다. 인간 개발자 입장에서 병렬 워크트리 여섯 개는 순서대로 하나씩 손으로 검토할 여섯 개의 코드 스트림으로 다가오지 않는다. 여섯 개의 스트림이 거의 동시에 책상 위에 떨어지고, 각각에 대해 결정을 내려야 한다. 이걸 반영할지, 다시 작업해야 할지, 다른 워크트리에서 형제 에이전트가 방금 한 작업과 충돌하는지.
실제로 바뀌고 있는 스킬
지난 몇 년간 AI 지원 코딩의 지배적인 모델은 대화형이자 단일적이었다. 개발자 한 명, 어시스턴트 한 명, 하나의 대화 스레드, 그리고 그것이 만들어지는 대로 거의 실시간으로 리뷰하는 방식. 그 스킬 — 프롬프트를 잘 짜는 것, 나쁜 제안을 그 자리에서 잡아내는 것, 반복하는 것 — 은 여전히 필요하다. 하지만 그건 Muse Code의 설계가 최적화하고 있는 스킬이 아니다. 서브 에이전트로의 확산은 당신이 이미 다른 작업 방식으로 옮겨갔다는 것을 전제로 한다. 즉 작업을 사전에 독립적으로 실행 가능한 조각들로 분해하고, 그다음에는 한 에이전트를 턴마다 조종하는 대신 여러 에이전트가 내놓은 완성된(혹은 절반쯤 완성된) 결과물을 한꺼번에 검토하는 방식이다.
이는 챗봇과 화면을 나눠 쓰는 페어 프로그래머보다는, 스프린트를 소규모 팀에 나눠주는 테크 리드에 더 가깝다. 개별 코딩 결정 하나하나보다 더 중요한 것은 분해(작업을 실제로 독립적인 선에 따라 나누었는가?)와 리뷰 단계(병렬로 나온 여섯 개의 diff가 각각 개별적으로 올바르면서 동시에 전체적으로도 일관성이 있는지 빠르게 판단할 수 있는가?)다.
격리는 충돌을 해결하지, 일관성을 해결하지 않는다
놓치기 쉬우니 짚고 넘어갈 가치가 있다. 격리된 워크트리는 두 에이전트가 같은 파일을 덮어쓰지 못하게 막아준다. 하지만 두 에이전트가 서로 상대방이 무엇을 만들고 있는지 볼 수 없어서, 같은 일을 하는 두 가지 다른 방법을 독립적으로 만들어내는 것 — 두 번째 날짜 포맷 헬퍼, 두 번째 재시도 래퍼, 중복된 API 라우트 — 을 막아주지는 못한다. git의 격리는 파일 시스템 차원의 보장이지, 설계 차원의 보장이 아니다. 여섯 개의 워크트리를 다시 하나로 병합하는 리뷰어야말로 중복된 추상화, 일관성 없는 네이밍 규칙, 서로 다른 데이터 형태를 암묵적으로 가정하는 두 기능이 걸러지는 유일한 체크포인트다. 만약 그 리뷰어가 병렬 산출물의 양이 꼼꼼한 읽기 속도를 앞질러서 diff를 대충 훑고 지나간다면, 바로 이런 종류의 드리프트가 그대로 배포되어 버린다.
이는 확산형 도구가 일상이 된 뒤 "코드 리뷰"가 의미해야 할 바를 재정의한다. 단일 diff를 한 줄 한 줄 뜯어보는 일은 줄어들고(에이전트의 문법 자체는 대체로 문제가 없다), 대신 diff 간의 정합성을 맞추는 일 — 병렬로 생성된 AI 작업물들이 공유 컨벤션, 공유 데이터 모델, 공유 에러 처리에서 서로 일치하는지 확인하는 일 — 이 늘어난다.
실제로 무엇을 향해 준비해야 하는가
이 중 어느 것도 Muse Code에만 국한되지 않는다. 같은 확산 패턴이 주요 코딩 에이전트 전반에서 나타나고 있으며, 이는 이것이 한 벤더만의 도박이 아니라 기본 아키텍처가 되어가고 있음을 시사한다. 지금 어떤 도구를 쓰든 상관없이 연습해 둘 만한 구체적인 것 몇 가지는 다음과 같다.
- 깔끔하게 분해되는 작업 명세를 작성하라. 병렬 작업을 요청하기 전에, 그 조각들이 진짜로 독립적인지 스스로 물어보라. 같은 파일, 같은 공유 상수, 같은 API 계약을 건드리는가? 그렇다면 그건 여섯 개의 병렬 에이전트를 위한 작업이 아니라, 한 에이전트가 순차적으로 처리할 작업이거나, 공유되는 부분을 당신이 먼저 손으로 분리해 둬야 할 작업이다.
- diff 시점이 아니라 병합 시점에서 리뷰하는 연습을 하라. 완성된 여러 브랜치를 나란히 놓고 "이 각각이 개별적으로 맞는가"뿐만 아니라 "이것들이 서로 일치하는가"를 묻는 데 익숙해져라.
- git 워크트리의 기본을 알아두라. 당신이 쓰는 도구들이 내부 동작을 이런 식으로 설명할 것이라면, 워크트리가 무엇을 보장하고 무엇을 보장하지 않는지 이해하는 것이 결과물을 신뢰하거나 — 혹은 올바르게 불신하기 위한 — 기본 소양이다.
- 공유되는 것들의 소유권을 명확히 하라. 상수, 스키마, 공유 유틸리티, 네이밍 규칙 같은 것들. 확산이 시작되기 전에 이런 것들을 얼마나 확실히 못박아 두느냐에 따라, 이후에 해야 할 정합성 맞추기 작업의 양이 달라진다.
Muse Code 같은 도구에서 가장 많은 것을 얻어낼 사람은 프롬프트를 가장 잘 쓰는 사람이 아닐 것이다. 그들은 작고 빠르며 가끔은 다소 엉성한 팀을 운영하는 데 조용히 능숙해진 사람들일 것이다 — 그 팀의 모든 구성원이 모델이라 하더라도 말이다.
