- Anthropic은 2026년 9월 17일 Claude Code의 Projects를 코디네이터와 병렬 실행 스레드 구조로 재설계했다.[1]
- 각 스레드는 독립 브랜치와 저장소 복제본을 가진 완전한 클라우드 세션이며, 공유 메모리와 라이브러리를 사용한다.[1][2]
- 여러 세션을 동시에 돌리므로 처리 대기 시간은 줄일 수 있지만 사용 한도 소진과 병합 충돌은 더 빨라질 수 있다.[1][3]
- 한국 개발팀은 대규모 기능 개발보다 되돌리기 쉬운 다중 저장소 마이그레이션으로 비용·검토 시간·실패율을 먼저 측정하는 편이 안전하다.[1][3]
공개일: 2026년 9월 17일. 이 글은 Anthropic의 공식 발표를 사실 기준으로 삼고, 독립 보도는 기능 범위와 비용 위험을 교차 확인하는 데 사용한다.[1][2][3]
한 줄 결론: Claude Code Projects의 핵심은 에이전트 수가 아니라, 하나의 목표를 여러 독립 작업으로 나누고 다시 검토 가능한 변경으로 모으는 조정 계층이다.
무엇이 달라졌나: 폴더에서 실행 관리자까지
기존 Projects는 대화와 파일을 모아 두는 작업 공간에 가까웠다.
새 Projects에서는 사용자가 목표와 저장소 또는 문맥을 지정하면 Claude가 일을 제안하고, 요청을 여러 스레드로 나누며, 결과를 검토해 최종 산출물로 조립한다.[1]
사용자는 메인 프로젝트 대화에서 전체 진행을 지켜보거나 개별 스레드에 들어가 방향을 바꿀 수 있다.[1][2]
출시 시점의 베타는 Claude Code 클라우드 세션을 쓰며 기존 웹·데스크톱 프로젝트가 없는 일부 Pro·Max 구독자부터 제공된다. Anthropic은 이후 더 많은 Pro·Max 사용자, Team과 Enterprise, 일반 Claude와 Cowork로 확대할 계획이라고 밝혔다.[1][2] 따라서 계정에 메뉴가 보이지 않는다고 설치 문제로 판단할 단계는 아니다.[1]
어떻게 작동하나: 코디네이터와 스레드를 분리한다
프로젝트 대화의 코디네이터는 목표를 해석하고 기존 또는 새 스레드로 작업을 보낸다. 각 스레드는 자체 브랜치와 저장소 복제본에서 실행되는 완전한 Claude Code 클라우드 세션이며, 필요하면 내부에서 다시 하위 에이전트·루프·워크플로로 일을 나눈다.[1][2]
여러 스레드는 프로젝트 공유 메모리를 읽고 갱신한다. 출시 일정 변경, 특정 기능을 뺀 이유, 결제 코드 수정 전 확인해야 할 담당자 같은 결정이 다음 작업으로 이어지며, 사용자가 올린 파일과 Claude가 만든 결과물은 라이브러리에 모인다.[1] 이는 채팅을 무한히 기억한다는 보장보다, 장기 작업에서 반복 설명을 줄이는 프로젝트 상태 계층으로 보는 편이 정확하다.[1]
이전 방식과 현재 방식 비교
| 항목 | 단일 Claude Code 세션 | 새 Claude Code Projects |
|---|---|---|
| 목표 분해 | 사람이 세션별로 나눔 | 코디네이터가 스레드에 위임 |
| 실행 단위 | 한 세션·한 작업 흐름 | 독립 브랜치의 병렬 클라우드 세션 |
| 맥락 전달 | 프롬프트·문서 수동 복사 | 공유 메모리와 라이브러리 |
| 결과 통합 | 사람이 변경을 비교 | 코디네이터가 검토·조립, 충돌은 PR 방식 |
| 주요 병목 | 대기 시간과 문맥 재설명 | 사용 한도, 병합 충돌, 검토량 |
왜 중요한가: 코딩 속도보다 조정 비용이 제품이 된다
이번 변화는 코딩 에이전트가 “코드를 잘 쓰는 한 명”에서 “여러 실행자를 관리하는 한 명”으로 이동하고 있음을 보여 준다.[1][2]
The Verge도 공유 목표·메모리·파일 라이브러리 아래 여러 에이전트를 조정하는 구조로 설명했다.[2]
이미 다룬 Cursor Projects의 검토 가능한 작업 단위와 같은 방향이지만, Claude Code Projects는 출시 시점에 모든 실행 스레드가 클라우드에 있다는 점이 중요하다.[1]
국내 스타트업이나 소규모 개발팀에는 여러 저장소를 동시에 바꾸는 API 버전 전환, 의존성 업데이트, 테스트 보강이 현실적인 첫 용도다.[1][3]
반대로 개인정보·고객 코드가 외부 클라우드로 나가면 안 되는 조직은 로컬 실행 지원이 실제 제공되고 보안 검토가 끝날 때까지 기다려야 한다.[1][2]
Anthropic은 로컬 도구와 사내 네트워크 뒤의 코드에서 실행하는 기능이 추후 제공될 예정이라고만 밝혔다.[1][2]
가장 중요한 주의점: 공유 메모리와 코디네이터가 있어도 두 스레드가 같은 코드를 바꾸면 일반 PR처럼 병합 충돌이 생긴다.[1][2]
자동 병합·배포 권한까지 한 번에 주면 조정 속도가 검토 속도를 앞지를 수 있다.[1][2]
특히 여러 저장소의 변경 순서가 얽힌 작업은 병합 전 사람이 의존 관계를 다시 확인해야 한다.[1]
실전 적용: 세 저장소 API 마이그레이션 시험
재현 가능한 첫 시험으로 api, web, mobile 세 저장소의 폐기 예정 엔드포인트를 교체한다고 가정한다. Anthropic도 저장소별 스레드를 만들고 테스트와 PR을 실행한 뒤 병합 순서를 보고하는 사례를 제시한다.[1]
- 스테이징용 복제 저장소를 연결하고 배포·비밀 조회 권한은 제외한다.
- 목표를 “v1 호출을 v2로 교체하되 공개 인터페이스와 테스트 통과 조건을 유지”로 한정한다.
- 저장소별 스레드를 만들고 변경 파일 수, 테스트 명령, 실패 조건을 명시한다.[1]
- 코디네이터에게 PR을 자동 병합하지 말고 의존 순서와 충돌 목록만 보고하게 한다.[1][2]
- 실행 뒤 총 사용량, 사람이 검토한 시간, 재작업 PR 수, 테스트 실패율을 기록한다.
- 단일 세션 기준선보다 세 지표 중 두 개 이상이 개선될 때만 동시 스레드 수를 늘린다.
The Register는 각 스레드가 완전한 세션이어서 여러 작업을 동시에 돌릴수록 사용량과 비용이 빠르게 늘 수 있다고 지적했다.[3]
Anthropic도 프로젝트별 사용량을 확인하고 코디네이터와 작업 스레드의 모델·노력 수준을 따로 선택할 수 있다고 설명한다.[1]
빠른 실행이 곧 저렴한 실행은 아니므로, 첫 시험에서는 병렬 수와 종료 조건을 함께 정해야 한다.[1][3]
또한 PR 수가 늘면 코드 리뷰와 CI 대기열이 새 병목이 될 수 있으므로, 완료 시간을 재는 것만으로 도입 성공을 판단해서는 안 된다.[1][3]
한계와 도입 체크리스트
- ☐ 계정이 베타 대상인지 확인하고, 기존 Projects 이전 시점을 추측하지 않는다.[1]
- ☐ 저장소·커넥터·플러그인에는 작업에 필요한 최소 권한만 부여한다.[1]
- ☐ 병합과 배포는 사람 승인 단계로 남기고 스레드별 테스트 결과를 보관한다.[1][2]
- ☐ 공유 메모리에 기록된 결정의 소유자와 만료일을 사람이 검토한다.
- ☐ 프로젝트별 사용량과 스레드 수를 매 실행 뒤 기록한다.[1][3]
- ☐ 사내망 전용 코드나 민감 데이터는 로컬 실행 지원과 계약 조건을 확인하기 전 연결하지 않는다.[1][2]
- ☐ 장기 실행 에이전트에는 요약·권한·통신 감사 원칙을 함께 적용한다.
결론
Claude Code Projects는 여러 세션을 띄우는 기능보다 그 사이의 목표 분해, 공유 상태, 결과 검토를 제품화했다.[1][2]
독립 브랜치와 클라우드 실행은 다중 저장소 작업의 대기 시간을 줄일 수 있지만, 사용 한도와 병합 충돌, 보안 검토 부담도 같은 방향으로 커진다.[1][2][3]
권장안은 세 저장소 마이그레이션처럼 되돌릴 수 있는 작업에서 시작해 사용량·검토 시간·재작업률을 기록하는 것이다. 수치가 좋아질 때만 병렬 수를 늘리고, 자동 병합과 배포는 충분한 회귀 테스트가 쌓일 때까지 분리하자.