claude code는 당신의 제품을 더 좋게 만들고 있지 않다

흥미로운 일이 벌어지고 있다. 방 안에서 가장 큰 목소리를 내는 사람들은 ai 코딩 에이전트가 모든 것을 바꿔놓았다고 말한다. 당신이 매일 사용하는 것들을 실제로 만든 엔지니어들은 더 복잡한 이야기를 하고 있다.

트위터 담론으로 가기 전에, 실제 데이터가 있다. 노동경제학자들이 먼저 여기에 도착했다. 코딩 에이전트로 인한 생산성 향상은 고르게 분포하지 않는다. 그것은 k자 형태로 갈라진다. 시니어 엔지니어들은 의미 있게 더 생산적이 되고 있다. 주니어 엔지니어들은 잘해봐야 제자리걸음이다. 최악의 경우, 오히려 더 나빠지고 있다.

경력 단계별 엔지니어링 산출량 · ai 도입 시대커밋 크기의 로그 · 2015년 1분기 – 2025년 1분기

시니어(파란색)는 2023년 llm 변곡점 이후 측정 가능한 산출 증가를 보였다. 주니어 산출(빨간색)은 사실상 정체되었거나 감소했다. k자 형태는 실재한다. 문제는 그것이 무엇을 의미하느냐다.

대중적인 서사는 그 k의 윗부분과 정확히 맞물린다. 벤처 자금을 등에 업은 트위터는 지난 2년 동안 이 차트의 자기 버전을 계속 만들어내고 있다. 이제 그 인용문들은 예측 가능하다.

“우리 팀은 한 분기 만에 6년치 백로그를 비웠다. 모든 PR이 ai 생성이다. 이렇게 빨리 배포한 적이 없다.” — 아무 yc 배치 창업자, 2025년의 아무 달

“나는 cursor를 써서 3일 만에 우리 전체 백엔드를 만들었다. 두 명의 엔지니어가 스무 명의 일을 한다. — 누가 비슷한 버전을 올릴 때마다 늘 4만 개의 좋아요를 받는 그 트윗

“anthropic의 claude code는 완전히 claude-coded다. ai가 ai를 쓴다. 재귀가 현실이다.— dario amodei / anthropic, 반복해서

그리고 공정하게 말하자면, k의 윗부분에는 실제로 무언가가 있다. 에이전트형 코딩은 특정 종류의 작업에서 pull request를 만드는 시간을 줄여준다. 진지한 사람 중에 이를 부정하는 이는 없다. 문제는 시간당 생성된 코드 줄 수가 애초에 측정해야 할 올바른 대상인지다.

엔지니어들이 더 생산적이라면, 엔지니어 1인당 제품이 개선되는 속도는 올라가야 한다

몇 주 전, 며칠 간격으로 세 가지 일이 일어났다. dax(opencode.ai를 만들고 있다)가 자기 팀에 무언가를 보냈다. karri saarinen(linear의 ceo)이 답했다. david cramer(sentry를 맨땅에서 월 1000만 달러까지 키운 사람)가 자신의 github 그래프를 올렸다. 그들 중 누구도 ai 비판론자가 아니다. 그런데 모두가 같은 패턴을 보고 있다.

dax가 자기 팀에 보낸 원문 메시지(좌상단), karri saarinen의 “술 취한 화이트보드” 답글(중앙), david cramer의 생산성 확신 트윗 (우상단), 그리고 왜 에이전트형 엔지니어링이 비대화를 만드는지 정확히 분석한 cramer의 후속 스레드.

David Cramer@zeeg im fully convinced that LLMs are not an actual net productivity boost (today) they remove the barrier to get started, but they create increasingly complex software which does not appear to be maintainable so far, in my situations, they appear to slow down long term velocity 11:03 PM · Mar 16, 2026 · 671K Views 463 Replies · 225 Reposts · 3.51K Likes cramer의 후속 글은 전체를 읽어볼 가치가 있다. 그는 특히 “복잡성이 있는 점진적 개발에서 LLM의 저조한 성능”, “LLM이 진정으로 단순화하고 관용적인 인터페이스를 만들지 못하는 무능력”, 그리고 “그들이 자주 따르는 순도 높은 slop 테스트 생성 기법”을 지적한다. 그의 요약은 이렇다. “대부분은 그냥 비대화다.”

