Anthropic의 Claude 코드 프로젝트 개요: TypeScript로 작은 프로젝트 코디네이터 만들기

대부분의 다중 에이전트 데모는 같은 방식으로 시작합니다.

에이전트 세 개를 가동하고,
같은 목표를 알려줍니다.
그리고 서로 방해하지 않기를 바랍니다.

때로는 그것이 작동하기도 합니다.
하지만 종종 동일한 파일을 수정하는 풀 리퀘스트(pull requests) 세 개와, 그 이유를 설명하는 네 번째 대화가 생겨납니다.

2026년 10월 9일, ClaudeDevs (Anthropic의 개발자 계정)는 다음과 같이 작성했습니다:

저희가 Claude Code Projects 대기자 명단에 있는 모든 Pro 및 Max 사용자들을 초대합니다!

이것이 Anthropic이 Projects redesigned: from folder to conversation에서 설명하는 제품입니다. 프로젝트는 더 이상 채팅 폴더가 아닙니다. 목표를 정의하고, 병렬 스레드에 작업을 위임하며, 돌아오는 내용을 검토하고, 완성된 결과물을 조립하는 코디네이터 대화입니다.

Anthropic 자체의 표현이 제가 기억하는 부분입니다:

프로젝트는 작업을 수행하는 스레드와 그들을 지시하는 코디네이터를 가집니다.

그리고:

내부적으로, 각 스레드는 자체 브랜치와 레포지토리(repo) 복사본에서 작업하는 Claude Code 클라우드 세션입니다. 코디네이터는 작업을 정리하지만, 만약 어떤 스레드가 동일한 코드에 대해 작업한다면, 그 중복은 다른 PR과 마찬가지로 병합 충돌(merge conflict)로 해결됩니다.

이 구분이 중요합니다.

병렬 작업은 쉽습니다.
코디네이션된 작업이 제품입니다.

만약 에이전트 다섯 개를 시작할 수는 있지만, 어떤 파일이 누구의 소유인지 말할 수 없다면, 그것은 프로젝트가 아닙니다. 로그로 가득 찬 교통 체증일 뿐입니다.

자, 그럼 작은 버전을 만들어 봅시다.

마지막에는 하나의 명령어를 실행하게 될 것입니다:

npx tsx coordinator.ts

그리고 하나의 목표가 일일 제한(daily cap) 아래 스레드로 분할되고, 또 다른 목표는 파일 충돌로 막히고, 둘 다 조립된 상태 보드를 출력하는 것을 지켜보게 될 것입니다.

이것은 제가 구상한 아이디어의 작은 모델입니다. 내부적으로 Claude Code Projects가 작동하는 방식은 아닙니다. 아래 언급된 모든 목표, 파일 경로 및 스레드 제한은 가상의 내용입니다.

1. 문제점

프로젝트 코디네이터는 네 가지 질문에 답해야 합니다.

어떤 작업은 자체 스레드에 속하는가?

오늘 몇 개의 스레드를 시작할 수 있는가?

누가 이미 어떤 파일을 선점했는가?

무엇이 완료된 것들로부터 무엇을 출시할 수 있는가?

대부분의 에이전트 루프는 전체 목표를 하나의 프롬프트에 쏟아부음으로써 첫 번째 질문만 답변합니다.

그러면 병합 충돌(merge conflict) 답변이 세 번째 질문을 대신해줍니다.

먼저 범위를 설정하고, 다음으로 제한을 두며, 세 번째로 선점하고, 마지막으로 조립한다. 이 순서가 설계다.

2. 단계 1: 공유 메모리

Anthropic은 모든 스레드가 공유 프로젝트 메모리에서 가져온다고 말합니다. 출시일, 결정 사항, 그리고 결제(billing)를 건드리기 전에 누구에게 연락해야 하는지 등이 포함됩니다.

작은 버전에서는 메모리가 사실들의 목록입니다.

type Fact = { key: string; value: string; by: string };

type ThreadPlan = { id: string; title: string; files: string[] };
...

remember는 키를 덮어씁니다. recall은 그것을 읽습니다.

