Skill 시리즈 (05): Skill 워크플로우 체이닝 — 4가지 패턴, 실제 데이터, 병렬 처리를 통한 1.5배 속도 향상

단일 Skill의 한계

단일 Skill은 한 가지 일만 수행하도록 설계되었습니다. "기술 작가 (technical writer)" Skill은 경쟁사 데이터를 검색하고, 이를 분석하며, 서식이 지정된 보고서를 생성할 수 없습니다. 그러기 위해서는 여러 단계와 여러 전문 분야가 체인(chain) 형태로 연결되어야 합니다.

워크플로우 체이닝 (Workflow chaining)은 단일 Skill들을 결합하여 이러한 한계를 넘어서는 파이프라인 (pipeline)을 구성합니다.

네 가지 체이닝 패턴

패턴 1: 순차적 체인 (Sequential Chain)

A → B → C
각 Skill의 출력이 다음 Skill의 입력이 됨

가장 단순한 구조이며 선형적인 작업에 적합합니다. 결정적인 제약 사항은 한 단계가 실패하면 전체 체인이 중단된다는 점입니다.

패턴 2: 병렬 팬아웃 (Parallel Fan-out)

         → B1 →
A → split → B2 → merge → C
         → B3 →

여러 Skill이 동시에 실행되고 결과가 병합됩니다. 이론적인 속도 향상(speedup)은 분기(branch)의 수와 같습니다. 실제 속도 향상은 병합(merge) 단계가 얼마나 오래 걸리는지에 따라 달라집니다.

패턴 3: 조건부 라우팅 (Conditional Routing)

A → Router → [technical] → tech-writer
             [marketing] → marketing-writer
             [default]   → general-writer

라우터 (router) Skill이 열거형 (enum) 값을 출력하면, 그 결과에 따라 워크플로우가 분기됩니다. 라우터는 자유 형식의 텍스트가 아닌 특정 열거형 타입 (enumerated type)을 반환해야 합니다.

패턴 4: 피드백 루프 (Feedback Loop)

A → Evaluator → [score ≥ 7] → output
                    ↓
               [score < 7] → feedback → A (재시도, 최대 3회)

품질 게이트 (Quality gate): 출력이 임계값(threshold)을 충족하지 못하면, 평가자 (evaluator)의 피드백을 바탕으로 다시 작성합니다. 무한 루프를 방지하기 위해 항상 최대 재시도 횟수를 설정해야 합니다.

데모 설계

네 가지 패턴 모두 실제 LLM 호출을 사용합니다:

패턴	구현	측정 항목
순차적 (Sequential)	LangGraph 3-노드 그래프: 키워드 → 개요 → 작성	엔드 투 엔드 지연 시간 (End-to-end latency)
...

실행 결과

패턴 1: 순차적 체인 (Sequential Chain)

주제:    Python async/await: 코루틴에서 프로덕션 준비 완료 패턴까지
키워드: async 프로그래밍, 코루틴 (coroutines), await, 프로덕션 준비 완료 패턴
개요:  - Python의 비동기 프로그래밍 소개
...

패턴 2: 병렬 팬아웃 (Parallel Fan-out)

Company: Notion
Product: Notion은 다음과 같은 포괄적인 제품군으로 눈에 띕니다...
Market: Notion의 시장 포지셔닝은 다재다능한 생산성 플랫폼으로서...
...

패턴 3: 조건부 라우팅 (Conditional Routing)

Input:  "코드 예제를 사용하여 Kubernetes 포드 스케줄링이 어떻게 작동하는지 설명해 주세요"
Route:  technical  (18.9s)
Output: Kubernetes 포드 스케줄링은 포드를 노드에 할당하는 과정입니다...
...

패턴 4: 피드백 루프 (Feedback Loop)

Topic: Redis Cluster 샤딩 전략에 관한 기술 기사 작성

  Iteration 1: score=8/10  ✓ PASS
...

세 가지 발견 사항 (Three Findings)