이들은 러다이트가 아니다. dax는 말 그대로 코딩 에이전트를 만들고 있다. karri는 linear를 만들었다. 그 제품은 소프트웨어 도구에서 적을수록 좋다는 철학을 중심에 두고 설계되어 있다. cramer는 20년 동안 오픈소스 소프트웨어를 배포해 왔고, 누구보다도 커밋 그래프를 잘 읽는다.

그런데 그들 모두는 코딩 에이전트로 인해 자기 제품 개선 속도가 가속하는 것을 체감하기 어렵다고 말하고 있다.

dax@thdxr us: we are struggling to figure out the best way to use coding agents, we don't have clarity yet everyone else: our team is moving at speeds unheard of, all our PRs are ai generated, we've cleared 6 years of backlog man we must really suck huh 3:53 AM · Mar 11, 2026 · 184K Views 166 Replies · 104 Reposts · 3.09K Likes claude code 자체를 생각해보자. claude code는 완전히 claude-coded다. 고리가 닫혔다. 기계가 기계를 쓰고 있다…

이 말은 곧, 제품이 개선되는 속도 자체가 가속해야 한다는 뜻이다.

그리고 그것이 사실이라면, 특정한 함의를 가진다. 엔지니어링 생산성은 복리 함수다. claude code를 쓰는 것이 제품을 개선하는 속도에 겨우 1.5배의 향상만 줘도, 첫날부터 그것을 쓴 팀은 다른 모두를 멀찌감치 따돌리고 있어야 한다. 격차는 분기마다 더 벌어져야 한다. 그림으로는 이렇게 보여야 한다.

source: y = e^(c*x)

하지만 현실은 그렇지 않다. 현실에서는 codex가 claude code보다 몇 달 뒤에 출시됐는데도 이미 기능적으로 경쟁 가능하다. cursor의 딜 흐름은 강하다. cognition과 factory도 여전히 굵직한 엔터프라이즈 계약을 따내고 있다. 실제 그림은 이렇다.

source: i made up the vibes

반증: claude code를 쓰는 것이 진짜 제품 속도 우위를 준다면, 그리고 anthropic이 그것을 7개월 동안 독점적으로 가졌다면, claude code와 모든 경쟁자 사이의 격차는 메울 수 없을 정도여야 한다. codex는 존재감이 없어야 한다. 그런데 실제로는 사람들이 여전히 어느 쪽이 더 나은지 활발히 논쟁하고 있다. 복리 우위가 나타나지 않고 있다. 제품 품질을 막는 다른 병목이 있으며, 그것은 애초에 코드가 아니었다.

진지하게 받아들일 만한 반론도 몇 가지 있다. 어쩌면 그 이득은 존재하지만 복잡성 부채가 다 잡아먹고 있을 수도 있다. 어쩌면 anthropic의 엔지니어링 팀이 너무 커서 엔지니어 1인당 한계 이득이 희석될 수도 있다. 하지만 오히려 그런 반론들이 원래의 요점을 증명한다. 세계 최고의 코딩 에이전트가 있어도 병목은 코드 생산이 아니다. 더 어려운 무언가다.

이 분야에 관해 글을 쓰는 대부분의 사람들이 놓치고 있는 멘털 모델이 여기 있다. 그리고 나는 이 생태계 전체의 토큰 경제성이 맞아떨어지지 않는다는 점에 대해 최근 글을 쓴 사람으로서 이 말을 한다. 문제는 단지 재정적인 것이 아니라 개념적인 것이다. 우리는 소프트웨어 엔지니어링이 실제로 무엇을 최적화하는지 오해해 왔다.

