에이전트 기반 코딩 전략: 무엇이 효과적이고 무엇이 역효age를 일으키는가

솔직한 답변은 "더 많은 에이전트를 사용하라"나 "가장 큰 모델을 구매하라"가 아닙니다. 최선의 에이전트 기반 코딩 (Agentic Coding) 전략은 작업의 형태에 따라 달라집니다.

현재 제가 신뢰하는 패턴은 다음과 같습니다:

작고 순차적인 작업: 긴밀한 컨텍스트 (Context)를 가진 강력한 에이전트 하나.
크고 병렬적인 작업: 명확한 인수인계 (Handoff)가 이루어지는 전문화된 에이전트들.
프로덕션 작업: 코드 작성 전의 사양 (Specs) 정의, 코드 작성 후의 테스트, 그리고 단계 사이의 결정론적 (Deterministic) 체크.
비용 민감형 작업: 쉬운 단계는 더 저렴한 모델로 라우팅하고, 모호함, 아키텍처, 그리고 리뷰를 위해 프런티어 모델 (Frontier models)을 예약.
익숙한 코드베이스: AI를 조심스럽게 사용하십시오. 숙련된 개발자의 속도를 늦출 수 있습니다.

가장 큰 실수는 모든 코딩 작업을 동일한 워크로드로 취급하는 것입니다.

1. 작업이 진정으로 병렬적일 때 멀티 에이전트 팀이 도움이 됩니다

멀티 에이전트 코딩 시스템은 작업이 역할별로 나뉠 수 있을 때 가장 강력해 보입니다: 플래너 (Planner), 코더 (Coder), 리뷰어 (Reviewer), 테스터 (Tester), 문서 작성자 (Docs writer), 마이그레이션 전문가 (Migration specialist), 보안 리뷰어 (Security reviewer).

제공된 노트에서 발견된 가장 강력한 증거는 전문화 (Specialization)와 교차 검증 (Cross-validation)이 유용한 메커니즘이라는 점을 가리킵니다. vibecoding.app의 멀티 에이전트 비교 보고서에 따르면, 유사한 모델 클래스를 사용하는 단일 에이전트 베이스라인의 SWE-bench Verified 점수가 약 65%인 것에 비해 멀티 에이전트 팀은 72.2%를 기록했습니다. 동일한 보고서는 더 강력한 리뷰 성능을 보고했습니다: 단일 에이전트 리뷰의 약 51% 대비 60.1%의 코드 리뷰 F1 점수를 기록했으며, 더 나은 치명적 버그 탐지 능력을 보여주었습니다.

저는 이것을 "항상 5개의 에이전트를 실행하라"로 해석하지 않습니다. 저는 다음과 같이 해석합니다:

범위가 넓을 때는 계획 (Planning)과 실행 (Execution)을 분리하십시오.
정확성이 중요할 때는 리뷰어 에이전트를 사용하십시오.
작업들이 동일한 가변적 컨텍스트 (Mutable context)를 필요로 하지 않을 때만 팬아웃 (Fan out) 하십시오.
인수인계 (Handoffs)를 명시적으로 유지하십시오: 변경된 파일, 작업 의도, 실행된 테스트, 알려진 리스크 등.

트레이드오프 (Tradeoff)는 실재합니다. 멀티 에이전트 실행은 더 많은 토큰 비용이 발생하고, 조정 오버헤드 (Coordination overhead)를 생성하며, 실패 시 디버깅을 더 어렵게 만듭니다. 만약 하나의 에이전트가 전체 문제를 파악할 수 있고 작업이 순차적이라면, 에이전트를 추가하는 것은 대개 지연 시간 (Latency)만 늘릴 뿐입니다.

2. 계층적 분해 (Hierarchical decomposition)가 하나의 거대한 계획보다 낫습니다

에이전트가 전체 계획을 하나의 평면적인 리스트 (flat list)로 유지하려고 할 때 장기적 작업 (Long-horizon work)은 실패합니다. 유용한 전략은 계층 구조 (hierarchy)를 사용하는 것입니다:

목표 (Goal).
마일스톤 (Milestones).
마일스톤 간의 인터페이스 (Interfaces).
파일 수준의 작업 (File-level tasks).
검증 게이트 (Verification gates).

