6.86배 빨라졌다는데 왜 못 믿나 — 성능 최적화 자동화의 best-of-N 함정

앞 글에서 UI를 만드는 일은 자동화됐지만 판정하는 일은 여전히 사람 몫이라는 이야기를 했다. 성능·메모리 최적화 루프를 자동화하려다 똑같은 벽을 만났다. 메모리는 적게, 속도는 빠르게 — 이걸 프로파일링 돌려 가며 끝없이 개선하는 루프인데, 논문들을 보면 "AI가 코드를 6.86배 빠르게 만들었다, 사람 평균 3.66배를 앞섰다" 같은 문장이 넘친다. 그대로라면 최적화 루프는 이미 사람 손을 떠났어야 한다.

그런데 이 6.86배라는 숫자에는 조용히 숨어 있는 조건이 하나 있다. 그 조건을 알고 나면 "왜 아직도 내가 프로파일러를 붙잡고 있나"가 설명된다. 이번 글은 LLM 최적화가 실제로 어디까지 왔고, 저 숫자를 왜 액면 그대로 믿으면 안 되는지, 그래서 사람은 어디에 서 있어야 하는지를 다룬다.

LLM 최적화의 '6.86배'가 숨기고 있는 것

본론부터 보자. AI가 코드를 직접 빠르게 고쳐 준다는 연구들이다. 가장 많이 인용되는 PIE(ICLR 2024)는 "사람 평균 3.66배를 넘어 6.86배 speedup을 달성했다"고 보고했다. 문장만 보면 AI 완승이다. 그런데 그 6.86배 옆에는 best@8이라는 꼬리표가 붙어 있다. 이게 핵심이다.

다이어그램 설명. best-of-N(줄여서 best@N)이란 AI에게 같은 문제를 N번 풀게 한 뒤 가장 좋은 결과 하나만 골라 성적으로 삼는 방식이다. 이 그림은 8번 생성해서 그중 가장 빠른 것만 뽑아 "평균 6.86배"라는 헤드라인이 만들어지는 과정을 보여준다. 초록색 단계(생성하고 채택하는 것)는 자동으로 돌아가지만, 마지막 빨간색 단계에 함정이 있다 — 8개 중 어느 게 진짜 맞는 답인지 고르려면 결국 사람이 각각을 실제로 실행하고 측정하고 검증해야 한다. 여기서 놓치기 쉬운 오해는 "6.86배가 AI 한 번의 실력"이라고 읽는 것이다. 한 번만 생성했을 때(single) 수치는 이보다 훨씬 낮고, 8개를 걸러 줄 채점자(측정·검증)가 없으면 저 평균은 손에 잡히지 않는다.

같은 함정이 다른 연구에도 반복된다. ComPilot(PACT 2025)은 미세조정 없이 컴파일러 최적화를 시켜 PolyBench라는 벤치마크에서 단일 실행 2.66배, best-of-5로는 3.54배를 냈다 — 5번 중 최고를 고르면 한 번 실행보다 눈에 띄게 올라간다. Astra(NeurIPS 2025)는 코드 생성·테스트·프로파일링·계획을 여러 AI가 협업하는 첫 GPU 커널 최적화 시스템으로, 한 프레임워크에서 뽑은 CUDA 커널에 대해 평균 1.32배를 냈다. 방향은 분명 인상적이다. 하지만 숫자를 읽는 눈은 달라야 한다.

두 번째 한계 — 아무도 독립 재현하지 않았다

best-of-N이 첫 번째 한계라면, 두 번째는 더 근본적이다. 위 speedup 수치들(6.86배·3.54배·2.66배·1.32배)은 거의 전부 연구팀이 자기 벤치마크에서 자기 방법으로 측정해 자기가 보고한 값이다. 제3자가 독립적으로 같은 결과를 재현했다는 보고는 사실상 없다. 대부분 2025~2026년에 갓 나온 프리프린트(정식 동료 심사 전 논문)라, 이 분야는 몇 달 단위로 숫자가 뒤집힌다. 화려한 개선 폭이 내 코드에서도 나온다는 보장은 어디에도 없다는 뜻이다.

연구	헤드라인 speedup	같이 봐야 할 조건
PIE (ICLR 2024)	6.86배	best@8 — 8개 중 최고. 단일 실행은 훨씬 낮음
ComPilot (PACT 2025)	3.54배	best-of-5. 단일 실행은 2.66배
Astra (NeurIPS 2025)	1.32배	자체 프레임워크 CUDA 커널, 단일 벤치
공통 — 전부 자체 보고·자체 벤치마크. 독립 재현 없음

표 설명. 세 연구 모두 왼쪽의 헤드라인 숫자만 떼어 읽으면 "AI가 몇 배씩 빠르게 해준다"로 들린다. 하지만 오른쪽 열을 붙여 읽으면 그림이 달라진다 — 저 숫자들은 여러 번 생성한 것 중 최고만 골라 나온 값이고, 그 최고를 고르려면 실제로 재는 채점자가 필요하며, 게다가 아직 누구도 남의 환경에서 같은 숫자를 재현해 보지 않았다. 개선 폭 자체는 진짜일 수 있다. 다만 그게 얼마나 일반적인지, 내 워크로드에서도 나오는지는 이 표만으로 알 수 없다.

