앤스로픽이 클로드 코드 프로젝트를 폴더에서 스레드와 코디네이터 구조로 바꿨다

앤스로픽(Anthropic)은 2026년 9월 17일 클로드(Claude) 프로젝트를 폴더 개념에서 대화 개념으로 다시 설계해 클로드 코드(Claude Code)에 베타로 열었다. 새 프로젝트에서는 사용자가 목표와 저장소를 지정하면 클로드가 요청의 범위를 정하고 작업을 나눠 맡기며 병렬 스레드를 조율하고 결과를 검토해 완성물로 합친다. 스레드 하나하나는 자기 브랜치와 저장소 사본 위에서 도는 클로드 코드 클라우드 세션이고, 스레드끼리 같은 코드를 건드리면 그 겹침은 일반적인 풀 리퀘스트와 똑같이 머지 충돌로 처리된다. 베타는 웹이나 데스크톱에 기존 프로젝트가 없으면서 클로드 코드에서 클라우드 세션을 쓰는 클로드 프로(Pro)와 맥스(Max) 구독자 일부에게 먼저 열렸다. ASAP은 이 구조 변경에서 편의 기능이 아니라 비용과 병합이라는 두 축이 어떻게 바뀌는지를 갈라서 읽는다.

프로젝트의 정의가 파일을 담는 폴더에서 일을 맡기는 대화로 바뀌었다

앤스로픽이 이번에 바꾼 것은 프로젝트라는 단위의 정의 자체이며, 발표문의 제목도 "폴더에서 대화로"다. 이전까지 여러 세션에 걸친 작업은 사용자가 일을 나누고, 세션 사이의 인수인계를 관리하고, 결과를 다시 꿰매는 방식이었다. 새 프로젝트에서는 무엇을 끝내야 하는지를 서술하면 클로드가 그 관리를 맡는다.

프로젝트를 시작할 때 사용자가 지정하는 것은 목표와 저장소 또는 컨텍스트다. 그러면 클로드가 곧바로 집어 들 수 있는 작업을 먼저 제안한다. 설정 가능한 항목은 프로젝트의 클라우드 환경, 커넥터, 플러그인, 지시, 모델이다.

진행 상황을 다루는 경로도 두 갈래로 갈린다. 프로젝트 메인 대화에서 전체를 지켜보며 방향을 주거나, 개별 스레드로 들어가 세부를 들여다보고 조종할 수 있다. 앤스로픽은 이 사용법을 비서실장에게 브리핑하듯 프로젝트 안의 클로드에게 브리핑하면 새 스레드나 기존 스레드로 일이 배분된다고 설명했다. 휴대폰에서도 방향을 잡을 수 있고, 컴퓨터 앞을 떠난 뒤에도 작업은 이어진다.

스레드 하나가 클라우드 세션 하나이고 브랜치 하나다

앤스로픽이 밝힌 내부 구조에서 각 스레드는 자기 브랜치와 저장소 사본 위에서 도는 클로드 코드 클라우드 세션이며, 코디네이터는 그 위에서 작업을 정리하는 역할을 맡는다. 저장소가 연결돼 있으면 스레드는 풀 리퀘스트를 열고 테스트를 돌린다. 문서가 연결돼 있으면 문서를 읽고 초안을 쓴다.

한 겹 더 쪼갤 수도 있다. 각 스레드는 필요할 때 서브에이전트와 루프, 워크플로를 써서 맡은 작업을 다시 조각내며, 앤스로픽은 큰 과제를 더 빨리 끝내기 위한 장치로 설명했다.

발표문이 예로 든 두 가지 시나리오가 이 구조의 쓰임을 보여 준다. 하나는 앱 결제 흐름의 p75 지연을 줄이겠다는 목표를 걸고 엔드포인트마다 프로파일링과 최적화 실험, 풀 리퀘스트 개설을 병렬 스레드로 돌리는 경우다. 다른 하나는 API와 웹, 모바일 저장소를 연결하고 폐기 예정인 v1 엔드포인트를 걷어내겠다는 목표를 거는 경우이며, 이때 클로드는 저장소마다 스레드를 하나씩 만들어 호출부를 옮기고 테스트를 돌리고 풀 리퀘스트를 연 다음, 어느 것을 먼저 병합해야 하는지를 알려 준다.

겹침을 막는 장치가 아니라 머지 충돌로 넘긴다는 문장이 설계의 핵심이다

