Claude Code의 dynamic workflows, 이른바 ultracode는 일반적인 세션보다 훨씬 더 많은 토큰을 소비합니다. 이 기사는 가상의 주제로 5단계 파이프라인을 반복 실행하며, 토큰 비용, 실제 시간, 품질을 실측하여 어디를 변경하면 얼마나 저렴해지는지를 하나씩 분리해낸 기록입니다. 최종적으로 권장하는 구성과, 효과가 있을 것이라 생각하여 제외했던 대책까지 기술합니다.

TL;DR

• 효과가 큰 순서대로 3가지 레버(Lever)가 있습니다.
  단가를 낮추기(공정마다 모델의 가격대를 변경), 수를 줄이기(채점을 1개로 통합), 캐시를 데우기(동일한 문맥을 시간적으로 가깝게 반복). 이 3가지를 중첩한 가장 저렴한 구성에서는 비용이 Opus 환산 시 약 68%, 실측 청구 금액 기준 약 74% 감소했으며, 실제 시간도 약 46% 단축되었습니다. 품질을 유지하는 권장 구성에서는 절감 폭이 이보다 약간 작아집니다. 발명 역할과 채점 역할의 모델 선택이 품질과 비용의 분수령이었습니다.
  발명과 채점에는 Sonnet을 기본으로 권장합니다. Sonnet은 명확하지 않은 중복도 Opus 수준으로 찾아내며, 착상의 품질도 Opus와 대등하고, 3개 모델 중 가장 안정적이며, 단가는 Opus의 0.6배입니다. Haiku는 채점에 적합하지 않습니다. 명백한 중복은 걸러낼 수 있지만, 기존 기능의 조합에 불과한 비자명한(non-trivial) 중복은 지시를 해도 찾아내지 못했습니다. 측정에는 함정이 있습니다.
  totalTokens는 몇 번을 돌려도 변동 계수가 0.7% 미만으로 견고하지만, 실제 청구 금액은 캐시의 온도에 따라 2할 가까이 움직입니다. 또한 혼성 모델의 토큰 수는 새로운 토크나이저(Tokenizer)의 영향으로 작업량 비교에 사용할 수 없습니다. 횡단 비교는 주로 Opus 환산 토큰을 기준으로 합니다. "반복되는 문맥을 앞부분에 배치하여 공유 캐시를 활용한다"는 정석적인 테크닉은, 병렬로 동시에 실행되는 에이전트에게는 효과가 없습니다. 동시에 발화하기 때문에 각 개체가 자신의 문맥을 개별적으로 캐시 쓰기하기 때문입니다.

미리 말씀드리면, 측정한 것은 아이디어 도출 작업입니다. 비용을 낮추는 레버, 즉 모델의 구분 사용이나 배치(Batch)화, 캐시 데우기는 용도와 상관없이 효과적이지만, 어떤 공정에 어떤 모델을 배치할 수 있는가에 대한 품질 측면의 결론은 이 용도에 국한된 이야기입니다. 개발과 같이 코드를 작성하게 하는 작업에서는 저렴한 모델로 충분한 범위가 달라질 수 있습니다.

dynamic workflows와 ultracode

dynamic workflows는 2026년 5월 Claude Opus 4.8과 동시에 공개된 프리뷰 버전 기능입니다. 정식 버전이 아니며, 이용을 위해서는 대응 버전의 Claude Code와 유료 플랜이 필요합니다. 프롬프트에 workflow라는 단어를 넣거나, 세션에 /effort ultracode를 설정하면, Claude가 JavaScript 정리 스크립트를 즉석에서 작성하고, 분리된 런타임(Runtime)이 배경에서 다수의 에이전트를 병렬로 실행합니다.

파악해 두면 읽기 편한 특성들을 나열합니다.

• 본고 시점에서는 1회 실행으로 기동할 수 있는 것은 최대 1,000개, 동시에 실행되는 것은 최대 16개입니다. 이를 초과하는 분량은 슬롯이 비기를 기다렸다가 순차적으로 실행됩니다.
• 중간 결과는 스크립트의 변수에 유지되며, 최종 결과만 세션으로 돌아옵니다. 중간의 방대한 출력으로 인해 메인 문맥이 오염되는 것을 방지할 수 있습니다.
• /workflows를 통해 실행 상황을 페이즈(Phase)나 에이전트 단위까지 추적할 수 있으며, 일시 정지나 정지도 가능합니다. 정리 스크립트 안에서는 모든 것을 기다린 후 다음으로 진행하는 parallel()과, 각 안을 기다리지 않고 흘려보내는 pipeline()을 구분해서 사용합니다.

