앤스로픽, 클로드 코드 프로젝트 로컬 실행 지원

앤스로픽이 9월 23일(미국 시간) 클로드 코드의 프로젝트 기능에 로컬 실행 지원을 추가했어요. 개발자 공식 계정 ClaudeDevs는 X에 "클로드 코드의 프로젝트에 로컬 지원을 더해, 이제 스레드가 여러분의 컴퓨터에서 돌아갈 수 있다"고 밝혔어요. 9월 17일 베타로 공개한 프로젝트는 그동안 모든 작업을 클라우드 세션에서만 돌렸는데, 엿새 만에 실행 범위를 사용자의 기기로 넓힌 거예요.

프로젝트는 대화 하나가 여러 작업을 지휘하는 구조예요. 앤스로픽의 9월 17일 발표에 따르면 사용자가 할 일을 말하면 클로드가 일을 스레드로 쪼개 병렬 클라우드 세션으로 돌리고, 스레드 사이에 맥락을 넘기며, 사용자가 자리를 떠도 일을 이어가요. 이 출시 게시물은 조회수 237만 회, 좋아요 1만 1,404개를 기록했어요.

안쪽은 두 층으로 나뉘어요. 공식 문서에 따르면 프로젝트 대화 속 클로드는 코디네이터로서 무엇을 스레드로 만들지 정하고, 스레드는 각자 별도 컨텍스트 창을 가진 클라우드 세션으로 자기 브랜치에서 한 가지 일을 맡아 필요하면 풀 리퀘스트를 연 뒤 결과를 보고해요. 코디네이터는 스레드가 보고한 내용만 보고 모든 단계를 들여다보지는 않아요. 두 스레드가 같은 코드를 건드리면 겹친 부분은 일반 풀 리퀘스트처럼 머지 충돌로 처리돼요. 회사는 블로그에서 "비서실장에게 브리핑하듯 프로젝트에서 클로드에게 브리핑하면 작업을 새 스레드나 기존 스레드로 보낸다"고 설명했어요.

이번 로컬 지원은 예고된 순서였어요. 앤스로픽은 출시 블로그에 "스레드는 오늘은 클라우드에서 돌지만, 로컬 도구와 코드 곁에서, 네트워크 안쪽의 여러분 컴퓨터에서 돌리는 기능이 아주 곧 나온다"고 적었어요. 클라우드 스레드는 GitHub 저장소와 업로드한 파일만 다룰 수 있어서, 로컬 데이터베이스나 기기 에뮬레이터, VPN 뒤의 API처럼 사용자 컴퓨터에서만 닿는 자원이 필요한 일은 문서가 프로젝트 대신 로컬 세션을 권하던 영역이에요.

이용자 쪽 요구도 있었어요. 출시 이튿날 한 X 이용자(@tropoFarmer)는 출시 게시물에 윈도우에서 로컬 폴더를 추가해도 아무 반응이 없고 프로젝트를 만든 뒤에는 저장소 말고 맥락을 더할 방법이 없다고 적으며 "로컬 워크플로에서는 이게 어떻게 작동하나요?"라고 물었어요.

메탈이 9월 24일 오후 확인한 공식 문서에는 아직 클라우드 전용 설명이 남아 있어요. 문서의 제약 항목은 로컬 세션은 프로젝트의 일부가 될 수 없다고 적고 있고, 프로젝트는 터미널 CLI와 아마존 베드록, 구글 클라우드 에이전트 플랫폼, 마이크로소프트 파운드리에서는 쓸 수 없다고 안내해요. ClaudeDevs의 게시물은 한 문장이라 어떤 요금제와 운영체제에서 로컬 스레드를 쓸 수 있는지, 로컬 스레드가 코디네이터와 어떻게 이어지는지는 공개되지 않았어요. 이 게시물은 같은 시각 조회수 31만 6,576회를 기록했어요.

이용 조건은 출시 때와 같아요. 앤스로픽에 따르면 베타는 클로드 코드에서 클라우드 세션을 쓰면서 기존 웹·데스크톱 프로젝트가 없는 일부 Pro·Max 구독자부터 열렸고, 같은 요금제의 더 많은 이용자로 넓힌 다음 클로드 전체와 Team·Enterprise 요금제로 간다고 회사는 밝혔어요. 기존 Pro·Max 프로젝트는 지금처럼 작동하다가 채팅과 코워크로 배포가 넓어질 때 업그레이드돼요. 메탈은 앤스로픽이 9월 16일 코워크와 채팅을 하나의 클로드로 합쳤다고 보도한 바 있으며, 프로젝트 개편은 그 이튿날 나왔어요.

엔지니어가 먼저 볼 대목은 비용 구조예요. 문서에 따르면 새 프로젝트는 스레드를 Opus 높은 추론 강도로, 코디네이터 대화를 Opus 낮은 강도로 돌리고, 스레드 하나하나가 완전한 세션이라 단일 세션보다 요금제 한도를 빨리 써요. 강제 상한은 모든 프로젝트를 합쳐 하루 새 스레드 200개예요. 풀 리퀘스트를 지켜보는 유휴 스레드는 CI가 실패하거나 리뷰 댓글이 달리면 다시 깨어나 한도를 쓰고, Pro·Max에서 캐시 수명 1시간을 넘긴 스레드에 후속 작업을 보내면 그 스레드는 대화 전체를 다시 읽어요.

맥락은 한 번 정하면 모든 스레드로 가요. 프로젝트 지침은 최대 1만 6,000자까지 새 스레드와 코디네이터에 전달되고, 프로젝트 메모리는 MEMORY.md 색인 파일로 저장돼 모든 스레드가 시작할 때 읽어요. 개요 창은 스레드를 리뷰 대기, 응답 대기, 작업 중, 머지 진행, 유휴, 완료 여섯 묶음으로 나누고, 일주일 동안 움직임이 없는 스레드는 자동으로 완료 처리돼요.

메탈이 확인한 출시 시연 영상 26초에는 이 흐름이 그대로 담겨 있어요. 사용자가 배포 뒤 체크아웃 경로의 p99 지연이 두 배가 됐으니 찾아 고치고, 금요일 릴리스 노트를 쓰고, stripe-node를 v15로 올리라고 한 번에 입력하자 클로드는 스레드 세 개를 띄워요. 릴리스가 월요일로 옮겨졌다는 말을 덧붙이자 코디네이터는 그 메시지를 릴리스 노트 스레드로만 넘기고, stripe-node 스레드가 Node 18 문제로 막히자 응답 대기 칸에 올려 사용자의 결정을 받아요.

TPM의 눈으로 보면 로컬 지원은 프로젝트가 맡을 수 있는 일의 경계를 바꿔요. 클라우드 전용일 때 프로젝트는 GitHub에 올라간 코드와 업로드한 파일로 끝나는 일에 맞춰져 있었고, 사내망 서비스나 로컬 도구가 필요한 일은 개발자가 여러 세션을 직접 조율해야 했어요. 스레드가 개발자 컴퓨터에서 돌 수 있게 되면 코디네이터 하나가 클라우드 작업과 로컬 작업을 함께 나눠 맡기는 구조가 가능해져요. 팀이 확인할 다음 질문은 문서가 아직 설명하지 않는 부분, 곧 로컬 스레드가 사용자 컴퓨터의 권한과 네트워크를 어디까지 쓰는지예요.