이 글은 소프트웨어 개발 및 프로그래밍 직업 관점에서 LLM의 현재 위치를 조명합니다. LLM을 둘러싼 과장된 기대나 비관론을 비판하며, '은탄환은 없다'는 프레드 브룩스의 고전적 주장을 빗대어 LLM이 소프트웨어 개발의 본질적인 난제를 단번에 해결할 수 없음을 강조합니다.
번역된 본문
LLM에 대해 이야기해 봅시다
게재일: 2026년 4월 9일
카테고리: 프로그래밍
우리 모두가 지금 무언가 한가운데에 있다는 데는 동의하는 것 같지만, 그것이 정확히 무엇인지에 대해서는 아직 논쟁 중인 것 같습니다. 그것은 생산성과 역량에서 전례 없는 혁명일 수 있으며, 어쩌면 그 너머의 세계가 어떻게 될지 전혀 짐작할 수 없는 기술적 '특이점(Singularity)'의 전조일 수도 있습니다. 아니면 그저 시들어버릴 또 하나의 가짜(Vaporware) 과대광고 사이클일 수도 있습니다. 아니면 닷컴 버블처럼 대규모 붕괴로 이어지지만 여전히 우리에게 유용한 무언가를 남길 거대한 거품일 수도 있습니다(닷컴 버블이 웹의 대중화를 촉진했던 것처럼요). 또 그 어느 것도 아닐 수 있습니다. 이러한 입장들을 두고 이미 수천 마디의 말들이 오가며 논쟁을 벌였습니다. 그래서 오늘 저 역시 이 주제에 대해 몇 천 단어 정도 더 쏟아부으려고 합니다. 블로그가 원래 그런 용도니까요. 적어도 여기서 읽게 될 모든 글은 제가 직접 쓴 것입니다(그리고 내가 죽어서 식어버린 내 손에서만 전각 대시(Em-dash)를 빼앗아 갈 수 있을 겁니다).
용어와 방향성 설정
하지만 먼저 몇 가지 빠른 참고 사항을 말씀드리겠습니다. 저는 이 글에서 'LLM'과 'LLMs'라는 용어를 거의 배타적으로 사용할 것입니다. 왜냐하면 그 정확성이 유용하다고 생각하기 때문입니다. 'AI(인공지능)'는 모호하고 의미가 너무 많이 담긴 용어이며, 누군가 'AI'라고 할 때 정확히 무엇을 의미하는지에 대한 언어 유희와 논쟁에 빠지기가 너무 쉽습니다. 그리고 현재 프로그래밍과 'AI'에 대해 논쟁적인 거의 모든 것은 사실 대형 언어 모델(LLM)의 등장에서 비롯되었습니다. 'GPT'라고 말하는 것이 약간 더 높은 수준의 정확성을 가져다줄 수도 있다고 생각하지만, OpenAI가 계속해서 그 용어를 자신들의 고유한 용어로 주장하려 하고 있으며, 이는 또 다른 종류의 달갑지 않은 짐이 될 수 있습니다. 그러니 'LLMs'라고 하겠습니다. 그리고 제가 'LLM 코딩'이라고 말할 때, 프로그래밍 언어로 코드를 생성하기 위해 LLM을 사용하는 것을 의미합니다. 인간의 감독을 받는지 여부, 코드의 유일한 생산자로 사용되는지(인간이 작성한 코드가 전혀 없는지) 여부 등에 상관없이 이러한 모든 사용을 아우르는 포괄적인 용어로 이것을 사용합니다. 또한 저는 여기서 제 댓글을 기술 및 전문 직업으로서의 프로그래밍과 직접적으로 관련된 것들로 제한하려고 노력할 것입니다. 왜냐하면 그것이 제가 아는 분야이기 때문입니다(저는 철학 학위를 가지고 있어서 LLM의 다른 측면에 대해 논평할 자격이 있지만, 이 글에서는 그러한 논쟁들이 많이 지루하고 말 그대로 대학 2학년 때 읽고 토론하던 것들을 떠올리게 하기 때문에 의도적으로 그 부분은 다루지 않겠습니다). 만약 다른 분야에서 LLM을 사용하고 있다면, 아마도 저는 그 분야에 대해 유용하게 논평할 만큼 잘 알지 못할 것입니다. 이 원칙을 따르지 않는 사람들의 일부 극단적인 주장을 보면서, 저는 LLM 관련 담론 중 많은 부분이 사람들이 자신의 직업과 분야를 제외한 모든 일자리와 분야를 LLM이 대신할 것이라고 기대하는 방식과 관련이 있다는 점에서 정말로 'LLM'과 '겔-만 기억 상실증(Gell-Mann Amnesia)'의 귀여운 합성어가 필요하다고 여러 번 생각했습니다.
은탄환은 없다
몇 년 전 저는 프레드 브룩스(Fred Brooks)의 '은탄환은 없다(No Silver Bullet)'에 대해 쓴 적이 있으며, 그것이 브룩스가 쓴 것 중 최고의 글이라고 생각한다고 말했습니다. '은탄환은 없다'를 읽어본 적이 없다면 강력히 읽어볼 것을 권하며, 요약본만 읽지 말고 직접 전체를 읽어볼 것을 권장합니다. '은탄환은 없다'는 컴퓨팅 하드웨어가 믿을 수 없는 속도로 발전하던 시기에 출판되었지만, 소프트웨어를 구축하는 우리의 능력은 그 발전 속도를 따라가지 못했습니다. 그래서 브룩스는 소프트웨어에 대해 대담한 예측을 내놓았습니다. "기술이나 관리 기법 모두에서 단일 개발만으로는 10년 내에 생산성, 안정성, 단순성에서 단 한 번의 자릿수(10배) 향상을 약속할 수 있는 것은 없다." 이를 뒷받침하기 위해 그는 소프트웨어 개발에서 어려움의 근원을 살펴보고, 이를 두 가지 광범위한 범주로 분류했습니다(원문의 강조 표시와 동일). "아리스토텔레스를 따라, 나는 이를 본질(essence), 즉 소프트웨어의 본성에 내재된 어려움과, 우발적 사고(accidents), 즉 오늘날 그 생산에 수반되지만 본질적이지 않은 어려움으로 나눕니다. 메모리 관리는 그에 대한 전형적인 예입니다..."
Let’s talk about LLMs Published on: April 9, 2026 Categories: Programming Everybody seems to agree we’re in the middle of something , though what, exactly, seems to be up for debate. It might be an unprecedented revolution in productivity and capabilities, perhaps even the precursor to a technological "singularity" beyond which it's impossible to guess what the world might look like. It might be just another vaporware hype cycle that will blow over. It might be a dot-com-style bubble that will lead to a big crash but still leave us with something useful (the way the dot-com bubble drove mass adoption of the web). It might be none of those things. Many thousands of words have already been spent arguing variations of these positions. So of course today I’m going to throw a few thousand more words at it, because that’s what blogs are for. At least all the ones you’ll read here were written by me (and you can pry my em-dashes from my cold, dead hands). Terminology, and picking a lane But first, a couple quick notes: I’m going to be using the terms “ LLM ” and “LLMs” almost exclusively in this post, because I think the precision is useful. “ AI ” is a vague and overloaded term, and it’s too easy to get bogged down in equivocations and debates about what exactly someone means by “ AI ”. And virtually everything that’s contentious right now about programming and “ AI ” is really traceable specifically to the advent of large language models. I suppose a slightly higher level of precision might come from saying “ GPT ” instead, but OpenAI keeps trying to claim that one as their own exclusive term, which is a different sort of unwelcome baggage. So “LLMs” it is. And when I talk about " LLM coding", I mean use of an LLM to generate code in some programming language. I use this as an umbrella term for all such usage, whether done under human supervision or not, whether used as the sole producer of code (with no human-generated code at all) or not, etc. I’m also going to try to limit my comments here to things directly related to technology and to programming as a profession, because that's what I know (I have a degree in philosophy, so I’m qualified to comment on some other aspects of LLMs, but I’m deliberately staying away from them in this post because I find a lot of those debates tedious and literally sophomoric, as in reminding me of things I was reading and discussing when I was a sophomore). If you’re using an LLM in some other field, well, I probably don’t know that field well enough to usefully comment on it. Having seen some truly hot takes from people who didn't follow this principle, I've thought several times that we really need some sort of cute portmanteau of “ LLM ” and “Gell-Mann Amnesia” for the way a lot of LLM -related discourse seems to be people expecting LLMs to take over every job and field except their own. No silver bullet A few years ago I wrote about Fred Brooks' No Silver Bullet , and said I think it may have been the best thing Brooks ever wrote. If you've never read No Silver Bullet , I strongly recommend you do so, and I recommend you read the whole thing for yourself (rather than just a summary of it). No Silver Bullet was published at a time when computing hardware was advancing at an incredible rate, but our ability to build software was not even close to keeping up. And so Brooks made a bold prediction about software: 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. To support this he looked at sources of difficulty in software development, and assigned them to two broad categories (emphasis as in the original): 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. A classic example is memory management: some programming languages require the programmer to manually allocate, keep track of, and free memory, which is a source of difficulty. And this is accidental difficulty, because there's nothing which inherently requires it; plenty of other programming languages have automatic memory management. But other sources of difficulty are different, and seem to be inherent to software development itself. Here’s one of the ways Brooks summarizes it (emphasis matches what's in my copy of 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. And to drive the point home, he also explains the diminishing returns of only addressing accidental difficulty: 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. This is a straightforward mathematical argument. If its two empirical premises—that the accidental/essential distinction is real and that the accidental difficulty remaining today does not represent 90%+ of total—are true, then the conclusion which rules out an order-of-magnitude gain from reducing accidental difficulty follows automatically. I think most programmers believe the first premise, at least implicitly, and once the first premise is accepted it becomes very difficult to argue against the second. In fact, I’d personally go further than the minimum required for Brooks’ argument. His math holds up as long as accidental difficulty doesn't reach that 90%+ mark, since anything lower makes a 10x improvement from eliminating accidental difficulty impossible. But I suspect accidental difficulty, today, is a vastly smaller proportion of the total than that. In a lot of mature domains of programming I’d be surprised if there’s even a doubling of productivity still available from a complete elimination of remaining accidental difficulty. There's also a section in No Silver Bullet about potential "hopes for the silver" which addresses " AI ", though what Brooks considered to be " AI " (and there is a tangent about clarifying exactly what the term means) was significantly different from what's promoted today as " AI ". The most apt comparison to LLMs in No Silver Bullet is actually not the discussion of " AI ", it's the discussion of automatic programming , which has meant a lot of different things over the years, but was defined by Brooks at the time as "the generation of a program for solving a problem from a statement of the problem specifications". That's pretty much the task for which LLMs are currently promoted to programmers. But Brooks quotes David Parnas on the topic: “automatic programming always has been a euphemism for programming with a higher-level language than was presently available to the programmer.” And Brooks did not believe higher-level languages on their own could be a silver bullet. As he put it in a discussion of the Ada language: 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 ar