내부자의 증언: Claude Code 팀이 말하는 AI 코딩의 현실

게시 2026/01/29

By BLUEBUG

73 분읽는 시간

As always, a very thoughtful and well reasoned take. I read till the end.

서론: 제품을 만드는 사람들이 말하다

Andrej Karpathy의 AI 코딩 경험담이 외부 사용자의 관찰이었다면, Boris Cherny의 답변은 그 도구를 만드는 사람들의 내부 증언입니다. Cherny는 Claude Code 팀의 핵심 멤버로, 그가 공유한 내용은 단순한 의견이 아니라 실제 제품 개발 현장에서의 생생한 데이터입니다.

그의 트윗은 짧지만 밀도가 높습니다. “Claude Code 팀 자체가 앞으로의 방향을 보여주는 지표일 수 있습니다”라는 도입부는 자신감과 겸손함을 동시에 보여줍니다. 그들은 단순히 AI 코딩 도구를 만드는 것이 아니라, 그 도구로 자신들의 제품을 개발하는 “dogfooding”을 실천하고 있습니다.

이것은 매우 중요한 신호입니다. 많은 소프트웨어 회사들이 자신들이 만든 도구를 실제로는 사용하지 않거나, 마케팅용으로만 사용한다고 주장하는 것과 달리, Anthropic의 Claude Code 팀은 진짜로 자신들의 도구에 의존하고 있습니다. 그들의 성공과 실패는 곧 제품의 성공과 실패로 직결됩니다.

1. 제너럴리스트 중심 채용: 과거 경험의 가치 재평가

“우리는 주로 제너럴리스트를 채용합니다”

Cherny의 첫 번째 포인트는 Karpathy의 질문 “LLM으로 무장한 제너럴리스트가 스페셜리스트를 능가하는가?”에 대한 직접적인 답변입니다. 그의 답은 명확합니다: 예, 그리고 그것은 이미 Claude Code 팀의 채용 전략에 반영되어 있습니다.

하지만 이것은 단순한 “제너럴리스트 우위론”이 아닙니다. Cherny는 중요한 뉘앙스를 덧붙입니다: “시니어 엔지니어와 덜 시니어한 엔지니어를 혼합해서 채용합니다. 사람들이 과거에 배운 모든 것이 LLM과의 코딩으로 전환되는 것은 아니기 때문입니다.”

이것은 매우 세심한 관찰입니다. AI 시대에는 두 가지 상반된 현상이 동시에 일어납니다:

경험의 평준화: 과거에는 10년 경력 시니어와 2년 경력 주니어 사이에 엄청난 격차가 있었습니다. 시니어는 수많은 프레임워크, 디자인 패턴, 베스트 프랙티스를 머릿속에 가지고 있었고, 이것이 생산성 차이를 만들었습니다. 하지만 AI가 이런 지식을 즉시 제공하면, 주니어도 시니어가 알고 있는 패턴을 활용할 수 있습니다.

메타인지의 가치 상승: 반면, “무엇을 모르는지 아는 것”, “언제 간단한 솔루션을 선택하고 언제 복잡한 설계가 필요한지 판단하는 것”, “시스템의 장기적 건강을 생각하는 것” 같은 고차원적 스킬은 여전히 경험에서 나옵니다. 그리고 이런 스킬은 AI가 쉽게 대체할 수 없습니다.

따라서 “시니어와 주니어 혼합”은 매우 전략적입니다. 시니어는 방향을 잡고, 아키텍처를 설계하고, 복잡한 트레이드오프를 판단합니다. 주니어는 AI를 활용해 빠르게 구현하고, 새로운 도구에 대한 적응력이 높고, 선입견 없이 “AI 네이티브” 방식으로 일합니다.

“과거에 배운 모든 것이 전환되는 것은 아니다”

이 문장은 깊은 통찰을 담고 있습니다. 20년 경력의 C++ 전문가가 AI 시대에 20년 경력의 가치를 모두 유지하는 것은 아닙니다. 그의 경험 중 일부는 여전히 귀중하지만(시스템 설계, 성능 최적화 철학, 디버깅 전략), 다른 일부는 AI가 더 잘할 수 있습니다(문법 세부사항, 라이브러리 API 사용법, 보일러플레이트 코드 작성).

이것은 베테랑 개발자들에게 도전이자 기회입니다. 도전은 자신의 경험 중 무엇이 여전히 가치 있고 무엇이 AI에게 넘겨야 할지 구분해야 한다는 것입니다. 기회는 AI를 활용해 자신이 항상 하고 싶었지만 시간이 없어서 못 했던 것(새로운 언어 배우기, 다른 도메인 탐험하기)을 할 수 있다는 것입니다.

Claude Code 팀이 “주로 제너럴리스트를 채용”한다는 것은, 그들이 특정 기술 스택의 깊은 전문성보다 빠른 학습 능력, 넓은 시야, 문제 해결 능력을 더 중시한다는 의미입니다. AI가 구체적인 구현 지식을 제공하므로, 인간에게는 “무엇을 만들 것인가”를 결정하는 능력이 더 중요해집니다.

Jared Sumner 사례: 횡단적 역량의 구현

Cherny는 Jared Sumner를 “product and infra를 아우르는” 10X 엔지니어의 예로 듭니다. Sumner는 Bun의 창시자로, JavaScript 런타임부터 패키지 매니저, 번들러까지 전체 스택을 혼자 개발한 것으로 유명합니다. 최근 Bun이 Anthropic에 합류하면서 그도 팀에 합류했습니다.

이것은 AI 시대 10X 엔지니어의 새로운 정의를 보여줍니다. 과거의 10X 엔지니어는 특정 영역(예: 백엔드 성능 최적화)에서 극도로 깊은 전문성을 가진 사람이었습니다. 하지만 AI 시대의 10X 엔지니어는 여러 영역을 넘나들며, 제품과 인프라를, 사용자 경험과 시스템 아키텍처를 동시에 이해하고 구현할 수 있는 사람입니다.

