이 기사의 요점 (2026년 6월): Claude Code Workflow의 API로 「39개 기사에 대한 CTA(기사 말미 유도 문구) 일괄 추가」를 하나의 Workflow에 맡겼더니, 116개의 에이전트가 기동되어 4.28M 토큰, 5시간 17분을 소비했다 (실측치. 출처는 내부 로그). 원인은 본래 「단일 에이전트의 bash 루프」로 충분한 순차 처리 (Sequential Processing) 페이즈에, 병렬 처리 (Parallel Processing)와 동일한 입도(Granularity)의 설계 (1 에이전트/건)를 채택했기 때문이다. 병렬 페이즈만 Workflow의 parallel()에 맡기고, 순차 페이즈를 bash 루프로 전환하는 이상적인 설계였다면 약 40개의 에이전트, 745K 토큰, 약 $4.47로 해결되었을 계산이 나온다. 비용 차이는 5.7배다. 이 기사는 그 경계선을 어떻게 설계해야 하는지를 실측 기반으로 정리한 것이다.

Workflow로 「전부 다 하기」가 왜 비싸게 먹히는가

Claude Code의 Workflow API를 사용하기 시작할 때 가장 먼저 매력적으로 보이는 점은 「여러 태스크를 묶어서 자동화할 수 있다」는 점이다. 기사 39개를 한꺼번에 편집하고, Hatena·Zenn·Qiita에 순차적으로 공개한다——이러한 일련의 흐름을 하나의 Workflow로 작성하면, 이후에는 실행만 하면 끝난다. 편리해 보인다.

하지만 이 「전부 다 하기」가 함정이 된다. Workflow에 맡기는 처리에는 성질이 다른 두 종류가 섞여 있기 때문이다.

병렬 처리 (Parallel Processing): 39개의 기사를 각각 독립적으로 편집한다. 하나의 처리가 다른 기사에 의존하지 않는다 -
순차 처리 (Sequential Processing): Hatena에 하나씩 공개한다. API의 Rate Limit(속도 제한)이나 공개 순서의 사정으로 인해, 한 건씩 직렬로 진행해야 한다

이 두 가지를 동일한 입도로 설계하면——즉, 둘 다 「1 태스크 = 1 에이전트」로 구성하면——순차 처리 측에서 에이전트 기동 비용이 선형적으로 쌓이게 된다. 이것이 이번 경험에서 일어난 일이다.

결론부터 말하겠다. 병렬 처리에는 Workflow의 parallel()을, 순차 처리에는 단일 에이전트의 bash 루프를 사용한다. 이 구분법을 설계 단계에서 의식하고 있느냐에 따라 비용이 몇 배나 달라진다.

무엇을 했고, 어떤 일이 일어났는가

2026-06-20, 나는 39개의 기사에 「다음 질문 예고형」 Zenn Book CTA (기사 말미 유도 문구)를 일괄 추가하는 Workflow를 실행했다. 각 기사의 테마에 맞춰 CTA 문구를 생성하고, 소스 파일·Hatena 투고용 entry·Zenn 투고용 content의 3곳을 편집한 뒤, 그대로 각 플랫폼에 공개하는 것까지를 하나의 Workflow로 묶었다.

실행 결과는 다음과 같다 (실측치. 출처는 내부 로그).

CTA 일괄 추가라는 겉보기에는 단순한 작업이다. 그것이 5시간을 넘기고 4.28M 토큰을 소비했다. 「성공적으로 자동화했다」고 생각한 직후, 수치를 보고 손이 멈췄다.

Workflow의 구성은 5개의 페이즈(Phase)로 나뉘어 있었다 (출처: 내부 로그).

Phase 1 (CTA 편집): 39개 기사를 parallel()로 동시 처리. 각 에이전트가 기사를 읽고 테마에 맞는 CTA를 생성하여 3곳의 파일을 편집 -
Phase 2 (Hatena 공개): 1 에이전트 × 38건을 순차 루프 -
Phase 3 (Zenn push): 단일 에이전트로 git push -
Phase 4 (Qiita 공개): 1 에이전트 × 37건을 순차 루프 -
Phase 5 (커밋): 단일 에이전트 -

Hatena 38건, Qiita 37건으로 39건과 차이가 나는 이유는 Zenn만 공개하거나 크로스 포스트를 제외하는 등 플랫폼별 공개 대상이 다르기 때문이다.

문제는 Phase 2와 Phase 4에 있다.

왜 에이전트가 116개가 되었는가

「여러 기사를 순서대로 공개한다」라고 하면, 직관적으로는 「한 건씩 처리하는 에이전트를 나열하면 된다」라고 생각하기 쉽다. 나도 그렇게 설계했다. Phase 2에서는 「1 에이전트가 1건을 공개한다」를 38번, Phase 4에서는 마찬가지로 37번 반복했다.

여기에 에이전트 기동 비용의 구조적인 함정이 있다.

