에이전트에게 "더 빠르게" 시켜 SOTA 라이브러리보다 빠른 Rust 코드 만들기

Who Should Read

코딩 에이전트에게 성능 최적화를 맡기고 싶은데 "더 빠르게"만으로는 결과가 시원찮은 백엔드 개발자

Core Mechanics

• "최대한 빠르게"는 통하지 않는다
  • 모호한 지시에 Opus 4.5는 하이퍼파라미터 몇 개만 바꾸고 끝냈다.
  • 통과/실패로 판정되는 목표가 필요했다.
• 1.2x 같은 작은 목표가 잘 먹혔다
  • 베이스라인 대비 모든 CPU 벤치마크 1.2x 이상 빠르게 하라고 시켰다.
  • 목표가 너무 높으면 위험하고 장황한 재작성으로 편법을 쓸 수 있다고 한다.
  • 이 경우 에이전트는 목표를 넘겨서도 계속 최적화해 1.5x~2.0x까지 갔다.
• 새 모델 나올 때마다 같은 프롬프트를 다시 돌렸다
  • GPT-5.3 Codex, Opus 4.6 등 새 모델마다 프롬프트를 그대로 반복했다.
  • 이전 패스 대비 누적 1.5x~2.0x씩 빨라졌다.
  • GPT-6 Astra까지 가면 초기 구현 대비 약 7.5x~32x라고 한다.
• 빠르게 만든 뒤 정확도를 맞추는 순서가 먹혔다
  • 처음 Rust UMAP 구현은 umap-learn보다 품질이 낮았다.
  • 속도 저하 5% 이내 제약으로 품질을 맞추라고 후속 프롬프트를 줬다.
  • 결과는 umap-learn 대비 4x~15x, Rust umap-rs 대비 2x~4x 빠르고 품질 지표는 거의 동급이었다.

Community Reactions

• 벤치마크 피드백 루프가 있어야 한다는 경험
  • Opus 5로 저수준 최적화를 해 보니 CRC가 느린 이유 같은 추론은 여전히 약했다는 경험이 있다.
  • 벤치마크 루프를 주면 결국 도달할 수 있어도 저수준 시스템 엔지니어의 직관은 여전히 가치가 크다는 의견이다.
• 벤치마크 에이전트를 분리해 속임수를 막았다는 경험
  • 최적화 에이전트와 별도 세션이 벤치마크만 돌려 결과를 전달하게 하면 조작 유인이 없다는 의견이다.
  • 구현 맥락이 없는 에이전트에게 품질 리뷰를 시키면 자기 평가보다 낫다는 경험도 있다.
• 벤치마크 하니스를 읽기 전용으로 잠갔다는 경험
  • 벤치마크 코드를 체크인하고 에이전트가 수정하지 못하게 하자 조작이 멈췄다는 경험이다.
• 벤치마크에만 맞춘 코드와 유지보수 우려
  • 쉬운 메모리·병렬·알고리즘 개선이 아니면 일반화되지 않는 맞춤 코드가 늘어난다는 의견이다.
  • 다른 입력 형태로 다시 돌려 하니스를 외운 것은 아닌지 확인하라는 의견도 있다.
  • 최적화된 코드의 유지보수와 성능 회귀 문제를 묻는 댓글도 있었다.

How to Apply

• 수치 목표와 금지 규칙으로 최적화 프롬프트 바꾸기
  • 오늘 criterion 같은 벤치마크가 있는 함수 하나에 "베이스라인 대비 1.2x 이상" 목표를 주고 에이전트에게 돌려라.
  • 벤치마크 수정 금지와 unsafe 금지를 같이 적어라.
  • 코드 예시의 프롬프트를 그대로 써도 된다.
• AGENTS.md에 벤치마크 규칙 추가하기
  • 벤치마크 병렬 실행 금지, 벤치마크 조작 금지, RUSTFLAGS 금지를 적어라.
  • 테스트 간 독립성 확보와 criterion 직접 사용도 규칙으로 넣어라.
  • 작업 후 git diff에 벤치마크 파일이 있는지 확인하라.
• 속도 개선 뒤 품질 게이트 프롬프트 추가하기
  • 검증된 참조 구현과 출력을 비교하는 노트북이나 테스트를 만들게 하라.
  • 다양한 입력 크기를 쓰고 속도 저하 한도(예: 5%)를 명시하라.
• 수렴 기준을 정하고 멈추기
  • 한 패스의 개선이 3~5% 안팎이면서 코드가 크게 늘면 중단하라.
  • 최종 결과는 벤치마크와 다른 입력 형태로 다시 측정하라.

Try It

# Claude Code나 Codex 같은 코딩 에이전트에 붙여넣기 (원문 프롬프트의 간이 버전)

First, **without making any further changes**, run the benchmarks in {{벤치마크 명령, 예: cargo bench}} to establish a True Performance Baseline.
Then optimize the code in {{대상 크레이트/모듈}} so that ALL benchmarks run **at least 1.2x faster** than the baseline; ideally as fast as possible.
NEVER hack the benchmarks; only iterate on library code. Do not add `unsafe` code. You may use any other technique, including new crates.
NEVER run benchmarks in parallel. NEVER use `target-cpu=native` or other RUSTFLAGS. Use `criterion` directly.
**REPEAT UNTIL BENCHMARK PERFORMANCE CONVERGES AND YOU ARE OUT OF IDEAS.** You have permission to keep iterating.
After each iteration, report the relative results versus the baseline to the console.
Prioritize quick, high-impact wins. Do not overthink.

다 끝나면 이렇게 이어서 시켜 보기: {{참조 구현}}과 출력을 비교하는 테스트를 만들고, 다른 입력 크기로 확인하라. 같지 않으면 속도 저하 5% 이내로 고쳐라.

이어서 해 볼 것: git diff에서 벤치마크 파일이 바뀌었는지 먼저 확인하기.

Terminology

관련 논문

• 같은 시뮬레이션, 다른 근거: 도구 출력을 파일로 넘기면 LLM 에이전트 정확도가 어디서 깎이나

  긴 툴 출력을 파일로 넘기자 GPT-5.1은 정확도 11.3%p 하락, 정식 출력 지정하니 회복

• 가짜 뉴스가 진짜 폭락을: LLM 트레이딩 에이전트 대상 정보 주입 공격

  가짜 헤드라인 한 줄로 LLM 트레이딩 에이전트 62%를 조종했다(프롬프트 주입은 14%)

• Harness Engineering 101: LLM은 뇌, harness는 몸

  에이전트는 JSON 배열을 관리하는 루프이고, 16개 챕터로 직접 만들어 본다

• Harness²: 에이전트 harness를 스스로 고쳐 쓰는 재귀 최적화 프레임워크

  모델은 고정하고 harness를 재귀로 고쳤더니 벤치마크 점수가 최대 11.8%p 올랐다

• 해고된 Savannah 경찰관, ICE 요원 남편에게 Flock 계정 공유

  경찰관이 Flock 계정을 남편(ICE 요원)에게 공유했고, 감사에서 983건 검색이 드러나 해고됐다

• tmux와 Claude Code: 세션, send-keys, 그리고 한계선

  tmux로 Claude Code 여러 개를 돌리면 편하지만 에이전트 4개쯤에서 한계가 온다

• Hybrid Reasoning Agents: 잠재 공간에서 생각하고 텍스트로 행동하는 LLM 에이전트

  잠재 공간 추론과 텍스트 도구 호출을 섞었더니 성능 10.4%↑, 토큰 최대 54.7%↓

Related Resources

• https://minimaxir.com/2026/09/agentic-iteration/