요약
AI 에이전트 덕에 만드는 비용이 크게 줄었으니, 예전엔 엄두 못 낸 소프트웨어에 도전해야 합니다.
개발자 블로거 댄 루의 글입니다. Postgres를 Rust로 다시 구현하는 pgrust의 개발자 마이클 말리스가 평소 하던 말을 제목으로 삼고, 자신이 에이전트로 만든 도구와 실험을 근거로 들었습니다.
왜 중요한가
- 에이전트 이전의 비용 감각으로 할 일을 고르는 습관이 이제는 걸림돌이 된다는 주장입니다.
- 느린 컴파일러를 새로 짜는 일은 10년 전엔 아무것도 출시하지 못하는 사람의 몫으로 여겨졌지만, 이제는 해볼 만한 일이 됐습니다.
핵심 내용
- 정규식 엔진, 그 엔진의 컴파일러를 쓰는 ripgrep 포크, Rust 빌드 가속 도구를 모두 합쳐 몇 시간 만에 만들었습니다.
- 보드게임 Azul의 AI는 약 5시간 만에 사람을 넘어섰고, 20시간쯤 들이자 당시 가장 강해 보이는 AI가 됐습니다.
- pgrust는 AI로 대충 만든 코드라는 의심을 받지만, 실제 Postgres 버그를 여럿 찾아냈다며 옹호했습니다.
- 퍼징(무작위 입력으로 오류를 찾는 시험)처럼 결과를 스스로 점검하는 장치를 갖추면 큰 작업도 맡길 수 있다고 봤습니다.
- 부록에는 대부분의 사람은 오히려 덜 야심 차야 한다는 요시 크레이닌의 반론을 함께 실었습니다.
HN 반응
- 코드 작성이 빨라져도 코드 리뷰와 사업 결정 같은 조직 절차가 병목으로 남는다는 지적이 가장 큰 흐름이었습니다.
- 속도만큼 기술 부채도 빨리 쌓인다는 반론과, 더 빠른 ripgrep 같은 목표는 누구나 세울 수 있다는 비판도 나왔습니다.
소프트웨어를 둘러싼 우리의 프로세스가 먼저입니다.
AI 논의는 대부분 이 도구가 개별 개발자에게 어떤 의미인지에 초점이 맞춰져 있는데, 팀 단위로 보면 어떤 이득이든 조율 비용과 이념적 마찰 때문에 날아가 버릴 위험이 있습니다. 제 경험으로는 지금 시점에서는 이념적 마찰이 그 대부분을 차지합니다.
코드 작성이라는 병목이 사라진 만큼 프로세스도 가속할 방법을 찾는 것이 필수입니다. 저는 한 개발팀이 매일 하는 PR/코드 리뷰 과정이 너무 느리다는 이유로 완전 수작업 개발로 되돌아가는 것을 봤습니다. 코드를 아무리 빨리 써도 그만큼 빨리 머지해서 고객에게 내보내지 못하면 소용없습니다. PR 스택으로 버틸 수 있는 것도 한계가 있습니다. 충돌이라는 괴물이 너무 커지면 감당이 안 되니까요.
AI가 프로세스, 이념, 사람 문제를 고쳐 줄 수 있다고는 생각하지 않습니다. 평균적인 PR 리뷰가 실제로 얼마나 걸리는지 저는 봤습니다. 이 직원들이 그냥 자기 일만이라도 제대로 했다면 AI와 상관없이 10배는 나아졌을 겁니다. 제대로 실력 있는 개발자가 진지하게 시도한다면, 2026년 10월 현재 맡은 작업의 99%는 같은 근무일 안에 해결할 수 있어야 합니다.
백로그를 0으로 줄인다고 해서 그 개발팀이 곧바로 해고되는 것은 아닙니다. 오히려 반대입니다. 그렇게 생긴 공백은 회사가 새로운 일로 채우게 되고, 그 덕에 개발자들의 보상 패키지가 덩달아 올라갈 수도 있습니다. 3주 내내 하루 50건씩 처리해 낸 개발팀을 자르는 곳은 없습니다. 그 팀이 만들어 놓았을지 모를 버그는 누가 맡겠습니까? 그렇습니다. 오히려 개발자를 더 뽑을 수도 있습니다. 이를 "윈윈" 시나리오라고 부릅니다. 모든 게임이 제로섬일 필요는 없습니다. 다만 이 가능성을 거부하는 태도도 앞서 말한 이념 문제의 일부라고 이해합니다.
전반적으로 동의하지만, 저한테 AI의 진짜 가치는(다른 사람의 생각을 바꾸려는 건 아닙니다) 세 가지 영역에 있다고 봅니다. 1. Haskell, Java 등의 에러 스택을 분석하는 것처럼 사소한 작업에서 시간을 아끼는 작은 이득들입니다. 온갖 사소하게 시간을 잡아먹는 문제들에서 아낀 몇 분이 쌓입니다. 2. 코딩 전, 심지어 설계 전의 브레인스토밍입니다. 아이디어를 마크다운 파일에 적은 다음 성능 좋은 AI 한두 개에게 반박해 보라고 하고, 제가 놓쳤을 만한 부분을 채워 달라고 합니다. 3. 기술과 무관한 사고입니다. 저는 정식 교육을 받은 적 없이 철학책 읽는 것을 즐기는데, 읽고 있는 내용에 대해 Gemini에게 다른 관점을 자주 물어봅니다. 이것도 역시 제 이해를 높이려는 목적일 뿐입니다.
AI는 우리를 더 나은 사람으로 만들어야지, 수조 줄의 코드를 찍어내기만 해서는 안 됩니다.
개발자들이 에이전트 떼를 돌려 놓고 잠자리에 드는 대규모 바이브 코딩이라는 발상 자체가 저는 불편합니다.
다만 제약 이론 때문에라도 힘든 시기가 될 겁니다.
이전에는 소프트웨어를 만드는 일이 대체로 주된 제약 중 하나였습니다. 회사가 X를 하고 싶다고 하면 만드는 데 3개월이 걸렸죠.
그러면 사업 구상과 거버넌스 사이클(무엇을 할지, 고객이 있는지, 얼마를 받을지)도 3개월쯤 걸려도 괜찮았다는 뜻입니다.
개발 프로세스를 10배로 빠르게 만든다면 비즈니스 프로세스도 똑같이 해야 합니다.
엔지니어링 팀이 백로그를 비우고 수십 년 쌓인 기술 부채까지 털어 내고 나면 제약은 다른 곳으로 옮겨 갈 겁니다. 그때 기업들이 어떻게 반응할지가 흥미롭겠습니다.
비즈니스 쪽에는 어떤 팀도 다 소화하지 못할 만큼 아이디어가 많은 사람이 반드시 있을 겁니다.
제품 제안용 PPT를 떠올려 보세요. 그 대신 프로토타입을 보여 줄 수 있다면 어떨까요? 순식간에 수요가 100배로 늘어납니다.
그게 바로 제본스의 역설입니다. https://en.wikipedia.org/wiki/Jevons_paradox
네, 그러시겠죠. 그런데 실제로 10배가 된 건 기술 부채뿐이에요. 사람들이 지금 수십 년어치 기술 부채를 1년도 안 되는 사이에 만들어 내고 있다고요.
맞습니다. 예전에는 무엇이 기술 부채를 억제했을까요? 아마 두 가지일 겁니다. 개발 속도와 좋은 관행(Good Practice)이요. 그리고 개발 속도가 적어도 관행만큼은 큰 역할을 했다고 생각합니다. 그러니 속도의 제약을 풀어 버렸다면 기술 부채의 제약도 상당히 풀어 버렸을 가능성이 큽니다.
정말 그럴까요? 직접 시험해 볼 의향이 있으십니까?
남은 항목이 없거나, 하루에 처리하는 항목 수가 매일 처리해야 하는 항목 수를 한참 넘어섰다면 누군가는 분명 해고됩니다.
우리는 오랫동안 경영진이 이런 문제에 신경 쓰지 않는다고 비판해 왔습니다. 그런데 이제 와서 그들의 좋은 판단력을 믿으라는 겁니까?
백로그 깔때기를 계속 채워 두는 일은 AI 전후를 가리지 않고 5년 가까이 저한테 거의 전업이었습니다. 실행할 줄 아는 팀이 갖춰지고 나면, 잘 정의되고 정리된 작업으로 백로그를 계속 채워 두는 것이 문제가 되는데, 경영진은 이걸 좀처럼 보지 못하고 따라서 어떻게 풀어야 할지도 모릅니다.
맞습니다.
저는 최근에 이직했는데, 전 직장에서는 이 일을 주로 하던 PM들이 AI가 자리 잡은 뒤로 너무 과로해서 (생산적인) 모든 팀의 PM 대 개발자 비율을 두 배로 늘렸습니다.
다른 회사에서도 비슷한 얘기를 읽었습니다. 구글에는 개발자 한 명에 PM 한 명인 팀도 있다고 들었어요.
지금 다니는 곳에서는 AI 덕분에 일이 훨씬 빨리 처리되고 품질도 더 좋습니다.
제 생각에 소프트웨어를 다루면서 AI로 의미 있는 효과를 못 본다면 뭔가 잘못하고 있는 겁니다.
그래서 기술 스택을 갈아엎는다는 얘기가 계속 들리는 것 같아요.
이런 회사 중 상당수는 애초에 뭘 해야 할지 모르기 때문에, 개발 처리량을 높이는 건 애초에 비즈니스 문제가 아니에요(자주 그렇게 탓하긴 하지만요).
제가 거친 모든 소프트웨어 직장에서, 새 기능을 내놓을 때마다 그 기능을 수정해 달라는 요청이 대략 세 건, 의도치 않은 버그 티켓이 두 건, 거기에 기술 부채까지 따라왔습니다. 일은 더 적은 일이 아니라 더 많은 일을 낳습니다. 일의 속도가 빨라졌다고 이게 달라질 이유를 모르겠습니다.
네, 지금도 말 그대로 항상 일어나는 일입니다. 근거를 대자면, 소프트웨어 개발 조직은 해야 할 일이 무엇이냐가 아니라 운영 예산의 빈자리를 채우기 위해 사람을 뽑습니다.*
*출처: 저는 소프트웨어 팀 900여 곳의 손익계산서를 보고 그 CTO들을 인터뷰했습니다.
조너선 블로우는 이 통념의 확실한 예외입니다. 그는 최신작을 만들려고 자체 엔진은 물론 자체 프로그래밍 언어와 컴파일러까지 직접 만들었고, 그 게임은 출시됐고 훌륭합니다. AI는 전혀 쓰지 않았습니다.
그의 작업물은 멋지다고 생각하고 새 게임도 재미있게 했지만, 자체 엔진과 언어를 만든 대가로 그 게임을 내놓기까지 10년과 수백만 달러가 들었다는 점은 꽤 인상적입니다. 본전을 뽑으면 좋겠지만, 10년을 들여 게임을 내놓았는데 상업적으로 그만큼 성공하지 못하는, 덜 유명한 개발자들은 어떻게 될까요?
그가 할 수 있었던 건 자신의 게임 엔진으로 만든 이전 게임들(그중 하나는 3D)을 팔아 수백만 달러를 벌어 둔 덕분입니다. 다른 개발자들이 이 방식을 시도했다가 성공하지 못한다 해도 어쩔 수 없는 일이고, 어떤 방식을 쓰든 그건 각자의 자유입니다. 저는 그저 글에 나온 고정관념에도 예외가 있다는 점을 짚었을 뿐입니다.
저는 GPGPU 언어를 만들어 볼까 생각 중인데, AI를 써도 시간이 꽤 걸릴 겁니다. 안타깝게도(??) AI는 지금으로서는 안목을 대체할 수 없고, 훨씬 더 반골 기질이 강해지지 않는 한 앞으로도 어려울 겁니다.
안목이란 원래 반골 기질입니다.
Claude가 제가 2단계 타입 이론(two-level type theory)을 만들겠다는데 "맞습니다!" 한마디로 넘어가서는 안 될지도 모르겠어요. 실제로 요즘은 "맞습니다, 그리고 어쩌고저쩌고 큐비컬 타입을 쓰면 정말 멋질 거예요"라고 하면서 몇 문단씩 토해 내며 끝까지 옹호하더라고요.
혼자서 개발한 게임을 생각하면 저는 늘 크리스 소여가 떠올라요. 제가 제일 좋아하는 게임인 롤러코스터 타이쿤과 트랜스포트 타이쿤 디럭스를 처음 만든 사람인데, 둘 다 거의 전부 어셈블리로 짰잖아요.
우리 업계라는 거품 밖에서는 소프트웨어 품질이 꽤 형편없다는 점을 기억할 필요가 있다고 생각합니다. 저는 올해 초 히타치 히트펌프를 설치했는데(추천하지 않습니다), 소프트웨어가 꽤 실망스럽습니다. 대체로 작동은 하지만 문서화되지 않은 기능도 많고, 설정 옵션이어야 할 값이 하드코딩된 곳도 많습니다.
예를 들어 히트펌프가 목표 온도에 도달하면 꺼졌다가 3분 뒤에 다시 켜집니다. 짧은 주기로 반복 가동되는 것(short cycling)을 막으려고 재가동 간격을 늘리고(3분보다 길게) 싶은데 바꿀 수가 없습니다. 누군가 3분이 모두에게 맞는 값이라고 정해 버렸고, 그걸로 끝입니다.
이걸 개선해 보려고 400유로짜리 인터페이스 박스(사실상 시리얼-IP 변환기일 뿐이고 하드웨어 원가는 많아야 20달러쯤일 것 같습니다)를 샀습니다. 8000유로짜리 히트펌프에는 와이파이도 이더넷도 기본으로 달려 있지 않아서 액세서리를 따로 사야 합니다. 히타치 제품은 아니지만 공식 추천 액세서리입니다. 제가 이걸 사려던 이유 중 하나인 기능은 마케팅 자료에도 광고되어 있는데 작동하지 않습니다.
업체에 이메일을 보냈더니, 제가 가진 디스플레이가 신형 리비전이라 필요한 설정에 접근할 수 없는 것 같다고 하더군요. 그 설정을 켜지 못하면 광고된 대로 그 기능을 쓸 수 없습니다. 자기네 부품이 문제가 아니니 히타치에 직접 이메일을 보내 이야기해 보라고 했습니다.
모든 소프트웨어가 오픈소스이거나, 하다못해 리버스 엔지니어링이 가능해서 이런 말도 안 되는 일이 사라지는 세상을 기대합니다.
거품 안에서도 꽤 형편없어요.
하하, 감사합니다. 덕분에 웃었어요. 물론 전적으로 동의합니다.
오픈소스일 필요까지는 없고, 널리 쓰이고 공유되는 표준이 필요합니다.
그쪽 내부는 비공개여도 표준이 있다는 게 핵심입니다.
좋은 표준은 못난 개발자들이 무시하는 경우가 많죠(항상 그런가요?).
저는 오히려 상업적인 문제라고 봅니다. 자기만의 폐쇄적인 생태계를 만드는 게 돈이 되니까요.
엄밀히 말하면 AI 덕분에 소프트웨어를 리버스 엔지니어링하는 게 훨씬 쉬워지긴 했어요. 가드레일이 불쑥 끼어들지만 않는다면요.
내장된 펌웨어를 리버스하는 건 좀 더 어렵습니다. 평범한 해커 수준을 넘어서는 일이 분명합니다.
야심이 커졌다기보다는, 아이디어와 설계는 오래전부터 있었지만 시간이 없어서 못 했던 것들을 이제 만들 수 있게 됐습니다. 최근 재미있는 사이드 프로젝트로, Kobo 리더에서 책뿐 아니라 다른 것도 읽을 수 있게 하는 작업을 했습니다. 샌드박싱과 권한 모델, 자동 업데이트, 공유 기능 등을 갖춘 e-ink 앱을 Kobo용으로 만들 수 있는 SDK와 앱을 만들었습니다. https://github.com/BandarLabs/Cobalt
AI를 아주 멋지고 창의적으로 활용한 예네요. 저는 Kobo 앱을 만들 생각은 전혀 못 했을 거예요 :D
그런가요? 원글 작성자의 프로젝트를 깎아내리려는 건 아니에요. 정말 멋져 보이거든요.
그런데 솔직히, 소프트웨어에 조금이라도 관심 있는 사람이 AI를 엄청난 역량 증폭기로 보지 않는다는 게 저는 이해가 안 돼요. 어떻게 자기가 원하던 걸 전부 하지 않고 있죠?
그냥 앉아서 불평만 하는 사람이 너무 많아요. 저로서는 도무지 이해가 안 됩니다.
더 빠른 postgres나 정규식은 말 그대로 더 빠른 말 비유 그대로예요.
소프트웨어가 목적을 위한 수단이라는 말은 HN에서 인기가 없는 편이지만, 우리에게 필요한 건 더 야심 찬 생각이고, 어쩌면 그 답이 소프트웨어일 수도 있어요.
(그리고 아니요, 십대 소년이 품은 행성 간 정복이라는 집착 어린 몽상은 수백 년 묵은 재탕일 뿐 독창적인 생각이 아닙니다)
우리는 더 다양한 소프트웨어를 만들어야 합니다.
프롬프트 기수라면 누구든 더 빠른 ripgrep을 만들 수 있어요. 사양이 "더 빠른 ripgrep"이니까요.
당신만이 명세할 수 있고, 당신의 경쟁 우위가 극대화되는 단 하나는 무엇입니까? 그걸 찾아서 온 힘을 다해 추구하세요!