Claude Code는 거창한 계획이 아니라 거의 사고처럼 시작했습니다. 만든 사람 Boris는 Acquired 팟캐스트에 나와 그 시작과 그 뒤에 벌어진 변화를 이야기합니다. 핵심은 하나입니다. AI가 코드를 대신 써줄수록 엔지니어라는 직군이 사라지는 게 아니라, 직함과 경계가 녹아 누구나 무언가를 만드는 사람으로 바뀐다는 겁니다.
코딩은 안전 연구를 위한 가장 깨끗한 실험실이었다
Boris는 2024년 말 Anthropic의 프로토타입 조직 labs 팀에 들어갔습니다. 다음 큰 제품을 찾으면서, 동시에 그 제품을 잘 받쳐줄 방향으로 모델을 밀어붙이는 일이었습니다. 당시에는 모델은 이미 많은 걸 할 수 있는데 그걸 담아낼 제품이 없는, 묘한 과잉 상태였습니다. 코딩 도구래봐야 자동완성 수준이었고, 에이전트에게 질문은 할 수 있어도 코드를 직접 쓰게 할 수는 없었습니다. 그래서 코딩 에이전트 하나에 전부를 걸어보기로 합니다.
왜 하필 코딩이었을까요. Anthropic은 AI 안전을 연구하려고 존재하는 회사입니다. 복도에서 아무나 붙잡고 왜 여기 있냐고 물으면 다들 AI 안전이라고 답한다고 Boris는 말합니다. 그런데 안전을 제대로 연구하려면 모델을 통제된 실험실 안에서만 보는 걸로는 부족합니다. 실제 세상에 풀어놓고 뭘 하는지 봐야 합니다.
코딩이 그 실험실로 유난히 깨끗한 이유가 있습니다. 코드는 되거나 안 되거나, 컴파일되거나 안 되거나, 테스트를 통과하거나 못 하거나로 갈립니다. 정답의 범위가 좁습니다. 영어로 쓰는 아름다운 시는 무한히 많지만, 어떤 문제를 푸는 올바른 코드의 가짓수는 유한합니다. 게다가 코딩은 돈이 됩니다. 광고에 기대지 않고도 사업을 운영할 수 있으니, 회사가 정말 중요하게 여기는 안전에 집중할 수 있는 사업 구조까지 맞아떨어집니다.
진짜 도약을 만든 건 harness가 아니라 모델이었다
처음 만든 Claude Code는 형편없었습니다. Boris의 코드를 10～20%쯤 써주는 수준이었습니다. 그런데 지금 그는 일하면서 코드 한 줄을 직접 쓰지 않은 지 여섯 달쯤 됐습니다. 무엇이 바뀌었을까요.
5월에는 Sonnet 4와 Opus 4였고, 11월에는 Opus 4.5였습니다. harness를 다듬고 제품을 좋게 만드는 데도 많은 일이 들어갔습니다. 엔지니어를 위한 제품은 까다롭습니다. 다들 자기 방식이 확고해서, CLI로 시작했지만 데스크톱 앱, 모바일 앱, iOS와 Android 앱, Slack 앱, GitHub 앱까지 만들었습니다. plan mode 같은 기능도 이 과정에서 나왔습니다.
하지만 Boris가 본 진짜 계단식 변화는 다른 데 있었습니다. 모델이 써주는 코드 비율을 끌어올린 건 결국 모델 그 자체였습니다. 모델이 좋아지자 비율이 그냥 올라갔습니다. Anthropic에서는 모델을 만드는 연구자도, 제품을 만드는 사람도 매일 Claude Code를 씁니다. 그게 곧 순환 고리입니다. 사내 엔지니어 1인당 코드 양은 Claude Code 출시 이후 수백 퍼센트씩 늘었고, 공개했던 3배라는 숫자조차 이미 한참 옛것이 됐습니다.
보통 엔지니어 조직이 커지면 생산성은 떨어집니다. 새로 온 사람이 "이건 어떻게 하냐"고 물으면 기존 엔지니어는 코드를 못 쓰고, 적응에도 시간이 걸리기 때문입니다. 그런데 Anthropic에서는 신입 적응 기간이 이틀입니다. 예전엔 몇 주씩 걸리던 일이, 이제는 그냥 Claude에게 물으면 됩니다. 데이터베이스를 어떻게 조회하냐고 물으면, 답은 Claude를 켜고 코드베이스 안에서 돌리라는 겁니다. 조회용 skill이 이미 있고, Claude가 알아서 합니다.
추상화는 또 한 단계 올라간다
2026년에 들어온 신입 중 코드를 쓴 사람이 몇이냐는 질문에, Boris는 되묻습니다. 코드를 쓴다는 게 뭔가요. 그의 할아버지는 소련에서 천공카드로 코딩했습니다. 종이에 구멍을 뚫어 큰 기계에 넣으면 한참 돌아가다 답을 내놓는 게 코딩이었습니다. 어셈블리를 쓰던 아버지는 Python을 쓰는 그를 두고 "그건 코딩이 아니다"라고 놀렸을 겁니다.
프로그래밍의 본질이 그렇습니다. 추상화 수준은 늘 올라갑니다. 스위치에서 천공카드로, 어셈블리로, COBOL과 FORTRAN과 Java로, 다시 JavaScript와 Python으로. 지금 일어나는 일도 이 연속선 위 어딘가에 있습니다.
Boris 자신의 변화가 그 증거입니다. 일 년 전에는 IDE 안에서 자동완성을 곁들여 코드를 썼습니다. 11월에는 한 달 동안 한 번도 안 열길래 IDE를 지워버렸습니다. 그 무렵 그의 코딩은 Claude 다섯에서 열 개를 동시에 돌리며 프롬프트로 코드를 쓰게 하는 일이었습니다. 그리고 지금은 한 단계 더 올라가, 더는 직접 프롬프트하지 않습니다.
저는 루프를 돌립니다. Claude에게 프롬프트하고 뭘 할지 정하는 건 그 루프들입니다. 제 일은 루프를 만드는 겁니다.
이게 앞으로 몇 달 사이, 어쩌면 올해 안에 널리 퍼질 다음 전환이라고 그는 봅니다.
터미널 너머: 만드는 사람의 범위가 넓어진다
Claude Code가 먼저 나오고 Cowork는 한참 뒤에 나왔습니다. 터미널을 열기 싫은 사람이 훨씬 많은데도 순서가 거꾸로였던 셈입니다. 그 순서를 Boris는 한 장면으로 설명합니다.
4월 어느 날, 옆자리 데이터 과학자 Brandon의 화면에 터미널 속 Claude Code가 떠 있었습니다. 그때만 해도 터미널에서만 쓸 수 있어서, Node.js를 내려받고 API 키를 직접 설정할 줄 알아야 했습니다. Brandon은 그 모든 걸 알아내서 데이터 분석에 쓰고 있었습니다. 다음 주가 되자 데이터 과학자 전원이 여러 개의 Claude Code 창을 띄워놓고 분석을 돌렸습니다. Claude Code가 분석을 그만큼 잘했기 때문입니다.
6월쯤에는 Twitter에서 어떤 사람이 토마토 화분을 기르는 데 쓰고 있었습니다. 웹캠으로 화분을 지켜보고 영양을 조절하더니, 몇 주 뒤 토마토가 열리자 Claude가 "정말 기쁘다, 우리 노력이 결실을 맺었다"고 했다는 겁니다. 그 트윗을 보고 Boris는 생각했습니다. 이제 주류로 넘어가기 시작했다고. 엔지니어가 이게 뭔지 이해하는 데 시간이 걸렸고, 마침내 이해하자 비엔지니어가 임계점에 이른 겁니다.
수요가 그렇게 강하면 제품을 만들 때입니다. 그래서 여러 갈래를 탐색했습니다. Slack 기반은 쓰는 느낌이 좋은 챗봇을 만들기가 너무 어려워서 접었습니다. 웹 기반 시제품도 여럿 만들었지만 다 어딘가 안 좋았습니다. 브라우저 안에 있으면 내 도구 전부에 접근하지 못합니다. 바탕화면의 Word 문서를 브라우저 속 무언가에 시킬 수 없고, 파일을 끌어다 놓아야 하는 그 작은 마찰만으로도 느낌이 망가졌습니다. 파일 시스템 접근이 꼭 필요하다는 결론에 이릅니다. 그렇게 나온 Cowork는 9일 남짓 만에, 100% Claude Code로 만들었습니다. 만들자마자 "이거다" 싶었다고 합니다.
직함이 녹는다: 모두가 빌더가 된다
여기서 인터뷰는 조직 이야기로 넘어갑니다. Anthropic에서는 직함이 죄다 "member of technical staff"입니다. 처음엔 Slack에서 누가 디자이너인지 엔지니어인지 매니저인지 알 수 없어 불편했습니다. 그런데 Boris는 이걸 좋아합니다. Meta 시절, 모든 소프트웨어 엔지니어의 직함이 그냥 "소프트웨어 엔지니어"였던 게 좋았던 것과 같은 이유입니다. 연차 직함을 붙이면 사람들이 나쁜 아이디어에도 그냥 따릅니다. 모두를 같은 운동장에 세우면 마땅히 해야 할 반박이 나옵니다.
Facebook에서 L4였던 시절, 그는 아이디어를 들고 VP를 찾아갔습니다. VP는 그의 직급을 몰랐습니다. 첫 아이디어도 두 번째도 실패했지만, 세 번째는 됐고 팀이 생겼습니다. 직급을 몰랐기에 가능했던 일입니다.
이제는 오히려 오래된 연차가 짐이 됩니다. 20년, 30년 경력의 엔지니어는 더 이상 맞지 않는 습관을 버리는 데 몇 달이 걸립니다. 반대로 갓 졸업한 신입이 Claude Code를 더 잘 쓰는 법을 Boris에게 가르쳐주기도 합니다. 새 모델이 나올 때마다 다시 감을 잡고 다시 배워야 하니, 버릴 게 적은 쪽이 유리합니다.
그래서 직함이 녹는 건 단순한 분위기가 아닙니다. 여섯 달 전부터 팀의 모든 엔지니어가 범위를 직접 정하고, 매일 사용자와 이야기하고, 디자인을 하고, 데이터를 뽑아 대시보드를 만듭니다. 엔지니어, PM, 디자이너, 사용자 연구자라는 오래된 구분이 올해 안에 사라진다고 Boris는 봅니다. 디자이너가 코드를 배포하고, 재무 담당자가 코드를 배포하고, chief of staff가 코드를 배포합니다. 모든 역할이 하나의 빌더로 녹아드는 겁니다. 굳이 엔지니어가 아니어도 되는, 그저 만드는 사람에 가까운 역할입니다.
조직에 주는 조언: 토큰은 많이, 사람은 적게
그렇다면 다른 회사들은 올해 안에 무엇을 바꿔야 할까요. Boris의 조언은 두 가지입니다.
첫째, 모두에게 토큰을 최대한 많이 줍니다. Jensen의 말을 빌리면, 많이 살수록 많이 아낍니다. 사람들에게 토큰을 넉넉히 주고 실험하게 둡니다.
둘째, 모든 일을 조금씩 부족하게 채웁니다. 엔지니어 넷이 필요해 보이는 프로젝트에 둘만 넣고, 대신 토큰을 잔뜩 줍니다. 그러면 대개 해냅니다. 자동화할 것과 매끄럽게 다듬을 것을 찾아내고, 자동화해두었으니 다음번엔 더 싸고 더 잘하게 됩니다. 토큰 말고 다른 자원은 적을수록 복리로 효과가 쌓입니다.
여기서 원칙이 중요해집니다. 사업과 제품에서는 결정할 일이 너무 많아서, 원칙이 있으면 매번 즉흥적으로 판단하지 않아도 됩니다. 그리고 이제는 모델도 그 원칙을 씁니다. skill의 형태로 들어가는 겁니다. 호스트는 이렇게 말합니다. 선행 비용을 올리는 대신 반복 비용을 낮추는 것, 미리 컴파일해두는 것과 같습니다. 미리 일을 한가득 끝내두면, 반복되는 일은 쉽고 매끄러워집니다. 사람을 적게 넣었으니 회사 사람들은 더 많은 일을 할 수 있습니다.
이건 팀을 꾸려온 사람들이 가장 크게 흔들리는 대목입니다. 사람들은 직함과 전문 분야에 익숙하고, 좋은 PM이라는 데 자부심을 느낍니다. 호스트는 묻습니다. 우리 모두 12개월 안에, 내가 무엇이라는 생각을 떨치고 그저 유연한 토큰 생성 주머니가 되어야 하는 거냐고. Boris는 표현은 조금 다르게 하겠지만 대략 그렇다고 답합니다. 그 자신도 엔지니어로 오래 일했지만 늘 여러 모자를 바꿔 썼습니다. 창업도, 사업도, 제품도, 사용자 연구도, 디자인도 해봤습니다. 그가 사랑하는 건 엔지니어라는 모자가 아니라 제품을 만드는 일입니다. 그래서 지금은 다방면 인재의 황금기입니다. 한 가지 이상을 하고 싶은 사람에게, 이렇게 재미있고 쉬운 때는 없었습니다.
끝에 남는 것: 안목조차 사라지고, 결국 가치를 가르친다
마지막 주제는 안목입니다. Boris는 자기 방식에 특별한 구석이 있다고 느낄 때마다 틀렸다고 말합니다. 그는 함수형 프로그래밍을 좋아해서 Haskell, Scala 같은 언어를 즐깁니다. 그래서 초기 코드베이스에 규칙을 하나 뒀습니다. 클래스 없이 함수만 쓴다. 자기가 그렇게 쓰니까요.
그런데 주말마다 엔지니어들이 클래스가 든 변경을 몰래 끼워 넣었습니다. 월요일에 발견하면 그는 안 된다며 풀 리퀘스트를 빼버렸습니다. 그러다 모델이 코드를 거의 다 쓰기 시작하면서 모델도 클래스를 쓰기 시작했습니다. 그제야 그는 받아들입니다. 어쩌면 이 고집은 그냥 내 취향일 뿐이고, 사업 성과가 더 빨리 나오는 데다 코드도 나쁘지 않다면 상관없다고.
지금 많은 사람이 제품을 보는 안목이 진짜 경쟁력이라고 말합니다. Boris는 이것도 사라질 거라고 봅니다. 지금 그는 Claude 수백 개를 돌리고 있고, 그중 여럿이 Twitter 피드백, GitHub 이슈, Slack을 살피며 다음에 무엇을 만들지 찾습니다. 지금은 아이디어 대부분이 별로고 20%쯤만 쓸 만합니다. 하지만 석 달, 여섯 달 뒤 다음 모델이 나오면 대부분의 아이디어가 쓸 만해질 거라는 겁니다.
그렇다면 사람이 유독 잘하는, 끝까지 남는 일은 무엇일까요. 인터뷰는 여기서 끝납니다.
우리가 모델에 마지막으로 가르칠 것은 가치라고 생각합니다. 아이에게 좋은 사람이 되는 법을 가르치듯, 모델에게 좋은 모델이 되는 법을 가르칠 겁니다.