대규모 언어 모델 코딩에 대한 회의적 시각을 이론과 실증 자료를 바탕으로 검토하며, 소프트웨어 개발의 핵심 병목은 코드 생성 속도가 아니라 명세, 설계, 검증, 통합에 있다고 주장하는 글.
우리 모두가 지금 무언가 한가운데에 있다는 데에는 대체로 동의하는 듯하지만, 정확히 그것이 무엇인지는 논쟁의 대상인 것 같습니다. 이것은 생산성과 역량에서 전례 없는 혁명일 수도 있고, 어쩌면 세계가 어떤 모습일지 추측조차 불가능해지는 기술적 “특이점”의 전조일 수도 있습니다. 그저 또 하나의 허황된 과대광고 주기였다가 지나가 버릴 수도 있습니다. 닷컴 버블처럼 큰 붕괴를 낳지만 여전히 유용한 무언가를 남길 버블일 수도 있습니다(닷컴 버블이 웹의 대중적 채택을 밀어붙인 것처럼 말입니다). 혹은 그 어느 것도 아닐 수도 있습니다.
이런 입장들의 변주를 두고 이미 수많은 글이 쓰였습니다. 그러니 당연히 오늘 저는 여기에 수천 단어를 조금 더 보태려 합니다. 블로그란 원래 그런 데 쓰라고 있는 법이니까요. 적어도 여기서 읽게 될 모든 문장은 제가 직접 쓴 것입니다(그리고 제 em-dash는 차가운 제 손에서나 빼앗아 가시길).
하지만 먼저, 짧게 몇 가지를 말해 두겠습니다.
이 글에서는 거의 전적으로 “LLM”과 “LLMs”라는 용어를 사용할 생각입니다. 저는 이런 정밀성이 유용하다고 보기 때문입니다. “AI”는 모호하고 과도하게 많은 의미를 짊어진 용어이며, 누군가가 정확히 무엇을 “AI”라고 뜻하는지를 두고 말장난과 논쟁에 빠지기 너무 쉽습니다. 그리고 지금 프로그래밍과 “AI”를 둘러싸고 논쟁적인 거의 모든 것은 실제로는 대규모 언어 모델의 등장에 직접적으로 연결됩니다. 물론 “GPT”라고 말하면 조금 더 정확할지도 모르겠습니다. 하지만 OpenAI는 그 표현을 자기들만의 전용 용어처럼 만들려 계속 시도하고 있고, 그것은 또 다른 종류의 반갑지 않은 짐입니다. 그러니 “LLMs”로 하겠습니다.
그리고 제가 “LLM 코딩”이라고 말할 때는, 어떤 프로그래밍 언어의 코드를 생성하기 위해 LLM을 사용하는 것을 뜻합니다. 저는 이것을 그런 모든 사용을 포괄하는 상위 개념으로 씁니다. 인간의 감독하에 이뤄지든 아니든, 코드의 유일한 생산자로 쓰이든(인간이 생성한 코드가 전혀 없든) 아니든 모두 포함합니다.
또한 여기서는 기술 자체와 프로그래밍이라는 직업에 직접 관련된 것들로 논의를 제한하려고 합니다. 그게 제가 아는 분야이기 때문입니다(저는 철학 학위도 있으니 LLM의 다른 측면들에 대해서도 코멘트할 자격은 있겠지만, 이번 글에서는 의도적으로 거기서 멀어지려 합니다. 그런 논쟁들 중 상당수가 지루하고, 문자 그대로 학부 2학년스럽다고 느끼기 때문입니다. 실제로 제가 학부 2학년 때 읽고 토론하던 것들을 떠올리게 합니다).
당신이 다른 분야에서 LLM을 쓰고 있다면, 저는 아마 그 분야를 충분히 잘 알지 못해서 유익한 말을 하기 어려울 것입니다. 이 원칙을 따르지 않은 사람들의 정말 뜨거운 의견들을 몇 번 보고 나니, “LLM”과 “Gell-Mann Amnesia”를 합친 귀여운 합성어라도 하나 필요하다는 생각을 여러 번 했습니다. LLM 관련 담론의 상당수가 자기 분야만 빼고는 모든 직업과 영역을 LLM이 접수할 거라고 기대하는 사람들처럼 보이기 때문입니다.
몇 해 전 저는 Fred Brooks의 _No Silver Bullet_에 대해 글을 쓴 적이 있고, 그것이 Brooks가 쓴 것 중 최고일지도 모른다고 말했습니다. _No Silver Bullet_을 아직 읽어보지 않았다면 꼭 읽어보시길 강력히 권합니다. 그리고 요약본이 아니라 전체를 직접 읽어보시길 권합니다.
_No Silver Bullet_은 컴퓨팅 하드웨어가 놀라운 속도로 발전하던 시기에 발표되었지만, 소프트웨어를 만드는 우리의 능력은 그 속도를 전혀 따라가지 못하던 때의 글입니다. 그래서 Brooks는 소프트웨어에 대해 대담한 예측을 했습니다.
There is no single development, in either technology or management technique, which by itself promises even a single order-of-magnitude improvement within a decade in productivity, in reliability, in simplicity.
이를 뒷받침하기 위해 그는 소프트웨어 개발의 어려움의 원천들을 살펴보고, 그것들을 두 개의 큰 범주로 나누었습니다(강조는 원문 그대로입니다).
Following Aristotle, I divide them into essence—the difficulties inherent in the nature of the software—and accidents—those difficulties that today attend its production but that are not inherent.
고전적인 예로 메모리 관리가 있습니다. 어떤 프로그래밍 언어는 프로그래머가 메모리를 수동으로 할당하고, 추적하고, 해제하도록 요구하는데, 이것은 어려움의 원천입니다. 그리고 이것은 우연적 어려움입니다. 본질적으로 그렇게 해야 할 이유는 없기 때문입니다. 다른 많은 프로그래밍 언어들은 자동 메모리 관리를 제공합니다.
하지만 어려움의 다른 원천들은 다르며, 소프트웨어 개발 그 자체에 내재한 것처럼 보입니다. Brooks가 이를 요약하는 방식 중 하나는 다음과 같습니다(강조는 제가 가진 No Silver Bullet 사본과 같습니다).
The essence of a software entity is a construct of interlocking concepts: data sets, relationships among data items, algorithms, and invocations of functions. This essence is abstract, in that the conceptual construct is the same under many different representations. It is nonetheless highly precise and richly detailed.
I believe the hard part of building software to be the specification, design, and testing of this conceptual construct, not the labor of representing it and testing the fidelity of the representation. We still make syntax errors, to be sure; but they are fuzz compared to the conceptual errors in most systems.
If this is true, building software will always be hard. There is inherently no silver bullet.
그리고 그는 우연적 어려움만 해결했을 때 수익이 체감하는 이유도 설명합니다.
How much of what software engineers now do is still devoted to the accidental, as opposed to the essential? Unless it is more than 9/10 of all effort, shrinking all the accidental activities to zero time will not give an order of magnitude improvement.
이것은 간단한 수학적 논증입니다. 그 두 개의 경험적 전제—우연적/본질적 구분이 실제로 존재한다는 것, 그리고 오늘날 남아 있는 우연적 어려움이 전체의 90% 이상을 차지하지는 않는다는 것—이 참이라면, 우연적 어려움을 줄이는 것만으로는 한 자릿수 차원을 넘는 개선을 얻을 수 없다는 결론은 자동으로 따라옵니다.
제 생각에 대부분의 프로그래머는 적어도 암묵적으로는 첫 번째 전제를 믿습니다. 그리고 첫 번째 전제를 받아들이고 나면, 두 번째 전제에 반대하기는 매우 어려워집니다. 사실 저는 개인적으로 Brooks의 논증에 필요한 최소한보다 더 나아가고 싶습니다. 그의 수학은 우연적 어려움이 90% 이상에 이르지 않는 한 성립합니다. 왜냐하면 그보다 낮으면 우연적 어려움을 제거해도 10x 개선은 불가능하기 때문입니다. 하지만 제 추측으로는 오늘날 우연적 어려움은 전체에서 그보다 훨씬 더 작은 비중을 차지합니다. 성숙한 프로그래밍 영역들에서는 남아 있는 우연적 어려움을 완전히 제거한다고 해도 생산성이 두 배조차 되지 않을 것 같아도 저는 놀라지 않을 것입니다.
_No Silver Bullet_에는 잠재적인 “hopes for the silver”를 다루는 부분도 있고, 거기서는 “AI”도 언급합니다. 다만 Brooks가 “AI”라고 보았던 것(그리고 그 용어가 정확히 무엇을 뜻하는지 분명히 하는 곁가지 논의도 있습니다)은 오늘날 “AI”라는 이름으로 홍보되는 것과는 상당히 달랐습니다. _No Silver Bullet_에서 LLM에 가장 적절하게 대응되는 비교 대상은 사실 “AI” 논의가 아니라 _automatic programming_에 대한 논의입니다. 이 표현은 세월 동안 많은 다른 뜻으로 쓰였지만, 당시 Brooks는 이것을 “문제 명세의 진술로부터 그 문제를 해결하는 프로그램을 생성하는 것”으로 정의했습니다. 이것이야말로 현재 LLM이 프로그래머들에게 가장 강하게 홍보되는 바로 그 작업입니다.
하지만 Brooks는 이 주제에 대해 David Parnas의 말을 인용합니다. “automatic programming always has been a euphemism for programming with a higher-level language than was presently available to the programmer.” 그리고 Brooks는 고급 언어만으로는 은탄환이 될 수 없다고 보았습니다. Ada 언어를 논의하는 대목에서 그는 이렇게 말합니다.
It is, after all, just another high-level language, and the biggest payoff from such languages came from the first transition, up from the accidental complexities of the machine into the more abstract statement of step-by-step solutions. Once those accidents have been removed, the remaining ones are smaller, and the payoff from their removal will surely be less.
오늘날 많은 사람들이 LLM을 소프트웨어 개발의 혁명적 도약으로 홍보하고 있지만, 거의 전적으로 LLM이 코드를 빠르게 생성할 수 있다는 주장에 근거하고 있습니다. _No Silver Bullet_의 논증은 이런 주장에 문제를 제기합니다. 단지 코드를 더 빨리 생성하는 것만으로 우리가 얼마나 많은 이득을 얻을 수 있는지 상한을 설정하기 때문입니다.
Brooks는 The Mythical Man-Month 2장에서 일정 계획의 지침으로 “소프트웨어 작업” 시간의 5/6(83%)이 코딩 이외의 것들에 쓰일 것이라고 제안했는데, 이는 코딩만 빨라졌을 때 얻을 수 있는 생산성 향상 상한을 꽤 낮게 만듭니다. 그리고 LLM이 코딩 시간을 0으로 줄인다고 가정하고, 단일한 발전으로는 한 자릿수 차원을 넘는 개선은 없을 것이라고 예측하는 _No Silver Bullet_의 좀 더 관대한 공식화로 가더라도, 그것은 여전히 Brooks 자신이 뛰어난 인간 프로그래머를 고용함으로써 얻을 수 있다고 믿었던 개선보다 작습니다. The Mythical Man-Month 3장에서:
Programming managers have long recognized wide productivity variations between good programmers and poor ones. But the actual measured magnitudes have astounded all of us. In one of their studies, Sackman, Erikson, and Grant were measuring performances of a group of experienced programmers. Within just this group the ratios between best and worst performances averaged about 10:1 on productivity measurements and an amazing 5:1 on program speed and space measurements!
(개인적으로 저는 “10x 프로그래머” 개념에는 회의적이지만, 소프트웨어 업계 전체는 대체로 그것을 사실로 받아들이는 듯합니다)
이제 일화 시간입니다. 제가 직업 프로그래머로서 경력 동안 많이 해온 일은 데이터베이스 기반 웹 애플리케이션과 서비스를 만드는 것이고, 저는 LLM에서 큰 이득을 보지 못합니다. 이 프로그래밍 분야에 익숙하지 않다면, 다루고 싶은 데이터에 대한 설명만으로 애플리케이션 전체의 뼈대와 기본적인 create/retrieve/update/delete HTTP 핸들러를 자동 생성하는 것이 인상적으로 보일 수는 있습니다. 하지만 그런 능력은 LLM 이전에도 있었습니다. 예를 들어 Rails의 scaffolding은 20년 전에도 그걸 할 수 있었습니다.
그리고 단지 원시적인 코드 생성뿐 아니라, 작업에 사용할 수 있는 추상화도 크게 발전해서, 저는 사실상 코드 생산의 순수한 속도가 저를 막고 있다고 느낀 적이 거의 없습니다. Fred Brooks가 예측했을 법하게도, 제 시간의 대부분은 다른 곳에 쓰입니다. 새 소프트웨어를 원하는 사람들(혹은 기존 소프트웨어의 변경을 원하는 사람들)과 대화하기, 그들이 무엇을 원하고 필요로 하는지 알아내기, 초기 명세를 만들기, 그것을 프로그래머들(어쩌면 저, 어쩌면 다른 사람들)이 작업할 수 있도록 적절한 크기의 조각들로 나누기, 첫 프로토타입을 시험하고 피드백을 받기, 다음 반복을 준비하기, 리뷰하거나 리뷰를 요청하기 등입니다. 개인적으로 그것이 Brooks의 5/6 추정과 정확히 맞는지 추적해 보진 않았지만, 맞는다고 해도 전혀 놀랍지 않을 것입니다.
이 모든 점을 고려하면, 단지 LLM이 제가 직접 썼을 때보다 더 빨리 코드를 쏟아내는 것만으로는 저에게 한 자릿수 차원을 넘는 개선은 물론, 그 비슷한 것도 주지 못합니다. 혹은 최근 Tailscale CEO가 쓴 인기 블로그 글의 표현을 빌리면:
AI’s direct impact on this problem is minimal. Okay, so Claude can code it in 3 minutes instead of 30? That’s super, Claude, great work.
Now you either get to spend 27 minutes reviewing the code yourself in a back-and-forth loop with the AI (this is actually kinda fun); or you save 27 minutes and submit unverified code to the code reviewer, who will still take 5 hours like before, but who will now be mad that you’re making them read the slop that you were too lazy to read yourself. Little of value was gained.
더 간단히 말해, 리뷰 큐가 예전과 같은 속도로만 비워진다면, 그 큐에 패치를 더 많이 던져 넣는다고 속도가 빨라지지는 않습니다. 실제 소프트웨어 개발에는 리뷰 큐뿐 아니라 제가 위에서 개괄한 다른 단계와 과정들이 있으며, 또 그 외의 것도 더 있습니다. LLM이 코드를 더 빨리 생성한다고 해서 다른 모든 것들의 속도나 처리량이 같이 늘어나지는 않습니다.
그래서 _No Silver Bullet_의 Brooks 논증을 받아들이는 사람으로서, 저는 이론적 근거만으로도 LLM이 “even a single order-of-magnitude improvement … in productivity, in reliability, in simplicity”를 제공할 수 없다고 믿을 수밖에 없습니다. 그리고 제 개인적 경험도 이 예측과 일치합니다.
하지만 이론은 이쯤 하고, 실제 현실의 LLM 코딩은 어떨까요?
코딩을 위한 LLM의 모든 팬은 그 혁명적 성격에 대한 일화를 하나씩 갖고 있지만, 우리가 가진 비일화적 데이터는 훨씬 더 엇갈립니다. 예를 들어 저는 여러 번 “State of AI-assisted Software Development”에 관한 DORA 보고서를 읽어 보라는 요청과 링크를 받았습니다. 처음에는 확실히 LLM의 효과가 이미 결론났고, 그것도 LLM 쪽 승리라고 선언하는 것처럼 보입니다. 집행 요약문(page 3)에서:
[T]he central question for technology leaders is no longer if they should adopt AI, but how to realize its value.
다른 곳에서는(page 34) “AI is the new normal in software development” 같은 주장도 합니다.
하지만 다시 집행 요약문으로 돌아가 보면, 이야기는 그렇게 일관되게 긍정적이지만은 않게 들리기 시작합니다.
The research reveals a critical truth: AI’s primary role in software development is that of an amplifier. It magnifies the strengths of high-performing organizations and the dysfunctions of struggling ones.
그리고 이어서(page 3):
The greatest returns on AI investment come not from the tools themselves, but from a strategic focus on the underlying organizational system: the quality of the internal platform, the clarity of workflows, and the alignment of teams. Without this foundation, AI creates localized pockets of productivity that are often lost to downstream chaos.
계속해서 page 4에서는:
AI adoption now improves software delivery throughput, a key shift from last year. However, it still increases delivery instability. This suggests that while teams are adapting for speed, their underlying systems have not yet evolved to safely manage AI-accelerated development.
“Delivery instability”는(page 13) 두 가지 요인으로 정의됩니다.
보고서 후반부는 이것을 더 자세히 다룹니다. 예를 들어 page 38에는 delivery instability 증가를 보여 주는 차트가 있습니다. 그리고 그 차트가 포함된 절의 다른 부분에서는, throughput 증가(DORA는 이것을 변경 리드타임, 배포 빈도, 실패한 배포의 복구 시간의 조합으로 정의합니다)가 이런 불안정성 증가를 상쇄하거나 보완하기에 충분한지 논의합니다(page 41, 강조는 제가 추가했습니다).
Some might argue that instability is an acceptable trade-off for the gains in development throughput that AI-assisted development enables.
The reasoning is that the volume and speed of AI-assisted delivery could blunt the detrimental effects of instability, perhaps by enabling such rapid bug fixes and updates that the negative impact on the end-user is minimized.
However, when we look beyond pure software delivery metrics, this argument does not hold up. To assess this claim, we checked whether AI adoption weakens the harms of instability on our outcomes which have been hurt historically by instability.
We found no evidence of such a moderating effect. On the contrary, instability still has significant detrimental effects on crucial outcomes like product performance and burnout, which can ultimately negate any perceived gains in throughput.
어쨌든 page 38의 차트는 throughput 증가보다 instability 증가가 꽤 더 큰 것으로 보입니다.
흥미롭게도 그 차트는 “code quality”의 유의미한 증가도 주장합니다. 그리고 보고서의 다른 부분들(page 30 등)은 delivery instability가 크게 증가하는 동시에 “productivity”도 크게 증가한다고 주장하는데, 이는 모순처럼 보여야 할 것 같습니다. 제가 보기에는 DORA가 “productivity”와 “code quality”의 근거로 삼는 것은 설문 응답자들이 자가 보고한 인지된 영향입니다. 다른 연구와 보고서는 이것들을 측정하기 위해 덜 주관적이고 더 정량적인 방식을 설계했습니다. 예를 들어 Cursor LLM 코딩 도구 도입에 관한 널리 논의된 이 연구는 코드의 품질과 복잡성을 측정하기 위해 정적 분석 결과를 사용했습니다. 특히 자가 보고된 생산성 영향은 매우 의심스럽게 봐야 하는 지표입니다. (관련된 예 하나를 들자면) METR의 2025년 초 연구에서(강조는 제가 추가했습니다):
This gap between perception and reality is striking: developers expected AI to speed them up by 24%, and even after experiencing the slowdown, they still believed AI had sped them up by 20%.
LLM 코딩 옹호자들은 이 특정 연구가 느린 개발 속도를 발견한 것은 더 오래된 세대의 LLM에 근거하기 때문이라고 자주 비판해 왔습니다(그 주장에 대해서는 조금 뒤에 더 말하겠습니다). 하지만 제가 알기로는 개발자들이 자기 생산성을 자가 추정하는 데 그다지 능숙하지 않다는 발견 자체를 진지하게 반박한 사람은 없습니다. 그래서 DORA가 자가 추정 생산성에 의존하는 것은 실망스럽습니다.
DORA 보고서는 이어서 조직을 위한 7단계 “AI capabilities model”도 제시합니다(page 49부터 시작). 추천 항목은 강력한 버전 관리 관행, 작은 배치로 작업하기, 좋은 내부 플랫폼, 사용자 중심의 초점 같은 것들인데… 이런 것들은 LLM을 쓰느냐와 무관하게 성공적인 조직이라면 당연히 갖춰야 할 기본기처럼 느껴집니다.
우스꽝스러운 예를 하나 들어 봅시다. 어떤 사람이 새로운 기술이 외과 수술을 혁신하고 있다고 말했는데, 그 이득은 고르게 분포하지 않고, 전체적으로 가장 좋은 결과는 새 기술을 쓰는 것에 더해 수술 전 팀원들이 손도 씻는 외과 팀에서 나타난다고 해 봅시다. 이 비유는 들리는 것만큼 과장이 아닙니다. DORA 보고서와 다른 유사한 백서, 보고서, 연구들에서 LLM 관련 이득을 극대화하기 위해 권하는 관행들은, 소프트웨어 개발에 있어서 외과 수술의 손 씻기만큼이나 기본적이거나 그래야 마땅한 것들이기 때문입니다. The Joel Test는 25년 전에 이미 이런 관행들 중 상당수를 권장하고 있었고, Agile Manifesto도 그중 여러 개를 암시했으며, 그때조차 그것들이 새롭지는 않았습니다. 효과적인 소프트웨어 개발에 관한 문헌을 파고들어 보면, DORA의 조언 상당수는 1970년대는 물론 그 이전까지 거슬러 올라가는 다양한 형태로 찾을 수 있습니다.
좀 더 최근의 데이터 포인트로, 많은 사람들이 CircleCI의 2026년 “State of Software Delivery”를 이야기하고 제게 링크를 보냈습니다. 이 보고서도 DORA처럼 LLM 도입의 이득이 고르지 않게 분포한다고 주장하며, 심지어(page 8) “the majority of teams saw little to no increase in overall throughput”라고 말합니다. CircleCI 보고서는 또한 DORA 보고서의 “delivery instability” 증가와 맞닿는 우려스러운 지점을 제기합니다(CircleCI 집행 요약문, page 3).
Key stability indicators show that AI-driven changes are breaking more often and taking teams longer to fix, making validation and integration the primary bottleneck.
CircleCI는 추가로(page 11) 전년 대비 깨진 메인 브랜치의 복구 시간이 13% 증가했고, 깨진 기능 브랜치는 25% 증가했다고 보고합니다. 그리고(page 12) 실패도 증가하고 있다고 말합니다.
[S]uccess rates on the main branch fell to their lowest level in over 5 years, to 70.8%. In other words, attempts at merging changes into production code bases now fail 30% of the time.
비교를 위해 말하자면, 메인 브랜치에 대한 그들의 자체 권장 성공 기준은 90%입니다.
이렇게 증가하는 실패와 그것을 해결하는 데 걸리는 시간 증가의 비용은 다음과 같이 정량화됩니다(강조는 보고서 원문 그대로, page 14).
For a team pushing 5 changes to the main branch per day, going from a 90% success rate to 70% is the difference between one showstopping breakage every two days to 1.5 every single day (a 3x increase).
At just 60 minutes recovery time per failure, you’re looking at an additional 250 hours in debugging and blocked deployments every year. And that’s at a relatively modest scale. Teams pushing 500 changes per day would lose the equivalent of 12 full-time engineers.
이런 보고서들에 대한 흔한 반응은 그것들이 오래된 LLM을 쓰는 사람들에 근거한 것이고, 지금 나오는 모델들이야말로 진정으로 혁명적이라서 그런 문제는 없을 것이라고 주장하는 것입니다. 예를 들어 제가 위에서 언급한 METR 연구에 대해 제기된 주요 반론도 이것입니다. 하지만 그 주장은 처음부터 빈약했습니다(그 주장을 뒷받침하는 데 필요한 종류의 증거를 거의 동반하지 않으니까요). 그리고 그 주장이 반복적으로 사용된다는 사실 자체가 그 신뢰를 깎아먹습니다. “이번 이 바로 세상을 바꿀 혁명적 도약이다, 진짜다”라고 말하는 사람들이 전에 그렇게 말했을 때마다 틀렸다면(그리고 실제로 틀렸어야 합니다. 왜냐하면 이전 어느 시점이 진짜 혁명적 도약이었다면 이제 와서 이번 이라고 말할 필요가 없기 때문입니다), 왜 이번에는 믿어야 합니까?
게다가 저는 LLM 코딩에 관한 연구와 보고서를 정말 많이 읽어 왔는데, 이런 종류의 발견—고르지 않거나 일관되지 않은 영향, 품질/안정성 저하 등—은 꽤 놀랄 만큼 안정적으로 반복됩니다. 다양한 모델과 그 버전을 쓰는 수많은 팀들에 걸쳐, 오랜 시간 동안 말입니다(DORA는 “code quality”는 증가하는데 “delivery instability”는 그보다 더 많이 증가한다는 모순된 주장을 함께 하고 있어 다소 혼란스럽긴 하지만, 위에서 말했듯 그건 방법론적 문제처럼 보입니다). 이 글에서 가장 많이 인용한 두 자료(DORA와 CircleCI 보고서)는 특히 LLM 코딩 옹호자들이 제게 자주 추천하는 것들이고, 그 입장도 상당히 친LLM에 가까워 보이기 때문에 골랐습니다.
이런 발견들에 대한 또 다른 예상 가능한 반응은 오래된 것은 꼭 모델 이 아니라 워크플로 였다는 주장입니다. 이제 최첨단은 단순히 LLM에 프롬프트를 던지고 그 출력을 바로 받아들이는 것이 아니라, 하나의 LLM(또는 LLM 기반 에이전트)이 코드를 생성하고 하나 이상의 “적대적” 층이 그 코드를 검토하고 수정하며 서로의 리뷰와 응답과 수정까지 다시 검토하는 식이라는 것입니다. 이렇게 하면 LLM이 자동으로 출력 품질을 개선하는 메커니즘이 도입된다는 주장입니다.
저는 아직 이런 접근에 대한 엄밀한 연구를 알지 못합니다. 하지만 몇몇 널리 알려진 초기 사례들은 신뢰를 주지 못합니다. 여기서는 Cloudflare를 예로 들겠습니다. 그들은 이런 방식의 LLM 사용을 적극적으로 옹호해 왔기 때문입니다. 그들의 Next.js LLM 재구현에서는:
We wired up AI agents for code review too. When a PR was opened, an agent reviewed it. When review comments came back, another agent addressed them. The feedback loop was mostly automated.
하지만 이 과정을 거치고, 그 위에 어느 정도의 인간 리뷰도 있었던 것으로 보이는 공개 릴리스는 처음에는 기본적인 기본 Next.js 애플리케이션조차 실행할 수 없었고, 보안 문제도 상당히 많았던 것으로 보입니다. 한 공개 글에서는(강조는 제가 추가했습니다):
AI is now very good at getting a system to the point where it lookscomplete.
구체적으로 지적된 문제 중 하나는, 이 LLM 재구현이 원래 테스트를 모두 가져오지 않았고, 따라서 그 테스트들이 검증하던 보안상 중요한 경우들을 놓칠 수 있었다는 점입니다. 같은 공개 글에서:
The process was feature-first: decide which viNext features existed, then port the corresponding Next.js tests. That is a sensible way to move quickly. It gives you broad happy-path coverage.
But it does not guarantee that you bring over the ugly regression tests, missing-export cases, and fail-open behavior checks that mature frameworks accumulate over years.
So middleware could look “covered” while the one test that proves it fails safely never made it over.
For example, Next.js has a dedicated test directory(
test/e2e/app-dir/proxy-missing-export/) that validates what happens when middleware files lack required exports. That test was never ported because middleware was already considered “covered” by other tests.
전체적으로 그 글은 다소 낙관적입니다. 하지만 Next.js 재구현이 아마도 전문성을 갖춘 사람들에 의해 수행되었고, 그들은 아마도 좋은 현대적 관행을 따랐으며, 좋은 최신 LLM에게 그 LLM들이 극도로 잘한다고 여겨지는 유형의 작업을 맡겼다고 가정해 봅시다. 훈련 데이터에 풍부하게 존재하고, 문서화도 잘 되어 있으며, 자동 검증을 도와줄 대상 언어로 작성된 대규모 기존 테스트 스위트도 있는 언어와 프레임워크 말입니다. 그런 상황을 보고도 제가 그렇게 낙관적이기는 어렵습니다.
그리고 저는 최근의 Claude Code 소스 유출 의혹을 직접 읽어보지는 않았지만, 그것을 읽은 사람들의 해설과 분석은 읽어 보았습니다. 다시 말해, LLM 코딩의 혁명적 능력을 최대한 활용하기에 누구보다 좋은 위치에 있어야 할 팀조차도 그렇게 해내지 못하고 있는 것처럼 보입니다.
그래서 여기서 일관되게 드러나는 주제는, 연구와 보고서들, 그리고 더 최근의 공개 사례들에서 모두, 2026년의 최신 LLM과 최신 관행을 쓰더라도 예전보다 훨씬 빠르게 코드를 생성할 수 있다는 사실이 예전보다 훨씬 빠르게 소프트웨어를 전달 할 수 있다는 보장은 여전히 아니라는 점입니다. CircleCI 보고서의 표현을 빌리면(page 3):
The data points to a clear conclusion: success in the AI era is no longer determined by how fast code can be written. The decisive factor is the ability to validate, integrate, and recover at scale.
그리고 이것이 Fred Brooks가 하곤 하던 말처럼 들린다면, 실제로 그런 종류의 말 이기 때문입니다. 코드 생성의 순수한 속도는 소프트웨어 개발의 병목이 아니었고 지금도 아닙니다. 그것을 가속하거나 코드 생성 시간을 사실상 0으로 줄인다고 해서 소프트웨어 개발의 다른 모든 부분이 사라지거나 더 빨라지는 것은 아닙니다.
그래서 이 시점에서 제게는, 실천 면에서도 이론 면에서도 LLM 코딩은 은탄환이 아니라는 것이 분명해 보입니다. 그리고 가까운 미래 어느 시점에 그것이 은탄환으로 변모할 가능성도 매우 낮아 보입니다.
LLM 코딩에 회의적인 태도를 보이면 흔히 돌아오는 반응은, 그것을 채택하지 않거나, 혹은 채택을 조금이라도 미루는 것만으로도 불가피하게 “뒤처지게” 되리라는 주장입니다. 심지어 더 강한 표현도 나옵니다(예를 들어 제 지인들 중, 정말 그러면 안 될 것 같은 사람들이 “obliterated” 같은 말을 한 번도 아니고 여러 번 쓴 적이 있습니다). LLM은 미래이고, 당신이 좋아하든 아니든 그렇게 될 것이니, 너무 늦기 전에 흐름에 올라타라는 것입니다.
기술적인 이야기만 하겠다고 했지만, “당신이 좋아하든 아니든 일어날 것”이라는 틀 짜기에는 잠깐 언급하고 넘어가겠습니다. 저는 이런 식의 framing을 많이 접했고, 꽤 불쾌하고 거부감이 들었으며, 제 생각을 바꾸게 만드는 데 전혀 도움이 되지 않았습니다. “It’s undeniable that…” 같은 좀 더 약한 형태도 수사적으로 수상합니다. LLM이 진정으로 혁명적이라는 주장을 하는 쪽이 입증 책임을 져야 하는데, 이런 framing은 그 책임을 암묵적으로 뒤집으려 합니다. 문자 그대로의 선결문제 요구이기도 합니다. 즉, 증명해야 할 결론(LLM이 실제로 혁명적이다)을 이미 주어진 것으로 가정합니다.
한편 제가 보기에는 가능한 결과는 두 가지입니다.
첫 번째 경우라면, 어떤 회사가 LLM 사용을 의무화한 곳에서 일하는 사람이 아닌 이상 늦게 채택하는 데 별다른 단점이 없습니다. 그리고 그런 경우에도, 원한다면 혹은 새 직장을 찾고 싶지 않다면 그때 배워도 됩니다.
두 번째 경우에 대해서는, 지금까지의 LLM 상태와 전망에 대해 제가 위에서 논한 바를 생각하면, 모델과 관행의 진전이 지금까지 보여준 종류의 연속선상에서는 은탄환에 이르는 현실적인 경로가 없다고 저는 당연히 봅니다. 즉, 진정으로 혁명적인 돌파구는 현재 최첨단과 충분히 달라야 하며, 그 결과 비LLM 워크플로뿐 아니라 이전의 많은(어쩌면 전부의) LLM 기반 워크플로도 무효화할 수밖에 없습니다.
그리고 그것이 모든 사람을 다시 같은 출발선에 세우는 완전한 백지 상태를 만들지 않더라도—즉, 옛날 LLM 워크플로 경험이 은탄환 이후 세계에서도 여전히 이점으로 남는다 하더라도—저는 그것이 흔히 가정되는 것 같은 극복 불가능한 이점이 될 수는 없다고 생각합니다. 한 가지 이유는, 평균 생산성이 훨씬 높아지더라도 그로 인해 생길 엄청나게 확장된 소프트웨어 수요를 채울 만큼 충분한 사전 LLM 경험을 지닌 사람들이 아마 존재하지 않을 것이기 때문입니다(그래서 많은 LLM 옹호자들이 여러 분야에 걸쳐 the Jevons paradox에 대해 그렇게 많이 이야기합니다). 또 다른 이유는, 어떤 진정한 은탄환 돌파구든 소프트웨어를 만드는 본질적 어려움을 공격하고 줄여야 하지, 우연적 어려움을 공격하는 것으로는 안 되기 때문입니다. 다시 한 번 Brooks로 돌아가 봅시다.
I believe the hard part of building software to be the specification, design, and testing of this conceptual construct, not the labor of representing it and testing the fidelity of the representation.
오늘날 인간 LLM 사용자에게 요구되는 기술의 상당 부분은 정확히 이것입니다. 즉, 소프트웨어를 “개념적 구성물”로 명세하고 설계하는 일입니다. 다만 그것을 LLM의 context window에 넣어서 코드를 생성하게 할 수 있는 구체적인 형태로 한다는 점만 다릅니다. 어떤 진정한 은탄환 세계에서는 이 기술셋의 상당 부분 혹은 전부가 쓸모없어져야 합니다. 그리고 그렇게 되면 은탄환이 마침내 달성되었을 때 늦은 채택에 따르는 불이익은 크게 줄어듭니다.
전문 프로그래머와 전문 소프트웨어 개발 팀에 대한 영향 외에도, LLM 코딩을 옹호하는 측에서 자주 하는 또 다른 주장은 그것이 소프트웨어 개발에 대한 접근을 민주화할 것이라는 점입니다. LLM 코딩 도구가 있으면 경험 많은 직업 프로그래머가 아닌 사람들도 자신의 일상 업무와 삶에서 마주치는 문제를 해결하는 소프트웨어를 만들 수 있다는 것입니다. 분명 이것은 엄청난 사회적 이익 아닌가요? 게다가 엄청 재미있기까지 하죠!
위에 링크한 New York Times 글이 실은 경험 많은 전문가가 쓴 것이라는 점은 제쳐 두더라도, 저는 이 사용 사례에도 설득되지 않습니다.
대체로 제 생각에는, 이것은 양쪽을 다 가질 수 없는 상황입니다. LLM 코딩 옹호자들 사이에서는 일관되게 유용한 결과를 내기 위해서는 상당한 이해, 연습, 경험이 필요한 기술이라는 데 널리 동의가 있는 듯합니다(이것이 바로 앞 절에서 다룬 “지금 채택하지 않으면 뒤처진다”는 주장에 깔린 전제입니다). 또한 좋은 소프트웨어를 설계하고 구축하는 법에 대한 강한 사전 지식도 일반적으로 권장되거나 전제됩니다. 하지만 이것은 민주화된 소프트웨어 주장과 크게 충돌합니다. 프로그래밍 지식이나 경험이 전혀 없는 사람이 그저 LLM을 집어 들고, 평범한 비기술적 자연어로 무언가를 만들어 달라고 하면, 충분히 기능하는 결과를 받을 것이라는 주장 말입니다.
제 생각에 가장 가능성이 큰 결과는 비기술 사용자가 목적에 명백히 맞지 않는 무언가를 받는 것입니다. 그들이 LLM을 효과적으로 프롬프트할 데 필요한 지식을 갖고 있지 않기 때문입니다. 자신의 문제를 위해 지침, 스킬 정의, 아키텍처 정보가 담긴 Markdown 파일 디렉터리를 어떻게 구성해야 하는지 모를 것입니다. 자신이 원하는 것을 충분한 세부 수준으로 묘사하는 기술 명세를 쓰는 연습도 없을 것입니다(다른 인간을 위한 것이든 LLM을 위한 것이든). 좋은 소프트웨어를 설계하고 아키텍처를 짜는 방법도 모를 것입니다. 여러 LLM이나 LLM 기반 에이전트를 조율해 서로를 적대적으로 검토하게 하는 법도 모를 것입니다. 요컨대, 성공적인 LLM 코딩 사용에 필수적이라고 여겨지는 그 어떤 기술도 갖고 있지 않을 것입니다.
또 하나의 가능성은, 내재적인 모호성과 정밀성 부족 때문에 “자연스러운” 인간 언어만으로는, 훨씬 더 발전한 LLM이나 미래의 다른 “AI” 시스템에게조차 프로그램을 명세하는 데 결코 충분하지 않을 수 있다는 점입니다. 그렇다면 프로그램 명세를 위한 어떤 종류의 특수한 형식 언어는 언제나 필요할 것입니다. 예를 들어 Edsger W. Dijkstra는 이런 입장을 취했고, “the foolishness of ‘natural language programming’”이라고 그가 부른 것을 유명하게 비웃었습니다. 여기에는 다음과 같은 고전적인 Dijkstra식 문장들이 있어 읽어볼 가치가 있습니다.
When all is said and told, the “naturalness” with which we use our native tongues boils down to the ease with which we can use them for making statements the nonsense of which is not obvious.
비프로그래머의 LLM 코딩에 대한 또 다른 가능한 결과는 자주 언급되는 3D 프린팅 비유입니다. 3D 프린팅 역시 누구나 무엇이든 설계하고 만들 수 있게 해 주는 위대한 민주화 도구로 과대선전되었지만, 그 약속을 실현하지 못했고, 개인 차원에서는 시간과 돈과 노력을 들여 어느 정도 잘하게 될 의지와 능력이 있는 소수 애호가들의 틈새 취미가 되었습니다.
하지만 악몽 같은 결과는 비프로그래머 LLM 사용자가 작동하는 것처럼 보이는 무언가를 받고, 그 결함이 훨씬 나중에야 드러나는 경우입니다. 저는 LLM이 코딩을 민주화하고, 프라이버시와 기밀성이 모두 중요하고 법적으로도 요구되는 분야에서 일하는 사람들을 위한 유틸리티 프로그램을 써 줄 것이라는 주장을 아주 자주 봅니다. 그래서 저는 그 잠재적 실패 모드가 정말 두렵습니다. 그리고 LLM 도입 옹호자들에게 일어날 수 있는 최악의 일 중 하나는, 선의의 비기술 사용자들이 예를 들어 LLM으로 만든 보조 프로그램 때문에 실수로 데이터 유출을 가능하게 해 버리거나, 혹은 “그저” 미묘하게 틀린 재무 모델을 자기 사업에 풀어놓아 인생이 망가졌다는 이야기들로 뉴스가 가득 차는 것이라고 생각합니다. 그래서 제가 LLM 코딩의 옹호자였다 하더라도, 그것을 비프로그래머에게 밀어붙이는 데는 대단히 신중했을 것입니다.
하지만 결국 LLM이 소프트웨어 개발에 대한 접근을 의미 있게 민주화할 수 있는 유일한 상황은, 그것이 진정한 은탄환이 되어 소프트웨어 개발 과정의 본질적 어려움을 크게 줄이거나 없애는 경우입니다. 그리고 앞서 언급했듯, LLM 옹호자들은 설령 은탄환 상황이 되더라도 기존에 LLM 사용 기술이 있는 사람과 없는 사람 사이의 격차가 너무 커서, 없는 사람은 의미 있게 따라잡을 수 없을 것이라고 믿는 듯합니다. 저는 개인적으로 그 믿음에 동의하지 않지만, 여전히 옹호자들은 양쪽을 다 가질 수 없습니다. 즉, LLM 코딩은 필요한 기술을 쌓아 올린 사람들만의 배타적 클럽이 될 것이거나, XOR 훌륭한 민주화 도구가 되어 그런 기술 자체의 필요를 없애 버릴 것입니다.
이 글이 이미 6,000단어를 훌쩍 넘었고, 더 길게 쓸 수도 있겠지만, 아마 이제 마무리해야 할 것 같습니다.
LLM 코딩에 대한 제 입장을 한 문장으로 요약해야 한다면 “제발 _No Silver Bullet_을 읽으세요”일 것입니다. 저는 그 글에서 Brooks의 논증이 이론적으로도 옳고, 경험적 결과로도 검증되었으며, LLM 코딩이나 그 밖에 오로지 혹은 주로 우연적 어려움을 공격하는 모든 도구나 기법이 미칠 수 있는 영향에 꽤 강한 한계를 설정한다고 생각합니다.
물론 우리가 할 수 있는 것과 얻을 수 있는 것에 한계가 있다는 사실이 반드시 세상의 끝은 아닙니다. _On Computable Numbers_부터 Rice’s theorem과 그 너머에 이르기까지 컴퓨터 과학의 많은 기초들은 우리가 할 수 있는 일에 굳건한 한계를 둡니다. 하지만 우리는 여전히 소프트웨어를 쓰고, 여전히 우리 기술의 상태를 진전시키기 위해 노력합니다. 따라서 No Silver Bullet 논증은 LLM이 반드시 쓸모없다 고 주장하는 것과는 다릅니다. 또, 거기서 어떤 이득도 절대로 나올 수 없다고 주장하는 것도 아닙니다. 하지만 만약 이득이 나온다면, 그것은 많은 사람들이 기대하는 세계를 바꾸는 혁명이라기보다 점진적이고 진화적인 것일 가능성이 높다는 주장입니다.
이에 따라 저는 지금 시점에서 LLM 코딩을 느리게 채택하거나 늦게 채택하는 데 큰 단점은 없다고 생각합니다. 아주 적은 조직만이 자신들이 생성하는 코드 양의 비교적 완만한 점진적 증가조차 흡수할 수 있는 강한 기본기를 갖추고 있으며, 제가 보기엔 그래서 그렇게 많은 연구와 보고서에서 엇갈린 결과와 망가진 CI pipeline을 발견하는 것 같습니다. 은탄환이 없을 뿐 아니라, 특히 기본기를 먼저 다지지 않은 채 LLM 코딩을 서둘러 도입한다고 해서 얻을 수 있는 빠르거나 마법 같은 이득도 없습니다. 사실 현재의 증거에 따르면, 그렇게 하면 생산성은 좋아지기보다 망가질 가능성이 더 큽니다.
또한 저는 LLM이 가까운 시일 내에 코딩을 의미 있게 민주화할 것이라고도 생각하지 않습니다. 설령 그것이 프로그래머에게 없어서는 안 될 도구가 되더라도, 명세를 쓰고 프롬프트를 설계할 때 사용자가 계속해서 “프로그래머처럼 생각해야” 할 가능성이 높습니다. 우리는 사람들을 아무 준비 없이 LLM 앞에 앉혀 두는 것보다, 훨씬 더 많은 사람에게 엄밀하게 사고하고 추상에 대해 추론하는 법을 가르치는 편이 훨씬 더 도움이 될 것입니다(그 사람들 자신에게도 더 좋을 것입니다).
그렇다면 뒤처질까 두려워 LLM 코딩을 서둘러 도입하는 대신 무엇을 해야 하느냐고요? 제 생각에는, 그 모든 백서와 보고서와 연구들이 실제로 말하고 있는 바에 귀를 기울이고, 기본기를 다져야 합니다. 버전 관리, 포괄적인 테스트 스위트, continuous integration, 의미 있는 문서화, 빠른 피드백 사이클, 반복적 개발, 사용자에 대한 집중, 작은 단위의 작업… 수십 년 동안 알려지고 입증되었지만, 실제 현실의 소프트웨어 현장에서는 여전히 너무 드문 이런 탄탄한 기초적 소프트웨어 개발 관행들을 채택하고 완성해 가야 합니다.
회의적인 입장이 틀렸고 장기적으로 LLM이 진정한 필수 코딩 도구가 된다고 해도, 현재의 문헌이 말하길 당신은 그것들을 최대한 활용할 수 있는 가장 좋은 위치에 놓이게 됩니다. 그리고 만약 그렇지 않다면, 당신은 어쨌든 지금보다 훨씬 더 좋은 상태에 있게 됩니다. 그리고 기본기를 다지지 않은 채 팀에게 그저 토큰을 씹어 먹으며 코드를 생성하라고 지시해 엄청난 생산성 향상을 좇다가, 아마 그 과정에서 개발 프로세스 자체를 망가뜨렸을 사람들보다 유리한 위치에 서게 될 것입니다.
혹은 Fred Brooks의 말로 하면:
The first step toward the management of disease was replacement of demon theories and humours theories by the germ theory. That very step, the beginning of hope, in itself dashed all hopes of magical solutions. It told workers that progress would be made stepwise, at great effort, and that a persistent, unremitting care would have to be paid to a discipline of cleanliness. So it is with software engineering today.
Copyright © James Bennett, 캘리포니아에 거주하는 소프트웨어 개발자. 여기 표현된 의견은 오직 각 저자의 것일 뿐입니다.