AI가 각 영역의 구체적 구현을 도와주므로, 한 사람이 과거보다 훨씬 넓은 범위를 커버할 수 있습니다. Sumner 같은 사람이 AI 없이 Bun을 만들었다는 것 자체가 놀라운 일이지만, AI와 함께라면 그런 횡단적 프로젝트가 더 흔해질 수 있습니다.

“Yes, he’s blushing”이라는 농담 섞인 덧붙임은 팀의 문화를 엿보게 합니다. 서로의 역량을 인정하고 칭찬하면서도, 과도하게 진지하지 않고 유머를 유지하는 분위기입니다. 이런 문화가 빠르게 변하는 AI 도구 개발에 필수적일 것입니다.

2. 100% AI 코딩: 이론이 아닌 현실

“나는 개인적으로 2개월 이상 100%였습니다”

Cherny의 가장 충격적인 고백은 이것입니다: “나는 손으로 작은 편집조차 하지 않습니다. 어제 22개 PR을 배포했고, 그 전날은 27개였으며, 각각 100% Claude가 작성했습니다.”

이것을 소화하는 데 잠깐 시간이 필요합니다. Anthropic의 핵심 제품 개발자가, Claude Code를 만드는 그 사람이, 문자 그대로 단 한 줄의 코드도 직접 타이핑하지 않고 있다는 것입니다. 모든 것이 Claude와의 대화를 통해 이루어집니다.

하루 22-27개 PR의 의미

전통적인 개발 방식에서 하루에 22개의 PR을 배포한다는 것은 거의 불가능합니다. 각 PR이 의미 있는 변경을 담고 있다고 가정하면, 코드 작성, 테스트, 리뷰, 수정, 병합까지 하루에 한두 개 완료하는 것도 빠른 편입니다.

하지만 Cherny는 평균 25개 정도를 배포합니다. 이것은 두 가지를 의미할 수 있습니다:

PR의 크기 변화: 각 PR이 과거보다 작고 집중적일 수 있습니다. 하나의 큰 기능을 여러 개의 작은 PR로 나누는 것이 AI와의 협업에서 더 효과적일 수 있습니다. 이것은 실제로 좋은 관행입니다 - 작은 PR은 리뷰하기 쉽고, 롤백하기 쉽고, 버그를 격리하기 쉽습니다.
병렬 작업: AI가 여러 작업을 동시에 처리하면, 개발자는 여러 브랜치에서 동시에 일할 수 있습니다. 한 작업이 AI에 의해 진행되는 동안, 개발자는 다른 작업의 요구사항을 정리하거나, 또 다른 PR을 리뷰할 수 있습니다.

다양한 인터페이스 활용

“일부는 CLI에서, 일부는 iOS 앱에서 작성했습니다”라는 언급이 흥미롭습니다. Cherny는 같은 작업이라도 컨텍스트에 따라 다른 인터페이스를 선택합니다.

CLI: 복잡한 리팩터링, 여러 파일에 걸친 변경, 터미널과의 긴밀한 통합이 필요한 작업
iOS 앱: 이동 중 간단한 버그 수정, 코드 리뷰, 아이디어를 빠르게 프로토타입으로 만들기
Desktop 앱: 집중적인 기능 개발, 큰 아키텍처 변경, 여러 도구 간 전환이 필요한 작업
Slack: 팀원의 요청에 즉시 응답, 간단한 유틸리티 작성, 빠른 실험

이것은 AI 코딩 도구가 “하나의 인터페이스”가 아니라 “여러 맥락에 적응하는 플랫폼”으로 진화하고 있음을 보여줍니다. 마치 스마트폰, 태블릿, 노트북에서 모두 작동하는 클라우드 서비스처럼, Claude Code는 개발자가 어디에 있든, 무엇을 하든 접근 가능합니다.

“산업 전체가 몇 달 내 비슷한 통계를 보게 될 것”

Cherny의 예측은 대담합니다. 그는 자신의 경험이 outlier가 아니라 선행 지표라고 생각합니다. “일부는 다른 것보다 시간이 더 걸리겠지만”이라는 조심스러운 단서를 달면서도, 전체적인 방향은 확실하다고 봅니다.

이것은 곧 소프트웨어 개발 조직에 큰 파장을 일으킬 것입니다:

생산성 측정의 재정의: 현재 많은 회사들이 “커밋 수”, “코드 라인 수”, “배포 빈도” 같은 지표로 생산성을 측정합니다. 하지만 AI가 코드를 작성하면, 이런 지표는 의미를 잃습니다. 대신 “해결한 문제의 가치”, “사용자 영향”, “비즈니스 성과” 같은 더 고차원적 지표가 필요해집니다.

코드 리뷰 프로세스의 변화: 하루에 25개 PR을 리뷰한다는 것은 전통적 방식으로는 불가능합니다. 따라서 리뷰 프로세스도 변해야 합니다. Cherny가 나중에 언급하듯, AI를 이용한 자동 코드 리뷰가 1차 필터 역할을 하고, 인간은 더 전략적이고 맥락적인 검토에 집중하게 될 것입니다.

팀 구조의 재편: 과거에는 프론트엔드 팀, 백엔드 팀, 인프라 팀이 분리되어 있었습니다. 하지만 제너럴리스트가 AI의 도움으로 전체 스택을 다룰 수 있다면, 팀 구조도 기능별이 아니라 제품별, 문제별로 재편될 수 있습니다.

“비-코딩 컴퓨터 작업에서도 비슷한 통계”

Cherny는 더 나아갑니다. 코딩뿐 아니라 “모든 컴퓨터 작업”에서 비슷한 패턴을 보게 될 것이라고 예측합니다. 이것은 무엇을 의미할까요?

데이터 분석: 애널리스트가 AI에게 “지난 분기 사용자 이탈률을 코호트별로 분석하고, 주요 패턴을 시각화하고, 개선 제안을 만들어줘”라고 하면, AI가 SQL 쿼리를 작성하고, Python으로 분석하고, 차트를 만들고, 보고서를 생성합니다.

디자인: 디자이너가 “이 피그마 디자인을 반응형 HTML/CSS로 구현해줘, Tailwind 사용하고, 접근성 고려해줘”라고 하면, AI가 픽셀 퍼펙트한 코드를 생성합니다.

