본문으로 건너뛰기

Claude Code는 어떻게 태어났나

게시일: 2026년 7월 7일 | 원문 작성일: 2026년 7월 7일 | 저자: Anthropic | 원문 보기

A warm coral-framed terminal window glowing against a dark charcoal background, showing a blinking cursor at a command prompt and a code diff of green added lines and red removed lines.

핵심 요약

2022년의 VS Code 확장 실험, 시대를 너무 앞서갔던 내부 도구 clide, Boris Cherny의 “Claude CLI” 데모 같은 조각이 여러 해에 걸쳐 쌓이고 이어져 Claude Code가 됐어요. 이 글은 그 과정을 직접 겪은 앤트로픽 안팎의 사람들이 들려주는 구술사예요.

  • 씨앗은 2021~2022년에 뿌려졌다 — 소프트웨어 엔지니어링 업무를 상당 부분 자동화하는 일이 변혁적 AI로 가는 길목이라 보고, 앤트로픽은 아주 일찍부터 코딩 모델과 에이전트 학습 인프라를 만들기 시작했어요.
  • 불씨는 clide와 Claude CLI 데모 — 투박하지만 “미래를 본” 내부 도구가 있었고, Boris가 이틀 만에 만든 데모는 동료들이 곧바로 쓰기 시작했죠.
  • 작은 팀, 2주 스프린트 — 일부러 팀을 작게 유지하며 Claude로 직접 개발했고, 지금 쓰는 핵심 기능 상당수가 단 2주 만에 만들어졌어요.
  • 2025년 2월 Claude Code로 출시 — 출시 전 반응은 미지근했지만 과감히 외부에 공개했고, Claude 4 모델과 구독제가 맞물리며 진짜 도약이 시작됐어요.
  • 만든 사람들도 이제 손으로 코딩하지 않는다 — Boris와 Igor는 2025년 겨울부터 코드를 손으로 한 줄도 쓰지 않고, Shauna는 Claude 열두 개를 한꺼번에 돌려요.

• • •

1. 시작

BEN MANN

앤트로픽 공동창업자이자 Labs 팀 리드

앤트로픽을 시작하고 결국 제품을 내기로 결정했을 때, 우리가 가장 먼저 만든 게 코딩 어시스턴트였어요. 제품을 만든다는 결정부터가 논쟁거리였지만요. 그 어시스턴트는 VS Code 확장이었는데, 채팅으로 대화할 수 있었고 프롬프트를 하나 넣을 때마다 어떻게 하면 좋을지 제안을 네 가지씩 내놓았어요.

SHAUNA KRAVEC

앤트로픽 강화학습(RL) 총괄

2022년 초에 우리는 이미 코딩 어시스턴트를 구상하면서, 소프트웨어 엔지니어링을 자율적으로 해낼 수 있는 모델을 만들 궁리를 하고 있었어요. 최초의 RL 코드베이스를 만들었고, 에이전트 학습 전반을 어떻게 할지도 알아냈어요.

코딩에 관심을 둔 건, 변혁적 AI에 이르려면 소프트웨어 엔지니어링 업무의 상당 부분을 자동화할 수 있어야 할 거라고 봤기 때문이에요.

DAWN DRAIN

앤트로픽 리서치 엔지니어

2021년에 앤트로픽에 들어온 뒤 첫 3년 동안 제 주력 프로젝트는, 코딩을 가능한 한 잘하는 모델, 적어도 저만큼은 해내는 모델을 만들어 보는 거였어요.

SHAUNA KRAVEC

RL 학습은 쉬운 과제부터 시작했어요. 모델이 간단한 함수를 짤 수 있을까? 그다음엔, 함수를 짜게 하고 그게 맞는지 테스트까지 시킬 수 있을까? 처음엔 모델들이 아주 형편없었어요.

BEN MANN

초기 코딩 어시스턴트는 2022년 봄에 꽤 인기가 있었어요. 외부 사용자가 100명쯤 됐어요.

SHAUNA KRAVEC

에이전트 코딩에 필요한 인프라는 챗봇용보다 훨씬 복잡해요. 특히 코드 실행을 생각하면, 코드가 실제로 어떤 환경에서 돌아가는지, 그걸 어떻게 안전하고 효과적으로 관리할지 고민해야 하죠. 지금(2026년) 사람들이 에이전트를 다루며 겪는 문제 상당수가 그때 우리가 겪던 문제와 똑같아요.

DAWN DRAIN

2022년에 부딪힌 또 다른 까다로운 문제는 하네스 설계였어요. 하네스는 모델을 둘러싼 발판 같은 건데, 모델이 실제로 행동할 수 있게 해 주죠. RL 팀 동료 한 명과 저는 컨테이너 안에서 상태가 유지되는 셸(persistent shell)을 띄우는 데 성공했어요. 그 덕에 모델이 코드를 실행하고, 입출력을 스트리밍하고, 타임아웃 상황도 매끄럽게 넘길 수 있게 됐어요.

BEN MANN