그래서 HITL은 어디에 서야 하나

두 한계를 알고 나면 사람이 설 자리가 또렷해진다. best-of-N을 뒤집어 보면 답이 보인다. AI가 후보를 8개 생성하는 일은 값싸고, 병렬로 얼마든 돌릴 수 있다 — 여기엔 사람이 필요 없다. 진짜 일이 벌어지는 곳은 그 8개 중 하나를 고르는 채점(scoring) 자리다. 논문은 이 채점을 "각 후보의 실행 시간을 실제로 재서 최고를 고른다"로 처리했다. 그 채점자를 비워 두면 6.86배는 신기루가 된다. 그러니 HITL(Human-in-the-Loop, 자동화 루프 중간에 사람의 판단을 끼워 넣는 것)에서 사람이 지켜야 할 자리는 생성이 아니라 바로 이 채점이다.

그래서 내 개인 최적화 루프의 규칙은 단순하다. 후보를 여러 개 뽑는 것까지는 AI에 마음껏 맡긴다. 하지만 그중 무엇을 채택할지는 내가 소유한 측정 게이트가 낸 실측치로만 정한다. AI가 "이게 제일 빠릅니다"라고 말한 걸 그대로 믿는 순간, best-of-N의 채점자 자리를 비워 두는 셈이 된다. 그리고 그 측정 자체가 믿을 만해야 한다 — 대표성 있는 워크로드에서, 벤치마크 노이즈를 감안해 여러 번 반복해서 재야 측정 노이즈가 만든 착시에 속지 않는다.

"측정 게이트"라고 하면 사람이 매번 앱을 손으로 굴려 가며 재는 그림을 떠올리기 쉬운데, 그게 아니다. 후보를 실행하고 시간을 재서 최고를 고르는 구동은 자동으로 돌아간다 — 논문의 best@8이 바로 그 자동 채점이다. 사람이 실제로 소유하는 건 그 게이트의 설계다. 무엇을 대표 워크로드로 볼지, 그 워크로드를 어떤 시나리오로 앱을 굴려 재현할지, 어느 정도 차이를 유의미한 개선으로 인정할지 — 이 판단과, 그 시나리오를 한 번 저작해 두는 선행 작업이 사람의 몫이다. 시나리오를 짜는 데는 손이 들지만, 그건 한 번(그리고 유지보수)의 선행 비용이지 매 변경마다의 클릭 노동이 아니다. 한 번 짜 두면 구동·측정·채점은 자동이고, 자동화로 넘길 수 없는 건 딱 이 무엇을 어떻게 잴지 정의하는 자리다.

독립 재현이 없다는 두 번째 한계도 같은 결론으로 모인다. 남이 보고한 6.86배를 내 코드의 기대치로 옮겨 오면 안 되고, 내가 정의한 게이트에서 내가 다시 재야 한다. 결국 사람이 지키는 채점자 자리란 스톱워치를 누르는 손이 아니라, 무엇을 대표로 삼고 무엇을 합격으로 볼지 정하는 판단이다.

정리 — 최적화도 결국 '판정'에서 사람이 필요하다

정리하면 성능·메모리 자동화도 UI와 똑같은 모양이다. 최적화 후보를 생성하는 일은 상당히 자동화됐다. 그런데 "이 후보가 진짜로, 믿을 만하게 빨라졌는가"를 보장하는 일 — 무엇을 대표로 재고 무엇을 합격으로 볼지 — 은 여전히 사람이 정의하고 소유해야 한다. 6.86배라는 숫자가 매력적일수록, 그게 8번 중 최고였고 아무도 독립 재현하지 않았다는 조건을 같이 기억해야 한다.

앞 글의 UI 판정과 완전히 같은 결론이다 — 자동화가 못 미더운 지점이 정확히 어디인지 알면, 사람의 시간을 딱 그 판정·보장 지점에만 남길 수 있다. 생성은 AI에게 넘기고, 채점자 자리는 내가 지킨다. 그게 지금 성능 최적화 자동화에서 사람이 할 일의 전부이자 핵심이다.

---

참고한 공개 자료:

• Learning Performance-Improving Code Edits (PIE, ICLR 2024) — https://arxiv.org/pdf/2302.07867
• ComPilot: LLM-guided auto-scheduling (PACT 2025) — https://arxiv.org/abs/2511.00592
• Astra: LLM multi-agent GPU kernel optimization (NeurIPS 2025) — https://arxiv.org/pdf/2509.07506

---

이 글은 생성형 AI의 도움을 받아 작성되었습니다. 원본 자료를 기반으로 AI가 초안을 생성하고, 작성자가 검토·편집하였습니다.