Claude Code 창조자 Boris Cherny 인터뷰 심층 분석

게시 2026/02/23

By BLUEBUG

40 분읽는 시간

출처: Y Combinator Light Cone 팟캐스트 인터뷰
원본 영상: https://www.youtube.com/watch?v=PQU9o_5rHC4
인터뷰이: Boris Cherny (Anthropic, Claude Code 창시자/수석 엔지니어)
동영상 게일자: 2026-02-18

인터뷰 개요
Claude Code의 탄생 배경
터미널이라는 의외의 선택
초기 사용 사례와 CLAUDE.md의 탄생
Boris의 CLAUDE.md 철학
Plan Mode의 탄생과 미래
서브에이전트와 멀티에이전트 시스템
Claude Teams 비전
엔지니어 생산성 혁명
새로운 인재상: 하이퍼 스페셜리스트 vs 하이퍼 제너럴리스트
터미널 UX의 도전과 혁신
Anthropic 합류 계기
코딩의 미래와 ASL4 시나리오
창업자/빌더를 위한 핵심 조언
TypeScript와 Claude Code의 평행 구조
핵심 인사이트 요약

1. 인터뷰 개요

이 인터뷰는 Y Combinator의 Light Cone 팟캐스트에서 진행된 심층 대담으로, Claude Code의 창시자이자 Anthropic 수석 엔지니어인 Boris Cherny가 출연했다. 인터뷰어는 Claude Code에 3주째 “수면을 빼앗길 정도로” 몰입해 있다고 고백하며 시작했다.

인터뷰는 Claude Code의 탄생부터 현재, 그리고 코딩의 미래까지 광범위한 주제를 다룬다. Boris는 2024년 9월 Claude Code를 처음 만들기 시작해 이후 3개월간 주말도 없이, 휴가도 없이 일했다고 회상했다. “뭔가 될 것 같다는 느낌이 있었지만 아직 유용한지 몰랐다”는 그의 말은 혁신적인 제품이 얼마나 불확실한 시작점에서 태어나는지를 잘 보여준다.

2. Claude Code의 탄생 배경

Anthropic의 장기 전략: 코딩에 올인

Boris에 따르면, Anthropic은 오래전부터 코딩을 핵심 베팅 영역으로 설정해왔다. 그 논리는 단순하다. 안전한 AGI로 가는 경로는 코딩을 통한다는 것이다.

“모델에게 코딩을 가르치고, 그다음 도구 사용을 가르치고, 그다음 컴퓨터 사용을 가르친다. 이 흐름이 처음부터 설계되어 있었다.”

이 철학은 Boris가 처음 합류한 Anthropic Labs 팀의 산출물에도 고스란히 드러난다. 이 팀에서 나온 세 가지 제품이 Claude Code, MCP(Model Context Protocol), 그리고 데스크탑 앱이다. 이 세 제품은 서로 유기적으로 연결된 하나의 큰 그림이다.

완전히 우연한 시작

Claude Code의 탄생은 놀랍도록 우발적이었다. 아무도 CLI(커맨드라인 인터페이스)를 만들라고 지시하지 않았다. Boris는 단지 Anthropic API를 이해하기 위해 “작은 터미널 앱”을 만들기 시작했을 뿐이다.

처음에는 단순한 채팅 앱이었다. 그 다음 API의 tool use 기능이 출시되자 Boris는 단순한 호기심으로 이를 실험해보기로 했다. 그는 모델에게 bash 도구를 주었고(당시 Anthropic 문서의 예제를 그대로 Python에서 TypeScript로 포팅했다), 모델에게 파일을 읽으라고 했다. 그런데 예상치 못한 일이 벌어졌다.

“지금 어떤 음악 듣고 있어?”라고 물었더니, 모델이 Apple Script를 작성해 Mac의 음악 플레이어에서 정보를 가져왔다. 이 순간이 Boris의 첫 번째 “AGI 느낌”이었다.

“오, 이 모델은 그냥 도구를 쓰고 싶어 한다. 그게 전부다.”

프로토타입에서 제품으로