이번 발표에서 가장 많은 정보를 담은 문장은 성능이 아니라 충돌 처리에 관한 것이며, 앤스로픽은 스레드들이 같은 코드를 건드리면 그 겹침이 다른 풀 리퀘스트와 똑같이 머지 충돌로 해소된다고 적었다. 코디네이터가 하는 일은 작업을 정리하는 것이지, 스레드들이 서로의 영역을 침범하지 않도록 사전에 막는 것이 아니라는 뜻이다.

이 선택은 회피가 아니라 설계 판단으로 읽는 편이 정확하다. 여러 에이전트가 같은 코드베이스를 동시에 고칠 때 충돌을 미리 막으려면 파일이나 심볼 단위로 잠금을 걸거나, 작업 범위를 사전에 겹치지 않게 분할해야 한다. 두 방법 모두 병렬성을 깎거나, 실제 코드의 의존 관계를 코디네이터가 정확히 알고 있다고 가정해야 성립한다. 브랜치와 머지 충돌에 넘기는 쪽은 이 가정을 버리는 대신 이미 수십 년간 검증된 도구에 통합 문제를 맡긴다.

대가는 사용자에게 돌아온다. 스레드 다섯 개가 동시에 풀 리퀘스트를 열었을 때, 그것들이 서로 모순되지 않는지를 확인하는 부담은 사라지지 않고 리뷰 시점으로 옮겨간다. v1 엔드포인트 예시에서 클로드가 어느 풀 리퀘스트를 먼저 병합해야 하는지 알려 준다고 적힌 부분이 이 부담을 덜기 위한 장치이며, 이 안내가 얼마나 정확한지가 병렬 스레드의 실효를 가른다. 병렬 에이전트 작업에서 어려운 부분은 일을 나누는 쪽이 아니라 합치는 쪽이고, 이번 설계는 그 어려움을 감추지 않고 익숙한 자리에 놓았다.

공유 메모리와 라이브러리가 프로젝트 단위로 쌓인다

앤스로픽이 이번 재설계에서 스레드 구조와 함께 내세운 축은 메모리이며, 모든 스레드가 공유 메모리에 기록을 더하고 거기서 필요한 것을 끌어 쓴다. 회사는 이 구조가 복잡한 프롬프트 엔지니어링의 필요를 줄인다고 밝혔다.

기억의 내용으로 제시된 예가 이 기능의 성격을 잘 보여 준다. 릴리스가 금요일로 밀렸다는 사실, 내보내기 기능을 왜 뺐는지, 빌링 서비스를 건드리기 전에 누구에게 확인해야 하는지 같은 것들이다. 코드에 적혀 있지 않고 대화와 결정에만 남는 종류의 정보다. 클로드는 사용자의 작업 방식과 소통 방식도 기억하며, 얼마나 자주 확인 요청을 보낼지, 새 스레드를 얼마나 자주 열지, 업데이트를 얼마나 상세히 쓸지를 조정하도록 요청할 수 있다.

메모리 옆에는 라이브러리가 붙었다. 사용자가 추가한 파일과 클로드가 만들어 낸 산출물을 함께 모아, 관련 자료를 찾기 쉽게 하고 새 작업이 이전 작업 위에 쌓이도록 하는 공간이다. 앤스로픽은 프로젝트가 한 번의 응답보다 오래 걸리고 부분이 여러 개인 장기 또는 에이전트형 워크플로를 위해 설계됐다고 적었다.

사용량 한도가 이 설계의 실제 가격표다

앤스로픽이 "다음 단계" 항목의 첫 문장으로 꺼낸 것은 기능이 아니라 비용이며, 프로젝트는 여러 스레드를 동시에 돌리고 각 스레드가 완전한 클로드 코드 세션이기 때문에 사용량 한도에 더 빨리 닿을 수 있다고 명시했다. 이에 대응해 프로젝트별 사용량을 확인할 수 있고, 코디네이터 대화와 워커 스레드에 쓰이는 모델과 강도 수준을 따로 고를 수 있다.

이 문단은 병렬 에이전트 제품의 경제학을 그대로 드러낸다. 스레드를 늘리면 벽시계 시간은 줄지만 총 토큰 소비는 줄지 않고, 오히려 각 스레드가 저장소 컨텍스트를 따로 읽는 만큼 늘어난다. 구독제 안에서 이 구조를 열면 한도 소진이 사용자가 가장 먼저 부딪히는 벽이 된다.

