정리 메모

이 글은 아래 YouTube 강의를 소개하기 위해, 해당 영상을 GPT-5.6 Thinking이 분석·정리한 답변을 거의 그대로 공개 백업한 것이다. 영상의 공식 대본이나 화자의 승인된 요약문은 아니며, 세부 표현과 수치는 원 영상과 하단 참고 자료를 우선한다.

YouTube에서 원 영상 보기

이 영상 한 줄 요약

Claude Code 성공담을 빌려, AI 시대의 제품·조직·개발 방식이 “코드를 잘 짜는 사람”에서 “문제를 정의하고 여러 에이전트를 지휘·검증하는 사람” 중심으로 바뀌고 있다는 이야기다.

영상은 2026년 2월 공개된 약 50분짜리 YC 인터뷰로, Claude Code를 만든 Boris Cherny가 개발 과정, Anthropic의 내부 업무 방식, 채용 기준, 소프트웨어 엔지니어의 미래를 설명한다.

1. Claude Code는 거창한 제품 계획에서 출발하지 않았다

Boris는 처음부터 “AI 코딩 에이전트를 만들겠다”고 시작한 게 아니다. Anthropic API와 모델을 직접 사용해보기 위해 가장 싸고 간단한 터미널 채팅 프로그램을 만들었는데, 여기에 Bash와 파일 조작 기능을 붙이면서 자연스럽게 코딩 도구가 됐다.

시제품을 동료들에게 나눠준 지 며칠 만에, 시키지도 않았는데 직원들이 자발적으로 사용하기 시작했고 내부 사용량이 급격히 증가했다. 즉, 정교한 시장조사보다 dogfooding을 통해 제품-시장 적합성을 발견한 사례다.

핵심은 이거다.

완벽한 제품 비전을 세운 뒤 구현한 게 아니라, 아주 단순한 도구를 실제 업무에 넣고 사람들이 어떻게 사용하는지를 관찰하면서 제품을 발견했다.

2. “현재 모델”이 아니라 “6개월 후 모델”을 위해 만들어라

이 영상에서 가장 중요한 주장 중 하나다.

Anthropic은 현재 모델이 못하는 것을 온갖 복잡한 코드로 보완하기보다는, 6개월 뒤 모델이 자연스럽게 할 수 있을 일을 예상하고 제품을 설계한다고 한다.

왜냐하면 모델의 약점을 보완하려고 만든 프롬프트, 라우터, 상태 머신, 별도 메모리 시스템, 특수 도구 같은 것들은 다음 모델이 나오면 상당 부분 불필요해지기 때문이다. Boris는 이런 비모델 코드를 통칭해 scaffolding, 즉 임시 비계에 가깝게 본다.

Claude Code 코드베이스의 약 80%가 최근 몇 달 안에 작성됐으며, 6개월 전부터 그대로 남아 있는 부분이 거의 없다고 설명한다. 도구를 몇 주 단위로 추가했다가 모델이 좋아지면 다시 제거하기도 한다.

연구 관점에서 해석하면

이건 최근 말하는 하네스 엔지니어링에 대한 상당히 중요한 경고다.

하네스는 필요하지만, 하네스 자체를 영구적인 지능으로 착각하면 안 된다는 것이다.

현재는 하네스가 20%의 성능을 올릴 수 있어도, 모델이 한 세대 좋아지면 그 하네스가 오히려 성능과 유연성을 제한할 수 있다.

따라서 좋은 하네스는:

• 작고,
• 교체 가능하고,
• 모델과 느슨하게 결합되며,
• 실험으로 필요성이 계속 검증돼야 한다.

3. Anthropic이 존중하는 것은 ‘Bitter Lesson’이다

Claude Code 팀 공간에는 Rich Sutton의 The Bitter Lesson을 액자로 걸어뒀다고 한다.

핵심 철학은 특정 문제에 맞춰 인간이 정교하게 설계한 규칙보다, 계산량과 학습을 이용하는 일반적인 방법이 장기적으로 승리한다는 것이다. Claude Code 식으로 번역하면 다음과 같다.

“모델이 못한다고 가정하고 거대한 특수 시스템을 만들지 마라. 모델은 곧 그 일을 할 수 있게 된다.”

그래서 팀에서는 새로운 기능을 만들 때마다:

