메뉴
HN
Hacker News • 3일 전

AI에도 지혜가 없고, 당신에게도 없어질 것이다

IMP
7/10
핵심 요약

AI 코드 생성에만 의존하면 개발자는 숙련(expertise)에 도달할 수 없으며, 바이브 코딩 프로젝트는 시간이 지나면 유지보수 불가능한 상태로 악화된다고 경고하는 글입니다. 유지보수성과 좋은 아키텍처는 즉각 측정이 어려워 AI 학습의 보상 신호가 될 수 없고, 전문가의 직관은 규칙화할 수 없기 때문에 AI는 결코 이를 대체할 수 없다는 것이 핵심 논지입니다.

번역된 본문

지난 한 달 동안 나는 이런 말들을 들었다: "나는 2025년 이후로 코드를 직접 쓴 적이 없다", "코드 리뷰는 죽었다", "이제 사람들은 코드를 읽지 않는다". 확실히 업계는 변화하고 있지만, 코드를 더 이상 읽고 쓰지 않는 함정에 빠진 개인과 조직은 그 대가를 치르게 될 것이다. 사실, 바이브 코딩(vibe-coded) 프로젝트는 시간이 지나면서 유지보수 불가능한 엉망진창으로 전락한다.

그 이유는 간단하지만 고치기 어렵다. 코드 유지보수성과 좋은 아키텍처에는 적용할 수 있는 좋은 측정 지표가 없기 때문이다. 나쁜 아키텍처나 유지보수 불가능한 코드의 영향은 알아차리는 데 몇 달, 심지어 몇 년이 걸리기 때문이다.

물론 나쁜 코드는 정의할 수 있다. 읽기 어렵고, 이해하기 어렵고, 미래에 어떤 일이 닥쳐도 대응하기 어려운 코드. 한 가지를 바꾸면 매우 비결정적인 방식으로 프로그램이 망가지거나, 변경한 곳과 멀리 떨어진 로직이 깨지는 '나비 효과'와 같은 코드. 기능을 추가하려면 여러 곳의 코드를 수정해야 하는데도 모든 곳을 패치하지 않아 불일치가 생기는, 중대한 작업이 되어버리는 코드. 설계의 불변식(invariant)이 불분명하고, 그 설계자들은 이미 자리를 떠나 위반을 막고 일관성을 보장해줄 수 없는 코드. 테스트하기 어려워 목(mock)을 필요로 하고 구현 세부사항을 노출시켜, 결국 의미 있는 리팩토링을 방해하는 취약한 테스트를 만들어내는 코드.

그리고 우리는 나쁜 코드를 알아차리는 데 시간이 걸린다는 것을 사실로서 안다. 몇 달, 몇 년이 걸린다. 물론 경험 많은 소프트웨어 엔지니어는 코드 스멜(code smell)을 감지하는 감각이 있어서 나쁜 영향이 관찰되기 훨씬 전에 조치를 취할 수 있다. 능숙한 개발자, 전문가들은 땀과 눈물로 만들어진 직관에 의존한다. 긴 시간 동안 프로덕션 문제를 디버깅하고 수정하며, 과거의 실수를 결코 반복하지 않겠다고 맹세하면서 쌓아온 직관이다. 이런 직관은 모든 것이 맥락에 따라 달라지기 때문에 딱딱한 규칙의 목록으로 만들 수 없다. 전문가는 초보자의 생산성을 높여주는 것과 같은 규칙과 레시피와는 양립하지 않는다. 전문가는 규칙을 따르지 않고, 규칙을 만든다.

그래서 우리에게는 문제가 있다. 우선, AI는 코드의 유지보수성이 무엇을 의미하는지에 대해 학습된 적이 없다. 예를 들어, 강화학습에는 즉시 측정 가능한 보상 신호가 필요하지, 유지보수성은 몇 달이나 몇 년 뒤에야 측정된다. AI는 초보자를 위한 규칙집에서 규칙을 배운다. AI는 실세계의 코드에서 패턴을 감지하는데, 솔직히 말해 실세계의 대부분의 코드는 꽤 나쁘다. 유지보수 가능한 코드에 대해 정의할 수 있는 적합도 함수(fitness function)는 없다. 적어도 우리가 식별할 수 있는 것은 없다. 그렇지 않았다면 이미 우리의 린터(linter)에 반영되었을 것이다.

AI가 코드를 '단순화'하는 것이 얼마나 끔찍한지 눈치챘는가? 그것도 SOTA(최고 수준) 모델들이 말이다. AI는 함수도 제대로 정의하지 못하고, 실제로 재사용 가능하지 않은 더 작은 함수들로 함수를 쪼개는 것을 택한다. 큰 함수를 이해하려면 추출된 작은 함수의 구현까지 읽어야 한다면, 큰 함수에서 작은 함수를 추출하는 것은 매우 나쁜 선택이다. 재사용 가능하고 명확성을 주는 함수를 정의하는 것은 예술이며, 숙달이 필요한 예술이다. 드레이퍼스 모델(Dreyfus model)에서 여전히 '고급 초보자(advanced beginner)'에 불과한 대부분의 개발자들은 좋고, 명확하며, 재사용 가능한 함수를 정의할 수 없으며, 현재의 AI도 마찬가지다.

