서론

지난 기사에서는 AI 오케스트레이션 도구인 TAKT에서 구현(coding 태그) 및 리뷰(review 태그)에 할당하는 모델의 강도를 변경했을 때, 중난이도 issue에서는 거의 예외 없이 비용이 악화된다는 결과를 얻었습니다. 악화 폭에는 비대칭성이 있어, '리뷰를 약화시키는' 방향만 거의 변화가 없었으며(+4%), 그 외(구현을 강화/약화, 리뷰를 강화)는 +45~81%의 악화가 발생했습니다.

하지만 지난 기사에서는 이 결론에 대해 다음과 같은 한계를 언급했습니다.

상위 모델의 추론 능력이 진정으로 효과를 발휘하는, 설계 판단이나 복잡한 의존 관계 파악이 필요한 고난이도 태스크에서도 동일한 결론이 성립하는지는 검증하지 못했습니다.

이번에는 이 과제를 이어받아, SQLite 대화 턴 영속화 기반 구현(transaction 원자성·병행성, privacy 책임 경계, stale 회수·보유 기간의 경계값 판정 포함, 명확하게 고난이도인 issue)을 대상으로 동일한 비교 축에서 재검증을 실시했습니다.

대상 독자:

• 지난 기사를 읽고 "난이도가 높아지면 어떻게 될까"가 궁금한 분
• TAKT 또는 유사한 멀티 스텝 AI 워크플로우 도구에서 고난이도 태스크를 다루고 있는 분
• 비용 최적화뿐만 아니라, 수렴의 안정성(프로세스가 자가 파괴되지 않는지)에도 관심이 있는 분

이 기사에서 알 수 있는 것

• 고난이도 태스크에서도 '리뷰를 약화시키는' 방향만이 중간 기준을 상회하는 비용 효율을 보인다는 점 (지난번 중난이도 issue보다 명확한 개선)
• '구현을 약화시키는' 방향의 악화가 중난이도 issue보다 심각해지며, 수렴율 자체도 저하된다는 점

1. 실험 설계

1.1 모델 수준의 정의 (지난번으로부터의 변경점)

기본적인 3단계 수준 정의는 지난 기사와 마찬가지로, Artificial Analysis Intelligence Index를 기반으로 선정한 다음을 따릅니다.

• 고: Sol(reasoning_effort: high)
• 중: Sol(reasoning_effort: medium)
• 저: Luna(reasoning_effort: xhigh) ※후술할 이유로 Sol(low)로 변경

이번에는 이 '저' 수준의 정의를 실험 도중에 변경했습니다. 저수준 구성(후술할 구성 B)을 실측한 결과, Luna는 벤치마크 스코어상 '저'에 위치하지만, 실제 비용 효율은 중간 기준을 크게 상회하여 악화됨을 확인했기 때문입니다. 이는 지난번 issue #25의 구성 B와 동일한 방향의 결과이며, '벤치마크 스코어의 고저와 비용 효율의 고저가 일치하지 않는다'는 점의 재현이라고 볼 수 있습니다.

따라서 구성 B는 'issue #23 한정의 예외 실시'로서 당초의 Luna(xhigh) 그대로 기록을 확정하였고, 이후의 저수준 비교는 동일 모델(Sol) 내에서 reasoning_effort만 낮춘 Sol(low) (구성 B2)로 변경했습니다. 이는 지난 기사의 고찰 3.4에서 언급한 '동일 모델 내에서의 reasoning_effort 차이 비교가 필요하다'는 과제에 대응하는 변경이기도 합니다.

1.2 검증 환경

• provider: codex (codex-cli, 실험 기간 중 여러 버전을 사용)
• workflow: default (plan → write_tests → draft(implement + 셀프 리뷰) → peer-review(전문 리뷰어 + merge-readiness + supervise)) - 대상 issue: #23 「SQLite 대화 턴 영속화 기반을 구현한다」 (난이도: 고, 평가 관점: transaction 원자성·병행성, 상태 전이의 정확성, privacy 책임 경계, 기동 시 라이프사이클, stale 회수·보유 기간의 경계값)