그래서 모델과 강도를 코디네이터와 워커에 따로 지정하게 한 설정이 부가 기능이 아니라 필수 장치로 보인다. 조율과 검토는 판단이 필요한 작업이라 강한 모델이 유리하고, 정해진 마이그레이션을 반복 수행하는 워커 쪽은 더 가벼운 설정으로도 충분한 경우가 많다. 이 분리가 없으면 병렬화의 이득이 한도 소진 속도에 그대로 먹힌다. 프로젝트를 써 볼 팀이 처음에 해야 할 일은 스레드를 많이 여는 것이 아니라, 두 층에 어떤 모델을 배정했을 때 한도 대비 산출이 가장 좋은지를 자기 저장소로 재 보는 것이다.

클라우드가 먼저 열리고 로컬이 나중이라는 순서가 도입 시점을 가른다

이번 베타에서 스레드는 오늘 클라우드에서만 돌고, 사용자의 기기에서 로컬 도구와 코드 옆에서 네트워크 안쪽으로 도는 방식은 곧 온다고만 적혔다. 베타 자격 조건에도 같은 방향이 들어 있다. 클로드 코드에서 클라우드 세션을 쓰는 프로와 맥스 구독자 중, 웹이나 데스크톱에 기존 프로젝트가 없는 사람에게 먼저 열렸다.

클라우드 우선이 자연스러운 이유는 이 제품의 핵심 약속에 있다. 컴퓨터 앞을 떠난 뒤에도 작업이 이어지고 휴대폰에서 방향을 잡을 수 있다는 것은 실행 주체가 사용자의 기기 밖에 있을 때만 성립한다. 로컬 실행은 같은 약속을 유지하기 어렵다.

다만 이 순서는 도입 가능한 조직을 한동안 갈라놓는다. 코드가 사내 네트워크를 벗어나면 안 되는 조직에서는 병렬 스레드의 이득을 지금 확인할 방법이 없고, 로컬 실행이 실제로 열리는 시점까지 기다려야 한다. 국내 금융이나 공공 영역처럼 망 분리와 반출 통제가 전제인 환경이 여기에 해당한다. 반대로 이미 클라우드 개발 환경을 쓰는 팀에게는 지금이 구조를 시험할 시점이다. 같은 발표 안에서 기존 프로와 맥스 프로젝트는 그대로 작동하며 롤아웃이 챗과 코워크(Cowork)로 확대될 때 업그레이드된다고 밝혀 둔 것도, 전환이 한 번에 끊기지 않게 하려는 배치로 읽힌다.

수치가 하나도 없다는 점이 이번 발표에서 가장 눈에 띄는 공백이다

앤스로픽의 이번 발표문에는 스레드 동시 실행 개수나 속도 개선폭, 성공률 같은 정량 지표가 한 건도 들어 있지 않으며, 제시된 것은 구조 설명과 두 가지 사용 시나리오뿐이다. 병렬화를 내세운 제품 발표에서 병렬화의 효과를 재는 숫자가 없다는 것은 그 자체로 읽을 거리다.

확인되지 않은 항목을 정리하면 이렇다. 첫째, 한 프로젝트가 동시에 열 수 있는 스레드 수의 상한은 밝혀지지 않았다. 둘째, 코디네이터가 어느 작업을 어느 스레드에 배분할지 정하는 기준과, 병합 순서를 안내할 때 쓰는 근거는 설명되지 않았다. 셋째, 공유 메모리가 잘못된 사실을 기억했을 때 그것을 수정하거나 지우는 경로는 이번 글에 나오지 않는다. 넷째, 베타 대상 규모와 대기자 명단의 처리 속도, "다음 주에 걸쳐" 확대되는 범위의 구체적 기준도 공개되지 않았다.

지금 상태에서 팀이 할 수 있는 판단은 하나로 좁혀진다. 자기 저장소에서 서로 독립적으로 진행 가능한 작업이 실제로 몇 갈래나 되는지를 먼저 세어 보는 것이다. 이 숫자가 작으면 스레드 구조는 한도만 더 빨리 소진하고, 이 숫자가 크면 병합 순서 안내의 정확도가 실제 이득을 결정한다. 어느 쪽이든 판단의 근거는 발표문이 아니라 자기 코드베이스에서 나온다.

출처: Projects redesigned: from folder to conversation (앤스로픽, 2026년 9월 17일)