복잡한 작업을 위한 AI 모델 체이닝(Chaining)의 기술

지난달 저는 GPT-4o는 법률 문서를 요약하고, Claude는 구조화된 조항을 추출하며, 미세 조정(fine-tuned)된 Mistral이 리스크를 분류하는 파이프라인을 디버깅하는 데 사흘을 보냈습니다. 결과물은 환상적이었습니다. 하지만 오케스트레이션(orchestration)은 재앙이었습니다. 경합 조건(race conditions), 긴 계약서에서의 토큰 오버플로(token overflow), 그리고 체인 내의 어떤 모델도 다른 모델의 오류를 잡아낼 책임이 없었기에 발생한 조용한 환각(hallucination)까지 발생했습니다. 저는 이를 해결했습니다. 그러고 나서 왜 AI 모델을 체이닝하는 것이 매일 이 작업을 수행하는 사람들조차 여전히 제대로 이해하지 못하고 있는지에 대해 깊이 고민하기 시작했습니다.

단일 모델 사고방식이 당신을 저해하는 이유

대부분의 개발자들은 하나의 모델을 선택해 모든 것을 수행하도록 시도합니다. 코드를 작성하고, 테스트하고, 리뷰하고, 설명하는 것 말입니다. 이는 저항이 가장 적은 경로이며, 작동은 합니다. 하지만 작동하지 않는 순간이 오기 전까지만 그렇습니다.

문제는 범용 모델(general-purpose models)이 제너럴리스트(generalists)가 되도록 훈련되었다는 점입니다. 이들은 넓은 범위에 최적화되어 있습니다. 모호한 텍스트에서 구조화된 JSON 추출, 10,000개의 청크(chunks)에 걸친 높은 재현율(high-recall) 검색, 또는 결정론적 분류(deterministic classification)와 같이 깊이가 필요한 경우, 제너럴리스트 모델은 제너럴리스트 수준의 결과만을 제공할 것입니다. 필드 이름을 환각(hallucinate)하거나, 검색 과정에서 왕복(round trip) 오류를 범하거나, 엣지 케이스(edge cases)를 자신 있게 잘못 분류할 것입니다.

체이닝(Chaining)은 단순히 더 많은 모델을 사용하기 위한 것이 아닙니다. 이는 역량(capability)을 작업(task)에 맞추는 것입니다. 한 가지 일을 정밀하게 수행하는 작고 미세 조정된 모델이, 열 가지 일을 대략적으로 수행하는 프런티어 모델(frontier model)보다 더 나은 성능을 보일 것입니다. 이 전제를 받아들이는 순간, 당신은 "어떤 모델을 사용해야 할까?"라고 묻는 대신 "어떤 모델이 이 단계를 담당해야 할까?"라고 묻기 시작할 것입니다.

토폴로지(Topology) 문제: 단순한 체인이 아니다

"Chaining"은 오해의 소지가 있는 단어입니다. 이는 A가 B를 공급하고, B가 C를 공급하는 선형성(Linearity)을 암시합니다. 실제 워크플로우(Workflow)는 그래프(Graph)입니다. 팬아웃(Fan-out, 하나의 모델이 다른 세 개의 모델로 병렬 호출을 생성), 팬인(Fan-in, 여러 모델의 출력을 하나의 합성 단계로 집계), 조건부 라우팅(Conditional routing, 분류기(Classifier)가 uncertain을 반환하면 더 유능한 모델로 재실행), 그리고 피드백 루프(Feedback loops, 비평가(Critic) 모델이 결과물을 하류(Downstream)로 내보내기 전에 자신의 파이프라인 출력을 평가)가 존재합니다.

그래프를 체인처럼 취급하면, 모든 것을 직렬화(Serialize)하거나(느리고 취약함), 일관된 상태 관리(State management) 없이 임시적인 비동기(Async) 호출을 하게 됩니다(빠르지만 혼란스러움). 둘 다 정답이 아닙니다.

단 하나의 API 호출을 작성하기 전에, 토폴로지(Topology)를 그리십시오. 질문하십시오: 어떤 단계가 진정으로 순차적인가? 어떤 단계가 병렬로 실행될 수 있는가? 어디에서 병합/축소(Merge/reduce) 단계가 필요한가? 어디에서 조건부 분기(Conditional branch)가 필요한가? 이 다이어그램은 — 종이에 그린 거친 그림일지라도 — 당신이 수행할 그 어떤 프롬프트 엔지니어링(Prompt engineering)보다 가치 있습니다. 아키텍처(Architecture)는 단 하나의 토큰이 생성되기도 전에 출력 품질의 80%를 결정합니다.

