Multi-Agent Orchestration에서 병렬 처리와 충돌 방지

AI 에이전트 여러 개를 동시에 돌리면 일은 빨리 끝나지만, 둘이 같은 파일을 고치거나 같은 배포를 두 번 하면 그 시간은 충돌을 푸는 데 다 쓰인다. 이 글은 병렬로 나눌 일을 고르는 기준, 작업자끼리 부딪치지 않게 하는 소유권·격리·단일 작성자 규칙, 그리고 결과를 합치고 검증하는 순서를 정리한 것이다.

한눈에 보기

병렬로 나눌 일과 나누지 말 일

병렬 처리의 이득은 작업끼리 서로를 기다리지 않을 때만 생긴다.

나눠도 되는 일

• 입력과 출력이 겹치지 않는 일: 글 여러 편을 각각 쓰기, 모듈별 테스트 작성, 파일별 코드 리뷰.
• 결과를 나중에 합치기만 하면 되는 조사: 서로 다른 디렉터리 탐색, 여러 라이브러리 비교.

나누지 말 일

• 앞 작업의 결과가 다음 작업의 입력인 일: 설계 → 구현 → 테스트는 순서가 있다. 억지로 나누면 뒤 작업자가 추측으로 시작하고, 앞 결과가 나온 뒤 다시 한다.
• 같은 파일 하나를 크게 고치는 일: 나눠 봐야 마지막에 사람이 손으로 합친다.
• 몇 번의 도구 호출로 끝나는 일: 작업자를 띄우고 지시서를 쓰는 비용이 일보다 크다.

판단 기준은 하나다. "이 두 작업을 서로 모르는 두 사람에게 맡겨도 결과가 맞는가." 아니라면 나누지 않는다.

나누는 기준은 파일 소유권

작업을 나눌 때 기능이 아니라 누가 어떤 파일에 쓰는가로 경계를 정한다.

• 작업 단위마다 쓸 수 있는 경로를 명시한다. 예: "work/<slug>/ 아래에만 쓴다."
• 두 작업이 같은 파일을 고쳐야 하면, 그 파일은 한 작업에만 주고 다른 작업은 변경 요청만 남기게 한다.
• 공통 설정 파일(package.json, 라우팅 표, 공통 상수)은 병렬 단계에서 아무도 고치지 않고 통합 단계로 미룬다.

소유권을 문장으로 적어 두면 작업자도 경계를 안다. 적지 않으면 작업자는 "도움이 될 것 같아서" 옆 파일을 고친다.

작업 공간을 따로 준다: 폴더와 git worktree

같은 작업 트리에서 여러 에이전트가 동시에 파일을 쓰면, 한쪽의 빌드·테스트가 다른 쪽의 반쯤 쓴 파일을 읽는다. 작업 공간을 나누면 이 문제가 사라진다.

• 작업자별 폴더: 산출물이 문서·이미지처럼 독립적이면 폴더만 나눠도 충분하다.
• git worktree: 코드를 고치는 작업은 작업자마다 브랜치와 작업 트리를 따로 준다. 저장소는 하나지만 체크아웃된 디렉터리가 분리된다.

# 작업자마다 브랜치와 작업 트리를 따로 만든다
git worktree add ../wt-auth -b agent/auth
git worktree add ../wt-billing -b agent/billing

# 끝난 뒤 정리
git worktree remove ../wt-auth

Claude Code의 Agent 도구에도 하위 에이전트를 별도 worktree에서 돌리는 격리 옵션이 있다. 변경이 없으면 자동으로 정리된다.

공유 상태는 한 명만 쓴다

저장소 커밋, 배포, DB 쓰기, 블로그 발행처럼 하나뿐인 대상은 병렬로 쓰면 안 된다.

• 단일 작성자(single writer): 오케스트레이터만 공유 상태에 쓴다. 작업자는 결과 파일만 만들고 끝낸다. 가장 단순하고, 충돌이 구조적으로 생기지 않는다.
• 리스(lease) 또는 잠금: 꼭 여러 작업자가 써야 하면 "이 자원은 누가 언제까지 쓴다"를 기록하고, 만료 시각이 지나면 다른 작업자가 가져가게 한다. 만료 없는 잠금은 작업자가 죽으면 영원히 풀리지 않는다.

에이전트 작업에서는 대부분 단일 작성자로 충분하다. 잠금은 구현과 디버깅 비용이 커서 정말 필요한 곳에만 쓴다.

합치는 단계: 통합 담당

fan-in은 결과를 모으는 것만이 아니다. 합칠 때 생기는 문제를 여기서 한 번에 처리한다.

할 일

• 작업자 결과를 하나씩 확인하고 순서대로 병합한다. 동시에 여러 브랜치를 섞지 않는다.
• 병합 충돌이 나면 통합 담당이 푼다. 충돌을 작업자에게 돌려보내면 그 작업자는 다른 작업자의 맥락을 모른 채 고친다.
• 병렬 단계에서 미뤄 둔 공통 파일 변경을 여기서 반영한다.
• 합친 뒤 전체 빌드·테스트를 한 번 돌린다. 각자 통과한 결과도 합치면 깨질 수 있다.

