우리가 만드는 소프트웨어에 더 큰 야심을 가져야 한다

Dan Luu의 글을 앞부분부터 '사람들은 이제 쉬운 일을 떠올리지도 않는다'는 대목까지 읽고 옮겼어요. 그 뒤 내용과 각주는 읽지 못했어요.

출발점: "더 야심 차야 한다"

올해 초부터 pgrust를 만드는 Michael Malis가 저자에게 흥미로운 작업을 보여 주며 이렇게 말해 왔대요.

우리가 만드는 소프트웨어에 더 야심을 가져야 해요.

pgrust는 '바이브 슬롭'일까

저품질 AI 생성 프로젝트가 워낙 많아서, pgrust 같은 재작성 프로젝트를 보면 대부분 "또 하나의 vibeslop"이라고 넘겨 버린대요. 저자도 Malis를 몰랐다면 그랬을 거래요. 하지만 들여다보면 pgrust는 실제 Postgres 버그를 찾아낼 만큼 철저히 테스트하고 있어요.

• 정상적인 SP-GiST 연산을 실패하게 만드는 수치 버그
• JSONPath 결과를 틀리게 만드는 포맷 캐시 버그
• 이후 연산을 실패하게 하는 pgcrypto 버그
• 사전 로더의 여러 메모리 안전성 버그
• money 타입 오버플로 버그

pgrust에 버그가 없다는 뜻은 아니지만, pgrust가 실패하더라도 이 시도로 Postgres는 이미 오래 남을 개선을 얻었대요. pgrust의 핵심 목표는 사실 성능이고, 실패해도 일부 최적화가 Postgres나 ClickHouse에 들어갈 수 있대요.

만드는 사람의 관점

소비자로서 보면 제작자가 엉터리 벤치마크로 빠르다고 주장하는 느린 소프트웨어, 작동하지 않는 저품질 소프트웨어가 어느 때보다 흔해요. 하지만 만드는 사람에겐 남들이 쓰레기를 금이라 부르며 쏟아내는 건 상관없대요. 테스트와 벤치마크를 제대로 하면, 예전엔 너무 커서 엄두도 못 낼 프로젝트를 실제로 쓸 만한 품질로 만들 수 있어요. 저자라면 "해야 한다(should)"보다 "할 수 있다(can)"라고 쓰겠다고 덧붙여요.

저자의 실험

OpenAI가 최상위 모델에 Cerebras를 쓴다는 소식을 듣고, 최상위 모델이 10–100배 빨라지면 자기 컴퓨터의 시간이 어디로 갈지 봤대요. 시스템 콜·파일시스템 오버헤드 같은 병목이 더 심해질 거라고 봤어요. 그래서 바쁜 와중에도 이런 걸 만들었대요.

• 원하는 작업에 맞춰 다른 범용 regex 라이브러리보다 빠르게 조정할 수 있는 정규식 엔진
• 그 엔진의 네이티브 코드 컴파일러를 쓰는 ripgrep 포크(Codex의 ripgrep 작업에서 더 빠름)
• 자기 프로젝트 빌드를 빠르게 한 Rust 관련 도구(콜드 빌드는 크게, 웜 빌드는 중간 정도 개선)

정규식, 문자열 매칭, 컴파일러를 잘 모르는 자신이 하면 '나한테는 돌아가는' 수준까지 1년 이상 걸렸을 일을 한 자릿수 시간에 했대요. 제품이나 오픈소스 수준으로 올리려면 훨씬 많은 일이 필요하지만요. 개발 환경을 Mac에서 Linux로 바꾼 것만으로도 파일시스템 오버헤드가 크게 줄었고, 직접 I/O 툴체인이나 시스템 콜을 흉내 내는 계층처럼 예전엔 터무니없던 일도 이제는 할 만하대요.

Malis의 말을 다시 읽으면

저자는 그 말을 "이제 쉬워진 일을 사람들이 떠올리지도 않는다"는 뜻으로 읽어요. 예를 들어 Rust 컴파일이 느리다는 불평을 매일 보는데, Rust 인터프리터를 쓰거나 컴파일 자체를 빠르게 만드는 것도 이제는 큰 노력 없이 할 수 있는 일이래요.