1.3 비교 대상 구성

지난번과 마찬가지로 중간 기준(구성 A)을 고정하고, 구현 또는 리뷰 중 한쪽만을 높음 또는 낮음으로 옮긴 구성으로 검증했습니다. 저수준 정의 변경에 따라 구현 측의 저수준 구성이 2종류(B·B2)가 되었습니다.

plan은 모든 구성에서 Sol(xhigh)로 고정(대상 외)입니다. 각 구성을 2~3회 실행하여, iterations

・total_tokens

・대략적인 비용을 기록했습니다.

2. 실측 결과

2.1 전 구성 종합 비교

지난번 중난이도 issue와 구도는 매우 유사하지만, 결정적으로 다른 점이 2가지 있습니다. "리뷰를 약화시킨다" (D)가 중기준을 명확히 하회했다는 것, 그리고 "구현을 약화시킨다" (B·B2)의 악화 폭이 확대되어 수렴률 자체도 떨어졌다는 것입니다. 이후 각각 자세히 살펴보겠습니다.

2.2 「리뷰를 약화시킨다」가 명확한 개선으로 전환 (구성 D)

지난번 중난이도 issue에서는 리뷰를 약화시킨 구성(Luna xhigh)이 A와 거의 비슷한 수준(+4%)에 머물렀으며, A를 하회하지는 않았습니다. 이번 고난이도 issue에서는 리뷰를 Sol(low)로 약화시킨 구성 D가 $100.15로, A보다 약 19% 낮게 나타나며 명확한 개선을 보여주었습니다. 실행 시간 또한 98.1분으로 A 평균(136.3분)을 크게 밑돌았습니다.