DevOps: 엔지니어가 “쿠버네티스 클러스터를 AWS에 배포하고, CI/CD 파이프라인 설정하고, 모니터링 대시보드 만들어줘”라고 하면, AI가 Terraform 설정, GitHub Actions 워크플로우, Grafana 대시보드를 생성합니다.

이 모든 작업에서 인간은 “무엇을” 원하는지 정의하고, AI는 “어떻게” 구현할지 처리합니다. 이것이 Cherny가 예견하는 미래입니다.

3. 코드 품질 문제: 인정과 낙관의 균형

“당신이 나열한 문제들은 현실입니다”

Cherny는 Karpathy가 지적한 문제들을 부정하지 않습니다. “모델이 과도하게 복잡하게 만들고, 사용하지 않는 코드를 남기고, 리팩터링을 해야 할 때 하지 않는다” - 이것은 모두 사실입니다.

이 솔직함이 중요합니다. 제품을 만드는 회사가 제품의 한계를 인정하는 것은 쉽지 않습니다. 특히 경쟁이 치열한 AI 시장에서, “우리 제품도 문제가 있어요”라고 공개적으로 말하는 것은 용기가 필요합니다.

하지만 Cherny는 이것을 약점이 아니라 개선의 여지로 제시합니다. “이것들은 모델이 개선되면서 계속 나아질 것입니다”라는 말에는 두 가지 전제가 깔려 있습니다:

모델 개선은 지속적이다: Anthropic는 Claude를 계속 발전시키고 있으며, 각 버전마다 코드 생성 품질이 개선되고 있습니다. Opus 4.5가 4.0보다 낫고, 5.0은 4.5보다 더 나을 것입니다.
피드백 루프가 작동한다: Claude Code 팀이 자신들의 도구를 사용하면서 발견하는 모든 문제는 직접 모델 학습과 제품 개선에 피드백됩니다. 그들은 단순히 사용자가 아니라 제품 개선의 최전선에 있습니다.

“코드 품질 기준이 더 높아질 것”

역설적이게도 Cherny는 AI가 코드 품질을 낮추는 것이 아니라 높일 것이라고 주장합니다. “우리의 코드 품질 기준은 결과적으로 더욱 올라갈 것입니다.”

이것은 어떻게 가능할까요? 과거에는 코드 품질과 개발 속도가 트레이드오프 관계였습니다. 완벽한 코드를 작성하려면 시간이 오래 걸리고, 빠르게 배포하려면 품질을 양보해야 했습니다.

하지만 AI가 구현 속도를 극적으로 높이면, 이 트레이드오프가 사라집니다. “완벽하게 작성하는 데도 10분이면 충분하니, 굳이 서두를 이유가 없다”가 됩니다. 따라서 개발자는 더 높은 품질 기준을 설정할 수 있습니다:

“이 함수는 단위 테스트가 90% 커버리지를 달성해야 한다” → AI가 테스트 자동 생성
“이 API는 OpenAPI 스펙을 완벽히 준수해야 한다” → AI가 스펙 검증 및 수정
“이 컴포넌트는 WCAG 2.1 AA 접근성 기준을 만족해야 한다” → AI가 접근성 검사 및 개선
“이 모듈은 순환 의존성이 없어야 한다” → AI가 의존성 분석 및 리팩터링

과거에는 시간과 예산 제약으로 “이상적으로는 이렇게 해야 하지만 현실적으로는…“하고 타협했던 것들을, 이제는 실제로 달성할 수 있습니다.

Slopacolypse 반론: “모델이 더 나아질 것”

Karpathy의 “Slopacolypse” 경고에 대해 Cherny는 낙관적입니다. “모델이 덜 엉성한 코드를 작성하고 기존 코드 문제를 수정하는 데 더 나아질 것이기 때문에 Slopacolypse는 없을 것입니다.”

이것은 흥미로운 대립되는 시각입니다:

Karpathy의 우려: AI가 저품질 코드를 대량 생산하면, GitHub는 비슷비슷한 프로젝트로 범람하고, 진짜 혁신을 찾기 어려워질 것입니다.

Cherny의 낙관: AI가 발전하면서 1) 애초에 고품질 코드를 생성하고, 2) 기존의 저품질 코드를 개선하는 능력이 커질 것입니다. 따라서 slop이 생기는 속도보다 제거되는 속도가 더 빠를 것입니다.

누가 옳을까요? 아마도 둘 다 부분적으로 옳을 것입니다. 단기적으로는 Karpathy의 우려대로 저품질 콘텐츠가 급증할 수 있습니다. 하지만 중장기적으로는 Cherny의 낙관대로 AI의 품질 개선과 자가 수정 능력이 이 문제를 완화할 수 있습니다.

여기서 핵심은 “모델 개선 속도”입니다. 만약 모델이 6개월마다 크게 개선된다면, slop 문제는 일시적일 것입니다. 하지만 만약 개선이 정체된다면, slop이 누적되어 심각한 문제가 될 수 있습니다.

Cherny는 “4.5가 이미 이런 면에서 꽤 좋고 계속 나아질 것”이라고 자신합니다. 이것은 단순한 희망이 아니라, 내부 로드맵과 벤치마크 데이터를 기반으로 한 판단일 것입니다.

4. 자동화된 코드 리뷰: 신선한 컨텍스트의 힘

“claude -p로 모든 PR을 리뷰합니다”

Cherny가 공유한 가장 실용적인 팁은 이것입니다: “그 사이에 도움이 되는 것은 모델이 신선한 컨텍스트 윈도우를 사용해 자신의 코드를 리뷰하게 하는 것입니다. Anthropic에서는 모든 PR에 대해 claude -p를 사용하며, 많은 문제를 잡아내고 수정합니다.”

claude -p의 의미

이것은 아마도 “claude with plan mode” 또는 특정 코드 리뷰 프롬프트를 의미할 것입니다. 핵심은 “신선한 컨텍스트 윈도우”입니다.

