24. 프롬프트 체이닝과 분해

5부는 단발 프롬프트를 넘어, 여러 단계·도구·역할이 얽히는 워크플로우를 다룹니다. 1~4부의 기법들이 더 큰 구조 안에서 결합되는 곳입니다.

한 번에 다 시키면 왜 약한가

복잡한 작업을 하나의 거대한 프롬프트에 다 담으면, 모델은 여러 가지를 동시에 신경 써야 합니다. 분석도 하고, 형식도 맞추고, 검증도 하고, 종합도 하고. 2·4장의 직관대로, 한 번에 너무 많은 것을 요구하면 attention이 분산되고 어느 하나도 충분히 못 하기 쉽습니다.

프롬프트 체이닝(prompt chaining)은 이를 쪼갭니다. 작업을 단계로 나누고, 한 단계의 출력을 다음 단계의 입력으로 넘기는 방식입니다. 각 단계는 한 가지에만 집중하므로 더 잘합니다.

flowchart LR
    in["입력"] --> s1["단계1<br/>추출"]
    s1 --> s2["단계2<br/>분석"]
    s2 --> s3["단계3<br/>초안"]
    s3 --> s4["단계4<br/>검토·다듬기"]
    s4 --> out["최종 출력"]

    classDef step fill:#dbeafe,stroke:#3b82f6,color:#1e3a8a
    classDef io fill:#fef9c3,stroke:#eab308,color:#713f12
    class s1,s2,s3,s4 step
    class in,out io

📌 핵심: 체이닝의 원리는 "한 단계 한 책임"입니다. 각 단계가 단순할수록 잘하고, 검증·디버깅도 쉬워집니다.

체이닝이 유리한 경우

체이닝 예시 — 긴 문서에서 보고서 만들기

[한 방에 ❌]
"이 30페이지 회의록 읽고 임원 보고서 만들어줘"
 → 추출·판단·작문·형식이 뒤섞여 품질 들쭉날쭉

[체이닝 ✅]
단계1: "이 회의록에서 '결정사항'만 빠짐없이 추출해 목록으로"
단계2: (단계1 결과를 입력) "이 결정사항들을 중요도순으로 정렬하고
        각각 한 줄 근거를 달아줘"
단계3: (단계2 결과를 입력) "이걸 임원 보고용 3문단으로 작성해줘"

각 단계의 출력을 눈으로 확인하고 다음으로 넘기므로, 어디서 틀어졌는지 바로 보입니다. 단계1에서 빠진 결정이 있으면 거기서 잡습니다.

💡 팁: 비개발자도 챗 인터페이스에서 체이닝을 할 수 있습니다. 한 번에 다 시키지 말고, 단계별로 대화를 이어가며 중간 결과를 확인하고 다음을 요청하면 됩니다. 단, 한 대화가 너무 길어지면 15장의 누적 문제가 생기니, 긴 체인은 단계별로 결과를 복사해 새 맥락에서 이어가는 것도 방법입니다.

분해의 기술 — 어떻게 쪼개나

좋은 분해의 핵심은 경계를 자연스러운 곳에 긋는 것입니다.

• 성격이 바뀌는 곳에서 끊기: 추출(사실)과 판단(해석)과 작문(표현)은 다른 작업
• 검증 지점에서 끊기: 다음으로 넘기기 전에 확인하고 싶은 곳
• 재사용 단위로 끊기: 여러 작업에 공통으로 쓰일 단계는 독립시키기

⚠️ 흔한 실수·미신: "무조건 잘게 쪼갤수록 좋다"는 아닙니다. 너무 잘게 나누면 단계 간 전달 비용·관리 부담이 늘고, 단계마다 맥락을 다시 줘야 해 오히려 비효율적일 수 있습니다. 모델이 한 번에 잘 처리하는 작업은 굳이 쪼개지 마세요. 쪼개는 기준은 "한 단계가 한 가지에 집중하는가 + 쪼개서 얻는 이득이 비용보다 큰가"입니다.

분기와 병렬 — 선형을 넘어서

