We should be more ambitious with the software we build

3줄 요약

1. 엔지니어 겸 기술 블로거 댄 루(Dan Luu)는 2026년 10월 24일 발표한 글에서 마이클 말리스(Michael Malis)의 발언을 인용해 코딩 에이전트 시대에는 개발자가 더 야심 찬 소프트웨어를 만들 수 있게 되었다고 설명했다.
2. 검증 없는 저품질 AI 코드는 흔하지만, 많은 프로그래머는 여전히 과거의 비용 기준으로 판단하여 몇 시간 만에 만들 수 있는 도구나 예전에는 큰 비용이 들던 프로젝트도 시도하기를 주저한다.
3. 모델의 구현 능력은 자체 검증 능력보다 빠르게 향상되므로, 개발자는 퍼징이나 일관성 검사처럼 적은 시간으로 관리할 수 있는 검증 체계를 설계해야 한다.

pgrust와 저품질 AI 코드에 대한 의구심

마이클 말리스는 오픈소스 데이터베이스 Postgres를 Rust로 재작성하고 성능을 개선하는 프로젝트 pgrust의 개발자다. 그는 올해 초부터 댄 루에게 자신이 만든 소프트웨어를 보여 주며 이렇게 말했다.

우리는 우리가 만드는 소프트웨어에 더 야심 차야 한다.¹

뉴스 애그리게이터에 pgrust 이야기가 올라올 때마다 대다수 독자는 이를 코딩 에이전트로 대충 만든 저품질 프로젝트, 이른바 바이브슬롭(vibeslop)으로 취급하며 무시한다. 댄 루 역시 시중에 있는 재작성 프로젝트 대부분이 조악한 수준이기 때문에 이러한 회의적인 반응이 자연스럽다고 본다. 일일이 프로젝트를 뜯어볼 시간이 없는 상태에서 말리스를 개인적으로 알지 못했다면 자신도 똑같이 생각했을 것이라는 설명이다.

그러나 pgrust의 테스트 과정을 조금만 살펴보면 일반적인 저품질 프로젝트와 확연히 다르다. 말리스는 pgrust를 검증하는 과정에서 기존 Postgres 본체의 실제 버그들까지 찾아내 보고하고 있다.

• 유효한 SP-GiST 공간 인덱스 연산을 실패하게 만드는 수치 계산 버그
• JSONPath 질의에서 잘못된 결과를 반환하는 포맷 캐시 버그
• 암호화 확장 모듈 pgcrypto에서 후속 연산 실패를 유발하는 버그
• 사전 로더(dictionary loader)의 메모리 안전성 결함 다수²
• 화폐(money) 자료형의 오버플로 버그

말리스는 pgrust를 철저히 테스트하며 Postgres 본체의 버그도 여러 건 찾아냈다.³ 프로젝트가 중단돼도 이 과정에서 고친 버그는 Postgres 생태계에 도움이 된다. pgrust의 핵심 목표인 성능 최적화에서도 마찬가지다. 프로젝트가 도중에 멈추더라도 그 과정에서 입증한 최적화 기법들은 Postgres나 ClickHouse 같은 기존 데이터베이스에 반영될 수 있다.

소프트웨어 소비자의 관점에서 보면 요즘은 어디를 둘러보나 느린 소프트웨어를 빠르다고 포장한 엉터리 벤치마크와 작동 불능 상태인 저품질 프로그램이 그 어느 때보다 흔하다. 반대로 소프트웨어를 직접 만드는 개발자의 관점에서는 다른 사람들이 엉터리 결과물을 얼마나 양산하든 상관이 없다. 과거에는 규모가 너무 커서 엄두를 내기 어려웠던 프로젝트라도 테스트와 벤치마킹을 성실히 수행하면 실제로 사용하기에 충분한 품질로 완성할 수 있다. 댄 루는 자신이라면 말리스의 말을 당위인 “야심 차야 한다”보다 가능성인 “야심 찰 수 있다”로 표현했을 것이라고 했다. 핵심은 개발자가 할 수 있는 일의 범위가 크게 확장되었다는 점이라고 정리했다.

에이전트 이전의 비용 모델과 나만의 개발 도구

