Claude Code는 당신의 제품을 더 좋게 만들지 않는다

• 코딩 에이전트의 생산성 효과는 균등하지 않고 K자형으로 갈라지며, 핵심 지표는 시간당 코드 줄 수가 아니라 엔지니어 1인당 제품 개선 속도가 실제로 높아졌는지에 있음
• Dax, Karri Saarinen, David Cramer는 AI 비판자가 아니지만, 코딩 에이전트가 제품 개선 속도를 뚜렷하게 높인다는 확신을 얻지 못하고 있으며 Cramer는 LLM이 복잡성과 비대화를 늘려 장기 속도를 늦춘다고 봄
• Claude Code가 Anthropic 내부에서 7개월간 독점적 이점을 줬다면 경쟁자와의 격차가 복리로 벌어져야 했지만, Codex, Cursor, Cognition, Factory가 여전히 경쟁하고 있어 병목이 코드 생산이 아닐 가능성이 커짐
• 좋은 엔지니어링 문화는 코드 줄 수를 자산이 아니라 비용으로 다루며, 기능과 통합이 늘수록 버그 표면·의존성·주변 기능이 함께 늘어 복잡성이 선형이 아니라 복리로 증가함
• 제품 품질의 최전선에서는 빠른 코드 작성보다 취향, 압축, 삭제, 거절의 판단이 더 중요하며, Claude Code는 0에서 Camry 수준으로 가는 데 유용하지만 Ferrari 장인들이 더 빠른 Ferrari를 만들게 하지는 못함

K자형 생산성 곡선

• 코딩 에이전트의 생산성 향상은 균등하지 않고 K자형으로 갈라짐
  • 시니어 엔지니어는 2023년 LLM 변곡점 이후 측정 가능한 산출 증가를 보임
  • 주니어 엔지니어의 산출은 거의 정체하거나 감소함
  • 중요한 지표는 시간당 코드 줄 수가 아니라, 엔지니어 1인당 제품 개선 속도가 실제로 올라가는지에 있음
• 에이전트형 코딩은 특정 작업에서 Pull Request를 만드는 시간을 줄여줌
  • “백로그 6년치를 한 분기에 처리했다”, “Cursor로 백엔드를 3일 만에 만들었다”, “Claude Code는 완전히 Claude로 코딩됐다” 같은 주장이 반복됨
  • 다만 코드 생산 속도가 제품 품질 향상과 같은 지표인지는 별개의 문제로 남음

제품을 잘 만드는 엔지니어들의 경고 신호

• Dax, Karri Saarinen, David Cramer는 모두 AI 비판자가 아니지만, 코딩 에이전트가 제품 개선 속도를 뚜렷하게 높인다는 확신을 얻지 못하고 있음
  • Dax는 opencode.ai를 만들고 있음
  • Karri Saarinen은 Linear CEO임
  • David Cramer는 Sentry를 처음부터 만들어 월 1,000만 달러 규모까지 성장시킨 인물임
• David Cramer는 LLM이 현재 순생산성 향상을 만들지 못한다고 봄
  • 시작 장벽은 낮추지만, 유지보수하기 어려운 복잡한 소프트웨어를 만든다고 함
  • 장기 속도를 늦추는 것으로 보인다고 함
  • LLM의 “복잡성 속 점진적 개발 성능 부족”, “진정한 단순화와 관용적 인터페이스 생성 능력 부족”, “엉성한 테스트 생성 기법”을 문제로 꼽음
  • 결국 대부분이 비대화(bloat) 라는 판단임
• Dax는 코딩 에이전트를 가장 잘 활용하는 방법을 아직 명확히 찾지 못했다고 밝힘
  • 반면 외부에서는 “모든 PR이 AI 생성”, “전례 없는 속도”, “6년치 백로그 처리” 같은 주장이 많음
  • 실제 제품 개선 속도를 높이는 데에는 이들 모두 어려움을 겪고 있음

