오케스트레이션 프롬프트에 '모델은 알아서' 넣었다가 토큰이 터진 이유

에이전트 여러 개를 병렬로 돌리는 워크플로우를 만들다 보면, 프롬프트에 이런 문장을 넣고 싶어져요. "작업 난이도에 맞는 모델은 알아서 선택해." 유연해 보이는 한 줄인데, 저는 이것 때문에 토큰 사용량이 터지는 걸 직접 겪었어요.

'알아서 선택'이 실제로 고르는 것

라이프케어로그의 플랜 시리즈를 혼자 만들다 보니, 리서치나 초안 정리 같은 반복 작업은 에이전트 6개를 병렬로 띄워 처리해요. 처음엔 오케스트레이터 프롬프트에 모델 선택을 통째로 위임했어요.

직접 돌려 보니 결과가 한쪽으로 쏠렸어요. 단순 분류든 짧은 요약이든, 거의 모든 에이전트가 제일 비싼 모델을 골랐어요. 로그를 확인해 보니 예외가 없다시피 했어요.

왜 전부 비싼 모델로 수렴할까

모델 입장에서 '알아서'라는 지시엔 실패하지 말라는 신호만 있어요. 비용을 아끼라는 제약은 어디에도 없죠. 그러면 가장 안전한 선택은 언제나 최고 성능 모델이 돼요.

문제는 이 선택이 곱셈으로 커진다는 점이에요. 토큰 단가가 5배 차이 나는 두 모델이 있을 때, 에이전트 6개가 전부 비싼 쪽으로 돌면 그 구간 비용도 그대로 5배가 돼요. 품질이 5배 좋아지는 것도 아닌데요.

모델 선택 위임→전부 최고가 모델로 수렴→병렬 개수만큼 비용 곱셈

고친 방법: 단계마다 한 줄씩 못 박기

해결은 허무할 만큼 간단했어요. 워크플로우 단계마다 쓸 모델을 명시하는 거예요.

• 수집·분류·추출처럼 기계적인 단계: 저가 모델 고정
• 판단·검증·최종 정리 단계: 고가 모델 허용

3단계 워크플로우면 지정할 곳도 3곳뿐이에요. 모델 이름을 적는 건 단계당 한 줄이면 끝나요. 적용해 봤더니 결과물 품질은 체감 차이가 없었고, 비싼 모델이 도는 구간만 확 줄었어요.

• ✓기계적 단계=저가 모델 고정
• ✓판단 단계만 고가 모델
• ✓위임 대신 단계별 명시

위임과 방임은 달라요

같은 실수를 피하려면 기준 하나만 기억하면 돼요. 결과 품질이 갈리는 판단 구간에만 비싼 모델을 쓰고, 나머지는 기본값을 싸게 잡는 거예요. 새 단계를 추가할 때 모델 칸을 비워 두지 않는 습관까지 들이면, 테스트해 보면 비용 그래프가 훨씬 예측 가능해져요.

'알아서'는 자율처럼 보이지만, 제약 없는 위임은 방임이에요. 위임할수록 제약은 더 명시적으로 적어 두세요.