복잡한 소프트웨어 엔지니어링 작업을 위한 오케스트레이션 방식을 비교해 본 적 있나요?
Has anyone compared different orchestration approaches for complex software engineering work?
핵심 요약
복잡한 개발 작업 시 비용 효율적인 에이전트 오케스트레이션 패턴과 모델 조합에 대한 실무 경험을 공유합니다.
- 비용 지표 — 토큰당 비용보다 '수락된 변경당 비용'과 재작업 최소화가 중요함
- 오케스트레이션 — 강력한 오케스트레이터와 저렴한 실행 에이전트 조합이 경제적임
- 검증 루프 — 명시적인 빌드-검증-수정 루프가 대규모 작업의 안정성을 높임
- 컨텍스트 관리 — 긴 컨텍스트 압축보다는 세션 재시작과 파일 기반 상태 유지가 효과적임
대규모 소프트웨어 엔지니어링 작업에 대해 이미 꽤 상세한 조사와 구현 사양서가 있다고 치자. 이제 에이전트를 써서 이 사양서를 실제 돌아가는 코드로 바꾸고 싶은 상황이야.
내가 지금 고민하는 건 단순히 토큰당 비용이 아니라, 신뢰할 만한 결과물을 뽑아내는 데 드는 총비용 측면에서 가장 효율적인 접근 방식이 뭐냐는 거야.
대충 몇 가지 방법이 있는 것 같아.
1. 강력한 모델 하나한테 구현 전체를 맡기기
예를 들어, Opus 5.5에 1M 컨텍스트 윈도우를 주고, 구현 사양서랑 코드베이스 접근 권한까지 다 던져준 다음, 별다른 오케스트레이션 없이 알아서 작업하게 두는 거지.
작업 규모가 크면 결국 컨텍스트가 꽉 차서 압축되거나 요약될 텐데, 모델은 그 상태로 계속 작업을 이어가겠지.
근데 이게 최종 퀄리티에 얼마나 영향을 줄지가 의문이야. 모델이 어찌어찌 구현을 잘 해낼 수도 있겠지만, 나중에 디버깅이나 후속 수정 작업이 더 많이 필요할 수도 있잖아.
2. 명시적인 빌드 → 검증 → 수정 오케스트레이션 루프 사용하기
다른 방법은 구현 사양서를 단계별로 쪼개서 서브 에이전트를 활용하는 거야.
예를 들면 이런 식이지:
-
오케스트레이터가 사양서의 다음 섹션을 선택함.
-
구현 에이전트가 해당 부분을 빌드함.
-
검증 에이전트가 사양서나 테스트 케이스에 맞춰 구현 내용을 확인함.
-
실패하면 다시 수정하라고 보냄.
-
해당 섹션이 통과되어야만 다음 단계로 넘어감.
직관적으로 생각하면 대규모 작업에서는 이 방식이 훨씬 안정적일 것 같아. 오케스트레이션이랑 검증에 토큰을 의도적으로 쓰니까 초기 비용은 더 들겠지만, 나중에 골치 아픈 뒷수습이나 재작업 비용을 아낄 수 있으니까 전체적으로는 더 싸게 먹히지 않을까 싶거든.
여기서 또 다른 변수가 있어. 어떤 모델한테 어떤 일을 시킬 거냐는 거지.
예를 들면:
-
구현이랑 검증 둘 다 Opus 5.5로 돌리기.
-
오케스트레이터/검증은 Opus 5.5가 하고, 구현은 Sonnet 5.5나 Haiku 4.5가 하기.
-
검증은 Grok 4.6/4.7 같은 싼 모델이 하고, 구현은 Composer 2.5가 하기.
-
작업 단계에 따라 조합을 다르게 가져가기.
내가 지금 머리 아픈 건 토큰당 비용만으로는 이 질문에 대한 답이 안 나온다는 거야.
모델마다 토큰을 쓰는 양이 천차만별이고, 필요한 반복 횟수도 다를 수 있거든.
예를 들어, Grok 4.7 + Composer 조합이 Opus 5.5가 한두 번 만에 끝낼 퀄리티를 뽑아내려고 빌드/검증 사이클을 세 번씩 돌려야 한다면, 싼 모델을 쓴다고 해서 꼭 비용이 절감되는 건 아닐 수도 있잖아.
동시에, 나도 직접 해보니까 반복 횟수만 충분히 주면 위에 언급한 방식들 전부 다 결국엔 돌아가는 코드를 만들어내긴 하더라고.
사양서를 만족하고 검증/테스트를 통과하는 구현물을 얻기까지 드는 총비용.
이상적으로는 이런 것들을 비교해보고 싶어:
-
총 토큰/API 비용
