Inside Claude Code: Building for the Model, Not the Moment

Chapter 1 · 해설: 와우멘토

Inside Claude Code: Building for the Model, Not the Moment

A WOW Mentor strategy teardown.

오늘 와우멘토가 해부할 주제는, 아무도 만들라고 시키지 않은 작은 터미널 프로그램 하나가 어떻게 전 세계 개발자의 일하는 방식을 통째로 바꾸어 놓았는가입니다. 이야기의 주인공은 클로드 코드를 처음 만든 엔지니어, 보리스 체르니입니다. 그는 이 도구가 로켓 부스터처럼 느껴진다는 진행자들의 말에 웃으며, 자신도 처음 이것을 만들었을 때 석 달 동안 단 하루도 쉬지 못했다고 털어놓습니다. 2024년 9월, 주말도 밤도 없이 일하면서 그는 이렇게 되뇌었다고 합니다. '세상에, 이건 뭔가가 될 것 같다. 아직 쓸모가 있는지는 모르겠지만.' 와우멘토가 먼저 주목하는 지점은, 창시자조차 그 순간에는 자기 손 안의 것이 무엇이 될지 확신하지 못했다는 사실입니다. 확신이 아니라 예감, 계획이 아니라 우연에서 이 모든 것이 시작되었습니다. 그가 지금 돌아보며 가장 놀랍다고 말하는 것이 두 가지 있습니다. 하나는 우리가 아직도 터미널을 쓰고 있다는 사실입니다. 터미널은 시작점이어야 했지 종착점일 리 없다고 그는 생각했습니다. 다른 하나는 이것이 실제로 쓸모가 있게 되었다는 사실입니다. 그의 회고에 따르면 2025년 2월만 해도 이 도구가 써낸 코드는 자기 코드의 10퍼센트 남짓이었고, 그는 여전히 대부분을 손으로 짰습니다. 그런데도 그가 이 방향에 베팅한 이유가 오늘 첫 번째 큰 교훈으로 이어집니다. 와우멘토가 강조하고 싶은 것은, 그가 '지금 잘하는 것'이 아니라 '곧 잘하게 될 것'에 걸었다는 점입니다. 그가 창업자들에게 지금도 반복해서 건네는 조언이 바로 이것입니다. 앤트로픽에서 그들이 사고하는 방식은 '오늘의 모델을 위해 짓지 않는다, 6개월 뒤의 모델을 위해 짓는다'는 것입니다. 그는 말합니다. 지금 모델이 잘 못하는 그 경계선, 그 프런티어를 찾아내라고요. 왜냐하면 모델은 반드시 그것을 잘하게 될 것이고, 당신은 그저 기다리기만 하면 되기 때문입니다. 와우멘토가 이 대목에서 잠시 멈춰 세우고 싶은 이유가 있습니다. 이것은 대부분의 창업 상식과 정반대이기 때문입니다. 보통은 '지금 작동하는 것'을 만들어 제품 시장 적합성을 찾으라고 배웁니다. 그런데 그는 반박합니다. 지금의 모델에 맞춰 제품 시장 적합성을 찾아봤자, 몇 달 뒤 다음 모델을 겨냥한 누군가에게 그대로 추월당한다는 것입니다. 모델은 몇 달마다 새로 나오니까요. 그러니 지금 모델로 그 한계의 경계를 손으로 더듬어 느껴본 다음, 6개월 뒤에 올 모델을 상상하며 그것을 위해 지으라는 것입니다. 이 원칙을 그는 자신의 코드베이스로 증명합니다. 그는 클로드 코드가 몇 번이고 쓰이고, 지워지고, 다시 쓰이기를 반복해왔다고 말합니다. 6개월 전에 있던 부분은 지금 단 하나도 남아 있지 않다는 것입니다. 도구를 몇 주마다 떼어내고 몇 주마다 새로 붙입니다. 코드베이스의 상당 부분이 불과 몇 달 이하의 나이를 가진다고 그는 인정합니다. 와우멘토가 여기서 끌어내고 싶은 통찰은, 그가 코드를 '자산'이 아니라 '소모품'으로 본다는 점입니다. 모델이 이렇게 빠르게 좋아지는 세상에서는, 6개월 뒤에도 여전히 의미 있을 만한 UI란 존재하지 않는다고 그는 판단했습니다. 그래서 그들은 터미널에 머물렀습니다. 화려한 인터페이스를 짓는 대신에요. 그렇다면 이 모든 것은 어디서 시작되었을까요. 그의 회고는 놀랍도록 소박합니다. 앤트로픽의 오랜 베팅은 코딩이었습니다. 안전한 초지능으로 가는 길이 코딩을 통한다는 믿음이었죠. 모델에게 코딩을 가르치고, 도구 사용을 가르치고, 컴퓨터 사용을 가르치면 거기에 닿는다는 것입니다. 하지만 누구도 그에게 명령줄 도구를 만들라고 시키지 않았습니다. 그의 표현으로는 '탐색 모드'였을 뿐입니다. 그래서 그는 먼저 API 사용법을 익히려고 아주 작은 터미널 채팅앱을 만들었습니다. UI를 만들 필요가 없었기 때문에 터미널을 골랐습니다. 당시엔 그 혼자였으니까요. 그리고 도구 사용 기능이 나오자, 그는 그저 궁금해서 시험해봅니다. 문서에 있던 예제가 마침 배시(bash) 도구였고, 파이썬으로 된 그 예제를 타입스크립트로 옮겨 붙였습니다.

