▲

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

 (ethanding.substack.com)
1P by GN⁺ 2시간전 | ★ favorite | 댓글 1개
  • 코딩 에이전트의 생산성 효과는 균등하지 않고 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 수준으로 가는 데는 매우 유용함
    • 최고 수준이 아닌 소프트웨어의 생산 비용은 크게 낮아질 가능성이 큼
    • 대신 공장 서까래에 혼란과 부채가 많이 쌓이고, 결국 누군가 이를 치워야 함

함께 보면 좋은 글 β

▲
GN⁺ 2시간전  [-]
Lobste.rs 의견들

  • 복잡도는 지수적으로 증가하고, 아마 그보다 더 빠를 수도 있음. 그래서 AGI 특이점을 두려워하는 사람들도 종종 놓치는데, 아무리 똑똑한 사람·모델·에이전트라도 아이디어·시스템·프로젝트·코드베이스·기능 집합이 커지면 결국 급격한 복잡도의 벽에 부딪힘
    모든 소프트웨어 프로젝트는 초반엔 비교적 순조롭지만, 어느 순간 복잡도의 지수 증가가 모든 걸 압도함. 좋은 아키텍처·설계·품질은 그 시점을 늦출 뿐이고, 유능한 사람들이 잘 설계하고 품질을 챙기면 크기·기능·성능·와우 포인트를 10배쯤 더 버틸 수는 있어도 결국 벽에 닿게 됨
    LLM 보조는 일정 수준, 대체로 평균적인 품질의 기능과 코드를 훨씬 빨리 만들게 해줌. 즉 그 벽에도 훨씬 빨리 도달한다는 뜻임. 성장, 실험, 비교적 쉬웠지만 시간이 많이 들던 저복잡도 작업에는 좋지만, 전에 없던 것이나 크고 복잡한 프로젝트를 만들게 해주는 건 아님. 그런 데 필요한 건 복잡도를 억제하는 개선인데, 현재 LLM은 그걸 제대로 제공하지 못함

    • 고전적인 문제임. 원인과 결과가 바로 이어지면 즉각적인 이익은 쉽게 보이지만, 원인과 결과 사이에 시간이 벌어져 있으면 부정적 효과는 훨씬 보기 어려움
      http://bastiat.org/en/twisatwins.html
      코드 에이전트 사용 비용은 직접적으로 드러나지 않고, 무엇보다 시스템이 어떻게 동작하는지에 대한 집단적 이해 상실에서 나옴
    • 그래도 계층적 조직화는 큰 규모의 복잡도를 관리하는 길을 제공함. 자연에서도 이런 방식으로 엄청나게 복잡한 구조가 생겨나는 걸 볼 수 있음. 독립적인 단위들이 조합되어 더 큰 구조를 이루는 식으로 시스템을 만들 수 있음
      견고한 시스템은 충격에 버티고 스스로 적응할 수 있어야 하므로, 각 부분은 독립적으로 실패하고 피해도 국소화되어야 함. 시스템을 중첩된 하위 시스템으로 조직하면, 서로 대화하며 일을 처리하는 세포 같은 단위가 생김. 이 단위들은 다른 세포의 내부 과정을 알 필요 없이 안정적인 부분 조립품처럼 동작함
      각 계층은 다른 곳에서 벌어지는 일에 발목 잡히지 않으므로 자기 영역 안에서 스스로 조직화하고 회복력을 유지할 수 있음. 이는 사실상 인터페이스 뒤에 부수적 복잡도를 캡슐화하고, 그 인터페이스가 의미를 담는 추상화를 만드는 방식임. 계층은 큰 시스템의 구성 요소들을 잇는 결합 조직으로 보는 게 좋음
      Erlang OTP는 이런 접근을 소프트웨어에서 잘 보여주는 예로, 큰 시스템을 서로 메시지를 주고받는 격리된 프로세스들로 구성함. 개별 프로세스가 죽거나 오류가 나도 전체 시스템을 무너뜨리지 않음
    • “복잡도를 억제한다”는 건 결정, 견해, 그리고 때로는 반대나 충돌을 필요로 한다고 봄
      누군가에게 무언가를 구현해 달라고 하면 “너무 복잡하다”, “1년 뒤에 터질 거다”, “Y팀이 하고 있다는 것과 호환되지 않는다”, “구현할 사람이 충분하지 않다” 같은 답을 할 수 있음. 마지막 말은 실제일 수도 있고, 간접적으로 “안 된다”고 말하는 방식일 수도 있음
      LLM이 그렇게 답할 가능성은 매우 낮음. 특히 낙관적이고 공손하게 조정되어 있기 때문임. 더구나 그런 성향이 참여도를 높이는 데 필요하니 다르게 조정될 가능성도 낮아 보임
      이 문제는 LLM이 사용자의 자살을 도운 문제와 비슷해 보임. 그건 꽤 명백한데도 LLM이 많이 해왔음. 관리되지 않은 복잡도로 프로젝트가 죽는 건 그보다 훨씬 덜 명확하니, LLM이 가까운 시일 안에 더 잘해낼 거라는 기대는 크지 않음

  • “Claude Code를 쓰면 진짜 제품 개발 속도 우위가 생기고, Anthropic이 7개월 동안 독점했다면 Claude Code와 모든 경쟁자 사이의 격차는 메울 수 없어야 한다. Codex는 무의미해야 한다. 그런데 사람들은 여전히 어느 쪽이 더 나은지 활발히 논쟁 중이다”라는 식의 추론은 탄탄해 보이지 않음
    Claude Code는 좋은 소프트웨어지만, 경쟁이 불가능해질 정도의 이상한 AGI 마법은 아님

    • 게다가 Codex도 바이브코딩으로 만들어졌으니 그 비교는 그런 면에서도 좀 우스움. 몇 달 먼저 시작했다는 건 별 의미가 없을 수 있음. 추가되는 많은 기능은 실제 사용자들이 도구로 무엇을 하는지에서 나오기 때문임
      Claude Code가 처음부터 완성된 로드맵을 갖고 있었고, 주된 장벽이 코드 작성 속도였던 건 아님. 핵심 장벽은 아이디어임. 모두가 해가며 만들어내는 중임
      글을 대체로 훑어봤을 뿐이라 깊게 말하긴 어렵지만, 문장 첫 글자 대소문자 문제는 차치하더라도 대부분 LLM이 쓴 산문처럼 보여서 읽고 싶지는 않았음

  • 지금까지 에이전트의 실수는 곱셈적으로 누적되는 경향이 있음
    기술적으로는 동작하지만 사용할 때 약간의 추가 코드가 필요한 API를 만들면, 그 결과 코드가 늘어나고, 중복·분기·버그가 생길 장소도 늘어남. 그러면 프랙털처럼 또 그다지 좋지 않은 코드가 더 많이 작성됨
    한 에이전트가 id 필드가 선택적인 구조체를 설계한 적이 있음. 자기가 작성한 생성자 하나 때문에 필요했던 필드였음. 그러고는 id가 있을 때와 없을 때의 코드를 지치지도 않고 두 벌로 쓰고, 없을 때를 위한 어색한 대체 경로까지 만들었음. 그 대체 경로들은 당연히 복잡하고 취약했음. 구조체의 거의 모든 사용처와 그에 의존하는 것들까지 감염됐고, 정작 id 없는 생성자는 쓰이지도 않았음. 코드베이스 절반은 쉽게 삭제할 수 있었음
    “멍청한 짓을 하고 있으면 파기를 멈춰라” 같은 지시를 충분히 넣으면 고칠 수 있고 코딩이 “해결”되기까지 몇 가지 해킹만 남은 건지, 아니면 확률적 앵무새의 장기적 문제라 선형 개선을 위해 지수적으로 증가하는 비용이 계속 필요한 건지 정말 모르겠음. 실수가 복리로 쌓이는 한, 복리 성장은 결국 발목을 잡음

    • 인간 개발자에게도 매우 비슷한 일이 일어나는 걸 봤음. 최고의 개발자를 가르는 특징 중 하나는 한 단계 높고 바깥 수준에서 멈춰 돌아보는 성향이라고 봄
      때로는 비즈니스 프로세스까지 포함됨. 도메인을 잘 아는 개발자는 기술적 해법을 몇 달 구현하는 대신 “계속 파기보다 그냥 프로세스를 바꾸면 안 되나?”라고 물을 수 있고, 답이 “물론이지, 그건 쉽다”일 때도 있음
      LLM도 결국 이 부분을 더 잘하게 될 것 같음. 이미 “이 접근은 좋아 보이지 않는데, 대안을 생각해볼 수 있나?”라고 직접 물으면 꽤 자주 찾아내기도 함. 다만 지금은 성공과 실패가 들쭉날쭉하고, 일단 그런 멍청한 일을 해두면 관련 없는 작업을 하다가 스스로 알아차릴 가능성은 낮음
      여기엔 절충도 있음. 사람들은 이미 모델이 문제를 과하게 생각하며 토큰을 태운다고 불평함. 특정 문제를 푸는 코드가 “어떤 느낌이어야 하는지”에 대한 경험과 직관이 있으면 개발자는 자연스럽게 언제 돌아봐야 할지 알 수 있음. 에이전트도 더 나은 훈련으로 그런 직관을 얻게 될지도 모름

  • 2025년 11월 변곡점 이후의 데이터로 갱신된 모습을 보면 좋겠음

답변달기