코딩 에이전트가 바꾸는 성능 최적화의 경제학: 이제 '느린 소프트웨어'는 선택의 문제다
핵심 요약
한때 성능 최적화는 극소수 전문가만 할 수 있는 값비싼 작업이었습니다. 하지만 코딩 에이전트가 등장하면서 이 비용 구조가 완전히 바뀌고 있습니다. 몇 문장의 지시만으로 컴파일러 전환, 멀티스레딩, 워크로드별 맞춤 최적화까지 시도할 수 있게 된 것이죠. 실제 실험 결과를 보면 그 효과는 결코 작지 않습니다.
- FRE 검색 엔진에 네이티브 AOT 컴파일을 도입해 장시간 검색을 2~4배 빠르게 만듦
- Azul 보드게임 AI는 멀티스레딩 도입만으로 기존 세계 최강 AI를 넘어섬 (속도 2배당 약 100 Elo 상승)
- 개인 ripgrep 사용 기록에 맞춘 최적화로 단 한 번의 패스만에 홀드아웃 성능 2% 향상
왜 지금 이게 중요한가
과거에는 "이 최적화가 2% 성능을 높여줄 것 같은데, 검증에만 며칠이 걸린다"는 상황이면 대부분 포기했습니다. 하지만 에이전트를 활용하면 사람이 투입해야 하는 시간이 작업에 따라 1,000배에서 100만 배까지 줄어들 수 있습니다. 즉, 예전 같으면 시도조차 안 했을 불확실한 아이디어도 이제 부담 없이 실험해볼 수 있는 시대가 된 겁니다.
FRE와 ripgrep: 실제 실험이 보여준 것
FRE는 에이전트가 한 달간 정규식 벤치마크(rebar)에 맞춰 개선한 검색 엔진입니다. 흥미로운 점은 초반에 벤치마크에 심하게 과적합했다가, "별도 홀드아웃 벤치마크가 있다"는 사실을 알려주자 일반화 성능이 좋아졌다는 겁니다. 이는 에이전트에게 무엇을 지시하느냐가 결과 품질에 얼마나 결정적인지를 보여줍니다.
실전 적용 실험도 있었습니다. ripgrep이 검색하는 동안 백그라운드 스레드에서 네이티브 코드를 컴파일하고, 완료되면 그쪽으로 전환하는 방식입니다.
- 실제 Codex 사용 기록에서 가져온 쿼리로 벤치마크한 결과, 단순한 장시간 검색은 2~4배 빨라짐
- 대표성 있는 홀드아웃 쿼리에서는 약 7% 향상
- 다만 짧은 쿼리는 컴파일에 스레드를 뺏겨 오히려 느려질 수 있어 트레이드오프가 존재함
재미있는 건, 이런 네이티브 컴파일이 항상 답은 아니라는 점입니다. 반복적인 텍스트 검색이 목적이라면 정규식 AOT 컴파일러보다 인덱스 구축이 더 직접적인 해법일 수 있습니다. 실제로 Bing 검색에 쓰인 BitFunnel 같은 프로젝트는 과거엔 대규모 팀 작업이었지만, 이제는 일부 구현을 주말 동안 시도해볼 수 있는 범위가 됐습니다.
게임 AI에서 확인된 압도적 격차
가장 인상적인 사례는 Azul 보드게임 AI입니다. 게임 AI 지식이 전혀 없는 상태에서 시작했음에도, 기존 세계 최강 AI를 큰 차이로 앞섰습니다. 승부를 가른 건 AI 기법의 차이가 아니라 구현 최적화였습니다.
- 기존 AI: 단일 스레드 / 새 AI: 멀티스레드
- 비결정적 멀티스레딩 버그를 잡기 위해 디버그 로그 재생 기능까지 구현 — 수작업이면 며칠~일주일 걸릴 작업
- 속도가 2배 될 때마다 약 100 Elo 상승, 여기에 수작업으로는 번거로워 포기했을 최적화 10~20개가 누적되면 격차는 매우 커짐
다만 여기엔 한계도 있습니다. 최신 공개 모델은 아직 스스로 안정적인 실험(벤치마크) 환경을 설계할 만큼 강하지 않습니다. "빨라진 게 실제로 더 강해진 것인가"를 판단할 평가 프레임워크는 사람이 먼저 만들어줘야 했습니다. 프레임워크만 갖춰지면 그다음부터는 일반적인 최적화 반복 작업으로 처리할 수 있었습니다.
그렇다면 개발자는 게을렀던 걸까?
이 글에서 강조하는 중요한 지점 중 하나는, 일반 프로젝트가 전문가 최적화 결과보다 느리다고 개발자를 탓하는 건 부당하다는 것입니다. 대부분의 개발자가 성능 전문성을 갖추지 못한 건 자연스러운 일이고, 사업 요구와 고용 시장을 고려하면 모두가 그런 전문성을 쌓는 것도 비현실적입니다.
대신 이제는 범위가 명확한 문제에서 전문가 수준(혹은 그 이상)의 성능을 코딩 에이전트로 끌어낼 수 있습니다. 단, 에이전트에는 아직 전문가급 판단력이 없어서 개방형(open-ended) 문제에는 약합니다. 실제로 "과적합하지 말라"는 막연한 지시만 줬을 때는 최고 정규식 엔진보다 10배 이상 느린 결과가 나왔고, "홀드아웃 성능이 나쁘다"고 구체적으로 알려준 뒤에야 2군 엔진 수준까지 개선됐습니다. 결국 좋은 지시와 명확한 검증 기준이 여전히 핵심이라는 뜻이죠. 이 접근은 백엔드뿐 아니라 LCP·INP 같은 프런트엔드 성능 지표 개선에도 그대로 적용할 수 있습니다.
개인 워크로드 맞춤 최적화라는 새로운 가능성
가장 눈에 띄는 변화는 "고객별·개인별 실제 사용 패턴에 맞춘 동적 맞춤 소프트웨어"가 현실적인 선택지가 됐다는 점입니다. 별도 프레임워크 없이 개인 ripgrep 쿼리 기록만으로 FRE 엔진을 최적화하는 실험은 단 2분 만에 시작할 수 있었고, 첫 패스만으로 홀드아웃 성능이 2% 향상됐습니다.
물론 주의할 점도 있습니다. 데이터 분포가 바뀌면 과적합된 최적화가 실패할 수 있어서, 이런 맞춤화는 지속적인 모니터링과 함께 가야 합니다. 그럼에도 실행 비용이 몇 분 수준으로 낮아졌다는 사실 자체가, 이제는 고급 기법을 찾아 헤매기보다 단순하고 투자 대비 효과가 큰 개선부터 가볍게 시도해보는 게 합리적인 전략임을 보여줍니다.
마무리
"소프트웨어가 느린 이유는 개발자의 게으름이 아니라 최적화의 경제성 문제였다"는 관점이 이 글의 핵심입니다. 그 경제성이 코딩 에이전트로 인해 극적으로 바뀌고 있는 지금, 우리가 던져야 할 질문은 "왜 이렇게 느리게 만들었나"가 아니라 "이제 우리가 원하는 성능 수준을 얼마나 쉽게 선택할 수 있는가"로 바뀌고 있습니다.