그리고 본론과 직결되는 특성이 하나 더 있습니다. 토큰 소비가 일반적인 세션보다 상당히 크게 부풀어 오른다는 점입니다. Anthropic도 공식적으로 일반적인 경우보다 훨씬 많은 토큰을 사용한다고 명시하고 있습니다. 따라서 스케일을 키우기 전에 어디에서 돈이 들고 있으며, 어디를 깎으면 효과적인지를 실측을 통해 파악해 두고 싶어집니다.

무엇을 "비용"이라 부를 것인가

수치를 제시하기 전에, 무엇을 측정하고 있는지 통일하겠습니다. 이번에는 3가지 계층으로 살펴보았습니다.

첫 번째는 totalTokens입니다. 각 실행의 저널 workflows/wf_<id>.json에 런타임이 집계하는 값으로, 이를 1차 지표로 삼습니다. 내용이 다른 주제로 몇 번을 돌려도 변동 계수는 0.7% 미만이었으며, 기준 구성에서는 ±0.27% 이내로 수렴하여 매우 재현성이 높은 값이었습니다.

여기에 한 가지 함정이 있습니다. 서브 에이전트(Sub-agent)의 생 로그(raw log)인 agent-*.jsonl 파일을 행 단위로 모두 더하면 토큰 수가 대폭 과다하게 계산됩니다. 동일한 메시지가 여러 행에 기록되어 중복 계산되고, 각 턴(turn)이 문맥(context) 전체를 포함하고 있어 턴을 넘겨가며 더할 경우 문맥을 반복해서 세게 되기 때문입니다. 따라서 숫자를 산출할 때는 저널(journal)의 totalTokens를 사용합니다.

두 번째는 유형별 과금 내역입니다. 각 에이전트의 로그를 message.id로 중복 제거한 뒤, 입력(Input), 캐시 쓰기(Cache Write), 캐시 읽기(Cache Read), 출력(Output)으로 나누어 공식 단가를 곱해 실제 청구 금액을 산출합니다. 단가는 다음과 같습니다.

여기서 주의할 점이 두 가지 있습니다. 첫 번째는 실제 청구 금액이 캐시의 온도(cache temperature)에 따라 격하게 변한다는 것입니다. 동일한 구성이라도 처음의 차가운(cold) 상태와, 직전에 동일한 문맥을 흘려보내 따뜻해진(warm) 상태에 따라 캐시 쓰기와 읽기의 내역이 뒤바뀝니다. 기준 구성의 실측액은 ±18% 정도 변동되었습니다. 두 번째는 Opus 4.7 이후 모델이 새로운 토크나이저(tokenizer)를 사용하고 있어, 동일한 텍스트라도 최대 35% 정도 토큰 수가 늘어난다는 점입니다. 즉, 모델을 혼합한 구성 간에 totalTokens를 비교하면 작업량의 차이와 토크나이저의 차이가 섞여 버립니다.

그래서 횡단 비교를 위해 세 번째 방법인 'Opus 환산 토큰'을 사용합니다. 입력 단가 비율이 Opus : Sonnet : Haiku = 5 : 3 : 1 이므로, 각 모델의 토큰에 1.0 / 0.6 / 0.2의 가중치를 곱하여 다시 합산한 값입니다. 이는 캐시의 온도나 토크나이저의 영향을 적게 받으므로, 구성 간의 비용을 안정적으로 비교할 수 있습니다.