침묵의 실패 문제 (The Silent Failure Problem)

이것이 실제로 프로덕션 파이프라인(Production pipelines)을 망가뜨리는 주범입니다. 사람이 잘못된 작업을 하면, 체인의 다음 사람이 이를 알아차리고 반박합니다. 하지만 모델이 잘못된 작업을 하면, 체인의 다음 모델은 그 위에 자신 있게 결과물을 쌓아 올립니다.

저는 이를 '신호 없는 오류 전파(Error propagation without signal)'라고 부릅니다. 모델 A가 날짜를 잘못 추출합니다. 모델 B는 그 날짜를 사용하여 마감일을 계산합니다. 모델 C는 잘못된 마감일이 포함된 공식 서한을 생성합니다. 어떤 모델도 예외(Exception)를 발생시키지 않습니다. 어떤 모델도 불확실성(Uncertainty)을 표시하지 않습니다. 출력물은 깔끔해 보이지만, 완전히 틀려 있습니다.

해결책은 전달 지점(Handoff points)에서의 의도적인 검증(Validation)입니다. 이는 다음을 의미합니다:

• 스키마 강제 (Schema enforcement): 검증된 JSON (JSON)을 전달할 수 있다면 모델 간에 가공되지 않은 텍스트 (Raw text)를 전달하지 마세요. Pydantic, Zod 등 사용 중인 스택이 무엇이든 — 스키마를 명시적으로 만들고, 위반 시에는 즉시 오류를 발생시키도록 (fail loudly) 하세요.
• 신뢰도 점수 (Confidence scoring): 어떤 작업들은 모델에게 답변과 함께 신뢰도 점수를 출력하도록 요청할 가치가 있습니다. 임계값(Threshold) 미만일 경우, 폴백 (Fallback) 경로로 전환하거나 사람이 검토하도록 라우팅하세요.
• 교차 모델 감사 (Cross-model auditing): 가끔은 경량 모델 (Lightweight model)을 다른 모델의 출력물에 대한 비평가 (Critic)로 실행하세요. 완벽할 필요는 없습니다 — 조용히 전파되는 명백한 실패들을 잡아낼 수 있으면 됩니다.

이 중 어느 것도 지적으로 화려하지 않습니다. 이것은 배관 작업 (Plumbing)입니다. 하지만 이 배관 작업이 데모와 프로덕션 시스템 (Production system)을 가르는 차이입니다.

컨텍스트 스태킹 (Context Stacking)은 지연 시간과 비용의 가장 큰 적입니다

아무도 충분히 쓰지 않는 사실이 하나 있습니다: 모델을 체이닝 (Chaining)할 때, 각 단계는 컨텍스트 (Context)를 누적합니다. 복잡한 파이프라인의 4단계나 5단계에 이르면, 여러분은 엄청난 양의 토큰 페이로드 (Token payloads) — 즉, 원래의 입력값에 모든 중간 출력값까지 더해진 것 — 를 각 모델 호출 시마다 전달하게 됩니다. 비용은 복리로 늘어납니다. 지연 시간 (Latency)도 복리로 늘어납니다. 그리고 모델은 너무 많은 무관한 이력 (History)에 주의를 기울이게(Attending) 되면서 성능이 저하되기 시작합니다.

여기서 필요한 규율은 **각 전달 지점(Handoff)에서의 컨텍스트 압축 (Context compression)**입니다. 체인의 각 모델은 다음 모델이 필요로 하는 것만을 출력해야 합니다. 전체 추론 과정 (Reasoning trace)이 아닙니다. 내부의 연습장 (Scratchpad)도 아닙니다. 오직 작업을 계속하는 데 필요한 구조화된 출력 (Structured output)뿐입니다.

이것은 실제로 구축하기 전까지는 당연하게 들립니다. 하지만 막상 구축을 시작하면, 더 쉽고

새로운 파이프라인 (Pipeline)에서 첫 번째 프롬프트 (Prompt)를 작성하기 전에, 다음 질문들을 순서대로 검토하십시오:

1. 작업 분해 (Task decomposition)

• 원자적 하위 작업 (Atomic subtasks)은 무엇인가? 각 작업을 한 문장으로 설명할 수 있는가?
• 어떤 하위 작업이 서로 다른 역량 (검색 (Retrieval) vs 생성 (Generation) vs 분류 (Classification) vs 합성 (Synthesis))을 요구하는가?

2. 모델 선택 (Model selection)

• 각 하위 작업에 가장 적합한 모델은 무엇인가? 단순히 벤치마크 (Benchmark) 점수뿐만 아니라 비용, 지연 시간 (Latency), 정확도, 컨텍스트 윈도우 (Context window)를 고려하십시오.
• 출력 품질을 희생하지 않으면서 더 작고 저렴한 모델을 사용할 수 있는 곳은 어디인가?