Claude Code의 독점적 이점이 격차로 나타나지 않음

• Claude Code가 완전히 Claude로 코딩됐다면, 제품 개선 속도는 가속되어야 함
  • Claude Code 사용이 제품 개선 속도를 1.5배만 높여도, 처음부터 이를 사용한 팀은 시간이 갈수록 경쟁자와 격차를 벌려야 함
  • 엔지니어링 생산성은 복리 함수이므로, 분기마다 차이가 커져야 함
• 실제 시장 상황은 그런 복리 격차를 보여주지 않음
  • Codex는 Claude Code보다 몇 달 늦게 출시됐지만 이미 기능적으로 경쟁 가능함
  • Cursor의 거래 흐름은 강함
  • Cognition과 Factory도 여전히 중요한 엔터프라이즈 계약을 따내고 있음
  • 사람들은 여전히 어떤 도구가 더 나은지 논쟁하고 있음
• 핵심 반증은 Anthropic이 Claude Code를 7개월 독점적으로 가졌다면, 진짜 제품 속도 우위가 있을 경우 경쟁자와의 격차가 따라잡을 수 없을 만큼 커졌어야 한다는 점임
  • Codex는 무의미해졌어야 하지만 그렇지 않음
  • 복리 우위가 보이지 않는다면 제품 품질의 병목은 코드가 아니었을 가능성이 큼
• 가능한 반론도 같은 결론을 강화함
  • 이득이 있더라도 복잡성 부채가 이를 먹어치웠을 수 있음
  • Anthropic의 엔지니어링 팀이 너무 커서 엔지니어당 한계 이득이 희석됐을 수 있음
  • 하지만 이 경우에도 병목은 코드 생산이 아니라 더 어려운 다른 요소가 됨

코드 줄 수는 자산이 아니라 비용

• 좋은 엔지니어링 문화는 코드 줄 수를 생산물이 아니라 지출로 다룸
  • 중요한 기능에는 코드를 쓰고, 중요하지 않은 기능에는 쓰지 않음
  • 코드베이스는 대차대조표상의 자산이 아니라 부채에 가까움
• comma.ai의 소프트웨어 자회사 tinychat은 코드베이스가 일정 크기를 넘으면 알람이 울리게 했고, 삭제된 코드를 축하했음
  • 모든 코드 줄은 버그 표면임
  • 모든 함수는 다음 함수의 의존성이 됨
  • 모든 기능은 주변 기능을 만들어냄
• 제품 표면적은 프랙탈처럼 확장됨
  • Slack 통합을 추가하면 Teams 통합과 이메일 대체 경로가 필요해짐
  • 알림을 추가하면 모바일, SMS, 엔터프라이즈 MDM 정책에 맞춰 다시 만들어야 함
  • MFA 지원을 추가하면 Duo, Okta, SAML과 호환돼야 함
  • 복잡성은 선형이 아니라 복리로 증가함
• Linear는 178명, 6년, ARR 1억 달러 규모임
  • Jira는 누적 엔지니어링 노력에서 Linear보다 56배 크지만 소비자 품질 점수는 6점 낮게 나타남
  • 핵심은 품질과 코드베이스 질량이 같지 않다는 점임
• Facebook 같은 규모에서는 UI 코드를 빨리 생산하는 능력이 병목이 아님
  • 숙련된 엔지니어는 Facebook 피드 목업을 하루 만에 만들 수 있음
  • 실제 제약은 수십억 명에게 어떤 부하와 지연 시간에서도 업타임을 유지하며 그 경험을 전달하는 데 필요한 코드 줄 수를 줄이는 것임
  • 보상 함수는 생산이 아니라 압축임
  • 이런 작업에서 코딩 에이전트는 장기 트레이드오프를 평가하지 못하며, 시스템에 대한 이론을 갖고 있지 않음

