Claude Code에 Projects 기능이 베타로 추가되었습니다. 큰 목표 하나를 맡기면 coordinator(작업을 나누고 배분하는 조정 역할의 Claude)가 목표를 여러 작업으로 쪼개고, 작업마다 클라우드의 독립된 Git 브랜치에서 도는 thread를 띄워 동시에 처리합니다. 지금까지 사람이 sub-agent를 설정하고 여러 터미널 세션과 worktree를 오가며 맞추던 조율을 Claude가 맡는 구조입니다. 현재 Pro와 Max 요금제 사용자에게 차례로 열리고 있습니다.
기존 세션과 무엇이 다른가
Projects를 이루는 요소는 세 가지입니다.
| 요소 | 하는 일 |
|---|---|
| Project | 계속 이어지는 하나의 대화이자 작업 공간 |
| coordinator | 대화 안에서 목표를 작업으로 나누고 모든 작업을 조율 |
| thread | 작업 하나를 맡는 독립된 Claude Code 세션, 클라우드의 자기 Git 브랜치에서 실행 |
여러 터미널 세션을 띄우고 sub-agent와 worktree를 직접 맞추던 조율을 coordinator가 대신한다는 점이 가장 큰 차이입니다.
thread가 클라우드에서 돌기 때문에 노트북을 닫거나 연결이 끊겨도 작업은 이어지고, 진행 상황은 휴대전화로도 확인할 수 있습니다. Chrome DevTools처럼 내 컴퓨터의 도구가 필요한 작업은 해당 thread만 로컬로 가져와 이어 갈 수 있습니다.
여러 세션이나 여러 저장소에 걸친 큰 목표에 알맞습니다. 지원이 끝난 패키지를 여러 저장소에서 한꺼번에 걷어 내는 일, API endpoint 하나를 바꾸면서 백엔드, 웹, 모바일 앱 코드를 함께 고치는 일이 대표적인 예입니다.
▲ coordinator와 thread 구조
프로젝트를 만들 때 정할 세 가지
데스크톱 앱이나 웹의 Claude 탭에서 ’New project’를 누르면 이름, 목표, 연결할 저장소나 폴더를 정하는 창이 열립니다. 웹사이트 성능 저하를 고치는 예로 보면 다음과 같습니다.
- 이름: Site Performance
- 목표: 모바일과 데스크톱 모두에서 p75 LCP 2.5초 미만, CLS 0.1 미만
- 저장소: 마케팅 사이트 저장소와 API 저장소 두 곳
LCP와 CLS는 Core Web Vitals(웹 페이지의 사용 경험을 재는 지표)에 속하는 값으로, 각각 페이지의 주요 내용이 보이기까지 걸리는 시간과 화면 요소가 갑자기 밀리는 정도를 나타냅니다. p75는 방문의 75%가 그 값 이내라는 뜻입니다. 목표를 이렇게 수치로 적어 두면 Claude가 작업을 언제 끝낼지 판단할 기준이 생깁니다.
프로젝트를 만들면 coordinator와 나누는 대화 창이 열리고, coordinator가 다음에 할 수 있는 일을 제안합니다.
문제를 알리면 계획부터 나온다
예시에서는 마케팅 사이트의 Core Web Vitals가 한 달째 나빠지고 있다고 알렸습니다. 모바일 p75 LCP가 4.1초, CLS가 0.28까지 올라갔고, 페이지 이동이 느리다는 사용자 의견이 이어진다는 내용입니다. 조사하고 고쳐 달라는 요청만 덧붙였습니다.
Claude는 두 저장소의 코드를 함께 살펴 병목을 추적한 뒤, 효과가 큰 순서로 고칠 목록을 내놓았습니다.
- 클라이언트 측 페이지 이동 개선
- 최적화되지 않은 이미지 정리
- 페이지 콘텐츠 캐싱
- 스크립트 지연 로딩
- 웹 폰트 미리 불러오기
- JavaScript 번들 분할
- 배너 자리 미리 확보
- 정적 자산 압축
개발자가 이 계획을 승인하자 Claude는 thread 8개를 띄워 각 항목을 동시에 고치기 시작했습니다. thread마다 경과 시간과 Git 브랜치 이름이 카드로 표시됩니다.
thread를 지휘하는 법
thread는 혼자 끝까지 돌 수 있지만, 사람은 언제든 들여다보고 끼어들 수 있습니다.
- 들여다보기: thread 카드를 누르면 실시간 터미널 출력, 바뀌는 코드, 현재 단계가 보입니다.
- 방향 바꾸기: thread에 직접 지시를 입력해 우선순위를 바꾸거나 바로 멈출 수 있습니다. 예시에서는 이미지 최적화 thread에 첫 화면의 대표 이미지는 우선 불러오는 이미지로 남겨 두라고 지시했습니다.
- 막힌 작업 찾기: Threads 사이드바가 실행 중인 thread와 사람의 입력을 기다리며 멈춘 thread를 따로 보여 줍니다.
작업을 마친 thread는 GitHub에 pull request(PR, 코드 변경을 합쳐 달라는 요청)를 자동으로 열거나, 올리기 전에 사용자에게 먼저 묻습니다. 예시의 수정에는 이미지 태그 34개에 너비와 높이를 지정하는 작업도 들어 있었습니다. PR을 연 뒤에도 thread는 CI(코드를 올릴 때마다 자동으로 도는 빌드·테스트) 결과를 지켜보다가 테스트가 실패하면 고치고, 리뷰 의견도 반영합니다. coordinator 대화에는 PR 상태가 요약되고, 승인한 변경은 그 대화에서 바로 병합할 수 있습니다.
예시 프로젝트의 결과는 다음과 같습니다.
| 지표 | 고치기 전 | 목표 | 고친 뒤 |
|---|---|---|---|
| 모바일 p75 LCP | 4.1초 | 2.5초 미만 | 2.2초 |
| 데스크톱 p75 LCP | - | 2.5초 미만 | 1.4초 |
| CLS | 0.28 | 0.1 미만 | 0.08 |
▲ 성능 지표 개선 결과
Library에 남는 결과물
Projects에는 artifact(Claude가 만든 문서나 결과물)를 모아 두는 Library 탭이 있습니다. 예시에서는 작업을 마친 뒤 해결한 문제와 고치기 전후 수치를 정리한 post-mortem(사후 분석 보고서)을 요청했고, Claude는 모바일 LCP, 데스크톱 LCP, CLS를 비교하는 막대그래프가 들어간 보고서를 만들었습니다.
Library는 프로젝트가 계속 쓰는 공유 폴더 역할을 합니다. 만든 문서뿐 아니라 직접 올린 화면 시안이나 기술 명세도 둘 수 있고, 지금 도는 thread와 앞으로 만들 thread가 모두 이 자료를 읽고 고칠 수 있습니다. 다음 작업이 앞선 작업의 맥락을 이어받는 통로인 셈입니다.
Connector와 routine으로 매일 점검하기
Projects는 Connector로 외부 개발 도구와 모니터링 서비스에 연결됩니다. Environment 설정에서 Sentry connector를 켜면 Claude가 실제 사용자 지표와 오류 로그를 직접 조회할 수 있습니다.
여기에 Routine(정해 둔 시각에 자동으로 도는 작업)을 더하면 문제가 생긴 뒤에 고치는 방식에서 먼저 찾아내는 방식으로 바뀝니다. 예시에서는 매일 오후 5시에 Sentry에서 마케팅 사이트의 Core Web Vitals와 오류 로그를 가져와, 나빠진 지표가 있으면 조사하고 고치라고 지시했습니다. 점검에서 성능 저하가 발견되면 Claude가 조사용 thread를 새로 띄우고, 수정안을 담은 draft PR(검토용 초안 PR)을 열어 둡니다.
사용량을 아끼는 설정
thread 하나하나가 온전한 Claude Code 세션이라, thread를 여러 개 동시에 돌리면 요금제 사용 한도가 대화 하나를 쓸 때보다 훨씬 빨리 줄어듭니다. Claude Code 개발팀이 권하는 설정은 다음과 같습니다.
| 설정 | 권장값 | 까닭 |
|---|---|---|
| coordinator의 추론 수준(effort) | Low | 작업을 나누고 배분하는 역할이라 깊은 추론이 필요 없음 |
| thread 기본 모델 | Sonnet 5.5 | 범위가 분명한 작업은 작은 모델로 충분 |
| 어려운 thread | Opus 5.5 | 깊은 추론이 필요한 작업에만 사용 |
| 동작 규칙 | 동시 thread 상한, 코드 작성 전 계획 제출 | 한꺼번에 많은 thread가 도는 것을 막음 |
모델과 effort는 General 설정에서 coordinator와 thread를 따로 정하며, 가벼운 Haiku 4.5도 고를 수 있습니다. coordinator의 effort를 Low보다 올려도 조율 품질은 크게 나아지지 않고 token 비용만 늘어나는 것으로 보입니다. 동시 thread 상한 같은 규칙은 coordinator 대화에 적어 주면 되고, 예시에서는 한 번에 최대 5개로 제한했습니다.
프로젝트 전체에 적용할 규칙은 프로젝트 메모리에 둡니다. 설정의 MEMORY.md 파일에 코딩 규칙과 선호를 적으면 지금의 thread와 앞으로 만들 thread가 모두 이 내용을 이어받습니다. 입력 상한은 16,000자입니다.
처음 써 볼 때의 순서
Projects는 한 번의 prompt로 끝나는 작업보다, 여러 저장소와 여러 단계에 걸친 목표를 맡길 때 효과가 커 보입니다. 다음 순서로 시작해 볼 수 있습니다.
- 여러 저장소나 세션에 걸친 목표 하나를 고르고, 끝났는지 판단할 수 있게 수치로 적습니다.
- 관련 저장소를 모두 연결하고, coordinator가 내놓은 계획을 검토한 뒤 승인합니다.
- coordinator effort는 Low, thread 기본 모델은 Sonnet 5.5로 두고 동시 thread 상한을 정합니다.
- 팀의 코딩 규칙을 MEMORY.md에 적어 모든 thread가 따르게 합니다.
- 같은 점검을 되풀이한다면 Connector와 Routine으로 자동화합니다.
아직 베타라서 기능과 화면은 앞으로 바뀔 수 있습니다. thread를 많이 띄울수록 사용 한도가 빨리 줄어든다는 점을 염두에 두고, 작은 목표부터 시험해 보는 편이 안전합니다.