2026년 11월 6일, 코딩 에이전트 Amp는 에이전트 및 팀과 협업하는 새로운 방식인 spaces를 출시했다. space란 하나의 에이전트와의 대화로, 그 에이전트가 다른 에이전트 스레드를 생성하고 조율하는 일을 맡는다. 사용자가 직접 스레드를 만들고 정리할 필요가 더 이상 없다. Amp의 판단은 이것이 에이전트와의 협업의 미래일 수 있다는 것이다. 사람은 '함장석'에 앉아 전체를 내려다보고, 필요할 때만 세부 사항으로 들어간다.
Amp는 자사 팀의 세 가지 사례로 설명한다. 새 기능을 개발할 때 팀 전체가 'Spaces v1'이라는 space를 공유하며 피드백, 버그, 새로운 아이디어를 채팅에 올렸고, 에이전트는 이를 각 스레드로 배정했다. 논의가 필요하면 먼저 댓글로 이야기하고 준비가 되면 Amp를 호출했다. 출시를 운영할 때는 Lewis가 하나의 space에서 service accounts 기능을 출시했다. X, Slack, 버그 보고를 모니터링하고, 들어온 버그를 수정하고, 이메일과 환불을 발송했으며, 이후 일주일 내내 해당 space가 사용자 문제와 시스템 상태를 지켜봤다. 정기 보안 검토에서는 Will이 space에 목표를 줬다. 최근 변경 사항을 보안 관점에서 검토하는 것이다. 첫 실행에서는 코드베이스를 16개 영역으로 나누어 각 영역을 별도 스레드로 검토하고, 모든 발견 사항을 다른 스레드에서 교차 확인한 뒤, 14개의 문제를 space 안의 요약 문서에 기록했다.
space를 시작하는 방법은 간단하다. 사이드바의 Spaces 섹션에서 +를 누르고, 제목과 프로젝트를 정한 뒤 에이전트에게 무엇을 할지 말하면 된다. Amp는 이렇게도 전한다. 지난 몇 주 동안 팀은 자연스럽게 논의를 space로 옮겼고, 화상 통화와 대화까지 Slack 대신 space에서 하게 됐다. 하지만 이는 어디까지나 Amp 자사의 사용법이다. 팀 규모와 진행 방식이 제각각이므로, 같은 효과가 날지는 더 많은 팀이 써봐야 알 수 있다. 또 다중 에이전트 병렬 작업이 공짜는 아니다. 다중 에이전트 팀 실측에서는 비용이 최대 5.1배까지 오르는 반면 품질은 거의 움직이지 않았다. spaces가 아껴주는 것은 스레드를 정리하는 시간이며, 조율 자체의 비용이 사라지는 것은 아니다.
다음으로 지켜볼 것은 두 가지다. spaces가 Amp의 한 기능에서 다중 에이전트 협업의 일반적인 작업 방식으로 확산될지, 그리고 다른 코딩 도구들이 비슷한 설계로 뒤따를지다. Meta가 Conductor를 인수하며 다중 에이전트 병렬 코딩에 베팅한 것은 대형 업체들도 같은 방향으로 움직이고 있다는 증거다. 이미 Amp를 쓰고 있는 팀에게 시도 비용은 작다. 다음 기능 개발 때 space를 하나 열어보면, 스레드 정리 시간이 절약되는지, 아니면 지켜봐야 할 조율이 한 겹 더 늘어나는지 알 수 있다.