육아휴직에서 돌아와 API 첫 버전을 출시하는 걸 도왔고, 그러다 보니 우리는 한동안 코딩 어시스턴트를 거의 잊고 지냈어요.

DAWN DRAIN

하지만 리서치 쪽에서는, 모델을 에이전트 코딩에 더 능숙하게 만드는 작업을 계속 밀고 나갔어요.

2. 불씨

SHAUNA KRAVEC

2022년 말에 우리는 좀 더 개방형(open-ended) 에이전트를 다루고, 그걸 실제로 쓸모 있게 만드는 쪽으로 방향을 틀었어요. 2023년에 들어서는 기본적인 함수 호출, 약간의 검색, 그 밖의 자잘한 것들을 할 수 있게 됐어요.

BEN MANN

Shauna 팀은 엄청난 진전을 보이고 있었어요. 모델에게 bash 도구를 쥐여주고, 여기저기 검색도 할 수 있게 해 주는 방법을 알아냈죠. 바로 이런 게 에이전트 코딩을 돌아가게 하는 핵심 조각이에요.

DAWN DRAIN

저는 Claude에게 diff를 쓰는 법을 가르치려고 애쓰느라 창피할 만큼 오랜 시간을 썼어요. 텍스트로 편집을 표현하는 가장 자연스러운 방법이 diff라고 생각했거든요. 결국 우리는 clide라는 걸 만들었어요. 이 이름은 예전 형태의 도구에 동료 Eli Tran-Johnson이 붙였던 거예요. 기본적으로는 내부 커맨드라인 도구였고, 이걸로 코드 편집이나 개발 작업을 두고 Claude와 대화할 수 있었어요.

SHAUNA KRAVEC

삐걱거렸어요. 정말, 정말 시대를 앞서갔죠.

BEN MANN

저는 짬날 때마다 clide를 이리저리 손봤어요. 그 도구가 정말 마음에 들었어요. 훌륭하다고 생각했지만, 훨씬 더 좋아질 수 있겠다 싶었어요.

DAWN DRAIN

clide에는 Claude Haiku 백 개를 병렬로 띄우는 기능이 있었어요. 그래서 컨텍스트 창에는 도저히 다 담기지 않을 폴더 하나를 통째로 놓고도 질문을 던질 수 있었어요. 페어 프로그래밍을 하다가 clide를 꺼내 질문에 답하곤 했는데 그게 무척 재미있었어요. 그럴 때마다 사람들은 이런 멋진 도구를 어떻게 알았냐고 물었고요.

SID BIDASARIA

Labs 팀 기술 스태프이자 Claude Code의 두 번째 엔지니어

다들 clide 얘기를 했지만, 정작 clide는 투박했고 켜지는 데도 너무 오래 걸렸어요.

ADAM WOLFF

Claude Code 팀의 첫 매니저

clide의 에이전트 기능은 제가 Labs로 옮기기 전 막바지에 넣은 기능이었어요. clide에는 bash 도구가 없어서 할 수 있는 게 제한적이었어요. 저는 부분적인 변경만 보고도 사용자가 뭘 하려는지 clide가 추론할 수 있게 해 놨어요. 그러니 걸음마 단계의 에이전트(baby agentic)였던 셈이죠.

그게 처음 제대로 작동했을 때, 저는 부엌을 돌아다니며 춤을 췄어요. 믿기지가 않더라고요.

BEN MANN

2024년 1월에 저는 Labs 팀을 꾸렸어요. 에이전트 코딩 시장에 빈틈이 보였거든요. 그해 9월에 Labs에 합류한 Boris는 린터를 만들고 싶어 했어요. 에이전트 코딩의 작은 조각 하나만 떼어 맡으려 한 거예요. 저는 “안 돼, 안 돼, 안 돼, 안 돼. 큰 걸 해야지” 했죠.

BORIS CHERNY

Claude Code 총괄

clide를 작동시키려면 온갖 주문을 외워야 했어요. 대단한 소프트웨어는 아니었어도, 어떤 면에선 놀랍고 마법 같았죠. 미래를 내다본 도구였으니까요.

제가 풀 리퀘스트 하나를 처음부터 끝까지 손으로 써 놨는데 Adam이 거절했어요. 그러면서 “사실 이건 clide로 하면 돼”라고 하더라고요. 그래서 저는 --string-edit인가 뭔가를 작성했어요. 이슈를 그냥 복사해서 clide에 붙여넣었더니 풀 리퀘스트를 통째로 써줬어요. 다섯 줄이나 열 줄짜리 풀 리퀘스트였는데, 그런 건 처음 봤어요. 그냥 충격이었죠.

미래가 온 것 같았어요.

BEN MANN

Boris 반응이 딱 “이런 미친”이었어요. 조각들은 이미 눈앞에 있었고, 그걸 하나로 합치기만 하면 됐던 거죠.

RAPHAEL LEE

Labs 팀의 첫 엔지니어링 매니저

Boris는 에이전트 코딩 영역을 맡게 됐어요. 어떤 식으로 접근할지도 생각이 아주 분명했어요.

BORIS CHERNY

