Sonnet 3.5는 정말 훌륭한 오케스트레이터임
Sonnet 5 Is a Really Good Orchestrator
핵심 요약
Sonnet 3.5가 에이전트 워크플로우와 복잡한 작업 지시 수행에서 뛰어난 성능을 보인다는 사용자 경험 공유.
- 오케스트레이션 성능 — Sonnet 3.5가 서브 에이전트 관리 및 프로세스 수행에서 매우 안정적임
- 워크플로우 최적화 — 아키텍처 설계 후 기능 추가 과정이 매우 매끄럽게 진행됨
- 토큰 관리 — 서브 에이전트의 응답 길이를 제한하여 모델의 혼란을 방지함
- 비용 효율성 — 기존 워크플로우가 확립된 경우 저비용으로 높은 효율을 낼 수 있음
Anthropic은 Sonnet 3.5가 에이전트 워크플로우를 위해 의도되었다고 말했고, 이제 저는 그 말을 믿습니다. Sonnet 3.5 이전 모델들은 서브 에이전트를 오케스트레이션하고 프로세스를 따르는 데 능숙하지 않았습니다. 서브 에이전트로 요청을 라우팅하는 간단한 작업조차 Opus를 써야 했죠. 호기심에 Sonnet 3.5로 /implement-sprint(장기 실행 코드 변경)를 시도해봤는데 완벽했습니다.
더 이상 "여기서 멈추자"라는 말은 없습니다. "3단계 완료됐는데 4단계로 넘어갈까?" 같은 질문도 안 합니다. 그냥 프로세스를 완료하고 문제가 생기면 복구합니다. 한 가지 눈에 띄는 점은 같은 사고 수준에서 Opus보다 훨씬 빠르다는 느낌은 안 든다는 겁니다. 하지만 이건 그냥 느낌일 뿐이고 테스트는 안 해봤습니다.
[편집] 이 레포는 꽤 오래됐고 제가 많은 부분을 최적화했지만, 일반적인 패턴은 여전히 유효합니다: /arch-design -> /arch-review (보통 여러 번) -> /create-sprint -> /implement-sprint -> /fold-pending. 이 프로세스는 저에게 아주 잘 작동합니다. 프로젝트 아키텍처가 설정되면 기능 추가는 보통 매우 매끄럽게 진행됩니다.
