서론

AI 오케스트레이션 툴인 TAKT에서는 워크플로우의 스텝마다 사용하는 모델을 provider_routing.tags로 전환할 수 있습니다. 이 기사에서는 구현(coding 태그)과 리뷰(review 태그)에 할당하는 모델의 강도를 변경했을 때, 토큰 소비량·수렴 속도·실제 비용이 어떻게 변하는지 검증했습니다.

비교를 위해 모델의 제품 라인업 이름으로 강약을 결정하는 것이 아니라, 벤치마크 스코어(Benchmark Score)를 기반으로 고/중/저의 3단계 수준을 다시 정의했습니다(상세 내용은 후술). 대상은 중난이도의 issue(수평 전개 누락·공통화 품질·회귀 방지가 요구되는 WebSocket의 에러 매핑 중복 해소)로, "중간 기준을 고정하고 구현 또는 리뷰 중 하나만 높거나 낮게 변경하는" 5가지 구성을 각각 3회씩 실행하여 비교했습니다.

대상 독자:

• TAKT 또는 유사한 멀티 스텝 AI 워크플로우 툴을 사용하고 있는 분
• 구현/리뷰에 어떤 모델을 할당할지 고민 중인 분
• "강한 모델을 사용하면 수렴이 빨라지고 비용도 낮아질 것이다"라는 가설을 검증하고 싶은 분

이 기사에서 알 수 있는 것

• 모델 강도를 구현/리뷰 중 어느 축으로 움직여도, 대부분의 경우 비용은 악화된다는 것
• 악화되는 정도는 움직이는 축(구현인가 리뷰인가)과 방향(강하게 할 것인가 약하게 할 것인가)에 따라 크게 비대칭적이라는 것
• 저렴한 모델은 구현보다 리뷰에 할당하는 것이 비용 효율이 높을 가능성이 있다는 것

1. 실험 설계

1.1 모델 수준의 정의 방법

수준 선정은 비용 효율성으로 필터링 (Artificial Analysis Intelligence Index 기반)

모델 수준 선정에는 제3자 벤치마크 기관인 Artificial Analysis가 공개한 Artificial Analysis Intelligence Index (Intelligence vs. Cost per Intelligence Index Task) 그래프를 기준으로 사용했습니다. GPT-5.6의 Sol/Terra/Luna 3개 계열 각각에 대해, reasoning_effort (low/medium/high/xhigh/max)별 Intelligence Index 스코어와 Task 단가가 플롯되어 있습니다.

선정 규칙은 "같은 스코어 대역에서 더 저렴한 후보를 우선하고, 비효율적인 점을 제외한다"는 비용 효율성(Pareto Frontier) 기준입니다. 그래프상의 Intelligence Index 스코어 대역별로 다음과 같이 압축했습니다.

• 55~60 대역: 이 대역에는 Terra/Luna의 점이 존재하지 않으므로, Sol 계열 내에서 가장 저렴한 점인 **Sol(high)**을 선택
• 50~55 대역: 후보는 Sol(medium)·Terra(xhigh)·Terra(max)·Luna(max). 동일 비용에서 스코어가 높은 쪽, 동일 스코어에서 비용이 낮은 쪽을 남기는 방식으로 Terra 계열을 제외하고 일단 **Luna(max)**를 선정 (후술할 이유로 인해 **Sol(medium)**로 변경)
• 45~50 대역: Terra(high)와 Luna(xhigh)가 후보. Luna(xhigh)가 거의 동일한 스코어이면서 더 저렴하기 때문에 Terra(high)를 제외하고 **Luna(xhigh)**를 선정

그 결과, 다음과 같은 3가지 수준을 정의했습니다.

• 고: Sol(reasoning_effort: high)
• 중: Sol(reasoning_effort: medium)
• 저: Luna(reasoning_effort: xhigh)

대상 외 태그(plan / supervise / merge-readiness / final-gate)도 비교 대상에서 제외하는 스텝으로서 중간 기준(Sol medium)으로 통일했습니다.

참고로 50~55 대역 선정 시 당초 "중간 = Luna(reasoning_effort: max)"를 상정했으나, TAKT의 codex 프로바이더용 reasoning_effort 값의 범위는 minimal / low / medium / high / xhigh의 5단계뿐이며 max는 존재하지 않아 ( max는 Claude 계열 effort의 값 범위에만 존재) 설정 시 에러가 발생했기 때문에 "중간 = Sol(medium)"로 변경했습니다.

1.2 검증 환경

• provider: codex (codex-cli 0.144.1~0.144.3, 실험 기간 중 업데이트 있음)
• workflow:
  default

(plan → write_tests → draft(implement + self-review) → peer-review(specialized reviewer + merge-readiness + supervise)) - 대상 issue: WebSocket의 text/audio 프레임의 에러 매핑 중복 해소 (난이도: 중, 평가 관점: 수평 전개 누락, 공통화 품질, 회귀 방지)

