Claude Code는 도구가 아니라, 하나의 세계관이다——Cat Wu 인터뷰에서 뽑아낸 7가지 제품 철학

제품을 만드는 사람이라면 꼭 시간을 내서 Claude Code 제품 책임자 Cat Wu의 두 인터뷰를 보길 추천한다. 하나는 Lenny's Podcast의 단독 인터뷰, 다른 하나는 Boris Cherny와 함께한 Every.to 'AI & I' 인터뷰다. 두 개 합쳐 세 시간이 넘는데, 정보 밀도가 너무 높아 두 번이나 반복해서 들었다.

많은 사람들이 이 인터뷰들을 논할 때 Anthropic이 어떻게 6개월치 기능을 1주일, 심지어 하루 만에 출시하는지에 초점을 맞춘다. 속도 자체는 확실히 미친 수준이지만, 내가 느낀 가장 큰 감동은 속도에 있지 않다.

진짜로 나에게 영감을 준 건 Claude Code라는 제품에 숨겨진 일체의 세계관이다. 7가지로 나눌 수 있는데, 각각 하나씩 떼어놓고 보면 반직관적이면서도 합쳐 놓으면 AI 네이티브 제품이 가져야 할 모습 그 자체다. 하나씩 살펴보자.

1

Plan Mode는 기능이 아니라 세계관이다.

Boris Cherny가 프로그램에서 아주 무거운 말을 했다:

"plan mode로 전환해서 Claude가 먼저 해야 할 일을 단계별로 제시하게 하고, 코드를 치기 전에 계획을 먼저 맞춰라——복잡한 작업의 성공률이 두 배, 심지어 세 배로 뛴다."

두 배에서 세 배. 이 숫자를 처음 들었을 때 꽤 충격이었다.

조작 자체는 Shift+Tab을 두 번 누르는 것뿐이다. 프로그램에서도 언급됐듯이, Boris 자신도 어려운 기능을 만들 때는 먼저 plan mode로 전환해서 계획을 맞춘 후에야 코드를 쓰기 시작한다. 코드는 한 줄도 쓰지 않은 상태에서.

문제는, 왜 단순한 UI 옵션처럼 보이는 작은 스위치가 성공률을 이렇게 높이는가 하는 것이다.

그 이유는 그 뒤에 제품 수준의 전제가 숨겨져 있기 때문이다——모델이 환각(hallucination)을 일으킬 수 있음을 인정하므로, 의도를 먼저 테이블 위에 올려놓아야 한다. Plan Mode는 사용자가 보라고 있는 것이 아니다. 모델이 보라고 있는 것이다——먼저 생각하게 한 다음에 행동하게 만드는 것.

많은 사람들이 Plan Mode를 "사용자가 AI의 계획을 확인하게 하는 기능"이라고 생각하지만, 더 정확한 표현은 "AI가 생각 단계를 건너뛰는 것을 금지하는 기능"이다.

"생각을 명시화하는 것"을 제품 수준의 메커니즘으로 만든 것. 이것이 세계관이다.

2

모델 역량에 맞춰 비계(scaffold)를 제거하라, 기능을 쌓지 말고.

Cat Wu가 Lenny's에서 꽤 미묘한 개념을 언급했는데, 그것은 AGI-pilled——간단히 말해 "AGI에 얼마나 많이 베팅하는 정도"다. 그녀는 AGI-pilled의 정도를 잘 맞추는 것이 제품에서 가장 어려운 일 중 하나라고 말했다:

AGI-pilled에 너무 치우치면 현실과 동떨어진 제품 비전이 나오고, 너무 AGI-pilled하지 않으면 모델 역량을 낭비하게 된다. 새 모델이 나올 때마다 이 균형점을 다시 조정해야 한다.

그녀와 Boris의 철학은 "만드는 만큼 없애는 것"이다. 기능을 내리는 것(unship)은 실패했기 때문이 아니라, 더 간단하고 직관적인 구현 경로를 찾았기 때문이다.

가장 구체적인 예는 할 일 목록(todo list)이다. 초기 모델은 완료된 항목을 신뢰성 있게 체크하지 못해서, 팀은 몇 메시지마다 한 번씩 상기시키는 system reminder를 추가해야 했다. 새 모델이 나온 후에는 이런 "상기 비계"가 잉여물이 되어 그냥 제거했다.