첫 프로토타입을 만든 지 이틀 만에 Boris는 팀에게 내부 테스트용으로 공유했다. 다음 날 출근하니 동료 엔지니어 Robert가 이미 Claude Code로 실제 코딩을 하고 있었다. “이거 아직 준비 안 됐는데!”라고 반응했지만, 이미 유용성은 증명되고 있었다.

12월, 공식 외부 출시 검토 시 Dario(Anthropic CEO)는 내부 사용량 차트가 수직으로 치솟는 것을 보고 “엔지니어들에게 강제로 쓰게 하는 거냐?”고 물었다. 답은 아니었다. 그냥 입소문으로 퍼진 것이었다.

3. 터미널이라는 의외의 선택

왜 터미널인가?

Claude Code가 터미널에서 시작된 이유는 단순하다. “UI를 만들 필요가 없어서”였다. Boris 혼자였고, 가장 빠르게 실험할 수 있는 형태가 터미널이었다.

흥미로운 점은 이것이 기점이 아닌 종착점처럼 느껴진다는 것이다. Boris 자신도 가장 놀라운 부분 중 하나로 “아직도 터미널을 쓰고 있다는 것”을 꼽았다. 터미널이 시작점이어야 했는데 끝점이 됐다는 것이다.

터미널의 철학적 강점

터미널이라는 제약은 역설적으로 강력한 디자인 원칙이 됐다. 개발자들은 터미널에서 코딩한다는 느낌을 받지 않는다고 한다. 그냥 재미있다. 파일이 어디 있는지 생각하지 않아도 되고, 자연스럽게 흘러간다.

“터미널이 UI보다 6개월 뒤에도 유효할 UI를 만들 수 없다고 생각했기 때문에 CLI에 머문 것이기도 하다. 모델이 너무 빠르게 발전하고 있어서.”

이 결정은 단순한 편의가 아닌 깊은 전략적 선택이었다. 모델 성능이 빠르게 향상되는 상황에서 무거운 UI 레이어를 만들면 금방 구식이 되기 때문이다.

현재 Claude Code의 다양한 형태

터미널에서 출발했지만, Claude Code는 이제 웹, 데스크탑 앱, iOS/Android 앱, Slack, GitHub, VS Code 익스텐션, JetBrains 익스텐션 등 다양한 형태로 확장되었다. Boris는 지금도 CLI의 수명에 대해 틀렸다고 인정한다.

4. 초기 사용 사례와 CLAUDE.md의 탄생

2024년 초기 사용 패턴

당시 모델은 코딩을 잘 못했다. Boris 본인도 git 자동화, bash 명령 자동화, Kubernetes 운영 같은 용도로 주로 사용했다. 코딩 자체에는 2024년 2월 시점에 자신의 코드 약 10%만 Claude Code가 작성했다.

가장 초기의 코딩 사용 사례는 유닛 테스트 작성이었다. 리스크가 낮고, 결과가 명확해서 실험하기 좋았기 때문이다.

CLAUDE.md의 우발적 발명

엔지니어들이 자연스럽게 마크다운 파일을 만들어 모델이 읽도록 하기 시작했다. 이것이 CLAUDE.md의 기원이다. Boris는 이를 “잠재 수요(Latent Demand)”의 완벽한 예시라고 설명한다. 아무도 이 기능을 만들라고 하지 않았지만, 사람들이 이미 그 행동을 하고 있었기에 공식 기능으로 만든 것이다.

“제품에서 가장 중요한 단일 원칙은 잠재 수요다. Claude Code의 거의 모든 것이 초기 CLI 이후 잠재 수요를 통해 만들어졌다.”

5. Boris의 CLAUDE.md 철학

Boris 자신의 CLAUDE.md는 단 두 줄

Boris의 개인 CLAUDE.md는 딱 두 가지 지시사항만 담고 있다.

PR을 올릴 때마다 automerge를 활성화할 것 (누군가 승인하면 자동 머지)
PR을 올릴 때마다 내부 팀 Slack 채널에 포스트할 것 (빠른 리뷰를 위해)