바로 여기서 오늘의 두 번째 큰 장면이 나옵니다. 그는 모델에게 물었습니다. '지금 내가 무슨 음악을 듣고 있지?' 그러자 모델은 애플스크립트를 작성해 그의 맥을 조작하고 음악 플레이어를 뒤져 답을 찾아냈습니다. 소네트 3.5 시절의 일입니다. 그는 이 순간을 자신의 첫 번째 'AGI를 향한 연료' 순간이었다고 부릅니다. 그때 그의 머릿속을 스친 깨달음은 이것이었습니다. '세상에, 이 모델은 그저 도구를 쓰고 싶어 한다. 그게 이 모델이 원하는 전부다.' 와우멘토가 이 문장을 오늘 전략의 심장이라고 부르는 이유가 있습니다. 그는 모델을 상자 안에 가두고 '여기 API가 있으니 이렇게만 나와 소통하라'고 명령하지 않았습니다. 대신 모델이 무엇을 하고 싶어 하는지 관찰하고, 그것을 가능하게 해주었습니다. 사용자를 대하듯 모델을 대한 것입니다. 이 관찰의 태도에서 그의 가장 중요한 제품 원리가 나옵니다. 바로 '잠재 수요'입니다. 그는 이것을 인터뷰 내내 다섯 번이나 반복하며, 제품에 관한 자신의 단 하나의 가장 큰 아이디어라고 못 박습니다. 잠재 수요란 이런 것입니다. 사람들은 자신이 이미 하고 있는 일만 합니다. 없던 일을 새로 하게 만들 수는 없습니다. 사람들이 하려는 일을 더 쉽게 만들면 그것은 좋은 아이디어이지만, 사람들에게 다른 일을 하라고 강요하면 그들은 하지 않습니다. 클로드 코드의 모든 조각이 이 잠재 수요 위에서 태어났다고 그는 말합니다. 프로토타입을 만든 지 이틀 만에 그는 팀에게 나눠주었고, 다음 날 출근하니 맞은편에 앉은 로버트라는 엔지니어가 벌써 그것으로 코드를 짜고 있었습니다. '이건 아직 프로토타입일 뿐인데, 뭐 하는 거야?'라고 그가 물을 정도였죠. 클로드MD 파일 역시 잠재 수요의 산물입니다. 그의 설명에 따르면, 사람들은 스스로를 위해 마크다운 파일을 써두고 모델에게 그것을 읽게 하기 시작했습니다. 아무도 시키지 않았는데 말이죠. 그 행동을 관찰한 데서 클로드MD가 나왔습니다. 와우멘토가 여기서 짚고 싶은 것은, 그가 '만들 것을 상상한' 게 아니라 '이미 벌어지는 일을 포착한' 방식으로 기능을 발명했다는 점입니다. 나중에 나오는 플랜 모드도 마찬가지입니다. 사람들은 이미 클로드에게 '아이디어를 짜되 아직 코드는 쓰지 마'라고 요청하고 있었습니다. 그는 일요일 밤 열 시에 깃허브 이슈와 내부 슬랙 피드백을 들여다보다가, 30분 만에 그 기능을 짜서 그날 밤 배포했고 월요일 아침에 세상에 나왔습니다. 그리고 그가 웃으며 폭로하는 플랜 모드의 정체는 이렇습니다. 그것이 하는 일은 프롬프트에 문장 하나를 더하는 것뿐입니다. '제발 코드는 쓰지 마.' 그게 전부라는 것이죠. 여기서 그의 또 다른 핵심 개념인 '비계'가 등장합니다. 모델을 위해 짓는 것과 별개로, 모델 주위에 코드를 둘러 성능을 조금 끌어올릴 수 있습니다. 영역에 따라 10에서 20퍼센트쯤이라고 그는 말합니다. 그런데 그 이득은 다음 모델이 나오는 순간 대체로 씻겨 내려갑니다. 그러니 선택지는 둘입니다. 비계를 짓고 이득을 얻은 뒤 다음 모델에 맞춰 또 새로 짓거나, 아니면 그냥 기다려서 다음 모델이 그것을 공짜로 해주게 하거나. 클로드 코드 팀이 앉는 자리 벽에는 리처드 서턴의 '쓰라린 교훈(The Bitter Lesson)'이 액자에 걸려 있다고 그는 전합니다. 더 일반적인 모델은 언제나 더 특수한 모델을 이긴다는 것, 그러니 절대 모델에 반대로 베팅하지 말라는 교훈입니다. 와우멘토가 여기서 여러분께 권하고 싶은 사고 습관은, 모든 '지금의 최적화'를 곧 버릴 임시물로 회계 처리하는 것입니다. 그것이 진짜 자산인지, 다음 파도에 쓸려갈 모래성인지 매번 물어야 합니다. 그의 클로드MD 이야기는 이 철학의 가장 구체적인 사례입니다. 그가 인터뷰 전에 확인해봤더니, 그의 개인 클로드MD는 단 두 줄이었습니다. 첫째, PR을 올리면 자동 병합을 켠다. 둘째, PR을 올리면 팀의 승인 채널에 게시한다. 그게 전부입니다. 다른 모든 지침은 코드베이스에 체크인된 공용 클로드MD에 들어 있고, 팀 전체가 매주 여러 번 거기에 기여합니다. 누군가 뻔히 예방 가능한 실수를 저지른 PR을 보면, 그는 그저 클로드를 태그해 '이걸 클로드MD에 추가해줘'라고 시킵니다. 그리고 그가 주는 조언은 반직관적입니다. 클로드MD가 너무 커지면, 개선하려 들지 말고 통째로 지우고 새로 시작하라는 것입니다. 목표는 모델을 궤도에 올리기 위한 최소한의 조치입니다. 지웠다가 모델이 엇나갈 때만 조금씩 다시 채우고, 모델이 좋아질수록 채울 것이 점점 줄어든다는 것을 발견하게 된다고 그는 말합니다. 와우멘토가 강조하는 지점은, 대부분의 사람이 이것을 과도하게 설계하려 든다는 그의 관찰입니다. 능력은 모델마다 바뀌므로, 오늘의 정교한 규칙집은 내일의 족쇄가 됩니다. 이 겸손의 태도는 사람에 대한 그의 관점으로도 이어집니다. 그는 스스로를 평범한 엔지니어라고 부릅니다. 빔(Vim) 같은 도구를 쓰지 않고 그저 더 단순한 VS 코드를 씁니다. 그는 엔지니어들이 저마다 다른 방식으로 도구를 쥔다는 것을, 모두에게 맞는 단 하나의 도구란 없다는 것을 일찍 배웠다고 합니다. 오히려 그 점이 클로드 코드를 좋게 만들었다고 그는 봅니다. 빔을 몰라도, 티먹스를 몰라도, SSH를 몰라도, 그냥 도구를 열면 알아서 안내해주니까요. 그리고 그는 개발자로서 오랜 시간 갈고닦은 강한 의견들이 이제 더는 유효하지 않은 경우가 많다고 말합니다. 시니어 엔지니어들이 보상받아온 그 확고한 신념들이, 모델이 좋아지면서 바뀌어야 한다는 것입니다. 그래서 그가 가장 중요하게 보는 기술은 과학적으로, 제일원리로 사고하는 능력입니다. 채용에서 그는 '당신이 틀렸던 적이 언제인가'를 묻습니다. 자기 실수를 뒤늦게라도 알아보는지, 그 실수를 자기 것으로 인정하는지, 거기서 무언가를 배웠는지를 보기 위해서입니다. 그는 자신도 아이디어의 절반은 틀린다고 담담히 말합니다. 시도하고, 사용자에게 주고, 이야기를 듣고, 배우고, 그러다 좋은 아이디어에 다다르기도 하고 못 다다르기도 한다는 것이죠. 이 겸손은 에이전트를 다루는 방식으로도 확장됩니다. 그가 든 메모리 누수 이야기가 상징적입니다. 그 자신은 힙 덤프를 떠서 개발자 도구로 열고 프로파일을 뒤지며 코드를 훑었지만 오래 걸렸습니다. 반면 크리스라는 동료 엔지니어는 그냥 클로드 코드에게 '메모리 누수가 있는 것 같은데 한번 봐줘'라고 물었고, 클로드 코드는 힙 덤프를 떠서 그것을 분석할 작은 도구를 스스로 짜서, 그보다 빨리 누수를 찾아냈습니다. 그는 이것을 끊임없이 다시 배워야 한다고, 자기 뇌는 여전히 6개월 전 어딘가에 갇혀 있다고 고백합니다. 그가 특히 흥미로워하는 사람은 데이지라는 엔지니어입니다. 그녀는 새 기능을 요청받았을 때 곧바로 기능을 짜는 대신, 먼저 클로드 코드에게 '임의의 도구를 시험하고 검증하는 도구'를 만들어주는 PR을 올렸고, 그다음 클로드가 자기 도구를 스스로 짜게 했습니다. 그는 이런 틀 밖의 사고를 높이 삽니다. 앤트로픽 팀은 클로드 에이전트 SDK로 개발의 거의 모든 부분을 자동화합니다. 코드 리뷰, 보안 리뷰, 이슈 라벨링, 배포까지요. 여기서 스웜과 서브에이전트 이야기가 나옵니다. 그가 소개하는 개념은 '상관없는 문맥 창'입니다. 여러 에이전트가 서로의 문맥, 혹은 자기 자신의 이전 문맥에 오염되지 않은 신선한 문맥 창을 갖는다는 것이죠. 그는 이것을 일종의 시험 시점 연산이라고 부릅니다. 문제에 더 많은 문맥을 던지면 그만큼 더 많은 능력이 나오고, 올바른 위상(topology)으로 배치하면 에이전트들이 더 큰 것을 지을 수 있다는 것입니다. 가장 상징적인 사례가 플러그인 기능입니다. 이 기능은 주말 사이에 스웜 하나가 통째로 지었습니다. 한 엔지니어가 클로드에게 명세를 주고 아사나 보드를 쓰라고 시키자, 클로드가 티켓 여러 개를 올리고 에이전트들을 여럿 띄웠으며, 그 에이전트들이 작업을 하나씩 집어 들었습니다. 사람의 개입은 거의 없이 며칠을 돌았고, 나온 결과물이 출시된 형태와 거의 같았다고 합니다. 그는 서브에이전트를 '재귀적인 클로드 코드'라고 설명하며, 팀에서는 그것을 태우는 원본을 '마마 클로드'라고 부른다고 웃으며 전합니다. 그리고 실용적인 조언 하나를 덧붙입니다. 어려운 문제일수록 서브에이전트의 수를 난이도에 맞춰 3개, 5개, 심지어 10개까지 병렬로 띄워 각자 다른 곳을 뒤지게 하라는 것입니다.

… The rest of this chapter continues in the full edition, available with a subscription.

Listen to this chapter