에이전트를 한 명만 쓰던 단계에서는 프롬프트를 더 잘 쓰는 사람이 유리했다. 하지만 에이전트를 여러 개 동시에 돌리기 시작하면 병목은 완전히 다른 곳에서 생긴다. 누가 어떤 목표로 움직이고 있는지, 어떤 작업은 바로 흘려도 되는지, 어떤 변경은 승인 뒤에만 나가야 하는지, 실패했을 때 어디서 다시 합류해야 하는지가 더 중요해진다. 최근 공개된 OpenAI의 Goal mode와 원격 개입 흐름, Notion의 워크스페이스 에이전트 허브 신호, 병렬 코딩 에이전트와 격리 실행을 강조한 커뮤니티 반응이 모두 같은 방향을 가리키는 이유다.
핵심은 모델 하나의 능력치가 아니라 여러 작업을 모으는 인박스 구조다. 실무에서 잘 굴러가는 멀티 에이전트 운영은 대개 다섯 가지를 분명히 한다. 목표 정의, 컨텍스트 전달 방식, 실행 격리, 도구 노출 제어, 비교 가능한 리뷰 루프다. 이 다섯 가지가 흐리면 에이전트 수를 늘릴수록 생산성이 아니라 충돌과 재작업이 늘어난다.
왜 지금 문제는 더 똑똑한 한 명의 에이전트가 아닌가
이번 주 흐름을 묶어 보면 공통점이 선명하다. 에이전트는 점점 더 오래 실행되고, 더 많은 도구에 연결되며, 더 자주 사람의 승인과 검토를 기다린다. 이런 환경에서는 “잘 대답하는가”보다 “잘 넘겨받고 잘 멈추는가”가 중요하다. 한 에이전트가 초안을 만들고, 다른 에이전트가 검토하거나 수정하고, 사람은 마지막에 승인만 하려면 중간 상태가 구조적으로 남아야 하기 때문이다.
그래서 멀티 에이전트 작업함은 메신저 알림함과 비슷해 보이지만 실제로는 운영 콘솔에 가깝다. 어떤 작업이 들어왔는지, 어떤 성공 기준으로 실행 중인지, 읽기 전용 단계인지 쓰기 단계인지, 결과를 누구와 비교해야 하는지가 한눈에 보여야 한다. 이 관점이 없으면 에이전트를 많이 돌릴수록 사람이 더 바빠진다.
1. 작업함의 첫 요소는 목표 정의다
Goal mode가 시사하는 가장 실용적인 변화는 프롬프트를 길게 쓰는 것보다 결과 기준을 먼저 쓰게 만든다는 점이다. 멀티 에이전트 환경에서는 이 차이가 더 크다. 같은 요청을 두 개 이상의 에이전트에 병렬로 맡길 때는 특히 “무엇을 하면 끝인가”가 모호하면 결과를 비교하기가 어렵다.
실무에서는 목표 문장과 성공 기준을 나눠 적는 편이 좋다. 목표 문장은 이번 작업이 무엇을 달성해야 하는지 한 줄로 적는다. 성공 기준은 검토자가 무엇을 보고 통과시킬지 3개 안팎으로 제한한다. 예를 들어 블로그 초안이라면 “한국어 독자를 위한 실전형 허브 글 작성”이 목표 문장이고, “근거 없는 단정 없음”, “후속 글과 내부 링크 연결”, “체크리스트 포함”이 성공 기준이 될 수 있다.
이렇게 기준을 먼저 적어 두면 병렬 실행 뒤에도 비교가 쉬워진다. 에이전트 A가 문장이 화려해도 기준을 덜 충족하면 탈락시키면 되고, 에이전트 B가 더 단정하고 재사용 가능하면 채택하면 된다. 멀티 에이전트 운영의 품질은 생성량보다 비교 가능성에서 나온다.
2. 두 번째 요소는 컨텍스트 전달 방식이다
여러 에이전트를 동시에 쓸 때 가장 빨리 무너지는 것은 설명 방식이다. 사람이 긴 배경설명을 매번 다시 붙이면 속도 이점이 줄고, 에이전트마다 다른 맥락을 받으면 결과 비교도 어려워진다. 그래서 최근에는 Appshots, 워크스페이스 허브, 브라우저 주석처럼 긴 텍스트 대신 더 구조화된 입력을 주는 흐름이 강해지고 있다.
좋은 작업함은 컨텍스트를 세 층으로 나눈다. 첫째는 기준 컨텍스트다. 팀의 정책, 스타일, 금지 규칙처럼 자주 바뀌지 않는 정보다. 둘째는 작업 컨텍스트다. 이번 요청의 목표, 관련 링크, 체크리스트, 마감 같은 정보다. 셋째는 실행 컨텍스트다. 현재 에이전트가 접근 가능한 파일, 도구, 화면, 상태 같은 정보다. 이 세 층이 섞이면 에이전트는 같은 내용을 반복해서 요약하거나 엉뚱한 곳에 집중한다.
워크스페이스 허브가 중요한 이유도 여기에 있다. 기준 컨텍스트와 작업 컨텍스트를 같은 곳에 남기고, 실행 컨텍스트만 에이전트별로 제한하면 사람은 전체 흐름을 잃지 않으면서도 각 에이전트에게 필요한 범위만 열어 줄 수 있다.
3. 세 번째 요소는 실행 격리다
멀티 에이전트 환경에서 격리는 보안 담당자만의 관심사가 아니다. 격리는 충돌을 줄이고 재실행을 쉽게 만드는 운영 도구다. 같은 저장소나 같은 데이터 집합을 여러 에이전트가 동시에 만지는 순간, 격리 기준이 흐리면 속도보다 충돌 비용이 먼저 늘어난다.
작은 작업은 브랜치나 worktree 수준 분리만으로도 충분할 수 있다. 하지만 코드 수정이나 외부 시스템 변경이 들어가면 더 강한 실행 경계가 필요해질 수 있다. 최근 커뮤니티가 microVM, hosted sandbox, locked computer use 같은 표현에 반응하는 이유도 여기에 있다. 에이전트를 가두기 위해서라기보다, 어떤 범위까지 수정했는지와 어디까지 책임을 지는지를 명확히 남기기 위해서다.
실무에서 중요한 질문은 복잡하지 않다. 이 작업은 읽기만 하는가, 쓰기를 하는가, 실패했을 때 되돌리는 비용이 큰가, 다른 에이전트와 같은 자원을 동시에 만지는가. 이 네 가지 질문에 따라 격리 단위를 정하면 된다.
4. 네 번째 요소는 도구 노출 제어다
MCP 서버를 많이 붙였다고 해서 에이전트가 바로 유능해지지는 않는다. 오히려 작업함 구조가 없으면 도구가 많아질수록 에이전트는 매번 불필요한 선택지를 검토하게 된다. 이 현상은 토큰 비용만 키우는 것이 아니라 품질도 흔든다. 어떤 단계에서 어떤 도구를 써야 하는지 분명하지 않으면, 병렬 실행 결과는 쉽게 산만해진다.
그래서 멀티 에이전트 작업함은 도구 카탈로그가 아니라 노출 정책을 가져야 한다. 리서치 에이전트에는 검색과 문서 조회만, 초안 에이전트에는 작성 도구와 제한된 참고 자료만, 발행 직전 단계에는 승인형 쓰기 도구만 보여주는 식이다. 연결은 넓게 하더라도 노출은 좁게 관리해야 한다.
도구 노출 제어는 속도와 안전을 동시에 다룬다. 불필요한 도구를 숨기면 탐색 경로가 짧아지고, 쓰기 권한이 있는 도구를 단계별로 늦게 열면 사고 반경도 줄어든다. 결국 멀티 에이전트 운영의 핵심은 더 많은 능력을 주는 것이 아니라, 필요한 순간에 필요한 능력만 꺼내는 것이다.
5. 다섯 번째 요소는 리뷰 루프다
병렬 실행이 실제 생산성으로 이어지려면 마지막에 비교 가능한 리뷰 루프가 있어야 한다. 같은 작업을 여러 에이전트가 다르게 풀었다면, 사람은 무엇을 기준으로 고를지 알아야 한다. 이때 생성량이나 답변 길이는 별 의미가 없다. 더 유용한 기준은 diff 품질, 충돌 수, 재작업 횟수, 승인까지 걸린 시간이다.
좋은 리뷰 루프는 결과물만 모으지 않는다. 어떤 기준으로 실행했는지, 어떤 도구를 썼는지, 어디서 막혔는지도 함께 남긴다. 그래야 다음 실행에서 기준을 손보거나 도구 세트를 조정할 수 있다. 리뷰는 끝 단계가 아니라 다음 실행의 입력이 되어야 한다.
소규모 팀이라면 복잡한 대시보드가 없어도 된다. 작업함 카드 하나에 목표 문장, 성공 기준, 사용 도구 세트, 산출물 링크, 승인 상태만 남겨도 운영이 달라진다. 중요한 것은 모든 에이전트가 같은 기준 위에서 비교 가능하게 움직이게 만드는 것이다.
바로 적용할 체크리스트
- 작업 시작 전 목표 문장과 성공 기준을 각각 한 줄씩 적는다.
- 읽기 전용 단계와 쓰기 단계가 같은 작업함 카드에서 구분되게 만든다.
- 장기 실행 작업에는 모바일 승인 또는 알림 경로를 함께 설계한다.
- MCP 도구는 작업별 최소 세트만 노출하고 기본값은 숨김으로 둔다.
- 코드 수정형 에이전트는 worktree, 브랜치, sandbox 중 하나의 격리 단위를 먼저 정한다.
- 결과 비교는 답변 길이보다 diff 품질, 충돌 수, 승인 속도로 본다.
멀티 에이전트 시대의 경쟁력은 에이전트를 많이 돌리는 데 있지 않다. 여러 에이전트가 같은 기준 위에서 멈추고, 넘기고, 비교되도록 만드는 작업함 구조에 있다. 이 구조가 있어야 Goal mode 같은 목표 정의 기능도, 워크스페이스 허브 같은 협업 표면도, MCP 같은 연결 레이어도 실제 생산성으로 이어진다.