우리가 만드는 소프트웨어의 목표를 더 높여야 합니다

AI 요약

코딩 에이전트와 모델 성능이 높아지면서 과거에는 시간과 전문성 때문에 엄두 내기 어려웠던 소프트웨어를 개인도 만들 수 있게 됐습니다. Dan Luu는 이 변화에 맞춰 개발자가 기존 프로젝트만 조금 더 빨리 만드는 데 그치지 말고, 이전에는 비용이 너무 커서 시도하지 않았던 문제에 도전해야 한다고 주장합니다. 다만 AI가 만든 결과물이 곧바로 제품 품질을 갖춘다는 뜻은 아닙니다. 저자는 직접 쓸 수 있는 수준과 다른 사람이 지속해서 쓸 제품 수준을 구분합니다.

에이전트가 낮춘 개발 비용

Luu는 Postgres를 Rust로 다시 구현하는 pgrust 사례를 듭니다. 개발자 Michael Malis는 pgrust를 시험하며 Postgres의 수치 처리, JSONPath, pgcrypto, 메모리 안전성 등에서 버그를 발견했습니다. pgrust 자체가 성공하지 못해도 이런 테스트가 Postgres 개선으로 이어질 수 있다는 설명입니다. 다만 저자는 pgrust의 성능 주장이 글의 주된 근거는 아니라고 선을 긋습니다. 빠른 구현에서 나온 최적화가 Postgres나 ClickHouse에 반영될 가능성도 있지만, 실제 버그 보고만큼 직접적인 효과는 아니라고 덧붙입니다.

저자는 고성능 모델이 개발 과정의 병목을 바꾸고 있다고 말합니다. 모델이 코드를 더 빠르게 작성하면 ripgrep 실행, Rust 컴파일, 시스템 호출과 파일시스템 작업이 시간을 잡아먹습니다. 이를 계기로 정규식 엔진과 ripgrep 포크, Rust 인터프리터를 만들었다고 합니다. 저자에게 생소한 분야도 개인 프로젝트로 직접 사용해볼 수준까지 만드는 데 각각 몇 시간 정도 걸렸습니다. 그러나 유용한 제품이나 오픈소스 프로젝트로 다듬으려면 훨씬 많은 작업이 필요하다고 밝힙니다. 글에서 든 Rust 인터프리터의 빌드 시간 개선은 콜드 빌드에서 50배, 캐시를 활용한 웜 빌드에서 2배라고 하지만, 이 수치는 엄밀한 벤치마크로 검증하지 않았다고 명시합니다.

더 큰 문제를 시도하되 검증해야 합니다

저자는 Azul 보드게임 AI, zstd 구현, IMAP RFC 구현과 Pandoc 같은 사례도 듭니다. 모델이 논문이나 코드베이스의 기법을 제대로 적용하지 못하던 시기와 비교하면, 최근 모델은 보드게임 AI 기법을 이해하고 구현하는 능력이 개선됐다고 설명합니다. zstd에서는 최신 모델이 여러 테스트 조건에서 등록된 테스트를 99% 넘게 통과했고, 구현 비용이 약 1달러였다고 합니다. 다만 모델이 더 많은 코드를 한 번에 작성할수록, 사람이 별도로 검증하지 않으면 구현 능력과 신뢰할 수 있는 검증 능력 사이의 격차가 커질 수 있다고 봅니다.

Yossi Kreinin의 반론은 AI를 활용한 야심이 대부분의 개발자에게 실패를 부를 수 있다는 것입니다. 명확한 통과·실패 기준이 없거나 거대한 블랙박스를 이해하지 못하면, AI가 만든 코드는 특정 사례에만 맞고 유지보수하기 어려워질 수 있습니다. Luu도 이 우려를 소개하면서 테스트와 자체 검증 구조를 만들면 복잡한 문제에도 AI를 쓸 여지가 있다고 답합니다. 퍼징, 속성 기반 테스트, 상호 일관성을 확인하는 방식 등이 그 예입니다. 하지만 검증 비용과 유지보수 문제까지 사라진다고 주장하지는 않습니다.

Hacker News 반응