1.3 비교 대상 구성

중간 기준(구성 A)을 고정하고, 구현 또는 리뷰 중 한 쪽만 높거나 낮게 변경한 5가지 구성으로 검증했습니다.

각 구성을 3회씩 실행하여, iterations, total_tokens, 추산 비용을 기록했습니다.

2. 실측 결과

2.1 전 5개 구성 종합 비교

비용 순위: A($21.20) < D($22.06) < C($30.70) ≒ B($31.05) < E($38.36)

결과는 명확합니다. 중간 기준(A)이 가장 비용 효율이 좋았으며, 구현 또는 리뷰 축 중 어느 방향으로 움직여도 비용은 악화되었습니다. "강한 모델을 사용하면 수렴이 빨라져 비용이 낮아질 것이다"라는 가설은 지지되지 않았으며, 오히려 "모델을 구동하는 행위 자체가 비용 증가로 이어진다"는 결과가 나왔습니다. 다만, 악화되는 정도에는 명확한 비대칭성이 존재합니다.

2.2 구현 측을 변경하면 크게 악화됨 (구성 B·C)

구성 B(구현을 Luna xhigh로 낮춤)는 iterations 평균이 A와 거의 비슷한 수준(14.3 vs 13.7)이었으나, total_tokens와 비용은 A의 약 2.4배로 증가했습니다. 원인은 Luna(xhigh)가 Sol(medium)보다 구현 단계에서 더 많은 토큰을 소비하기 때문입니다(implement의 phase2_report가 구성 B에서 500만~546만 토큰으로, 구성 A의 구현 단계 전체를 상회하는 규모였습니다). 단가가 낮은 모델이라도 reasoning_effort를 높이면 반드시 비용 절감으로 이어지지는 않는다는 것을 보여주는 결과입니다.

구성 C(구현을 Sol high로 강화)는 iterations 평균이 3개 구성 중 가장 작았지만(13.0), 비용은 B와 거의 비슷한 수준($30.70)까지 상승했습니다. 구현 모델의 reasoning_effort를 높이면 1회당 토큰 단가 및 소비량 자체가 늘어나기 때문에, "이테레이션이 줄어들면 수렴이 빠르다"가 "비용은 반드시 낮아지지는 않는다"라는 결과로 이어집니다.

약화시키든(Luna xhigh) 강화하든(Sol high), 구현 단계를 중간 기준에서 변경하면 비용은 A의 약 1.45~1.47배로 악화된다는 점에서 B와 C는 공통점이 있었습니다.

2.3 리뷰 측은 약화시켜도 거의 악화되지 않음 (구성 D)

구성 D(리뷰를 Luna xhigh로 낮춤)는 total_tokens 평균이 5개 구성 중 가장 컸음에도 불구하고(약 3,900만), 추산 비용은 중간 기준(A) 다음으로 두 번째로 저렴한 결과($22.06, A보다 불과 +4%)를 보였습니다.

Luna의 단가가 Sol의 1/5 정도(input $1 vs $5, output $6 vs $30)이기 때문에, 리뷰 측에서 Luna의 토큰 소비가 늘어나더라도 총비용에 미치는 영향이 작습니다. 이는 동일한 Luna(xhigh) 설정을 구현 측에 사용했던 구성 B에서 비용이 2.4배로 악화된 것과 대조적입니다.

즉, 동일한 모델과 동일한 reasoning_effort를 사용하더라도, 구현(implementation) 단계와 리뷰(review) 단계 중 어디에 할당하느냐에 따라 비용에 미치는 영향이 크게 달라집니다. 저렴한 모델은 대량의 편집을 동반하는 구현 단계보다, 읽고 판단만 하는 리뷰 단계에 할당하는 것이 비용 효율적일 가능성이 높음을 시사합니다.

2.4 리뷰 측을 강화할 때 가장 악화함 (구성 E)

구성 E(리뷰를 Sol high로 강화)는 5가지 구성 중 가장 비용이 높게 나타난 결과($38.36, A의 약 1.81배)였습니다. total_tokens 평균 자체는 5가지 구성 중 3번째(B·D보다 적음)임에도 불구하고, Sol(high)의 단가 높이가 비용 상승으로 직결되었습니다.

리뷰 관련 4단계(arch-review / ai-antipattern-review-1st / ai-antipattern-review-2nd / coding-review) 모두에 고단가 모델을 적용한 영향이 가장 뚜렷하게 나타난 결과입니다.

2.5 악화 폭의 비대칭성

5가지 구성을 전체적으로 살펴보면, 비용 악화 정도는 다음과 같은 비대칭적인 서열을 보였습니다.