나머지 모든 지침은 코드베이스에 체크인된 팀 공용 CLAUDE.md에 있다. 팀원 전체가 주 여러 번 기여한다. Boris는 PR을 보다가 예방 가능한 실수를 발견하면 바로 Claude에게 태그를 달아 “이걸 CLAUDE.md에 추가해”라고 지시한다.

CLAUDE.md가 너무 길어지면?

Boris의 조언은 명쾌하다. 삭제하고 처음부터 다시 시작하라.

“모델 성능은 버전마다 바뀐다. 원하는 것은 모델을 올바른 방향으로 안내하는 최소한의 것이다. CLAUDE.md를 삭제하고, 모델이 잘못된 방향으로 가면 그때 조금씩 추가하면 된다. 새 모델이 나올수록 추가할 것이 점점 줄어든다.”

많은 사람들이 CLAUDE.md를 과도하게 엔지니어링하려 하지만, 이는 역효과다. 모델의 능력이 매 버전 향상되므로, 전 버전에서 필요했던 지침이 더 이상 필요 없어지는 경우가 많다.

6. Plan Mode의 탄생과 미래

Plan Mode는 어떻게 만들어졌나

Plan Mode는 어느 일요일 밤 10시, Boris가 GitHub 이슈와 내부 Slack 피드백 채널을 훑어보다 발견한 패턴에서 나왔다. 사람들이 반복적으로 “계획은 세워줘, 근데 코딩은 하지 마”라고 요청하고 있었다. 형태는 달랐지만 공통 차원은 분명했다. “아직 코딩하지 말고 먼저 생각해.”

Boris는 그날 밤 30분 만에 만들어 월요일 아침에 배포했다. 기술적으로 Plan Mode가 하는 것은 단 하나다. 프롬프트에 딱 한 문장을 추가한다. “코딩하지 마세요.” 그게 전부다.

“사실 CLAUDE.md에 그냥 ‘아직 코딩하지 마’라고 써도 된다. Plan Mode는 그것의 버튼화일 뿐이다.”

Plan Mode의 현재 활용

Boris는 현재 세션의 약 80%를 Plan Mode로 시작한다. 여러 터미널 탭을 열고, 각각 Plan Mode에서 계획을 세우게 한 다음, 계획이 좋으면 실행한다. Opus 4.5부터, 특히 4.6에서 더 좋아진 점은 계획이 한 번 잡히면 실행 단계에서 거의 벗어나지 않는다는 것이다.

Plan Mode의 수명은 한 달?

Boris는 놀라운 예측을 했다. Plan Mode의 수명이 한 달 정도밖에 남지 않았을 수도 있다는 것이다. 이유는 이미 Claude Code가 스스로 Plan Mode에 진입할 수 있게 됐기 때문이다. 모델이 언제 계획을 세워야 하는지 스스로 판단하게 되면, 별도의 모드 자체가 필요 없어진다.

현재의 흐름을 보면, 6개월 전에는 계획 후에도 계속 감시해야 했고, 그 전에는 계획 전후 모두 감시가 필요했다. 이제는 계획 전 단계만 신경 쓰면 된다. 다음 단계는 프롬프트만 주면 나머지를 알아서 하는 것이다.

7. 서브에이전트와 멀티에이전트 시스템

서브에이전트란?

서브에이전트는 기술적으로 재귀적 Claude Code다. “mama quad”(어미 Claude Code)가 지시를 내리고, 여러 서브에이전트가 병렬로 작업을 수행한다. Boris에 따르면 현재 대부분의 에이전트가 실제로 Claude Code에 의해 프롬프트되는 서브에이전트 형태로 시작된다고 추측한다.

실제 활용 사례: 메모리 누수 디버깅

팀에서 메모리 누수가 있었다. Boris는 직접 heap dump를 열고 DevTools에서 프로파일링하며 추적하고 있었다. 그런데 동료 Chris는 그냥 Claude Code에게 물었다. Claude Code는 heap dump를 가져가 분석 도구를 스스로 만들어 Boris보다 더 빠르게 누수를 찾아냈다.

“이것을 계속 다시 배워야 한다. 내 뇌는 아직 6개월 전에 머물러 있다.”

서브에이전트 활용 전략

