코딩 에이전트가 성능 최적화 비용을 낮추고 있어요

코딩 에이전트가 성능 최적화 비용을 낮추고 있어요

IT & AI 뉴스 썸네일

성능 최적화는 구현보다 검증에 시간이 많이 드는 작업이에요. 코딩 에이전트는 코드 수정과 벤치마크 반복에 드는 사람의 시간을 줄여요. 몇 분간 지시한 실험에서 긴 정규식 검색이 2~4배 빨라졌고, 대표 홀드아웃 쿼리도 약 7% 개선됐어요. 다만 벤치마크를 잘못 잡으면 특정 입력에만 빠른 코드가 나올 수 있어요. 1

핵심 요약

구분	확인된 결과	함께 봐야 할 조건
정규식 검색	네이티브 AOT 전환으로 단순한 장시간 검색은 2~4배 빨라졌어요	대표 홀드아웃 쿼리의 개선 폭은 약 7%였어요
게임 AI	멀티스레딩과 반복 최적화로 적은 개발 시간과 장비에서도 강한 Azul AI를 만들었어요	속도가 2배가 될 때마다 약 100 Elo가 올랐지만, 게임별 특성이 달라요
개인별 최적화	실제 ripgrep 사용 기록에 맞춘 첫 최적화가 홀드아웃에서 약 2% 향상됐어요	입력 분포가 바뀌면 과적합이 드러날 수 있어요
개발 방식	구현과 측정의 반복 비용이 낮아져 작은 개선안도 시험하기 쉬워졌어요	평가 환경과 성공 기준은 사람이 먼저 설계해야 해요

1. 성능 개선의 병목이 코드 작성에서 평가 설계로 옮겨가요

Dan Luu는 코딩 에이전트가 소프트웨어 성능 작업에 미치는 변화를 여러 실험으로 설명했어요. 예전에는 컴파일러와 멀티스레딩처럼 전문성이 필요한 변경을 시도하려면 구현과 검증에 며칠 이상을 잡아야 했어요. 이제 개발자가 요구사항을 몇 문장으로 적고 에이전트에게 코드 수정과 반복 측정을 맡길 수 있어요. 덕분에 성공 여부가 불확실한 최적화도 적은 사람 시간으로 먼저 시험할 수 있게 됐어요. 2

AOT 컴파일은 긴 검색에서 효과가 컸어요

첫 사례는 FRE라는 정규식 엔진이에요. 일반 매처가 검색하는 동안 별도 스레드에서 정규식을 네이티브 코드로 컴파일하고, 준비가 끝나면 실행 경로를 바꾸는 방식을 시험했어요. 단순하면서 오래 걸리는 검색에서는 2~4배 빨라졌어요. 실제 Codex 기록에서 고른 대표 홀드아웃 쿼리 가운데 AOT를 켤 만한 작업은 약 7% 개선됐어요.

728x90

모든 검색이 빨라진 것은 아니에요. 짧은 쿼리는 컴파일에 스레드를 내줘서 오히려 손해를 볼 수 있어요. 복잡한 정규식에서는 기존 Rust 정규식 라이브러리의 알고리듬 최적화를 활용하지 못해 느려지는 경우도 있었어요. 반복 검색이 많다면 네이티브 컴파일보다 인덱스를 만드는 편이 더 직접적인 해법일 수 있어요. 이 사례는 AOT 자체보다 여러 대안을 싸게 구현하고 실제 작업 부하에서 비교할 수 있다는 점을 보여줘요.

게임 AI는 속도가 곧 탐색 깊이로 이어졌어요

Azul 게임 AI에서는 구현 속도가 경기력과 연결됐어요. 작성자는 네이티브 코드와 WebAssembly 버전을 만들고, 서로 다른 탐색 구조에 맞는 멀티스레딩도 여러 번 다시 구현했어요. 비결정적 버그를 찾기 위해 디버그 로그를 재생하고, 결과가 달라지는 지점에 기록을 더하는 반복 작업도 코딩 에이전트에 맡겼어요. 수작업이라면 며칠에서 일주일이 걸릴 수 있는 작업이었다고 설명해요. 2

이 Azul AI에서는 실행 속도가 2배가 될 때마다 약 100 Elo가 올랐어요. 같은 시간에 더 많은 수를 탐색할 수 있기 때문이에요. 하지만 이 수치를 다른 게임이나 일반 소프트웨어에 그대로 적용할 수는 없어요. Azul은 무승부가 드물고, 구현 최적화가 탐색량과 결과에 직접 영향을 주는 조건을 갖고 있어요.

개인 사용 기록에 맞춘 최적화도 가능해졌어요

작성자는 자신의 ripgrep 쿼리를 학습용과 홀드아웃용으로 나눠 FRE를 한 번 최적화했어요. 첫 패스의 홀드아웃 성능은 약 2% 좋아졌어요. 작은 수치지만 한 사람의 실제 작업 부하에 맞춰 코드를 조정하는 비용이 낮아졌다는 사례예요.

여기에는 과적합 위험이 따라요. 같은 명령 패턴을 계속 쓰면 효과가 유지될 수 있지만, 프로젝트나 파일 구성이 바뀌면 개선 폭이 사라질 수 있어요. 공통 소프트웨어를 고객별로 자동 조정하려면 최근 작업 부하만 보지 말고 별도 홀드아웃과 이전 버전 대비 회귀 테스트를 함께 운영해야 해요.

왜 중요한가요

개발팀은 1~2% 개선을 위해 며칠을 쓰기 어려워요. 코딩 에이전트가 구현과 반복 측정을 맡으면 검토할 수 있는 아이디어 수가 늘어요. 특히 컴파일러 옵션, 메모리 배치, 병렬 처리처럼 수정 범위가 넓은 작업을 작은 실험으로 시작할 수 있어요. 2

사람의 역할은 줄어들기보다 앞단으로 이동해요. 무엇을 측정할지, 어떤 입력을 홀드아웃으로 둘지, 속도와 정확성 중 어느 기준을 지킬지 먼저 정해야 해요. FRE는 초기에 공개 벤치마크에 과적합했고, 별도 홀드아웃이 있다는 조건을 준 뒤에야 일반화된 개선을 찾았어요. 게임 AI도 실행 속도와 경기력을 함께 비교할 평가 틀이 필요했어요.

실무에서는 가장 복잡한 기법부터 시도할 이유가 없어요. 프로파일러로 병목을 찾고, 캐시나 쿼리 구조처럼 투자 대비 효과가 큰 개선부터 맡기는 편이 나아요. 에이전트가 낸 패치는 기존 테스트와 독립 벤치마크를 모두 통과해야 해요. 이렇게 평가 기준을 고정하면 저렴해진 구현 비용을 성능 개선으로 연결하면서 회귀와 과적합을 줄일 수 있어요.

참고 자료

1. 소프트웨어가 더 이상 느릴 이유는 없다 — GeekNews
2. There's no reason for software to be slow anymore — Dan Luu