마지막으로, 구조의 핵심이 되는 발견을 하나 공유하겠습니다. 에이전트 1개당 약 20~23k 토큰의 고정적인 바닥(floor)이 존재합니다. 단발성·단일 턴의 작은 채점 작업이라도 약 20k를 소비합니다. 그 내용은 서브 에이전트의 시스템 프롬프트(system prompt), 기본 도구군, 워크플로우의 기반, 구조화된 출력(structured output) 메커니즘입니다. 이 바닥이 존재하기 때문에, 토큰 수를 줄이는 최대 레버(lever)는 '에이전트 수를 줄이는 것'이며, 비용을 줄이는 최대 레버는 '에이전트당 단가'와 '캐시의 온도'가 됩니다. 이 바닥의 정체는 나중에 실측을 통해 확인하겠습니다.

참고로, 레이트 리밋(rate limit)에 도달하여 구조화된 출력이 중간에 끊긴 망가진 실행 건은 모두 버리고, 끝까지 완주한 24개의 클린한 데이터만을 사용했습니다.

실험 방법

주제는 가상의 관엽 식물 케어 리마인더 앱이며, 수행한 작업은 이 앱에 추가할 신기능 아이디어를 폭넓게 도출한 뒤 엄격하게 압축하는 것입니다. 자매 기사에서 게임 신규 기획안을 찾게 했던 것과 동일한 형식을 일회성 소재로 다시 진행했습니다. 이 작업을 선택한 이유는, 멀티 에이전트(multi-agent)가 정말로 적합한 형태가 바로 '넓게 발산하고 기계적으로 압축하는' 방식이기 때문입니다. 에이전트 1개로 충분한 작은 수정 작업에 멀티 에이전트를 쓰는 것은 과잉이며, 모집단을 넓히고 임계값으로 쳐내는 아이디어 도출과 같은 작업에서 비로소 가치가 나타납니다. 새로움이나 중복 탐지라는 명확한 품질 축이 있는 만큼, 저렴한 모델이 어느 지점에서 무너지는지도 측정하기 쉬운 소재였습니다.

이에 대해 조사·발명·선별·채점·설계의 5단계 파이프라인을 하나 구축하고, args 노브(knob)만 변경하며 변수를 하나씩 분리했습니다.

채점 단계에는 실제 워크로드에서의 '기존 기능 리스트' 역할을 대신하기 위해, 약 5k 토큰의 기능 카탈로그를 모든 채점자에게 전달했습니다. 품질을 측정하는 회차에 한해서는 후보와 설계 대상을 고정하고 모든 실행에 동일한 입력을 전달했으며, 모델만을 변경했습니다. 이는 생성의 변동성을 배제하고 모델의 차이만을 추출하기 위함입니다. Opus를 2회 실행하여 자기 변동성의 바닥을 만들고, Sonnet과 Haiku의 차이가 이를 초과하는지를 보고 판정합니다.

비용 절감 레시피

효과가 큰 순서대로 나열합니다.

단가 낮추기 — 공정별로 모델의 가격대 변경

가장 큰 비용 절감 요인은 공정별로 모델의 가격대를 변경하는 것이었습니다. 깊은 사고가 필요한 선별과 설계는 Opus에 남겨두고, 그 외의 넓고 얕은 공정은 저렴한 모델로 배치합니다. 입력 단가는 Opus를 1.0으로 보았을 때 Sonnet이 0.6, Haiku가 0.2입니다. 다만 발명과 채점은 모델에 따라 결과물의 질이 달라지므로, 어떤 모델에 배치할지는 다음 절에서 상세히 다룹니다.

실측 결과, 선별과 설계만 Opus에 남기고 조사·발명·채점을 모두 Haiku로 몰아넣은 가장 저렴한 구성에서, Opus 환산 시 약 61%, 실측 청구 금액 기준 약 65%의 비용이 절감되었습니다. 이는 단가를 최대한 낮춘 구성이며, 품질을 고려한 배분은 이후 절에서 설명하겠습니다. 토큰의 "수" 자체는 거의 변하지 않습니다. 낮아진 것은 단가입니다. 혼성 구성이므로 totalTokens는 토크나이저 (Tokenizer)의 영향을 받지만, Opus 환산으로 보면 솔직하게 비용이 하락한 것으로 해석할 수 있습니다.