Boris의 방법은 작업 난이도에 따라 서브에이전트 수를 조절하는 것이다. 보통 작업이면 기본, 어려운 연구성 작업이면 3개, 5개, 심지어 10개의 서브에이전트가 병렬로 리서치하게 한다.

이 패턴을 CLAUDE.md에 넣지 않는 이유는 케이스 바이 케이스이기 때문이다. CLAUDE.md는 같은 것을 반복적으로 요청할 때 넣는 단축키다. 그렇지 않으면 그냥 직접 지시하면 된다.

Plugins 기능: 스웜으로 주말 동안 개발

Claude Code의 Plugins 기능 전체가 스웜(swarm) 에이전트들에 의해 주말 동안 만들어졌다. 엔지니어 한 명이 Claude에게 스펙을 주고, Asana 보드를 사용하라고 했다. Claude는 Asana에 티켓들을 생성하고, 여러 에이전트를 스폰하여 각자 태스크를 맡아 처리했다. 주 에이전트가 전체 스펙의 맥락 없이 독립적으로 작동하는 에이전트들에게 지시를 내렸다. 결과물은 거의 그대로 출시됐다.

8. Claude Teams 비전

핵심 아이디어: 비상관 컨텍스트 윈도우

Claude Teams의 핵심 철학은 “uncorrelated context windows(비상관 컨텍스트 윈도우)”다. 여러 에이전트가 서로의 컨텍스트나 이전 작업으로 오염되지 않은 깨끗한 컨텍스트 윈도우를 가진다는 개념이다.

더 많은 컨텍스트를 문제에 던지는 것은 테스트 시간 컴퓨팅의 한 형태다. 그 위에 올바른 토폴로지(에이전트들이 올바른 방식으로 소통하고 배치되는 방식)를 갖추면, 더 큰 것을 만들 수 있다.

Claude의 자율적 커뮤니케이션

Boris의 팀에서는 Claude들이 서로 대화한다. Slack에서 내부 사용자들과 소통하기도 한다. 심지어 Boris의 Claude가 가끔 트윗을 하기도 한다. (Boris가 삭제하지만) 패턴은 이렇다. Claude가 코드베이스에서 특정 엔지니어가 수정한 내용을 보고, Slack으로 해당 엔지니어에게 명확화 질문을 보낸다. 답변을 받으면 계속 작업을 진행한다.

9. 엔지니어 생산성 혁명

Anthropic 내부 데이터

Anthropic 팀은 작년에 팀 규모가 두 배로 늘었지만 엔지니어당 생산성은 약 70% 성장했다. 가장 단순한 측정 지표인 PR(Pull Request) 수로 계산했을 때, Claude Code 도입 이후 엔지니어당 생산성은 150% 성장했다.

이 수치가 얼마나 놀라운지 이해하려면 맥락이 필요하다. Boris는 이전에 Meta에서 코드 품질 및 개발자 생산성을 담당했다. 당시 2%의 생산성 향상이 수백 명이 1년간 작업한 결과였다. 150% 성장은 그야말로 “전례가 없는” 수치다.

Boris의 현재 코딩 방식

Boris는 IDE를 삭제했다. 단 한 줄의 코드도 손으로 직접 쓰지 않는다. 100% Claude Code와 Opus를 통해 코딩한다. 매일 약 20개의 PR을 올린다.

Dario의 예측(“Anthropic 코드의 90%가 Claude에 의해 작성될 것”)은 현실이 됐다. Boris 기준으로는 100%다. Anthropic 전체로는 팀에 따라 70~90% 수준이며, 많은 개인에게는 이미 100%다.

10. 새로운 인재상: 하이퍼 스페셜리스트 vs 하이퍼 제너럴리스트

이중 구조의 등장

Boris가 관찰하는 고효율 엔지니어는 두 가지 극단으로 나뉜다.

하이퍼 스페셜리스트: Jared처럼 메모리 누수 같은 특정 영역에서 세계 최고 수준의 이해를 가진 사람. Bun 팀처럼 JavaScript 런타임 시스템을 누구보다 깊이 아는 전문가들.

