# Claude Code는 당신의 제품을 더 좋게 만들지 않는다 > Clean Markdown view of GeekNews topic #29225. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=29225](https://news.hada.io/topic?id=29225) - GeekNews Markdown: [https://news.hada.io/topic/29225.md](https://news.hada.io/topic/29225.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-05-06T21:02:29+09:00 - Updated: 2026-05-06T21:02:29+09:00 - Original source: [ethanding.substack.com](https://ethanding.substack.com/p/claude-code-is-not-making-your-product) - Points: 1 - Comments: 1 ## Topic Body - 코딩 에이전트의 생산성 효과는 균등하지 않고 **K자형**으로 갈라지며, 핵심 지표는 시간당 코드 줄 수가 아니라 엔지니어 1인당 **제품 개선 속도**가 실제로 높아졌는지에 있음 - [Dax](https://x.com/thdxr/status/2031579270389059978), Karri Saarinen, [David Cramer](https://x.com/zeeg/status/2033680587874308579)는 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](https://x.com/thdxr/status/2031579270389059978), Karri Saarinen, [David Cramer](https://x.com/zeeg/status/2033680587874308579)는 모두 AI 비판자가 아니지만, 코딩 에이전트가 제품 개선 속도를 뚜렷하게 높인다는 확신을 얻지 못하고 있음 - Dax는 [opencode.ai](http://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](http://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 수준으로 가는 데는 매우 유용함 - 최고 수준이 아닌 소프트웨어의 생산 비용은 크게 낮아질 가능성이 큼 - 대신 공장 서까래에 혼란과 부채가 많이 쌓이고, 결국 누군가 이를 치워야 함 ## Comments ### Comment 56952 - Author: neo - Created: 2026-05-06T21:02:29+09:00 - Points: 1 ###### [Lobste.rs 의견들](https://lobste.rs/s/kn0jwm/claude_code_is_not_making_your_product) - **복잡도는 지수적으로 증가**하고, 아마 그보다 더 빠를 수도 있음. 그래서 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월 변곡점** 이후의 데이터로 갱신된 모습을 보면 좋겠음