'AI 덕분에 개발 생산성이 10배가 됐다'는 이야기, 요즘 정말 많이 들리죠. 그런데 한 개발자가 2026년 현재 LLM으로 코딩하는 현실을 솔직하게 정리한 글을 내놨어요. 결론은 도발적이지만 공감 가는 한 줄이에요. '10배가 아니라 2배다.' AI 코딩 도구를 대충 써보고 실망한 사람이 아니라, 진지하게 잘 쓰는 사람이 내린 결론이라는 점에서 곱씹어볼 가치가 있는데요. 그리고 이 글의 진짜 메시지는 '2배면 엄청난 거다'라는 거예요.
왜 10배가 안 나올까요
핵심 논리는 암달의 법칙(Amdahl's Law)이에요. 이게 뭐냐면, 전체 작업 중 일부만 빨라지면 전체 속도 향상에는 한계가 있다는 법칙이거든요. 개발자의 하루를 떠올려보세요. 코드를 '타이핑'하는 시간이 실제로 얼마나 되나요? 요구사항을 이해하고, 기존 코드를 읽고, 설계를 고민하고, 동료와 논의하고, 디버깅하고, 리뷰하는 시간이 훨씬 길죠. LLM이 코드 작성 자체를 5배, 10배 빠르게 해줘도 그게 전체 업무의 30~40%라면, 체감 생산성은 잘해야 2배 언저리에서 멈춘다는 계산이 나와요. 애초에 타이핑 속도는 소프트웨어 개발의 병목이 아니었던 거죠.
게다가 LLM이 짠 코드는 공짜가 아니에요. 검증이라는 새로운 비용이 생기거든요. 그럴듯하게 생겼지만 미묘하게 틀린 코드를 걸러내려면 결국 사람이 읽고 이해해야 하고, 이 리뷰 부담이 커지면 절약한 시간을 도로 뱉어내게 돼요. 실제로 METR이라는 연구기관이 숙련된 오픈소스 개발자들을 대상으로 진행한 실험에서는, AI 도구를 쓴 쪽이 오히려 19% 느려졌는데 정작 본인들은 빨라졌다고 느꼈다는 결과도 있었어요. 체감과 실측이 다를 수 있다는 무서운 이야기죠.
그럼 어디서 2배가 나오냐면
그렇다고 LLM이 과대평가만 됐다는 얘기는 아니에요. 잘 먹히는 영역은 확실하거든요. 보일러플레이트 코드, 처음 써보는 라이브러리나 API 탐색, 테스트 코드 작성, 일회성 스크립트, 낯선 언어로의 포팅 같은 것들이요. 이런 작업에서는 진짜로 10배 빠를 때도 있어요. 반대로 맥락이 깊은 레거시 코드베이스, 미묘한 설계 판단, 도메인 지식이 필요한 비즈니스 로직에서는 이득이 급격히 줄어들어요. 결국 어떤 일에 쓰고 어떤 일에 안 쓸지를 판단하는 감각이 생산성을 가르는 거예요. 같은 도구를 쓰는데 누구는 2배가 되고 누구는 오히려 느려지는 이유가 여기에 있어요.
그래도 2배는 혁명이에요
여기서 관점을 하나 바꿔볼 필요가 있어요. 소프트웨어 공학 역사에서 '은탄환은 없다'는 말이 나온 이래로, 생산성을 단번에 2배 올려준 단일 도구는 거의 없었거든요. 고수준 언어, IDE, 오픈소스 생태계 같은 거대한 변화들이 수십 년에 걸쳐 만들어낸 수준의 향상이에요. 그걸 도구 하나가 몇 년 만에 해냈다면 그 자체로 역사적인 사건인 거죠. '10배' 마케팅에 실망해서 '역시 별거 없네'로 돌아서는 것도, 반대로 검증 없이 AI 코드를 그대로 밀어 넣는 것도 둘 다 함정이에요.
한국 개발자에게 주는 시사점도 분명해요. 회사에서 'AI 도입했으니 인력 절반으로 같은 아웃풋을 내라'는 식의 기대가 내려오기 시작했잖아요. 이 글은 그런 기대에 근거를 갖고 반박할 수 있는 좋은 재료예요. 현실적인 목표는 '검증 가능한 2배'이고, 그것만으로도 충분히 크다는 것. 개인 차원에서는 LLM에 맡길 작업과 직접 할 작업을 가르는 자기만의 기준을 만들고, AI가 짠 코드를 빠르게 검증하는 능력, 그러니까 테스트 설계와 코드 리딩 실력을 기르는 게 앞으로의 핵심 역량이 될 거예요.
요약하면, LLM 코딩의 현실적인 성과는 10배가 아니라 2배이고, 그 2배도 아무에게나 주어지는 게 아니라는 이야기예요. 여러분의 체감 배율은 얼마인가요? 어떤 작업에서 가장 큰 이득을 보고 계신가요?
🔗 출처: Hacker News