• 지금 코드를 추가해서 10~20% 개선할 것인가,
• 몇 달 뒤 모델이 자연스럽게 해결할 때까지 기다릴 것인가,

를 계속 비교한다고 한다.

다만 이걸 **“하네스가 필요 없다”**로 이해하면 틀린다. Boris도 실제로는 CLAUDE.md, Plan Mode, Agent SDK, 서브에이전트, 코드리뷰 에이전트 등을 적극적으로 쓴다.

정확한 메시지는:

하네스는 영구 아키텍처가 아니라, 현재 모델의 능력 경계를 임시로 연결하는 적응형 구조물이어야 한다.

4. 제품 아이디어는 ‘latent demand’에서 찾아라

Boris가 가장 강조하는 제품 개념은 latent demand, 즉 잠재수요다.

사람들에게 완전히 새로운 행동을 가르치려고 하기보다, 사람들이 이미 불편하게 하고 있는 행동을 찾아서 더 쉽게 만들어주라는 것이다.

Plan Mode

사용자들이 이미 Claude에게 반복적으로 다음과 비슷하게 말하고 있었다.

구현하지 말고 먼저 계획만 세워줘.

Boris는 이 행동을 발견하고 시스템 지시에 “아직 코드를 작성하지 말라”는 조건을 추가해 Plan Mode를 만들었다. 초창기 구현은 일요일 밤 짧은 시간 안에 만들어져 다음 날 배포됐다고 한다.

CLAUDE.md

사용자들은 프로젝트 규칙, 빌드 명령, 코딩 스타일을 매번 설명하기 귀찮아서 직접 Markdown 문서를 만들고 Claude에게 읽히고 있었다.

Anthropic은 이 행동을 공식 기능으로 만든 것이다. 즉, CLAUDE.md는 새로운 행동을 발명한 게 아니라 사람들이 이미 하던 우회 작업을 표준화한 것이다.

Cowork

디자이너, 재무팀, 데이터 과학자처럼 비개발자들이 Claude Code를 사용하기 위해 터미널 설치법까지 배워가며 애쓰는 현상이 나타났다. Anthropic은 이를 강한 잠재수요로 판단하고, Claude Code 에이전트를 GUI와 가상머신 기반 안전장치로 감싼 Cowork를 만들었다. 이 프로토타입은 약 10일 만에 대부분 Claude Code로 작성됐다고 한다.

5. Boris 본인은 의외로 CLAUDE.md를 거의 안 쓴다

Claude Code 제작자니까 거대한 CLAUDE.md와 복잡한 프롬프트를 쓸 것 같지만 정반대다.

개인 CLAUDE.md에는 PR 자동 병합과 내부 리뷰 채널 공유처럼 사실상 두 가지 정도만 넣어두고, 대부분의 규칙은 팀이 공유하는 프로젝트 CLAUDE.md에 둔다고 한다. 공유 파일도 수천 토큰 정도로 관리하며, 길어지면 압축하려 하지 않고 차라리 지우고 필요한 것부터 다시 추가한다.

운영 원칙은 이거다.

1. 처음부터 규칙을 많이 넣지 않는다.
2. 실제 실패가 발생했을 때만 규칙을 추가한다.
3. 새 모델이 나오면 기존 규칙이 여전히 필요한지 다시 본다.
4. 오래된 규칙과 과잉 제약은 삭제한다.

이건 연구실의 AGENTS.md, CLAUDE.md, coding policy에도 그대로 적용할 만하다.

규칙은 예방적 상상으로 추가하는 게 아니라, 관측된 failure mode에 대한 회귀 방지 장치로 추가하는 것이 좋다.

6. 실제 업무는 이미 멀티에이전트 시스템에 가깝다

Anthropic 내부에서는 Agent SDK를 이용해 다음 단계들을 자동화한다고 한다.

• 코드 리뷰
• 보안 리뷰
• 이슈 분류
• 구현
• 테스트
• 배포 진행 관리
• Slack을 통한 담당 엔지니어 문의

예를 들어 Claude가 코드를 보다가 특정 부분의 작성자를 git blame으로 찾아낸 다음, 해당 엔지니어에게 Slack으로 질문하고 답을 받아 작업을 계속하는 식이다.

