Claude Code 워크플로우 (3) — Boris Cherny "Why Coding Is Solved" 강연 후기

시리즈 로드맵

• (1) gstack + Superpowers — 두 플러그인만 남긴 이유
• (2) gstack /office-hours로 AI에게 제품 인터뷰를 받아봤다
• (3) Boris Cherny "Why Coding Is Solved" 강연 후기 ← 현재 글

TL;DR

• Boris Cherny는 2025년 10월부터 손으로 코드를 짜지 않는다. 하루 PR을 수십 개, 기록은 150개까지 올린다.
• 그의 작업 방식의 중심은 세션을 capacity로 스케줄링하는 것 — 터미널 5탭, 브라우저 5~10세션, 핸드폰까지 동시에 돌아간다. 핵심은 디바이스가 아니라 *"주의력을 어디에 배분하느냐"*다.
• 그가 자주 쓰는 메커니즘은 /loop (cron으로 반복 작업 스케줄)와 새 기능 Routines (서버 측에서 영구 실행).
• Boris도 YC 출신이고, 거기서 배운 첫 원칙이 *"first build for yourself". (1)~(2)편의 *"Make something people want"와 정확히 같은 자리에 있다.
• 시리즈 결론: 사용자 인터뷰와 프롬프트 설계는 같은 능력이다. 도구가 무엇이든 앞단에서 정확하게 정의하는 일이 결과의 90%를 결정한다.

영상을 보게 된 맥락 — Boris도 YC 출신이라니

강연 관련 자료를 정리하다가 Pragmatic Engineer 인터뷰와 developing.dev 인터뷰에서 Boris 본인의 발언을 발견했습니다.

"I did YC back in the day, and in YC they teach you that first you build for yourself. You have to build awesome stuff. You have to build stuff people love."

Boris도 창업해서 YC를 거쳐본 사람이었고, 거기서 배운 첫 원칙이 "first build for yourself" — 너 자신을 위해 먼저 만들어라, 그게 다른 사람도 같은 문제를 갖고 있다는 가장 좋은 신호니까 — 였다는 겁니다.

이걸 알고 나서 강연을 다시 보면, 왜 그가 자기 자신을 위해 Claude Code를 만들고 "이게 내가 코드 짜는 방식이었다"라고 자연스럽게 말하는지가 다르게 들립니다. 우연이 아니라 일관된 원칙입니다.

강연의 골자 — 숫자로 보는 워크플로우

영상과 외부 보도(BigGo 분석, Pragmatic Engineer)를 종합하면 그의 작업 방식은 이렇게 요약됩니다.

항목	내용
마지막으로 손코딩한 시점	2025년 10월
일일 PR	수십 개, 기록은 150개
동시 세션 수	터미널 5탭 + 브라우저 5~10 + 핸드폰
핵심 메커니즘	/loop (cron 스케줄), Routines (서버 측 영구 실행)
사용 코드베이스	TypeScript + React (모델의 "분포 위에 있다"는 이유로 의도적으로 선택)
변곡점 모델	Opus 4 (2025년 5월 출시) — 이 모델 이후 100% AI 코딩 가능

수치만 보면 비현실적인 사람 같지만, 그가 만든 도구가 그걸 가능하게 설계됐다는 게 핵심입니다.

"loop"가 정확히 뭔가

영상에서 자주 나오는 단어가 loop입니다. 그는 이걸 *"crontab처럼 돌리는 것"이라고 표현하는데, 단순한 비유가 아닙니다 — /loop 슬래시 커맨드가 실제로 cron을 사용해 반복 작업을 스케줄합니다.

기존 LLM 사용 = 단발성. "한 번 묻고 한 번 답한다."
loop = 영구. "한 번 잘 정의해두고 계속 돌아간다."

그가 loop로 처리한다고 밝힌 작업들:

• PR 베이비시팅 (CI 실패 자동 수정, 자동 리베이스)
• 피드백 클러스터링
• 데이터 변화 감지 후 결과를 Slack으로 푸시 (MCP 경유)

여기서 한 단계 더 나간 게 Routines — 2026년 4월 발표된 새 기능입니다. 공식 발표에 따르면 Routines는 "한 번 설정하면 스케줄에 따라, API 호출로, 또는 GitHub 이벤트에 반응해서 실행되며, Anthropic 인프라 위에서 돌기 때문에 노트북이 필요 없다"고 합니다.

즉, 작업이 그의 디바이스에 묶여 있지 않습니다. 사람은 어디서든 지시·검증만 하고, 실제 작업은 서버에서 계속 돌아가는 구조입니다.

이 부분에서 (1)편의 5단계 워크플로우와 결이 비슷하다고 느꼈습니다. (1)편의 핵심도 "사람이 모든 단계에 붙어있지 않는다"였습니다. 회의(/office-hours) → 계획서(writing-plans) → 분업 실행(sub-agent) 형태로 각 단계가 독립적으로 돌아갑니다. Boris는 그걸 훨씬 더 극단적으로 밀어붙인 형태일 뿐입니다.

"AI는 도구가 아니라 capacity다"

Karo Zieminski의 정리에 나오는 한 줄이 강했습니다.