댄 루는 OpenAI가 5.3-Codex-Spark처럼 빠르지만 품질이 낮은 모델뿐 아니라 최첨단(SOTA) 모델에도 세레브라스(Cerebras)의 초고속 추론 칩을 도입한다는 소식을 들었다. 그는 만약 최첨단 모델의 실행 속도가 지금보다 10~100배 빨라진다면 자신의 컴퓨터에서 전체 작업 시간의 병목이 어디에 생길지 점검했다. 지금도 종종 병목이 되며 모델이 빨라질수록 더 심각해질 구간은 세 가지였다.

1. 텍스트 검색 도구 ripgrep 실행 시간
2. Rust 컴파일 시간
3. 운영체제 시스템 콜 및 파일시스템 오버헤드

다른 사람에게 배포할 제품이라기보다 ‘내 환경에서 내게만 잘 작동하면 되는(works for me)’ 수준을 목표로 삼으면 이 세 가지는 모두 큰 폭으로 개선할 수 있다. 댄 루는 정규표현식과 문자열 탐색 알고리즘, 컴파일러와 인터프리터에 관한 배경지식이 전혀 없었다. 그런데도 한 자릿수에 해당하는 몇 시간의 여가만 투자해 다음 도구들을 직접 만들었다.

과거였다면 배경지식이 없는 분야에서 이 네 가지 프로젝트를 구현하는 데 1년 이상이 걸렸을 것이다. 물론 상용 제품이나 공개 오픈소스 수준으로 완성하려면 훨씬 많은 노력이 필요하고 과거 대비 단축 비율도 낮아지겠지만, 개인용 도구를 만드는 속도는 극적으로 빨라졌다. 댄 루는 5년 전이었다면 콜드 컴파일을 50배 빠르게 만든 Rust 인터프리터만으로도 별도의 글을 썼을 것이라고 적었다. 이제는 이런 작업이 워낙 쉬워져 별도의 글로 소개할 만큼 특별하게 느끼기도 어렵다는 것이다.

그럼에도 트위터에서는 몇 주 동안 Rust 컴파일 속도가 느려 개발 속도가 제한된다는 불평이 매일같이 올라왔다.⁴ 컴파일이 느리다면 직접 Rust 인터프리터를 작성하거나 컴파일 과정을 가속하면 된다. 유능한 프로그래머들조차 이런 시도를 기피하는 이유는 머릿속에 에이전트 이전 시대의 비용 모델(pre-agentic cost model)을 그대로 유지하고 있기 때문이다.⁵ 10년 전만 해도 컴파일러가 느리다는 이유로 새 컴파일러를 짜는 사람은 소프트웨어를 끝내 출시하지 못하는 사람의 전형이었다. 인디 게임을 만들겠다며 3D 게임 엔진부터 새로 짜는 사람과 같았다. 당시에 형성된 기피 습관이 비용 구조가 바뀐 지금까지도 남아 있는 셈이다.

모델 세대 교체와 구현과 검증 사이의 격차

모델의 능력 향상은 개발 도구 밖의 도메인에서도 빠르게 진행되고 있다. 댄 루는 이전에 보드게임 아줄(Azul)의 AI를 만든 경험을 예로 들었다. 당시 그는 AI에 관한 배경지식이 전혀 없었지만 GPT-5.1과 GPT-5.2를 사용해 약 5시간 만에 아줄 AI를 만들었다. 이 AI는 같은 제한 시간 조건에서 인간 최고수를 이겼다. 약 20시간 만에는 온라인 보드게임 플랫폼 보드게임 아레나(Board Game Arena, BGA)에서 부정행위에 쓰이던 AI를 능가하는 당시 최강 수준의 AI를 완성했다.⁶

그런데 최근 가브리엘 칸구수(Gabriel Cangussu)는 댄 루가 들인 것보다 훨씬 짧은 시간 만에 댄 루의 아줄 AI를 일방적으로 이기는 새 AI를 만들어 냈다. 두 사람이 대화를 해 보니 핵심 차이는 모델 세대에 있었다.

최신 모델이 한 번의 지시(one-shot)만으로 끝낼 수 있는 과제는 분명히 늘어났다. 세간에서는 새 모델을 쓰면 모든 것이 한 번에 작동하고 소프트웨어 개발의 모든 문제가 사라졌다는 주장도 나온다. 그러나 댄 루는 이 주장에 동의하지 못한다. 모델이 쉽게 해내는 일이 늘어날수록 개발자는 모델이 여전히 힘겨워하는 더 어렵고 야심 찬 과제로 목표를 높이기 때문이다.⁸