제가 처음 맡은 과제는 “코딩을 자동화하라”였어요. 그래서 이렇게 생각했어요. “좋아, 우선 API 쓰는 법부터 배워야겠다.” 그때까지 API를 써본 적이 없었거든요. 이것저것 만져보기 시작했는데, 우리가 정확히 뭘 만들고 싶은 건지는 몰랐어요.

그렇게 이리저리 뚝딱거리다가, 제가 “Claude CLI”라고 이름 붙인 데모를 하나 만들었어요.

Claude CLI 데모가 뭔지 아무도 이해하지 못했어요. 저도 사실 잘 몰랐고요. 그런데 지금 다시 보면, 그때의 요소들이 아직 그대로 남아 있는 게 보여요. 제가 무슨 음악을 듣고 있는지 알아봐 달라고 했더니, 그냥 Apple Music을 스크린샷으로 찍어서 읽어냈어요. 어딘가 마법 같아요. 알아서 해내는 거예요.

이건 대략 이틀치 작업이었어요. 지금 Claude Code로 이걸 다시 만든다면 2분이면 될 거예요.

저는 이걸 슬랙에 올렸어요. 좋아요를 두세 개 받은 것 같네요.

IGOR KOFMAN

Labs 팀 기술 스태프

제가 보기엔 이게 옳은 접근이라는 게 분명했어요.

BORIS CHERNY

이걸 올린 다음 날, 출근해서 Robert가 일하는 걸 봤는데 코드 변경을 표시하는 그 빨간 줄과 초록 줄을 알아봤어요. 지금은 거의 상징처럼 된 모습이죠. Robert는 “응, 이게 내 대신 코딩하고 있어” 하더라고요. 정말 말도 안 되는 일이었어요. 이게 진짜로 쓸모가 있었던 거예요.

ROBERT BOYCE

Labs 팀 기술 스태프

그때 정확히 뭘 하고 있었는지는 기억이 안 나요. 아마 Claude 데스크톱 앱 관련 작업이었을 거예요. 그 앱은 당시엔 아주 단순했어요. 루프 안에 도구 정의를 넣은 것과 간단한 REPL UI, 딱 그 정도였어요.

BORIS CHERNY

당연히 완성도와는 정말, 정말 거리가 멀었어요. 그래도 이걸 붙잡고 제대로 만들어야 한다는 절박함을 강하게 느꼈어요. 주말마다 일하기 시작했죠. 친구들은 “무슨 일이야? 놀러 나와!” 했지만, 도무지 머릿속에서 떨쳐낼 수 없는 무언가가 있었어요. 지금도 그때만큼 절박하게 느껴져요.

IGOR KOFMAN

앤트로픽에 처음 왔을 때 저는 엔지니어가 아닌 사람들도 AI의 힘을 누릴 수 있게 하는 일을 하고 싶었어요. 코딩은 누가 봐도 우리가 틀림없이 풀어낼 문제 같았어요. 그래서 그보다 덜 뻔한 걸 해 보고 싶었죠. 그런데 석 달쯤 지나서, 코딩이야말로 집중해야 할 분야라는 걸 깨달았어요. 다른 모든 걸 이루려면 반드시 거쳐야 하는 길목이니까요.

3. 팀

ADAM WOLFF

저는 대학에서 컴퓨터과학이 아니라 영화를 전공했어요. 그래도 컴퓨터로 뭔가 만드는 건 늘 좋아했어요. 1993년에 Wired 잡지 창간호를 읽고 “세상에, 나도 이 판에 끼어야겠다” 싶었죠. 그래서 베이 에어리어로 이사했어요. 커리어 초반엔 게임 디자이너였다가 나중에 프로그래머가 됐어요. 그러다 결국 React1라는 큰 프로젝트에 참여하게 됐는데, 지금은 아주 인기 있는 웹 프레임워크죠.

BORIS CHERNY

제가 Adam에게 우리 매니저가 되어 달라고 부탁했어요. 처음엔 Adam이 다시 실무자(IC)로 돌아가고 싶다며 여러 번 거절했는데, 제가 계속 조르고 같이 맥주도 몇 잔 마시면서 결국 승낙을 받아냈어요.

IGOR KOFMAN

저는 일곱 살쯤 BASIC으로 코딩을 시작했어요. 처음 만든 소프트웨어는 다섯 살짜리 남동생에게 수학을 가르치는 게임이었어요. “2 더하기 2는 뭘까?” 그리고 맞히면 음악이 나왔어요. 그때 우리는 우크라이나에 살았는데, 그 게임은 아마 서방에서 들여온 컴퓨터에서 돌아갔을 거예요. 테이프를 넣어 쓰는 기계였고, 코모도어 642였던 것 같아요.

FIONA FUNG

Claude Code 및 Cowork 조직 리더

토론토 대학에서 만든 Turing3이라는 언어가 있었는데, 저는 그걸로 첫 게임을 만들었어요. 꼭 예술 같았어요. 프로그래밍으로 이야기를 들려주고 무언가를 창조할 수 있거든요.

CAT WU

Claude Code 프로덕트 총괄