"Boris doesn't see AI as a tool you use, but as a capacity you schedule."

처음엔 "동시에 여러 세션을 돌린다"가 그냥 멀티태스킹 자랑처럼 보였는데, 이 표현으로 보면 다르게 읽힙니다. 그는 AI를 컴퓨팅 자원처럼 다룹니다 — 큐에 넣고, 워크로드를 분배하고, 컨텍스트 스위치는 결과가 나왔을 때만 합니다.

병목은 모델 생성 속도가 아니라 사람의 주의력 배분이라는 게 그의 입장입니다. 이 관점이 왜 그가 동시에 10~15개 세션을 돌리는가를 설명해줍니다 — 한 세션이 답변 만드는 동안 다른 세션의 결과를 처리하면, 사람은 항상 "다음 결정"만 내리면 되니까요.

Plan Mode — Boris도 "계획 우선"

(1)편에서 "바로 만들어줘 금지, /office-hours부터"라고 적었던 게 떠올라서 약간 놀란 부분이 있습니다. Boris의 워크플로우 핵심 원칙도 같았습니다.

그의 X 스레드와 후속 정리에 따르면, 그는 거의 모든 세션을 Plan Mode로 시작합니다. Plan Mode에서 Claude와 왔다갔다하며 계획을 다듬고, 충분히 좋아지면 그제야 auto-accept edits 모드로 전환해 실행시킵니다.

표현은 다르지만 같은 이야기입니다.

도구	"계획 우선" 메커니즘
gstack (1편)	/office-hours로 회의 → writing-plans로 계획서
Claude Code (Boris)	Plan Mode에서 계획 확정 → auto-accept edits로 실행

그가 강조하는 한 줄 — "never let Claude write code until you've reviewed and approved a written plan" — 은 (1)편의 운영 규칙(새 프로젝트는 무조건 회의부터)과 정확히 같은 원칙입니다.

인쇄술 비유 — 가장 와닿았던 한 대목

Boris가 코딩의 미래를 비유한 방식이 인상적이었습니다.

인쇄술 이전에 글을 읽고 쓸 수 있는 사람은 인구의 일부분이었다 — 필경사(scribes)였다. 인쇄술 이후 그게 보편화됐다.

같은 일이 코딩에 일어나고 있다는 게 그의 주장입니다. 코딩을 직업으로 가진 사람만 할 수 있는 일이었지만, 앞으로는 "컴퓨터로 일하는 사람"이라면 누구나 코딩으로 자기 문제를 해결할 거라는 거죠.

이 비유가 자극적이지만, 그가 든 본인 팀의 사례를 보면 단순한 슬로건이 아닙니다 — Claude Code 팀의 PM, EM, 디자이너, 데이터 사이언티스트, 파이낸스 리드, 유저 리서처까지 모두 코드를 친다고 합니다. 모든 직군이 자기 영역의 전문성은 유지하되, 코딩이 보편 기술처럼 깔리는 셈입니다.

"코딩이 solved 됐다"의 단서들

이 표현은 자극적이라 따로 정리해 둘 필요가 있습니다. 영상과 보도를 합쳐보면 단서는 분명합니다.

• 그가 짜는 종류의 코드에 한해서다. 그가 짜는 건 TypeScript + React 기반의 비교적 표준적인 웹 코드입니다.
• 남아있는 어려운 영역은 큰 복잡한 코드베이스, 그리고 모델이 충분히 학습하지 못한 비주류 언어.
• 그의 답은 "보통은 다음 모델을 기다리면 된다". 즉, 솔루션이 코드 짜는 능력이 아니라 모델 발전에 있다는 입장입니다.
• 이 입장은 그의 다른 원칙과도 맞물립니다 — "At Anthropic, we don't build for the model of today, we build for the model of six months from now." Claude Code가 초기 6개월간 거의 안 작동한 이유이자, 결국 Opus 4 출시와 함께 폭발적으로 작동하기 시작한 이유.

이 단서들 덕분에 "AI가 모든 코드를 다 짠다"는 메시지로 받아들이지 않을 수 있었습니다. 도메인 지식이 깊은 비즈니스 로직, 레거시 마이그레이션, 임베디드, 시스템 코드 같은 영역은 여전히 사람이 깊게 붙어있어야 합니다.

두 인사이트가 만나는 지점

(1)~(2)편을 거쳐 이 강연을 보면서 정리된 한 문장이 있습니다.

사용자 인터뷰와 프롬프트 설계는 같은 능력이다.

• (2)편에서 본 /office-hours의 효용 = "내가 만들 것을 앞단에서 정확하게 정의하는 일"
• Boris의 워크플로우 = "에이전트가 만들 것을 앞단에서 정확하게 정의하는 일"

둘 다 앞단의 정의가 결과의 90%를 결정한다고 말하고 있고, 그 정의를 잘하는 능력 — 모호한 것을 구체화하고, 우선순위를 정하고, 트레이드오프를 명시하는 — 이 진짜 핵심 기술이 된다는 결론에 도달합니다.