Claude Code의 서브 에이전트(Sub-agent)는 각각이 독립된 컨텍스트 윈도우 (Context Window)를 가지고 기동한다. 에이전트를 하나 실행할 때마다, 그 에이전트는 자신의 역할·절차·전제를 처음부터 읽어 들인다. 한 건의 공개 작업 자체는 가볍더라도, 그 전 단계인 「기동하여 문맥을 정돈하는」 비용이 매번 발생한다.

Phase 2의 38개와 Phase 4의 37개로, 총 75회분의 기동 비용이 쌓였다. Phase 1의 병렬 39개와 각 페이즈의 관리 에이전트(Agent)를 합치면, 기동된 에이전트는 116개에 달했다.

이는 별도의 기사에서 「서브 에이전트 위임세」라고 썼던 구조와 완전히 동일한 것이다. 1개 태스크(Task)마다 에이전트를 기동하면, 기동 비용이 태스크 수에 비례하여 선형적으로 쌓인다. 위임세 기사에서는 노트 1건의 퀵 캡처(Quick Capture)를 통해 「COO 직접 실행은 8초, 에이전트 위임은 약 1분」이라는 차이를 실측했는데, 이번에는 그것이 75건분만큼 쌓인 셈이 된다.

순차 처리에서는 이 기동 비용이 매번 발생한다. 이것이 비용을 부풀린 정체다.

보충: 「116개의 에이전트는 39개 동시 처리라는 특수한 케이스가 아닌가? 보통은 그렇지 않을 것이다」라고 느끼는 독자도 있을 것이다. 확실히 건수의 규모는 특수하다. 하지만 「1건마다 에이전트를 기동하면 기동 비용이 건수에 비례한다」는 구조 자체는, 건수가 3개든 300개든 변하지 않는 보편적인 것이다. 건수가 늘어날수록 설계 미스의 대가가 더 크게 보일 뿐이다.

왜 「병렬인가, 순차인가」에 따라 페이즈의 구현을 나누어야 하는가

그렇다면 어떻게 설계했어야 했을까. 원칙은 심플하다. 페이즈의 성질(병렬인가 순차인가)에 따라 구현 방식을 나누는 것이다. 「이것은 각 태스크가 서로 의존하지 않는가?」라는 질문이 판단의 기준이 된다.

parallel()를 사용한다

병렬 처리인 Phase 1의 CTA 편집은 39개가 각각 독립되어 있다. A 기사의 CTA 생성은 B 기사의 결과를 필요로 하지 않는다. 이런 「각 태스크가 서로 의존하지 않는」 처리야말로 Workflow의 parallel()이 진가를 발휘하는 장면이다.

39개를 1개씩 직렬로 처리하면 39배의 시간이 걸리지만, parallel()라면 동시에 실행된다. 기동 비용은 39개분이 들지만, 그 대가로 처리 시간이 극적으로 압축된다. 병렬 페이즈에서는 이 시간 단축이 비용만큼의 가치를 한다. 만약 bash 루프로 39개를 직렬 처리했다면, 그야말로 몇 시간이나 기다려야 했을 것이다.

순차 처리에는 단일 에이전트의 bash 루프를 사용한다

반면, Phase 2의 Hatena 공개는 사정이 다르다. 1건씩 직렬로 진행할 수밖에 없는 처리다 (공개 API의 레이트 리밋(Rate Limit)이나 순서상의 이유가 있다). 어차피 직렬이라면, 에이전트를 여러 개 기동할 의미가 없다.

이 경우는 「1개의 에이전트를 기동하고, 그 에이전트 안에서 bash 루프를 돌려 38개를 순차적으로 공개하는 것」이 옳다. 에이전트의 기동 비용은 1회로 끝나며, 루프 자체는 셸(Shell)이 돌리기 때문에 거의 비용이 들지 않는다. Phase 4의 Qiita 공개도 마찬가지로, 1개 에이전트의 bash 루프로 묶을 수 있다.

순차 처리에서 에이전트를 건수만큼 기동하는 것은, 셸의 for 루프로 충분한 처리에 매번 프로세스를 새로 띄우는 것과 같다. 직렬이라면 문맥을 가진 에이전트는 1개만 있어도 충분하다.

여기서 「bash 루프로 충분하다면, 애초에 Workflow를 사용할 의미는?」이라고 생각할지도 모른다. 의미가 있는 것은 병렬 페이즈다. Phase 1의 39개 동시 처리는 bash 루프로는 직렬로 처리될 수밖에 없어 몇 시간이나 걸린다. Workflow의 parallel()은 바로 그 지점에서 효과를 발휘한다. Workflow는 「병렬을 압축하는 도구」이지, 「순차 처리를 대신해 주는 도구」가 아니라고 이해하면 좋다.

이상적인 설계와의 비교: 비용은 5.7배 차이 났다

실제 설계와 원칙대로 다시 구성한 이상적인 설계를 페이즈별로 나열하면 다음과 같다.