그렇다면 이 모델 할당은 어디서 변경할까요? dynamic workflows에는 설정 화면이 없으며, 모든 것은 취합 스크립트 (Summary script) 내에서 결정됩니다. 각 에이전트 (Agent) 호출인 agent()에 model을 전달하는 방식으로, agent(prompt, { model: 'haiku' })와 같이 작성합니다. 스크립트는 Claude가 그 자리에서 작성하므로, 직접 적용하려면 트리거 시점에 "조사는 Haiku, 채점은 Sonnet, 설계는 Opus로"라고 방침을 전달하여 작성하게 하거나, 스크립트를 직접 작성해서 전달하는 두 가지 방법이 있습니다. 참고로 agent()에 모델을 전달하지 않으면 메인 루프 (Main loop)의 모델을 그대로 상속합니다. 기준 구성은 총 15개체가 Opus 4.8이었습니다. 저렴하게 만들려면 각 공정에서 명시해야 합니다.

수를 줄이기 — 채점을 1개체로 통합하기

토큰 수 자체를 가장 많이 깎는 방법은, 채점을 개별 에이전트의 병렬 처리에서 1개체가 한꺼번에 채점하는 배치 (Batch) 방식으로 바꾸는 것이었습니다. 채점을 6개체에서 1개체로 줄이면, 고정적인 바닥 비용인 20k를 5개체분, 그리고 기능 카탈로그 (Function catalog)의 캐시 (Cache) 쓰기를 5회분 없앨 수 있습니다. 토큰은 33% 감소했고, 실측 청구 금액도 39% 낮아졌습니다. 이번 실험은 모두 Opus를 사용했으므로 토크나이저의 간섭 없이 깔끔하게 비교할 수 있었습니다.

실제 시간은 거의 변하지 않습니다. 채점 페이즈 (Phase)는 원래 가장 느린 1개체에 의해 속도가 제한(Bottleneck)되어 있었고, 카탈로그 입력 처리도 1회로 충분하기 때문입니다. 33%의 토큰 절감을 속도를 희생하지 않고 얻을 수 있습니다. 다만 배치 건수를 너무 늘리면, 1개체가 순차적으로 내뱉는 출력이 병렬 1개체의 시간을 초과하는 교차점이 발생하며, 그 지점부터는 느려집니다.

왜 병렬 처리에서 "개체 수를 줄이는 것"이 이토록 효과적인지는 다음의 캐시 이야기와 연결됩니다.

캐시를 데우기 — 동일한 문맥을 시간적으로 가깝게 반복하기

실제 청구 금액을 가장 크게 움직이는 것은 캐시의 온도 (Temperature)였습니다. 캐시에는 두 종류가 있습니다. 새로 쓰는 캐시 쓰기 (Cache write)는 단가가 높고, 기존 것을 읽어오는 캐시 읽기 (Cache read)는 그 약 12분의 1로 저렴합니다. 동일한 문맥을 시간적으로 가깝게 반복하면, 2회차부터는 해당 문맥이 저렴한 읽기로 충당됩니다.

배치를 바꿔서 측정한 또 다른 소규모 실험에서는, 동일한 워크플로우가 캐시가 식은 첫 실행 시 $1.07, 완전히 데워진 상태에서 $0.33였습니다. 약 3.2배의 차이입니다. 카탈로그를 두느냐 마느냐, 앞에 두느냐 뒤에 두느냐와 같은 차이보다 온도가 압도적으로 지배적이었습니다.

운용 측면에서는 유사한 에이전트를 하나의 워크플로우 내에서 가까운 시각에 모으는 것이 유리합니다. 반대로, 별개의 워크플로우를 다수 동시에 실행하면 경합으로 인해 느려집니다. 4개를 동시에 실행했을 때는 각 페이즈가 15~40초 정도 늘어났습니다. 같은 종류의 에이전트는 하나로 뭉치는 것이 캐시도 데워지고 비용과 실제 시간 측면 모두에서 이득을 봅니다.

효과가 있을 줄 알고 시도했으나 실패한 것 — 병렬에서는 프리픽스 정렬도 카탈로그 축소도 조연에 불과함

여기까지에서 효과가 없었던 시책도 적어둡니다. 직관적으로는 반복되는 카탈로그를 각 채점자의 문맥 앞부분에 공유 프리픽스 (Shared prefix)로 배치하면, 첫 번째 에이전트가 작성한 캐시를 후속 에이전트들이 읽어와서 저렴해질 것 같습니다.