댄 루는 생산성과 작업 속도는 높아졌지만, 새 모델이 나올 때마다 별도 개입 없이 ‘그냥 알아서 작동하는(it just works)’ 소프트웨어를 만들기는 도리어 더 어려워졌다고 말한다. 모델이 사람의 세심한 개입 없이 스스로 검증할 수 있는 능력보다 모델이 일단 구현해 낼 수 있는 능력이 더 빠르게 향상되면서 두 능력 사이의 차이가 계속 커지고 있기 때문이다.⁹

부록 1: 야심을 줄여야 한다는 반론과 자체 검증 체계

댄 루는 원고 초안을 읽은 요시 크레이닌(Yossi Kreinin)이 보내온 반론을 허락을 얻어 부록에 전문 인용했다. 크레이닌의 요지는 대부분의 개발자가 AI로 소프트웨어를 만들 때 반대로 야심을 줄여야 처참한 실패를 피할 수 있다는 것이다.

많은 문제는 합격과 불합격 기준이 명확하지 않아서 에이전트 루프(agentic loops)에 적합하지 못하다. 설령 기준이 명확하더라도, 내부 구조를 이해하지 못하는 거대한 블랙박스에 제약 조건만 걸어서 추론하는 일은 나 자신을 포함해 대다수 사람에게 매우 어렵다. 이는 마이크로서비스와 비슷하다. 소수의 사람에게는 마이크로서비스가 실제로 필요하고 그들은 이를 아주 잘 다루지만, 대다수 사람은 그만큼 필요하지도 않고 제대로 다루지도 못한다.

“소프트웨어가 느릴 이유가 없다”는 주장에 대해서도 비슷한 생각이다. AI를 시켜 특정 실행 흐름을 빠르게 만들면, 테스트한 사례에만 과적합(overfit)된 지저분한 코드가 잔뜩 추가되기 십상이다. 이런 코드는 다른 사용 사례에서도 같은 성능을 내기 어렵고, 향후 변경할 때 유지보수도 불가능해지기 쉽다. 시스템을 어떻게 분해하고 어느 부분을 집중 최적화하며 어떻게 벤치마킹할지 정확히 아는 사람에게 AI는 훌륭한 도구다. 그러나 관리자가 그저 “소프트웨어가 느릴 이유가 없다”고 믿으며 팀원들에게 AI로 아무 부분이나 빠르게 만들라고 압박한다면 당장 대피해야 한다.

댄 루는 크레이닌의 지적에 공감하면서도 두 가지 근거로 자신의 원래 입장을 유지한다.

첫째는 암달의 법칙(Amdahl’s law)과 과제의 선택이다. AI가 생산성을 100배, 1000배 높여 준다는 통념과 달리, 실제로는 백만 배 이상 빨라지는 작업과 속도가 그대로인 작업이 공존한다. 만약 5년 전에 하던 작업을 정확히 똑같은 방식으로 AI와 함께 수행한다면 속도 향상 폭은 매우 작다. 암달의 법칙에 따라, 속도가 그대로인 작업에 필요한 시간이 전체 소요 시간을 제약하기 때문이다. 생산성을 크게 높이려면 무엇을 가속할지 스스로 선택해야 하며, 그 대상은 대개 과거에는 비용이 너무 많이 들어 시도조차 하지 않았던 일들이다.

둘째는 부분적인 자체 검증(self-checking) 체계의 구축 가능성이다. 언뜻 보기에 명확한 정답 기준이 없어 에이전트에게 맡기기 부적합해 보이는 문제라도, 사람이 적은 시간을 들여 자체 검증 구조를 설계할 수 있는 경우가 많다. 댄 루는 보드게임 《가즈 오브 아틀란티스 2(Guards of Atlantis 2)》의 규칙 구현을 사례로 든다. 이 게임의 공식 규칙서에는 모호하고 서로 모순되는 영어 문장이 많다. 인간 플레이어들이 가장 자주 규칙을 틀리는 게임으로 꼽히며, 게임 디자이너조차 규칙이 완벽히 명확하다고 주장하면서 자신의 해석을 수시로 바꾸곤 했다.