저는 2024년 여름에 앤트로픽에 합류했어요. Boris가 Claude CLI 데모를 올렸을 때, 저는 그걸 RL 환경을 구축하는 데 쓰기 시작했는데, 작업이 얼마나 빨라지는지 보고 감탄했어요.

저는 Boris에게 몇 문단씩 되는 피드백을 보내고 있었어요. 그러면 Boris는 그에 못지않게 빠르게, 요청한 것들 상당수를 기능이나 수정으로 반영했다고 답을 주더군요. 그때 저는 아마 꽤 활발한 사용자 축에 들었을 거예요. 그러다 이렇게 묻더라고요. “이거 같이 할래요?”

MEAGHAN CHOI

앤트로픽 프로덕트 디자이너

제가 팀과 처음 연이 닿은 건 아마 2024년 12월이었을 거예요. CLI 도구를 위한 디자인은 흔한 일이 아니죠. 그런데 Claude CLI를 보고 이런 생각이 들었어요. “이거 멋진 제품이 될 수 있겠는데, 디자인의 손길만 조금 더하면 되겠어.” 그래서 2주짜리 짧은 집중 작업(spike)을 해봐도 되겠냐고 물어봤어요.

SID BIDASARIA

저는 2024년 8월에 Labs 팀에 합류했어요. Boris에게 멋진 CLI가 있길래 거기에 뛰어들었어요. 저는 커리어 내내 한 분야만 파 본 적이 없고, 개발자 도구나 코딩 도구를 만들어본 적도 없었어요. 완전히 새로운 일이었어요.

4. 개발

BORIS CHERNY

2024년 10월, 저는 죽어라 매달렸어요. 매주 “Raph, 엔지니어 좀 주세요, 제발!” 하고 졸랐죠.

RAPHAEL LEE

우리는 앤트로픽 Labs를 거의 통째로 Claude Code에 투입했어요. 나머지는 MCP4 팀이 됐고요. 더 빨리 채용할 수 있었으면 좋았을 텐데요! 초기엔 팀이 주로 내부 이동과, 느리지만 수준 높은 외부 채용으로 커졌어요.

ADAM WOLFF

팀을 키우는 건 참 양날의 검이에요. Boris는 팀을 빨리 키우자고 강하게 밀어붙였지만, 저는 정반대를 원했고, 할 수 있는 한 브레이크를 걸었어요. 일손이 늘어나는 건 좋지만, 규모가 커지면 프로세스든 문화든 비전이든 전부 다루기가 더 어려워지거든요.

저는 이걸 초기 실험으로도 봤어요. Claude Code가 엔지니어링 팀을, 그리고 생산성에 대한 우리의 기대치를 어떻게 바꿀지 가늠해 보는 실험이요. 비교적 작은 팀인데도, 우리는 제가 이제껏 본 적 없는 속도로 기능을 쏟아내고 버그를 때려잡았어요.

BORIS CHERNY

돌이켜보면, 팀을 작게 유지한 게 사실 우리 성공에 아주 중요했어요. 덕분에 가진 자원을 무척 창의적으로 쓸 수 있었고, 과잉 설계(overengineering)에 빠지지 않았죠. Claude를 더 많이 쓸 수밖에 없기도 했어요. 안 그러면 그 속도를 낼 수가 없었으니까요.

SID BIDASARIA

2024년 12월까지 이걸 붙잡고 있던 건 저와 Boris뿐이었고, Ben이 조금 거드는 정도였어요. 승인이 떨어지자 Labs 팀과 다른 몇몇 팀에서 여섯일곱 명이 뛰어들었고, 우리는 마지막 2주 스프린트를 시작했죠. 지금 여러분이 쓰는 핵심 기능 상당수가 그 2주 안에 만들어졌어요. 버그 리포트나 로그인 흐름 같은 것들요. 그 스프린트 때 “좋아, 이거 진짜 물건이 돼 가는구나” 하는 느낌이 들었어요.

ADAM WOLFF

React 때도, 페이스북 안에서 쓰기 좋게 만들려고 한 일들 덕분에 외부 사람들까지 React를 쓰기 시작했어요. 우리는 장점이 뭔지, 어디에 함정이 있는지, 어떤 길이 있는지 더 잘 이해하게 됐죠. Claude Code도 마찬가지였어요.

SID BIDASARIA

코드베이스에는 PR 제한도, 리뷰 제한도 없었어요. 수정 사항은 그냥 바로 배포했어요. Boris가 초기에 정말 대단한 걸 해 놨는데, 자동 업데이트와 제대로 된 사용자 지표를 미리 심어 둔 거예요. 그래서 누가 찾아와 “이건 별로예요”라고 하면 곧바로 수정을 배포할 수 있었고, 그 사람은 5분 뒤면 그걸 받아봤어요.

RAPHAEL LEE

피드백이 쏟아지기 시작했어요. Boris와 Sid는 모든 코멘트에 몇 분 안에 답했고, 종종 당일이나 심지어 한 시간 안에 PR을 올렸죠. Claude Code는 워낙 금방금방 고칠 수 있는 물건이었으니까요.