하지만 병렬로 동시에 실행되는 에이전트에서는 이것이 성립하지 않습니다. 배치를 변경하여 타입별 내역을 실측했습니다.

차가운 상태의 첫 번째 '이전 · 카탈로그 있음'을 보면, 캐시 쓰기(Cache Write)가 128,144로, 이는 대략 6개체 × 21k입니다. 6개체는 모두 동일한 시스템 프롬프트(System Prompt)와 카탈로그 접두사(Prefix)를 가지고 있음에도 불구하고, 각자 이를 풀(Full)로 쓰고 있습니다. 개별적으로 확인해도 6개체 모두 약 21,400으로 일치했습니다. 공유가 작동한다면 1개체만 높고 나머지는 낮아야 하지만, 그렇지 않습니다. 병렬 에이전트는 동시에 발화하기 때문에, 선두가 만든 캐시를 후속이 읽는 방식의 절약이 일어나지 않습니다. 앞서 언급한 '1개체 20k의 고정 바닥'의 정체는, 바로 차가운 상태에서 개체마다 실제로 지불하는 캐시 쓰기였습니다.

따뜻해진 상태에서는 구성이 무관했습니다. 이전이든 이후든 쓰기는 45k로 떨어지고, 읽기는 동일한 값이며, 청구 금액도 $0.33$0.39로 맞춰집니다. 일단 따뜻하게 만들어 두면 카탈로그는 어떤 구성에서도 저렴한 읽기로 충당되므로 차이가 사라집니다.

따라서 '채점자에게 카탈로그를 재주입하지 않는다'는 대책이 효과를 보는 것은, 카탈로그가 캐시 쓰기되는 시점, 즉 차가운 상태이거나 다시는 반복되지 않는 유니크한 문맥(Context)일 때뿐입니다. 따뜻하게 만들어 반복하는 운용에서는 카탈로그가 저렴한 읽기로 처리되므로, 이를 줄여도 효과는 작았으며 전체의 약 4% 정도였습니다. 올바른 일반화는 다음과 같습니다. 병렬 환경에서 효과가 있는 것은 개체 수를 줄이는 것과 동일한 문맥을 따뜻하게 만들어 반복하는 것 두 가지입니다. 접두사(Prefix) 정렬이 효과를 발휘하는 것은 순차적으로 실행할 때뿐입니다.

턴(Turn)을 줄이기

마지막으로 작은 레버(Lever)로서, 조사 단계의 웹(Web) 왕복을 중단하는 방법이 있습니다. 비용에 대한 기여도는 고정 바닥 대비 한계적이었으며, 약 2.5%였습니다. 하지만 실제 시간(Wall-clock time)에는 효과가 있습니다. 조사 페이즈(Phase)가 49초에서 19초로, 30초 단축되었습니다.

조합(Combination)의 결과

이상의 내용을 중첩한 구성을 각각 6개씩 온도를 맞춘 풀(Pool)에서 다시 측정했습니다. 실패한 실행을 제외한 24개 분량의 클린 데이터입니다.

totalTokens의 변동 계수는 0.7% 미만이며, 각 구성의 단발 추정치도 모두 6개 구간 안에 들어왔습니다. 결론은 수치로서 안정적입니다. 실측 청구 금액은 기준 대비 ±18%로 가장 크게 흔들리지만, 이는 캐시의 온도(Temperature)에서 기인한 것이므로, 횡단 비교는 Opus 환산을 주로 보고 실측액을 부차적으로 확인합니다. 참고로 이 표의 '조합'은 발명과 채점도 Haiku로 낮춘 가장 저렴한 방식이며, 나중에 보여드릴 품질 중시 권장 구성은 절감률이 이보다 약간 낮아집니다.

실제 시간도 측정했습니다. 클린하게 비교할 수 있는 것은 단독 실행 간의 비교뿐입니다.

표의 페이즈 값은 각 단계에서 가장 느린 1개체의 시간이며, 전체는 실측한 총 시간입니다. 페이즈 간의 미세한 전달 과정 때문에 단순 합산과는 몇 초 정도 차이가 납니다. 기준의 174초가 조합에서는 93초로, 약 46% 단축되었습니다. 단축의 주된 원인은 조사 단계의 웹 중단으로 인한 30초와, 채점을 Haiku 배치(Batch)로 돌린 35초였습니다. 이 실제 시간은 채점까지 Haiku로 낮춘 조합에서의 실측치입니다. 설계는 Opus를 유지하므로 변하지 않습니다. 토큰과 비용에 최적화된 구성이 동시에 거의 2배 더 빠르다는 결과가 나왔습니다.