플러그인 기능을 만들 때는 한 에이전트에게 명세와 Asana 보드를 주고, 에이전트가 티켓을 나누고 서브에이전트를 생성해 병렬로 작업하도록 했다고 한다. 난도가 높은 버그는 3개, 5개, 때로는 10개의 서브에이전트가 서로 다른 가설을 병렬 조사하도록 한다고 설명한다.

이건 생성팀–검증팀 하네스보다 한 단계 발전한 구조다.

중요한 것은 에이전트 수가 아니라, 에이전트가 독립적인 증거와 가설을 생성하도록 만드는 것이다. 같은 프롬프트를 열 번 실행하는 것은 진정한 병렬 검증이 아니라 correlated sampling일 수 있다.

7. Plan Mode는 중요하지만 결국 사라질 기능이라고 본다

Boris는 자신의 세션 약 80%를 Plan Mode로 시작한다고 한다.

여러 개의 터미널 탭에서 각각 계획을 세우게 하고, 계획이 충분히 좋아진 뒤 실행을 지시한다. 최신 모델에서는 계획이 제대로 잡히면 구현 과정이 크게 이탈하지 않는다고 평가한다.

그런데 동시에 Plan Mode의 수명은 제한적이라고 말한다.

미래 모델은 사용자의 요청을 보고 스스로:

• 바로 실행해야 하는지,
• 먼저 조사해야 하는지,
• 계획을 세워야 하는지,
• 사람에게 질문해야 하는지,

판단하게 될 것이므로, 인간이 별도 모드로 지정할 필요가 없어질 거라는 것이다.

즉 현재의 plan → execute 하네스도 모델의 metacognition이 부족해서 존재하는 임시 인터페이스라는 관점이다.

8. Claude Code가 쓰는 코드의 비율과 생산성

Boris는 IDE를 사실상 사용하지 않고 자신의 코드를 Claude Code로 작성한다고 말한다. 영상 당시 Anthropic 내부에서는 팀에 따라 코드의 약 70~90%가 AI로 작성되고, 일부 개인은 100%에 가깝다고 설명한다.

그는 하루 약 20개의 PR을 병합하며, PR 개수뿐 아니라 commit과 코드가 살아남는 기간 등을 함께 보면서 생산성을 측정한다고 한다. Claude Code 도입 이후 Anthropic의 엔지니어당 생산성이 150% 증가했다고 주장한다.

다만 이 숫자는 주의해서 봐야 한다.

• Anthropic 내부의 자체 측정치고,
• PR과 commit은 가치 창출의 완전한 지표가 아니며,
• AI 제품을 만드는 회사가 자사 AI를 쓰는 특수한 환경이고,
• 품질·장기 유지보수 비용은 아직 충분히 관측되지 않았다.

따라서 **“모든 조직에서 즉시 2.5배 생산성”**이라는 의미는 아니다. 오히려 “AI-native 조직은 기존 조직과 비교하기 어려울 정도로 개발 루프를 압축할 가능성이 있다”는 사례로 보는 게 맞다.

9. 앞으로 소프트웨어 엔지니어라는 직함이 약해질 수 있다

Boris는 코딩 자체가 점점 해결되면 software engineer라는 역할이 독립적으로 존재하기보다 builder, 즉 문제를 정의하고 제품을 만드는 일반적인 역할로 합쳐질 가능성이 있다고 본다.

Anthropic에서는 이미 PM, 디자이너, 엔지니어링 매니저, 재무 담당자까지 코드를 만들고 있다. 동시에 엔지니어는 코딩 이외에:

• 사용자 인터뷰
• 문제 정의
• 명세 작성
• 디자인
• 제품 판단
• 에이전트 관리
• 결과 검증

을 더 많이 수행하게 된다고 설명한다.

영상의 주장대로라면 미래에는 다음 구분이 약해진다.

반면 다음 두 부류의 가치는 커진다.

1. Extreme specialist
   런타임, 컴파일러, 메모리, 분산시스템, 보안, 수치해석처럼 모델도 쉽게 대체하기 어려운 깊은 전문가

2. Hyper-generalist
   연구·제품·디자인·비즈니스·코드를 횡단하며 전체 문제를 완성할 수 있는 사람

Claude Code 팀은 특히 후자를 선호한다고 한다.

10. 채용도 코드시험에서 ‘에이전트 사용 기록’으로 바뀔 수 있다