AI가 코드를 작성할 때는 특정 맥락과 가정을 가지고 있습니다. 하지만 같은 AI라도 코드를 리뷰할 때는 새로운 컨텍스트로 접근하면, 마치 다른 사람이 보는 것처럼 객관적으로 평가할 수 있습니다.

이것은 인간의 “고무 오리 디버깅(rubber duck debugging)”과 비슷합니다. 문제를 다른 사람(혹은 고무 오리)에게 설명하다 보면 스스로 해결책을 찾게 되는 현상입니다. AI도 “작성 모드”와 “리뷰 모드”를 분리하면, 자신이 만든 코드의 문제를 더 잘 발견합니다.

자동 리뷰가 잡아내는 것들

Cherny는 “많은 문제를 잡아내고 수정합니다”라고 말합니다. 구체적으로 어떤 문제일까요?

일관성 문제: 코드 A에서는 null 체크를 했는데 코드 B에서는 안 했거나, 한 곳에서는 async/await을 쓰고 다른 곳에서는 콜백을 쓰는 등의 불일치
엣지 케이스: 빈 배열, null 값, 음수 입력 같은 경계 조건을 처리하지 않은 경우
보안 취약점: SQL 인젝션, XSS, 하드코딩된 비밀번호 같은 명백한 보안 문제
성능 문제: O(n²) 알고리즘을 O(n log n)으로 개선할 수 있거나, 불필요한 데이터베이스 쿼리를 제거할 수 있는 경우
테스트 부족: 중요한 로직인데 테스트가 없거나, 테스트가 있어도 커버리지가 낮은 경우
문서화 부족: 복잡한 함수인데 주석이나 타입 힌트가 없는 경우

이런 것들을 자동으로 잡아내면, 인간 리뷰어는 더 중요한 것에 집중할 수 있습니다:

비즈니스 로직이 요구사항을 정확히 반영하는가?
아키텍처 선택이 장기적으로 유지보수 가능한가?
이 변경이 시스템의 다른 부분에 의도하지 않은 영향을 미치지 않는가?
사용자 경험이 개선되는가?

두 단계 리뷰 프로세스

Anthropic의 워크플로우는 아마도 이렇게 작동할 것입니다:

1단계 - AI 리뷰:

개발자가 PR을 생성하면 자동으로 claude -p 실행
AI가 코드를 스캔하고 문제 발견
발견된 문제를 자동으로 수정하거나, 수정 제안을 코멘트로 추가
개발자가 제안을 검토하고 승인하면 자동 커밋

2단계 - 인간 리뷰:

기술적 문제는 대부분 1단계에서 해결되었으므로, 인간은 전략적 검토에 집중
“이게 정말 우리가 원하는 방향인가?”
“더 나은 대안은 없는가?”
“이것이 제품 비전과 일치하는가?”

이런 프로세스는 품질은 유지하면서도 속도를 크게 높입니다. Cherny가 하루에 25개 PR을 배포할 수 있는 것은 각 PR이 이미 자동 리뷰를 통과했기 때문일 것입니다.

메타적 재귀: AI가 AI 코드를 리뷰

흥미로운 점은 AI가 생성한 코드를 AI가 리뷰한다는 메타적 재귀입니다. 이것은 마치 작가가 쓴 글을 편집자가 검토하는 것과 같습니다. 같은 사람이 쓰고 편집할 수도 있지만, 시간을 두고 다른 마인드셋으로 접근하면 더 객관적으로 볼 수 있습니다.

AI의 경우, “신선한 컨텍스트 윈도우”가 이런 시간적 거리를 제공합니다. 코드를 작성할 때의 컨텍스트와 리뷰할 때의 컨텍스트가 다르므로, 다른 “AI 페르소나”가 평가하는 것과 비슷한 효과가 납니다.

더 나아가, 이것은 AI의 자가 개선(self-improvement)으로 발전할 수 있습니다. AI가 자신이 만든 코드의 문제를 반복적으로 발견하고 수정하면서, 어떤 패턴이 문제를 일으키는지 학습하고, 다음번에는 처음부터 그 패턴을 피할 수 있습니다.

물론 이것은 완벽하지 않습니다. AI는 여전히 자신의 가정과 편향을 완전히 벗어날 수 없습니다. 인간의 감독과 판단은 여전히 필수적입니다. 하지만 “AI 작성 + AI 리뷰 + 인간 검증”의 조합은 “인간 작성 + 인간 리뷰”보다 빠르고, 많은 경우 더 일관성 있는 결과를 만듭니다.

5. 제품 팀의 실험실: Dogfooding의 진화

“먹는 자신의 개밥(Dogfooding)”의 새로운 의미

전통적으로 “dogfooding”은 회사가 자신의 제품을 사용해서 문제를 발견하고 개선하는 것을 의미했습니다. 하지만 Claude Code 팀의 경우는 더 근본적입니다. 그들은 단순히 “사용”하는 것이 아니라 “완전히 의존”하고 있습니다.

Cherny의 “2개월 이상 100% Claude로만 코딩”은 dogfooding의 극단적 형태입니다. 이것은 여러 의미를 가집니다:

1. 제품에 대한 절대적 신뢰

만약 도구가 불안정하거나 신뢰할 수 없다면, 자신의 주요 제품 개발에 100% 의존할 수 없습니다. Cherny의 선택은 Claude Code가 실제로 프로덕션 레벨의 안정성과 품질을 가지고 있다는 증거입니다.

2. 가장 엄격한 테스터

일반 사용자는 도구에 문제가 있으면 다른 도구로 전환하거나 불평합니다. 하지만 제품 팀은 도피할 곳이 없습니다. 문제를 직접 해결해야 합니다. 따라서 그들은 가장 동기부여된 버그 헌터이자 기능 개선 제안자입니다.

3. 즉각적인 피드백 루프

외부 사용자의 피드백은 수집, 분류, 우선순위 지정을 거쳐 개발팀에 전달되기까지 시간이 걸립니다. 하지만 개발팀이 직접 사용자라면, 문제 발견부터 수정까지의 사이클이 극도로 짧아집니다. 아침에 버그를 발견하고, 점심 전에 수정하고, 오후에 배포하는 것이 가능합니다.