• @mindcandy — 수십 년간 해온 일을 AI에게 시키게 됐다고 말하는 사람은 많이 봤지만, AI를 활용해 몇 달 동안 노력한 끝에 전에는 불가능하다고 여겼던 것을 만들었다는 이야기는 훨씬 적게 봤습니다. 새 도구를 들고도 더 어려운 일을 시도하기보다 지루하다고 불평하는 편이 쉽습니다.
• @wccrawford — 더 야심 차게 만드는 것보다 기존 소프트웨어를 더 잘 쓰는 데 집중해야 한다고 봅니다. AI 슬롭이 쏟아지는 이유도 사람들이 갑자기 더 야심 차게 만들기 시작했기 때문입니다. 저는 수십 년 미뤄둔 프로젝트를 시작했지만, 기존에 만들던 것을 더 빠르고 나은 방식으로 만들고 있습니다.
• @__MatrixMan__ — 기존 소프트웨어가 정말 만족스러운지도 물어야 합니다. 예전에는 맞춤형 소프트웨어를 만들기엔 비용이 너무 비쌌습니다. AI로 비용이 내려가면 수익성이 낮아 투자받지 못했던 문제를 해결할 기회가 생길 수 있습니다.
• @lubujackson — AI는 프롬프트 하나로 MVP까지 빠르게 만들고 지식의 빈틈도 메워줍니다. 하지만 제품 선택, 통합, 보안, 고객 대응, 버그 처리 같은 MVP 이후의 문제까지 해결하지는 않습니다. 이를 이해하고 요청하는 사람의 판단이 필요합니다.
• @Supermancho — 자신이 일하는 곳에서는 LLM이 만든 코드가 여러 애플리케이션을 안정화했다고 말합니다. 기능 테스트와 부하 테스트, 성능 프로파일링을 갖추면 성능 문제와 절충점을 확인할 수 있다고 봅니다.
  • @majormajor — 단순한 요청에 모델이 취약한 우회책을 만들기도 합니다. 한 사례에서는 외부 라이브러리가 오류 원인을 드러내지 않자 특정 경고 로그 문자열을 찾아 다시 던지는 코드를 만들었습니다. 동작은 했지만 버전 의존성과 로그 손실 문제를 일으킬 수 있어 검토 단계에서 고쳤다고 합니다.
• @tlarkworthy — Anthropic 모델로 저자의 zstd 재작성 벤치마크를 다시 해봤고, Haiku 5.5도 성공하는 점이 놀라웠다고 말합니다.
  • @kristianp — 해당 코드가 학습 데이터에 들어갔을 가능성도 있다고 지적합니다.
• @malisper — C와 Rust 코드를 Lean으로 옮기는 컴파일러를 작성하고 LLM으로 동작 동등성을 증명한다고 설명합니다. pgrust에서 약 7만 줄의 C 코드에 대해 동등성을 증명했지만, 증명 맥락이 커지면서 처리 속도가 크게 느려지는 문제가 있다고 합니다.
  • @sealeck — C와 Rust에서 Lean으로 변환하는 컴파일러에 버그가 있으면 증명 결과도 신뢰하기 어렵지 않느냐고 묻습니다.
  • @malisper — 목적은 소프트웨어가 완벽하다는 증명이 아니라 적은 노력으로 최대한 많은 버그를 찾는 것이라고 답합니다. 변환기 버그를 제외하고 pgrust와 Postgres의 동작 차이를 찾더라도 성과라고 덧붙입니다.
• @anonymous908213 — pgrust가 ClickBench에서 세 가지 방식으로 벤치마크를 속였다는 주장을 제기합니다. 특정 쿼리에 맞춘 코드, 캐시, 벤치마크 밖 쿼리 실행 불가를 지적하며, 저자가 개발자와 친하다는 이유로 신뢰하는 설명은 설득력이 약하다고 비판합니다.
  • @malisper — 제출된 바이너리를 직접 실행하고 환경 변수를 설정하면 쿼리별 코드 경로를 확인할 수 있다고 답합니다. 벤치마크 쿼리는 일반 쿼리 경로를 이용했고 결과 캐시도 쓰지 않았다고 설명합니다. 다만 SQL 지원 범위가 좁아 서브쿼리 같은 기능은 지원하지 않는다고 인정합니다.
  • @verdverm — 바이너리의 자체 로그만으로는 검증이 충분하지 않다고 반박하며 전체 커밋 기록 공개를 요구합니다. 공개 저장소의 대규모 변경을 감사하기 어렵고, 투명성이 논란을 끝내는 방법이라고 주장합니다.
• @vishvananda — AI를 활용해 C++ 컴파일러를 만들었고 C++11과 x86에 한정된 조건에서 GCC보다 약 7배 빨리 컴파일한다고 말합니다. 생성된 코드의 성능은 약 5% 느리다고 덧붙입니다.