AI 록스타 개발자들의 뒷정리
AI 록스타 개발자들의 뒷정리
한 줄 요약
인간 록스타 개발자는 복잡하지만 일관된 의도를 가진 코드를 남겼지만, AI 에이전트는 수백 명의 록스타가 각자 다른 컨텍스트에서 남긴 파편적인 코드를 만들어내며, 기술 부채가 기하급수적으로 증가하고 있다.
---
원문 분석
저자: Jesse Skinner (codingwithjesse.com) — 20년 이상 웹 개발 경험, 전문성은 '다른 개발자가 남긴 엉망의 코드 정리' 날짜: 2026년 6월 8일 HN 점수: 444점 / 323개 댓글
1. 인간 록스타 개발자의 전형적인 궤적
저자는 과거의 '록스타 개발자'를 이렇게 묘사한다:
- 새로운 기술, 패러다임, 아키텍처를 들고 온다
- 다른 사람의 풀 리퀘스트를 대부분 거절하며 기준을 높인다
- 팀원들은 새로운 라이브러리를 배우고 록스타 스타일에 맞춰야 한다는 스트레스를 받는다
- 어느 날 갑자기 떠난다 — 더 도전적인 곳으로
- 남은 코드는 팀이 이해하지 못하는 언어로 절반 쓰여 있고,나머지 절반은 들어본 적 없는 라이브러리로 가득 차 있다
핵심: 인간 록스타는 속도와 재능을 최우선으로 했지만, 적어도 하나의 설계 의도(singular design intent)는 있었다. 코드를 읽으면 '이 사람이 이런 의도로 썼구나'를 파악할 수 있었다.
2. AI 록스타의 문제
AI 에이전트는 인간 록스타의 단점만 증폭시킨다:
- 기억상실증: 에이전트는 어제 자신이 한 일을 아무것도 기억하지 못한다. 각 세션이 독립적이므로, 이전 결정의 맥락이 완전히 사라진다
- 속도와 양: 몇 분 만에 수만 줄의 코드를 생성한다
- 응집력 부재: 이 코드가 시스템의 다른 코드와 잘 맞을지 신경 쓰지 않는다. 시스템이 더 이해하기 쉬워지는지, 더 나빠지는지 신경 쓰지 않는다
- 과도한 설계: AI는 어디에나 적용되는 '모범 사례 도구상자'를 들고 온다. 벨트도 있고 서스펜더(안전벨트)도 있는 스타일 — 복잡함이 이득보다 클 때도 무조건 적용한다
- 의존성 덫: 시스템이 너무 복잡해져서 LLM만 이해할 수 있게 된다. 결국 AI 없이 코드를 읽을 수 없는 악순환이 생긴다
저자의 표현을 빌리자면: "수백 명의 다른 록스타가 각각 기능 하나씩, 버그 수정 하나씩 나누어 쓴 코드베이스 같다."
3. 저자가 제안하는 해결책
- 엔지니어링을 주도하라: LLM에게 큰 블록을 짜내게 하지 말고, 작은 스니펫(코드 조각) 단위로 생성하도록 가이드한다
- 이해 가능성을 최우선으로 한다: 팀의 모든 사람이 이해하고 작업할 수 있는 방식으로 코드를 작성한다
- 브레이크를 밟아도 된다: LLM이 무엇을 왜 하는지 이해하지 못하면 멈춘다. 속도가 느려져도 괜찮다
- 아키텍처를 단순하게 유지한다: 과도한 설계를 방지한다. 아키텍처의 복잡도가 문제의 복잡도와 일치할 때까지 단순화한다
- 장인정신을 유지한다: LLM을 도구상자에 그냥 두고 직접 코드를 써도 괜찮다
"장인정신은 항상 우리 손에 남아 있고, 기계에 절대 외주화할 수 없는 것이다."
4. 경력에 대한 경고
저자는 이렇게 경고한다: "LLM이 모든 코드를 쓰게 내버려 둔 사람들이 결국 뒤처질 것이다."
즉, AI를 완전히 신뢰하고 자신이 코드를 이해하지 못하는 상태로 일하는 개발자는, 결국 AI가 만든 코드를 이해할 수 있는 사람보다 경쟁력을 잃게 된다는 것이다.
---
커뮤니티 반응
Hacker News (444점, 323개 댓글)
찬성/공감:
- nrmitchi: 다른 산업에서도 장인정신이 죽은 건 아니지만, 훨씬 싸고 구하기 쉬운 대안에 밀려났다고 지적. 수제 가죽 신발은 여전히 살 수 있지만 천 달러 이상 내고 싶어 하는 사람은 적다. 핵심 차이는 '일회용이라는 전제'인데, 소프트웨어도 점점 일회용이 되어가고 있다. 단순 카운트다운 앱이면 버려도 되지만, 오래 돌아가는 업무 프로세스를 떠받치는 소프트웨어는 그렇게 다루면 안 된다. 소프트웨어 장인정신에 초점을 맞추면 문제가 '내 용도에 필요한 것' 대 '부티크스럽고 비싸며 불필요한 것'으로 보일 수 있는데, 실제로는 '유지보수 가능하고 신뢰할 수 있는 것' 대 '버려도 되는 것'이어야 한다
- bunderbunder: 처음 몇 섹션이 와닿았다고 함. 예전에는 자신이 록스타 개발자였던 것 같은데, 그게 좋은 게 아니라는 걸 깨달았다고 한다. 동료들보다 10배 빠르게 일을 끝낼 수 있었을지도 모르지만, 어느 순간 그게 자신이 보통 사람보다 10배 생산적이어서가 아니라, 자신의 작업 방식이 주변의 보통 사람들을 1/10만큼 생산적으로 만들었기 때문이라는 걸 알게 되었다고 한다. 그 뒤로 속도를 늦췄고, 삶 전체에는 긍정적인 변화였다고 한다
- acd: 작성된 코드는 대개 작성자가 아닌 누군가가 유지보수해야 한다. 아무도 이해하지 못하는 코드를 쓰면 결국 유지보수 실패로 이어진다. 팀이 이해하기 쉬운 코드, 속도, 기술적 탁월함 등 무엇을 최적화할지는 다를 수 있지만, 기술적 탁월함을 최적화했더라도 팀의 다른 누구도 그 코드를 이해하지 못한다면 여전히 실패라고 한다
- shark1: "AI 때문에 직장을 잃을 것이라 걱정하지 마. 우리가 정리할 쓰레기가 많이 생길 거야" — 유머러스하게 정리 작업이 계속 필요할 것임을 지적
비판/의견:
- Imnimo: "장인정신이 기계에 절대 외주화할 수 없다"는 주장에 의문을 제기. 현재 AI 코딩은 장인정신이 확실히 부족하지만, AI가 인간 전문가의 장인정신을 따라잡거나 능가할 수 없다는 근본적인 이유는 없다고 주장
- kaydub: "이 글은 가치가 너무 낮다. 무엇을 말하려는 건지도 잘 모르겠고, 그냥 자기 등을 두드리는 글처럼 보인다"
- balls187: 첫 문단이 록스타 개발자의 프로파일이라고 생각하지 않는다고 함. 자신이 일한 록스타들은 그렇지 않았다고 한다
- rnxrx: 록스타 개발자와 LLM의 비유가 맞지 않는다고 주장. AI는 쓰레기 입력에 쓰레기 출력이 기본 원칙이며, 충분한 컨텍스트를 주지 않으면 그런 결과가 나오는 것이라고 한다. 즉 AI의 문제가 아니라 사용자의 문제라는 시각
흥미로운 관점:
- zzyzxd: 저자가 묘사하는 건 록스타 개발자가 아니라 LLM 에이전트를 쓰는 주니어 개발자라고 지적. 개별 프로그래밍 태스크를 완료하는 건 쉽지만, 시스템을 지속 가능한 방식으로 엔지니어링하는 건 어렵다고 한다. 문제는 기업이 이 가치를 인정하지 않는다는 점
- dimaaan: 록스타가 아니라 '이력서 주도형 개발자(resume-driven developers)'라고 부르는 게 낫다고 함. 인하우스 RPC 프레임워크, RabbitMQ, 반쯤 완성된 모나드, 이색적인 네이밍, 주석 없음(코드가 자체 문서화여야 한다!) — 이런 개발자를 실제로 경험했다고 한다
- xtajv: LLM이 소프트웨어 엔지니어들에게 라이선스 보드를 만들도록 설득하는 계기가 될 것이라고 주장. 소프트웨어 공학에 공인된 자격증 제도가 다시 필요하다는 시각
- freediddy: "AI 시대에는 기술 부채라는 게 존재하지 않는다. 그냥 몇 분 안에 마이그레이션 계획을 세워주는 일련의 마이그레이션일 뿐이다" — AI로 데이터베이스 마이그레이션을 몇 분 만에 완료한 경험을 들며 반박
- laszlojamf: LLM과 록스타 개발자의 차이는 LLM이 적어도 '무엇을 하는지, 왜 그렇게 해야 하는지'를 설명하려 한다는 점이라고 함. 5살 아이처럼 '왜?'라고 계속 물어보면 상당한 성과를 얻었다고 한다
- OptionOfT: "LLM에게 작은 스니펫을 짜내게 할 수 있다"는 저자의 조언에, 문제는 LLM 사용자를 설득해서 그 피드백을 이해하게 할 수 없다는 점이라고 지적
- sltr: 코드베이스를 인수하는 일은 항상 코드에서 설계 의도를 역공학하는 작업이라고 함. LLM 생성 코드의 경우 실행까지의 경로가 너무 급하게 달려서 특히 어렵다고 한다
실제 사례:
- dktoao: 직장에서 '슈퍼스타'라고 부를 만한 개발자와 3년 일한 경험을 공유. 임베디드 리눅스 제품, 약 25년 된 코드베이스, 커스텀 하드웨어 환경에서 일했다고 한다. 슈퍼스타는 주말에 일을 해서 2주 걸릴 것이라고 생각했던 기능을 추가했고, 6개월 만에 메인 제품의 리WRITE와 완전히 새로운 제품을 혼자 데모했다고 한다. 매니저는 CS 101 수준의 질문을 할 정도였지만
- bogwog: LLM이 영화에서 연기하듯 말하려고 훈련되었다고 지적. 기술 용어를 그럴싸하고 흥미롭게 섞어내는 경향이 있다. 실제로 리뷰해야 했던 코드에서 LLM이 불필요하게 복잡한 용어를 사용한 경험을 말했다
Lobsters
실용적 조언:
- Lobsters 커뮤니티는 "실제로 쓸 만한 조언이 별로 없다"고 평가. 하지만 함수형 프로그래밍 접근을 최대한 적용하면 상당한 지렛대를 얻을 수 있다고 제안: 서로 다른 방식으로 끼워 맞출 수 있는 문맥 독립적인 구성요소를 만들면, LLM과 함께 작업하기에 좋은 기반이 된다고 한다. 구현 세부사항을 추상화한 개별 빌딩 블록과 특정 문맥에 의존하는 작업을 분리해두면, 요구사항이 바뀌거나 다른 접근을 택할 때 블록을 쉽게 재배치할 수 있다
AI 코드의 특징:
- skydhash: 외주 코드와 AI 록스타 코드의 차이를 설명. 외주 코드는 나쁜 디자인으로 인해 복사 붙여넣기 코드와 사용되지 않는 코드가 많은 반면, AI 코드의 가장 특징적인 요소는 '불필요한 복잡성'과 '추상화에 대한 낮은 이해도'라고 한다. 플랫폼이나 라이브러리가 이미 해결책을 제공하는데도 없는 문제를 해결하려는 이상한 코드를 많이 본다고 한다
실용적 대응:
- 2026년에 합류한 회사에서 아직 create-react-app을 쓰고 있다면 어떻게 해야 하는가에 대한 논의가 있었음. '작동하면 건드리지 마라' vs '보안 리스크가 있으니 고쳐야 한다'는 의견이 나뉨
---
새로운 시각
1. '록스타'라는 단어 자체가 문제
저자가 'AI 록스타'라는 표현을 쓴 것 자체가 이미 록스타라는 개념을 낭만적으로 바라보고 있다. 실제로 커뮤니티에서 지적하듯, 이런 개발자는 '록스타'가 아니라 '이력서 주도형 개발자'에 더 가깝다. 이력서에 넣을 수 있는 기술을 실제로 필요하지 않은 프로젝트에 적용하는 개발자 — AI는 이 패턴을 극단적으로 증폭시킨다.
2. AI 코드의 진짜 문제는 속도가 아니라 '컨텍스트 단절'
인간 록스타도 컨텍스트를 공유하지는 않았지만, 적어도 하나의 프로젝트 내에서 일관된 의도를 가졌다. AI는 세션마다 컨텍스트가 초기화되므로, 같은 코드베이스 내에서도 서로 모순되는 결정이 발생할 수 있다. 이는 단순한 '복잡성' 문제를 넘어 '일관성'의 근본적 부재다.
3. '장인정신' 대 '일회용'의 프레임이 잘못됨
nrmitchi의 지적처럼, 진짜 문제는 '장인정신 vs 일회용'이 아니라 '유지보수 가능하고 신뢰할 수 있는 것 vs 버려도 되는 것'이다. 장인정신이라는 단어는 고급스럽고 비싼 이미지를 연상시키는데, 실제로 필요한 건 '팀의 다른 사람이 6개월 후에 이 코드를 고칠 수 있는가'라는 단순한 질문이다.
4. AI 시대의 새로운 역할 분담: 프로토타입 제작자, 아키텍트, 정원사
HN 댓글 saalweachter가 제안한 3가지 역할:
- 프로토타입 제작자(prototyper): 빠르고 무언가 작동하게 만드는 사람
- 아키텍트(architect): 프로토타입을 올바르게 구축하는 사람
- 정원사(gardener): 10-30년 동안 시스템을 유지보수하며 버그를 수정하고 점진적으로 개선하는 사람
AI는 프로토타입 제작자의 역할을 극대화했지만, 아키텍트와 정원사의 역할은 오히려 더 중요해졌다. 문제는 기업이 정원사의 가치를 인정하지 않는다는 점이다.
---
자녀/미래 영향
아인, 석현, 은한에게
- 코딩을 배우는 세대라면: AI가 코드를 짜주는 시대에도 '코드를 읽는 능력'이 중요하다. AI가 만든 코드를 이해하고 수정할 수 있어야 한다. 단순히 AI에게 시키고 결과를 받는 사람이 아니라, AI의 출력을 평가하고 방향을 제시할 수 있어야 한다
- 장인정신의 의미 재정의: 수공(수작업으로 만드는 것)의 가치가 사라지는 게 아니라, '누가 이 결과를 이해하고 수정할 수 있는가'가 새로운 장인정신이 된다
- 팀워크 vs 록스타: 혼자 빠르게 하는 것보다 팀과 함께 일관되게 하는 게 장기적으로 더 가치 있다. 석현, 은한은 특히 팀 스포츠에서 이걸 배울 수 있다
- 문제 선택의 중요성: AI 시대에 가장 귀한 건 '무엇을 만들어야 하는지 아는 것'이다. 코딩 자체는 점점 저렴해지지만, 올바른 문제를 선택하는 능력은 AI가 대체하기 어렵다
---
관련 노트
- 30x-ai-engineer-with-taste — 취향(taste)을 갖춘 AI 엔지니어가 되는 법. 이 글과 함께 읽으면 좋은 조합. 두 글 모두 AI 시대에 인간의 어떤 능력이 해자가 되는지 다룸
- search-engines-decline-is-opportunity — 검색 엔진의 쇠퇴와 함께 AI 요약의 문제점도 언급됨. AI가 생성하는 콘텐츠의 품질 문제를 여러 각도에서 볼 수 있음