코딩하지 마라: Boris Cherny on Claude Code

Claude Code 창시자 Boris Cherny가 말하는 Claude Code의 시작, '코딩은 끝났다'는 단언, loops/routines 기반의 멀티 에이전트 워크플로, 그리고 AI가 재편하는 SaaS 해자에 대한 인터뷰.

YouTubeyoutu.be/is0zk47UjRc
코딩하지 마라: Boris Cherny on Claude Code

"코딩하지 마라": Boris Cherny가 말하는 Claude Code

Anthropic 행사에서 진행된 Claude Code 창시자 Boris Cherny와의 인터뷰. Claude Code의 시작, 소프트웨어 개발의 모습이 어떻게 바뀌고 있는지, 그리고 에이전트가 키보드를 차지한 뒤 산업이 어디로 향하는지를 다룬다.

Claude Code는 'Product Overhang'에 대한 베팅이었다

Boris는 2024년 말, Anthropic 내부의 소규모 인큐베이터인 Anthropic Labs에서 거의 우연히 Claude Code를 시작했다. 팀의 가설은 product overhang(모델은 이미 어떤 제품도 담아내지 못한 일을 해낼 수 있다는 것)이었다.

"당시 최첨단 기술은 type ahead였어요. IDE에서 탭을 누르면 한 줄이 자동으로 채워지는 거죠. 그런데 우리 느낌은 훨씬 더 멀리 갈 수 있다는 거였어요. 에이전트가 코드를 전부 짜면 되잖아요."

처음 6개월간 제품은 거의 쓸 수 없는 수준이었다. 출시 후에도 한동안 인기가 없었다. 지수적 성장은 5월 Opus 4와 함께 시작됐고, 그 뒤 4, 4.5, 4.6, 4.7로 모델이 나올 때마다 변곡점을 찍었다. 전략의 핵심은 처음부터 끝까지 현재 모델이 아니라 다음 모델을 위해 만든다는 것이었다.

"우리는 PMF 이전 상태의 제품을 만들고 있었어요. 그리고 앞으로 6개월간은 PMF가 안 나올 거라는 것도 알고 있었죠. 다음 모델을 위해 만들고 있었으니까요."

"코딩은 끝났다": Boris는 코드의 100%를 에이전트로 짠다

손으로 코드를 100% 짜는 사람이 누구냐, 에이전트로 100% 짜는 사람이 누구냐는 질문에 대한 Boris의 답은 명확하다. 본인은 100% 에이전트.

"Claude Code 코드베이스는(유출돼서 다들 아실 텐데) 그냥 TypeScript하고 React예요. 큰 비밀도 없고 복잡한 것도 없어요."

TypeScript와 React를 고른 이유는 모델 학습 분포에 잘 맞기 때문이었다. Claude Code 자체의 코드가 100% 모델에 의해 작성되기 시작한 건 작년 10–11월쯤이다. Boris는 하루에 수십 개의 PR을 올리고, 최근에는 하루에 150개 PR을 올린 기록도 있다. 어디까지 갈 수 있는지 일부러 밀어붙여 본 결과다.

이게 어디서나 통하는 건 아니다. 크고 복잡한 코드베이스, 흔치 않은 언어에서는 모델이 여전히 헛발질한다. "보통 답은 그냥 다음 모델을 기다리는 거예요."

개인 작업 환경: 폰, 루프, 그리고 수백 개의 에이전트

Boris는 작업의 대부분을 휴대폰에서 한다. Claude 앱의 code 탭에 5–10개의 세션을 늘 띄워두고, 각 세션이 서브에이전트를 띄운다. 낮 동안 수백 개 에이전트, 깊은 작업이 도는 밤에는 수천 개.

진짜 돌파구가 된 건 서브에이전트가 아니라 /loop다.

"정말 단순한데 잘 돼요. Claude가 cron으로 작업을 예약하는 거예요. 1분, 5분, 하루 단위로 돌릴 수 있어요. 저는 수십 개 루프를 돌리고 있어요."

Boris가 늘 돌리고 있는 루프들: - 자기 PR을 돌보는 루프: CI 고치기, 자동 리베이스 - CI 자체를 건강하게 유지하는 루프: flaky 테스트가 생기면 알아서 고침 - Twitter 피드백을 30분마다 끌어와 클러스터링하는 루프