조합의 청구 금액 내역을 보면, 비용의 대부분은 Opus를 유지한 선별과 설계 공정이 차지합니다. 저렴한 모델로 낮춘 공정은 이미 수량 면에서 효과를 보고 있으며, 비용의 바닥은 Opus를 남겨둔 공정이 결정합니다.

어떤 모델을 어디에 배치할 것인가

지금까지의 비용 이야기는 품질을 측정한 후에야 결론을 내릴 수 있습니다. 질적인 공정을 저렴한 모델로 낮추었을 때 결과물이 어떻게 변하는지, 입력을 고정하여 측정했습니다. 먼저 채점부터 살펴보겠습니다.

채점에서 가장 어려운 것은 새로움(novelty)의 판정입니다. 그중에서도 기존의 2가지 기능을 조합했을 뿐인 '비자명한 중복 (non-obvious redundancy)'을 찾아낼 수 있는지가 관건이었습니다. 동일한 후보군을 각 모델에 채점하게 하고, 루브릭(rubric)에 '중복은 감점할 것'이라는 지침을 넣었는지 여부에 따라 변수를 분리했습니다.

숫자는 '지시 없음 / 지시 있음'을 나타내며, Haiku는 각 2회씩입니다. 읽어낸 결과, 유효한 변수는 지시 여부가 아니라 중복의 자명성과 모델의 판별력이었습니다. 명백한 축어적 중복이라면 Haiku도 지시 없이 낮게 채점하여 Opus에 근접합니다. 하지만 비자명한 중복, 즉 기존의 공유 태스크 리스트와 케어 이력의 교차에 불과한 후보에 대해 Opus는 3438, Sonnet은 1828로 정확히 바닥(floor)을 찍은 반면, Haiku는 지시를 넣어도 52~72로 낮추지 못했습니다.

이는 각 셀을 15회씩 다시 추출해도 변하지 않았습니다. 비자명한 중복에 대한 평균은 Opus가 27.5, Sonnet이 10.6, Haiku가 52.7이었으며, Haiku는 중앙값 기준으로 Opus보다 25점 높았고 편차도 약 5배였습니다. Haiku가 비자명한 중복을 간파하지 못하는 것은 통계적으로도 확실한 품질 결함입니다.

한편, Sonnet의 성격은 다음과 같이 정리할 수 있습니다.

Sonnet은 비자명한 중복도 Opus 수준으로 바닥을 찍으며, 3개 모델 중 자기 재현성이 가장 높습니다. 약점은 좋은 후보의 점수를 일률적으로 72로 압축해 버려, 양안들 사이의 세밀한 서열 매기기에서 Opus에 뒤처진다는 점뿐이었습니다.

채점뿐만 아니라, 발명이 만들어내는 착상의 질도 측정했습니다. 고정된 지시문으로부터 각 모델에 안을 내게 하고, 그 질을 모델당 30회씩 Opus가 가린 상태에서 채점한 평균은 Sonnet이 65.3, Opus가 62.2, Haiku가 54.1입니다. Sonnet과 Opus는 거의 나란히 위치하며 통계적인 차이는 없었습니다. 떨어지는 것은 Haiku로, 새로움이 아니라 구체성과 실현성이 각각 10점 정도 낮았습니다. 관점은 나쁘지 않은데 마무리가 부족한 것입니다. 따라서 발명 또한 기계적인 사전 조사와 달리 저렴한 모델에 전적으로 맡길 수는 없습니다.

최종 설계는 Opus에 남겨둡니다. 구현에 영향을 미치는 엣지 케이스(edge case), 예를 들어 서머타임이나 타임존에 의한 오검출, 발송 완료와 진정한 미발생의 구분 같은 세부적인 검토에서 Opus가 가장 깊게 잡아내기 때문입니다.

여기서 권장 사항이 결정됩니다.