이는 단순히 형식을 갖추기 위한 절차가 아닙니다. 이는 오류의 누적 (compounding error)을 제한합니다.

Spec Kit Agents는 이러한 방향성의 좋은 예시입니다. 해당 논문은 SPEC, PLAN, TASKS, IMPLEMENT 단계로 구성된 단계별 워크플로 (workflow)를 설명하며, 각 단계 전에는 컨텍스트 그라운딩 (context-grounding) 훅을, 각 단계 후에는 검증 (validation) 훅을 배치합니다. 보고된 결과는 크지 않지만 유용합니다. 컨텍스트 그라운딩은 1-5점 복합 점수에서 판단된 품질을 0.15 개선했으며, SWE-bench Lite Pass@1을 1.7 퍼센트 포인트 향상시켜 58.2%에 도달했습니다.

이것이 올바른 교훈입니다. 명세 (specs)가 마법처럼 에이전트를 천재로 만드는 것이 아닙니다. 명세는 실패를 더 일찍 가시화할 수 있게 해줍니다.

3. 명세 주도 및 테스트 주도 워크플로는 서로 다른 문제를 해결합니다

명세는 의도 (intent)를 정의합니다. 테스트는 성공 (success)을 정의합니다.

에이전트 기반 코딩 (agentic coding)을 위해서는 두 가지 모두가 필요합니다:

동작, 제약 조건, 비목표 (non-goals), 수락 기준 (acceptance criteria)을 명시한 짧은 명세.
수정된 파일과 위험한 가정 (risky assumptions)을 나열한 계획.
변경 사항이 작동함을 증명하는 테스트 또는 체크.
원래 명세와 비교하여 차이점 (diff)을 읽는 최종 검토 단계.

명세 주도 개발 (Spec-driven development)은 에이전트가 API를 환각 (hallucinate)하거나, 저장소 컨벤션 (repo conventions)을 무시하거나, 원래 목표에서 벗어날 가능성이 있을 때 가장 유용합니다. 테스트 주도 개발 (Test-driven development)은 기대되는 동작을 실행 가능한 신호 (executable signal)로 인코딩할 수 있을 때 가장 유용합니다.

이것이 역효과를 내는 경우: 국소적 범위 (local scope)가 명확한 작은 변경 사항일 때입니다. 두 줄짜리 검증 수정을 위해 5페이지짜리 명세를 작성하지 마십시오.

4. 하네스 (harness)는 사람들이 인정하고 싶어 하는 것보다 더 중요합니다

MindStudio는 냉혹한 결과를 요약했습니다. 동일한 모델이라도 하네스 설계만으로 최대 6배의 성능 차이를 보일 수 있습니다. 그들의 실무적인 권장 사항은 실행에 옮길 가치가 있습니다:

에이전트가 필요하지 않은 도구(tools)를 제거하십시오.
프롬프트(prompt)에서 무관한 컨텍스트(context)를 제외하십시오.
검증기(verifiers)와 검색 루프(search loops)가 도움이 될 것이라고 가정하기 전에, 실제 작업 부하에 도움이 되는지 테스트하십시오.
오케스트레이션(orchestration) 로직을 모델이 이해할 수 있는 곳에 배치하십시오.

이는 저의 개인적인 견해와도 일치합니다. 에이전트의 성능은 종종 모델 선택의 문제라기보다 시스템의 문제입니다.

질문은 "어떤 모델이 가장 좋은가?"가 아닙니다. 다음과 같습니다:

모델이 어떤 컨텍스트(context)를 보는가?
모델이 어떤 도구(tools)를 호출할 수 있는가?
모델 외부에서 결정론적(deterministic)으로 처리할 수 있는 작업은 무엇인가?
다음 단계로 넘어가기 전에 무엇이 검증(verified)되는가?
실행이 실패한 이유를 조사하기가 얼마나 쉬운가?

만약 이 질문들에 대한 답이 부정적이라면, 더 강력한 모델을 사용하는 것은 대부분 더 비싼 실패를 가져올 뿐입니다.

5. 모델 계층화(Model tiering)는 비용 제어 전략입니다

모든 단계를 가장 비싼 모델로 보내지 마십시오.

실질적인 라우팅(routing) 정책:

저렴하거나 로컬(local) 모델: 검색, 요약, 보일러플레이트(boilerplate), 포맷팅, 문서 초안 작성.
워크호스(Workhorse) 모델: 일반적인 구현, 테스트 생성, 간단한 리팩터링(refactors).
프론티어(Frontier) 모델: 모호한 아키텍처, 어려운 디버깅, 보안 민감 변경 사항, 최종 검토.

정확한 모델 이름은 바뀔 수 있습니다. 하지만 라우팅 규칙은 바뀌어서는 안 됩니다.

에이전트 기반 작업(Agentic work)은 예측 불가능하게 토큰(tokens)을 소모할 수 있습니다. 에이전트 기반 코딩 작업의 토큰 소비에 관한 2026년 arXiv 논문에 따르면, 에이전트 기반 작업은 단순한 코드 채팅보다 훨씬 더 많은 토큰을 소비할 수 있으며, 동일한 작업에 대해 실행 방식에 따라 토큰 사용량이 극적으로 달라질 수 있고, 토큰 지출이 높다고 해서 반드시 정확도가 높아지는 것은 아니라고 보고되었습니다.

따라서 기본 설정은 자동적인 프론티어 모델 사용이 아니라, 측정된 단계적 에스컬레이션(escalation)이어야 합니다.

6. 익숙한 코드베이스를 다루는 숙련된 개발자는 선택적이어야 합니다

METR의 무작위 대조 시험(randomized controlled trial)은 경고 신호입니다. 그들의 2025년 초 연구에 따르면, 16명의 숙련된 오픈 소스 개발자들이 자신에게 익숙한 저장소(repositories)의 246개 실제 이슈를 처리했습니다. 개발자들은 AI가 자신을 더 빠르게 만들어 주었다고 믿었음에도 불구하고, AI 도구를 허용했을 때 완료 시간이 19% 증가했습니다.

이것이 AI가 모든 사람의 속도를 늦춘다는 것을 증명하는 것은 아닙니다. METR은 그 점에 대해 주의를 기울이고 있습니다. 다만 이는 실제적인 실패 모드 (failure mode)를 보여줍니다:

개발자가 이미 시스템을 알고 있음.
작업이 로컬 컨벤션 (local conventions)에 의존함.
AI가 검토와 정리가 필요한 그럴듯한 코드 (plausible code)를 생성함.
검토 비용이 생성으로 인한 절감 효과를 초과함.

익숙한 코드 내의 시니어 개발자에게 AI는 검색, 테스트 스캐폴드 (test scaffolds), 마이그레이션 초안, 대안 설계, 검토 체크리스트와 같이 좁은 범위의 지원 작업으로 범위를 제한하는 것이 효과적일 때가 많습니다.

나의 의사결정 프레임워크 (decision framework)

상황	기본 전략	이유
1인 개발자, 소규모 프로젝트	단일 강력한 에이전트 (Single strong agent)	낮은 오버헤드, 빠른 반복 (iteration)
...

요약된 답변 (The bucket answer)

대부분의 1인 개발자에게 가장 좋은 기본 설정은 여전히 뛰어난 컨텍스트 관리 (context management) 능력을 갖춘 단일 강력한 에이전트입니다.

복잡하고 병렬화 가능한 프로덕션 작업의 경우, 가장 좋은 기본 설정은 다음과 같습니다:

짧은 명세서 (spec).
계층적 작업 분해 (Hierarchical task decomposition).
작업이 자연스럽게 나뉘는 부분에만 특화된 에이전트 사용.
작업 인계 (handoff) 사이의 결정론적 검사 (Deterministic checks).
인간의 검토 전 리뷰어 에이전트 (reviewer agent) 배치.
작업 난이도에 따른 모델 라우팅 (Model routing).

더 많은 에이전트를 사용하는 것이 전략이 아닙니다. 더 나은 작업 경계 (task boundaries)를 설정하는 것이 전략입니다.

출처:

Multi-agent benchmark and tradeoff summary: https://vibecoding.app/blog/multi-agent-vs-single-agent-coding
Spec Kit Agents paper: https://arxiv.org/html/2604.05278v1
Harness design discussion: https://www.mindstudio.ai/blog/better-model-vs-better-harness-agent-benchmark-score
METR experienced developer RCT: https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/
Agentic token consumption paper: https://arxiv.org/abs/2604.22750