"지금 시점에서 루프가 미래라는 느낌이 들어요. 아직 안 써봤다면 정말 추천합니다."

Anthropic은 최근 routines도 출시했다. 같은 개념인데 서버 사이드에서 돌기 때문에, 노트북을 닫아도 루프가 계속 돈다.

팀은 분야를 가로지르는 제너럴리스트가 된다

오늘날 말하는 '제너럴리스트'(iOS, 웹, 서버를 다 다루는 프로덕트 엔지니어)는 결국 엔지니어다. Boris는 다음 물결의 제너럴리스트는 분야 자체를 가로지르는 사람이 될 거라고 본다. 엔지니어이면서 디자인도 잘하거나, 프로덕트도 잘하거나, 데이터 사이언스도 잘하는 사람.

"우리 팀은 엔지니어링 매니저, PM, 디자이너, 데이터 사이언티스트, 재무 담당, 유저 리서처까지 한 명도 빠짐없이 코드를 써요. 각자 전문 분야가 있지만, 이제는 다 같이 코드를 쓰는 거죠."

SaaS 종말론: 약해지는 해자와 그렇지 않은 해자

Boris는 SaaS 종말론을 Hamilton Helmer의 Seven Powers 프레임워크로 다시 짠다. AI는 어떤 파워는 약화시키고 어떤 파워는 그대로 둔다.

약해지는 파워: - 전환 비용(switching costs): 모델이 한 제품에서 다른 제품으로 쉽게 옮겨준다. - 프로세스 파워(process power): 워크플로 전문성이 해자였던 회사들은 입지가 좁아진다. Claude 4.7은 "무엇이든 hill climb할 수 있다." 목표를 주고 끝날 때까지 돌리라고 하면 그냥 해낸다.

여전히 단단한 파워: - 네트워크 효과 - 규모의 경제 - 코너드 리소스(cornered resources)

두 번째 예측은 더 대담하다. 앞으로 10년간 산업을 흔드는 스타트업의 수가 ~10배 늘어난다. 작은 스타트업이 큰 회사만큼 가치 있는 제품을 만들어 정면으로 붙을 수 있다. 큰 회사는 기존 프로세스와 사람을 이끌고 변화를 헤쳐나가야 하기 때문이다.

"처음부터 시작한다면 AI를 기본 전제로 깔고 처음부터 만들 수 있어요. 지금이 스타트업을 하기 가장 좋은 시기예요."

Deep Dive: Hamilton Helmer의 Seven Powers 전체 그림

Boris는 영상에서 7가지 중 5가지만 언급해요. 프레임워크 전체와 빠진 두 파워의 함의까지 정리.

7가지 파워의 정의

# Power 정의 사례
1 Scale Economies 생산량이 늘수록 단위당 비용이 떨어짐 Netflix(콘텐츠 비용 분산), Amazon 물류
2 Network Effects 유저가 늘수록 각 유저의 효용이 커짐 Facebook, eBay, LinkedIn
3 Counter-Positioning 기존 사업 모델을 망가뜨려야만 따라할 수 있어서 거대 경쟁자가 못 따라옴 Vanguard 인덱스펀드 vs 액티브 펀드, Netflix vs Blockbuster
4 Switching Costs 다른 제품으로 옮기는 비용(금전·절차·관계)이 커서 잠김 SAP/Oracle ERP, AWS
5 Branding 기능 차이를 넘어선 정서·신뢰 기반 가치 Hermès, Tiffany's, Coca-Cola
6 Cornered Resource 희소 자원(인재·IP·입지)에 대한 우선 접근 Pixar의 brain trust, 특허
7 Process Power 조직에 깊이 박혀 흉내 내기 힘든 운영 프로세스 Toyota Production System

모든 파워는 Benefit(경제적 가치 창출) + Barrier(경쟁자가 못 따라 하는 장벽) 두 조건을 동시에 만족해야 진짜 파워로 인정돼요.

