Muse Code는 왜 에이전트를 세션 내내 살려두는가

만들고 버리는 방식의 문제

대부분의 멀티 에이전트 코딩 툴은 같은 공식을 따릅니다. 태스크가 들어오면 헬퍼 에이전트를 하나 띄우고, 작업 한 조각을 맡기고, 결과를 받아서 폐기하는 것입니다. 추상화로는 깔끔하지만 비용이 만만치 않습니다. 새로 생성된 에이전트는 매번 제로에서 시작해야 합니다. 저장소 구조를 다시 읽고, 빌드 시스템을 다시 파악하고, 코드베이스의 컨벤션을 다시 익혀야 하죠. 태스크가 10개인 세션이라면 이 컨텍스트 수집 비용을 10번 내는 셈입니다.

이 비용은 토큰만의 문제가 아닙니다. 콜드 스타트마다 실제 작업이 늦어지니 레이턴시 문제이고, 한 시간 전에 배운 것을 잊어버린 에이전트가 같은 질문을 두 번 하니 사람이 조종에 쏟는 노력의 문제이기도 합니다.

Muse Code의 답: 지속성

Muse Code는 단순한 메인 에이전트 루프에 비동기 백그라운드 에이전트들을 더한 구조로 만들어졌습니다. 그리고 이 백그라운드 에이전트들은 세션 내내 살아 있습니다. 개별 태스크를 위해 생성되는 존재가 아닙니다. 각자 전문 분야가 있고, 세션이 진행될수록 컨텍스트를 계속 쌓아가며, 메인 에이전트에게 보고할 가치가 있는 일인지 스스로 판단합니다.

마지막 문장이 생각보다 중요합니다. 백그라운드 에이전트는 지시를 기다리며 메인 루프를 막지도 않고, 상태 업데이트로 메인 루프를 도배하지도 않습니다. 다음 단계를 독립적으로 수행하다가, 중요한 순간에만 소통합니다. Meta가 밝힌 설계 근거도 정확히 위의 두 비용입니다. 지속성은 레이턴시를 줄이고, 어렵고 긴 다단계 작업에서 사람이 개입해야 하는 빈도를 줄입니다.

병렬로 일하는 워커, 뒤에서 지켜보는 리뷰어

실제로 써보면 임시직 대기열이 아니라 역할이 정해진 팀과 일하는 느낌입니다. 워커는 변경 작업을 병렬로 실행하고, 리뷰어는 결과물이 내게 도착하기 전에 백그라운드에서 끊임없이 검증합니다. 출시 당시의 표현인 “기본이 멀티 에이전트(multi-agent by default)“는 과장이 아닙니다. 협업은 켜야 하는 모드가 아니라 모든 태스크가 돌아가는 방식 그 자체입니다. 더 빨리 출시할 수 있는 이유는 개별 에이전트가 빨라서가 아니라, 품질 검증이 사후 처리가 아니라 동시에 일어나기 때문입니다.

덧붙인 게 아니라 모델에 학습시킨 것

이 하네스 설계가 범용 모델 래퍼보다 Muse Spark 1.2와 훨씬 잘 맞물리는 데는 이유가 있습니다. 모델이 Muse Code 하네스와 함께 공동 학습되었기 때문입니다. 학습 레시피 자체가 목표 유지, 컨텍스트 압축과 더불어 서브에이전트 행동을 명시적으로 최적화했습니다. 메인 루프와 상주 전문가들 사이의 분업은 위에 얹은 프롬프트 엔지니어링 트릭이 아니라, 모델이 학습 과정에서 직접 본 구조입니다. “재시도는 줄고 툴 사용은 좋아졌다”는 주장의 근거가 바로 여기에 있으며, 자세한 내용은 Muse Spark 1.2 학습 과정을 다룬 글에서 확인할 수 있습니다.

지속성이 해결하지 못하는 것

수명이 긴 에이전트들이 같은 저장소를 동시에 편집한다면 머지 참사의 지름길일 것입니다 — 작업 사본을 공유한다면 말이죠. 하지만 공유하지 않습니다. 작업이 팬아웃되면 쓰기 권한을 가진 자식 에이전트마다 격리된 git 워크트리를 받기 때문에, 병렬 작업이 파일 수준에서 충돌할 일이 없습니다. 이 격리 메커니즘은 따로 설명할 가치가 있어서 별도의 글로 다뤘습니다: 에이전트 팬아웃과 git 워크트리. 그리고 내가 보고 있지 않은 사이에 이 에이전트들이 실제로 무엇을 했는지 궁금하다면, 추가 전용(append-only) 이벤트 로그에 완전한 답이 있습니다.