이처럼 혼란스러운 규칙서를 단순한 방식으로 AI에 입력하면 제대로 된 구현을 얻을 수 없다. 대신 댄 루는 서로 상충하는 규칙 설명에 일관성 검사(consistency checks)를 적용하는 자동 검증 환경을 만들었다. 이 환경을 활용해 실제 정답과 상당히 일치하는 규칙 체계를 도출한 뒤, 다른 사람이 수작업으로 만든 구현체와 교차 비교해 정상 작동하는 규칙을 완성했다. 그는 이 작업에 GPT-5.1과 GPT-5.2를 사용해 월 200달러짜리 OpenAI 구독 계정의 한두 달 치 토큰을 소비했다. 이 토큰 비용은 모순 없는 규칙 명세서를 처음부터 직접 작성할 때 드는 인건비보다 훨씬 적었다.

댄 루는 이 상황이 코딩 에이전트 등장 이전의 소프트웨어 테스트 논쟁과 판박이라고 본다. 과거에 그는 퍼징(fuzzing)과 속성 기반 테스트(property-based testing)가 매우 효과적이라고 주장할 때마다 거의 모든 도메인의 개발자들로부터 “우리 분야에는 그 기법이 통하기 어렵다”는 반박을 들었다. 하지만 그가 사람들이 불가능하다고 말했던 모든 도메인에 퍼징과 속성 기반 테스트를 직접 적용하자, 두 기법은 훨씬 효율적이고 효과적으로 작동했다. 전통적인 단위 테스트를 작성할 때보다 초기 설계에 약간의 노력이 더 필요했을 뿐이다. 물론 업계 전반에서는 버그가 급증했다. 댄 루는 최근 대형 AI 연구소의 웹 채팅창을 사용한 지 1분 만에 두 자릿수의 버그를 발견했다. 대다수 사람이 이런 검증 체계를 갖추지 못한다는 크레이닌의 지적도 타당하다. 그렇더라도 남들이 간신히 돌아가는 조악한 코드를 양산한다고 해서 자신까지 그럴 필요는 없다는 것이 댄 루의 결론이다.

부록 2: 일회성 개인 도구, 게임 제작, 정형 검증 사례

두 번째 부록에서 댄 루는 본문에서 다룬 개발 도구 외에도 자신과 주변 엔지니어들이 여가 시간에 만든 다양한 사례와 함께, 도구 제작에 과도하게 몰입할 때의 한계를 정리했다.

먼저 모델과 하네스의 능력이 몇 달 단위로 급변하기 때문에, 3개월 뒤면 쓸모없어질 도구에 지나치게 많은 시간을 쏟는 것은 비합리적이다. 스티브 예기(Steve Yegge)는 자신이 만든 에이전트 프레임워크 Gas Town의 생산성을 여러 차례 글로 소개했다. 그러나 다음 프레임워크를 만들 때는 Gas Town으로 성공적으로 만든 소프트웨어가 Gas Town뿐이었다고 시인했다. 한때 유행했던 Ralph Loops(한 턴이 끝날 때마다 무조건 컨텍스트를 초기화하는 루프 방식) 역시 댄 루가 직접 비교해 본 결과, 문맥을 유지하다가 필요한 시점에 적절히 비우는 단순한 기본 루프보다 성능이 떨어졌다.

나아가 개인이 만든 보조 도구 상당수는 조만간 AI 연구소가 직접 개선해 쓸모없어질 가능성이 높다. 예를 들어 댄 루는 GPT-5.6 Sol 출시 이후 코덱스에서 메모리 누수가 발생할 때마다 프로세스를 재시작해 주는 도구를 만들어 유용하게 썼지만, 이는 OpenAI가 버그를 고치면 사라질 도구다. OpenAI는 자사 코딩 에이전트의 체감 속도를 제약하는 Rust 컴파일 병목도 연구소 차원에서 직접 개선할 공산이 크다. 그러면 앞서 언급한 개인용 Rust 인터프리터 역시 쓸모없어질 가능성이 높다.¹⁰