병렬 페이즈(Phase 1)는 그대로 두는 것이 맞다. 바꿔야 할 것은 순차 페이즈(Phase 2 · 4)의 75개를 각각 1개 에이전트의 bash 루프로 묶는 것이다. 이것만으로도 기동 에이전트는 116개에서 약 43개(Phase 1: 39개 + Phase 2~5: 각 1개)까지 줄어든다.

비용으로 환산하면 다음과 같다 (추산치. 출처는 후술).

비용 차이는 5.7배다. 동일한 결과물(39개에 대한 CTA 추가 및 공개)을 얻는 데 있어, 설계의 경계선 하나로 6분의 1 가까이 압축할 수 있었다는 계산이 나온다.

비용 추산의 전제를 명시해 둔다. 토큰 단가는 Sonnet 4.6의 $3/MTok (입력) · $15/MTok (출력)를 기준으로, 입출력 비율을 3:1로 가정했다. 4,283,366 토큰을 3:1로 배분하면 입력 약 321만 · 출력 약 107만 토큰이며, 개략적으로 약 $25.70이다. 이상적인 설계의 745,000 토큰을 동일한 비율과 단가로 계산하면 약 $4.47이다 (모두 2026-06-20 시점의 단가에 따른 추산이며, 실제 청구 금액과는 차이가 있을 수 있다).

Workflow는 「병렬 페이즈 전용 도구」 —— 설계의 경계선으로 비용이 5.7배 달라진다

Workflow는 병렬 페이즈를 압축하는 도구이지, 순차 페이즈를 대신 수행하는 도구가 아니다.

이번 경험을 통해 얻을 수 있는 설계 원칙은 이 한 문장으로 요약된다.

병렬 처리 (각 태스크가 독립적) $\rightarrow$ Workflow의 parallel(). 기동 비용을 대가로 처리 시간을 압축한다.
순차 처리 (1건씩 직렬) $\rightarrow$ 단일 에이전트의 bash 루프. 기동 비용을 1회로 억제한다.

"Workflow로 전부 다 한다"는 생각은, 병렬과 순차를 동일한 입도로 설계할 경우 오히려 비용이 역전되는 결과를 초래한다. 나는 이를 사후의 수치(116개 에이전트 · 4.28M 토큰 · 5.7배)를 보고서야 비로소 뼈저리게 깨달았다.

이상적으로는 이 경계선을 설계 단계에서 의식해야 한다. 페이즈를 나열했다면, 각각에 대해 "이것은 병렬인가, 순차인가"라고 한 번씩 질문해야 한다. 병렬이라면 parallel(), 순차라면 bash 루프. 그 한 번의 수고가 비용을 몇 배나 좌우한다.

한 가지 보충해 두고 싶은 점이 있다. 이번 Workflow를 의뢰했을 때의 지시는 "39개의 기사에 동일하게 반영해 줘"라는 단순한 것이었다. "순차 처리는 단일 에이전트의 bash 루프로 해줘"라는 말은 한마디도 하지 않았다.

이 경계선은 사용자가 지시에 포함해야 하는 지식이 아니다. Workflow를 구현하는 측 — 에이전트든 엔지니어든 — 이 기본적으로 판단해야 할 사항이다. 의뢰자가 "병렬인가 순차인가"를 설계 수준에서 의식하여 지시하지 않으면 효율적인 구현이 되지 않는다면, 그것은 구현 측의 설계력 문제다.

바꿔 말하면, 이번 경험은 "이렇게 지시했어야 했다"는 이야기가 아니라, "Workflow를 작성하는 측이 이러한 판단력을 갖추고 있지 않았다"는 이야기가 된다.

덧붙여, 이번 실행 중 Qiita 공개 시 레이트 리밋(Rate Limit, HTTP 429)도 별도로 발생했으나, 그것은 또 다른 주제이므로 본문에서는 다루지 않는다. 순차 공개 설계에는 기동 비용과는 별개로 레이트 리밋에 대한 배려도 필요하다 — 라는 숙제만 남겨둔다.

Workflow의 페이즈 설계에서 "어디를 병렬로 하고, 어디를 순차로 묶을 것인가"를 정리하면 다음 질문이 떠오른다. — 애초에 이 Workflow를 구동하는 여러 개의 에이전트를 조직으로서 어떻게 설계하고, 어떻게 운영에 태웠는가?

병렬·순차의 구분은 「팀이 움직이고 있다」는 전제의 이야기다. 나는 그 전 단계――에이전트 구성을 짜고, 그것을 일상적인 자동화에 태워 나가는 과정――을 Zenn Book에 정리하고 있다. Vol.1에서는 역할 설계·위임 규칙·CLAUDE.md 작성법을, Vol.2에서는 운영·자동화·Routines 구성 방법(이번과 같은 Workflow를 어디에 배치할지를 포함하여)을 다루고 있다.

관련 기사: Claude Code의 서브 에이전트 위임세 (에이전트 구동 비용의 구조를 다른 각도에서 분석한 기사)

이 글은 はてなブログ (Hatena Blog) 에서의 크로스 포스트입니다.

Discussion