"우리는 만드는 소프트웨어에 더 야심을 가져야 한다." 데이터베이스 개발자 마이클 말리스가 Postgres를 Rust로 다시 구현하는 pgrust 프로젝트를 보여주며 댄 루(Dan Luu)에게 반복해서 한 말이다. 댄 루는 이 문장을 "가져야 한다(should)"보다 "가질 수 있다(can)"로 바꾸고 싶다고 말한다. 당위의 문제라기보다, AI 코딩 도구의 역량이 올라가면서 과거라면 엄두도 못 낼 작업이 실제로 가능해졌다는 관찰이기 때문이다.
pgrust가 증명한 것
뉴스 애그리게이터에서 pgrust 같은 재작성 프로젝트가 언급될 때마다 대부분은 'AI가 대충 뽑아낸 쓰레기(vibeslop)'로 치부한다. 실제로 저품질 AI 생성 프로젝트가 넘쳐나기 때문에 그 의심 자체는 합리적이다. 그러나 pgrust는 테스트가 충분히 치밀해서, 검증 과정에서 오히려 Postgres 본체의 실제 버그들을 들춰냈다. 유효한 SP-GiST 연산을 실패하게 만드는 수치 버그, JSONPath가 잘못된 결과를 내게 하는 포맷 캐시 버그, 이후 연산을 깨뜨리는 pgcrypto 버그, 사전 로더의 여러 메모리 안전성 버그, money 타입 오버플로 버그 등이다. pgrust 자체가 버그가 없다는 뜻은 아니지만, 설령 프로젝트가 끝내 성공하지 못해도 그 시도만으로 Postgres는 지속적인 개선을 얻은 셈이다. pgrust의 핵심 내세움은 성능이며, 여기서 입증된 최적화는 실패하더라도 Postgres나 Clickhouse 같은 엔진에 흡수될 여지가 있다.
'1년짜리' 작업이 '몇 시간짜리'가 되다
댄 루는 자신이 정규표현식·문자열 매칭·컴파일러에 대해 아무것도 모르면서도 짧은 시간에 여러 도구를 만들었다고 적는다. 특정 워크로드에서 범용 정규표현식 라이브러리보다 빠르게 조정할 수 있는 정규식 엔진, 그 엔진의 네이티브 코드 컴파일러를 쓰는 ripgrep 포크, 그리고 Rust 빌드를 가속하는 Rust 인터프리터가 그 예다. 특히 이 인터프리터는 콜드 빌드에서 큰 폭, 웜 빌드에서 완만한 개선을 냈다. 개발 환경을 Mac에서 Linux로 옮긴 것만으로 시스템 콜과 파일시스템 오버헤드도 줄었다. 과거라면 '그럭저럭 쓸 만한' 수준까지 1년 넘게 걸렸을 작업들이 단 몇 시간으로 압축됐다는 것이다. 물론 이를 '쓸 만한 오픈소스 제품' 품질로 끌어올리는 일은 여전히 훨씬 큰 노동이 든다는 단서는 분명히 달려 있다.
그가 짚는 진짜 병목은 기술이 아니라 사고방식이다. 많은 개발자가 'Rust 컴파일이 느려 개발 속도가 나지 않는다'고 매일 불평하지만, 느린 컴파일러에 불만이 있으면 Rust 인터프리터를 직접 써버리거나 컴파일 자체를 가속하면 되는 선택지가 이제 현실적이라는 것이다. 사람들이 이런 시도를 떠올리지 못하는 이유는 '에이전트 이전 시대의 비용 모델'을 무의식적으로 끌고 다니기 때문이다. 10년 전이라면 컴파일러가 느리다고 새 컴파일러를 짜는 사람은 인디 게임을 만들겠다며 3D 엔진부터 새로 만드는, 결국 아무것도 출시하지 못하는 부류였다. 생산적인 개발자일수록 이런 시도에 거부감을 갖지만, 지금은 합리적인 선택이 됐다는 지적이다.
모델 세대가 바뀌며 달라진 것
보드게임 아줄(Azul) AI 사례는 세대 차이를 잘 보여준다. 댄 루는 AI 지식이 전혀 없는 상태에서 GPT-5.1/5.2로 약 5시간 만에 초인적 수준에, 약 20시간 만에 당시 최강으로 보이는 AI를 만들었다. 다만 모델의 제안은 대부분 틀렸고, 논문의 기법을 지목해도 겉만 비슷할 뿐 실제 기법이 아니어서 끊임없이 교정해야 했다. 반면 가브리엘 칸구수는 Fable 5.1과 Opus 5.5로 그보다 훨씬 짧은 시간에 댄 루의 AI를 압도하는 AI를 만들었는데, 핵심 차이는 최신 모델이 보드게임 AI를 훨씬 잘 이해해 논문과 코드베이스를 직접 읽고 기법을 구현할 수 있게 된 점이었다. 압축 알고리즘 zstd 구현 실험에서도 GPT-6 Astra는 성능을 떨어뜨리는 TDD 같은 조건에서조차 99% 넘게 테스트를 통과했고 비용도 약 1달러에 그쳤다. 모델이 너무 좋아져서 평가 과제를 IMAP RFC나 Pandoc처럼 더 어려운 것으로 바꿔야 했을 정도다.
흥미로운 역설도 있다. 흔히 '새 모델을 쓰니 다 알아서 되더라, 소프트웨어는 끝났다'고 하지만 댄 루의 경험은 반대였다. 모델이 한 번에 해결하는 일이 늘수록 그는 더 야심 찬 과제로 옮겨가고, 거기선 모델이 여전히 버거워한다. 모델이 핸드홀딩 없이 '검증'할 수 있는 수준과 실제로 '구현'할 수 있는 수준의 격차가 세대마다 벌어지고 있어서, 더 강한 모델을 쓸수록 오히려 '그냥 다 된다'에서 멀어진다는 것이다.
이 낙관에는 분명한 반론이 따라붙는다. 요시 크레이닌은 대부분의 사람에게는 AI로 만드는 소프트웨어에 오히려 '덜' 야심을 가지라고 조언한다. 많은 문제는 명확한 통과/실패 기준이 없어 에이전트 루프에 잘 들어맞지 않고, 기준이 있더라도 사람들은 제약은 걸 수 있지만 내부를 이해할 수 없는 거대한 블랙박스를 다루기 어려워한다는 것이다. 그는 이를 마이크로서비스에 비유한다. 정말 필요하고 능숙하게 쓰는 소수가 있는 반면, 대다수에게는 덜 필요하고 제대로 쓰지도 못한다는 것이다. 결국 역량이 올라간 것은 사실이되, 그 역량을 자기 통제 아래 둘 수 있는지는 개인의 검증 능력과 도메인 이해에 달려 있다. 야심을 키울 기회가 열린 만큼, 그 야심을 어디까지 밀어붙일지 가늠하는 판단력이 함께 요구되는 셈이다.