에이전트 팀 구성을 스스로 바꿔 GPU 커널 최적화의 지역 최적을 탈출한다
Evolving Agent Teams
무엇인가
이 논문이 다루는 문제는 코드 생성 자체가 아니라 개방형 최적화다. 목표는 정답 커널을 만드는 것이 아니라 하드웨어에 종속된 거대한 설계 공간을 탐색해 성능을 끌어올리는 것이다. FlashInfer나 FlashAttention 같은 전문가 커널은 저수준 프리미티브(WGMMA 텐서 코어, 스위즐된 공유메모리 레이아웃)와 고수준 아키텍처(디스패치 전략, 워프 전문화, 데이터플로우) 두 층위를 함께 조율하는데, 후자가 도달 가능한 성능 상한을 사실상 결정한다. 저자들이 확인한 실패 모양은 일관된다. 강한 코딩 에이전트도 초반에는 빠르게 진전하다가, 구현하기 쉬운 설계 방향을 골라 예산 대부분을 그 안에서의 튜닝에 쓰고, 디버깅 부담이 큰 대안은 다시 검토하지 않는다. DeepSeek-V3 추론에 쓰이는 MLA 디코드 커널에서 단일 에이전트는 WGMMA 기반 구현을 반복된 정확성 실패 끝에 포기하고 더 단순하지만 비효율적인 WMMA 설계로 후퇴했고, Codex 5.5 xHigh는 1000달러 예산과 수일에 걸친 시도에도 전문가 성능의 28%에 그쳤다. Claude Code Opus 4.7 1M로 구성한 고정 4역할 팀도 55%에 머물렀다. 문제는 최적화 과정이 정확성 확보, 하드웨어 프리미티브 디버깅, 병목 프로파일링, 아키텍처 재설계라는 서로 다른 국면을 지나가는데, 고정된 팀 구성은 매 국면에서 요구되는 전문성·도구·협업 방식과 어긋난다는 점이다.
어떻게 동작하나
제안 방법은 팀 구성을 탐색 대상으로 승격시키는 것이다. 저자들은 기존 시스템을 팀 구성 T=(R, Π, M), 즉 역할(Roles), 조정(Coordination), 지식관리(Knowledge management)의 세 축으로 정리하고, 이 셋이 실행 전에 사람이 설계해 고정된다는 점을 한계로 지목한다. Evolving Agent Teams는 해답 s와 함께 T를 공진화시킨다. 구조는 두 층이다. 팀 진화 층에서는 중앙 감독(supervisor) 에이전트가 각 팀의 실행을 관찰하고 성공·실패 패턴을 분석해 다음 팀 T_{v+1}을 설계한다. 팀 실행 층에서는 셸 접근권을 가진 LLM 코딩 에이전트들이 현재 구성 T_v 아래에서 커널을 작성·컴파일·프로파일링·반복한다. 두 층을 잇는 것이 지속 파일 시스템 K로, 축적된 경험 문서(learnings), 팀별 산출물(커널과 역할별 기록), 진화 이력(감독의 회고와 설계 결정)을 담는다. 감독은 팀 실행이 끝나거나 정해진 주기의 크론 작업으로 깨어나, 쉬운 경로로의 이탈, 이전 팀의 핵심 통찰 유실, 디버깅 교착, 과도한 미세 최적화 같은 징후를 진단하고 세 축을 다시 짠다. 역할은 미리 정해진 목록에서 고르는 게 아니라 필요에 따라 발명한다. 병목을 격리하는 마이크로벤치마크를 설계하는 Profiling Scientist, 주장된 성능 상한을 압박하는 Challenger, 유용한 프리미티브를 소규모 테스트로 검증하는 Primitive Study Agent, 흩어진 발견을 실행 가능한 계획으로 통합하는 Knowledge Integrator 등이다. 조정 방식은 연구→구현→프로파일링 파이프라인, 별도 브랜치 병렬 실행, 또는 둘의 결합 중에서 고르며, 예컨대 막힌 이슈 전담 디버거를 메인 코드베이스 접근 금지 조건으로 띄우는 동안 다른 에이전트가 메인 브랜치에서 최적화를 계속하게 한다. 지식관리는 각 에이전트가 결과를 어디에 남길지까지 지정하는 수준이다.
무엇과 다른가
MLA 디코드 커널 사례 연구는 이 루프가 실제로 어떻게 작동하는지 보여준다. 이 과제에서 시스템은 100개가 넘는 팀 구성을 탐색했다. V1에서 V2로 갈 때 감독은 에이전트가 압박을 받으면 WGMMA에서 스칼라 코드로 흘러가고 프로파일링은 하지 않으며 여러 변수를 한꺼번에 바꿔 원인 귀속이 불가능하다고 진단하고, 비-WGMMA 커밋을 차단하고 커밋당 한 번에 한 변경만 허용하는 Disciplinarian 역할과 LEARNINGS.md를 도입해 첫 정상 동작 WGMMA 커널을 얻었다(커널 시간 비율 0.15 → 0.065). V5에서 V6에서는 V3~V5가 모두 같은 근본 원인으로 P@V WGMMA 통합에 실패한 것을 보고 감독이 직접 병렬성을 지휘했고, 메인 커널을 건드릴 수 없는 Focused Debugger와 마이크로 연산만 다루는 Main Optimizer를 격리된 브랜치에서 동시에 돌려 0.34 → 0.49(+44%)를 기록했다. V7에서 V8에서는 이전 팀의 전략적 권고가 공유 학습 문서에 없어 반복 유실되는 문제를 잡아 SYNTHESIS.md를 만들고 이후 팀에 읽도록 강제했으며(0.50 → 0.51), WGMMA 통합으로 병목 구조 자체가 바뀐 뒤에는 이전 병목 분석을 모두 폐기하고 재프로파일링부터 시작해 0.50 → 0.66(+32%)을 얻었다.
어떻게 쓰나
실험은 두 아키텍처에 걸친 네 개의 CUDA 커널 최적화 과제다. Blackwell B200의 FlashAttention-4 프리필과 Gated DeltaNet 프리필, Hopper H100의 MLA 페이지드 디코드와 GEMM+AllReduce(G+AR) 융합이다. 지표는 워크로드 집합에 대한 베이스라인 대비 지연시간 비의 기하평균으로, 1.0배를 넘으면 베이스라인이 느리다는 뜻이다. 동일 토큰 예산 통제下에서 Evolving Agent Teams는 네 과제 모두 Claude Code(Opus 4.6 1M, 파일 편집·셸·컴파일러 호출 가능)를 앞섰다. MLA 디코드에서는 Claude Code가 0.44~0.51배에서 평탄해지며 WGMMA를 포기하는 반면 진화형 팀은 0.74배에 도달했고, 예산을 늘리자 FlashInfer-Bench의 프로덕션 DeepSeek-V3 워크로드 47개에서 평균 1.21배 속도 향상, 47개 중 36개에서 우위(나머지 11개는 0.86~0.99배)를 기록해 프로덕션 FlashInfer MLA 페이지드 디코드 커널을 능가했다. 이전 최고 기록인 K-Search는 0.61배였다. GDN 프리필은 21개 팀 버전에 걸쳐 2.2배에서 4.06배까지 개선됐고, 최악 워크로드가 0.40배로 올라오며 베이스라인 미달 워크로드가 100개 중 43개에서 37개로 줄었다. G+AR은 cuBLAS+NCCL 대비 1.56배로 ThunderKittens(1.54배)와 견줄 수준이며, 예산을 늘린 실행에서 cuBLAS를 완전히 우회하고 NVLink 멀티캐스트를 all-reduce에 결합한 WGMMA 커널을 발견해 통신 지연이 지배적인 최소 워크로드에서 2.57배를 냈다. 이미 전문가가 튜닝한 코드에서도 작동한다는 점도 확인했다. Flash-KMeans의 Triton 할당 커널을 CUDA로 다시 쓰게 해 기본 워크로드에서 1.71배, 연산 지배 구성에서 최대 1.5배 낮은 지연을 얻었다.
전제와 한계
절제 실험은 이득이 모델 선택이나 다중 에이전트 구조 자체에서 오는 것이 아님을 분리한다. 같은 모델·같은 다중 에이전트 골격을 쓰되 진화가 없는 고정 4역할 팀(Profiler, Hardware Researcher, Planner, Implementer)은 0.31배, GPT-5.5 xhigh 258K의 Codex는 0.28배였고, 진화형 팀은 0.74배였다. GPU 커널 최적화 전용으로 설계된 K-Search, CUDAForge와의 비교에서도 같은 800달러 예산·동일 모델로 두 번의 실행 모두 우세했는데, 격차의 원인은 각 시스템이 정착한 구현 계열이었다. 진화형 팀은 두 실행 모두 WGMMA 기반 커널을 만들었고, K-Search는 WMMA, CUDAForge는 스칼라/SIMT 코드로 수렴했다. 나아가 같은 감독 프롬프트와 사전 정의된 역할 없이 더 새로운 모델로 돌린 실험에서 AMD MI350X의 vLLM 수제 HIP 커널 대비 3.01배, B200의 FlashKDA 대비 3.44배(KDA 프리필), Apple M4 Pro 48GB에서 MLX 4비트 Qwen3.8-Flash-Next의 MoE 전문가 오프로드 서빙 30.3 토큰/초 디코드, RoboDojo 시뮬레이션 양팔 조작 42개 과제에서 held-out 시드 62.1점(리더보드 최고 55.3, π0.5 VLA 단독 11.4)을 보고했다.
실무자에게 이 논문이 주는 신호는 명확하다. 첫째, 장시간 실행되는 코딩 에이전트 파이프라인에서 성능이 평탄해지는 원인이 모델 능력이 아니라 팀 구성의 경직성일 수 있다는 진단 틀(Roles·Coordination·Knowledge management)을 제공한다. 둘째, '어려운 구현을 포기하고 쉬운 구현으로 후퇴하는' 실패 모양은 GPU 커널에 국한되지 않으므로, 규율 강제(Disciplinarian), 격리 병렬 디버깅, 세대 간 지식 합성 문서 같은 개입 패턴은 다른 개방형 최적화 작업에도 이식 가능한 레시피다. 셋째, 성능 비교를 볼 때 토큰 예산이 통제되었는지, 실행 횟수가 몇 번인지, 베이스라인이 무엇인지를 반드시 함께 확인해야 한다. 이 논문의 핵심 수치들도 예산 조건(통제/확장)에 따라 0.74배와 1.21배로 갈린다.
저자들이 밝힌 한계는 통계적 엄밀성이다. 주요 설정은 각 2회, 5절(새 하드웨어·새 도메인 실험)의 설정은 1회만 실행해 통계적 비교에는 제약이 있으며, 비용 대 성능 파레토 분석과 더 노이즈가 큰 도메인에 대한 통제된 연구는 향후 과제로 남겨두었다. 또한 감독 에이전트 자체가 Claude Code 에이전트이고 워커들도 Opus 계열 모델 위에서 돌아가므로, 결과 수치는 특정 모델·API 가격 체계에 묶여 있다는 전제도 깔려 있다.