체인이 항상 일직선일 필요는 없습니다.

• 분기: 단계1의 결과에 따라 다른 단계로 (예: 분류 결과가 '환불'이면 환불 처리 체인으로)
• 병렬: 독립적인 하위 작업을 따로 처리 후 합치기 (예: 문서 5개를 각각 요약 후 종합)

flowchart TB
    in["입력"] --> classify["분류"]
    classify -->|환불| r["환불 처리 체인"]
    classify -->|기술| t["기술지원 체인"]
    classify -->|기타| o["일반 응답 체인"]

    classDef step fill:#dbeafe,stroke:#3b82f6,color:#1e3a8a
    classDef io fill:#fef9c3,stroke:#eab308,color:#713f12
    class classify,r,t,o step
    class in io

🔧 개발자 노트: 체이닝은 코드로 오케스트레이션할 때 진가를 발휘합니다. 각 단계를 별도 API 호출로 만들고, 단계 사이에 검증·파싱·분기 로직을 넣습니다. 이때 13장의 컨텍스트 전략이 중요합니다 — 다음 단계에 이전 단계 전체가 아니라 필요한 출력만 넘겨 컨텍스트를 깨끗이 유지하세요(isolate). 또한 병렬 단계는 동시 호출로 지연을 줄일 수 있습니다. 단계가 많아지면 단순 체인을 넘어 "에이전트"(28장) 영역으로 이어지는데, 핵심 차이는 다음 단계를 사람이 미리 정하느냐(체인) vs 모델이 스스로 정하느냐(에이전트)입니다.

체이닝과 4부의 연결

체이닝은 4부의 신뢰성 기법과 잘 맞습니다. 단계를 나누면 각 단계를 따로 평가(23장)할 수 있고, 검증 단계를 명시적으로 끼워넣을 수 있습니다(20장). 예를 들어 마지막에 "검토 단계"를 두어 앞 단계 결과를 점검하게 하는 것은 체이닝과 자기 비판(25장)의 결합입니다.

🧪 직접 검증법: 자주 틀리는 복잡한 작업이 있다면, 그것을 2~3단계로 쪼개 각 단계를 따로 돌려보세요. 어느 단계에서 품질이 무너지는지 보일 겁니다. 그 단계만 집중해 고치면, 통짜 프롬프트를 막연히 손보는 것보다 훨씬 효율적입니다.

이 장에서 배운 것

• 프롬프트 체이닝은 복잡한 작업을 단계로 쪼개 한 단계의 출력을 다음 입력으로 넘기는 기법으로, "한 단계 한 책임"이 원리다.
• 단계 성격이 다르거나, 중간 검토가 필요하거나, 특정 단계가 자주 틀리거나, 긴 입력을 나눌 때 유리하다.
• 분해는 성격이 바뀌는 곳·검증 지점·재사용 단위에서 경계를 긋는다. 너무 잘게 쪼개면 전달·관리 비용이 늘어 역효과다.
• 체인은 분기·병렬로 확장할 수 있다. 다음 단계를 사람이 정하면 체인, 모델이 정하면 에이전트(28장)다.
• 단계 분리는 각 단계의 평가·검증을 쉽게 해 4부의 신뢰성 기법과 잘 결합된다.

✍️ 확인 문제

1. "이 고객 이메일들을 읽고 불만 유형을 분류한 뒤, 가장 많은 유형에 대한 개선안을 보고서로 써줘"를 체이닝으로 나눠보세요. 어디서 경계를 그을지와 이유를 적어보세요.

1. "무조건 잘게 쪼갤수록 좋다"가 틀린 이유를, 단계 간 전달 비용과 맥락 재공급 관점에서 설명해보세요.

1. (실습) 자주 하는 복잡한 작업 하나를 골라 3단계 체인으로 설계하고, 각 단계에서 다음으로 무엇만 넘길지(컨텍스트 정리)까지 적어보세요.

다음 → 25. 자기 비판과 자기 수정 유도
이전 ← 23. 평가(eval)의 기초 · 목차