4. 엣지 케이스의 보고

일반 사용자는 도구를 “정상적인” 방식으로 사용합니다. 하지만 제품을 만드는 팀은 도구의 한계를 시험하고, 예상하지 못한 방식으로 사용하고, 복잡한 시나리오를 만듭니다. 이것이 일반 테스터가 놓치는 엣지 케이스를 발견하게 합니다.

다양한 인터페이스 사용의 의미

Cherny가 CLI, iOS 앱, Desktop 앱, Slack을 모두 사용한다는 것은 우연이 아닙니다. 이것은 의도적인 제품 전략입니다.

옴니채널 개발 경험

현대 개발자는 데스크탑에만 묶여 있지 않습니다:

출퇴근 중 지하철에서 간단한 버그 수정
회의 중 급한 코드 리뷰
집에서 소파에 누워 아이디어 프로토타이핑
사무실 책상에서 집중적인 기능 개발

각 상황마다 최적의 인터페이스가 다릅니다. iOS 앱은 모바일에, Desktop 앱은 집중 작업에, CLI는 터미널 워크플로우에, Slack은 협업에 적합합니다.

Claude Code 팀이 모든 인터페이스를 실제로 사용함으로써, 각각이 실제 워크플로우에서 어떻게 작동하는지 이해하고, 인터페이스 간 일관성을 유지하며, 각각의 강점을 최대화할 수 있습니다.

컨텍스트 전환의 매끄러움

이상적으로는 개발자가 인터페이스를 바꿔도 작업이 끊기지 않아야 합니다. 지하철에서 iOS로 시작한 작업을 사무실 도착해서 Desktop 앱으로 이어서 하고, 회의 중 Slack에서 동료와 협업하고, 배포는 CLI로 하는 것이 매끄럽게 이어져야 합니다.

Cherny 본인이 이렇게 작업하므로, 어떤 마찰점이 있는지, 어떤 정보가 전환되지 않는지, 어떤 기능이 어느 플랫폼에 빠져 있는지 직접 경험합니다. 이것이 제품 개선의 직접적 인사이트가 됩니다.

팀 전체의 참여

“팀의 다른 사람들은 주로 Claude Code 앱이나 Slack으로, 또는 Desktop 앱으로 코딩합니다”라는 언급은 팀 전체가 다양한 사용 패턴을 가지고 있음을 보여줍니다.

이것은 매우 건강한 신호입니다. 만약 모든 팀원이 똑같은 방식으로만 도구를 사용한다면, 다른 사용 패턴의 문제를 놓칠 수 있습니다. 하지만 팀 내에 다양성이 있으면:

한 사람은 CLI 파워 유저로서 터미널 통합의 모든 세부사항을 테스트
다른 사람은 GUI 선호자로서 시각적 인터페이스의 직관성을 평가
또 다른 사람은 모바일 중심으로 터치 인터페이스와 작은 화면 최적화를 검증
협업 지향적인 사람은 Slack 통합과 팀 워크플로우를 탐험

이런 다양성이 제품을 더 포괄적이고 견고하게 만듭니다.

6. 미래 예측: 확신과 신중함의 균형

“산업 전체가 몇 달 내 비슷할 것”

Cherny의 예측은 야심차지만 무모하지 않습니다. “일부는 다른 것보다 시간이 더 걸리겠지만”이라는 단서를 달아서, 모든 회사와 모든 개발자가 즉시 전환하리라고 주장하지 않습니다.

얼리 어답터 vs 주류 vs 지각 채택자

기술 확산은 S-곡선을 따릅니다:

얼리 어답터 (2-3%): Anthropic, 첨단 스타트업, 개인 개발자들 - 이미 전환 중
얼리 메인스트림 (13-14%): 혁신적인 기술 기업들 - 향후 3-6개월
레이트 메인스트림 (34%): 일반 기술 기업들 - 향후 6-18개월
지각 채택자 (34%): 보수적인 대기업, 규제 산업 - 향후 18개월 이후
래거드 (16%): 변화 거부, 레거시 시스템에 고착 - 수년 또는 절대 전환하지 않음

Cherny는 아마도 얼리 메인스트림까지는 “몇 달 내”, 레이트 메인스트림까지는 “1-2년 내”를 예상하는 것 같습니다.

장벽과 가속 요인

왜 일부는 빠르고 일부는 느릴까요?

빠른 채택을 돕는 요인:

스타트업 (레거시 없음, 빠른 의사결정)
클라우드 네이티브 기업 (현대적 도구 스택)
오픈 소스 커뮤니티 (실험 문화)
젊은 개발자 팀 (새로운 것에 열림)

느린 채택을 만드는 장벽:

대기업 (긴 승인 프로세스, 보안 심사)
규제 산업 (금융, 의료, 국방 - 엄격한 컴플라이언스)
레거시 코드베이스 (30년 된 COBOL, 방대한 기술 부채)
문화적 저항 (AI 불신, 일자리 불안)

Cherny의 예측이 맞으려면, 빠른 채택 집단의 성공 사례가 명백해야 합니다. “저 회사는 AI로 개발 속도를 3배 높였는데 우리는 왜 안 하지?”라는 경쟁 압력이 확산을 가속화할 것입니다.

“비-코딩 작업도 따라올 것”

Cherny의 더 대담한 예측은 코딩을 넘어선 확산입니다. 이것은 여러 단계로 펼쳐질 것입니다:

1단계 - 코드와 가까운 작업 (현재)

인프라 스크립트 (Terraform, Kubernetes YAML)
SQL 쿼리와 데이터 분석
설정 파일 (JSON, YAML, TOML)

2단계 - 구조화된 콘텐츠 (진행 중)

기술 문서 (API 문서, 가이드)
테스트 케이스와 버그 리포트
프로젝트 관리 (이슈 생성, 마일스톤 정의)

3단계 - 창의적 작업 (시작 단계)

UI/UX 디자인 구현
마케팅 콘텐츠 생성
비즈니스 분석과 전략 문서

4단계 - 복합 워크플로우 (미래)