SID BIDASARIA

웹 앱이 아니라 CLI 제품이었으니, 씨름할 복잡한 아키텍처가 없었어요. 클라이언트 애플리케이션일 뿐이라 반복 개발도 무척 빨랐죠. 아주 단순해요.

BEN MANN

모델 제품화를 오래 해보지 않은 사람들에겐 잘 와닿지 않는 얘긴데요, 지금은 성공률이 20~30퍼센트밖에 안 되는 걸 만들어 놔야, 다음 모델이 나왔을 때 성공률이 80퍼센트가 돼요. 시장의 호응을 얻기엔 그 정도면 충분하죠. 그다음 모델에선 90몇 퍼센트가 되고, 그때부터 진짜로 앞으로 나아가는 거예요. 게다가 맷집도 아주 좋아야 해요. 거듭 헛다리를 짚을 테니까요.

지금에 충실해야 하지만, 동시에 미래를 바라봐야 해요.

5. 출시

CAT WU

출시 전 얼리 액세스 프로그램에서는 미지근한 반응을 받았어요. 멋진 아이디어라고 느낀 사람도 있었지만, 버그가 엄청 많았어요. 그래도 우리는 과감히 뛰어들어 2025년 2월에 외부에 출시했어요.

바로 그때 Claude CLI의 이름을 공식적으로 Claude Code로 바꿨죠. 프로덕트 마케팅의 Alex Isken이 이 이름을 제안했어요. 우리는 그 단순함이 마음에 들었어요.

IGOR KOFMAN

출시를 앞둔 어느 늦은 밤, “ASCII 로고가 있으면 멋지지 않을까?” 하는 생각이 들었어요. Claude와 함께 ASCII 아트 폰트를 채워 나갔고, 그걸로 누구나 알아보는 Claude Code 대문자 로고를 만들었어요. 로그인할 때 나오는 작은 즐거움이었어요.

MEAGHAN CHOI

제가 제일 좋아한 건 터미널에 작은 “Clawd” 캐릭터를 넣은 거예요. Clawd는 원래 Sam McAllister가 Claude 3.5 Sonnet 출시 때 만든 캐릭터예요. 제품에서 이런 걸 해 볼 기회는 좀처럼 없거든요.

AUSTIN RAY

Ramp의 AI DevX 리드이자 스태프 소프트웨어 엔지니어

저는 커리어 내내 CLI 파였어요. 그래서 틈만 나면 터미널에 붙어 있었죠. Claude Code가 (2025년 2월에) 리서치 프리뷰로 공개된 뒤, 누군가 그 얘기를 올린 글을 보고 알게 됐어요. 쓰기 시작한 지 5분 만에 “아, 이건 모든 걸 근본적으로 바꿔놓겠구나” 싶었어요.

KYLE EASTERLY

Delve Group CEO이자 Claude 커뮤니티 앰배서더

여덟, 아홉 살 때 조부모님과 캠핑카 여행을 하다가 코딩을 배웠어요. 할아버지에게 노트북이 있었는데, 거기 DOS 배치 파일 도움말 매뉴얼이 들어 있었어요. 저는 if 문만으로 범죄 현장을 수사하는 작은 탐정 게임을 만들었어요.

훌쩍 건너뛰어 2025년, 저는 알래스카 주 자립생활위원회(Statewide Independent Living Council of Alaska)라는 비영리단체의 소프트웨어 프로젝트에서 컨설턴트로 일하고 있었어요. 장애 청소년을 지원하는 곳인데, 고등학생들을 모아 졸업 후에 하고 싶은 일을 두고 목표를 세우게 해요. 워크숍은 펜과 종이로 진행했고, 끝까지 마치는 아이는 열 명 중 한 명꼴이었어요.

그 단체에 줄 앱을 만들기 시작했을 때 저는 이미 Claude를 쓰고 있었어요. Workbench에서 Claude와 주고받으며 파일 여러 개를 클립보드에 복사해 붙이고, 태그로 감싸는 식이었죠. 그 프로젝트를 하는 사이에 Claude Code가 공개됐고, 저는 도중에 휙 갈아탔어요.

AUSTIN RAY

처음 쓸 때 소름이 돋았어요. 읽고, 편집하고, bash를 실행할 수 있다면 뭐든 할 수 있는 거예요. Claude Code는 실제로 그 단계들을 하나씩 해냈고, 그 기본 동작들만 있으면 나머지 모든 걸 만들어낼 수 있었죠.

저는 곧바로 (Ramp5 안에서) Claude Code를 알리고 다니기 시작했어요. 채널마다 메시지를 뿌려서 또 누가 이걸 쓰는지 수소문했어요. 그리고 사람들 자리로 직접 찾아가서 이랬어요. “자, 날 믿어봐. 이거 할 때까지 안 갈 거야. Claude Code 설치하고, 터미널에서 켜서, 몇 가지 해보자. 지금 뭐 작업 중이야? 그걸 그냥 얘한테 말해봐. 그러고 나서 어떻게 되나 보자고.”

