Saram ConsultingCEO가 여러분에게 이렇게 지시합니다. “품질 이벤트를 검토하고 CAPA(시정 및 예방 조치)가 필요한지 여부를 알려주는 AI를 구축하십시오.”
주니어 엔지니어가 거대한 ’메가 프롬프트(mega-prompt)’를 작성합니다. 이 프롬프트는 단 한 번의 LLM 호출로 일탈 보고서(deviation report)에서 사실을 추출하고, 500개의 SOP(표준작업지침서)를 검색하며, GMP 절차를 해석하고, 환자 위험을 평가하고, CAPA 필요성을 판단하며, 시정 조치를 제안하고, 조사 보고서를 작성하고, 요약본(executive summary)을 작성하며, 감사 추적(audit trail)을 생성하고, 인용 목록까지 정리하도록 Claude에게 요구합니다.
결과는 실패입니다. Claude의 능력이 부족해서가 아닙니다. 정보 추출, 검색, 규제/법적 해석, 과학적 추론, 위험 평가, 계획 수립, 작성을 단 한 번의 모델 호출로 동시에 수행하도록 요구했기 때문입니다. 이것은 프롬프트의 문제가 아닙니다. 바로 아키텍처의 문제입니다.
해결책은 **분해(Decomposition)**입니다. 복잡하고 모호한 작업을 각각 검증 가능한 작고 결정론적(deterministic)이며 독립적으로 해결 가능한 하위 작업으로 체계적으로 쪼갠 뒤, 그 결과들을 다시 하나로 조합하는 것입니다.
이는 AI 아키텍처에서 가장 중요하게 다루어지는 핵심 개념입니다. 불안정한 데모 수준의 시스템과 실제 프로덕션 시스템을 가르는 결정적인 차이이기도 합니다.
핵심 원칙
Anthropic의 공식 가이드라인에서는 이를 명확하게 명시하고 있습니다:
단순하게 시작하고, 결과가 눈에 띄게 개선될 때에만 복잡성을 추가하며, 에이전트 설계에서 단순성을 유지하십시오.
분해(Decomposition)는 바로 이를 실현하는 방법입니다. 각 LLM 호출이 처리해야 하는 작업의 난이도를 낮춤으로써, 지연 시간(latency)과 비용을 정확도 및 신뢰성과 맞바꿉니다. 이를 통해 모든 단계가 극적으로 단순해지고, 테스트하기 쉬워지며, 감사가 가능해집니다.
반드시 알아야 할 5가지 패턴
이 5가지 패턴은 Anthropic의 Building Effective Agents(효과적인 에이전트 구축하기) 가이드에서 제시된 것입니다. 자격 시험이든 설계 검토(design review)든, 한눈에 이 패턴들을 구별할 수 있어야 합니다.
1. 프롬프트 체이닝(Prompt Chaining) — 순차적 분해
작업을 정해진 순서의 일련의 단계로 나눕니다. 각 LLM 호출은 이전 단계의 출력을 처리합니다. 각 단계 사이에는 추가적인 LLM 지시문이 아닌 프로그래밍 방식의 게이트(코드 기반 검증)를 삽입합니다.
마케팅 문구 작성 → 번역 → 규제 준수 검사(Compliance Check) → 서식 지정(Format)적용 시점: 작업 흐름이 예측 가능하고 반복적일 때 사용합니다. 작업을 시작하기 전에 수행해야 할 단계들을 이미 알고 있는 경우입니다.
핵심은 바로 ’게이트(Gate)’입니다. 시험에서는 “검증 단계를 어디에 추가해야 하는가?“라는 질문이 자주 출제됩니다. 그 정답은 거의 항상 체인의 각 단계 사이이며, 또 다른 LLM 지시문이 아닌 **결정론적인 코드(deterministic code)**로 검증하는 것입니다. 예를 들어 2단계에서 JSON을 생성했다면, 3단계로 넘기기 전에 코드로 스키마를 검증해야 합니다. 3단계 LLM에게 “입력값이 유효한지 확인하라”고 프롬프트로 요청해서는 안 됩니다.
트레이드오프: 지연 시간(latency)이 증가합니다. 체인의 각 연결 고리마다 모델과의 왕복 통신(round-trip)이 발생하기 때문입니다.
시험 출제 패턴: 개요 작성 → 기준 검사 → 문서 작성. 리서치 → 초안 작성 → 인용 검증. 추출 → 분류 → 라우팅.
2. 라우팅(Routing) — 분류 기반 분해
입력을 먼저 분류한 다음, 특화된 다운스트림 핸들러로 전달합니다. 각 핸들러는 고유한 프롬프트, 도구 세트, 그리고 경우에 따라 서로 다른 모델을 사용합니다.
고객 이메일 → 분류기(Classifier) → ┌→ 결제/청구 에이전트 (Billing Agent)
├→ 기술 지원 에이전트 (Technical Support Agent)
└→ 일반 문의 에이전트 (General Inquiry Agent)적용 시점: 입력이 이질적(heterogeneous)일 때 사용합니다. 뚜렷하게 구분되는 카테고리마다 근본적으로 다른 처리가 필요한 경우입니다.
비용 최적화 관점: 단순한 질문은 빠르고 저렴한 모델(Haiku)로 라우팅하고, 난이도 높은 복잡한 질문은 고성능 모델(Sonnet 또는 Opus)로 라우팅합니다. 이는 시험에 단골로 등장하는 시나리오입니다.
도구 과부하(Tool Overload) 해결: 등록된 도구가 50개 이상이어서 모델이 엉뚱한 도구를 계속 선택한다면, 해결책은 도구 설명을 더 정교하게 다듬는 것이 아닙니다. 라우팅과 **동적 도구 범위 지정(dynamic tool scoping)**을 결합하여, 각 전문 핸들러가 해당 도메인과 관련된 도구만 볼 수 있도록 제한해야 합니다.
3. 병렬화(Parallelization) — 데이터 및 역량 분해
여러 LLM 호출을 동시에 실행하고 그 결과를 프로그래밍 방식으로 취합(aggregate)합니다. 두 가지 방식이 있습니다:
구획화(Sectioning) — 하나의 작업을 독립적인 하위 작업들로 분할:
문서 → ┌→ 보안 스캐너 (읽기 전용 도구)
├→ 스타일 검사기 (읽기 전용 도구)
└→ 정확도 분석기 (읽기 전용 도구)
→ 결과 취합(Aggregate)투표(Voting) — 신뢰도를 높이기 위해 동일한 작업을 여러 번 독립적으로 실행:
코드 스니펫 → ┌→ 취약점 검토 #1
├→ 취약점 검토 #2
└→ 취약점 검토 #3
→ 다수결 / 임계값 합의(Consensus)적용 시점: 하위 작업들이 서로 독립적이어서 병렬로 실행할 수 있거나, 정확도를 위해 다각도의 관점이나 합의가 필요한 경우입니다.
숨겨진 이점: 컨텍스트 격리(Context isolation)입니다. 각 서브에이전트가 독립된 컨텍스트 윈도우를 갖습니다. 이를 통해 긴 문서를 단일 모델로 처리할 때 문서의 앞부분과 뒷부분에는 집중하지만 중간에 묻힌 정보를 놓치기 쉬운 ‘중간 유실(lost in the middle)’ 문제를 방지할 수 있습니다.
4. 오케스트레이터-워커(Orchestrator-Workers) — 동적 분해
전문가 자격 시험의 핵심 출제 주제입니다. 중앙 LLM(오케스트레이터)이 특정 입력에 기반하여 작업을 동적으로 분해하고, 하위 작업을 워커(Worker) LLM들에게 위임한 뒤, 그 결과를 종합(synthesize)합니다.
사용자 요청 → 오케스트레이터 (계획 모드)
├→ 워커 A: 인증 코드 검색
├→ 워커 B: DB 계층 검색
└→ 워커 C: UI 컴포넌트 검색
→ 종합(Synthesize) → 최종 결과물병렬화와의 핵심적인 차이: 하위 작업들이 사전에 정의되어 있지 않다는 점입니다. 오케스트레이터는 입력이 요구하는 바에 따라 런타임에 무엇을 위임할지 결정합니다. 병렬화가 고정적이고 경직된 반면, 오케스트레이터-워커 패턴은 유연합니다.
적용 시점: 사전에 하위 작업을 예측할 수 없을 때 사용합니다. 대표적인 예시로는 알 수 없는 파일들에 걸쳐 복잡한 변경을 수행해야 하는 코딩 에이전트, 여러 소스에서 정보를 수집하는 리서치 작업, 근본 원인이 어디에든 있을 수 있는 디버깅 세션 등이 있습니다.
시험 함정: 문제에서 “수정해야 할 파일의 수가 사용자 요청에 따라 달라진다”고 명시되어 있다면, 고정된 목록을 가진 병렬화를 선택하지 마십시오. 오케스트레이터-워커 패턴을 선택해야 합니다.
프로덕션 환경 구현: 오케스트레이터는 계획 모드(Plan Mode)를 갖춘 메인 에이전트 세션에 해당합니다. 워커는 독립된 컨텍스트 윈도우와 도구 세트를 가지고 생성되는 서브에이전트입니다. 파일 시스템이나 공유 상태(shared state)가 조율의 기반(substrate) 역할을 합니다.
5. 평가자-최적화자(Evaluator-Optimizer) — 반복적 분해
하나의 LLM이 결과물을 생성(Generate)하고, 다른 LLM이 명확한 기준에 따라 이를 평가(Evaluate)합니다. 결과물이 기준을 통과할 때까지 이 루프가 반복됩니다.
생성자(Generator) → 결과물 → 평가자(Evaluator) → 통과? → 최종 결과물
↑ │
└── 피드백(Feedback) ───────┘적용 시점: 잘 정의된 평가 기준이 존재하며, 반복적인 개선이 품질을 측정 가능하게 향상시킬 때 사용합니다. 대표적인 예시로는 문학 번역(평가자가 유창성과 정확성을 검증), 테스트 코드가 평가자 역할을 수행하는 코드 생성, 추가 검색이 필요한지 평가자가 판단하는 복잡한 리서치 등이 있습니다.
종료 조건(Stopping condition)이 핵심입니다. 임의의 반복 횟수 제한에만 의존하지 마십시오. 모델의 stop_reason(tool_use vs end_turn)을 검사하여 루프 종료 여부를 판별해야 합니다. 어시스턴트의 자연어 텍스트에서 신호를 파싱하는 방식은 취약하고 신뢰할 수 없습니다.
의사결정 프레임워크
새로운 시나리오를 마주할 때마다 다음 5가지 질문 체크리스트를 실행하십시오:
| 질문 | “예”인 경우 선택할 패턴 |
|---|---|
| 처리 단계가 사전에 알려져 있고 예측 가능한가? | 프롬프트 체이닝(Prompt Chaining) |
| 입력이 이질적이며 명확히 구분되는 카테고리가 있는가? | 라우팅(Routing) |
| 하위 작업들이 독립적이며 병렬 처리가 가능한가? | 병렬화(Parallelization) |
| 입력을 확인하기 전까지 하위 작업을 예측할 수 없는가? | 오케스트레이터-워커(Orchestrator-Workers) |
| 명확한 평가 기준이 있으며 반복적인 품질 개선이 가능한가? | 평가자-최적화자(Evaluator-Optimizer) |
대부분의 프로덕션 시스템은 여러 패턴을 결합하여 사용합니다. 대표적인 복합 아키텍처는 입력을 라우팅한 뒤 오케스트레이터-워커로 연결하고, 코드 생성 단계에서는 평가자-최적화자 루프를 적용하는 방식입니다.
하위 작업 간의 계약(Contract)
분해된 시스템이 가장 빈번하게 실패하는 지점이 바로 여기입니다. 시험과 실무 모두 확률적 해법보다 결정론적 해법을 우선시합니다:
자연어 설명이 아닌, 기계가 사용할 수 있는 ID 기반의 구조화된 출력. 도구 A가 도구 B를 호출해야 한다면, 도구 A는 URL이나 제목이 아니라 document_id를 반환해야 합니다. 이 패턴은 시험에서 반복적으로 출제됩니다.
각 하위 작업의 정의 요소: 목표(objectives), 출력 스키마(output schema), 사용 가능한 도구(available tools), 범위 경계(scope boundaries), 성공 기준(success criteria).
오케스트레이터는 전체 대화 기록이 아닌 요약본을 전달받아야 합니다. 워커의 장황한 출력은 관련성에 비해 토큰을 지나치게 많이 소모합니다. PostToolUse 훅을 사용하여 결과가 대화 기록에 들어가기 전에 불필요한 내용을 잘라내야(trim) 합니다.
출처 추적성(Provenance tracking): 정보를 성급하게 축약하지 말고 stated_value(진술된 값) + calculated_value(계산된 값) + source_location(출처 위치)을 함께 기록하십시오. 이는 디버깅, 평가, 그리고 규제 산업에서의 감사 추적(audit trail)을 강력하게 뒷받침합니다.
실패를 부르는 안티패턴
만능 에이전트(The God Agent)
하나의 에이전트. 50개의 도구. 전체 코드베이스에 대한 무제한 접근 권한. 모든 것을 한 번에 처리하려는 10,000토큰 규모의 메가 프롬프트.
실패하는 이유: 어텐션 희석(Attention dilution), 잘못된 도구 선택, 예측 불가능한 동작, 테스트 및 디버깅의 불가능.
해결책: 분해를 적용하고 도구의 범위를 동적으로 제한하십시오. 각 서브에이전트는 자신의 도메인에 관련된 도구만 볼 수 있어야 합니다.
과도한 분해(Over-Decomposition)
적절한 검색(Retrieval)이 보강된 단 한 번의 LLM 호출로도 충분히 해결할 수 있는 작업에 12개의 서브에이전트를 투입하는 경우.
실패하는 이유: 조율 비용(Coordination overhead)이 작업의 가치를 초과합니다. 컨텍스트가 단편화되고, 지연 시간이 폭증하며, 실제 작업보다 결과를 통합하는 데 더 많은 시간을 허비하게 됩니다.
해결책: 단순하게 시작하십시오. Anthropic의 원칙을 기억하십시오: 결과가 눈에 띄게 개선될 때에만 복잡성을 추가하십시오.
구조적 문제에 대한 프롬프트 만능주의(Prompt-Only Fix for a Structural Problem)
calculated_total 필드와 코드 검증 게이트를 추가하는 대신, 프롬프트에 “계산에 주의할 것”이라는 지시를 추가하는 경우.
실패하는 이유: LLM은 확률적(probabilistic) 모델입니다. “주의하라”고 당부한다고 해서 연산이 결정론적(deterministic)으로 바뀌지는 않습니다.
해결책: 체인 단계 사이에 구조화된 필드와 결정론적인 코드 게이트를 사용하십시오.
대규모 환경에서의 동기식 루프(Synchronous Loop at Scale)
반복적인 품질 개선이 필요하다는 이유로 50,000건의 문서를 동기식 평가자-최적화자 루프로 처리하는 경우.
실패하는 이유: 비용과 지연 시간이 폭발적으로 증가합니다. 요청 시간이 초과되거나 프로젝트 예산이 바닥날 것입니다.
해결책: 표본 샘플을 대상으로 대화형으로 프롬프트를 개선한 뒤, 전체 데이터셋에 대해서는 최적화된 프롬프트를 배치 API(Batch API)를 통해 일괄 배포하십시오.
지나치게 협소한 분해(Overly Narrow Decomposition)
오케스트레이터가 “창의 산업에 미치는 AI의 영향”이라는 주제를 디지털 아트, 그래픽 디자인, 사진의 세 가지로만 분해한 경우. 서브에이전트들은 완벽하게 임무를 완수했지만, 최종 보고서는 시각 예술 분야만 다루게 됩니다.
실패하는 이유: 코디네이터(오케스트레이터)의 분해가 지나치게 협소했습니다. 서브에이전트들은 제 역할을 다했지만, 아키텍처 자체가 실패를 야기한 것입니다.
해결책: 코디네이터가 전체 커버리지(포괄성)에 대한 책임을 집니다. 분해가 지나치게 협소했다면, 실패의 원인은 워커가 아니라 상류(upstream)인 오케스트레이터에 있습니다.
컨텍스트 관리: 논리적 분할을 넘어 분해해야 하는 이유
분해를 적용하는 이유는 단순한 논리적 분리 때문만은 아닙니다. 바로 컨텍스트 윈도우 경제성(Context window economics) 때문입니다.
도구 출력값은 매우 빠르게 누적됩니다. 만약 lookup_order가 40개의 필드를 반환하는데 필요한 것이 5개뿐이라면, 해당 결과가 대화 기록에 들어가기 전에 불필요한 데이터를 잘라내야 합니다.
스크래치패드(Scratchpad) 파일은 성능 저하를 방지합니다. 긴 세션 동안 에이전트는 핵심 발견 사항을 기록하는 스크래치패드 파일을 유지하고, 이후 질문에서 이를 참조하도록 해야 합니다.
서브에이전트 위임은 메인 컨텍스트를 보호합니다. 출력이 많은 탐색(discovery) 단계에서는 별도의 탐색용 서브에이전트를 생성하여 처리함으로써, 메인 에이전트가 고수준의 조율 컨텍스트를 온전히 유지할 수 있도록 하십시오.
‘중간 유실(lost in the middle)’ 현상은 실재합니다. Claude는 긴 입력의 시작과 끝 부분은 신뢰도 높게 처리하지만, 중간에 묻힌 정보는 놓칠 수 있습니다. 분해는 긴 문서를 집중 분석 가능한 섹션들로 나누어 병렬로 분석함으로써 이 문제를 직접적으로 해결합니다.
생명과학 실전 사례: 일탈(Deviation) 조사
단일 “일탈 조사관(Deviation Investigator)” 에이전트를 두는 대신, 특화된 추론 단계들로 분해합니다:
| 단계 | 담당 역할(Responsibility) | 입력(Inputs) | 출력(Outputs) |
|---|---|---|---|
| 1 | 사실 추출 (Fact extraction) | 일탈 보고서 | 구조화된 사실 데이터 |
| 2 | 타임라인 재구성 (Timeline reconstruction) | 사실 + 시스템 로그 | 이벤트 발생 순서 |
| 3 | 문서 검색 (Document retrieval) | 사실 | 관련 SOP, 배치 제조 기록서 |
| 4 | 규제 준수 분석 (Compliance analysis) | 사실 + SOP | 절차상 일탈 사항 |
| 5 | 과학적 평가 (Scientific assessment) | 사실 + 제조 공정 맥락 | 기술적 가설 |
| 6 | 근본 원인 분석 (Root cause analysis) | 이전 단계 출력물 | 우선순위화된 근본 원인 |
| 7 | 위험 평가 (Risk assessment) | 근본 원인 | 환자/의약품 위험도 |
| 8 | CAPA 권고 (CAPA recommendation) | 위험 평가 결과 | 제안된 CAPA |
| 9 | 증거 검증 (Evidence verification) | 모든 이전 단계 출력물 | 추적성 보고서 |
| 10 | 인간 검토 패키지 (Human review package) | 검증된 출력물 | 감사 대응 문서철(Dossier) |
이러한 아키텍처는 규제 기관의 기대치와 자연스럽게 부합합니다. 모든 결론은 구체적인 증거로 역추적(traceable)할 수 있습니다. 각 단계는 독립적으로 밸리데이션(검증)될 수 있습니다. 정해진 통제 지점(control point)에서 인간의 검토가 이루어집니다. 사후에 억지로 덧붙이는 것이 아니라, 아키텍처 구조 자체에 의해 감사 추적(audit trail)이 자동으로 생성됩니다.
분해가 항상 정답은 아닙니다
**단순하고 단발적인 작업(Single-shot tasks)**에는 분해가 필요하지 않습니다. 잘 작성된 단일 프롬프트로 작업을 안정적으로 처리할 수 있다면, 여기에 오케스트레이션을 추가하는 것은 비용, 지연 시간, 장애 발생 표면(failure surface)만 늘릴 뿐입니다.
잘 구조화된 모듈형 시스템에서도 과도한 분해가 일어날 수 있습니다. 단일 트랜잭션을 완료하기 위해 서비스를 쪼개다 보니 5번의 네트워크 호출이 필요해졌다면, 분산의 이점은 전혀 누리지 못한 채 복잡성만 떠안은 ’분산 모놀리스(distributed monolith)’를 만든 셈입니다.
단순하게 시작하십시오. Anthropic의 핵심 원칙을 상기하십시오. 결과가 실질적으로 개선될 때에만 복잡성을 추가해야 합니다.
핵심 결론
분해(Decomposition)는 기교 넘치는 단일 프롬프트를 작성하는 프롬프트 엔지니어에서, 복원력 있는 분산 AI 시스템을 설계하는 진정한 아키텍트로 거듭나는 핵심 도약점입니다.
복잡한 작업을 마주했을 때 여러분의 첫 번째 직관은 항상 다음과 같아야 합니다: 이 작업을 어떻게 더 작고, 검증 가능하며, 반복 가능한 단계들로 쪼갤 것인가?
문제의 구조에 맞는 패턴을 선택하십시오. 고정된 단계에는 체이닝, 미지의 단계에는 오케스트레이터-워커, 다양한 입력에는 라우팅, 정확도가 결정적인 작업에는 투표, 반복적인 품질 개선에는 평가자-최적화자를 적용합니다. 각 단계 사이에는 구조화된 계약(Contract)을 정의하십시오. 실패의 대가가 큰 중요한 지점에는 결정론적 게이트를 추가하십시오. 컨텍스트는 누적이 아니라 격리를 통해 보존하십시오.
흐름도를 직접 그리고, 각 패턴을 선택한 이유를 설명하며, 검증이 들어가야 할 위치를 정확히 짚어낼 수 있다면, 여러분은 프로덕션 AI 아키텍처가 요구하는 핵심 역량을 이미 체화한 것입니다.