실패와 재시도: 멱등한 작업 단위

작업자는 중간에 멈추거나 틀린 결과를 낸다. 그 작업만 다시 돌릴 수 있어야 한다.

• 작업 단위를 다시 실행해도 같은 결과가 되게 만든다. 출력 파일을 덮어쓰고, 외부에 쓰는 일(커밋·배포)은 작업자에게 주지 않는다.
• 작업마다 입력·출력 경로를 고정한다. 그러면 실패한 작업 하나만 다시 띄울 수 있다.
• 재시도 전에 실패 원인을 본다. 같은 지시서로 같은 실패를 반복하는 일이 가장 흔한 낭비다.

작업 지시서가 곧 컨텍스트

하위 에이전트가 아는 것은 지시서에 적힌 것뿐이다. 오케스트레이터가 대화에서 정한 규칙도 지시서에 없으면 작업자는 모른다. 무엇을 넣고 뺄지는 AI Agent의 Context Engineering과 메모리 계층 설계에서 다룬 원칙과 같다.

지시서에 넣을 것은 다섯 가지다.

목표: 무엇을 만들면 끝인가 (끝 기준 포함)
범위: 쓸 수 있는 경로, 하지 말 일 (커밋·배포·발행 금지)
입력: 읽을 파일 경로, 이미 확인한 사실
형식: 결과물 위치와 꼴, 길이 상한
보고: 확신 없는 이름·사실을 목록으로

마지막 항목이 중요하다. 작업자가 불확실한 부분을 스스로 밝혀야 검증할 곳이 좁아진다.

결과 검증

작업자의 결과는 확신에 찬 문장으로 돌아온다. 맞는 결과와 틀린 결과의 말투가 같다. 그래서 만든 쪽이 아닌 쪽이 검사한다. 검사 규칙과 반복 횟수는 Maker–Checker Loop로 AI Agent 결과물 검증하기에 정리했다.

통합 담당은 최소한 다음을 직접 본다: 작업자가 소유 경로 밖을 고치지 않았는가, 보고한 불확실 항목이 맞는가, 합친 결과가 검사를 통과하는가.

실제 예: 이 블로그의 기술 아티클 발행

이 블로그의 기술 아티클은 주제 4~6개를 한 번에 받아 위 규칙대로 만든다.

• 오케스트레이터가 주제마다 작업자를 하나씩 띄운다. 작업자는 work/<slug>/ 폴더 하나만 소유하고 원고와 다이어그램만 만든다.
• 지시서에는 이미지 자리 표기 형식, 본문 상한, 겹치는 과거 글 경로, 확신 없는 이름을 보고하라는 요청을 넣는다.
• 이미지 커밋, 배포, 발행은 오케스트레이터 혼자 한다. 저장소와 사이트에 쓰는 주체가 하나라 충돌이 없다.
• 작업자 보고의 불확실 항목은 오케스트레이터가 다시 확인하고, 원고 검사 스크립트를 통과해야 발행한다.

한 줄 프롬프트로 프로젝트를 생성하는 Project Factory 설계도 같은 구조를 프로젝트 생성에 적용한 설계안이다.

정리

자주 하는 실수

• 순서가 있는 일을 병렬로 돌린다. 뒤 작업자가 앞 결과를 추측하고, 결국 다시 한다.
• 소유 경로를 적지 않는다. 작업자가 공통 파일을 각자 고쳐 통합 때 충돌이 쏟아진다.
• 작업자에게 커밋·배포를 맡긴다. 같은 대상에 쓰는 주체가 여럿이 되어 순서가 꼬인다.
• 지시서를 짧게 쓴다. 오케스트레이터가 아는 규칙을 작업자는 모르고, 규칙을 어긴 결과가 돌아온다.
• 작업자 보고를 그대로 믿는다. 불확실 항목과 소유 경로 위반을 확인하지 않으면 오류가 합쳐진다.

점검표

• 병렬 작업들이 서로의 결과를 입력으로 쓰지 않는다
• 작업마다 쓸 수 있는 경로가 지시서에 적혀 있다
• 공통 파일 변경은 통합 단계로 미뤘다
• 코드를 고치는 작업자는 각자 worktree나 폴더에서 일한다
• 커밋·배포·발행은 한 주체만 한다
• 잠금을 쓰면 만료 시각이 있다
• 작업 단위를 다시 실행해도 결과가 같다
• 지시서에 목표·범위·입력·형식·보고가 모두 있다
• 합친 뒤 전체 검사를 한 번 돌린다
• 작업자의 불확실 항목을 다른 쪽이 확인했다

멀티 에이전트를 빠르게 만드는 것은 작업자 수가 아니라, 서로 기다리지 않는 일만 나누고 공유 상태에는 한 명만 쓰게 하는 경계다.