이제 소프트웨어가 느려야 할 이유는 없다
LLM으로 성능 최적화의 비용과 진입 장벽이 급격히 낮아짐
아직 모든 코드를 어셈블리로 작성할 단계는 아니지만, 테스트에서 원하는 버그 수를 선택할 수 있게 됐다는 관점이 성능에도 점점 적용되고 있음
이 변화는 앞서 짚었던 것처럼, 과거 희소한 전문성을 갖춘 개인이나 팀이 맡던 성능 작업을 몇 문장만 입력할 수 있는 사람도 시도할 수 있게 됐다는 의미
전문 성능 작업의 비용이 여러 자릿수 규모로 감소하면서, 최대 규모이거나 수익성이 매우 높은 프로젝트가 아니면 경제성이 없던 최적화도 실행할 수 있게 됨
특정 작업군을 위한 범용 소프트웨어보다 개별 워크로드에 맞춘 동적 소프트웨어가 유력해졌고, 그만큼 새로운 위험과 기회도 생김
마지막 요점에 전적으로 동의함. 작업군 전체가 아니라 특정 워크로드에 맞춘 동적 커스텀 소프트웨어가 매우 유력한 결과로 보임. 물론 여기에는 여러 흥미로운 위험과 기회가 뒤따름. FFTW와 특정 문제·하드웨어에서 극도로 빠르고 작게 동작하도록 만든 오래된 demoscene 기법들이 떠오름. 코드를 텍스처로 재사용해 뛰어난 캐시 지역성을 확보한 데모도 기억남
코드 작성 자체가 어려웠던 영역에서는 더 야심 찬 소프트웨어를 만들 수 있게 됨
“코드는 원래 어려운 부분이 아니었다”는 말이 일부 영역에는 맞지만, JIT 컴파일러처럼 구현 난도가 도입을 가로막았던 영역도 분명히 존재함
많은 소프트웨어가 JIT으로 빨라질 수 있는데도 드물었던 이유는 역사적으로 구현 비용이 효과보다 컸기 때문이며, LLM이 이 장벽을 크게 낮춤
pgrust도 이 전제에서 출발하며, 가장 만들기 어려운 소프트웨어에 속했던 데이터베이스에서도 구현 범위를 넓힐 수 있음
AI가 도움이 되지 않는 이유로 “코드는 원래 어려운 부분이 아니었다”는 밈이 돌고 있음. 일부 영역에서는 맞지만, 다른 영역에서는 코드 작성이 분명 가장 어려운 부분이었음. JIT 컴파일러가 대표적임. 많은 소프트웨어에서 JIT 컴파일러는 속도를 크게 높일 수 있지만, 역사적으로 구현이 너무 어려워 투자할 가치가 없었기 때문에 드물었음. LLM은 진입 장벽을 낮춰 JIT 컴파일러 작성을 훨씬 쉽게 만들었고, 이것이 pgrust의 전제임. 데이터베이스는 역사적으로 가장 만들기 어려운 소프트웨어였고 그 때문에 제약도 컸지만, 이제 AI와 함께 더 야심 찬 종류의 소프트웨어를 만들 수 있음
작업군 단위 최적화
FRE의 AOT 컴파일을 ripgrep에 결합한 실험에서 대표 쿼리는 약 7% 빨라짐
FRE는 에이전트가 한 달 동안 rebar 정규식 벤치마크 모음을 보며 성능을 개선해 만든 엔진
처음에는 rebar에 심하게 과적합됐지만 holdout 벤치마크가 있다고 알려주자 최적화를 어느 정도 일반화해 holdout에서도 무난한 성능을 냄
검증된 정규식 엔진보다 holdout에서 빠르지 않은 엔진을 쓸 이유는 없지만, native AOT 버전은 긴 검색에서 좋은 결과를 보였음
ripgrep의 일반 matcher를 실행하는 동안 다른 스레드에서 native code를 컴파일하고, 완료되면 native code로 전환하도록 몇 문장으로 에이전트에 지시함
짧은 쿼리는 컴파일에 스레드 하나를 빼앗겨 느려질 수 있지만, 몇 초짜리 작업보다 수십 초에서 수분 걸리는 작업의 단축을 우선하는 선택
실제 Codex 기록에서 가져온 단순한 긴 쿼리는 2~4배 빨라졌고, AOT를 활성화해야 하는 대표 holdout 쿼리는 약 7% 개선됨
native code가 항상 유리한 것은 아님
기존 벤치마크에서는 컴파일 시간을 감수해도 Rust regex crate보다 느린 사례가 많았음
주로 복잡한 쿼리에서 Rust 엔진은 알고리즘 최적화를 쓰지만, 개발 시간이 상대적으로 짧았던 FRE native compiler는 단순한 방식으로 fallback하기 때문
반복적인 텍스트 검색에는 인덱스가 더 직접적인 해법이지만, 고난도 구현도 가볍게 시험할 수 있다는 점이 핵심
빠른 검색만 원한다면 정규식용 native compiler보다 인덱스를 만드는 편이 자연스러움
빠르고 지속적인 텍스트 수집에 특화된 Bing 검색 인덱스 BitFunnel을 만들었던 경험을 활용하면 머신 전체를 위한 로컬 인덱스도 실험할 수 있음
코드 디렉터리만이 아니라 Codex가 거대한 임시·생성 파일 디렉터리와 전체 머신까지 ripgrep으로 훑으면서 생기는 지연을 줄이려면 디스크 전체 인덱스가 필요함
Cerebras 같은 가속기에서 SOTA 모델을 돌려 tok/s와 검색 수요가 크게 늘어나는 AI 연구소라면 기존 indexer가 충분히 빠른지 조사하고 전용 구현을 검토할 만함
오픈소스 BitFunnel에는 bytecode interpreter와 JIT 하나만 있지만 Bing 버전에는 여러 JIT compiler가 포함됨
과거에는 이런 수준의 최적화가 대형 프로젝트였지만, 일부는 이제 실제로 “주말이면 만들 수 있는” 작업이 됨
월 $200 계정 수준에서는 조금 더 빠른 ripgrep과 기성 인덱스면 충분해, 고속 수집형 머신 전체 인덱스는 대규모 AI 연구소에 더 적합함
최적화 비용의 붕괴
2025년 11월 무렵부터 최적화에 필요한 사람 시간은 흔히 1,000배·10,000배·1,000,000배까지 줄어듦
비용 감소 폭은 작업마다 다르지만, metered token 비용과 Bing의 JIT compiler 엔지니어 비용을 비교하면 금액 기준으로는 약 1,000배 수준으로 추정됨
과거에는 성능 2%를 얻기 위해 N person-days의 검증 비용을 감수할지 판단해야 했지만, 이제는 구현과 측정 비용이 낮아져 불확실한 아이디어까지 훨씬 많이 시험할 수 있음
에이전트가 잘하는 반복 작업에는 비결정적 멀티스레드 버그를 재현하기 위한 debug log replay 구현과, 완전한 replay가 안 될 때마다 비결정성 logging을 추가하는 과정도 포함됨
수작업이면 며칠에서 일주일쯤 걸릴 작업을 루프로 처리할 수 있어 까다로운 최적화의 반복 노동이 크게 사라짐
Azul AI에서는 훨씬 적은 시간과 하드웨어로 세계 최고 수준의 결과를 냄
게임 AI 지식 없이 GPT-5.1 또는 GPT-5.2 시기에 만든 Azul AI가 당시 2위 AI보다 큰 폭으로 강해짐
논문에 나온 절차와 비교하면 투입 시간은 약 두 자릿수 배 적었고, cluster 대신 대부분 노트북에서 실험함
핵심 우위는 AI 기법 자체보다 single-threaded인 비교 대상과 달리 multi-threading을 적용한 최적화에서 나옴
native code 버전과 shared wasm memory + JavaScript 버전, 서로 다른 search architecture를 함께 지원함
작은 고속 net에는 minimax, 큰 net에는 MCTS가 필요해 멀티스레딩 알고리즘도 완전히 달랐음
LLM이 잘못된 추론으로 알고리즘을 고르게 뒀다가 직접 30분간 관련 자료를 읽은 뒤 Codex로 여러 번 다시 작성함
이 AI에서는 속도가 2배가 될 때마다 약 100 Elo를 얻었고, 단순히 멀티스레딩만 추가해도 대형 머신에서 비슷한 AI를 압도함
손으로 하기 성가신 최적화 10~20개를 더 쌓으면, 비슷한 전문성과 시간 조건에서 수작업 AI가 따라가기 어려운 수준까지 강해짐
다만 세계 최상위 Go·체스 엔진을 만든 수준의 실제 AI 전문가는 AI 설계 자체의 우위로 이 결과를 이길 수 있음
게임 AI 최적화는 속도와 결과가 동시에 바뀌어 실제 강도가 좋아졌는지 싸게 판정하기 어렵고, 공개 SOTA 모델의 실험 설계 능력도 부족해 사람이 평가 framework를 먼저 마련해야 했음
범위가 명확한 최적화에서는 숙련된 성능 엔지니어도 괜찮은 모델을 따라가기 어려움
Jamie Brandon이 Anthropic의 공개 성능 take-home 과제를 푼 뒤 Claude가 이어받자 훨씬 좋은 결과를 냄
일부 최적화는 본인도 생각했지만 아직 구현하지 못한 것이었고, 나머지는 몇 주간 매달리지 않는 한 시도하지 않을 정도로 과감했음
기존 작업 덕분에 에이전트가 유리했을 가능성을 확인하려고 새 과제를 처음부터 맡겨도 비슷한 점수를 냈고, 다른 에이전트의 빠른 검사에서 부정행위 증거는 발견되지 않음
에이전트는 판단력이 필요한 개방형 문제에는 약하지만, 경계와 평가 기준이 명확한 문제에서는 같은 시간의 인간을 크게 앞설 수 있음
워크로드별 최적화
개별 고객이나 개인의 실제 데이터에 맞춰 소프트웨어를 자동 최적화하는 흐름은 사실상 피하기 어려움
작업군 전체가 아니라 특정 워크로드에 맞춘 동적 커스텀 소프트웨어가 널리 쓰일 가능성이 큼
pgrust에서도 고객 워크로드를 보고 필요한 최적화를 추가할 수 있을 만큼 구현 비용이 낮아짐
[pgrust 최적화 논의]… 이런 최적화는 충분히 쉽게 만들 수 있으므로 고객의 워크로드를 살펴보고 필요할 때 추가할 수 있음
개인 ripgrep 워크로드에 맞춘 첫 최적화는 holdout에서 표준 ripgrep보다 2% 빨랐고 계속 개선 중
별도 framework 없이 에이전트를 실행하는 데 약 2분이 들었으며, 일반 FRE 엔진을 실제 쿼리 benchmark와 후속 holdout 쿼리에 맞춰 개선함
native code compiler 전환은 포함하지 않은 수치이며, 두 방식을 올바르게 결합하면 전체 개선 폭이 더 커질 수 있음
ripgrep fork를 직접 수정했으면 더 빨랐을 가능성이 있지만, FRE의 과적합 문제도 개인 쿼리 데이터로 풀 수 있는지 확인하려고 FRE를 유지함
FRE는 원래 holdout에서 Rust regex engine보다 상당히 느렸고 개선도 정체됐음
정규식 workload 지식이 없었고 SOTA LLM도 유도 없는 개방형 자기개선 실험을 설계하기에는 부족했기 때문
개인 workload에는 충분한 기존 데이터와 계속 생성되는 신규 데이터가 있어 더 나은 조건이지만, 과거 데이터에 없던 regime change가 발생하면 과적합에 주의해야 함
Amazon이나 pgrust처럼 규모가 있는 조직이라면 고객 데이터로 맞춤 최적화하는 pilot을 운영하고 일반 고객까지 확장하는 방식을 검토할 수 있음
개인 프로젝트에서도 실험 실행에 몇 분밖에 들지 않으므로 2% 개선이라도 받아들일 만함
간단하고 ROI가 높은 개선을 먼저 해야 한다는 우선순위는 그대로임
signup flow 페이지를 50 MB에서 5 MB로 줄였을 때 revenue A/B test에서 매출이 약 0.5% 늘었음
custom compiler 같은 고도 전문 작업보다 간단하고 쉬운 개선에 더 높은 ROI가 있을 가능성이 큼
실험 결과의 한계
에이전트로 실험 결과를 얻는 시간은 크게 줄었지만 엄밀하게 검증하고 글로 정리하는 시간은 줄지 않았거나 오히려 늘어남
앞선 두 글에서도 다뤘듯, 호기심을 충족할 결과는 빠르게 얻지만 과거 방식으로 엄밀하게 쓰면 가능한 실험 중 극소수만 공개할 수 있음
이번 글은 빠르고 비엄밀하게 공유하는 실험으로, 작성과 정리를 30분 안에 끝내려 했으나 조금 넘겼음
본문 입력만 20~30분가량 걸리고, 데이터가 이상해 보일 때 추가 확인도 필요했음
실제로 여러 차례 문제를 다시 살폈지만 시간을 더 쓰지 않았으므로 아직 발견하지 못한 데이터 문제가 있을 가능성도 있음
아직 LLM이 글을 대신 쓰게 할 생각은 없고, 글 하나를 30분 미만에 완성하는 것도 현실적으로 어려움
빠른 실험 기록에 대한 의견은 Mastodon에서 받을 수 있음
이제 기대할 수 있는 기본 성능
성능 전문성이 없어도 LLM을 합리적으로 활용하면 무난한 성능의 소프트웨어를 만들 수 있게 됨
과거에는 개발자마다 전문 분야가 다르고 시장·사업 관점에서 성능 전문성을 익힐 이유도 부족해, 대부분의 프로젝트가 전문가가 만들 수 있는 수준보다 느린 것이 자연스러웠음
프로그램이 낼 수 있는 속도와 실제 프로그램의 속도가 크게 벌어진 모습은, 직접 만들 수 있는 UI와 최고 수준 UI의 격차처럼 전문성 차이로 설명할 수 있었음
이제 Jamie Brandon 같은 엔지니어를 고용할 수 없어도 제한된 최적화 문제에서 그보다 좋은 결과를 내는 coding agent는 사용할 수 있음
에이전트에게 단순히 과적합하지 말라고만 했을 때 FRE는 holdout에서 최고 정규식 엔진보다 10배 넘게 느렸지만, holdout 성능이 나쁘다고 구체적으로 알려주자 2군 정규식 엔진과 대체로 비슷한 수준까지 빨라짐
공개 SOTA 모델만으로 일반적인 성능 작업을 수행하려면 여전히 사람이 또는 skill이 benchmark 환경을 구성해야 하며, 이 글의 실험과 이전 논의에서도 사람이 또는 skill이 benchmark 환경을 구성해야 했음
LCP·INP 같은 명확한 지표를 낮추는 프런트엔드 성능에서도 에이전트가 특별히 더 약해 보이지 않음
LLM에 무작정 “최적화하라”고 하면 잘못되고 위험한 변경을 자주 만들므로 검토가 필요하지만, 이는 LLM을 효과적으로 사용할 때 전반적으로 요구되는 능력이지 성능만의 전문 기술은 아님
Codex의 ripgrep 워크로드
한 대의 노트북에서 약 한 달간 관찰한 ripgrep 쿼리는 사람이 직접 쓰는 검색보다 길고 복잡했음
검색 pattern 길이는 p50 55 Unicode code point, p90 119자였음
정규식의 alternation arm도 수작업 검색보다 많았고, 정규식이 길수록 arm 수가 늘어나는 상관관계가 보임
가장 긴 정규식 대부분은 함수명이나 테스트 이름을 길게 alternation한 형태였으며, 다음은 FRE 개발과 관련된 사례
에이전트는 사람이 보기에는 이상한 수치 정규식과 pipeline도 자주 만듦
다음 긴 정규식은
:(?:1[3-9]|[2-9][0-9])[0-9]{2}:와 동등하며, 원본 입력에서 ripgrep으로 실행하면 성능도 거의 같음:(13[0-9]|14[0-9]|15[0-9]|16[0-9]|17[0-9]|18[0-9]|19[0-9]|20[0-9]|21[0-9]|22[0-9]|23[0-9]|24[0-9]|25[0-9]|26[0-9]|27[0-9]|28[0-9]|29[0-9]|30[0-9]|31[0-9]|32[0-9]|33[0-9]|34[0-9]|35[0-9]|36[0-9]|37[0-9]|38[0-9]|39[0-9]|40[0-9]|41[0-9]|42[0-9]|43[0-9]|44[0-9]|45[0-9]|46[0-9]|47[0-9]|48[0-9]|49[0-9]|50[0-9]|51[0-9]|52[0-9]|53[0-9]|54[0-9]|55[0-9]|56[0-9]|57[0-9]|58[0-9]|59[0-9]|60[0-9]|61[0-9]|62[0-9]|63[0-9]|64[0-9]|65[0-9]|66[0-9]|67[0-9]|68[0-9]|69[0-9]|70[0-9]|71[0-9]|72[0-9]|73[0-9]|74[0-9]|75[0-9]|76[0-9]|77[0-9]|78[0-9]|79[0-9]|80[0-9]|81[0-9]|82[0-9]|83[0-9]|84[0-9]|85[0-9]|86[0-9]|87[0-9]|88[0-9]|89[0-9]|90[0-9]|91[0-9]|92[0-9]|93[0-9]|94[0-9]|95[0-9]|96[0-9]|97[0-9]|98[0-9]|99[0-9])[0-9]:
이 정규식이 나온 전체 pipeline은 다음과 같음
cargo clippy … | rg 'crates/fre-aot-regex/src/module.rs:' | rg NUMBER_REGEX | head -250ripgrep 쿼리 지연은 p99가 거의 1분, p999가 거의 10분, 최댓값은 2시간에 가까웠음
이는 한 노트북에서 약 한 달간 모은 결과로, 에이전트를 실행하는 AWS host 등 다른 환경을 대표한다고 주장할 수 없음
Codex는 흔히 line number 옵션을 원했고, 매우 드물게 PCRE2 정규식도 사용함
검색 pattern의 약 94%는 한 번만 등장해 지역성이 낮았지만, 검색 대상 파일은 가까운 시점에 다시 검색될 가능성이 비교적 높아 작은 파일이라면 메모리에서 처리될 여지가 큼
쿼리의 99%는 정규식 검색이고 1%는 비정규식 문자열 검색이었으며, 검색 쿼리의 99.9%는 ASCII only였음
검색된 파일은 약 45%가 ASCII only, 55%가 Unicode 포함 파일로 예상보다 Unicode 비중이 높았음
필요한 기능만 지원하는 정규식 엔진은 더 빨라질 수 있음
back reference 같은 기능을 지원하지 않는 등 기능 수를 줄이면 정규식 구현이 더 빨라질 수도 있음
이번 워크로드별 최적화는 짧은 지시만 준 표면적인 실험이라 추가 개선 여지가 큼
Codex를 가장 효과적으로 쓰는 방식은 아니었으며, 상세한 계획을 세워 실제 쿼리의 흔한 사용 사례에 집중하면 더 큰 향상을 기대할 수 있음
source https://danluu.com/perf-opt/
HN에서는 LLM이 성능 최적화의 비용을 크게 낮춘다는 주장에는 상당한 관심을 보였지만, 그것만으로 느린 소프트웨어가 사라진다는 결론에는 대체로 신중했다. 실제 사용자가 겪는 지연은 개별 함수보다 네트워크 왕복, 웹 기반 실행 환경, 과도한 애니메이션, 동기 호출, 자원 경합 같은 구조적 선택에서 생긴다는 지적이 많았다. 구현 속도가 빨라져도 제품과 아키텍처의 우선순위가 그대로라면 체감 성능은 나아지기 어렵다는 판단이다.
반면 목표를 수치로 검증할 수 있는 작업에서는 에이전트의 효용을 직접 확인한 사례가 나왔다. 정규식 엔진, 검색 자료구조, 프런트엔드 로딩처럼 벤치마크와 테스트를 반복 실행할 수 있는 영역에서는 프로파일러와 디스어셈블러를 활용해 사람이 미뤄 둔 최적화를 수행했다. 낯선 SIMD API를 익히거나 같은 기능을 더 엄격한 자원 조건에서 다시 구현하는 일도 잘 맞았다. 핵심은 명확한 성능 지표와 강한 회귀 테스트, 벤치마크에만 맞춘 개선을 걸러낼 별도 검증 자료였다.
회의적인 반응은 성능 문제의 상당수가 코드를 고치는 단계보다 병목을 찾고 전체 구조를 바꾸는 단계에 있다는 데서 출발했다. 메모리 배치와 캐시 사용, 부하 변화에 따른 버퍼와 연결 풀의 동작, 순차·병렬 처리의 선택은 시스템 전체를 이해해야 다룰 수 있다. 극단적으로 최적화한 코드는 사람이 유지하기 어려울 수 있고, 사용자별 맞춤 소프트웨어는 지원 방식과 공통 사용법을 잃을 위험도 있다. 속도만 높이다 정확성, 보안, 안정성, 확장성을 훼손할 수 있다는 경계도 이어졌다.
결국 판단 기준은 LLM의 코딩 능력보다 조직이 무엇을 측정하고 비용을 어디에 쓰느냐에 가깝다. 성능을 개선하려면 먼저 실제 지연이 네트워크와 아키텍처, 런타임, 개별 구현 중 어디서 발생하는지 확인해야 한다. 이어 동작 명세와 테스트가 충분한지, 개선 폭이 유지보수 부담과 다른 품질 저하를 감수할 만큼 큰지 따져야 한다. 에이전트는 이 조건이 갖춰진 최적화의 단가를 낮출 수 있지만, 성능을 제품의 우선순위로 만드는 결정까지 대신하지는 않는다.
