Hacker News • 50일 전

AI 록스타 개발자가 남긴 참상 치우기

IMP

8/10

핵심 요약

과거 팀 내 '록스타 개발자'가 퇴사 후 유지보수 불가능한 복잡한 코드를 남기던 문제가, 이제는 생성형 AI의 등장으로 수백 명의 AI 록스타가 만들어내는 걷잡을 수 없는 스파게티 코드로 확대 재생산되고 있습니다. AI는 압도적인 속도로 코드를 쏟아내지만 시스템의 복잡성을 폭발시키며, 결국 개발자와 기업을 AI에 의존하게 만듭니다. 과도한 AI 코딩의 부작용을 경고하고 이를 수습하는 과정의 어려움을 조명한 중요한 기사입니다.

번역된 본문

AI 록스타 개발자가 남긴 참상 치우기 Martijn Baudoin의 Unsplash 사진 우리는 모두 '록스타 개발자'와 함께 일해본 적이 있을 것입니다. 그들은 몇 년 전 팀에 합류했을 때 에너지가 넘쳤습니다. 새로운 기술, 새로운 패러다임, 새로운 아키텍처에 대한 훌륭한 아이디어를 가지고 있었습니다. 그들의 혁신적인 아이디어는 다른 모든 사람들이 뒤처지고 구식이라고 느끼게 만들었습니다. 그들은 회사의 핵심 아키텍처 대부분을 재작성했습니다. 새로운 빌드 프로세스, 새로운 도구, 새로운 언어를 도입했습니다. 대부분의 풀 리퀘스트(Pull Request)를 거부하며 다른 모든 사람들에게 기대치를 한 단계 높였습니다. 아무도 그들이 작성한 코드를 이해하지 못했지만, 아무도 그 사실을 인정하려 하지 않았습니다. 가장 어려운 작업은 모두 록스타에게 할당되었습니다. 그들은 누구보다 빠르게 해냈죠. 록스타만이 시스템이 어떻게 맞물려 돌아가는지 알고 있었을 뿐, 그 엔지니어링은 항상 매우 인상적으로 들렸습니다. 비교해보면 다른 모든 사람은 훨씬 더 느리게 움직였습니다. 모두 새로운 라이브러리를 배우고 록스타의 방식대로 일하기 위해 애쓰며 뒤처지지 않으려 고군분투했습니다. 그러다 그들이 팀에 합류한 지 몇 년 후, 갑자기 그들은 사라졌습니다. 그들은 지루해졌고, 더 큰 회사에서 더 도전적인 프로젝트를 하는 더 좋은 직장을 원했던 것입니다.

여파 처리 갑자기 당신은 록스타의 프로젝트를 인계받게 되었습니다. 코드를 파고들었지만, 그 안에 산 채로 묻힌 것 같았습니다. 데이터의 흐름을 따라가기가 너무 어려워서 마치 누군가 살인을 은폐하려는 것 같았습니다. 간단한 버그를 고치는 것부터 시작하려 했습니다. 그저 노트북에서 코드를 실행하는 데만 일주일이 걸렸습니다. 코드의 절반은 당신이 이해하지 못하는 언어로 작성되어 있었습니다. 나머지 절반은 들어보지도 못한 라이브러리를 사용해 작성되어 있었습니다. 상사에게 코드를 전면 재작성(rewrite)해야 한다고 말하려 했지만, 상사는 믿지 않았습니다. 왜냐하면 그 코드가 바로 록스타 본인이 작성한 것이기 때문입니다. 이 쓰레기 더미 같은 코드를 뒤지면서, 당신은 채용 공고를 둘러보며 이곳을 떠나는 상상을 했습니다.

록스타가 남긴 뒤처리 저는 록스타들이 남긴 뒤처리가 필요한 수많은 팀 및 에이전시와 함께 일해왔습니다. 저는 사실 이 엉망진창인 코드베이스를 이해하고 구출해내는 도전을 즐깁니다. 마치 엉켜있는 크리스마스 트리 전등 상자 앞에 앉아, 다시 사용할 수 있을 때까지 실뭉치를 하나씩 풀어내는 것과 같거든요. 저는 이 과정을 거치면서 몇 가지 패턴을 발견했습니다. 이 록스타들은 코딩, 학습, 새로운 패러다임의 사용을 절대적으로 사랑하며, 그것은 그들의 모습에서도 드러납니다. 그들은 항상 자신의 능력 한계까지 밀어붙이며, 가장 영리한(clever) 코드를 작성하기 위해 노력합니다. 그들은 가능한 한 빨리, 빠르게 움직이는 데만 집중합니다. 불행히도 이 록스타들이 가장 신경 쓰지 않는 마지막 것은 바로 '다른 사람들이 작업할 수 있는 코드'를 작성하는 것입니다.