반면 연구소가 대신 만들어 주지 않을 개인 용도의 소프트웨어는 개발자가 직접 만든다. 예전에는 비용 때문에 포기했던 작업도 이제 시도할 수 있다. Postgres 커미터인 피터 지오건이 들려준 Neovim 포매터 일화는 사람이 직접 유지보수하기에는 타산이 맞지 않던 소프트웨어를 어떻게 만드는지 구체적으로 설명한다. 그는 자신이 수정한 패치 영역만 블록 비주얼 모드로 선택해 포매팅하고 싶었다. 그러나 clang-format만으로는 pgindent 규칙을 완벽히 맞출 수 없었고, pgindent는 파일 전체만 처리했다. 그가 Fable을 시켜 만든 Lua 함수는 세 단계로 작동하는 복잡한 ‘골드버그 장치’다.

1. clang-format/clangd로 1차 포매팅 패스를 돌린 뒤 pgindent로 2차 포매팅 패스를 수행한다.
2. 사용자가 처음 선택한 줄 범위는 C 추상 구문 트리(AST) 요소와 정확히 대응하지 못한다. 따라서 tree-sitter로 덮어쓸 코드의 정확한 범위를 계산해 임시 전체 파일 버퍼에서 추출한 뒤 원래 작업 버퍼에 덮어쓴다.
3. 새 구조체(struct)를 추가할 때마다 전체 Postgres 바이너리에 objdump를 다시 실행하면 지연 시간이 급증한다. 이를 피하려고 clangd에서 해당 파일의 추가 typedef만 동적으로 생성해 pgindent에 전달한다.

지오건은 자신이 Lua를 전혀 모르고 이 함수가 내부적으로 어떻게 돌아가는지 어렴풋이만 이해하고 있지만, 지연 시간도 충분히 짧고 완벽하게 작동한다고 밝혔다. 그는 서비스형 소프트웨어(SaaS)의 종말론에는 회의적이다. 그러나 사람이 직접 유지보수하기에는 효용에 비해 수고가 너무 커 경제성이 없던 특수 소프트웨어도 있다. 그는 이런 소프트웨어를 만드는 데 대규모 언어 모델이 이미 매우 유용한 코드를 작성하고 있다고 평가했다.

가장 흥미로운 지점

나는 이 글에서 댄 루의 관찰과 피터 지오건의 Neovim Lua 포매터 사례를 함께 읽으며 특히 주목했다. 댄 루는 모델이 발전할수록 ‘그냥 알아서 작동하는’ 경우가 도리어 줄어든다고 관찰했다. 언뜻 보면 두 이야기는 서로 다른 말을 하는 것처럼 들린다. 댄 루의 관찰에 따르면 모델의 구현 능력과 자체 검증 능력의 차이가 커져 사람이 더 신경 써야 한다. 한편 지오건은 Lua를 한 줄도 모르고 내부 작동도 잘 모르는 골드버그 장치를 만들어 매일 쾌적하게 사용한다.

이 두 사례를 구분하는 기준은 오류의 파급 범위와 검증 비용이다. 지오건의 포매터는 설령 드문 예외 상황에서 오작동하더라도 눈앞의 에디터 버퍼에서 즉시 티가 나고 최종적으로는 Postgres CI의 pgindent 검사가 걸러 준다. 다시 말해 기존 워크플로 자체가 이미 완벽한 자동 검증기 역할을 하고 있기 때문에 내부가 아무리 복잡한 블랙박스여도 사용자가 부담할 위험이 없다. 반대로 pgrust나 《가즈 오브 아틀란티스 2》 같은 대규모 시스템은 정답 기준이 자명하지 않다. 이런 시스템에서 개발자의 핵심 역량은 코드 한 줄을 직접 짜는 대신, 그럴듯하지만 잘못된 모델의 구현을 검출할 체계를 얼마나 영리하게 설계하느냐에 있다. 기존 Postgres 테스트 스위트와 Lean 4 증명기, 모순된 규칙서들 사이의 일관성 검사가 그 예다.

출처

Dan Luu, “We should be more ambitious with the software we build”, 2026-10-24 원문: https://danluu.com/ambitious/

치비 서소영 삽화 다섯 장은 「느낌적인 느낌을 숫자로 옮기는 일」의 치비 서소영 라인아트를 참조해 gpt-image-2.5-flare로 따로 생성했다.