Cat에게는 고정된 벤치마크 테스트도 있다——Claude Code가 Excalidraw에 테이블 기능을 추가하게 하는 것. 2025년 6월의 Opus 4는 가끔 성공했지만, 불과 1년 후인 2026년 4월의 Opus 4.6은 한 번에 성공해서 수천 명의 엔지니어 앞에서 라이브 데모를 할 수 있었다.

1년의 시간 동안 "가끔 성공"에서 "한 번에 성공"으로. 비계를 제거하는 리듬은 전적으로 모델 역량에 따라 움직인다.

다른 사람들은 기능을 쫓지만, 그들은 모델을 쫓는다——모델이 1cm라도 강해질 때마다 비계도 1cm씩 제거한다.

3

Swiss Cheese 다층 방어는 vibe coding이 아니다.

Anthropic 내부에서는 이 메커니즘을 Swiss Cheese Model이라고 부른다——여러 층을 겹쳐서, 각 층에 구멍이 있더라도 합치면 구멍이 없어지는 방식이다.

Claude Code 제품에 적용된 예로, Boris가 프로그램에서 PR 하나를 처리하는 구체적인 5단계를 설명했다:

Claude가 스스로 테스트를 돌리고, 테스트가 없으면 직접 작성하고, 자가 생성한 linter를 실행하고, 자동 리뷰어로써 한 번 더 확인하고, 마지막으로 사람이 검토한다.

여기서 주목할 점은, 5단계 중 앞의 4단계는 Claude Code가 스스로를 위해 구성한 것이라는 점이다. 모든 단계가 단독으로 오류 없이 작동할 것이라는 믿음이 없기 때문에, 사람이 검토하기 전에 스스로 4번 먼저 검증하는 것이다.

Boris의 관점에서 vibe coding——"느낌상 될 것 같다"는 식의 코드 작성법은 일회성 코드나 프로토타입에만 적합하고, 프로덕션 시스템에는 부적합하다. 이유는 간단하다——프로덕션 시스템의 반대말은 모델이 충분히 강하지 않기 때문이 아니라, 반례는 반드시 나타나기 때문이다.

이것이 Swiss Cheese 사상의 가장 날카로운 지점이다: 진정한 산업급 AI 제품은 모델이 실수하지 않을 것이라고 도박하는 것이 아니라, 모델이 반드시 실수할 것이라고 가정하고, 구조로 그 실수를 받아내는 것이다.

4

Antfooding——5분마다 하나의 피드백.

Anthropic 엔지니어들 사이에는 ants(개미)라는 별명이 있다. 그래서 그들은 내부 사용 사이클을 Antfooding이라고 부른다——dogfooding의 진화형이다.

Cat이 프로그램에서 꽤 무모해 보이는 말을 했다:

"우리의 피드백 채널에서 5분마다 새 메시지가 뜬다."

5분마다 하나. 누군가 이 기능을 정말 좋아하는지, 버그가 있는지, unship을 해야 하는지——5분마다 신호 하나를 받을 수 있다.

사무실에 있는 수백 명의 엔지니어가 매일 Claude Code를 사용하고 있고, Cat이 한 바퀴 돌면 바로 현장 피드백을 볼 수 있다. 이 그림이 꽤 중요한데——Claude Code의 첫 번째 사용자는 세상에서 가장 까다롭고, 코드를 가장 잘 쓰고, 불평을 가장 잘하는 사람들이라는 것.

출시 → 내부 dogfooding → 몇 분마다 피드백 청취 → 반복 → 재출시. 이 사이클이 얼마나 짧은가? 예전에는 기능 하나가 기획에서 출시까지 6개월이 걸렸지만(기획 + 팀 간 조율 + PRD 작성), 지금 Anthropic 내부의 전체 리듬은 24시간 안에 ship하는 수준으로 줄었다——이것은 팀 전체의 반복 주기라는 점에 주목. 같은 기능이 6개월에서 24시간으로 줄었다는 뜻은 아니다.

