원문: Writing Code Was Never The Bottleneck - ordep.dev

저자: @ordepdev (트위터), 2025년 6월 30일


수년간 저는 소프트웨어 엔지니어링에서 코드 작성 자체가 병목이 아니라고 느껴왔습니다.

실제 병목은 코드 리뷰, 멘토링 및 페어링을 통한 지식 전달, 테스트, 디버깅, 그리고 조율과 소통에 드는 인적 오버헤드였습니다. 이 모든 것은 티켓, 계획 회의, 애자일 의식이라는 미로 속에 얽혀 있습니다.

품질 향상을 위한 이 과정들은 생각, 공유된 이해, 그리고 건전한 판단을 요구하기 때문에 코드 작성 자체보다 우리를 더 지연시키는 경우가 많습니다.

이제 LLM(대규모 언어 모델)이 작동하는 코드를 그 어느 때보다 쉽게 생성하게 되면서, 코드 작성이 병목이었고 우리가 마침내 이를 해결했다는 새로운 이야기가 등장했습니다.

하지만 그것은 현실과 다릅니다.

특히 LLM 덕분에 새로운 소프트웨어를 추가하는 한계 비용은 0에 가까워지고 있습니다. 하지만 그 코드를 이해하고, 테스트하고, 신뢰하는 데 드는 비용은 얼마일까요? 그 어느 때보다 높습니다.


LLM은 작업 부하를 이동시킬 뿐, 제거하지 않습니다.

Claude와 같은 도구는 초기 구현 속도를 높일 수 있습니다. 하지만 그 결과는 종종 시스템을 통해 더 많은 코드가 흐르게 하고, 이를 검토하고 통합하며 유지보수하는 사람들에게 더 많은 압력을 가하게 됩니다.

다음의 경우에 특히 명확해집니다:

  • 작성자가 제출한 내용을 완전히 이해하고 있는지 불분명할 때.

  • 생성된 코드가 익숙하지 않은 패턴을 도입하거나 기존의 관례를 깰 때.

  • 엣지 케이스와 의도치 않은 부작용이 명확하지 않을 때.

우리는 코드를 생산하기는 더 간단하지만 검증하기는 더 복잡한 상황에 처하게 되며, 이는 팀 전체의 속도를 반드시 빠르게 하지는 않습니다.

이것은 새로운 도전이 아닙니다. 개발자들은 오랫동안 “복사-붙여넣기 엔지니어링“에 대해 농담해왔지만, LLM이 가능하게 한 속도와 규모는 이러한 복사-붙여넣기 습관을 증폭시켰습니다.


코드 이해는 여전히 어려운 부분입니다.

“코드의 가장 큰 비용은 이해하는 것이다 - 작성하는 것이 아니라.”

LLM은 코드를 생산하는 데 걸리는 시간을 줄여주지만, 동작을 추론하고, 미묘한 버그를 식별하며, 장기적인 유지보수성을 보장하는 데 필요한 노력의 양은 변하지 않았습니다. 검토자들이 생성된 코드와 직접 작성된 코드를 구별하거나 특정 솔루션이 선택된 이유를 이해하는 데 어려움을 겪을 때, 그 작업은 훨씬 더 어려워질 수 있습니다.


팀은 여전히 신뢰와 공유된 맥락에 의존합니다.

소프트웨어 엔지니어링은 항상 협업적이었습니다. 이는 공유된 이해, 정렬, 그리고 멘토링에 달려 있습니다. 그러나 코드가 논의되거나 검토될 수 있는 속도보다 빠르게 생성될 때, 팀은 품질이 보장되기보다는 가정되는 모드에 빠질 위험이 있습니다. 이는 검토자와 멘토에게 스트레스를 주어 미묘한 방식으로 일을 지연시킬 수 있습니다.


LLM은 강력하지만, 근본적인 문제를 해결하지는 않습니다.

더 빠른 프로토타이핑, 스캐폴딩, 자동화에는 진정한 가치가 있습니다. 하지만 LLM은 명확한 사고, 신중한 검토, 그리고 사려 깊은 설계의 필요성을 없애지 않습니다. 오히려 더 많은 코드가 생성될수록 이러한 요소들은 더욱 중요해집니다.

네, 코드 작성 비용은 실제로 줄어들었습니다. 하지만 팀으로서 코드를 함께 이해하는 데 드는 비용은 줄어들지 않았습니다.

그것이 여전히 병목입니다. 아닌 척하지 맙시다.