Boris, Cat과 저는 매주 피드백 미팅을 했어요. 그렇게 개발자와 사용자로서 자연스럽게 관계를 쌓아 갔어요.

저는 늘 이것저것 만지작거리길 좋아하는 사람이었어요. 자동화, 작은 개선을 눈덩이처럼 불려 나가는 일, 내 작업 환경을 거듭 재귀적으로 최적화하는 일에 진심이었죠. (Claude Code는) 그런 역량을 발휘하기에 딱 맞는 토대였어요.

JARRED SUMNER

Bun 창립자

Claude Code를 처음 써봤을 때, 저는 Bun6에 웹소켓 클라이언트 압축을 구현해 달라고 했어요. RFC 문서를 넣어줬더니, 알아서 구현 방법을 찾아내더군요. 처음엔 좀 엉성하게 했지만, 여러 번 프롬프트를 주니까 스스로 고쳤어요. 그러고 나서 저는 Bun에서 우선순위를 정하는 방식을 사실상 바꿔 버렸어요. Bun을 Claude Code와 함께 쓰기 쉽게 만드는 쪽으로요.

당시 Claude Code가 실제로 낸 효과에 비하면 제가 지나치게 빠져 있었던 것 같아요.

TRISTAN HUME

앤트로픽 성능 엔지니어링 기술 스태프

제 작업은 대부분 맥락이 많이 필요했어요. 까다로운 가속기용 커널을 다뤘는데, 인터넷에 공개된 문서가 없는 경우가 많았거든요. Claude Code는 스스로 도구를 만들고, 이것저것 조사해가며 즉석에서 뭔가를 배우는 건 그다지 잘하지 못했어요. 그래서 아주 제한적인 작업이 아니면 별로 쓸모가 없었어요.

JARRED SUMNER

아마 (2025년) 8월이나 9월쯤에, 누군가 Bun에서 Claude Code 사용을 금지하고 싶어 한다는 논의가 있었어요. 하지만 저는 그렇게 되도록 놔둘 생각이 전혀 없었죠.

MEAGHAN CHOI

Claude 4 모델이 나왔을 때 비로소 우리 차례가 왔어요. 그전까지는 사실 할 수 있는 UX 디자인이 그렇게 많지 않았거든요. 만들고 싶은 제품을 감당하기엔 모델이 아직 준비가 안 됐던 거예요. 그러다 마침내 준비가 된 거죠.

BORIS CHERNY

우리는 구독 요금제도 함께 내놨어요. 그러니까 비즈니스 모델 혁신과 모델 혁신, 이 두 가지가 맞물린 덕분에 Claude Code가 도약할 수 있었죠.

DAWN DRAIN

저는 Claude Code가 clide 덕을 그렇게 많이 봤다고는 생각하지 않아요. 일단 모델 성능이 어떤 문턱을 넘고 나면, 제품 형태(form factor)는 어느 정도 저절로 드러나거든요.

KYLE EASTERLY

우리가 일하는 방식이 근본적으로 바뀌었어요. 2022년에 처음 AI를 만지작거리던 때만 해도, 저는 Claude Code를 머릿속에 그려볼 수 없었어요. 하지만 AI가 작동하는 앱을 만들어낼 수만 있다면, 거기서부터 앞날을 미루어 볼 수 있겠다는 건 알았어요.

SID BIDASARIA

이게 이렇게 큰 제품이 될 거라곤 전혀 생각 못 했어요. 완전히 뜻밖이었고, 지금도 여전히 놀라워요.

6. 새로운 세계

BORIS CHERNY

2025년 2월에 Claude Code는 제 코드의 아마 10퍼센트쯤을 쓰고 있었어요. 5월엔 30, 40퍼센트로 올라갔고요. Code with Claude 개발자 콘퍼런스에서 Sonnet 4가 나왔을 때가 기억나요. 뒤편 방에 앉아 코딩을 하다가 “와, 이거 정말 좋아지고 있는데” 싶었죠. 모델이 훨씬 나아졌어요. 에이전트답게 알아서 척척 움직였고, 코딩도 정말 잘했죠.

2025년 겨울에는 제 코드의 100퍼센트를 Claude Code가 썼어요. 손으로 쓴 건 단 한 줄도 없었죠.

KYLE EASTERLY

개발자에는 두 부류가 있어요. 한 부류는 코드 쓰는 걸 정말 좋아해요. 거의 자기만의 선(禪) 정원을 가꾸는 일 같은 거죠. 푹 빠져들게 되고, 기분도 좋아요. 그리고 또 다른 부류가 있어요. 완전한 이분법은 아니고 겹치는 부분도 있지만, 이들이 가장 큰 성취감을 느끼는 순간은 현실의 누군가가 자기가 만든 소프트웨어를 쓰면서 마음에 들어 할 때예요. 저는 바로 이쪽이에요.

SHAUNA KRAVEC