• 리뷰를 약화시킴 (D): +4% (거의 악화 없음)
• 구현을 약화시킴 (B) · 강화함 (C): +45~47% (중간 정도의 악화)
• 리뷰를 강화함 (E): +81% (최대 악화)

'움직이는 축'과 '움직이는 방향'의 조합에 따라 비용으로 되돌아오는 방식이 완전히 다르다는 것을 알 수 있습니다.

3. 고찰

3.1 "모델을 조정하면 최적화할 수 있다"는 성립하지 않음

"고성능 모델을 사용하면 수렴이 빨라져 비용도 낮아질 것이다"라는 직관적인 가설에 대해, 모델 차이는 명확히 관측되었으나 그 효과는 "조정하면 할수록 악화한다"는, 당초 가설과는 반대되는 방향이었습니다.

"고성능 모델을 사용하면 한 번에 올바르게 구현되어 수렴이 빨라지고, 결과적으로 비용이 낮아질 것"이라는 직관은 구현 측을 강화한 구성 C에서 부분적으로 뒷받침되었습니다 (iterations는 최소). 하지만 고성능 모델 자체의 단가와 토큰 소비량의 증가가 그 효과를 상회하여, 비용 측면에서는 악화되는 결과로 이어졌습니다.

3.2 저렴한 모델은 리뷰에 집중하는 것이 합리적

구성 B와 D의 대비는 시사하는 바가 큽니다. 동일한 Luna(xhigh)라는 "약하고 저렴하지만, reasoning_effort를 높임으로써 소비 토큰량 자체는 늘어난" 모델이라도, 구현에 사용하느냐(B) 리뷰에 사용하느냐(D)에 따라 비용에 미치는 영향이 완전히 달랐습니다.

• 구현에 사용 (B): 대량의 편집 및 생성을 동반하기 때문에, 단가의 저렴함보다 토큰 소비량의 증가가 더 크게 작용하여 비용 +47%
• 리뷰에 사용 (D): 독해 및 판정이 중심이라 토큰 소비량은 증가하지만, 단가의 저렴함이 이를 상쇄하여 비용 +4%

리뷰 단계는 구현 단계만큼 출력 토큰을 대량으로 생성하지 않기 때문에 모델 단가의 영향을 강하게 받습니다. 비용을 억제하고 싶다면, 저렴한 모델은 구현이 아닌 리뷰에 할당하는 것이 합리적이라고 판단됩니다.

3.3 중간 기준을 함부로 변경하지 않는 것이 최적해 ── 단, 이번 issue의 범위 내에서는

이번 중난이도 issue에 관해서는 구현이나 리뷰 중 어느 축을 어느 방향으로 움직여도, 중간 기준(A)을 상회하는 비용 효율을 얻을 수 없었습니다. 저비용화를 노리고 저렴한 모델로 기울어도(B), 빠른 수렴을 노리고 고성능 모델로 기울어도(C, E), 모두 비용이 악화되었습니다.

유일하게 비용 악화가 경미했던 구성 D(리뷰를 약화시킴)도 A보다 나은 결과를 내지는 못했습니다. 이 결과로부터는 태스크의 난이도에 걸맞은 "중용"의 모델을 모든 단계에서 통일적으로 사용하는 것이, 부분적으로 모델을 조정하는 것보다 비용 효율이 좋다는, 다소 직관에 반하는 결론이 도출됩니다.

다만, 이 결론을 과도하게 일반화하는 것은 위험합니다. 이번 issue(수평 전개 누락 · 공통화 품질 · 회귀 방지가 요구되는 에러 매핑 중복 해소)는 변경 대상 파일 수나 작업량은 저난이도 issue보다 많지만, 요구되는 설계 판단이나 추론의 복잡성 자체는 그리 높지 않습니다. "양은 많지만 복잡도는 낮은" 중난이도 태스크이며, 이러한 태스크에서는 중간 단계 모델(Sol medium)로도 충분히 대응이 가능하여, 상위 모델(Sol high)의 추론 능력을 필요로 하는 국면이 애초에 적었을 가능성이 있습니다. 구성 C·E에서 비용이 악화된 것도 상위 모델의 실력이 발휘되기 전에 "오버스펙인 단가만 얹어진" 결과로 볼 수도 있습니다.

즉, 이번 실험만으로는 상위 모델의 추론 능력(reasoning capability)이 진정으로 발휘될 수 있는, 설계 판단이나 복잡한 의존 관계 파악이 필요한 고난이도 태스크에서도 동일한 결론이 성립하는지는 검증하지 못했습니다. 이 과제는 다음 issue로 넘깁니다.

3.4 평가 축 자체의 재고

이번 실험 결과를 바탕으로 하면, 모델 구성의 비교 설계 자체에도 재검토해야 할 점이 몇 가지 보였습니다.

