Claude Code는 당신의 제품을 더 좋게 만들지 않는다: K자형 생산성의 함정

안녕하세요, Tom입니다.

AI 코딩 도구에 관한 포스트를 50개 넘게 써오면서 한 번도 정면으로 다루지 못한 질문이 있었어요. "Claude Code가 정말 제품을 더 좋게 만드나?"라는 질문이에요. 릴리스 노트를 정리하고 기능 변화를 추적하다 보면 어느새 "이 도구가 훌륭하다"는 전제에서 출발하게 되거든요.

그런데 최근 Geeknews에서 이 전제 자체를 정면으로 건드리는 글이 올라왔어요. 제목부터 도발적이에요. "Claude Code는 당신의 제품을 더 좋게 만들지 않는다."

K자형 생산성이란

글에서 제시하는 핵심 개념이 K자형 생산성(K-shaped productivity)이에요.

AI 코딩 에이전트를 도입하면 생산성이 균일하게 올라갈 것 같지만, 실제로는 K자처럼 갈라진다는 거예요. 경험 있는 시니어 개발자는 위쪽 화살표를 탄다. 무엇을 만들지, 어떤 코드를 채택할지, 어디서 멈춰야 하는지 알기 때문에 AI의 속도를 온전히 활용할 수 있어요.

반면 주니어 개발자는 아래쪽 화살표로 향한다는 주장이에요. AI가 만들어주는 코드가 맞는지 판단할 기준이 아직 없고, 피드백 루프 없이 코드만 쌓다 보면 이해 부채가 빠르게 쌓여요. 코드는 늘어나는데 실력은 정체되는 상태가 되는 거예요.

처음 읽었을 때 좀 과하게 비관적인 게 아닌가 싶었어요. 그런데 생각해보면 이건 망치 이야기랑 비슷해요. 망치가 생기면 목수는 더 빠르게 집을 짓지만, 망치 쓰는 법을 배우는 중인 사람은 못을 더 빠르게 잘못 박을 수도 있거든요.

진짜 지표는 코드 줄 수가 아니에요

글에서 가장 인상적이었던 지적은 측정 지표의 문제예요.

"엔지니어당 코드 줄 수" 혹은 "시간당 완료된 태스크 수"로 생산성을 측정하면 AI 코딩 도구는 거의 모든 상황에서 수치를 올려줘요. 그런데 이 지표들이 실제로 제품이 좋아지는 것과 얼마나 상관관계가 있냐는 거예요.

저자가 제안하는 지표는 "엔지니어 한 명이 단위 시간에 제품 개선을 얼마나 만들어내느냐"예요. 제품 개선은 사용자에게 가치를 주는 변화를 의미해요. 버그가 줄었는지, 주요 플로우가 빨라졌는지, 사용자 이탈이 줄었는지.

이 기준으로 보면 AI가 코드를 10배 빠르게 만들어줘도, 그 코드가 제품 개선으로 이어지지 않으면 의미가 없어요. 더 나쁘게는, 더 빠르게 만들어진 잘못된 코드가 나중에 더 큰 기술 부채가 될 수 있다는 거예요.

Linear와 Sentry의 시선

글에는 이미 유명한 두 개의 회의론도 언급돼요. Linear의 Karri Saarinen과 Sentry의 David Cramer가 각자의 채널에서 비슷한 취지의 이야기를 했어요.

Saarinen은 "AI 코딩 도구가 코드를 빨리 만들어주는 건 맞는데, 올바른 것을 만드는 속도를 빠르게 해주지는 않는다"고 했어요. 제품의 방향을 잡는 건 여전히 사람의 판단이라는 거예요.

Cramer는 비용 측면을 짚었어요. AI가 만든 코드는 나중에 유지보수하는 사람이 이해해야 하는데, 그 이해 비용이 생성 속도의 이득을 상쇄할 수 있다는 거예요.

두 사람 모두 AI 코딩 도구를 안 쓴다는 게 아니에요. 도구가 만능이라는 서사를 경계하는 거예요.

독점 우위는 없다

또 하나 흥미로운 지점이에요. Claude Code가 7개월 먼저 출시했지만, 그것이 경쟁자가 따라잡기 어려운 독점적 우위가 됐냐고 물으면 글쓴이는 회의적이에요.

코딩 에이전트 기능 자체는 경쟁자가 빠르게 따라잡을 수 있어요. 진짜 차별화는 그 도구를 쓰는 팀이 만드는 제품 판단력이지, 도구 자체에서 나오지 않는다는 거예요.

저는 이 블로그를 Claude Code로 만들었어요. v2.1.16부터 지금까지 거의 모든 릴리스를 추적했고, 실제로 코드를 짤 때도 Claude Code를 씁니다. 그래서 이 도구가 얼마나 편리한지는 누구보다 잘 알아요.

그런데 동시에, "내가 Claude Code 덕분에 더 좋은 판단을 하게 됐나"라고 물으면 솔직히 아니에요. 더 빠르게 구현하게 됐지, 무엇을 구현할지는 여전히 제 판단이에요.

코드는 자산이 아니에요

글 전체에서 제일 오래 생각하게 만든 문장이에요. "코드는 자산이 아니라 비용이다."

코드가 많다는 건 기능이 많다는 게 아니에요. 유지보수해야 할 것, 이해해야 할 것, 고쳐야 할 것이 늘어난다는 거예요. AI가 코드를 빨리 만들어주면 이 비용이 더 빨리 쌓여요. 코드가 많아진다고 제품이 좋아지는 게 아니고, 오히려 복잡도만 올라갈 수 있다는 거예요.

저자가 표현한 비유가 좋아요. "AI는 누구나 캠리를 만들게 해준다. 하지만 페라리를 만드는 장인을 더 빠르게 만들어주지는 않는다."

더 나쁜 건, 캠리를 기대했는데 더 복잡한 버전의 대중차가 나오는 상황이에요. 요구사항을 정확히 판단하는 능력, 더 단순한 해법을 고르는 절제력, 지금 만들지 말아야 할 것을 알아보는 감각. 이게 시니어 개발자의 진짜 차별화 포인트인데, 이건 AI가 빠르게 해줄 수 없어요.

그래서 Claude Code를 어떻게 써야 하나

저도 이 글을 읽으면서 제 사용 패턴을 돌아봤어요.

저는 Claude Code를 주로 이미 무엇을 만들지 결정한 다음에 구현 속도를 높이는 용도로 써요. "이 기능을 이런 구조로 만들고 싶다"는 방향이 잡힌 다음에 세부 코드를 맡기는 거예요. 이 순서를 지키면 K자의 위쪽에 탈 확률이 올라가요.

반면 "뭔가 만들어줘"처럼 방향 자체를 AI에게 맡기면 나온 결과를 평가하는 기준 자체가 없어져요. 그 상태에서 코드가 빠르게 쌓이면 오히려 문제예요.

참고: AI 코딩 도구의 생산성 효과를 측정할 때 "얼마나 빠르게 코드를 만들었나"보다 "배포 후 실제로 어떤 제품 개선이 일어났나"를 기준으로 쓰는 걸 권해요.

결국 이 글의 결론은 비관적이지 않아요. Claude Code는 좋은 도구예요. 하지만 도구를 잘 쓰는 건 도구 자체가 해주지 않아요. 뭘 만들지 아는 사람에게는 날개가 되고, 모르는 사람에게는 더 빠른 표류가 될 수 있다는 거예요.

---

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