최고의 엔지니어링 문화는 코드 줄 수를 생산하는 것이 아니라 소비하는 것으로 취급한다. 중요한 기능에 그것을 쓴다. 중요하지 않은 기능에는 쓰지 않으려 한다. 코드베이스는 자산이 아니라 대차대조표상의 부채다.

tinychat(comma.ai의 소프트웨어 자회사)는 코드베이스가 일정 크기를 넘으면 울리는 알람으로 유명했다. 그들은 삭제된 코드를 축하했다. 소프트웨어가 실제로 무엇인지 이해하면 그 이유는 단순하다. 모든 줄은 버그가 생길 표면이다. 모든 함수는 다음 함수의 의존성이다. 모든 기능은 이웃을 만들어낸다.

제품 표면적은 프랙탈처럼 확장된다. slack 연동을 추가하면 teams 연동이 필요해지고, 그다음에는 이메일 폴백이 필요해진다. 알림을 추가하면 모바일, sms, 엔터프라이즈 mdm 정책을 위해 다시 만들어야 한다. mfa 지원을 넣으면 duo, okta, saml과 호환되어야 한다. 복잡성은 선형적으로 확장되지 않는다. 복리처럼 누적된다.

linear는 차트의 우상단 사분면에 있으면서 가장 작은 버블을 가지고 있다. 직원 178명, 설립 6년, arr 1억 달러다. jira는 누적 엔지니어링 투입이 56배 더 많지만 소비자 품질 점수는 6점 더 낮다. 버블 크기 자체가 핵심이다. 품질과 코드베이스의 질량은 같은 것이 아니다.

엔지니어가 10만 명인 facebook은 UI 코드를 얼마나 빨리 생산할 수 있는지 때문에 막히지 않는다. 유능한 엔지니어라면 하루 만에 facebook 피드를 목업할 수 있다. 실제 제약은 어떤 부하와 어떤 지연 시간 아래에서도, 업타임을 유지하면서, 수십억 명에게 그 경험을 전달하는 데 필요한 코드 줄 수를 줄이는 것이다. 보상 함수는 생산이 아니라 압축이다. 그런 종류의 워크로드에서는 코딩 에이전트가 장기적 트레이드오프를 평가할 수 없다. 시스템에 대한 이론이 없기 때문이다.

이 주장에는 아직 아무도 제대로 말로 정리하지 못한 마지막 층위가 하나 더 있다. 최전선에서의 제품 품질 개선은 코드를 얼마나 빨리 쓸 수 있는가에 의해 제한되지 않는다. 최전선을 밀어낼 만큼 좋은 아이디어를 얼마나 빨리 떠올릴 수 있는가에 의해 제한된다.

jira도 꽤 합리적으로 잘 설계되어 있다. jira와 linear의 차이는 linear가 더 나은 상자를 그렸기 때문이 아니다. 프로젝트 관리 소프트웨어가 어떤 느낌이어야 하는지에 대한 구체적인 창조적 비전이 누군가에게 있었고, 그 비전을 수년에 걸쳐 절제하면서 실행했기 때문이다. 그런 종류의 제품 품질은 토큰 처리량에서 나오지 않는다. 그것은 감각에서 나온다. 덜 만들겠다는 결정에서 나온다.

“좋은 소프트웨어가 어떤 느낌인지”의 최전선을 밀어낼 수 있는 제품 비전가는 누구나 인정하고 싶어 하는 것보다 훨씬 희귀하다. 곡선의 가장자리에 놓인 아이디어는 백로그를 질주해서 나오지 않는다. dax가 자기 팀에 “우리는 만족을 지연하는 능력을 잃고 있다”고 경고할 때 말하는, 느리고 불편한 사고에서 나온다.