하이퍼 제너럴리스트: 제품-인포, 제품-디자인, 제품-유저 리서치, 제품-비즈니스를 넘나드는 사람들. “이상한 것”을 하는 사람들. 과거에는 “실제로 뭔가를 만들 수 있나?”라는 의심을 받았지만, 이제는 이런 사람들이 가장 가치 있다.

사례: Daisy 엔지니어의 사고방식

팀에 합류한 지 얼마 안 된 Daisy는 Claude Code에 새 기능을 추가하는 PR을 올렸다. 그런데 단순히 기능을 추가한 것이 아니었다. 먼저 Claude Code가 임의의 도구를 테스트하고 검증할 수 있는 도구를 만드는 PR을 올렸다. 그리고 나서 Claude에게 그 도구를 직접 구현하게 했다. 자신이 구현하는 대신 Claude에게 Claude를 위한 도구를 만들게 한 것이다.

“아직 많은 사람이 이 방식을 이해하지 못한다. 이것이 진짜 혁신적인 사고다.”

AI 시대의 채용 면접

Boris는 AI 에이전트와 코딩하는 세션 트랜스크립트를 채용 도구로 활용하는 것에 긍정적이다. 트랜스크립트를 보면 다음을 알 수 있기 때문이다.

로그를 들여다보는가?
에이전트가 잘못된 방향으로 가면 수정할 수 있는가?
Plan Mode를 사용하는가? 사용한다면 테스트를 확인하는가?
시스템을 이해하는가?

Boris는 이것이 NBA 2K의 스파이더웹 그래프처럼 누군가의 Claude Code 스킬 수준을 측정하는 도구가 될 수 있다고 본다. 스킬 축으로는 시스템 이해, 테스팅, 사용자 행동, 제품 감각, 자동화 능력 등이 될 것이다.

초심자의 마인드셋

Boris는 AI 시대에 가장 중요한 스킬은 “초심자 마인드셋”과 겸손함이라고 강조한다. 시니어 엔지니어들은 강한 의견을 가지도록 훈련됐지만, 그 의견들 중 많은 것이 이제 더 이상 유효하지 않다. 과학적으로 사고하고 제1원칙에서 출발할 수 있는 사람이 진짜 가치 있는 인재다.

채용 면접에서 Boris가 즐겨 묻는 질문: “언제 자신이 틀렸다고 인정한 예시를 들어보세요.” 실수를 인식하고, 책임지고, 거기서 배울 수 있는지를 본다.

11. 터미널 UX의 도전과 혁신

터미널 디자인의 제약과 재발명

터미널은 가로 80자, 세로 100자 정도의 공간에 256가지 색상, 하나의 폰트 크기, 마우스 인터랙션 없음이라는 극도의 제약 속에 있다. Boris는 터미널 UX 원칙을 완전히 새로 발명해야 했다고 한다. 기존 터미널 앱들은 ncurses 기반의 창(window) 시스템을 사용해 현대 기준으로 복잡하고 투박해 보인다.

흥미로운 사실: Claude Code의 터미널은 실제로 React로 만들어져 있다.

Verbosity(출력 상세도) 결정 과정

Claude Code가 얼마나 자세한 정보를 터미널에 보여줄지는 끊임없는 논쟁거리였다. Boris는 약 6개월 전 bash 출력을 요약으로 대체하려 했다. 하루 동안 Anthropic 직원들에게 테스트했더니 모두 반발했다. 특히 Kubernetes 작업처럼 실제 출력을 봐야 하는 경우가 있었기 때문이다.

최근에는 파일 읽기와 파일 검색을 축약했다(“1개 파일 읽기”, “1개 패턴 검색” 등). 이는 6개월 전에는 불가능했다. 당시 모델은 여전히 잘못된 파일을 읽는 경우가 많아 사용자가 직접 확인해야 했다. 이제 모델이 충분히 신뢰할 수 있어서 요약이 가능해졌다.

그러나 GitHub 이슈에서 사용자들이 반발했다. 그래서 verbose 모드를 추가했다. Boris는 이런 피드백을 가장 좋아한다. 사람들이 어떻게 사용하고 싶은지 듣는 것이 즐겁기 때문이다.

터미널 스피너: 50~100번의 반복

