요약
폴 배틀리가 Ruby와 Rails가 AI 쪽으로 돌아선 데 실망해 자신의 Ruby 젬 저장소를 모두 아카이브했습니다.
Ruby 젬(Ruby용 라이브러리 패키지)을 만들어 온 개발자 폴 배틀리의 글입니다. 그는 저장소를 아카이브(읽기 전용으로 잠그는 것)하고, 더는 손대지 않는 이유를 알리려고 각 저장소에서 이 글로 연결했습니다.
왜 중요한가
- 프로그래머의 행복과 사람을 앞세운 Ruby의 처음 철학이 AI 시대에 흔들린다는 문제 제기입니다.
- 공짜로 나눈 코드가 AI 학습에 쓰인다는 반감 때문에 유지보수자가 손을 뗀 사례입니다.
핵심 내용
- 거대 기업이 AI 학습용으로 마구 긁어 가는 공유 자산에는 더 기여하고 싶지 않다고 했습니다.
- Ruby 자체도 이제 LLM 에이전트(스스로 코드를 쓰는 AI 도구)로 주로 개발된다고 지적했습니다.
- 마쓰모토 유키히로(Matz)가 Ruby를 'AI 시대의 언어'로 내세우는 것도 문제로 꼽았습니다.
- Rails를 이끄는 DHH의 Rails World 2026 기조연설은 그가 프로그래밍 자체에 흥미를 잃었음을 보여 준다고 했습니다.
- Rust를 혹평하던 DHH가 이제 에이전트로 Rust 앱을 만들고 결과물은 검토하지도 않는다고 꼬집었습니다.
HN 반응
- 많은 이용자가 AI가 코드를 대신 쓰면서 코딩의 즐거움과 함께 만드는 재미가 사라졌다며 상실감을 털어놓았습니다.
- 반면 실무 대부분은 원래 재미없는 반복 작업이었고 이제 설계에 집중할 수 있어 오히려 홀가분하다는 반론도 많았습니다.
스타가 8만 개쯤 되는, 아주 유명한 오픈소스 프로젝트에 커밋하는 친구와 이야기를 나눴습니다. 그 친구가 환멸을 느끼는 건 로봇이 일을 못해서가 아닙니다. 로봇은 정말 잘합니다. 슬픈 건, 그 친구가 코드를 쓰고 커뮤니티와 함께 개선해 나가는 일을 좋아했다는 점입니다. 아주 인간적이고 협력적인 일이었으니까요. 로봇이 프로젝트를 훨씬 더 빠르게 밀고 나가고 보안과 성능에서도 놀라운 성과를 내고 있지만, 즐거움은 사라졌습니다.
저도 그 기분이 충분히 이해됩니다. 전문 수학자들도 아마 똑같은 기분일 겁니다.
코드 쓰는 게 좋아서 SWE가 된 사람이라면 누구나 이걸 겪고 있습니다. 저는 팀원들에게 이것이 정당한 상실감이고, 거기에 따르는 애도의 과정이 있다고 솔직하게 말했습니다. 자기만 그런 게 아니라는 걸 알게 되어 다들 도움이 됐습니다.
그리고 그 슬픔 너머에는 우리가 익숙했던 것과는 아주 다르지만, 새롭고 잠재적으로 흥미로운 무언가가 있다는 것도 말했습니다.
많은 분들처럼 저도 코드 쓰는 게 좋아서 SWE가 됐어요. 특히 Ruby는 (다른 장단점이야 뭐라고 생각하든) 아주 표현력이 풍부하고 아름다울 수 있죠.
하지만 대부분의 코드는 기업용 CRUD예요. 세상은 어찌 보면 CRUD로 돌아가죠. 그런데 이런 코드는 재미있거나 아름답거나 보람을 주는 경우가 드물어요. 아름답게 다듬을 시간이 거의 없으니 대개 꽤 못생기고요. 그러니 거기서 잃는 즐거움은 별로 없어요.
게다가 에이전트 워크플로를 쓰는데도 우리 팀은 아키텍처 문제를 여전히 깊이 고민해요. 잘 구조화된 코드는 봇에게도 사람에게도 더 낫다고 믿거든요. 그래서 저는 아직도 엔지니어링 두뇌를 쓰고 있어요. 이제는 벽돌을 직접 쌓는 대신 설계도를 그리고 벽돌공을 감독하는 셈이죠.
여러분 팀의 경험도 조금은 비슷한가요? 이런 글타래에 글을 쓰는 사람들은 평행 우주에서 일하는 것 같다는 생각이 들 때가 있어요. 거기서는 대부분의 코딩 업무가 어째서인지 보람 있고 재미있잖아요. 현실에서는 99%가 리포트 손보기, 난해하고 모순투성이인 비즈니스 로직 구현하기, 형편없고 짜증 나는 외부 요인과 씨름하기인데 말이죠. 어쩌면 그런 부분에서 즐거움을 찾는 사람도 있겠죠. 세상엔 별별 사람이 다 있으니까요. 하긴 저도 대부분의 개발자가 질색하는 SQL 쓰기를 좋아하는 변태거든요.
정말 멋진 일이네요! 세상 모든 리더가 이 정도 공감 능력의 절반만이라도 갖췄으면 좋겠어요. 잘하셨어요!
저는 업무용 소프트웨어에서 즐거움을 찾는 별난 사람 중 하나예요. 명확한 명세, 합리적인 일정, 충분한 기술적 자유가 있으면 깔끔하고 안전하고 견고한 아키텍처에 집중할 수 있거든요.
오히려 개인 프로젝트가 더 힘들어요. 학습 곡선의 초입에도 못 미치는 분야로 덤벼드는 버릇이 있어서, 결국 작업을 몇 번씩 다시 하게 되더라고요.
어디서 일하시는지는 모르겠지만, 회사의 90%는 그렇지 않습니다. 오히려 정반대입니다. 형편없는 경영진, 끔찍한 일정, 레거시 코드가 가득하죠.
회사에게 엔지니어링은 늘 골칫거리였고, 기술 부채를 해결하는 유지보수 승인을 받아내는 것조차 험난한 싸움이었습니다.
저도 즐거웠습니다.
재미있던 일 중 하나는 8시간 근무 중 4~5시간만 산출물 작업에 쓰는 것이었습니다. 그 정도면 보통 기대치를 넘기기에 충분했거든요. 남은 시간 중 2~3시간은 아키텍처를 크게 개선하는 데 썼고(1~2시간은 제 몫으로 챙겼습니다).
6개월에 한 번쯤 개선안을 내놓으면 앱이 갑자기 눈에 띄게 좋아졌고, 그 공은 제가 인정받았습니다.
와. 제가 업계에서 30년 가까이 일하는 동안에는 그런 경우가 거의 없었어요. 말씀하신 일을 저도 좋아하(했)지만... 그런 경우가 얼마나 흔했나요?
저는 다른 사람이지만 SWE 경력이 한 10년 됐는데, 제가 가장 좋아한 일은 남들이 남기고 간 CRUD 코드를 개선하는 것이었습니다. 예를 들면 REST API를 문서화하는 데 쓰던 독점 문서를 가져다가 OpenAI 스펙에 맞는 yaml 파일로 바꿔 주는 변환기를 만든 적이 있습니다. 단일 테넌트 애플리케이션을 안전한 멀티테넌트 애플리케이션으로 바꿔서 앱 서비스 80개를 2개로 줄였고, 모든 데이터 소스를 하나의 정규화된 DB로 통합했죠. 자랑스러운 작업이 많습니다. 저는 늘 “진흙탕 속에서” 레거시 코드를 고치고 나아지게 만드는 사람이었고, 그 일이 아주 보람 있고 흥미롭다고 느꼈습니다.
대단하네요! 저도 그런 일을 좋아하는데, 세월이 가면서 아주 냉소적이 됐어요. 누군가 기능을 더 더 더 내놓는 대신 기술 부채를 해결하려 들면, 경영진은 마치 엔지니어들이 가장 중요한 고객과 줌 회의를 하는 도중에 회의 테이블 한복판에 똥이라도 싼 것처럼 굴었거든요. 청구 가능한 에이전시 업무라면 더 싫어했고요.
엄청난 노력과 강력한 설득이 있으면 보통은 기술 부채 해결할 시간을 얻어 낼 수 있었지만, 경영진은 마치 당신에게 엄청난 호의를 베푸는 것처럼 굴었어요. 대체로 커리어에는 독이었죠.
아니면 제 개인 시간에 그런 일을 하는 방법도 있었는데... 그건 커리어 킬러가 아니라 결혼 생활 킬러예요.
수십 년을 시도하다가 결국 번아웃이 왔어요.
맞아요. 엉망으로 망가진 쓰레기를 고치는 데서 즐거움을 느낀다면 그런 기회는 널려 있어요. 다만 돈이 안 돼요. 돈이 되는 건 새 기능뿐이고, 그래서 코드베이스가 이 모양인 거죠. 저도 드물게 다른 팀이 만든 걸 고치거나 출시시키려고 임시로 불려 간 해결사 노릇을 한 적이 있는데, 그건 재미있었어요. 짧게 끝났지만요.
그건 LLM이 못하는 부분이죠. 흥미로운 1%가 기대할 만한 가치가 있었던 건데요.
저는 아키텍처가 그렇게 중요한지 확신이 안 서요. 예전엔 그렇게 생각했는데, 요즘은 이제 우리에게 없는 문제의 산물이라는 쪽으로 기울고 있어요. 예전엔 아키텍처를 다시 하는 게 위험하고 시간이 많이 드는 일이었잖아요. AI가 그걸 토큰 값 100달러나 1000달러(언젠가는)에 안전하게 해 줄 수 있다면, 그 ROI는 어쩌면 마이너스일 수 있어요.
LLM이 속도를 열 배쯤 끌어올려 줘도, 활성 고객과 데이터가 많은 대규모 프로덕션 코드베이스에서는 아키텍처 변경이 여전히 꽤 어렵게 느껴져요. 데이터를 마이그레이션하고 채워 넣고 하는 일 전부요. Claude한테 저장소를 보여 주고 “이거 Rust로 다시 써 줘”라고 하는 것보다 훨씬 복잡하죠.
그래도 말씀이 맞는 것 같긴 해요. 아키텍처를 깔끔하게 유지하는 ROI가 뭘까요? 나중에 시간과 돈을 아끼는 건 분명하지만, 순이익인지는 불분명해요.
(물론 올바른 아키텍처를 찾고 코드를 깔끔하게 유지하는 선행 작업 역시 그만큼 줄었다는 점도 중요해요. 방정식의 양쪽이 다 영향을 받는 거죠…)
업계는 LLM 이전 시절에도 이 질문에 믿을 만한 답을 내놓는 방법을 끝내 찾지 못했으니, 앞으로도 판단하기 어려울 거라고 생각해요.
제 경험으로는 나쁜 아키텍처를 좋은 아키텍처로 제대로 옮기는 데 하루보다 훨씬 오래 걸려요. 처음 구현을 바이브 코딩으로 만드는 데 든 시간보다 며칠은 더 걸리죠. 프로토타입이 있으면 원하는 걸 이해하는 데는 좋지만, 돌아가서 제대로 다시 만드는 건 더 긴 작업이에요. 뭐, 그래도 괜찮지만요.
이건 “평행 우주”가 아니라고 생각해요. 선택 편향이에요. 코딩을 좋아하는 사람들은 사소하지 않은 최전선 작업을 고르는 경우가 많거든요. 그런 사람들이 에이전트 워크플로에 대해 가장 많이 푸념하죠. 저도 포함해서요.
저는 문제를 푸는 게 좋아서 SWE가 됐습니다. 코드로 문제를 푸는 게 좋고, AI로 문제를 푸는 것도 좋습니다.
감정이 아주 복잡합니다.
AI 덕분에 예전 같으면 디버깅, 문제 해결, 구글링, stackoverflow를 거쳐야 했을 문제들을 훌쩍 해치웁니다.
코딩 실력이 퇴화하기 시작했습니다.
저수준 언어의 사소한 특이점을 신경 쓰지 않아도 되는 건 좋습니다(C#과 Java에서 subString의 매개변수가 다른 것 등).
하지만 OP와 같은 걸 저도 봅니다. 팀으로 일할 때 주인 의식과 공동체 의식이 사라졌습니다. 다른 개발자가 AI로 만든 Jira 티켓을 제대로 읽으려면 AI에게 AI식 말투를 풀어 달라고 해야 합니다. 풀 리퀘스트는 그걸 만든 AI, 리뷰 봇, 수동으로 PR 리뷰에 AI를 쓰는 다른 개발자들 사이의 에코 챔버가 됐습니다.
우리 개발자들이 스스로를 대체할 바로 그 기계를 먹여 살리고 있다는 사실은 부인하기 어렵습니다.
전문가가 되고 싶지 않았던 코드가 많습니다. 알고리즘에는 신경 쓸 수도 있고, UX에는 신경 쓸 수도 있습니다. 그 밖에 신경 쓰지 않는 것들은 AI에게 맡길 수도 있고요.
하지만 그게 현재 AI의 문제입니다. 예를 들어 설명 사이트를 만들려고 Claude Code로 글을 쓰게 했더니 심각한 문제가 있었습니다. “평이한” 영어 대신 “화려한” 표현과 “임팩트 있는” 문장을 쓰려 합니다. 그래서 사용자는 그걸 이해하느라 시간을 더 써야 합니다.
코드 주석도 형편없습니다. 한 문장이면 충분한 걸 세 문단이나 씁니다. 그러면 다음 에이전트(또는 사람)가 “수수께끼 같은” 문장이 무슨 뜻인지 알아내느라 컨텍스트 윈도를 낭비해야 합니다.
그리고 정말 중요하게 여기는 부분은, 신경 쓰라고 말해 주지 않는 한 AI는 신경 쓰지 않습니다. 그렇게 말해도 아주 조심해야 합니다. 프로젝트 도중에(토큰 부족으로) 멈춰 버려서 끝날 때까지 아주 엉망인 상태로 방치할 수 있는, 외주 업자처럼 움직이니까요.
더 심하면, 원하는 걸 잊어버리고 제멋대로 한참 하다가 상기시켜 줘야 돌아옵니다.
개발자는 늘 다른 모든 사람을 대체할 기계를 먹여 살려 왔죠.
우리는 늘 스스로를 대체해 왔어요. 여러분이 쓴 “재사용 가능한” 함수, 클래스, 라이브러리 하나하나가 다시는 돈 받고 쓰지 않을 코드 줄을 뜻하니까요. 컴파일러는 어셈블리 코더의 일자리를 빼앗았고요.
지금 다가오는 건 질적으로 달라요. 안정적으로 대량 생산하기 위해 뭔가를 형식화하는 게 아니니까요.
자주 나오지 않는 지적이에요. AI는 대체로 속으로만 하던 말을 입 밖에 내고 있을 뿐이죠.
돈 많은 밸리 형님들은 정치적으로 퇴행적 보수주의를 받아들이기 직전에 그걸 알아챘어요. 마사지와 반려동물 데이케어를 해 주던 시절에서, 지주가 소작농 부리듯 하는 임원식 관리로 넘어온 데는 이유가 있죠.
그리고 그 이유는 “캘리포니아에서는 높은 주거비 때문에 서비스업이 너무 비싸기 때문”이에요.
분명 모든 SWE에게 해당하는 말은 아닙니다. 코드를 직접 쓰는 부담이 AI와 상호작용하며 코드를 빚어 가는 방식으로 대체되면서 해방감을 느끼는 사람이 많습니다. 코드를 쓰는 일에 자신을 많이 동일시했던 사람들은 이제 그걸 기계가 하니 힘들어하는 것 같고, 그게 힘들 거라는 생각은 듭니다.
맞아요. 코딩을 즐기지 않던 사람들이 그렇게 말해요.
AI는 잘하고 싶지 않은 일에는 훌륭한 조력자예요. 제 워크플로에서 잡무성 작업을 상당수 덜어 줬죠. 하지만 더 잘하고 싶고 아끼는 일에서는 즐거움을 죽이는 존재이고, 조심하지 않으면 프롬프트 쓰는 법만 배울 뿐 그게 어떻게 돌아가는지는 배우지 못해요.
저는 코딩을 깊이 즐기는데, 제 감정은 그렇게 단순하지 않습니다.
저는 장인 정신으로서의 코드를 사랑합니다. 완벽한 추상화를 설계하며 시간을 보내는 걸 좋아합니다. 구현 단계에서 그것이 하나로 맞춰지는 걸 지켜보는 것도 좋아합니다. 문제를 해결해 가는 과정, 마침내 문제의 근본 원인과 마주했을 때 찾아오는 이해도 좋아합니다. 이 모든 걸 너무 좋아해서 거의 출시하지 못하고, 시간을 전부 과정에 씁니다.
저는 도구로서의 코드도 사랑합니다. 목표를 묘사하기 위해 쉬지 않고 애쓰다가 그것이 완성되는 걸 지켜보는 게 좋습니다. 제 프로젝트가 테라바이트 단위의 데이터를 소화해 쓸모 있는 결과를 내놓는다는 걸 아는 것도 좋습니다. 결과에 대한 제 가정이 맞았는지 틀렸는지 확인하는 것도 좋습니다.
이제는 앞의 것 없이 뒤의 것을 할 수 있게 됐고, 그래서 깊이 갈등합니다. 제 안의 큰 부분은 그 어느 때보다 신이 납니다. 다른 한 부분은 꽤 슬픈데, 안타깝게도 그곳이 제 자존심이 사는 곳입니다. 지금은 LLM에게 대안 아키텍처들의 장단점을 설명해 달라고 해서 이 마음을 다스리고 있습니다. 그렇게 하면 제가 만드는 제품에 대해 계속 배울 수 있으니까요.
저는 다른 사람들에게 이렇게 말하곤 해요. 예전 제 일은 아키텍처와 패턴이 70%, 코딩과 알고리즘이 30%였어요. 지금은 100% 아키텍처와 패턴이에요. 여전히 시간 대부분을 아키텍처와 패턴에 쓰고, 코딩과 알고리즘보다 이쪽이 더 즐겁기도 하지만, 제 손으로 코드를 온전히 몰던 때와는 “다른 직업”을 갖고 있다는 느낌이에요.
사람들이 이런 말을 항상 하는데, 실제로 무슨 뜻이에요? 코드의 세부 사항도 적어도 어느 수준까지는 “아키텍처”의 일부 아닌가요? 이렇게 말하는 사람들이 도대체 뭘 만들길래, 벽돌은 들여다볼 일도 없이 하루 종일 앉아서 새 레고 구조물만 구상하는지 정말 궁금해요.
벽돌은 꽤 표준화돼 있잖아요? 단일 연결 리스트와 이중 연결 리스트를 맨바닥부터 다시 발명하진 않잖아요, 그렇죠? 저는 프로그래밍할 때 자료구조, 데이터 계층, 알고리즘으로 생각해요. 여기엔 큐, 저기엔 락, 저쪽엔 이중 연결 리스트, 이쪽엔 배열 리스트, 어쩌면 충돌을 연결 리스트 체이닝으로 처리하는 해시 딕셔너리, 이런 식으로요. 제 경력에서 맞춤형 자료구조를 맨바닥부터 만든 건 몇 번 안 되고, 전부 아주 뜨거운 루프(hot loop)를 위한 것이었으며, 한 번은 락프리 알고리즘 작업이 얽혀 있었어요.
저는 과거에 함수형 코딩을 많이 했어요(학계에서, 취미로 Haskell, 그리고 초기 합류자로 있던 유니콘 기업에서 Scala). 아마 그게 제 사고방식에 영향을 줬겠죠. 하지만 저는 코드를 이렇게 조직하는 게 아주 자연스럽다고 느껴요. 결국 프로그램이 CPU, 메모리, IO 중 어디에 묶이는지 같은 핵심 특성을 흔히 결정하는 건 기본 자료구조와 그 사이의 계층이니까요.
저는 꽤 시니어 엔지니어이기도 해서, 에이전트 이전에는 보통 팀을 이끌며 무언가를 구현하는 게 제 일이었어요. 고객 요구 사항을 충족하는지 확인하려고 v0 구현은 제가 직접 하고, 한 걸음 물러나 팀이 서비스를 확장하도록 돕곤 했죠. 요즘은 팀이 훨씬 작아져서 다른 엔지니어 한 명 정도고, 나머지는 에이전트가 채워요.
제가 틀렸을 수도 있지만, ‘아키텍처’에는 비교적 저수준의 세부 사항도 포함될 수 있다고 생각해요. 각 함수가 무엇을 하는지까지 프로그램을 설계하더라도, 코드를 직접 쓰지 않고 그것이 어떻게 동작해야 하는지를 정확히 명시하지 않는 한, 그건 코딩이 아니라 ‘아키텍처’만 하는 것일 수 있어요.
그럼 전부 소원과 기도뿐이라는 거예요? 소프트웨어 품질이 떨어지는 게 놀랍지도 않네요.
소프트웨어는 소원과 기도 위에 지어져요. 프로그래머는 모니터에 설치될 픽셀을 납품하지 않고, (대부분은) 컴파일러 내부를 다루지도 않죠. 우리는 상세한 지시 사항을 적어 놓고, 우리가 꼭 이해하지는 못하는 여러 시스템이 그걸 의도한 결과가 나올 만큼 잘 따라 주기를 바라요. 이게 되는 건, 누군가들이 모여서 자기들의 소원과 기도를 아주 잘 적어 놓은 덕에 나중에 다른 사람들이 그걸 이해하고 따를 수 있었기 때문이에요.
우리는 다른 사람들이 문제에 어떻게 접근하는지 궁금해할 수도 있고, 결함을 찾으려 들 수도 있어요. 이 댓글은 다른 관점을 이해하려 하기보다 부정적인 쪽으로 튀어 버리는 좋은 예 같아요.
저는 다른 사람들이 프로그램을 구조화하는 방식을 배우는 건 풍요로운 일이지, 그 때문에 고집을 부리며 다른 모양의 접근 방식을 깎아내릴 일은 아니라고 생각해요.