진짜 병목은 좋은 제품 아이디어의 최전선을 미는 능력

• 최전선의 제품 품질 개선은 코드를 얼마나 빨리 쓰느냐가 아니라, 최전선을 밀 만큼 좋은 아이디어를 얼마나 빨리 떠올리느냐에 의해 제한됨
• Jira와 Linear의 차이는 더 나은 박스를 그렸는지가 아님
  • Linear에는 프로젝트 관리 소프트웨어가 어떤 느낌이어야 하는지에 대한 구체적인 창의적 비전이 있었고, 이를 수년 동안 절제 있게 실행함
  • 이런 품질은 토큰 처리량에서 나오지 않고 취향과 덜 만드는 결정에서 나옴
• “6년치 백로그를 처리했다”는 주장은 들리는 것만큼 인상적이지 않음
  • CRUD 기능과 내부 도구로 가득한 백로그는 코딩 에이전트가 가속하는 작업에 잘 맞음
  • 동시에 그런 작업은 제품의 최전선을 미는 작업이 아님
  • 더 빨리 출시했다고 제품이 좋아지는 것이 아니라, 출시한 것이 사용자가 더 신경 쓰게 만들 때 제품이 좋아짐
• AI 코딩 에이전트는 0에서 1로 가는 제품을 품질 최전선에 더 빨리 도달하게 도와줌
  • 첫 동작 버전까지 걸리는 시간을 줄임
  • 초기 단계 작업에서 속도 향상은 실제로 존재함
• 비용도 있음
  • 코드베이스가 품질보다 더 빨리 커짐
  • 기술 부채가 복리로 쌓임
  • 지금 얻는 속도는 나중에 갚아야 할 비용으로 구매하는 것임

모두에게 Camry를, 누구에게도 Ferrari는 아님

• 최전선에 있는 팀의 병목은 코딩 에이전트가 아니라 취향을 가진 사람들임
  • Linear와 Sentry처럼 “덜어내는 취향으로 최고가 되는” 능력은 특정 사람 안에 있음
  • Linear의 Nan Yu, Skunk Works의 Kelly Johnson이 예로 제시됨
  • Kelly Johnson의 선별된 팀은 SR-71을 만들었고, SR-71은 60년 뒤에도 가장 빠른 공기흡입 유인 항공기로 언급됨
  • Blackbird가 빨랐던 이유는 청사진을 더 많이 생산했기 때문이 아니라, 무엇을 남기지 않을지에 대한 Johnson의 이론이 있었기 때문임
  • 삭제하고, 압축하고, 거절하는 취향은 어떤 프런티어 모델 로드맵에도 없으며, 바닥 수준이 올라갈수록 오히려 더 가치 있어짐
• 이미 최전선에 있다면 토큰 지출로 R&D 비용을 두 배로 늘리는 것이 경제적 가치를 만드는지는 불명확함
  • Ramp 엔지니어들은 지난 1년 동안 토큰 지출로 사실상 급여를 두 배로 늘렸다고 함
  • Ramp 제품이 실제로 더 좋아졌는지는 확인하기 어려움
  • 이미 1위라면 승률은 거의 고정돼 있고, “더 큰 차이로 1위”가 되는 것은 측정하기 어려움
  • 판단을 바꾸려면 Ramp의 승률 또는 손익 데이터가 필요함
  • Ramp 고객으로서 현재와 작년의 차이를 체감하지 못한다고 밝힘
• Claude Code는 누구나 Camry 경쟁 제품을 만들도록 도울 수 있지만, Ferrari 장인들이 더 빠른 Ferrari를 만들도록 돕지는 못함
  • 0에서 Camry 수준으로 가는 데는 매우 유용함
  • 최고 수준이 아닌 소프트웨어의 생산 비용은 크게 낮아질 가능성이 큼
  • 대신 공장 서까래에 혼란과 부채가 많이 쌓이고, 결국 누군가 이를 치워야 함