사람이 release=Friday라고 작성합니다. 스레드들은 완료될 때 그것을 읽으므로, 재프롬프트 없이도 조립된 보드가 일관성을 유지합니다.

그것은 RAG(Retrieval-Augmented Generation)가 아닙니다. 키가 있는 화이트보드입니다.

3. 단계 2: 목표 범위 설정하기

범위 설정(Scoping)은 실제 시스템이 모델을 호출하는 곳입니다.

여기서는 플래너가 모의(mocked)됩니다. 두 개의 데모 목표는 고정된 스레드 계획을 반환합니다.

function scope(goal: string): ThreadPlan[] {
  if (goal.includes("v1 checkout")) {
    return [
...

각 계획은 ID, 제목, 그리고 건드릴 파일들을 가지고 있습니다.

Anthropic의 기사는 동일한 형태를 사용합니다: 사용 중단된 v1 엔드포인트를 리포지토리당 하나의 스레드로 폐기하거나, 프로파일링 엔드포인트를 병렬로 열고 PR(Pull Request)을 생성하는 것입니다.

중요한 부분은 코디네이터가 분할권을 소유한다는 것입니다. 스레드가 자체 범위를 발명하지 않습니다.

4. 단계 3: 제한 내에서 스레드 열기

Claude Code Projects는 각 스레드가 전체 세션이기 때문에 사용 한도에 더 빨리 도달할 수 있습니다. Anthropic은 프로젝트별 사용 제어를 문서화하고 있습니다. 대기 목록 오픈과 관련된 보도 자료에서도 일일 신규 스레드 할당량을 언급합니다. 이 숫자는 기사 위의 인용문이 아니라 보도 자료로 간주하십시오.

이번 데모에서 한도는 첫 번째 프로젝트에 대해 하루 3개의 스레드를 예시 입력값으로 사용합니다.

function openThreads(p: Project, plans: ThreadPlan[]): string[] {
  const notes: string[] = [];
  for (const plan of plans) {
...

할당량에 맞는 스레드는 running 상태로 시작합니다.

나머지는 이유와 함께 queued 상태로 유지됩니다.

Queued는 실패한 것이 아닙니다. 내일 또는 사람이 할당량을 늘려줄 때까지 기다리는 것입니다.

5. Step 4: 편집하기 전에 파일 청구(Claim Files Before You Edit)

Anthropic은 중복되는 편집을 브랜치에서 병합 충돌(merge conflicts)로 해결합니다.

작은 버전(tiny version)은 더 엄격하고 빠릅니다. 스레드는 작업을 완료하려면 파일을 먼저 청구해야 합니다. 먼저 청구하는 사람이 승리합니다 (First claim wins).

function claimFiles(p: Project, t: Thread): string | null {
  const taken = t.files.filter((f) => p.claimed.has(f) && p.claimed.get(f) !== t.id);
  if (taken.length > 0) {
...

만약 다른 스레드가 이미 api/routes/checkout.ts를 청구했다면, 새로운 스레드는 이유가 출력되면서 blocked 상태가 됩니다.

이것이 전체 기능입니다.

금요일에 예상치 못한 PR 싸움에서 충돌을 겪는 것이 아니라, 코디네이터 로그에서 충돌을 보고 싶습니다.

6. Step 5: 완료된 것들을 조립하기(Assemble What Finished)

요약하는 법이 없는 코디네이터는 단순한 프로세스 스포너에 불과합니다.

function assemble(p: Project): string {
  const done = p.threads.filter((t) => t.status === "done");
  const blocked = p.threads.filter((t) => t.status === "blocked");
...

보드는 메모리, 완료된 스레드(done threads), 차단된 스레드(blocked threads), 그리고 대기 중인 스레드(queued threads)를 나열합니다.

사람들은 보드를 읽습니다. 에이전트는 보드를 남겨야 합니다.

7. Step 6: 실행하기(Run It)

파일을 coordinator.ts로 저장하고, 설치한 다음 실행하십시오:

npm install
npx tsx coordinator.ts

예시 출력 (예시 입력값만 해당):

tiny-project-coordinator demo

=== demo 1: retire v1 checkout (cap 3) ===
...

Demo 1은 API, 웹 및 모바일 전반에 걸쳐 v1 체크아웃을 폐기합니다.

세 개의 스레드가 시작됩니다. 문서(Docs)는 일일 할당량 제한 때문에 대기합니다. 메모리는 모든 완료된 결과에 `release=Friday`를 전달합니다.

Demo 2는 p75 지연 시간 단축을 시도합니다.

`profile`과 `cache`가 완료됩니다. `query`는 이미 `profile`이 `api/routes/checkout.ts`를 선점했기 때문에 차단됩니다.

이것이 의도적으로 포착된 트래픽 정체입니다.

## 8. 문제점 분석 (Where It Breaks Down)

**스코핑(Scoping)은 모의 구현되었습니다.** 실제 코디네이터는 작업을 분할하기 위해 모델(또는 인간)을 필요로 합니다. 잘못된 분할은 아예 분할하지 않는 것보다 더 나쁩니다.

**파일 선점(File claims)이 거칩니다.** 실제 저장소는 더 세밀한 잠금(lock)이나 병합 규칙을 가진 의도적인 공유 소유권을 필요로 합니다. Anthropic은 git 충돌에 의존합니다. 이 데모는 두 번째 작성자를 거부합니다.

**메모리는 평면 맵입니다.** `by` 외에는 출처(provenance)가 없고, 만료 기한이나 접근 제어 기능이 없습니다. 규칙 없이 공유되는 메모리는 공유 오염원이 됩니다.

**할당량(Caps)이 조잡합니다.** 일일 스레드 수는 토큰 예산, 달러 예산 또는 위험 예산과 같지 않습니다. 아마도 이 세 가지 모두를 원할 것입니다.

**검토 단계가 없습니다.** Anthropic의 코디네이터는 어셈블리 전에 출력을 검토합니다. 이 보드는 상태만 계산합니다. 검토(Review)가 다음 관문입니다.

**큐에 대기 중인 작업은 자동으로 재개되지 않습니다.** 할당량을 높이고 큐를 비우는 것은 연습으로 남겨지며, 이는 모델 라우터에서 지출 일시 정지(spend pause)와 같은 아이디어입니다.

## 9. 더 큰 그림 (The Bigger Idea)

goal
└→ scope: 스레드 계획 + 파일
└→ open: 일일 할당량 제한 하에
...


`goal`은 의도(intent)를 제공합니다.

`scope`는 분할을 제공합니다.

`cap`은 상한선(ceiling)을 제공합니다.

`claim`은 소유권(ownership)을 제공합니다.

`memory`는 연속성(continuity)을 제공합니다.

`board`는 인계(handoff)를 제공합니다.

이 부분은 역사가 아니라 예측입니다.

저는 '우리가 몇 명의 에이전트를 실행할 수 있는가'라는 질문이 멀티 에이전트 작업에 있어 잘못된 질문이 되어가고 있다고 생각합니다. 흥미로운 질문은 누가 그것들을 코디네이션하는가입니다.

Anthropic이 병렬 클라우드 스레드보다 코디네이터 대화를 위에 두는 것은 올바른 방향입니다. Google의 Gemini 에이전트, Meta의 Muse Wonder 포커스 루프, 그리고 OpenAI의 도구 중심 스택은 모두 다른 측면에서 같은 형태를 그리며 순환하고 있습니다.

다른 제품들. 같은 방향성.

**병렬 처리(Parallel)는 기능일 뿐입니다. 코디네이션(Coordination)이 바로 제품입니다.**

## Try Roster

저는 이 아이디어를 바탕으로 Roster를 구축하고 있습니다: 실제 책임, 도구, 메모리, 일정 및 컴퓨터 접근 권한을 가진 AI 직원들입니다. 이들은 단순히 분산되는 것(fan out)에 그치지 않습니다. 각자의 업무 영역을 유지하고, 배운 것을 공유하며, 인간이 읽을 수 있는 보드 형태로 결과물을 전달합니다.

만약 동일한 후속 조치, 인수인계, 대기 루프가 매주 시간을 잡아먹는다면, 그것들을 AI 직원에게 맡겨보세요.

[Try Roster →](https://get-roster.com)