클로드 코드는 어떻게 태어났나

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 팀 동료 한 명과 저는 컨테이너 안에서 지속되는 셸을 띄우는 데 성공했어요. 그 덕에 모델이 코드를 실행하고, 입출력을 스트리밍하고, 타임아웃 상황도 매끄럽게 넘길 수 있게 됐죠.

BEN MANN

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

DAWN DRAIN

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

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 얘기를 했지만, 투박했고 시작할 때 너무 느렸어요.

ADAM WOLFF

Claude Code 팀의 첫 매니저

clide의 에이전트 기능은, 제가 Labs로 옮기기 전에 clide에 마지막으로 넣은 기능 중 하나였어요. clide에는 bash 도구가 없어서 할 수 있는 게 제한적이었죠. 저는 부분적인 변경만 보고도 사용자가 뭘 하려는지 추론할 수 있게 만들었어요. 그래서 아기 수준의 에이전트(baby agentic)였던 셈이죠.

그게 처음 제대로 작동했을 때, 저는 부엌에서 춤을 추고 있었어요. 믿기지가 않았죠.

BEN MANN

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

BORIS CHERNY

Claude Code 총괄

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

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

미래처럼 느껴졌어요.

BEN MANN

그는 “이런 미친”이라는 반응이었어요. 우리는 조각들을 이미 다 봤던 거예요. 그저 그걸 하나로 합치기만 하면 됐죠.

RAPHAEL LEE

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

Boris는 에이전트 코딩 영역을 맡았어요. 자기가 취하고 싶은 접근 방식에 대해 아주 분명한 생각이 있었죠.

BORIS CHERNY

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

이리저리 해킹하듯 만지다가, 제가 “Claude CLI”라고 이름 붙인 데모를 하나 만들었어요.

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

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

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

IGOR KOFMAN

Labs 팀 기술 스태프

저한테는 이게 옳은 접근이라는 게 명백했어요.

BORIS CHERNY

이걸 올린 다음 날, 출근해서 Robert가 일하는 걸 봤는데, 코드에 그어진 그 빨간 줄과 초록 줄, 지금은 상징처럼 된 그 표시를 알아봤어요. 그가 이러더군요. “응, 이게 내 코딩을 해주고 있어.” 정말 미친 일이었죠. 실제로 쓸모가 있었어요.

ROBERT BOYCE

Labs 팀 기술 스태프

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

BORIS CHERNY

당연히 완성도와는 정말, 정말 거리가 멀었어요. 그런데 저는 이걸 붙잡고 좋게 만들어야 한다는 강렬한 조급함을 느꼈어요. 주말마다 일하기 시작했죠. 친구들은 “무슨 일이야? 놀러 나와!” 했지만, 도무지 머릿속에서 떨쳐낼 수 없는 무언가가 있었어요. 그리고 그 감각은 오늘도 여전히 그때만큼 절박해요.

IGOR KOFMAN

앤트로픽에서 저는 원래 엔지니어가 아닌 사람들에게 AI의 힘을 가져다주는 일을 하고 싶었어요. 코딩은 우리가 반드시 풀어낼, 너무 당연한 문제처럼 보였죠. 그래서 저는 덜 당연한 걸 하고 싶었어요. 그런데 세 달쯤 지나서, 코딩이야말로 집중해야 할 바로 그것이라는 걸 깨달았어요. 다른 모든 것으로 가는 핵심 경로 위에 있으니까요.

ADAM WOLFF

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

BORIS CHERNY

제가 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가 있길래 그리로 뛰어들었죠. 저는 커리어 내내 한 가지 전문 분야를 가져본 적이 없고, 개발자 도구나 코딩 도구를 만들어본 적도 없었어요. 완전히 처음이었죠.

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 때도, 페이스북 내부에서 채택되게 만들려고 했던 모든 일이 결국 외부 사람들도 채택하게 만들었어요. 우리는 장점이 뭔지, 함정이 어떻게 생겼는지, 길이 어떤 모습인지 더 잘 이해하게 됐죠. Claude Code도 마찬가지였어요.

SID BIDASARIA

코드베이스에는 PR 제한도, 리뷰 제한도 없었어요. 그냥 수정 사항을 바로 배포했죠. Boris가 초기에 한 대단한 일 하나는 자동 업데이트와 아주 좋은 사용자 지표를 만들어 넣은 거예요. 그래서 누군가 우리에게 “이건 별로예요”라고 하면, 우리는 수정을 배포했고 그 사람은 5분 뒤에 그걸 받아볼 수 있었어요.

RAPHAEL LEE

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

SID BIDASARIA

웹 앱이 아니라 CLI 제품이라는 건, 헤쳐나가야 할 복잡한 아키텍처가 없다는 뜻이었어요. 우리는 정말 빠르게 반복할 수 있었죠. 그냥 클라이언트 애플리케이션이니까요. 아주 단순해요.

BEN MANN

모델 제품화를 오래 해보지 않은 사람들에겐 잘 와닿지 않는 얘긴데요, 지금 20~30퍼센트만 작동하는 무언가를 만들어 놔야 다음 모델이 나왔을 때 80퍼센트로 작동해요. 그리고 그 정도면 시장에서 발을 붙이기에 충분하죠. 그다음 모델은 90퍼센트대가 되고, 그때부터 진짜로 앞으로 나아가는 거예요. 그리고 맷집이 아주 좋아야 해요. 계속, 계속 틀릴 테니까요.

지금 이 순간에 발을 딛고 있어야 하지만, 동시에 미래를 바라봐야 하죠.

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 Code가 공개됐고, 저는 프로젝트 중간에 갈아탔어요. 쾅.

AUSTIN RAY

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

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

Boris, Cat, 그리고 저는 매주 피드백 미팅을 했어요. 그렇게 자연스럽게 개발자와 사용자라는 관계를 쌓았죠.

저는 늘 손 대보길 좋아하는 사람이었어요. 자동화, 눈덩이 굴리기, 내 작업 환경을 반복적이고 재귀적으로 최적화하는 것에 진심이었죠. (Claude Code는) 그런 기질에 딱 맞는 토대였어요.

JARRED SUMNER

Bun 창립자

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

솔직히 당시 실제 영향력에 비하면 제가 너무 과하게 빠져 있었던 것 같아요.

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를 머릿속에 그려볼 수 없었어요. 하지만 이게 작동하는 앱을 그냥 만들어낼 수 있다면, 거기서부터는 얼마든지 확장해 나갈 수 있겠다는 건 보였죠.

SID BIDASARIA

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

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가 사용자의 신뢰를 얻었다는 걸 보여준다고 생각해요.

ADAM WOLFF

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요.

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가 있죠.