제품 기획부터 배포까지 전 과정
고객 피드백 분석에서 기능 구현까지
아이디어에서 프로토타입까지

Cherny가 “몇 달 내”라고 할 때, 아마도 1-2단계를 의미하는 것 같습니다. 3-4단계는 더 시간이 걸리겠지만, 방향은 분명합니다.

신중한 낙관

Cherny의 답변 전체를 관통하는 톤은 “신중한 낙관(cautious optimism)”입니다. 그는:

현재 문제를 부정하지 않음 (과도한 복잡화, dead code, 리팩터링 부족)
하지만 이것들이 해결 가능하다고 믿음 (모델 개선, 더 나은 도구)
구체적 증거를 제시함 (자신의 100% 통계, 팀의 실제 사용 사례)
과장하지 않음 (“일부는 더 오래 걸릴 것”)

이것은 AI 시대에 필요한 균형 잡힌 태도입니다. 맹목적 낙관도, 냉소적 비관도 아닌, 현실을 직시하면서도 가능성을 믿는 자세입니다.

7. 내부자 vs 외부자: 두 관점의 조화

Karpathy와 Cherny의 대화가 주는 가치

Karpathy의 원글과 Cherny의 답변을 함께 읽으면, 매우 입체적인 그림이 나옵니다.

Karpathy (외부 사용자 관점):

놀라움과 발견: “이게 이렇게까지 되나?”
솔직한 문제 지적: 실수, 과도한 복잡화, 능력 위축
철학적 질문: 10X 엔지니어는? 제너럴리스트 vs 스페셜리스트는?
사회적 우려: Slopacolypse, 격차 확대

Cherny (내부 개발자 관점):

확신과 데이터: “우리는 이미 100% 사용 중”
문제 인정과 해결 방안: “맞습니다, 하지만 개선되고 있습니다”
구체적 실천: claude -p, 다양한 인터페이스
낙관적 예측: “산업 전체가 곧 따라올 것”

이 두 관점은 서로를 보완합니다. Karpathy는 “이게 정말 지속가능한가?” 묻고, Cherny는 “우리는 이미 지속하고 있고, 점점 나아지고 있습니다”라고 답합니다.

신뢰성의 문제

흥미롭게도, 두 사람의 증언은 서로 다른 이유로 신뢰됩니다.

Karpathy의 신뢰성:

이해관계 없음: Anthropic 직원 아님, 솔직한 비판 가능
깊은 전문성: AI 연구자이자 엔지니어로서 기술적 통찰
공개적 성찰: 수천 명이 읽는 트윗에서 장단점 모두 논의
커뮤니티 검증: Hacker News에서 수백 명의 개발자들이 토론하고 검증

Cherny의 신뢰성:

직접 경험: 매일 도구를 사용하는 당사자
구체적 데이터: “2개월”, “100%”, “22 PR” 같은 측정 가능한 주장
문제 인정: 제품 한계를 솔직히 인정하는 것이 오히려 신뢰 증가
피부에 와닿는 이해관계: 만약 도구가 나쁘면 자신의 생산성도 떨어짐

둘을 종합하면, AI 코딩이 실제로 작동하고, 실제로 유용하며, 실제 문제도 있지만, 실제로 개선되고 있다는 그림이 그려집니다.

서로 다른 우선순위

두 사람의 강조점 차이도 흥미롭습니다:

Karpathy의 우선순위:

능력 위축 - “손으로 코딩하는 능력이 위축됨”
Slopacolypse - 저품질 콘텐츠 범람 우려
재미 - 프로그래밍이 더 재미있어짐
끈기 - AI의 지치지 않는 시도

Cherny의 우선순위:

생산성 - “하루 25개 PR”
품질 개선 - “기준이 더 높아질 것”
팀 구성 - 제너럴리스트 채용
자동 리뷰 - claude -p로 문제 잡아내기

Karpathy는 개인 개발자로서의 경험과 철학적 성찰에 집중하고, Cherny는 팀과 제품의 실용적 측면에 집중합니다. 이것은 그들의 역할과 책임을 반영합니다.

8. 한국 기업과 개발자에게 주는 시사점

빠른 추격 vs 신중한 도입

한국 기업들은 이 대화에서 무엇을 배울 수 있을까요? 두 가지 상반된 메시지가 있습니다:

Cherny의 메시지: “빨리 시작하라”

산업 전체가 몇 달 내 전환될 것
늦으면 경쟁에서 뒤처짐
일단 시작하고 배우면서 개선

Karpathy의 메시지: “신중하게 접근하라”

능력 위축, 기술 부채 같은 리스크 존재
맹목적 AI 의존은 위험
비판적 사고와 검증 유지

한국 기업의 현명한 접근은 아마도:

파일럿 팀으로 시작: 전사 도입 전에 혁신적인 소규모 팀에서 실험
측정과 학습: 생산성, 품질, 개발자 만족도를 정량적으로 측정
점진적 확장: 성공 사례가 명확해지면 단계적으로 확대
안전장치 마련: 자동 리뷰, 페어 프로그래밍, 코드 품질 게이트 강화

제너럴리스트 육성

Cherny의 “제너럴리스트 채용” 전략은 한국 IT 교육과 채용에 시사점을 줍니다.

전통적 한국 방식:

전공 중시: “컴퓨터공학 전공자만”
특정 기술 스택 요구: “3년 이상 Java Spring 경험”
세부 기술 테스트: 알고리즘, 자료구조, 프레임워크 API 암기

AI 시대에 필요한 것:

학습 능력: “새로운 것을 빨리 배울 수 있는가?”
문제 정의: “무엇을 만들어야 할지 파악하는가?”
시스템 사고: “전체 그림을 볼 수 있는가?”
AI 협업: “AI를 효과적으로 활용할 수 있는가?”

한국 기업들은 채용과 교육에서 이런 전환이 필요합니다. “React를 아는가?”보다 “React를 AI와 함께 배울 수 있는가?”가 더 중요해집니다.

자동화된 코드 리뷰 도입

claude -p로 모든 PR을 리뷰하는 Anthropic의 관행은 한국 기업들이 즉시 도입할 수 있는 실천입니다.