Boris가 언급 안 한 두 가지의 흥미로운 함의

  • Counter-Positioning: 오히려 AI 시대에 가장 강력해질 수 있는 파워. 기존 SaaS 회사는 "비싼 엔지니어 다수 + per-seat 가격" 위에 P&L이 짜여 있어서, 에이전트 기반으로 갈아엎으면 자기 매출 구조가 무너져요. 그래서 못 따라옴. AI 네이티브 스타트업이 노릴 수 있는 가장 명확한 자리.
  • Branding: 기능 차이가 사라지는 시기에 오히려 더 중요해질 수 있어요. 모두가 같은 모델을 쓸 때 "왜 이 회사 제품을 쓰는가"는 기능이 아니라 신뢰·취향·문화 같은 비-기능적 차이로 옮겨가요.

소프트웨어 민주화: 인쇄기 비유

Boris가 가장 명확하다고 보는 역사적 비유는 인쇄기다. 인쇄기 이전 유럽 인구의 ~10%만 글을 읽고 쓸 줄 알았고, 보통 글을 못 읽는 왕과 영주들이 이들을 전문 독자/필경사로 고용했다. 첫 인쇄기 이후 50년간 유럽에서 출판된 책의 양은 그 전 천 년간의 출판량을 넘었다. 책 값은 약 100배 떨어졌다. 그 뒤 몇 백 년에 걸쳐 전 세계 문해율은 ~70%까지 올랐다.

"지금 일어나려는 일도 비슷해요. 다만 50년보다 훨씬 빠르게 일어날 거예요. 소프트웨어가 완전히 민주화돼서 누구나 할 수 있는 일이 됩니다."

여전히 전문 작가가 있는 것처럼 전문 엔지니어도 남는다. 하지만 더 인상적인 함의는 어떤 소프트웨어를 누가 가장 잘 만들 수 있느냐다.

"회계 소프트웨어를 가장 잘 만들 수 있는 사람은, 어쩌면 오늘 시점에도, 엔지니어가 아니라 진짜 잘하는 회계사예요. 그 도메인을 정말 잘 아니까요. 코딩은 쉬운 부분이고, 도메인을 아는 게 어려운 부분이에요."

제품 vs 모델: 비중이 옮겨가고 있다

Claude Code의 성공에서 모델 기여도와 제품 기여도가 어느 정도냐는 질문에, Boris는 1년 전에도 50/50, 6개월 전에도 50/50이었다고 답했다. 모델이 좋아질수록 harness의 비중은 줄어든다. 프롬프트 인젝션 방어, 명령어 정적 검증, 권한 모드, 휴먼 인 더 루프 같은 안전 장치들은 모델이 충분히 정렬되면 대부분 사라진다. 그땐 모델이 그냥 "옳은 일을 한다."

그래도 "사람들이 사랑하는 제품을 만들어라"는 여전히 유효하다. 종일 쓰는 도구가 쾌적하려면 자잘한 디테일에 집착해야 한다.

제품 측면의 질문도 바뀐다. 루프를 어떻게 일급 시민(first-class)으로 만들 것인가. 여러 에이전트를 병렬로 돌리는 일을 어떻게 쉽게 만들 것인가?

멀티 에이전트: 유저에게 조율을 떠넘기지 마라

병렬화에 대해, Boris는 유저가 언제 에이전트를 띄울지 직관으로 판단해야 한다는 프레이밍을 거부한다.

"유저가 도구를 더 잘 잡는 법을 알아내야 한다면, 그건 제품 디자인 문제예요. 제가 일을 잘 못하고 있다는 뜻이죠. 이건 모델이 더 잘해야 하는 일이에요."

4.7은 이미 자연스럽게 이렇게 동작한다. 데이터를 가져오라고 시키면 스스로 "데이터가 시간에 따라 바뀌고 있네요. 루프를 시작해서 30분마다 리포트를 드릴게요" 라고 제안하고, Slack MCP로 리포트를 전달한다.

로컬 vs 클라우드: 중요하지 않다

미래가 클라우드 중앙집중형 컴퓨팅이 될지, 로컬 에이전트가 될지에 대해:

"중요하지 않다고 봐요. 모델이 코드를 다 짤 거고, 에이전트를 띄울 거고, 환경도 만들 거예요. 어떤 작업에 로컬 모델을 쓰는 게 낫다고 판단하면, 그렇게 하겠죠. 이런 건 더 이상 우리가 엔지니어로서 결정할 문제가 아니에요."

Anthropic의 진짜 우위는 기술이 아니다