터미널의 로딩 스피너 하나가 약 50~100번 반복 수정을 거쳤다. 80%는 출시되지 않았다. 시도하고 느낌이 좋지 않으면 다음 것을 시도했다. Claude Code 덕분에 20개의 프로토타입을 연속으로 빠르게 만들 수 있었다. 과거라면 Origami나 Framer로 3개 만드는 데 2주가 걸렸을 것이다.

12. Anthropic 합류 계기

Boris는 일본 시골에 살면서 매일 아침 Hacker News를 열면 AI 관련 뉴스로 가득 찼던 시절을 기억한다. 초기 AI 제품들을 사용해보니 “숨이 막힐 정도”였다고 한다.

Anthropic의 공동창업자 Ben Mann을 만났고, 이후 팀 전체를 만나며 두 가지 이유로 합류를 결심했다.

첫째, Anthropic은 연구 기관처럼 운영된다. 제품이 주인공이 아니라 모델이 주인공이다. 수년간 제품을 만들어온 Boris에게 이것은 신선한 관점이었다.

둘째, 사명 중심의 문화다. 열렬한 SF 독자인 Boris는 AI가 잘못될 수 있는 최악의 시나리오를 잘 알고 있다. Anthropic의 복도와 구내식당에서 사람들이 AI 안전에 대해 이야기하는 것을 들을 수 있다. 그런 곳에 있고 싶었다.

13. 코딩의 미래와 ASL4 시나리오

하한: 코딩의 완전한 민주화

Boris의 하한 예측은 코딩이 모든 사람에게 “일반적으로 해결될(generally solved)” 것이라는 전망이다. 이미 Boris 본인에게는 실질적으로 해결됐다. “소프트웨어 엔지니어”라는 직함은 사라지고, “빌더”나 “제품 매니저” 같은 역할로 대체될 것이다.

Anthropic 팀 내부에서는 이미 PM, 디자이너, EM, 심지어 재무 담당자까지 모두 코딩한다. 이 트렌드가 전체 산업으로 퍼질 것이다.

상한: ASL4의 등장

더 두렵고 극적인 시나리오는 ASL4다. ASL3는 현재 모델 수준이다. ASL4는 모델이 재귀적 자기 개선(recursive self-improvement)을 할 수 있게 되는 단계다. 이 수준에 도달하면 엄격한 기준을 충족해야만 모델을 출시할 수 있다.

또한 bioweapon 설계, 제로데이 취약점 설계 같은 치명적 악용 가능성도 우려된다. Anthropic은 이를 방지하기 위해 적극 연구 중이다.

공개 지표들

인터뷰 시점 기준 일부 외부 통계:

Mercury 조사: 스타트업의 70%가 Claude를 선호 모델로 선택
전 세계 공개 커밋의 약 4%가 Claude Code로 작성됨
NASA 퍼서비런스 화성 탐사선 궤도 계획에도 Claude Code가 활용됨

14. 창업자/빌더를 위한 핵심 조언

조언 1: 오늘의 모델이 아닌 6개월 후 모델을 위해 만들어라

“지금 모델이 잘 못하는 것이 무엇인지 생각해라. 곧 잘하게 된다. 그냥 기다리면 된다.”

이 조언의 역설은 PMF(Product-Market Fit)를 찾으려면 제품이 작동해야 한다는 현실과의 긴장이다. 그러나 오늘의 모델에만 최적화하면 새 모델이 나올 때 경쟁자에게 뒤처진다.

경계를 느끼고, 6개월 후 모델이 어떨지 감을 잡고, 그것을 위해 만들어라.

조언 2: 모델에 절대 베팅하지 마라 (Bitter Lesson)

Anthropic 팀 자리 옆 벽에는 Rich Sutton의 “The Bitter Lesson”이 액자로 걸려 있다. 핵심 메시지: 더 범용적인 모델이 항상 더 특화된 모델을 이긴다.

이의 함의는 명확하다. 모델의 한계를 보완하기 위한 스캐폴딩을 과도하게 만들지 말라. 10~20%의 성능 향상을 위해 엔지니어링 공수를 쏟아붓는 것은 대부분 다음 모델 출시 때 무의미해진다. 그냥 기다리면 모델이 해준다.