현재 많은 한국 기업의 코드 리뷰:

형식적: 시간 부족으로 대충 훑어봄
불균등: 시니어는 바빠서 안 하고, 주니어는 뭘 봐야 할지 모름
일관성 부족: 리뷰어마다 다른 기준
병목: 리뷰 대기로 배포 지연

AI 자동 리뷰 도입 후:

모든 PR에 일관된 1차 검증
인간 리뷰어는 전략적 검토에 집중
빠른 피드백 (몇 초 내)
학습 효과 (반복 지적되는 패턴을 개발자가 학습)

이것은 즉시 시작할 수 있고, 비용도 크지 않으며, ROI가 명확합니다.

다양한 인터페이스 지원

Cherny의 “CLI, iOS, Desktop, Slack” 활용은 한국 기업의 개발 환경 구축에도 시사점을 줍니다.

많은 한국 기업들은 여전히:

사무실 책상의 워크스테이션에 의존
VPN으로 회사 네트워크 접속 강제
보안을 이유로 모바일/클라우드 제한

하지만 AI 시대에는:

언제 어디서나 개발 가능해야 함
컨텍스트 전환이 매끄러워야 함
협업이 실시간으로 이루어져야 함

보안과 편의성의 균형을 새롭게 찾아야 합니다. 예를 들어, 민감한 코드는 온프레미스에서만, 일반 개발은 클라우드에서도 가능하게 하는 등의 하이브리드 접근입니다.

9. 비판적 질문과 우려

“100% AI 코딩”의 지속가능성

Cherny가 2개월 이상 100% AI로만 코딩했다는 것은 인상적이지만, 몇 가지 질문이 남습니다:

Q1: 이것이 특수한 상황인가? Claude Code는 상대적으로 새로운 제품이므로, 레거시 코드 부담이 적습니다. 30년 된 레거시 시스템을 유지하는 팀도 100% AI 코딩이 가능할까요?

Q2: 모든 유형의 작업에 적용 가능한가? 새로운 기능 개발은 AI에게 좋은 작업입니다. 하지만 복잡한 버그 디버깅, 성능 프로파일링, 아키텍처 리팩터링도 100% AI로 가능할까요?

Q3: 코드 이해도는 유지되는가? 100% AI가 작성한 코드를 사용하면서도, Cherny는 코드베이스를 깊이 이해하고 있을까요? 6개월 후 그 코드를 유지보수할 때 문제는 없을까요?

Q4: 팀 전체 평균은? Cherny는 최고 수준의 엔지니어입니다. 평균적인 개발자도 같은 수준의 AI 활용이 가능할까요?

Slopacolypse 논쟁의 해결되지 않은 측면

Karpathy는 저품질 콘텐츠 범람을 우려하고, Cherny는 모델 개선으로 해결될 것이라 낙관합니다. 하지만:

시간차 문제: 모델이 개선되기 전에 slop이 먼저 쌓일 수 있습니다. 그 과도기를 어떻게 관리할까요?

인센티브 문제: AI로 콘텐츠 생성 비용이 0에 가까워지면, 품질과 무관하게 양만 추구하는 인센티브가 생깁니다. 이것을 어떻게 제어할까요?

신호 대 잡음: 검색 엔진, 추천 알고리즘이 AI 생성 콘텐츠를 식별하고 품질로 필터링할 수 있을까요? 아니면 그것들도 AI 생성이라 또 다른 AI와의 군비 경쟁이 될까요?

의존성과 벤더 락인

Cherny의 팀이 Claude Code에 100% 의존한다는 것은, 반대로 Claude Code 없이는 작동할 수 없다는 의미이기도 합니다.

만약 Anthropic에 문제가 생긴다면?

서비스 중단: API 다운타임, 가격 인상, 모델 성능 저하
회사 문제: 인수합병, 사업 방향 변경, 서비스 종료
규제 문제: 특정 국가에서 서비스 금지, 데이터 주권 이슈

대안은 있는가?

오픈 소스 모델: 성능이 뒤처짐
다른 상업 모델: 전환 비용과 학습 곡선
내부 모델 개발: 현실적으로 대부분 기업에 불가능

이것은 클라우드 컴퓨팅 초기의 논쟁과 비슷합니다. “AWS에 모든 것을 맡기면 락인된다”는 우려가 있었지만, 실제로는 클라우드의 이점이 너무 커서 대부분 기업이 수용했습니다. AI도 비슷한 경로를 밟을 수 있지만, 위험은 여전히 존재합니다.

10. 장기적 전망: 5년 후 소프트웨어 개발

2030년의 개발 팀 모습

Cherny와 Karpathy의 대화를 연장하면, 5년 후 개발 팀은 어떤 모습일까요?

인력 구성:

1-2명의 “비전 아키텍트”: 무엇을 만들지 정의하고 전략적 결정
2-3명의 “AI 조율자”: 여러 AI 에이전트를 관리하고 조정
3-4명의 “품질 검증자”: AI 결과물을 검증하고 테스트
수십 개의 AI 에이전트: 실제 코딩, 테스팅, 배포, 모니터링

과거 10명이 하던 일을 5명 + AI가 10배 속도로 할 수 있습니다.

작업 흐름:

아침 스탠드업: 팀원들이 각자 관리하는 AI 에이전트의 진행상황 공유
전략 세션: 다음 분기 로드맵, 아키텍처 결정 등 고차원 논의
AI 태스킹: 각자 담당 AI에게 당일 작업 할당
모니터링: AI 진행상황 모니터, 막힌 부분 해결, 품질 검증
통합 리뷰: AI들이 완성한 작업을 통합하고 전체 시스템 테스트
배포: 자동화된 CI/CD, 인간은 승인 버튼만 클릭

기술 스택:

언어/프레임워크: AI가 최적 선택, 필요시 실시간 전환
인프라: 완전 자동화, 셀프 힐링 시스템
문서: AI가 코드 변경과 동시에 자동 업데이트
테스트: 100% 커버리지, 자동 생성 및 유지보수

교육의 변화