세상에서 Claude Code에 막힌 엔지니어보다 더 까다로운 사용자는 없다. 일반 제품의 dogfooding은 "우리도 사용한다"는 수준이지만, Antfooding은 "우리가 누구보다 더 세게 사용한다"는 수준이다.

5

Subagent가 서로 흠집을 내게 하라, 한 방에 결정하지 말고.

이 부분이 아마 전체 인터뷰에서 내 인식을 가장 뒤흔든 대목일 것이다.

Boris가 자신의 코드 리뷰 명령을 설명한 방식은 이렇다:

한 번에 여러 subagent를 병렬로 실행한다——하나는 스타일 가이드라인을 검사하고, 하나는 git history를 뒤져 예전에 어떻게 구현했는지 확인하고, 하나는 명백한 버그를 찾는다. 첫 번째 라운드에서는 실제 문제와 가짜 알람이 동시에 나온다. 그래서 다시 5개의 subagent를 실행해서, 앞에서 나온 발견들에 대해 특별히 흠을 잡게 한다. 결과는 실제 문제는 모두 찾아내고, 가짜 양성은 모두 제거하는 것이다.

이 글을 읽고 잠시 멈칫했다. 나 자신이 평소 Agent 제품을 만들 때의 본능적인 반응은 항상 "더 강한 모델로 교체하자"였다——품질 문제가 생기면 첫 번째 직감은 "모델이 충분하지 않다"는 것이었다. 한 번도 N개의 Agent가 서로 흠을 잡게 하는 방법을 생각해본 적이 없었다——품질은 모델의 강도가 아니라, 모델 간의 대립(adversarial)에 달려 있다.

대부분의 사람들이 Agent 제품을 만들 때 생각하는 방식은 "가장 강한 모델 하나로 모든 것을 해결하자"는 것이다. Claude Code는 그 반대다——여러 모델이 서로 싸우게 한다. 첫 번째 subagent가 리뷰하고, 두 번째 subagent가 첫 번째 subagent의 리뷰에 대해 특별히 흠을 잡는다.

Cat도 비슷한 설정을 사용한다——planner subagent 하나, code review subagent 하나. 동기식 상호작용에서는 subagent를 사용하고, CI에서는 slash command를 사용하지만, 하는 일은 같다.

대가도 확실하다. subagent-heavy 워크플로우의 토큰 소비는 단일 agent보다 25배 많다. 업계 공개 데이터와 비교하면, 기업 배포 시 평균적으로 개발자 한 명당 월 150250달러 수준이지만, Anthropic 내부에서는 단일 사용자가 한 달에 token 비용으로 15만 달러를 태운 극단적인 사례도 있었다——개별 사례이기는 하지만, 이 방법의 상한이 얼마나 무서운지를 충분히 보여준다.

하지만 Boris의 관점은 단호하다: subagent가 서로 흠을 잡게 하면, 결과가 오히려 더 깨끗해진다. 대립이야말로 품질의 원천이다.

AI가 한 번에 맞는 답을 낸다고 믿는 대신, AI 서로에게서 반박을 받도록 하라.

6

Stop Hook이 '완료'의 정의를 다시 쓴다.

앞 절은 단일 지점 판단을 신뢰하지 않는 것에 관한 이야기였다. 이 절은 한 걸음 더 나아간다——"모델이 스스로 다 끝났다고 말하는 것" 자체도 믿어서는 안 된다는 것이다.

Boris가 제시한 해결책은 Stop Hook이다:

"모델이 실제로 일이 완료될 때까지 계속 실행하게 할 수 있다."

구체적인 방법은 stop hook에 테스트 스위트를 걸어 놓는 것이다——테스트가 실패하면 오류를 Claude에게 돌려보내서 수정하게 하고, 다시 실행하고, 모든 테스트가 통과할 때까지 반복한다. "내가 다 했어"는 완료가 아니다. "테스트가 통과했다"가 완료다.

Boris가 프로그램에서 특히 강조한 점은, Claude에게 스스로 검증할 수 있는 루프를 제공하는 것이 Claude Code에서 좋은 결과를 얻는 데 있어 가장 중요한 일이며, 이 루프가 있으면 최종 품질이 2~3배 향상된다는 것이다.