3. 토폴로지 매핑 (Topology mapping)

• DAG (Directed Acyclic Graph, 유향 비순환 그래프)를 그리십시오. 어떤 단계가 순차적 (Sequential)이고, 어떤 단계가 병렬적 (Parallel)이며, 어떤 단계가 조건부 (Conditional)인가?
• 팬아웃 (Fan-out) 및 팬인 (Fan-in) 지점은 어디인가?

4. 핸드오프 계약 (Handoff contracts)

• 프롬프트를 작성하기 전에 모든 모델 간 페이로드 (Payload)에 대한 스키마 (Schema)를 정의하십시오.
• 각 단계가 다음 단계로 전달해야 하는 최소 실행 가능 출력 (Minimum viable output)은 무엇인가?

5. 실패 모드 (Failure modes)

• 다음 단계에서 감지하지 못하는 상태로 모델이 조용히 실패 (Silently fail)할 수 있는 지점은 어디인가?
• 각 핸드오프 (Handoff) 시점에서 어떤 검증 (Validation), 점수 산정 (Scoring), 또는 감사 (Auditing)가 이루어지는가?
• 단계가 실패하거나 신뢰도가 낮은 출력 (Low-confidence output)을 반환할 때의 폴백 (Fallback) 전략은 무엇인가?

6. 관측 가능성 (Observability)

• 잘못된 최종 출력이 발생했을 때, 이를 유발한 단계로 어떻게 추적 (Trace)할 것인가?
• 디버깅 (Debugging)을 가능하게 하기 위해 각 단계에서 무엇을 로그 (Log)로 남길 것인가?

구축을 시작하기 전에 이 여섯 가지 계층에 모두 답할 수 있다면, 디버깅에 소비하는 시간을 70% 줄일 수 있습니다. 만약 이를 건너뛴다면, 주말을 디버깅에 바치게 될 것입니다.

AI Handler가 이를 접근하는 방식

제가 AI Handler를 구축해 온 이유는 멀티 모델 오케스트레이션 (Multi-model orchestration)을 일급 시민 (First-class) 문제로 다루는 도구를 찾을 수 없었기 때문입니다. 제가 시도했던 모든 도구는 특정 제공업체 (Provider)에 종속시키거나, 그래프를 선형 체인 (Linear chain)으로 평탄화하거나, 혹은 너무 많은 추상화 (Abstraction)를 제공하여 디버깅이 고고학 발굴 수준이 되게 만들었습니다.

AI Handler는 위에서 설명한 토폴로지 우선(topology-first) 접근 방식을 중심으로 구축되었습니다. 여러분은 파이프라인을 그래프(Graph)로 정의합니다. 노드(Node)는 명시적인 스키마(Schema)를 가진 모델 호출이며, 엣지(Edge)는 타입이 지정된 핸드오프(Handoff)이고, 런타임(Runtime)은 여러분의 계약(Contract)을 강제합니다. 팬아웃(Fan-out)과 팬인(Fan-in)은 임시방편이 아닌 네이티브 프리미티브(Native primitives)로 제공됩니다. 모든 단계는 계측(Instrumented)되어 있어, 세 개의 서로 다른 서비스에서 로그를 읽지 않고도 실패의 원인을 발생 지점까지 추적할 수 있습니다.

검증 레이어(Validation layer)가 내장되어 있습니다. 핸드오프 시의 스키마 강제(Schema enforcement), 설정 가능한 신뢰도 임계값(Confidence thresholds), 그리고 파이프라인의 어떤 단계에도 연결할 수 있는 크리틱 모델(Critic-model) 패턴이 포함됩니다. 컨텍스트 압축(Context compression)은 런타임에서 처리됩니다. 여러분은 각 모델이 무엇을 받는지 전체를 정의하는 것이 아니라, 각 모델이 무엇을 출력(Emit)할지를 정의합니다.

제가 마주한 문제들이 모든 진지한 AI 개발자가 마주하는 문제라고 믿기 때문에, 저는 이 과정을 공개적으로(Building in public) 진행하고 있습니다. 그리고 그 해결책이 사적인 인프라 안에만 머물러서는 안 된다고 생각합니다. 도구(Tooling)는 존재해야 합니다.

AI Handler는 제가 만들고 있는 통합 AI 워크플로우(AI workflow) 도구입니다. 2026년 6월 출시 예정입니다. 베타 액세스 권한을 원하시면 ceo@eternalsix.com으로 이메일을 보내주세요.