인공지능의 등장 지난 몇 년 동안, 대부분의 팀은 록스타 군대의 침공에 압도당했습니다. 누군가 새로운 채팅을 시작할 때마다, 팀에 새로운 록스타를 추가할 위험이 따릅니다. 이 AI 에이전트는 어제 자신이 무슨 짓을 했는지 기억하지 못합니다. 그저 기꺼이 몇 분 만에 수만 줄의 코드를 쏟아냅니다. 인간의 한계를 벗어나 비인간적으로(unhumanly) 빠르게 작업을 완료하는 데에만 집중합니다. 이 코드가 시스템의 다른 모든 코드와 잘 맞을지는 신경 쓰지 않습니다. 시스템이 더 이해하기 쉬워지는지, 아니면 더 최악이 되는지도 관심이 없습니다. AI는 아마도 현재 상황에 적용되지 않을 '모범 사례(best practices)' 도구 상자를 가지고 있습니다. 복잡성이 이점을 능가할 때조차, 안전장치를 두 번 세 번 치장하는 '벨트와 멜빵(belt and suspenders)' 방식을 고집합니다. 당신의 코드 리뷰를 요청받으면, 당신이 동의하지 않는 수많은 개선 사항들이 담긴 긴 목록을 쏟아냅니다. 모든 사람에게 기준이 높아졌고, LLM(대형 언어 모델)을 사용하지 않으면 영원히 뒤처질 것이라고 느끼는 사람들이 많아졌습니다. (비록 LLM에게 모든 코드 작성을 맡겨버리는 사람들이야말로 결국 도태될 것이라고 저는 믿지만요.) 생성된 코드가 너무 많아지면 시스템의 복잡성은 기하급수적으로 증가할 수 있습니다. 너무 복잡해서 그 의미를 파악할 유일한 방법이 LLM을 사용하는 것밖에 없을 정도가 될 수도 있습니다. 개발자, 팀, 심지어 기업 전체가 생성형 AI에 중독되고 의존하게 될 수 있습니다.

수백 명의 AI 록스타가 남긴 뒤처리 엉망진창인 코드 더미 앞에 앉는 것은 단순한 록스타의 뒤처리보다 결코 재미있지 않습니다. 적어도 과거의 록스타는 어떠한

원문 보기

원문 보기 (영어)

Cleaning up after AI rockstar developers Photo by Martijn Baudoin on Unsplash We've all worked with a rockstar developer. They joined the team years ago, full of energy. They had great ideas about new tech, new paradigms, new architectures. Their cutting-edge ideas left everyone else feeling a bit behind and outdated. They rewrote most of the company's core architecture. They introduced new build processes, new tools, new languages. They rejected most pull requests, raising the bar on what was expected of everyone else. Nobody understood the code they wrote but nobody would admit it. All the hardest tasks were assigned to the rockstar. They'd have it done faster than anyone else. The engineering always sounded very impressive, even if the rockstar was the only one who knew how it fit together. Everyone else was moving a lot slower in comparison. Everyone was struggling to keep up, to learn the new libraries, and to do things the rockstar way. A few years after they joined the team, suddenly they were gone. They had gotten bored, and wanted a better job working on a more challenging project at a bigger company. Dealing with the aftermath Suddenly, you were asked to take over the rockstar's projects. You dug into the code, and you found yourself buried alive. The flow of data was so hard to follow, it seemed like someone was trying to cover up a murder. You started with trying to fix a simple bug. Just getting the code to run on your laptop took a week. Half the code was written in a language you didn't understand. The other half was written using libraries you never heard of. You tried to tell your boss that you think the code needs a rewrite. They didn't believe you, because it was written by the rockstar himself. As you waded through the slop, you browsed job postings and fantasized about leaving. Cleaning up after a rockstar I've worked with many teams and agencies who needed me to clean up after these rockstars. I actually love the challenge of trying to understand and rescue a messy codebase. It's like sitting down with a box of tangled string lights, and pulling it apart until they're usable again. As I've gone through the process, I've seen some patterns. These rockstars absolutely love coding, learning, and using new paradigms, and it shows. They're always pushing themselves to the edge of their abilities, writing the most clever code they can. They are focused on moving as fast as they can. Unfortunately, the last thing these rockstars care about is writing code that others can work with. Along comes artificial intelligence In the past years, most teams have been overwhelmed by an army of rockstars. Every time someone starts a new chat, there's the risk of adding a rockstar to the team. The agent doesn't remember anything it did yesterday. It happily generates tens of thousands of lines of code in minutes. It works to complete tasks as fast as unhumanly possible. It doesn't care whether this code will fit with all the other code in the system. It also doesn't care whether the system is becoming more understandable, or worse. The AI has a toolbox of best practices that probably don't apply here. It insists on the "belt and suspenders" way of doing things, even when the complexity outweighs the benefit. When asked to review your code, it comes up with a long list of improvements, many of which you disagree with. The bar has been raised for everyone, and many feel they need to use LLMs or else they'll fall behind forever. (Though I believe it'll be those who let LLMs write all their code who will ultimately be left behind.) With so much generated code, the complexity of a system can grow exponentially. It can be so complex that the only way to make sense of it is to use an LLM. Developers, teams, whole companies can become addicted and dependent on generative AI. Cleaning up after hundreds of AI rockstars Sitting down with a pile of slop isn't as fun as cleaning up after a rockstar. At least the rockstar had some kind of design in mind, and was trying to do their best. A vibe coded pile of slop wasn't written by a single artificial developer. It was generated across many different chats, and many different contexts. It's like a codebase written by hundreds of different rockstars, one feature or bugfix at a time. Sometimes there's so much technical debt that it can never be paid off. Building software that lasts There are many ways to use an LLM that don't allow it to act like a rockstar. You can lead the engineering, and guide the LLM to generate small snippets at a time. You can ensure that the software is written in a way that everyone on your team will be able to understand and work with it easily. If you find yourself lost, unable to understand what the LLM is doing or why, tap the brakes. It's okay to move slower, to ensure the software you're generating is high quality. It's also okay to prevent over-engineering, to simplify and simplify until the architecture matches the complexity of the problem. It's also okay to leave your LLM in the toolbox sometimes, and to write code yourself. Craftsmanship will always be in our hands, it's one thing we can never outsource to a machine. Published on June 8th, 2026. © Jesse Skinner

AI 코딩 기술 부채 LLM 소프트웨어 개발 코드 리뷰