지난번(issue #25, 중난이도): 리뷰를 약화시킨다(D) → A와 거의 비슷한 수준(+4%)
이번(issue #23, 고난이도): 리뷰를 약화시킨다(D) → A를 명확히 하회(-19%)

고난이도 태스크에서는 리뷰 라운드 자체의 절대량이 많아(2.5절 후술), 리뷰 모델의 단가를 낮춤으로써 얻는 절감 효과가 더 크게 작용했다고 판단됩니다. 중기준에서는 "리뷰를 약화시켜도 거의 영향이 없었"으나, 태스크가 무거워질수록 "리뷰를 약화시키는 것"의 투자 대비 효과가 올라간다는 관계가 확인되었습니다.

2.3 「구현을 약화시킨다」의 악화가 더욱 심각해짐 (구성 B·B2)

구현을 약화시키는 방향은 저수준(low)의 정의(구 Luna xhigh · 신 Sol low)와 관계없이 지난번보다 악화 폭이 확대되었습니다.

• 구성 B (Luna xhigh, 참고값): $213.91, A의 1.73배
• 구성 B2 (Sol low, 신규 정의): $229.00, A의 1.85배

지난 issue #25의 구성 B(구현=Luna xhigh)는 A의 약 1.47배 악화였으나, 이번에는 동일한 Luna xhigh임에도 1.73배까지 악화되었습니다. 나아가 정의를 변경한 B2(Sol low)에서는 악화 폭이 1.85배까지 넓어졌습니다.

비용 이상으로 주목해야 할 점은 수렴률의 저하입니다. 구성 B는 2회 시도 중 1회 시도가 30 iteration 상한에 도달하여 미수렴하였고, 구성 B2는 3회 시도 중 2회 시도가 수렴하지 못했습니다 (1회차는 resume 후 프로세스 자가 파괴, 2회차는 iteration 상한). 중난이도 issue에서는 관찰되지 않았던 "구현 효율을 낮추면 코드 품질뿐만 아니라 태스크 수행 프로세스 준수 자체도 무너진다"는 불안정화가 고난이도 issue에서 현재화된 것으로 보입니다.

2.4 구현을 강화·리뷰를 강화는 중간 정도의 악화로 지난번과 동일한 경향

• 구성 C (구현=Sol high): $152.45, A의 1.23배
• 구성 E (리뷰=Sol high): $149.85, A의 1.21배

이 두 가지는 지난번 중난이도 issue와 마찬가지로 중간 정도의 악화(+21~23%)에 그쳤습니다. 3회 시도 모두 안정적으로 completed까지 도달하였으며, 프로세스 이상도 관찰되지 않았습니다. "모델을 강화하는" 방향은 약화시키는 방향에 비해 비용 측면과 프로세스 안정성 측면 모두에서 예측 가능성이 높다는 경향은 난이도가 바뀌어도 일관된 것으로 보입니다.

2.5 고난이도화로 현재화된 2가지 부차적인 문제

비용 비교와는 별개로, 이번 issue #23에서는 지난번 issue #25에서는 볼 수 없었던 두 가지 현상이 관찰되었습니다.

리뷰 라운드 수가 압도적으로 많음

issue #25의 각 구성은 reviewers ⇄ fix가 최대 3회 정도였으나, issue #23의 구성 A(1회차)에서는 8라운드가 소요되었습니다. 지적 내용 또한 포맷 붕괴나 명명(naming) 수준이 아니라, transaction 병행성(transaction concurrency) 문제였습니다 (BEGIN만으로 쓰기 transaction 시작 → 동시 실행으로 sqlite3.OperationalError: database is locked 발생)

가 누수되는 상황)이나 기동 시 라이프사이클(ThreadPoolExecutor 생성 실패 시의 리소스 잔류)과 같은, 실질적인 설계 결함에 다가간 지적이었습니다. 고난이도 issue에서는 리뷰가 "찾아서 고쳐야" 할 문제의 절대량 자체가 많으며, 이것이 2.2절에서 살펴본 "리뷰를 약화시켜도 악화하지 않거나 오히려 개선되는" 원인 중 하나일 가능성이 있습니다 (리뷰 모델을 강화하더라도, 양이 너무 많아서 질적인 개선 효과가 단가 증가에 미치지 못한다는 관점도 가능합니다).

3. 고찰

3.1 "모델을 구동하면 비용은 악화된다"는 대강의 틀은 고난이도에서도 성립, 단 비대칭성은 확대

지난번 issue #25에서 얻은 "중간 기준을 구동하면 대체로 악화하지만, 악화 폭에는 비대칭성이 있다"는 대강의 결론은, 고난이도 issue #23에서도 성립했습니다. 다만, 그 비대칭성의 내용은 난이도에 따라 변화하고 있습니다.

"리뷰를 약화함"은 난이도가 높아질수록 유리해지고, "구현을 약화함"은 난이도가 높아질수록 불리해진다는 난이도 의존적 비대칭성이 이번에 새롭게 드러났습니다. 반면 "강화함" 방향(구현·리뷰 모두)은 지난번만큼 악화 폭이 크지 않고 오히려 축소되었습니다. 이는 3.2절에서 서술할 수렴률·안정성 문제와 함께 해석할 필요가 있습니다.

3.2 비용뿐만 아니라 "수렴할 수 있는가"를 볼 필요가 있음

지난번 issue #25에서는 모든 구성이 안정적으로 수렴하고 있어 비용(cost)·iterations·total_tokens 비교만으로 충분했습니다. 하지만 고난이도 issue #23에서는 구현을 약화시킨 구성(B·B2)에서 수렴률 자체가 크게 저하되었습니다 (B: 2회 시도 중 1회, B2: 3회 시도 중 1회만 정식 수렴).

이는 "비용이 높은가 낮은가" 이전에, "애초에 태스크가 완료되는가"라는 더 근본적인 문제입니다. 고난이도 태스크에서 구현 모델을 약화시키는 것은 단순히 비용 효율이 나쁠 뿐만 아니라, 수렴 보장 자체를 해칠 위험이 있다고 할 수 있습니다. 역으로 말하면, B·B2에서 산출한 비용 평균(n=1)은 "우연히 수렴한 1회"의 값이며, 기대 비용(expected cost) 측면에서는 과소평가되었을 가능성이 있습니다 (미수렴 시도를 포함하면 실질적인 기대 비용은 더욱 악화됩니다).

3.3 난이도에 따라 튜닝 방침을 바꿀 여지가 있음

지난번 issue #25의 결론은 "중용(中庸)한 모델을 모든 단계에서 통일적으로 사용하는 것이 비용 효율이 좋다"는 것이었습니다. 이번 결과가 이 결론을 완전히 뒤집는 것은 아니지만, 태스크의 난이도에 따라 "구동했을 때 이득을 보는 축"이 달라진다는 것을 보여줍니다.

• 중난이도 태스크: 중간 기준이 최적. 구동하면 기본적으로 손해 (유일하게 "리뷰를 약화함"이 거의 변화 없음)
• 고난이도 태스크: 중간 기준은 여전히 나쁘지 않은 기준점이지만, "리뷰를 약화함"에 한해서는 명확하게 이득

이는 실무적으로 "난이도가 높은 태스크일수록 리뷰 비용을 줄여서 아낀 부분을 다른 용도(시도 횟수를 늘리거나, 다른 issue에 할당하는 등)로 돌릴 여지가 있다"는 시사점을 줍니다. 다만 2.5절에서 언급한 리뷰 라운드 수의 많음이라는 유보 사항이 있으므로, 단순히 "고난이도라면 리뷰를 약하게 해도 좋다"라고 결론짓는 것은 시기상조입니다.

3.4 실험 설계의 한계

• 각 구성의 n수는 2~3으로 적으며, 특히 B·B2는 수렴 샘플이 n=1이므로 통계적 신뢰성이 낮습니다.
• 프로세스 이상(resume 시 plan 재실행) 발생률(B2: 2/3)도 소수 시도에 기반한 참고치이며, 모수를 늘리지 않는 한 일반화할 수 없습니다.
• 저수준(low level)의 정의가 B(Luna xhigh)와 B2(Sol low)로 뒤바뀌어 있어, 구현 약화에 따른 악화 폭의 수치(1.73배 vs 1.85배)는 완전히 동일한 조건에서의 비교가 아닙니다.
• 대상 issue는 1건뿐이므로, "고난이도 issue 전반"으로 일반화하기 위해서는 더 많은 고난이도 issue를 통한 재검증이 필요합니다.

4. 요약

• 고난이도 issue #23에서 재시험한 결과, 지난번 issue #25의 "중간 기준을 움직이면 전반적으로 악화한다"라는 큰 틀의 결론은 유지되었으나, 비대칭성의 내용이 난이도에 따라 변화한다는 사실이 밝혀졌습니다. - "리뷰를 약화시키는" 방향은 중난이도 issue에서는 변화가 없었으나(+4%), 고난이도 issue에서는 **A를 명확히 밑도는 개선(-19%)**을 보였습니다.
• "구현을 약화시키는" 방향은 중난이도 issue에서도 악화되었으나, 고난이도 issue에서는 악화 폭이 확대되고(+73~85%), 수렴률 자체도 저하되는 등 비용 이전에 근본적인 문제가 드러났습니다. - 고난이도 issue에서는 모델이나 effort 수준과는 독립적으로, resume 시 plan을 재실행함으로써 프로세스가 붕괴되는 워크플로우 측면의 취약성도 관측되었습니다. - 난이도에 따라 "움직였을 때 이득을 보는 축"이 달라질 가능성이 있으며, 태스크의 난이도를 고려한 모델 구성 튜닝(tuning)에는 어느 정도 여지가 있어 보입니다. 다만 각 구성의 n수는 적으므로, 더 많은 고난이도 issue를 통한 재시험이 향후 과제입니다.

지난번과 이번을 통틀어, "모델 구성을 움직이면 최적화할 수 있다"라는 단순한 가설은 지지되지 않았으나, "중용을 유지하는 것이 항상 정답이다"라는 결론 또한 태스크의 난이도에 따라 무너질 수 있음이 보였습니다. 다음 과제는 프로세스 이상(resume 시의 붕괴) 자체의 수정이나, 더 많은 고난이도 issue를 통한 재시험입니다.

참고 링크

Discussion