YC의 "Make something people want"도 같은 자리에 있습니다. *사람들이 진짜로 원하는 것을 정확하게 정의하고, 그것에 맞춰 만들어라. Boris가 YC에서 배웠다는 "first build for yourself"도 결국 같은 원칙의 다른 표현입니다 — 자기가 진짜 필요로 하는 것에서 시작하면 정의가 모호할 일이 적으니까요.

도구가 무엇이든(스타트업이든, 코드든, 에이전트든) 앞단의 정의가 흔들리면 뒷단의 모든 자원이 낭비됩니다. 이게 시리즈를 통해 잡힌 큰 그림이고, 다음 1년 동안 제 작업에서 가장 비중 있게 두려는 부분입니다.

한계와 남은 의문

• Boris가 보여준 워크플로우는 그가 만든 제품이고, 그가 가장 잘 쓰는 환경입니다. 외부 개발자가 그대로 따라 한다고 같은 생산성이 나오진 않을 것이라고 봅니다. 본인이 "이건 내가 짜는 종류의 코드에 한해서"라고 단서를 단 게 그 증거입니다.
• "loop 기반 워크플로우"의 가장 큰 위험은 검증 단계가 약하면 사고가 누적된다는 점입니다. 다행히 Boris도 이 부분을 인지하고 있어서, 본인의 13가지 팁 중 마지막을 "give Claude a way to verify its work"로 꼽았습니다 — 검증 루프가 있으면 결과 품질이 2~3배가 된다고 합니다. 다만 그가 쓰는 검증(Chrome 확장으로 UI 자동 테스트)은 그의 스택(TypeScript + React)이라서 가능한 부분이 큽니다. 다른 도메인에서는 어떻게 verify할 것인가가 별도의 설계 문제로 남습니다.
• "모든 사람이 코딩한다"는 비전은 매력적이지만, 읽는 것과 쓰는 것은 다릅니다. PM이 Claude Code로 프로토타입을 만드는 것과, 그 코드의 보안·성능·유지보수 책임을 지는 것은 다른 문제입니다. 인쇄술 비유가 깔끔하지만, 책임의 층은 그 비유에 안 들어가 있습니다.
• (2)편에서 언급한 것처럼 AI에게 인터뷰를 받는 게 진짜 사용자 인터뷰를 대체하지 않듯이, 잘 짜인 프롬프트가 사용자 검증을 대체하지 않습니다. 둘 다 본질적으로 "앞단의 정의를 더 좋게 하는 도구"일 뿐, 정의 자체가 옳다는 보장은 아닙니다.

핵심 정리

• Boris Cherny는 2025년 10월부터 손코딩을 안 한다. 하루 PR 수십 개~150개를 처리한다.
• 그의 작업 방식의 중심은 세션을 capacity로 스케줄링하는 것 — 터미널·브라우저·핸드폰을 가로지르는 10~15개 동시 세션. 병목은 모델이 아니라 주의력 배분이다.
• 핵심 메커니즘은 /loop (cron 스케줄)와 Routines (서버 측 영구 실행).
• Boris도 YC 출신. 거기서 배운 첫 원칙이 "first build for yourself" — (1)~(2)편의 Make something people want와 같은 자리.
• "코딩이 solved 됐다"는 단서가 분명하다 — 그가 짜는 종류의 코드에 한해서. Plan Mode와 verification 루프가 그의 워크플로우의 두 축이다.
• 시리즈 결론: 사용자 인터뷰와 프롬프트 설계는 같은 능력이다. 도구가 무엇이든 앞단에서 정확하게 정의하는 일이 결과의 90%를 결정한다.

참고 자료

• 원본 영상: Anthropic's Boris Cherny: Why Coding Is Solved, and What Comes Next (Sequoia Capital, 2026.05.04)
• 가장 자세한 보도(150 PR/일·Routines·product overhang 등): BigGo Finance 분석
• Boris 본인의 워크플로우 트윗 정리: howborisusesclaudecode.com
• Boris의 YC 경험 + 커리어: developing.dev — On How His Career Grew
• 더 깊은 인터뷰: Pragmatic Engineer — Building Claude Code with Boris Cherny
• 인쇄술 비유 관련 보도: Fortune (2026.02.24)
• Y Combinator 원칙: Make Something People Want
• 시리즈 (1)편: gstack + Superpowers 두 플러그인만 남긴 이유
• 시리즈 (2)편: gstack /office-hours로 AI에게 제품 인터뷰를 받아봤다

시리즈 마무리

세 글을 쓰면서 잡힌 큰 그림은 단순합니다. 앞단에서 정확하게 정의할수록, 뒷단의 도구가 더 많은 일을 알아서 한다.

(1)편에서 도구를 추렸고, (2)편에서 그 도구로 인터뷰를 받아봤고, (3)편에서 같은 원칙이 훨씬 큰 스케일에서 작동하는 사례를 봤습니다. 그리고 그 사례를 만든 사람도 결국 같은 학교(YC)의 같은 원칙(build for yourself)을 거쳐온 사람이었습니다.

다음 1년은 이 원칙을 내 작업에서 어떻게 더 잘 살릴 수 있는가에 집중해보려 합니다.

---