저는 Claude Code 파워 유저예요. 제 Claude 열두 개가 떼 지어 돌아다니며 문서를 읽고, 이것저것 업데이트하고, 슬랙에서 자료를 끌어와요. 리서치 리드다 보니 지난 몇 년간 코드를 많이 쓰진 않았는데, 이제는 오히려 더 많이 쓸 수 있게 됐어요. 워낙 쉬워졌으니까요.

IGOR KOFMAN

모델과 Claude Code가 좋아질수록, 우리는 다음 추상화 단계로 올라가게 될 거예요. 그때는 여러 Claude를 관리하는 게 아니라, 그 Claude들의 관리자를 관리하게 되겠죠.

TRISTAN HUME

동료들이 Claude에게 백그라운드에서 작업을 맡기며 엄청난 효과를 누리는 걸 봤어요. 그런데 저한테는 그렇게 할 마땅한 방법이 없었죠. 사실상 평소 업무를 일주일이나 접고 새 개발 환경을 세팅하는 데만 매달려야 했어요. 하지만 생산성을 최대로 끌어올리려면 이제 예전과는 다르게 코딩해야 한다는 건 분명해요.

BORIS CHERNY

어제는 아내와 강아지가 소파에서 뒹구는 동안 저는 하루 종일 Claude Code로 코딩했는데, 커밋이 88개였어요.

CAT WU

처음 출시했을 때는 다들 Claude Code가 보내는 권한 요청을 하나하나 꼼꼼히 읽었어요. 요즘은 아주 많은 사용자가 전부 자동 승인해 버려요. 저는 이 변화에서 Claude가 사용자의 신뢰를 얻었다는 게 드러난다고 생각해요.

7. 미래

ADAM WOLFF

React를 겪으면서 프로젝트가 성공하면 어떤 한계가 따르는지 알게 됐어요. React는 처음에 아주 순수한 컴퓨터과학적 아이디어에서 출발했어요. 사용자 인터페이스 상태를 표현하는 데는 메시지 전달보다 함수형 프로그래밍이 더 나을 거라는 아이디어요. 그런데 일간 활성 사용자 100만 명을 넘어설 즈음엔, 그건 완전히 다른 무언가가 되어 있었어요. 컴퓨터과학적 아이디어라기보다는 하나의 로고이자 브랜드이자 느낌이 됐죠. 보통의 React 사용자가 그걸 좋아한 이유가 그 핵심 통찰에서 비롯된 것인지 아닌지조차 분명하지 않았어요.

Claude Code도 분명 같은 식으로 진화할 거예요. 여러분이 Claude Code를 뭐라고 생각하든, 그게 터미널이든 Claude의 성격이든 지금 쓰고 있는 특정 프롬프팅 기법이든, 끝까지 가 보면 그 어느 것도 중요하지 않아요.

AUSTIN RAY

처음 Ramp에서 Claude Code 도입을 이끌 때, 저는 커뮤니티와 실험 문화를 만드는 데 신경 썼어요. 어떻게 실패하는지, 뭐가 되고 뭐가 안 되는지를 공유하고, 공개된 자리에서 터놓고 이야기하는 거죠. 팀의 암묵적 노하우(tribal knowledge)를 복리처럼 불려 나가는 게 핵심이에요.

FIONA FUNG

소프트웨어 엔지니어링의 역할은 바뀔 거예요. 저는 11년 반 동안 개발자 도구를 만들어 왔지만, 다음 달에 어떻게 될지 안다고 감히 말하지 못하겠어요. 우리는 호기심을 잃지 말고, 내부든 외부든 사용자에게서 적극적으로 배워야 해요.

TRISTAN HUME

저는 이걸 갈 수 있는 데까지 밀어붙여 봤어요. Claude에게 Jupyter 노트북의 새로운 대안을 처음부터 다 짜게 했어요. 코드는 하나도 들여다보지 않고, 알아서 하게 놔두고, 심지어 브라우저로 UI 테스트까지 직접 하게 했죠. Claude는 실제로 작동하는 걸 만들어냈어요. 그런데 막상 써보니 저는 그게 마음에 안 들었어요. 안목을 갖춘 Claude가 나올 때까지 기다려야겠어요. 제게 필요한 걸 전부 꿰고 있어서, 그걸 백그라운드에서 알아서 해낼 수 있는 그런 Claude요.

AUSTIN RAY

”이걸 더 빠르게 만들 수 있을까? 더 좋게 만들 수 있을까?” 하는 집착이에요. 그게 Ramp의 문화예요. 확실히 “프런티어를 끌어안고, 일단 해 보자”는 쪽이죠. 고객에게 도움이 된다면 우리는 뭐든 시도해 볼 거예요.

KYLE EASTERLY

알래스카 주 자립생활위원회 같은 비영리단체는 예전이라면 맞춤 소프트웨어를 절대 감당할 수 없었어요. 그런 걸 만들 보조금 자체가 존재하지 않으니까요. 그런데 이제는 그런 부류의 일이 한꺼번에 가능해졌어요.

지금은 알래스카 노스 슬로프에서 손으로 적은 연료 배송 기록을 가져다가, 옮겨 적어 CSV 파일로 정리할 수 있어요. 그 고객을 위해 얼마 전 태블릿 앱도 출시했어요.

