"LLM이 짜는 코드는 느리고 비대하다"는 비판은 개발자 커뮤니티에서 흔히 반복된다. 그러나 댄 루(Dan Luu)는 정반대의 관점을 제시한다. 과거에 희소한 전문성을 요구하던 성능 최적화 작업의 비용이 몇 자릿수 단위로 떨어지면서, 예전에는 대규모 프로젝트나 수익성 높은 서비스에만 정당화되던 최적화를 이제는 누구나 시도할 수 있게 됐다는 것이다. 그는 놀런 로슨이 테스트에 대해 했던 말, 즉 "이제는 버그를 몇 개나 남길지 스스로 고를 수 있다"는 표현을 성능 영역에 빌려온다. 최적화를 얼마나 할지가 기술적 한계가 아니라 선택의 문제가 되어가고 있다는 뜻이다.
어려웠던 것은 코드였다
"AI는 도움이 안 된다, 코드 작성이 어려운 부분이었던 적은 없으니까"라는 반론이 있다. 루는 이것이 일부 분야에서는 맞지만, JIT 컴파일러 같은 영역에서는 명백히 틀렸다고 본다. 많은 소프트웨어가 JIT 컴파일러로 큰 성능 이득을 볼 수 있음에도 JIT이 드문 이유는, 구현이 너무 어려워 대부분의 경우 투자 가치가 없었기 때문이라는 것이다. LLM은 이 진입 장벽을 낮췄다. 데이터베이스처럼 구축 난이도 자체가 야심을 제약하던 소프트웨어에서도 이제 더 대담한 시도가 가능해진다. PostgreSQL을 러스트로 재구현하려는 pgrust 프로젝트가 그런 사례로 언급된다.
몇 분의 타이핑으로 만드는 최적화
루는 앞선 글에서 에이전트를 한 달간 반복 실행시켜 만든 정규표현식 엔진 FRE를 예로 든다. 이 엔진은 rebar 벤치마크에 과적합되는 문제가 있었는데, 홀드아웃 벤치마크의 존재를 알리자 에이전트가 최적화를 일반화했다. 흥미로운 지점은 네이티브 AOT 컴파일 버전이 긴 검색에서 좋은 성능을 냈다는 점이다. 그는 여기서 착안해, ripgrep이 일반 매처로 검색하는 동안 별도 스레드에서 네이티브 코드를 컴파일하고 완성되면 그쪽으로 전환하는 구조를 몇 문장의 지시만으로 에이전트에게 구현시켰다. 사람이 직접 하면 상당한 코드 수술이 필요한 작업이다. 결과는 단순한 긴 쿼리에서 2~4배, 대표성 있는 홀드아웃 쿼리에서는 약 7% 향상이었다. 극적이진 않지만 몇 분의 노동 대비 나쁘지 않은 성과다.
다만 그는 이것이 다소 우스운 접근임을 인정한다. 텍스트를 반복 검색하는 상황이라면 정규식용 네이티브 컴파일러가 아니라 인덱스를 만드는 편이 정석이기 때문이다. 요점은 결과의 크기가 아니라, 예전에는 시간과 전문성을 요구하던 이런 작업을 이제 손쉽게 시도해볼 수 있다는 사실 자체다.
판단의 기준선이 바뀐다
CPU 마이크로코드와 검증, 검색 엔진 인덱스 최적화 경험을 가진 루는 늘 "이 최적화는 2% 개선을 주지만 검증에 며칠이 든다"는 식의 손익 계산을 해왔다. 그 며칠(N)이 인간 시간 기준으로 1000배에서 100만 배까지 줄어들면, 시도할 만한 최적화의 개수 자체가 폭증한다. 성공 여부가 불확실해 예전엔 착수를 망설였던 실험적 최적화도 이제 부담 없이 던져볼 수 있다. 게임 AI 사례에서 그는 세계 최강 수준의 아줄(Azul) AI를 만들었는데, 승부의 대부분은 멀티스레딩 등 최적화에서 갈렸다. 속도가 두 배가 될 때마다 약 100 Elo가 올라, 손으로 짠 AI로는 따라잡기 어려운 격차가 벌어졌다. 비결정적 멀티스레딩을 디버깅하기 위해 로그 재생 기능을 붙이는 일처럼, 손으로 하면 며칠 걸릴 지루한 작업도 에이전트가 반복 루프로 처리했다.
한계와 실무적 함의
장밋빛 전망만 있는 것은 아니다. 현재 공개된 최고 수준 모델도 실험 설계에는 약해서, 최적화의 좋고 나쁨을 판별하는 평가 프레임워크는 사람이 직접 세워야 했다. 게임 AI처럼 최적화가 결과 자체를 바꾸는 경우엔 속도 이득과 결과 변화를 함께 저울질할 방법이 필요하다. 루 역시 모델이 잘못된 논리로 멀티스레딩 알고리즘을 고르게 두었다가, 결국 스스로 30분간 관련 자료를 읽고 여러 번 재작성하게 했다고 털어놓는다. FRE의 과적합 문제가 보여주듯, 벤치마크를 잘 짜지 못하면 검증 세트에서 무너지는 최적화를 양산하기 쉽다.
그럼에도 방향성은 분명하다. 마크 브루커의 표현처럼, 특정 워크로드에 맞춰 재단된 동적 맞춤형 소프트웨어가 현실적인 귀결로 다가온다. 실제로 루는 이 글을 쓰기 직전 몇 분 만에 자신의 ripgrep 쿼리에 특화된 최적화를 에이전트에 맡겼고, 첫 패스만으로 홀드아웃에서 표준 ripgrep보다 2% 빠른 결과를 얻었다. 한국의 실무자에게 이 논의가 던지는 메시지는 성능 개선을 특권적 전문 작업으로 미뤄두던 관성을 재검토하라는 것이다. "할 가치가 있는가"의 계산식에서 인건비 항이 크게 줄어든 만큼, 워크로드별 맞춤 최적화와 불확실한 실험을 시도할 문턱은 낮아졌다. 다만 무엇을 최적화할지 정하고 성공을 판별하는 안목만큼은 여전히 사람의 몫으로 남는다.