한줄 요약
앤트로픽(Anthropic)이 클로드 코드(Claude Code)를 만든 과정을 공개했습니다. AppleScript로 음악을 바꾸던 사이드 프로젝트가 연 매출 5억 달러 규모의 제품이 되기까지, 소수의 엔지니어가 하루 5번 배포하고 기능 하나에 프로토타입 20개를 던지는 방식으로 일했습니다. 클로드 코드 개발 이야기는 'AI-first 팀'이 실제로 어떻게 굴러가는지 보여주는 드문 사례입니다.
Photo by Chris Ried on Unsplash
무슨 일이 있었나?
시작은 거창하지 않았습니다. 보리스 체르니(Boris Cherny)는 2024년 9월 앤트로픽에 합류한 뒤, 공개 API에 익숙해지려고 터미널에서 클로드를 이것저것 붙여봤습니다. 첫 버전은 파일도 못 읽고 bash도 못 쓰는 껍데기였지만, 컴퓨터와 상호작용은 됐습니다. 그가 AppleScript를 연결하자 클로드는 그가 듣던 음악을 알려주고, 지시하면 곡을 바꿔주기도 했습니다. 멋진 데모였지만 그 이상은 아니었습니다.
전환점은 파일시스템 접근이었습니다. 캣 우(Cat Wu)와의 대화 뒤 보리스가 파일을 읽고 쓰고 명령을 실행하는 도구를 붙이자, 에이전트가 갑자기 흥미로워졌습니다. 코드베이스에 질문을 던지면 클로드가 파일을 읽고, 그 안의 import를 보고, import에 정의된 파일을 또 읽으며 답을 찾을 때까지 스스로 탐색했습니다. 보리스는 이를 "제품 오버행(product overhang)"이라 표현했습니다. 모델은 이미 이걸 할 수 있는데, 그 능력을 담아낼 제품이 없었던 것입니다.
내부 확산은 빨랐습니다. 2024년 11월 도그푸딩 버전을 내놓자 첫날 엔지니어링 팀의 약 20%가, 5일 차에는 50%가 클로드 코드를 썼습니다. 흥미로운 건 공개를 두고 내부 논쟁이 있었다는 점입니다. "우리만의 비밀 병기로 두자"는 의견도 있었지만, 결국 "앤트로픽은 모델 안전 회사이고, 사람들이 쓰는 도구를 만들어야 안전과 능력을 배운다"는 논리로 공개를 택했습니다.
지금 클로드 코드는 5월 정식 출시 이후 연 매출 실행률(ARR) 5억 달러를 넘겼고, 3개월 만에 사용량이 10배 이상 늘었습니다. 앤트로픽 엔지니어의 80% 이상이 매일 쓰고, 데이터 사이언티스트들도 여러 인스턴스를 띄워 쿼리를 돌립니다.
왜 중요한가?
이 이야기가 주목받는 이유는 결과물이 아니라 일하는 방식 때문입니다.
클로드 코드 팀은 열 명 남짓이지만 배포 속도가 압도적입니다. 내부적으로 하루 60~100번 배포하고, 외부로도 거의 매일 새 버전을 냅니다. 여름 동안 엔지니어 한 명이 하루 약 5개의 풀 리퀘스트(PR)를 올렸는데, 대다수 회사에서 하루 1~2개가 보통인 것과 비교하면 상당한 속도입니다.
더 인상적인 건 팀 규모가 두 배로 커지는 동안 생산성이 떨어지지 않았다는 점입니다. 보통 팀이 급성장하면 기존 엔지니어가 온보딩에 시간을 뺏겨 인당 PR 지표가 내려갑니다. 그런데 앤트로픽은 인당 PR 처리량이 오히려 67% 늘었고, 그 공을 클로드 코드에 돌립니다. 도구가 사람의 산출을 밀어올린 셈입니다.
그리고 클로드 코드는 90%가 클로드 코드로 작성됩니다. 스스로가 스스로를 만드는 구조입니다.
AI-first 팀이 일하는 3가지 방식
앤트로픽이 공개한 내용에서 다른 조직이 참고할 만한 방식은 크게 세 가지입니다.
1. 기능 하나에 프로토타입 20개를 던진다
보리스는 새 'todo 리스트' 기능 하나를 만들며 이틀 동안 프로토타입 약 20개를 돌렸습니다. 리스트를 입력창 위에 보일지, 아래 알약(pill) 형태로 넣을지, 옆에서 서랍처럼 밀어낼지를 하나하나 프롬프트로 만들어 보고, 느낌이 좋으면 동료에게 공유하고 어색하면 새로 만들었습니다.
핵심은 프로토타이핑의 비용이 급락했다는 점입니다. 예전엔 이틀에 프로토타입 두 개만 나와도 다행이었지만, 에이전트를 쓰면 하루 5~10개를 만들어 비교할 수 있습니다. "프로토타이핑이 원래 얼마나 오래 걸렸는지는 잊는 게 낫다"는 게 이 사례의 교훈입니다.
2. 모델을 최대한 날것 그대로 느끼게 한다
팀의 설계 철학은 "비즈니스 로직을 가능한 한 적게 쓴다"입니다. 클로드 코드는 모델 위에 얹힌 가벼운 껍데기일 뿐이고, 실제 일은 모델이 거의 다 합니다. UI를 정의하고, 도구를 노출하고, 그다음엔 비켜서는 구조입니다.
보리스는 "많은 코딩 제품이 모델의 앞을 가로막는다"고 지적합니다. 도와주려고 넣은 UI 요소와 스캐폴딩이 오히려 모델을 한 발로 절뚝이게 만든다는 것입니다. 그래서 이 팀은 새 모델이 나올 때마다 코드를 지웁니다. 4.0 모델이 나왔을 때는 시스템 프롬프트의 절반을 삭제했습니다. 프롬프트를 줄이고, 도구 수를 줄이고, 모델을 최대한 raw하게 두는 방향입니다.
3. 항상 가장 단순한 선택지를 고른다
클로드 코드는 가상화 없이 로컬에서 실행됩니다. 도커 컨테이너나 클라우드에서 샌드박스로 돌릴지 고민했지만, "명령을 어디서 실행하고 파일을 어디서 읽는가"라는 질문의 가장 단순한 답이 '로컬'이었기 때문입니다.
대신 가장 공들인 부분이 권한 시스템입니다. 로컬 실행의 위험은 에이전트가 파일 삭제 같은 되돌릴 수 없는 일을 저지르는 것이라, 클로드 코드는 행동 전에 반드시 권한을 묻습니다. 한 번만 허용할지, 앞으로도 허용할지, 거부할지를 사용자가 정합니다. 이 설정은 프로젝트별·사용자별·회사별로 계층화돼 팀과 공유할 수도 있습 니다.
Photo by Florian Olivo on Unsplash
실전에서 어떻게 쓸 수 있을까?
이 사례를 우리 팀에 옮긴다면 세 가지를 시험해볼 수 있습니다.
첫째, 기획 회의를 '프로토타입 여러 개'로 대체해보는 것입니다. 어떤 UI가 좋을지 말로 토론하는 대신, 에이전트로 5개를 만들어 실제로 만져보고 고르는 방식입니다. 논쟁의 시간이 검증의 시간으로 바뀝니다.
둘째, 도구가 아니라 팀의 일하는 규칙부터 바꾸는 것입니다. 클로드 코드 팀의 속도는 도구 하나가 아니라 '하루 여러 번 배포', '내부에서 먼저 매일 쓰기', '느낌이 좋으면 바로 공유' 같은 규칙에서 나옵니다. 같은 도구를 쓰더라도 이런 리듬이 없으면 속도는 나오지 않습니다.
셋째, '단순한 선택지 우선' 원칙을 의사결정 기준으로 삼는 것입니다. 새 기능을 넣을 때 "가장 단순한 답이 뭔가"를 먼저 묻고, 복잡한 구조는 정말 필요할 때만 도입하는 방식입니다. 클로드 코드가 가상화를 포기하고 로컬을 택한 것처럼, 단순함이 오히려 속도를 만듭니다.
인사이트
이 이야기에서 가장 오래 남는 대목은 서브에이전트(subagents) 기능을 3일 만에 만들었는데 그중 이틀 작업은 버렸다는 부분이라고 봅니다. 빠른 속도의 정체는 '한 번에 잘 만드는 것'이 아니라 '틀린 걸 빨리 버리는 것'이었습니다. 프로토타입 20개를 만들 수 있다는 건 곧 19개를 미련 없이 폐기할 수 있다는 뜻이기도 합니다. 에이전트가 만드는 비용을 낮추면, 진짜 병목은 '무엇을 남길지 판단하는 안목'으로 옮겨갑니다.
다만 이 방식을 그대로 이식할 때 조심할 점도 분명합니다. 앤트로픽은 자사 모델을 만드는 회사라, 모델과 제품이 같은 지붕 아래 있고 엔지니어 전원이 도구에 중독될 만큼 도그푸딩 환경이 완벽합니다. 기술 스택도 클로드가 가장 잘 다루는 TypeScript와 React로 골라 "가르치지 않아도 스스로 만드는" 조건을 갖췄습니다. 우리 조직이 참고할 것은 특정 스택이나 배포 횟수 같은 숫자가 아니라, 그 뒤에 있는 원칙입니다. 모델을 가로막지 말 것, 가장 단순한 답을 먼저 고를 것, 그리고 만드는 비용이 싸진 시대에는 잘 만드는 능력보다 잘 버리는 판단이 팀의 속도를 결정한다는 것입니다.
원문: Anthropic — The Making of Claude Code / 세부 내용 참고: The Pragmatic Engineer — How Claude Code is built