기본 설정은 조사는 Haiku, 발명과 채점은 Sonnet, 선별과 설계는 Opus로 배치하고, 채점은 배치(batch)로 처리합니다. 발명과 채점은 모두 질적인 판단이므로 Sonnet에 맡기고, 조사는 각도만 제시하면 하류 공정에서 심사하므로 Haiku를 사용하는 것이 리스크가 적습니다. 새로움과 중복의 선별이 목적이라면 채점은 Sonnet이 유일한 선택지입니다. 좋은 후보의 세밀한 순위까지 원하는 경우에만 채점을 Opus로 합니다.

채점을 Haiku로 낮추는 것은 권장하지 않습니다. 명백한 중복만 나오는 채점에 한해서는 최저가이겠지만, 일반적인 아이디어 선별에서는 비자명한 중복을 놓치게 됩니다.

비용 실측에서 약 70%라는 절감 수치는 발명과 채점 모두 Haiku로 낮춘 가장 저렴한 구성의 값입니다. 품질을 고려한 권장 구성에서는 발명과 채점을 Sonnet으로 올립니다. 채점은 배치로 1개체이므로 올려도 비용 증가가 매우 미미하지만, 발명은 여러 개체이므로 Sonnet으로 올리면 비용이 약간 돌아옵니다. 그럼에도 청구액의 주성분은 Opus에 남겨둔 선별과 설계이므로, 권장 구성의 절감률은 최저가 구성보다 약간 작아질 뿐, 여전히 크게 낮아집니다. 품질을 유지할 수 있는 만큼, 이는 타당한 트레이드오프(trade-off)입니다.

개선 단계

자신의 워크플로우를 저렴하게 만들려면, 효과가 큰 순서대로 다음 조치들을 취하는 것이 지름길입니다.

• 공정별로 모델을 할당하기. 조사는 Haiku, 발명과 채점은 Sonnet, 선별과 설계는 Opus. agent()에 모델을 전달하지 않으면 전부 Opus를 상속받으므로, 각 단계에서 명시할 것.
• 채점을 배치(Batch)로 처리하기. 한 번에 모아서 채점하면, 고정 비용(floor)과 카탈로그 쓰기 횟수를 개체 수만큼 줄일 수 있음.
• 캐시를 예열하기 (Warm the cache). 유사한 에이전트를 하나의 워크플로우로 묶거나 가까운 시간대에 모으고, 서로 다른 워크플로우를 다수 동시에 실행하지 말 것.
• 상한선 가드 및 시범 운영. budget.total과 budget.remaining()으로 상한선을 설정하고, 본 작업 전에 작게 돌려 기준 수치를 확보할 것 - 암묵적인 기준은 루브릭(Rubric)에 명시한다. 단, 자명하지 않은 중복은 명시하더라도 Haiku가 찾아내지 못함.

마치며

dynamic workflows의 비용은 세 가지 레버에 따라 정직하게 움직였습니다. 단가를 낮추고, 수를 줄이고, 캐시를 예열하는 것. 가장 저렴하게 구성했을 때는 비용이 Opus 환산 기준 약 68%, 실측 기준 약 74% 감소했으며, 실제 시간도 약 46% 단축되었습니다. 품질을 유지하기 위해 발명과 채점을 Sonnet으로 올리면 절감 폭은 약간 줄어들지만, 비용의 주성분은 Opus로 남겨둔 선별과 설계이므로 여전히 크게 낮아집니다. 저렴하게 운영하는 것과 착상 및 중복 탐지의 품질을 유지하는 것은 공정별로 모델의 가격대를 선택함으로써 양립할 수 있었습니다.

다중 에이전트(Multi-agent)를 실제 제작에 어떻게 활용했는지, 그리고 '재미있는지 여부의 판정'만은 기계화할 수 없었던 이야기는 Claude Code의 dynamic workflows를 통해 38체의 AI에게 게임을 찾게 했던 기사에 적어두었습니다. 어떤 공정을 저렴한 모델에 맡길 수 있는지, 자명하지 않은 중복은 저렴한 모델이 찾아내지 못한다는 이번 실험의 경계선은, 해당 기사의 "최종적인 수렴은 인간의 몫으로 남았다"는 이야기와 그대로 이어집니다.

Discussion