코딩 에이전트 10개를 돌리는 건 이제 어려운 문제가 아님. 진짜 문제는 그들에게서 유용한 자율적 결과물을 뽑아내는 것임.
Running 10 coding agents isn't the hard problem anymore. Getting useful autonomous work out of them is.
핵심 요약
에이전트 실행 환경과 개발 워크플로우를 분리하여, 에이전트의 작업 방식을 체계화하고 성능을 벤치마킹하는 새로운 접근법을 제안함.
- 워크플로우 분리 — 에이전트 런타임과 개발 워크플로우를 분리하여 에이전트를 교체 가능한 모듈로 활용함.
- 작업 체계화 — GSD, Spec-kit 등 다양한 워크플로우를 정의하여 에이전트의 단계, 기술, 프롬프트를 제어함.
- 성능 벤치마킹 — SWE-bench를 활용해 특정 워크플로우와 에이전트 조합의 성능을 객관적으로 측정함.
이제 에이전트 찍어내는 건 꽤 익숙해졌지.
tmux, worktrees, containers, session managers까지, 이제 Claude Code, Codex, Gemini 같은 걸 병렬로 돌릴 방법은 널리고 널렸어.
근데 이제는 그보다 한 단계 위인, 더 흥미로운 문제가 눈에 들어오기 시작하네.
도대체 이 에이전트들이 어떤 워크플로우를 따라야 하는가?
난 이걸 해결하려고 에이전트 런타임이랑 개발 워크플로우를 아예 분리해서 실험 중이야.
예를 들어 이런 식이지:
Gemini → 리서치
Claude → 구현
Codex → 리뷰
근데 이 워크플로우 자체는 GSD, Spec-kit, OpenSpec, BMAD, Superpowers가 될 수도 있고, 그냥 커스텀 TOML 플러그인이 될 수도 있는 거야.
그러니까 오케스트레이터에 "에이전트가 코딩하는 법"을 하드코딩하는 대신, 워크플로우가 단계, 스킬, 프롬프트, 아티팩트, 게이트를 정의하고 그걸 실행할 코딩 에이전트에 매핑하는 거지.
이렇게 하면 에이전트가 일종의 교체 가능한 런타임이 된다는 게 꽤 흥미로운 지점이야.
이제 이런 질문을 던질 수 있게 되는 거지:
GSD + Claude 조합이 GSD + Codex보다 성능이 좋을까?
아니면,
Gemini 리서치 → Claude 구현 → Codex 리뷰로 이어지는 Spec-kit 조합이, 전체 과정을 Claude 하나로 밀어붙이는 것보다 나을까?
슬슬 에이전트 숫자를 늘리는 것보다, 이 워크플로우 계층이 자율 코딩에서는 훨씬 더 중요할지도 모르겠다는 생각이 들어.
여기에 SWE-bench 러너까지 붙여놨으니까, 이제 입만 털지 말고 직접 조합별로 벤치마크를 돌려볼 생각이야.
혹시 너희도 코딩 에이전트를 이런 식으로 생각하고 있는지 궁금하네.
관심 있는 사람들을 위한 저장소:
https://github.com/fynnfluegge/agtx