영상에서 흥미로운 아이디어는 지원자의 Claude Code transcript를 보는 채용 방식이다.

완성된 코드만 보면 결과만 알 수 있지만, 작업 기록을 보면 다음을 평가할 수 있다는 것이다.

• 문제를 어떻게 분해했는가
• 로그와 증거를 확인했는가
• 모델의 오류를 발견했는가
• 테스트를 요구했는가
• 계획을 반복 수정했는가
• 에이전트를 맹신했는가
• 시스템 전체를 이해하고 있는가

YC 측에서도 이런 transcript 기반 평가를 실험하고 있다고 언급된다.

Boris가 사람을 볼 때 중요하게 여기는 질문은 “네가 틀렸던 사례를 말해봐라”에 가깝다. 틀린 사실보다:

• 자신의 오류를 인정하는가,
• 사후적으로 원인을 설명할 수 있는가,
• 학습해서 행동을 바꾸는가,

를 본다는 것이다. 경력이 많아서 기존 방식에 강한 확신을 가진 사람보다, 초심자의 태도로 과학적 실험과 first-principles thinking을 할 수 있는 사람을 높게 평가한다.

이 영상의 진짜 메시지

표면적으로는 Claude Code 개발기지만, 실제 메시지는 세 가지라고 본다.

① 코드는 병목에서 멀어지고 있다

과거에는 아이디어를 코드로 변환하는 속도가 병목이었다.

이제 병목이 다음으로 이동한다.

즉 무엇을 만들지, 제대로 만들어졌는지 어떻게 검증할지가 더 중요해진다.

② 하네스의 핵심은 복잡성이 아니라 피드백 루프다

Anthropic의 강점은 “엄청 복잡한 멀티에이전트 프레임워크”라기보다:

라는 짧은 폐루프다.

이는 하네스 엔지니어링을 다음처럼 다시 정의하게 한다.

하네스 엔지니어링은 에이전트를 둘러싼 거대한 소프트웨어를 만드는 분야가 아니라, 실패를 관측하고 수정하며 검증하는 폐루프를 설계하는 분야다.

③ AI 시대에 가장 귀한 사람은 ‘판단 가능한 사람’이다

코드를 직접 많이 쓰는 능력보다:

• 중요한 문제를 찾고,
• 좋은 명세를 만들고,
• 에이전트의 결과를 평가하고,
• 틀렸을 때 원인을 진단하고,
• 여러 전문영역을 연결하는 능력

이 중요해진다는 주장이다.

내 평가

이 영상은 2026년 AI-native engineering의 최전선에서 실제로 무슨 일이 벌어지는지를 보여주는 좋은 인터뷰다. 특히 “현재 모델의 결함을 영구적인 아키텍처로 고정하지 마라”와 “사용자가 이미 하고 있는 행동에서 제품을 찾아라”는 부분은 연구와 제품개발 모두에 매우 강한 통찰이다.

다만 Boris의 주장은 Anthropic이라는 극단적으로 특수한 조직에서 나온 것이므로 그대로 일반화하면 위험하다.

특히 연구실에서는:

• 코드 생성 속도 증가가 논문의 과학적 기여 증가를 의미하지 않고,
• 에이전트 수 증가가 독립적 검증을 의미하지 않으며,
• PR 생산량이 연구 성과나 시스템 신뢰성과 동일하지 않고,
• 모델이 좋아져도 데이터·실험설계·안전·재현성은 자동 해결되지 않는다.

그래서 연구실에 적용한다면 **“100% AI-written research”보다 “100% traceable and verifiable research workflow”**를 목표로 잡는 게 맞다.

예를 들면:

결국 이 영상은 “코딩이 끝났다”는 선언보다는,

코딩 이후의 병목인 문제정의, 실험, 검증, 판단을 누가 얼마나 잘 시스템화하느냐가 다음 경쟁이라는 선언

으로 이해하는 게 가장 정확하다.

참고 자료

1. Y Combinator, “Inside Claude Code With Its Creator Boris Cherny”, 2026년 2월. 공식 소개 페이지
2. Chris Ellis, “How the Claude Code Team Works”, 2026년 3월 2일. 정리 글
3. Rich Sutton, “The Bitter Lesson”, 2019년. 원문