사람들이 여전히 통제권을 가지고 그 실수들로부터 배운다면 이렇게까지 나쁘지 않을 것이다. 하지만 우리는 사람들이 AI에 의존해 코드를 쓰고, 심지어 읽기까지 하는 추세를 목격하고 있다. 그런 사람들은 결코 숙달에 도달하지 못할 것이다. 더 이상 선택을 하지 않고, 코딩의 실수에 대한 책임을 지지 않으며, 그 실수로부터 배우지도 않기 때문이다. 이제 실수를 하는 것은 AI다. AI는 그 실수로부터 배우지 않고, AI에 의존해 코딩하는 사람들도 배우지 않는다. 아이코!

오해하지 말기 바란다. 나는 LLM이 훌륭한 도구라고 생각한다. 나는 러다이트(기술 반대론자)가 아니며, 실제로 배운 것을 동료들에게 가르치면서 일상 업무에 AI를 통합하고 있다.

원문 보기
원문 보기 (영어)
In the past month alone I’ve heard these phrases: I haven’t written code since 2025 ; Code reviews are dead ; People no longer read code . Certainly the industry is transforming, however, the people and organizations falling into the trap of no longer reading and writing code only do so at their peril. Fact is, vibe-coded projects devolve over time into an unmaintainable mess. The reason is simple, yet hard to fix: code maintainability and good architecture don’t have good measurements that we can apply, because it takes months, years even, to notice the effects of bad architecture or of unmaintainable code. We can certainly define bad code: code that’s hard to read, hard to understand, hard to evolve for whatever the future throws our way. The kind of code in which changing one thing breaks the program in very non-deterministic ways, or breaks the logic somewhere else, far removed from your change, resembling the “butterfly effect”. The kind of code where adding a feature means a serious undertaking due to changing code in multiple places and still forgetting to patch everything, thus getting inconsistencies. Code in which the invariants of the design aren’t clear, with its authors no longer being around to guard against violations and ensure some coherence. Code that is hard to test, requiring mocks and exposing implementation details, leading to fragile tests that end up preventing meaningful refactoring. And yet, we know it as a fact that noticing bad code takes time. Months, years. Of course, the experienced software engineers have a nose that can detect code smells and can take action long before the bad effects can be observed. The proficient developers, the experts, rely on their intuition built with sweat and tears, working long hours trying to debug and fix production issues, swearing to never again be so foolish as to repeat past mistakes. It’s the kind of intuition that can’t really be made into a list of rigid rules, because everything is context-dependent. Experts are incompatible with the same rules and recipes that make beginners more productive. Experts don’t follow the rules, they make the rules. And so we have a problem… For one, AI is not trained on what it means for code to be maintainable. For instance, any reinforcement learning done needs a reward signal that can be measured immediately, not in months or years. The AI learns rules from rulebooks meant for beginners. The AI notices patterns from code in the wild and let’s be honest, most code in the wild is pretty bad. There is no fitness function you can define for maintainable code, at least not one that we can discern, otherwise it would’ve been baked into our linters. Have you noticed how terrible is the AI at “simplifying” code? Yes, the SOTA models. It can’t even define functions properly, choosing to split functions into smaller functions that are not actually reusable. Extracting a smaller function from a bigger function is a very bad choice if, to understand the bigger function, you have to also read the implementation of the extracted smaller function. Defining reusable and clarifying functions is an art form, an art that takes mastery. Most developers, being still “advanced beginners” in the Dreyfus model , are not able to define good, clarifying, reusable functions and neither does the AI currently. This wouldn’t be so bad if people would still be in control and learn from those mistakes. But we are seeing a trend of people relying on AI to write, and even read code. Those people will never reach mastery, because they no longer make choices, they no longer take responsibility for mistakes in coding and no longer learn from those mistakes. It’s the AI that’s making mistakes now, the AI doesn’t learn from those mistakes, and neither are the people relying on AI for coding. Yikes! Don’t get me wrong, I think LLMs are a great tool. I’m no Luddite, I’ve integrated AI in my everyday work, while actually teaching my colleagues what I’ve learned. I gladly use LLMs to take care of all the boring, soul-sucking shit we have to deal with. I’m also enjoying the efficiency benefits that I’m seeing. But at the end of the day, it’s just a tool, and like all other revolutions, its light will also fade; IMO, it already is, as right now tech news is frankly quite boring. People are actually terrible at making predictions. I believe the future will surprise all of us. But, I’m going to make a prediction of my own… In the future we will see more and more companies proudly boasting their “NO-AI” policy as a competitive advantage. And they will be right. “But automated assembly lines are always more efficient” people say, except that the software industry is special, because we’ve always done automation at scale, everything we do is automation, LLMs are not the only means for it, and depending on context, it may actually be a distraction. “Coding isn’t solved” in any meaningful sense. Sure, you can instruct the LLM to build you a C/C++ compiler, or you can just clone GCC or LLVM, and you’d get a better C/C++ compiler, for free, too. And maybe there are better ways to spend our time and resources than reinvent the same CRUD apps (human needs and desires are infinite, there’s no shortage of new goals to work on). If people and companies don’t start being responsible about its use, there will be consequences. Updated: September 22, 2026 | Written by Alexandru Nedelcu Tags: AI | Opinion Related Articles # Copyright is Dead AI | Open Source | Opinion March 6, 2026 Boring Tech May Become Irrelevant Tech AI | FP | Opinion | Programming | Languages March 5, 2026 Programming Languages in the Age of AI Agents AI | FP | Opinion | Programming | Languages November 16, 2025