그는 또한 PostToolUse hook을 실행해서 코드를 자동으로 포맷팅한다——Claude는 보통 포맷에 문제가 없지만, 이 hook이 마지막 10%를 수정해서 CI가 망가지지 않게 한다.

이 두 층위를 겹쳐서 보면, Stop Hook이 하는 일은 매우 근본적인 작업이다——'완료'라는 단어 자체를 재정의하는 것. AI 시대에는 결과만이 유일한 정직이다. 모델이 스스로 "완료했다"고 말하는 것은 유효하지 않으며, 실행을 통해 통과한 것만이 '완료'다.

7

typing에서 deciding으로——가장 희소한 것은 판단력이다.

마지막 절에서 Cat이 Lenny's에서 한 가지 말을 했는데, 나는 그것을 여러 번 친구들에게 캡처해서 보여줬다:

"코드는 점점 더 싸지고 있다. 더 가치 있는 일은 '무엇을 써야 할지 판단하는 것'이 되었고——또한 어떤 일이 얼마나 어려운지를 이해하는 것이 우선순위 판단에 도움이 된다."

그녀는 더 나아가, 모든 역할이 융합되고 있다고 말했다——PM이 엔지니어링 일을 하고, 엔지니어가 PM 일을 하고, 디자이너가 PM 일을 하고 있다. 그녀의 팀에 있는 거의 모든 PM은 엔지니어였거나 스스로 PR을 제출하며, 디자이너도 모두 프런트엔드 엔지니어 출신이다.

Boris의 시각은 더 날카롭다. 그의 관점에서 소프트웨어 엔지니어는 필경사(참경사종이(copyist) 비유)와 같고, AI는 인쇄술과 같다——코드는 더 이상 희소재가 아니다.

앞의 6가지를 이 절에 놓고 되돌아보면, 결국 같은 이야기다——

Plan Mode는 판단을 명시화하게 하는 것이고, 비계 제거는 모델 역량에 맞춰 판단을 조정하는 것이고, Swiss Cheese는 '모델이 실수할까요?'를 판단하지 않아도 되게 하는 것이다. Antfooding은 판단이 최대한 빨리 실제 피드백을 접하게 하는 것이고, Subagent 흠잡기는 모델의 판단을 대신 검증하는 것이며, Stop Hook은 '완료'의 진위 여부를 대신 판단하는 것이다.

모든 제품 철학이 단 한 가지 일을 위해 봉사한다——사람을 typing에서 해방시켜 deciding에 집중하게 하는 것.

Claude Code는 엔지니어를 대체하려는 것이 아니라, 엔지니어를 타이피스트 자리에서 일으켜 세우는 것이다.

---

7가지 이념을 연결하면, 바로 Claude Code 제품의 세계관이다——

AI가 신뢰할 수 없다는 점을 인정하기에 다층 방어를 세우고, 단일 지점 판단을 신뢰하지 않기에 서로 흠을 잡게 하고, 모델이 스스로 주장하는 '완료'는 신경 쓰지 않고 실행을 통과한 결과만을 중시하며, 사람을 타이피스트 위치에서 해방시켜 판단에 집중하게 한다.

보고 나서 가장 큰 감동은 놀라움이 아니라, **'스스로 변화를 구하라(主動求變)'**는 이 네 글자다.

우리가 사용하는 제품은 이미 이 세계관에 따라 돌아가고 있다——그것은 오류를 가정하고, 대립을 조직하며, 완료를 재정의하고, 사람을 판단 자리로 밀어낸다. 그렇다면 우리가 제품을 만들고, 팀을 이끌고, 자기 손에 있는 일을 하는 방식도 따라잡아야 하지 않을까? 팀의 협업도 변해야 하고, 도구도 변해야 하고, 업무 습관도 변해야 하고, 심지어 '무엇이 일을 완료한 것인가'라는 정의도 다시 적어야 한다.

스스로 변화를 구하지 않으면, 이 세계관에 의해 끌려갈 수밖에 없다.

당신도 이 두 인터뷰를 직접 들어보길 추천한다. 내가 길게 설명하는 것보다 훨씬 유용할 테니까.

Claude Code를 사용하면서 당신의 인식을 가장 뒤흔든 디자인은 무엇인가? 댓글에서 이야기해 보자.