내부에서 dogfooding할 때 Anthropic은 다른 사람들과 같은 모델을 쓴다. 실험용으로 Mythos를 좀 쓰고, 대부분은 Opus 4.7로 코드를 짠다. 모델 격차는 크지 않다. Anthropic은 자기가 파는 것을 그대로 쓰기 때문이다.

진짜 격차는 조직 프로세스다.

"우리는 Claude를 정말 모든 일에 써요. 우리의 Claude들이 하루 종일 떠들고 있어요. 제가 코딩하는 동안 제 Claude들이 루프 안에서 코딩을 하고, 다른 사람들의 루프 도는 Claude들과 Slack으로 이야기해서 모르는 걸 알아내요. 회사 어디에도 수동으로 짠 코드가 없어요. 모든 SQL은 모델이 써요."

이 조직적 재배선은 모델보다 훨씬 따라잡기 어렵다. 하지만 동시에 스타트업의 강점이기도 하다. "처음부터 그렇게 시작하는 게 훨씬 쉬워요."

코드 너머: MCP와 Computer Use

일반적인 지식 노동(Co-work 제품)에서 에이전트에게 충분한 접근권을 주려면, 답은 개발자용과 같다: MCP. Claude.ai에서 쓰는 Salesforce, Google Docs, Google Calendar 커넥터를 Co-work에서도, Claude Code에서도 그대로 쓴다.

MCP가 없는 시스템에는 computer use가 catch-all이다. 4.7과 함께라면 느리긴 해도 컴퓨터에 있는 거의 모든 소프트웨어를 잘 쓴다.

"MCP든, CLI든, API든, 프로그래밍으로 접근할 수 있으면 돼요. 모델은 신경 안 써요. 모델 입장에서는 다 그냥 토큰이거든요."

지금 Boris가 만든다면

지금 만들 때의 패턴은 Claude Code를 성공시킨 패턴과 같다. 지금 모델이 할 수 있는 것이 아니라, 6–12개월 뒤 모델이 할 수 있을 것에 베팅하라. 모델이 좋아질수록 훨씬 더 흥미로워지는 영역으로 Boris가 꼽은 것들:

Source

Deep Dive

2026-05-17

왜 "루프가 미래"인가: 구조적 5가지 이유

Boris가 영상에서 "지금 시점에서 루프가 미래라는 느낌이 들어요"라고 말한 건 단순히 cron 같은 스케줄러를 의미하는 게 아니에요. 패러다임 전환의 단위로서의 루프를 가리켜요.

1. 사람의 주의와 에이전트 처리량의 디커플링. 지금까지 에이전트는 인터랙티브 도구였어요. 내가 묻고 답을 받는 구조라 처리량은 사람의 타이핑 속도가 상한이었어요. 루프는 이 줄을 끊어요. 한 사람이 수십~수천 개 에이전트를 동시에 자기 의도로 굴리는 단위가 돼요. Boris가 폰에서 하루 150 PR을 올리는 게 가능한 이유는, 그는 코드를 짜는 게 아니라 상시 실행되는 의도(standing intent)들을 관리하는 거예요.

2. 병목이 "코드 쓰기" → "목표 정의 + 차이 검토"로 이동. 루프는 "이 PR이 계속 그린 상태이도록 유지해줘" 같은 standing intent를 코드화해요. 사람이 자는 동안에도 에이전트가 그 의도를 향해 일해요. 단순히 코딩이 빨라진다가 아니라, 소프트웨어 일의 단위 자체가 함수에서 의도로 바뀐다는 의미.

3. 비용 곡선이 백그라운드 작업에 유리해짐. 토큰 비용이 빠르게 내려가면서, "비싸고 동기적인 한 세션"보다 "싸고 좁고 많이 도는 100개 루프"가 경제적으로 더 나은 구간에 들어왔어요. 점진적으로 백그라운드 작업이 디폴트가 돼요.

4. Self-pacing이 루프를 진짜 데몬으로 만든다. 간격을 빼면 Claude가 직접 다음 실행 시점을 결정해요. 목표 달성 시 알아서 종료하고, 외부 상태가 안 변했으면 더 길게 자요. 단순 cron과 결정적으로 다른 지점, 타이머가 아니라 목표 지향 데몬(goal-driven daemon)이에요.

5. Routines로 promote 가능. /loop은 개발자의 실험장이에요. 잘 돌아가는 게 검증되면 Routines(서버사이드)로 옮길 수 있어요. 노트북을 닫아도, GitHub 이벤트나 API webhook으로도 트리거 가능. 같은 멘탈 모델로 시작해서 production-grade로 키울 수 있다는 게 강력해요.