이것이 또한 “6년치 백로그를 비웠다”는 주장이 들리는 것만큼 인상적이지 않은 이유다. CRUD 기능과 내부 도구로 가득 찬 백로그는 정확히 코딩 에이전트가 가속하는 종류의 일이다. 그리고 동시에, 그것은 정확히 최전선을 밀어내지 않는 종류의 일이기도 하다. 더 빨리 배포했다고 해서 당신의 제품이 더 좋아지는 것은 아니다. 당신의 제품은 당신이 배포한 무언가가 사용자로 하여금 더 크게 신경 쓰게 만들었을 때 더 좋아진다.

↑ ai 코딩 에이전트는 실제로 도움을 준다. 0에서 1로 가는 제품이 품질의 최전선에 더 빨리 도달하도록 돕는다. 최초의 작동 버전까지 걸리는 시간을 줄여준다. 초기 단계 작업에서는 그 속도가 진짜다.

↑ 하지만 대가가 있다: 그것들은 당신의 원을 더 크게 만든다. 코드베이스는 품질보다 더 빨리 커진다. 기술 부채는 복리처럼 쌓인다. 당신은 나중에 갚을 돈으로 지금 속도를 사고 있다.

그렇다면 이 모든 것의 실제 결론은 무엇일까? 내가 claude code가 돈을 내고 쓸 가치가 없다고 생각하느냐고? 음, 그건 스택의 어디에 있느냐에 달려 있다.

• 당신이 최전선에 있다면, 병목은 코딩 에이전트가 아니라 감각을 가진 사람들이다. linear와 sentry 같은 회사들이 보여주는 “덜어내는 감각을 통해 최고가 되는 상태”는 특정한 사람들 안에 있다. linear의 nan yu. 그리고 손발이 맞는 소수 팀이 sr-71을 만든 skunk works의 kelly johnson. 그 항공기는 지금도, 60년이 지난 오늘까지도, 역사상 가장 빠른 공기흡입식 유인 항공기다. blackbird가 빨랐던 것은 johnson의 팀이 더 많은 설계도를 만들었기 때문이 아니다. johnson에게 무엇을 빼야 하는지에 대한 이론이 있었기 때문이다. 삭제하고, 압축하고, 거부하는 감각은 어떤 최전선 모델의 로드맵에도 없다. 오히려 그 아래 바닥이 올라가고 있는 지금, 그것은 더 가치 있어진다.

• 당신이 이미 최전선에 있다면, 연구개발 급여를 토큰 지출로 두 배로 늘리는 것이 과연 경제적 가치를 전혀 만들어내는지조차 분명하지 않다. 예를 들어 ramp를 보자. 그들의 엔지니어들은 지난 1년 동안 토큰 지출로 사실상 급여의 두 배를 쓰고 있다고 전해진다. 제품으로서의 ramp가 더 좋아졌는가? 도대체 그걸 어떻게 알 수 있을까? 이미 #1일 때는 승률이 거의 고정되어 있다. #1에서 “더 큰 격차의 #1”로 가는 것은 측정하기가 꽤 어렵다. 내 생각을 바꾸려면 ramp의 승률이나 손익 데이터를 봐야겠지만, 행복한 ramp 고객인 나로서는 오늘과 작년 사이의 차이를 진심으로 느낄 수 없다.

• claude code는 누구나 쉽게 camry 경쟁작을 만들게 도와준다. ferrari의 장인들이 더 빠른 ferrari를 만들도록 도와주지는 않는다. 하지만 당신이 0에서 camry로 가는 중이라면, 그것은 엄청나게 도움이 될 것이다.

  • 이것은 camry들의 비용을 끌어내릴 것이다. 최고 중의 최고가 만든 것이 아닌 소프트웨어는 이제 극적으로 더 저렴해질 것이다.

  • 그 대가로 공장 서까래 위에 엄청난 혼란과 부채가 쌓이게 된다. 결국 누군가는 그 서까래를 청소해야 한다.

Mark Hay, Nan Yu, & Nikunj Kothari에게 감사

더 읽기