발견 1: 이론적인 3배가 아닌, 1.5배의 병렬 가속 (Parallel Speedup)

세 개의 분석기가 동시에 실행되었습니다. 팬아웃 (Fan-out) 단계: 12.4s. 순차 실행 시 소요 시간: 37.2s (12.4 × 3). 팬아웃 단계만 따지면 약 3배의 가속이 발생했습니다. 전체 파이프라인 (팬아웃 + 병합 (merge)): 24.5s. 전체 가속 성능: 37.2 / 24.5 ≈ 1.5x.

암달의 법칙 (Amdahl's Law) 적용:

Total speedup = 1 / (serial fraction + parallel fraction / N)

이번 실행 결과:
...

최적화의 핵심 레버는 더 많은 병렬 분기(concurrent branches)를 만드는 것이 아니라, 병합 (merge) 단계에 있습니다. 병합 프롬프트의 토큰 부하를 줄이면 직렬 병목 현상 (serial bottleneck)이 줄어들어, 실질적인 가속 성능의 상한선이 높아집니다.

발견 2: 세 번째 라우팅 결과는 "일반 (General)"이 아닌 "기술적 (Technical)"이었다

"머신러닝(Machine Learning)이란 무엇이며 왜 중요한가?"라는 질문은 일반 작가가 아닌 기술 작가(technical writer)에게 라우팅되었습니다.

이 분류는 합리적이지만 대상 독자(audience)에 따라 달라질 수 있습니다. 엔지니어링 팀에게 ML은 기술적인 주제입니다. 하지만 제품 관리자(Product Manager)에게는 일반적인 주제입니다. 분류기(classifier)는 질문을 하는 사람이 누구인지가 아니라 질문 텍스트만을 보았습니다.

운영 환경에서의 해결책: 분류기 입력값에 대상 독자 정보를 포함하십시오:

classifier_input = f"Request: {request}\nTarget audience: {workflow_input.audience}"

이 정보가 없다면, 라우터는 질문자가 누구인지에 대해 암묵적인 가정을 하게 됩니다. 그 가정은 보이지 않으며, 적어도 한 종류의 독자층에게는 틀린 결과가 됩니다.

발견 3: 피드백 루프가 첫 번째 반복에서 통과했다 — 그것이 핵심이다

1차 반복(iteration 1)에서 점수 8/10을 기록했으며, 재시도(retries)가 필요하지 않았습니다. 소요 시간: 44.8s.

게이트(gate)는 8/10점이 충분히 괜찮다고 판단하여 첫 번째 시도를 통과시켰습니다. 이것이 설계가 올바르게 작동하고 있다는 증거입니다. 품질 게이트(quality gates)는 모든 출력을 거르는 것이 아니라, 진정으로 품질이 낮은 출력만을 필터링합니다.

임계값 교정 (Threshold calibration):

• 5/10은 너무 낮음: 거의 아무것도 트리거되지 않으며, 게이트가 장식적인 역할에 그침
• 9/10은 너무 높음: 거의 모든 것이 트리거되며, 토큰 비용이 두 배로 증가함
• 7/10은 유용한 시작점: 실제 품질 격차를 차단하면서도, 견고한 초안은 통과시킴

피드백의 품질이 재시도(retry)의 효과를 결정합니다:

효과적임: "write-behind 패턴에 대한 코드 예시가 누락되었습니다. TTL과 eviction policy의 차이를 명확히 하세요."
효과적이지 않음: "더 좋고 포괄적으로 만드세요."

두 번째 피드백은 작성자가 실행할 수 있는 구체적인 지침을 전혀 제공하지 않습니다. 루프는 돌아가고, 토큰은 소비되지만, 출력물은 거의 변하지 않습니다.

에러 핸들링 (Error Handling)

체인된 워크플로우(Chained workflows)는 네 가지 에러 유형에 직면하며, 각 유형은 서로 다른 대응을 필요로 합니다:

일시적 에러 (Transient) (LLM 타임아웃, rate limit)
  → 지수 백오프 (exponential backoff)를 적용하여 3회 재시도: 1s, 2s, 4s

...

상태 스키마 (State Schema)

체인 내에서 상류(upstream) Skill의 출력은 하류(downstream) Skill의 입력이 됩니다. 스키마가 일관되지 않으면 출력이 변경되는 즉시 체인이 끊어집니다.

{
  "status": "success",
  "output": {
...

긴 파이프라인을 위한 컨텍스트 압축 (Context compression): 상류의 출력이 약 5,000 토큰을 초과할 때, 하류 Skill들은 전체 내용이 필요한 경우가 드뭅니다. 세 가지 옵션이 있습니다:

1. 하류로 전달하기 전에 압축하기 위한 요약(summarizer) Skill을 삽입
2. 하류 Skill에 필요한 필드만 전달 (output.main_content가 아닌 output.metadata 전달)
3. 대규모 중간 결과물(artifacts)을 외부에 저장하고, 하류에서 필요할 때 호출하여 가져옴

설계 체크리스트 (Design Checklist)

순차적 체인 (Sequential chain)

• 각 단계의 출력 형식이 정의되어 있는가 (하류에서 파싱 가능해야 함)
• 중요한 단계에 폴백(fallback) 로직이 있는가 (단순히 실패 시 중단하는 것이 아님)

병렬 팬아웃 (Parallel fan-out)

• 병합(Merge) Skill이 부분적인 브랜치 실패를 처리하는가 (실패 처리 대신 주석 처리)
• 얼마나 많은 브랜치를 추가할지 결정하기 전에 병합 단계의 지연 시간(latency)을 측정했는가

조건부 라우팅 (Conditional routing)

• 라우터(Router)가 자유 텍스트가 아닌 열거형(enumerated type)을 출력하는가
• 기본 분기(Default branch)가 분류되지 않은 입력을 처리하는가
• 라우팅 입력에 대상(audience) 또는 컨텍스트(context) 메타데이터가 포함되는가

피드백 루프 (Feedback loop)

• 최대 재시도 횟수(Max retry count)가 설정되어 있는가 (3회가 적절한 기본값임)
• 피드백이 일반적인 "더 잘해봐"가 아닌 특정 문제를 타겟팅하는가
• 최대 재시도 후: 에러를 반환하는 대신 최선의 결과와 주석(annotation)을 반환하는가

요약 (Summary)

1. 병렬 가속은 3배가 아닌 1.5배였다: 팬아웃(fan-out) 단계는 3배 더 빠르게 실행되었지만, 병합(merge) 단계가 팬아웃만큼의 시간이 소요되었습니다. 암달의 법칙(Amdahl's Law)에 의해 전체 속도는 1.5배로 제한되었습니다. 해결책은 더 가벼운 병합 단계를 만드는 것입니다.
2. 조건부 라우팅에는 대상 컨텍스트가 필요하다: 주제만으로는 모호할 수 있습니다. 동일한 질문이라도 기술적 대상(technical audience)인지 일반 대상(general audience)인지에 따라 라우팅이 달라집니다.
3. 피드백 루프의 효율성은 임계값(threshold) 설계에 달려 있다: 첫 번째 시도에서의 통과율은 임계값이 올바르게 조정되었음을 보여줍니다. 게이트(gate)의 역할은 재시도를 강제하는 것이 아니라 실제 품질 격차를 필터링하는 것입니다.

참고 문헌 (References)

• LangGraph StateGraph documentation
• 전체 데모 코드: skill-05-workflow

실제 기업급 워크플로우에서 검증된 AI 에이전트와 스킬의 큐레이션 마켓플레이스인 PrimeSkills를 확인해보세요. 불필요한 내용은 빼고, 실제로 작동하는 것들만 제공합니다.

저의 홈페이지에서 더 유용한 지식과 흥미로운 제품들을 찾아보세요.