# AI 록스타 개발자들의 뒷정리 > Clean Markdown view of GeekNews topic #30332. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=30332](https://news.hada.io/topic?id=30332) - GeekNews Markdown: [https://news.hada.io/topic/30332.md](https://news.hada.io/topic/30332.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-06-10T09:06:54+09:00 - Updated: 2026-06-10T09:06:54+09:00 - Original source: [codingwithjesse.com](https://www.codingwithjesse.com/blog/rockstar-developers/) - Points: 1 - Comments: 2 ## Topic Body - 과거 ‘록스타 개발자’가 남긴 이해하기 어려운 코드베이스 문제가 LLM 생성 코드 확산으로 팀 전체의 **유지보수 부담**으로 커짐 - 록스타 개발자는 새 기술, 새 패러다임, 새 아키텍처를 빠르게 도입하고 어려운 일을 빠르게 끝냈지만, 다른 사람이 이해하고 함께 작업할 수 있는 코드 작성에는 관심이 낮았음 - LLM 에이전트는 이전 작업을 기억하지 못한 채 짧은 시간에 수만 줄의 코드를 만들고, 시스템 전체와 맞는지나 이해 가능성이 좋아지는지에는 신경 쓰지 않음 - 생성 코드가 많아질수록 시스템 **복잡도**가 크게 커지고, 이를 이해하기 위해 다시 LLM에 의존하는 흐름이 생길 수 있음 - 오래가는 소프트웨어에는 LLM을 작은 코드 조각 생성에 제한하고, 사람이 설계를 이끌며, 문제 복잡도에 맞게 아키텍처를 단순화하는 태도가 필요함 --- ### 록스타 개발자가 남긴 구조 - 록스타 개발자는 팀에 합류한 뒤 새 기술, 새 패러다임, 새 아키텍처에 대한 강한 아이디어를 제시함 - 회사 핵심 아키텍처 대부분을 다시 작성하고, 새 빌드 프로세스와 도구와 언어를 도입함 - 많은 풀 리퀘스트를 거절하며 팀원들에게 요구되는 기준을 높였고, 다른 사람들은 그 코드 이해 여부를 드러내지 못함 - 가장 어려운 작업은 록스타 개발자에게 배정됐고, 그는 다른 사람보다 빠르게 끝냄 - 다른 팀원들은 새 라이브러리를 배우고 록스타 개발자의 방식에 맞추느라 더 느리게 움직임 - 몇 년 뒤 록스타 개발자는 더 어렵고 큰 회사의 프로젝트를 원해 팀을 떠남 ### 여파 다루기 - 남은 팀원은 록스타 개발자의 프로젝트를 넘겨받고, 코드 속에서 압도되는 상황을 겪음 - 데이터 흐름은 따라가기 어려웠고, 마치 누군가 살인을 은폐하려는 것처럼 느껴질 정도였음 - 단순한 버그 수정부터 시작했지만, 노트북에서 코드를 실행하는 데만 일주일이 걸림 - 코드 절반은 이해하지 못하는 언어로 작성됐고, 나머지 절반은 들어본 적 없는 라이브러리로 작성됨 - 코드 재작성이 필요하다고 상사에게 말했지만, 록스타 개발자가 작성한 코드라는 이유로 받아들여지지 않음 - 난잡한 코드를 헤매는 동안 구인 공고를 보며 떠나는 상상을 하게 됨 ### 록스타 뒤 정리하기 - 여러 팀과 에이전시는 이런 록스타 개발자가 남긴 코드베이스 정리를 필요로 함 - 복잡한 코드베이스를 이해하고 구하는 과정은 엉킨 전구 줄을 다시 쓸 수 있게 푸는 일에 비유됨 - 록스타 개발자들은 코딩, 학습, 새 패러다임 사용을 좋아하며 자신의 능력 끝까지 밀어붙임 - 가능한 한 영리한 코드를 작성하려 하고, 최대한 빠르게 움직이는 데 집중함 - 다른 사람이 함께 작업할 수 있는 코드를 작성하는 일은 록스타 개발자에게 가장 낮은 우선순위가 됨 ### 인공지능의 등장 - 최근 몇 년 동안 많은 팀은 록스타 개발자 군단에 압도되는 상황을 겪음 - 누군가 새 채팅을 시작할 때마다 팀에 록스타 개발자를 추가하는 위험이 생김 - 에이전트는 어제 한 일을 기억하지 못하고, 몇 분 만에 수만 줄의 코드를 생성함 - 에이전트는 인간적으로 불가능할 만큼 빠른 속도로 작업 완료를 추구함 - 생성된 코드가 시스템의 다른 코드와 맞는지, 시스템이 더 이해하기 쉬워지는지에는 관심을 두지 않음 - AI는 상황에 맞지 않을 수 있는 모범 사례 도구상자를 가지고 있음 - 복잡성이 이익보다 커질 때도 AI는 “벨트와 멜빵” 방식의 과도한 안전장치를 고집함 - 코드 리뷰를 요청하면 동의하기 어려운 항목이 많은 긴 개선 목록을 만들어냄 - LLM을 쓰지 않으면 영원히 뒤처질 것처럼 느끼는 사람이 많아짐 - LLM이 모든 코드를 작성하게 두는 방식은 결국 뒤처지는 결과로 이어진다고 봄 ### 수백 명의 AI 록스타 뒤 정리하기 - 난잡한 생성 코드 더미를 정리하는 일은 록스타 개발자 한 명의 코드를 정리하는 것만큼 즐겁지 않음 - 적어도 록스타 개발자에게는 어떤 설계 의도가 있었고, 최선을 다하려는 시도가 있었음 - 바이브 코딩으로 만들어진 난잡한 코드 더미는 한 명의 인공 개발자가 작성한 것이 아님 - 여러 채팅과 여러 맥락에서 기능 하나 또는 버그 수정 하나씩 생성된 코드베이스가 됨 - 이는 수백 명의 서로 다른 록스타 개발자가 작성한 코드베이스와 비슷함 - 어떤 경우에는 기술 부채가 너무 커져 절대 갚을 수 없는 수준이 됨 ### 오래가는 소프트웨어 만들기 - LLM을 록스타 개발자처럼 행동하지 못하게 사용하는 방법은 여러 가지가 있음 - 사람이 엔지니어링을 이끌고, LLM에는 한 번에 작은 코드 조각만 생성하도록 안내할 수 있음 - 팀원 모두가 쉽게 이해하고 작업할 수 있는 방식으로 소프트웨어가 작성되도록 확인해야 함 - LLM이 무엇을 왜 하는지 이해하지 못한 채 길을 잃었다면 속도를 늦춰야 함 - 생성하는 소프트웨어의 품질을 보장하기 위해 더 천천히 움직이는 것은 괜찮음 - 과잉 엔지니어링을 막고, 아키텍처가 문제의 복잡도와 맞을 때까지 계속 단순화해도 괜찮음 - 때로는 LLM을 도구상자에 그대로 두고 직접 코드를 작성해도 괜찮음 - 장인정신은 항상 사람의 손에 남아 있으며, 기계에 아웃소싱할 수 없는 영역임 ## Comments ### Comment 59301 - Author: neo - Created: 2026-06-10T09:39:18+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=48458586) - 장인정신이 항상 사람 손에 남아 있고 기계에 절대 외주화할 수 없다는 마지막 문장은 조금 걱정됨 다른 산업에서도 장인정신이 죽은 건 아니지만, 훨씬 싸고 구하기 쉬운 대안에 밀려났음. 수제 가죽 신발은 여전히 살 수 있지만 $1000 이상 내고 싶어 하는 사람은 적고, 몇 주를 들인 그림도 살 수 있지만 대부분은 HomeGoods에서 벽 장식과 잡화를 삼 핵심 차이는 **일회용이라는 전제**인데, 안타깝게도 소프트웨어도 점점 다른 제품처럼 “일회용”이 되어가고 있음. 단순 카운트다운 앱이면 버려도 되지만, 오래 돌아가는 업무 프로세스를 떠받치는 소프트웨어는 그렇게 다루면 안 됨 소프트웨어 장인정신에 초점을 맞추면 문제가 “내 용도에 필요한 것” 대 “부티크스럽고 비싸며 불필요한 것”으로 보일 수 있음. 실제로는 “유지보수 가능하고 신뢰할 수 있는 것” 대 “버려도 되는 것”이어야 함 이 흐름이 OpenAI나 Anthropic 같은 대형 모델 제공자에게 이득이 되는지와는 별개로, 여기서 말하려는 요지는 그게 아님 - 다른 산업의 장인정신은 소프트웨어에서 말하는 방식으로 죽어가는 게 아님 납작한 박스에 담겨 와서 내가 드라이버로 조립한 싼 책상도 공장에서 대량생산됐지만, 그 **설계**에는 맞춤 제작품보다 훨씬 많은 전문가의 장인정신이 들어갔을 수 있음. 높은 초기 설계 비용을 들인 뒤 낮은 한계비용으로 대량생산하는 구조임 소프트웨어는 처음부터 대체로 그런 상태였음. Firefox를 내려받을 때 장인이 나만을 위해 웹 브라우저를 만드는 게 아니라, 어딘가 데이터센터의 CDN 서버가 캐시에서 바이트를 복사해 주는 것임 AI가 위협하는 건 다른 산업에서 대규모로 일어난 적이 없는 **초기 투자형 장인정신**의 대체임. AI가 더 성공적으로 대체한 건 저가의 “수공업적” 소프트웨어인데, 이 영역은 지금까지 경제성이 너무 낮아 사실상 존재하지 않았던 범주임 - 물리적 산업과 소프트웨어는 매우 다름. 가죽 신발은 고객마다 한 켤레씩 여러 번 만들어지지만, 코드는 한 번 만들고 모든 고객이 같은 제품을 씀 그래서 **품질 투자**에 훨씬 큰 지렛대가 생김 소프트웨어가 같은 의미로 일회용이라는 데도 동의하기 어려움. 임시 문제라면 코드를 버리고 다른 문제가 생길 때 새로 만들 수 있음. 하지만 지속되는 문제라면 코드는 계속 남음 - 기계가공 쪽에서 보면 흥미로운 관점이 있음 나사는 한때 맞춤 제작되는 귀한 물건이었고, 좋은 나사 하나를 만드는 데 엄청난 시간과 노력이 필요했음. 지금 우리가 **기계 나사**라고 부르는 것도 매우 숙련된 사람이 극도의 노동을 들여야 만들 수 있었음 그런데 기계는 장인정신을 옮길 수 있음. 정말 좋은 나사 하나를 만들면, 기계가 그 나사의 품질을 수많은 새 나사로 이전함 현대에는 모든 종류와 품질의 나사가 거의 똑같이 소모품이 됐고, 예전이라면 손으로 며칠이나 몇 주 걸려 깎았을 나사를 오늘날에는 수십억 개씩 만듦 AI도 리드스크루 없는 선반처럼 봄. 처음에는 직접 손으로 나사를 만들어야 하고, 그 뒤에는 내가 낼 수 있는 품질을 얼마든지 새 나사로 옮길 수 있음. 더 좋은 나사를 만들 수 있게 되면 그걸 선반에 넣고 더 나은 나사를 더 많이 만들 수 있음. 하지만 근본적으로는 내가 직접 만들 수 있는 나사의 품질에 제한됨. 삐뚤고 울퉁불퉁한 엉망만 만들 수 있다면 기계에서도 그 정도밖에 나오지 않음 - 그건 완전히 잘못된 관점임. 소프트웨어에서 “장인정신”에 해당하는 건 신발의 제조가 아니라 **신발 설계**에 가까움 소프트웨어 개발자는 고유한 지적 재산을 만들지, 소프트웨어 단위를 제조하지 않음. 책 저자나 음악가와 비슷함 소프트웨어에는 단위 제조에 해당하는 게 없음. 그냥 비트를 복사해 옮기는 일이기 때문임 따라서 소프트웨어 맥락에서 “장인정신”은 좋은 것을 설계하는 데 얼마나 신경 쓰느냐를 뜻함. 우리가 쓰는 소프트웨어의 품질조차 중요하지 않아지는 지점에 도달하지 않는 한 사라지지 않을 것이고, 지금 그런 방향으로 간다는 신호는 없음 - 수제 신발 비유는 한 사람만 쓰는 소프트웨어를 말하는 게 아니라면 맞지 않아 보임 더 적절한 비교는 신발 공장의 **제조 장비를 만들고 유지보수하는 엔지니어**일 수 있음. 소비자와는 한 단계 떨어져 있지만, 거기에도 분명 장인정신이 들어감 - AI나 외주 코드 고치는 일이 좋음. 지난주 어떤 고객이 부서용 도구를 바이브 코딩으로 만들려 했다는 걸 알게 됐는데, 결과물은 컴파일에 메모리 10GB가 필요한 거대한 **Next.js 쓰레기**였고 린트 오류가 수천 개, Git에는 시끄러운 개발 로그까지 들어 있었음 이제 우리가 고쳐야 하니 이런 일은 반복해서 1만~5만 유로짜리 공짜 일감이나 다름없음. 뭘 하는지 알면 아주 쉽고, 모르면 불가능함. 계속 더 가져오면 됨 - 어떤 면에서는 고객이 구현할 **명세와 UI 목업**을 준 셈임 - 이 말에 1000배 동의함 중소기업 대상 **침해 대응** 일을 하는데, 지난 몇 년 동안 감당하기 어려울 정도로 일이 늘었고 은행 계좌는 용의 금더미처럼 느껴짐 보안은 항상 통합되고 계획되어야 한다는 편이고, 침해 사고를 보고 싶다는 뜻은 전혀 아님 다만 애매한 전문성을 가진 사람들이 한 시간 만에 앱을 쏟아낼 수 있게 된 건 나와 비슷한 사람들에게 엄청난 횡재였음 - 이런 일에 집중하는 에이전시는 큰돈을 벌 것임. 이미 이런 일을 몇 건 받았고, 사람들이 제품을 **바이브 코딩**할 수 있다고 생각하는 한 계속 들어올 것임. 말한 대로 쉬운 돈임 - 많은 사람이 AI에 큰돈을 걸고 있음. 그중 일부는 유망하지만 모든 베팅이 성공하진 않을 것임 이런 사고방식은 사람들이 돈을 밀어 넣는 **인간 슬롯머신**이라고 보면 됨 - 본인이나 고객 신원이 드러나지 않는 선에서 실제로 어떻게 전개되는지 더 들려줄 수 있는지 궁금함 고객들이 찾아올 때는 처음부터 운영 환경으로 올리는 데 도움을 받으려던 건지, 아니면 AI 접근이 모두 실패한 뒤의 최후 수단인지 궁금함 이런 프로젝트가 보통 무너지는 방식이 있는지, 아니면 실패가 대체로 미묘한지도 궁금함 - 살면서 정말 뛰어나다고 부를 만한 사람들을 몇 명 만났음. “도대체 어떻게 이렇게 똑똑하지?” 싶은 사람들임 정말 똑똑한 사람들에게서 보이는 두 가지가 있는데, 보통 서로 배타적임. 하나는 자신이 얼마나 똑똑한지 모르는 경우임. 본인에게는 간단하거나, 자기가 아는 주제라서 컴퓨터과학 학위가 있는 사람이라면 다 알고 기억하고 이해한다고 가정함. 암호 관련 수학을 줄줄 말하는 친구들을 보며 “그 수업은 통과했지만 방금 네가 말한 주제를 내가 정말 안다고는 못 하겠다”고 느낀 적이 있음 다른 하나는 자신이 주변 대부분보다 똑똑하다는 사실을 고통스러울 정도로 늘 의식하는 사람들임. 일부는 못되게 굴고, 일부는 상대적으로 “멍청한” 사람들에게 둘러싸인 데 지쳐 있음. 후자에게는 어느 정도 공감함. 모든 것이 명확하고 뻔하고 쉽게 처리되는 삶을 살면서, 답이 오래전부터 알려져 있는데도 인류가 계속 어리석은 선택을 반복하는 걸 봐야 한다고 상상해 보면 됨 - 세 번째 문제도 있음. 훨씬 과반수의 사람들이 자신을 그 마지막 문장에 해당한다고 믿는다는 것임 - 스스로 책을 많이 읽었다거나 IQ가 높다고 주장하진 않지만, **상식처럼 느껴지는 작은 일들**에서는 비슷하게 느낌 사람들이 우왕좌왕하거나, X를 하면 명백히 나쁜 결과인 -Y가 나올 텐데도 X를 하는 걸 보면 미칠 것 같음. 대부분은 그냥 입 밖에 내지 않는 법을 배웠음 가까운 가족 관계에서는 특히 건강하지 않음. 너무 많이 보여서 잔소리로 죽일 수도 있겠다고 느낄 정도임 - 그런 사람들을 알고 만난 적은 있음 하지만 그 누구도 거대한 엉망을 쌓아 올려서 팀과 내가 몇 달씩 치우게 만든 **10x 개발자**는 아니었음 - 어떤 근본적인 특성에서 **특이점에 있는 사람**으로 사는 건 외로운 일임 아무리 노력해도 대부분의 사람과 관계 맺기 어렵고, 그들도 특히 나를 이해하기 어려워함. 살아온 경험의 차이가 매우 크고, 종종 넘기 어려움 - 많은 개발자는 그냥 일상 업무만 하거나 **카고 컬트**를 따르기로 선택함 모든 개발자가 같은 산출량을 낼 수는 없겠지만, 문화적 평균을 넘어 계속 생각하기로 결정하면 누구나 자기만의 방식으로 똑똑해질 수 있음 대부분은 자신이 그렇게 할 수 있다는 걸 깨닫지 못함 - 이 두 문장이 와닿았음 “데이터 흐름을 따라가기가 너무 어려워서 누군가 살인을 은폐하려는 것 같았다” “코드를 노트북에서 실행시키는 데만 일주일이 걸렸다” 데이터 흐름을 이해하거나 제대로 된 개발 환경을 세우는 데 어려움을 겪는 사람이 나뿐이라고 늘 생각했음. **가면 증후군**과 가끔은 “속도”를 밀어붙이는 유해한 환경도 도움이 되지 않았음 나만 그런 게 아니라는 걸 알게 되어 좋았음 - “코드를 노트북에서 실행시키는 데만 일주일이 걸렸다”는 부분은 놀라웠음 CLI의 **Claude Code**는 앱을 띄우고 임의의 의존성이나 Docker 관련 문제를 디버깅하는 일을 예전보다 훨씬 수월하게 만들어 줬음. 예전에는 아키텍처를 배우는 동시에 내 머신에서 안 되는 것까지 해결해야 했음 - 나만 그런 건 아님. 나도 같은 느낌을 받았고, 그런 지식은 대개 사람들 머릿속이나 임의의 Slack 스레드에 들어 있음 AI 코드에서는 더 심해짐. 당시 그럴듯해 보이는 걸 그냥 생성했을 뿐이기 때문임 - 남이 남긴 걸 치워야 하는 사람들이 조금 부러움. 적어도 퍼즐을 푸는 느낌은 있으니까 지금 일은 정말 지루함. 주니어도 할 수 있을 만큼 단순한 작업인데 굳이 **미드레벨 개발자**가 필요하다고 함. 내가 이 일보다 낫다는 말도 아니고, 미드레벨이 이런 일을 맡지 않는다는 말도 아님. 다만 이 회사가 만드는 코드에 관심을 갖도록 스스로를 밀어붙일 수가 없음. 낡고 먼지 쌓였고, 중요한 사람에게도 쓰이지 않음. 고객들은 한때 이 도구를 샀고, 재미없는 도구라 바꿀 만큼 관심이 없어서 쓰고 있을 뿐임 내 경험과 더 맞는 일이 곧 온다고 약속받았지만, 이런 정체된 회사에 그런 고객이 올 것 같지 않음 이 회사가 고객과 직원을 잃는 건 놀랍지 않음. 하지만 주택담보대출을 갚아야 함. 오늘은 계약을 연장하지 않을 수도 있다는 이야기를 들었고, 사실상 같은 급여로 더 많은 주인의식과 더 많은 일을 하라고 협박받은 셈임 안타깝게도 진짜로 흥미로운 새 자리를 찾을 때까지 버텨야 함. 돈이 많이 필요한 것도 아니고 “성장” 같은 건 전혀 관심 없음. 그냥 살아남을 만큼만 필요함 이 댓글이 많이 관련 없을 수 있는데, 사과함. 이걸 올릴 다른 배출구가 없음 - 혼자가 아님. Microsoft에서 정확히 같은 상황이었고 결국 사직서를 냈음 L63이었지만 하던 일은 L60~L61도 할 수 있는 수준이었고, David Graeber가 말한 **Bullshit Jobs** 중 하나에 있는 느낌을 자주 받았음. 보수는 넉넉했지만 입사 보너스 주식이 끝나자, 내가 안정성 때문에만 그 직장에 남아 있다는 걸 봤음 Hooli 사무실 테라스에서 주식 베스팅을 기다리며 일광욕하는 엔지니어 중 하나가 된 느낌이었음. 경력 9년 차인데 지금 내 커리어에 최선이라고 보이지 않았음 다만 나는 큰 재정 의무가 없어서 훨씬 쉬운 결정이었음 - 처음에는 “medior”가 “senior”의 이상한 오타인 줄 알았는데, 두 번 나온 걸 보고 찾아봤음. 유럽 일부 지역에서는 **중급**을 뜻하는 말로 쓰이는 듯함 - “이 회사가 만드는 코드에 관심을 갖도록 스스로를 밀어붙일 수가 없다”는 말에 매우 공감함 쓰레기 회사가 만드는 쓰레기 제품들이, 대부분의 게으름과 취향 없음에 기생하고 마케터들이 그걸 수익화함 이제 더 나쁘게도 전체 분야가 **LLM화**되면서 100배 증폭되고 있음. 코드를 유지보수 불가능하게 만들고, 더 나쁘게는 우리 모두를 더 멍청하게 만듦 우리가 이걸 발견하지 않았으면 좋았겠다고 진심으로 생각함 - 지금 작업 중인 코드베이스를 잘 들여다보면, 남이 남긴 것이든 본인이 남긴 것이든 치울 기회가 꽤 많을 것 같음 - “같은 급여로 더 많은 주인의식과 더 많은 일을 하라고 협박”했다는 부분이 조금 궁금함 단순히 추가 근무와 쓸데없는 업무를 하라는 뜻인지, 실제로 더 많은 코딩 기회가 있는 건지, 아니면 갑자기 더 가치 있다는 걸 증명하라는 기대인지 궁금함 겪은 일을 가볍게 보려는 건 아님. 후자라면 실제로 뭔가 해볼 수 있는지 궁금함 - 처음 몇 섹션이 와닿았음. 예전에는 내가 **록스타 개발자**였던 것 같은데, 그게 좋은 게 아니라는 걸 깨달았음 동료들보다 10배 빠르게 일을 끝낼 수 있었을지도 모름. 하지만 어느 순간 그게 내가 보통 사람보다 10배 생산적이어서가 아니라, 내 작업 방식이 주변의 보통 사람들을 1/10만큼 생산적으로 만들었기 때문이라는 걸 알게 됨 그 뒤로 속도를 늦췄고, 삶 전체에는 긍정적인 변화였음. 팀 플레이어가 되는 건 이 미친 업계에서 같은 수준의 상승 이동성을 주진 않지만, 정신건강에는 놀라울 만큼 좋았음 - 나도 과거에 록스타 방식으로 구현하다가 스스로 발등을 찍은 적이 분명히 있음 내 경우에는 대개 필요 없는 것을 **과도하게 추상화**하거나, 실제로 일어나지 않는 사용 사례를 위해 뭔가를 만드는 식이었음. 그래서 생각이 과도한 추상화 쪽으로 흘러갈 때마다 YAGNI와 KISS를 떠올리려 노력함 - 이 글은 가치가 너무 낮음 무엇을 말하려는 건지도 잘 모르겠고, 그냥 자기 등을 두드리는 글처럼 보임 - 나쁜 코드는 분명히 있음. 하지만 이 글은 “나쁜 코드”와 “복잡하고 크며 익숙해지는 데 시간이 걸리는 코드”를 뒤섞는 것처럼 보임 “록스타 개발자”가 남긴 **엄청난 양의 나쁜 코드**라고 불리는 것 중 상당수는 사실 요구사항 변화에 맞서 복잡도가 길고 느리게 조금씩 쌓인 결과였음 또 사람들이 “가독성을 위해 리팩터링한다”고 생각하지만, 실제로는 “코드를 다시 작성하면서 그 과정에서 이해하게 되는” 경우가 많았음 - 요약하면 “LLM을 사용할 때 속도를 늦추고 뭘 하는지 생각하라”임. 5분을 아껴줬음 더 많은 내용이나 실제 예제 같은 걸 기대했음. 글의 90%는 저자가 불평하고 문제를 정의하는 데 쓰고, 마지막에서 두 번째 단락에 손으로 휘저은 듯한 모호한 해결책이 나옴. 실제 관련성이나 유용성은 거의 없음 - 내가 만든 수익성 높은 두 프로젝트 주변의 인프라를 만들려고 **프로덕션 엔지니어** 두 명을 강하게 밀어붙인 건 정말 바보 같은 짓이었음 전부 10x 보스처럼 스파게티 코드로 만들고 Anthropic으로 옮겨 9자리 보상 패키지를 받았으면 훨씬 더 많은 돈을 벌 수 있었을 텐데. 멍청하고 또 멍청한 나였음 적어도 여기서 내가 얻은 결론은 그거임 - 작성된 코드는 대개 작성자가 아닌 누군가가 유지보수해야 함. 그러니 아무도 이해하지 못하는 코드를 쓰면 결국 **유지보수 실패**로 이어짐 팀이 이해하기 쉬운 코드, 속도, 기술적 탁월함 등 무엇을 최적화할지는 다를 수 있음 하지만 기술적 탁월함을 최적화했더라도 팀의 다른 누구도 그 코드를 이해하지 못한다면 여전히 실패임 과도하게 설계된 코드를 본 적이 있음 ### Comment 59295 - Author: neo - Created: 2026-06-10T09:06:55+09:00 - Points: 1 ###### [Lobste.rs 의견들](https://lobste.rs/s/uvwcdo/cleaning_up_after_ai_rockstar_developers) - 이 글에는 **실제로 쓸 만한 조언**이 별로 없음 - 누군가의 개인적 불만을 그럴듯하게 보이게 하려고 유행어 두 개로 포장한 느낌임 “록스타 개발자”라는 표현은 늘 의심스럽지만, 뛰어난 개발자는 실제로 존재함. 다만 그런 사람들은 글에서 묘사한 식으로 행동하지 않고, 기존 환경 안에서 가능한 만큼 일하며 코드베이스를 개선하고, 검증되지 않은 새것을 장난감처럼 들여오지 않으며, 테스트·스크립트화된 배포·린팅 등을 통해 떠날 때 더 안정적인 상태로 남겨둠 여기에 **AI**는 이런 행동이 더 나빠질 것이라는 식으로 덧붙여진 듯한데, 그럴 수는 있어도 아직 충분히 입증된 사실은 아닌 것 같음. 수십 년간 컨설턴트로 일하며 엉망인 코드베이스를 많이 정리했지만, 원인은 과하게 나간 사람들일 때도 있었고 더 나은 방법을 몰랐던 팀일 때가 더 많았음. 어느 경우에도 “록스타/닌자/유행어 개발자가 했겠군”이라고 생각한 적은 없음 - 이제 챗봇이 머리 위에 쏟아낸 쓰레기를 치우는 것뿐 아니라, 그걸 신경 쓰지 않는 사람들 뒤처리까지 해야 하는 건가 싶음 **거품이 꺼지기**만 기다리게 됨 - 원래도 늘 이랬고, **AI가 문제를 증폭**할 뿐임. 반대로 정리 작업이 더 쉬워졌다고도 볼 수 있음 - 2026년에 어떤 회사에 합류했는데 아직 **create-react-app**을 쓰고 있다는 걸 알게 되면, 실제로 권장되는 행동 방식이 뭔지 궁금함. 그냥 아무 말도 하지 말라는 건가? - 새 프로젝트라면 이제 **deprecated**되었고 더 이상 권장되지 않는다고 말하면 됨 오래된 프로젝트라면 기술 부채를 발견한 것임. 누구에게나 있음. 이런 걸 고치자고 설득하는 가장 좋은 방법은 사업적으로 납득되는 근거를 만드는 것임. 동작한다면 정말 리스크인가? 다른 기술 부채와 비교하면 우선순위가 어떤가? 업그레이드하지 않으면 어떤 암묵적 위험을 떠안는가? 업그레이드에 필요한 노력은 어느 정도인가? 노력이 적고 동료들도 원한다면 허락을 구하지 않고 그냥 작업하는 방법도 있음. 다만 이 변경의 영향을 받는 사람들의 지지가 있고, 본인 산출물에 방해되지 않을 때 가장 잘 통함. 입사 첫 주에 할 일은 아닐 수 있음 보통은 “어떻게 되어야 한다”고 말하기보다, 왜 지금 이렇게 되어 있는지 질문하고 알아보는 편이 항상 더 좋음. 역사가 있는 모든 코드베이스는 아직 모르는 수천 가지 결정의 결과물임. 지식과 공감으로 무장해야 함 - 합류했을 때는 다르게 해야 할 모든 것을 지적하기 전에 먼저 관찰하는 편을 선호함. 새 사람이 팀에 들어올 때 모든 것을 바꾸는 것과, 실제로 **영향이 있는 일**에 집중하는 것 사이에는 균형이 있음. 합류 직후에는 무엇이 영향을 만드는지 아직 모름 - 어떤 싸움을 고를지에 따라 다름. 개인적으로는 그만한 가치가 없다고 보지만, 나는 당신이 아님. **레거시 코드**는 어디에나 있고, create-react-app 같은 프레임워크에서 벗어나 다시 작성하는 비용은 사람들이 이미 익숙한 상태로 버티는 비용보다 훨씬 큼 - 웹 개발자가 아니라서 그런데, 이 질문의 의미가 뭔가? **create-react-app**이 낡았다는 뜻인가, 아니면 React가 낡았다는 뜻인가? - 사람들이 이제 **CRA**를 싫어한다는 게 너무나도 확인받는 느낌이라 알려주고 싶음 2020년에 아직 멋져 보이던 시절부터 싫어했음 - “에이전트는 어제 자신이 한 일을 아무것도 기억하지 못한다”는 건 해결 가능한 문제임. 메모리 접근법 등을 쓰면 됨. 보편적으로 좋은 건 아니지만 점점 나아지는 중임 “이 코드가 시스템의 다른 코드와 잘 맞을지 신경 쓰지 않는다”는 건 내 경험과는 다름. 보통 **LLM 생성 코드**는 관련 영역의 유사한 코드와 꽤 비슷해지는 경향이 있음. 방향을 잡기 위해 읽은 코드가 거의 그대로 반영됨 “시스템이 더 이해하기 쉬워지는지, 더 나빠지는지 신경 쓰지 않는다”도 해결 가능함. LLM으로 이를 평가하게 하고 점진적으로 낮추면 됨. 어떤 것이 이해하기 쉬운지는 시스템의 비결정적 속성인 경우가 많아서, 역설적으로 다른 도구보다 LLM이 측정하기 쉬운 접근일 수 있음. 새 세션에서 “이 새로 추가된 코드를 이해하려면 시스템의 어느 정도를 이해해야 하는가”라고 묻고 그 범위를 줄이는 식으로 최적화할 수 있음 “AI는 여기에는 맞지 않을 수도 있는 모범 사례 도구상자를 갖고 있다”는 부분은, AI를 쓰는 과정이 새 프로젝트에 같은 이상을 갖고 들어온 **주니어 개발자**를 훈련하는 것과 비슷할 때가 많음. 주니어에게는 말로 알려주고 그 지식을 기억해 응용하길 기대하지만, AI에는 AGENTS.md / CLAUDE.md 파일에 문서화하면 그 지식이 계속 남음 “코드 리뷰를 부탁하면 동의하지 않는 개선점이 잔뜩 나온다”는 건 Codex 기준으로는 목록을 작고 간결하며 가치 높게 유지하도록 조정되어 있음. 다른 모델은 다를 수 있지만, 이것도 결국 지시 수준의 문제임. 신경 쓰는 사항은 문서화할 가치가 있는 경우가 많고, AI를 쓰면 그게 필요해짐 - 록스타를 상대할 때 문제의 절반은 **자아**지만, 그래도 사람이 쓴 코드를 남긴 록스타에게는 그걸 뒷받침하는 성찰과 의도가 있었음 반대로 AI 위에 인간 껍데기만 씌운 “록스타”들은 허세는 같거나 더 큰데, 자신들이 해결한다고 주장하는 문제의 절반조차 완전히 모르는 경우가 있음 - **함수형 프로그래밍** 접근을 최대한 적용해, 서로 다른 방식으로 끼워 맞출 수 있는 문맥 독립적인 구성요소를 만들면 상당한 지렛대를 얻을 수 있음 구현 세부사항을 추상화한 개별 빌딩 블록과 특정 문맥에 의존하는 작업을 분리해두면, 요구사항이 바뀌거나 다른 접근을 택할 때 블록을 쉽게 재배치할 수 있음. 또 전체 배치 맥락을 몰라도 각 조각을 독립적으로 추론할 수 있고, 그 조각들을 어떻게 맞물렸는지를 보면 상위 수준 로직을 이해할 수 있음 함수형 언어는 **LLM과 함께 작업**하기에 좋은 기반을 제공함. 코드를 문맥을 제한하는 방식으로 자연스럽게 쓰게 만들기 때문임. 이는 프로그램의 특정 기능을 이해하는 데 필요한 범위를 줄여 모델과 인간 사용자 모두에게 도움이 됨