우리는 고객들에게 이렇게 말해요. 직접 눈으로 봐야 한다고요. AI가 어떻게 작동할지는 말로만 들어서는 알 수 없다고요.

SHAUNA KRAVEC

자율 소프트웨어 엔지니어링 에이전트라는 비전은 이제 어느 정도 결실을 맺어가고 있어요.

AI가 사람들에게 해 줄 일을 두고 나오는 긍정적인 전망은 상당수가 결국, AI가 정해진 틀에 갇히지 않고 사람들이 혼자서는 풀지 못하던 문제까지 풀어낼 만큼 유능해지느냐에 달려 있다고 생각해요. 우리는 연구를 가속하고, 암을 정복하고, 달에 가는 얘기를 하잖아요. 그런 건 질문에 답하기만 하는 모델에서는 나오지 않아요. 세상에 나가 직접 행동할 수 있는 모델이 필요하죠.

MEAGHAN CHOI

코딩은 오랫동안 문턱이 아주 높은 일이었어요. 그걸 그토록 많은 사람의 손에 쥐여주고, 내부에서든 외부에서든 사람들이 무엇을 만들어내는지 지켜보는 건 무척 보람 있었어요.

SHAUNA KRAVEC

제 원래 전공은 이론물리학이에요. 그 분야에선 사람들이 같은 난제를 수백 년째 붙들고 있기도 해요. 발전 속도는 AI보다 훨씬 느리고, 무척 어렵고 비싼 것들에 막혀 있는 경우가 많아요. 입자 가속기를 지어봐야 몇 개나 짓겠어요.

2026년과 2027년에는 거의 내내, 불과 석 달 사이에도 아주 많은 일이 벌어질 거라고 생각해요. 2024년이었다면 석 달 사이에 개선은 있었겠지만, 이만큼 극적이진 않았을 거예요.

그게 바로 어질어질한 부분이고, 저는 이걸 받아들일 준비가 된 사람이 있기나 한지 모르겠어요.

IGOR KOFMAN

제 어머니는 과학자셨는데, 코딩할 때 천공카드를 쓰셨어요. 저는 어머니의 천공카드 디버깅을 돕곤 했죠. 아버지는 엔지니어셨지만 코딩은 할 줄 모르셨어요. 그러다 누군가 키이우의 돔 피오네로프(Dom Pionerov)에 코모도어를 기증했어요. 우리 동네 YMCA 같은 곳이었죠. 아버지는 코딩 책을 한 권 구해오셨고, 우리는 집에서 그걸 함께 읽었어요. 그렇게 저는 소프트웨어를 짜는 길로 들어섰어요.

저는 2025년 겨울을 기점으로, 이제 더는 코드를 혼자 손으로 쓰지 않아요.

BORIS CHERNY

이건 IBM 0297예요. 소련에서 할아버지가 프로그래밍하실 때 쓰시던 기계와 비슷하죠. 그리고 이건 초창기 텍스트 편집기인데, 지금도 모든 맥에 기본으로 깔려 있어요. 그러고 나서 그게 진화하고, 진화하고, 또 진화했고, 지금도 계속 진화하고 있어요. 그리고 그 스펙트럼 어딘가에 Claude Code가 있죠.

• • •

이 인터뷰들은 2026년 2월부터 5월 사이에 녹음되었으며, 편집과 축약을 거쳤습니다.

옮긴이 주

  1. 페이스북(현 메타)이 2013년 공개한 오픈소스 자바스크립트 UI 라이브러리. 오늘날 웹 프런트엔드 개발에서 특히 널리 쓰이는 도구입니다. ↩
  2. 1982년 출시된 8비트 가정용 컴퓨터로, 1980년대에 가장 많이 팔린 개인용 컴퓨터입니다. 프로그램을 카세트테이프에 담아 불러오곤 했습니다. ↩
  3. 1982년 토론토 대학에서 프로그래밍 교육용으로 만든 언어. 문법이 간결해 학교 입문 수업에 오래 쓰였습니다. ↩
  4. Model Context Protocol. 앤트로픽이 2024년 공개한 개방형 표준으로, AI 모델을 외부 도구·데이터 소스와 연결하는 방식을 규격화한 것입니다. ↩
  5. 미국의 핀테크 기업으로, 법인카드와 지출 관리 서비스를 제공합니다. ↩
  6. 자바스크립트·타입스크립트 런타임 겸 도구 모음. 빠른 속도를 앞세워 Node.js의 대안으로 주목받았습니다. ↩
  7. 1964년 나온 IBM의 천공카드 키펀치 기계. 당시 프로그래머는 종이 카드에 구멍을 뚫어 코드를 입력했는데, 이것이 초기 컴퓨터 프로그래밍 방식이었습니다. ↩

참고: 이 글은 앤트로픽이 공개한 구술사 “The Making of Claude Code”를 번역한 것입니다.

원문: The Making of Claude Code - Anthropic

생성: Claude (Anthropic)

총괄: 존 (디노이저denoiser)