컴퓨터 공학 교육도 근본적으로 바뀔 것입니다:

과거 교육:

프로그래밍 언어 문법
자료구조와 알고리즘
디자인 패턴
프레임워크 사용법

미래 교육:

문제 정의와 분해
AI 프롬프팅과 협업
시스템 사고와 아키텍처
윤리와 책임
품질 검증과 테스팅

“코딩”보다 “소프트웨어 엔지니어링”이 중심이 됩니다. 마치 전기공학이 “전선 연결”보다 “시스템 설계”가 핵심이듯, 소프트웨어 엔지니어링도 “코드 작성”보다 “문제 해결”이 핵심이 됩니다.

산업 구조의 재편

소프트웨어 회사의 변화:

대기업의 우위 감소: AI로 소수 인원도 대규모 시스템 개발 가능
스타트업 폭발: 창업 비용 급감, 아이디어가 있으면 누구나 시도
수직 통합: 한 팀이 프론트, 백, 인프라, 모바일, ML 모두 담당

새로운 직업:

AI 프롬프트 엔지니어 (이미 등장 중)
AI 에이전트 조율자
크로스-AI 통합 전문가
AI 윤리 감사관
레거시 코드 AI 번역가

사라지거나 변하는 직업:

주니어 개발자 (AI가 대체)
코드 작성 위주 역할 (프론트엔드 “코더”, 백엔드 “구현자”)
QA 테스터 (자동 테스팅)
DevOps (완전 자동화)

하지만 완전히 사라지지는 않을 것입니다. 오히려 더 고차원적 형태로 진화할 것입니다. 주니어 개발자는 “AI 학습자”로, QA는 “품질 전략가”로, DevOps는 “인프라 아키텍트”로 진화합니다.

결론: 두 증언이 그리는 미래

합의점: 변화는 현재진행형

Karpathy와 Cherny는 세부사항에서는 의견이 다르지만, 핵심에는 동의합니다:

AI 코딩은 현실이다: 더 이상 실험이나 미래가 아니라, 지금 여기서 일어나고 있는 현실입니다.
돌아갈 수 없다: 한번 경험하면, 과거 방식으로 돌아가는 것은 상상하기 어렵습니다.
문제가 있지만 개선되고 있다: 완벽하지 않지만, 빠르게 나아지고 있습니다.
산업 전체가 영향받을 것이다: 소수 얼리 어답터의 실험이 아니라, 전체 산업의 패러다임 전환입니다.

차이점: 낙관의 정도

Karpathy의 신중한 낙관:

놀라운 가능성을 보지만
위험(능력 위축, slopacolypse, 의존성)도 경계하고
철학적 질문(10X 엔지니어, 재미의 본질)을 던지며
사회적 영향을 고민합니다

Cherny의 자신있는 낙관:

내부 데이터로 효과를 입증하고
문제는 인정하되 해결 가능하다고 보며
구체적 실천(자동 리뷰, 다중 인터페이스)을 공유하고
빠른 확산을 예측합니다

둘 다 옳을 수 있습니다. Cherny는 최첨단에서 최상의 도구와 팀으로 일합니다. 당연히 더 낙관적일 수 있습니다. Karpathy는 일반 개발자의 현실과 장기적 사회 영향을 생각합니다. 당연히 더 신중할 수 있습니다.

우리에게 주는 교훈

이 두 사람의 대화는 우리에게 몇 가지 중요한 교훈을 줍니다:

1. 실험하라, 하지만 비판적으로 AI 코딩 도구를 적극적으로 시도하되, 맹목적으로 수용하지 마세요. Cherny처럼 대담하게 사용하면서도, Karpathy처럼 신중하게 관찰하세요.

2. 측정하라 “AI로 생산성이 올랐다”는 느낌이 아니라, 구체적으로 측정하세요. PR 수, 버그 수, 배포 빈도, 개발자 만족도 등을 정량화하세요.

3. 학습을 멈추지 마라 AI가 구현을 도와주더라도, 기본 원리와 고차원 스킬을 계속 배우세요. 그것이 AI를 더 효과적으로 사용하게 하고, 능력 위축을 방지합니다.

4. 커뮤니티와 공유하라 Karpathy와 Cherny가 공개적으로 경험을 나누듯, 여러분의 성공과 실패도 공유하세요. 우리 모두 함께 배우고 있습니다.

5. 윤리적으로 접근하라 AI가 생성한 코드의 품질, 보안, 접근성에 책임을 지세요. Slopacolypse를 방지하는 것은 각자의 몫입니다.

6. 미래를 준비하라 5년 후 소프트웨어 개발은 지금과 매우 다를 것입니다. 지금부터 제너럴리스트 역량, AI 협업 능력, 시스템 사고를 키우세요.

마지막 생각

Karpathy의 경험담은 개인 개발자의 솔직한 고백이었고, Cherny의 답변은 제품 팀의 자신있는 증언이었습니다. 둘을 종합하면, AI 코딩이 과대광고도 아니고 환상도 아닌, 실제로 작동하고 빠르게 발전하는 현실임을 알 수 있습니다.

우리는 Karpathy가 말한 “20년 만의 가장 큰 변화”의 한가운데 서 있습니다. Cherny가 예측하듯 “산업 전체가 몇 달 내 따라올” 수도 있습니다. 이 변화는 두렵기도 하고 흥미롭기도 합니다.

중요한 것은 이 변화를 능동적으로 맞이하는 것입니다. 변화를 거부하며 뒤처질 수도, 맹목적으로 따라가다 잘못된 길로 갈 수도 있습니다. 대신, Karpathy의 비판적 성찰과 Cherny의 대담한 실천을 모두 배우며, 우리만의 길을 찾아야 합니다.

2026년은 정말로 Karpathy가 말한 “고에너지의 해”가 될 것입니다. 그리고 Cherny가 보여주듯, 그 에너지의 중심에는 AI와 인간의 협업이 있을 것입니다.

변화의 물결에 올라타되, 방향은 우리가 정합시다.

작성 일자: 2026-01-29

AI, Material

AI Material BorisCherny Claude agentic-coding Claude.write