이것이 Claude Code 코드베이스가 6개월마다 전면 재작성되는 이유다. 스캐폴딩을 계속 삭제하고 새로 만든다. Claude Code에는 6개월 전에 있던 코드가 단 한 줄도 없다.

조언 3: 잠재 수요를 찾아라

사람들이 이미 하고 있는 것을 더 쉽게 만들어라. 새로운 행동을 하도록 설득하려 하지 마라. 잠재 수요를 발견하는 법: 사용자 피드백을 읽고, GitHub 이슈를 보고, 사무실을 돌아다니며 사람들이 도구를 어떻게 쓰는지 관찰하라.

조언 4: 에이전트가 원하는 것을 생각하라

DevTool 창업자에게 Boris의 핵심 질문은 하나다.

“모델이 하고 싶어 하는 것이 무엇인가? 어떻게 하면 그것을 더 쉽게 만들 수 있는가?”

모델을 박스에 가두고 “API는 이렇게 쓰고, 세상과 이렇게 상호작용해”라고 하지 마라. 모델이 무엇을 원하는지 관찰하고, 그것을 가능하게 만들어라. 사용자를 위한 제품을 만들 때와 같은 방법론이다.

15. TypeScript와 Claude Code의 평행 구조

Boris는 TypeScript 책을 저술한 초기 TypeScript 사용자이기도 하다. TypeScript가 JavaScript 커뮤니티에서 처음 나왔을 때의 상황은 Claude Code가 터미널에서 시작한 것과 묘하게 닮아 있다.

TypeScript는 처음에 매우 이상한 언어 결정들을 했다. 리터럴 타입이 첫 번째 클래스 타입이 될 수 있다거나, 조건부 타입 같은 것은 어느 언어도 생각하지 못했다. 이 “이상한” 결정들은 학문적 논리가 아닌 순전히 실용적 관찰에서 나왔다.

TypeScript 팀의 접근법: JavaScript 개발자들이 코드 작성 방식을 바꾸도록 설득하지 말 것. 그들이 이미 작성하는 방식(뮤테이션, 리플렉션, 비안전한 패턴들)을 그대로 타입 시스템으로 감쌀 것.

Claude Code도 같은 철학이다. 엔지니어들이 도구를 좋아하는 방식은 사람마다 다르다. Vim 광신도도 있고 VS Code 사용자도 있다. Claude Code는 그 어떤 방식도 강요하지 않는다. 그냥 열면 된다.

결과: 15년이 지난 지금, Haskell로 만들어진 코드베이스보다 TypeScript로 만들어진 것이 훨씬 많다. 실용주의가 학문주의를 이겼다.

16. 핵심 인사이트 요약

제품 전략

원칙	내용
잠재 수요	사람들이 이미 하고 있는 것을 발견하고 더 쉽게 만들어라
6개월 후 모델	오늘이 아닌 내일의 모델을 위해 설계하라
최소 스캐폴딩	모델이 할 수 있는 것은 모델에게 맡겨라
Bitter Lesson	범용 모델은 항상 특화 솔루션을 이긴다

사용 방법

실천	효과
CLAUDE.md 최소화	매 모델마다 필요한 것이 줄어든다
Plan Mode 우선	복잡한 작업에서 실행 오류를 줄인다
서브에이전트 병렬화	어려운 문제를 더 빠르게 해결한다
초심자 마인드셋	모델 능력을 과소평가하지 않는다

미래 전망

소프트웨어 엔지니어라는 직함의 소멸, 모두가 코딩하는 세상
Plan Mode 같은 명시적 모드의 소멸, 모델이 스스로 판단
에이전트들이 사용자와 직접 소통하는 세상
ASL4 도달 시의 새로운 패러다임

본 문서는 Y Combinator Light Cone 팟캐스트 인터뷰의 한국어 심층 분석 자료입니다.
정리 일자: 2026-02-23

AI, Claude Code

AI claude-code CLAUDE.md sub-agents multi-agent agent-teams claude-teams BorisCherny Claude.write