벤치마크 스코어와 실제 태스크의 상관관계는 보장되지 않는다

구성 B(구현=Luna xhigh)는 Artificial Analysis Intelligence Index 그래프상에서 비용 효율이 좋은 지점으로 선정했던 모델이었습니다. 하지만 실제로는 구현 단계에 사용했을 때 비용이 A의 2.4배로 악화되었습니다. 벤치마크상의 가성비(Cost-performance)는 어디까지나 일반적인 태스크에서의 지표이며, TAKT의 워크플로우라는 특정 실제 태스크(멀티 턴의 구현·리뷰 왕복을 포함)에서의 비용 효율과 일치한다고 단정할 수 없습니다. 벤치마크 스코어는 '후보를 좁히기 위한 참고치'로 남겨두고, 최종적인 채택 여부는 실제 태스크에서의 실측에 맡겨야 합니다.

동일 모델 내에서의 reasoning_effort 차이 비교가 필요하다

이번 3단계(고=Sol high, 중=Sol medium, 저=Luna xhigh)는 모델과 reasoning_effort가 동시에 변화하고 있습니다. 따라서 '비용이 악화된 것이 모델의 차이 때문인지, 아니면 reasoning_effort의 차이 때문인지'를 이번 설계로는 분리할 수 없습니다. 특히 구성 B에서는 Luna라는 저렴한 모델임에도 reasoning_effort를 xhigh까지 높임으로써 토큰 소비량 자체가 증가했음이 확인되었으며, 이 요인이 어디까지 기여했는지 확인하기 위해서는 동일 모델 내에서 reasoning_effort만을 변경한 비교가 별도로 필요합니다.

고단가 모델의 투자 대비 효과(ROI)는 태스크의 복잡도와 분리하여 측정할 수 없다

3.3절에서 언급한 태스크 특성의 한계는, 평가 설계 측면에서 보면 '고단가 모델이 가치를 발휘할 조건을 선택하지 못했다'는 문제로 바꿔 말할 수 있습니다. 고단가 모델(Sol high)의 비용 대비 효과를 올바르게 측정하려면, 단계 설정 방식(1.1절)이나 평가 축의 분리(reasoning_effort 차이)뿐만 아니라, 대상 태스크 자체를 고난이도 쪽으로 설정하는 것도 비교 설계의 일부로 포함해야 합니다.

4. 요약

• 벤치마크 스코어 기반으로 고/중/저 3단계(Sol high / Sol medium / Luna xhigh)를 정의하고, 중난이도 issue에서 5가지 구성을 비교한 결과,
  • 중간 기준(A)이 가장 비용 효율이 좋았으며, 구현·리뷰 어느 축을 움직여도 비용은 악화되었다 (단, 이 중난이도 issue 범위 내에서의 결과)
  • 악화 폭은 비대칭적이며, '리뷰를 약화함'은 거의 변화가 없었으나(+4%), '구현을 약화/강화함'은 중간 정도(+45~47%), '리뷰를 강화함'은 최대(+81%)로 나타남
• 동일한 저가형 모델(Luna xhigh)이라도 구현에 사용하느냐 리뷰에 사용하느냐에 따라 비용에 미치는 영향이 완전히 다르며, 리뷰에 할당하는 것이 비용 효율이 더 좋음
• '고성능 모델로 수렴 속도를 높여 비용을 절감한다'는 가설은, 수렴 속도(iterations 감소) 자체는 일부 뒷받침되었으나, 모델 단가 증가가 이를 상회하여 비용 측면에서는 부정됨
• 다만 이번 issue는 '작업량은 있지만 요구되는 복잡도는 높지 않은' 태스크였으므로, 상위 모델의 추론 능력이 정말로 효과를 발휘하는 고난이도 태스크에서도 같은 경향이 나타날지는 이번 실험만으로 판단할 수 없음
• 평가 설계에도 개선 여지가 있음. 벤치마크 스코어와 실제 태스크의 비용 효율은 일치하지 않을 수 있으며, 모델과 reasoning_effort를 동시에 변화시킨 이번 설계에서는 양자의 영향을 분리하지 못함. 고단가 모델의 가치는 복잡도와 설계 판단을 요하는 태스크에서 측정해야 함

저난이도 issue에서는 관측되지 않았던 모델 차이가 중난이도 issue에서는 명확하게, 심지어 직관에 반하는 방향으로 관측되었습니다. 토큰 수뿐만 아니라 모델 단가까지 포함한 개략적인 비용으로 비교하지 않으면 최적의 모델 구성을 판단하는 데 오류를 범할 가능성이 있습니다. 한편, 상위 모델의 진가가 발휘되는 복잡한 태스크에서의 검증과 평가 축 자체의 분리(모델 차이 vs reasoning_effort 차이)는 향후 과제입니다.

참고 링크

Discussion