Boris의 주장을 한 문장으로: "인터랙티브 시대의 product surface는 채팅창이었다. 자율 에이전트 시대의 product surface는 루프다."

루프 실전: 메커니즘과 사용법

메커니즘. /loop은 Claude Code 슬래시 커맨드. 내부적으로 인터벌을 cron 표현식으로 변환해 CronCreate 프리미티브에 등록해요. 스케줄러가 매초 due task를 체크해 낮은 우선순위로 큐에 넣고, Claude의 턴 사이에 발화해요 (응답 중간엔 안 끼어듦). 시간대는 사용자 로컬 기준.

세 가지 변형: 자주 헷갈리니까 명확히.

/loop (세션) Desktop scheduled tasks Routines (클라우드)
어디서 도나 현재 터미널 세션 내 맥 Anthropic 서버
노트북 닫으면 죽음 맥이 켜져 있어야 함 계속 돔
트리거 종류 간격 / self-pacing 간격 간격 + GitHub 이벤트 + API webhook
영속성 세션 종료 시 사라짐 영속 영속
플랜 모든 플랜 모든 플랜 Pro/Max/Team/Enterprise

명령어 예시.

# 간격 기반
/loop 5m check if the deployment finished and tell me what happened

# 자연어 인터벌
/loop check Vercel build status every 2 hours

# 다른 슬래시 커맨드를 루프로
/loop 20m /review-pr 1234

# Self-pacing — Claude가 알아서 페이스 정함
/loop keep retrying the failing test until it passes, then stop

# 관리
/tasks   # 이 세션의 모든 활성 루프 보기

지원 단위: s m h d. cron 표현식도 받음 (*/15, 1,15,30).

제약사항. - 세션당 50 task 한도 - 7일 자동 만료(폭주 방지). /loop 1d는 약 7번 돌고 사라짐. 매일 도는 작업은 Desktop tasks나 Routines로 - 컨텍스트 윈도우 누적: 오래 도는 세션은 품질 저하. 사이사이 /compact 권장 - 턴 사이에만 발화: 인터랙티브로 계속 묻고 있으면 큐에 쌓임

실전 사용 패턴. - PR 베이비시터: N분마다 main에 rebase → CI 확인 → 실패 시 패치 푸시 - CI 힐러: 테스트 스위트의 flaky 테스트 탐지 → 원인 격리 → 자동 패치 PR - 피드백 클러스터러: 30분마다 Twitter/Slack 멘션 → 테마별 클러스터링 → 다이제스트 - Deploy 폴러: 헬스체크가 OK 될 때까지 self-pacing 폴링 - Ralph loop / 야간 빌더: 사람 자는 동안 긴 호흡의 자율 빌드. Boris는 폰으로 디스패치 후 잠. 아침에 결과 받음 - 모닝 다이제스트: 야간 변경/PR을 슬랙으로 정리

주의해야 할 것. 1. 토큰 비용은 조용히 무한정 쌓임. 10분 루프를 4시간 방치 = 24회 실행. 잊힌 루프가 쿼터를 갉아먹어요. /tasks로 자주 확인 2. 쓰기 권한 있는 루프는 위험. 커밋·포스팅·파일 수정을 멈출 때까지 계속함. 도구 접근 범위를 의도적으로 좁히세요 3. 실패 처리는 자동이 아님. 에러 경로를 프롬프트에 명시 안 하면 중간에 멈춤. "실패 시 ~하라"를 의도에 박아넣으세요

처음 시도하기 좋은 것. 본인 워크플로 중 "매 X분마다 한 번 체크하면 좋겠는데"라고 떠올린 적 있는 일을 하나 골라서 /loop로 돌려보세요. 가장 흔한 첫 사용처는 "지금 도는 배포/빌드가 끝났는지 폴링". 5분짜리로 시작 → self-pacing으로 진화 → 잘 되면 Routine으로 promote.

Key Insight

루프는 cron이 아니다. 사람의 주의와 에이전트 처리량의 디커플링이고, 함수 단위에서 의도 단위로 옮겨가는 작업 원자의 재정의이며, 채팅창 다음 세대의 product surface다.

References