2부 6장. 프롬프트 체이닝: 단계를 나누면 왜 강해지는가

한 번에 다 시키면 왜 자꾸 흔들릴까

처음 에이전트를 만들 때 많은 사람이 이렇게 생각한다. "모델이 똑똑한데, 그냥 한 번에 길고 자세하게 시키면 되지 않을까?" 그래서 요구사항을 길게 적고, 원하는 형식도 적고, 주의사항도 적고, 검토 기준도 적고, 마지막에는 톤앤매너까지 덧붙인다. 그러면 프롬프트는 점점 비대해지고, 기대는 오히려 불안정해진다.

이유는 단순하다. 한 번의 호출 안에 너무 많은 일을 넣으면 모델은 동시에 여러 목표를 만족해야 한다. 내용을 만들어야 하고, 형식을 맞춰야 하고, 사실관계를 조심해야 하고, 빠진 항목도 점검해야 하고, 마지막에는 읽기 좋게 다듬기까지 해야 한다. 사람에게도 버거운 일인데, 모델이라고 해서 언제나 완벽하게 해내지는 못한다.

프롬프트 체이닝은 이 문제를 정면으로 다루는 방법이다. 하나의 거대한 지시를 작은 단계들로 나누고, 각 단계가 한 가지 역할에 집중하도록 설계하는 방식이다. 쉽게 말해 "한 번에 다 잘하라"가 아니라 "순서대로 하나씩 잘하라"로 바꾸는 것이다.

이 차이는 생각보다 크다. 거대한 프롬프트는 겉으로는 단순해 보여도 내부에서는 여러 작업이 뒤엉켜 있다. 반면 체이닝은 작업을 분해한다. 생성은 생성답게, 검토는 검토답게, 정제는 정제답게 맡긴다. 그러면 결과물의 품질뿐 아니라, 왜 그런 결과가 나왔는지 이해하기도 쉬워진다.

프롬프트 체이닝이란 무엇인가

프롬프트 체이닝은 여러 번의 모델 호출을 연결해 하나의 작업을 수행하는 설계 방식이다. 앞 단계의 출력이 다음 단계의 입력이 된다. 중요한 것은 단순히 호출 횟수를 늘리는 것이 아니라, 각 단계를 서로 다른 목적에 맞게 분리하는 데 있다.

예를 들어 블로그 글을 작성하는 작업이 있다고 해보자. 한 번에 "주제 조사, 구조 설계, 초안 작성, 사실 확인, 문장 다듬기까지 해줘"라고 시킬 수도 있다. 하지만 체이닝 방식이라면 먼저 독자와 목적을 정리하고, 다음에 개요를 만들고, 그다음 초안을 쓰고, 이후 검토 단계에서 빠진 논점을 찾고, 마지막으로 문장을 다듬는다. 겉으로 보기엔 번거로워 보이지만, 실전에서는 이 편이 훨씬 강하다.

프롬프트 체이닝은 에이전트가 복잡한 일을 더 안정적으로 수행하도록 돕는 가장 기본적인 패턴 중 하나다. 거창한 멀티에이전트 구조나 복잡한 도구 연결이 없어도, 단계만 잘 나눠도 성능과 통제 가능성이 크게 달라진다.

왜 작은 단계들의 조합이 더 강한가

가장 큰 이유는 한 단계의 목표가 분명해지기 때문이다. 목표가 분명하면 평가 기준도 분명해진다. 평가 기준이 분명하면 실패를 발견하고 고치기 쉬워진다. 결국 체이닝의 힘은 "잘 만들기" 이전에 "잘 관리하기"에서 나온다.

첫째, 인지 부담이 줄어든다. 모델은 한 번의 호출에서 너무 많은 제약을 동시에 처리할 때 흔들린다. 작업을 나누면 매 단계가 집중해야 할 판단의 종류가 줄어든다. 예를 들어 초안 작성 단계에서는 창의성과 구조가 중요하고, 검토 단계에서는 누락과 오류 탐지가 중요하다. 이 둘을 한 번에 하게 하면 어느 하나가 희생되기 쉽다.

둘째, 중간 산출물을 확인할 수 있다. 거대한 프롬프트는 결과가 마음에 들지 않을 때 어디서 문제가 생겼는지 알기 어렵다. 개요가 잘못된 것인지, 초안이 산만한 것인지, 검토가 느슨한 것인지 구분이 안 된다. 하지만 단계가 나뉘어 있으면 중간 결과를 보고 어느 지점에서 틀어졌는지 바로 찾을 수 있다.

셋째, 수정 비용이 낮아진다. 마지막 결과만 보고 전체를 다시 생성하는 대신, 문제가 있는 단계만 재실행하면 된다. 개요가 좋지 않다면 개요 단계만 다시 돌리고, 문장 톤이 어색하다면 정제 단계만 다시 수행하면 된다. 시스템은 더 유연해지고 비용 통제도 쉬워진다.

넷째, 역할 분리가 가능해진다. 생성에 강한 프롬프트와 비판에 강한 프롬프트는 다르다. 어떤 단계는 넓게 발산해야 하고, 어떤 단계는 엄격하게 수렴해야 한다. 체이닝은 각 단계에 맞는 프롬프트와 모델 설정을 따로 줄 수 있게 해준다.

생성, 검토, 정제: 가장 기본적인 3단 분리

실무에서 가장 자주 쓰이는 체이닝은 생성, 검토, 정제의 3단 구조다. 단순하지만 매우 강력하다.

생성 단계에서는 일단 내용을 만든다. 여기서는 지나치게 완벽하려고 하지 않는 편이 좋다. 핵심은 뼈대를 세우고 초안을 내놓는 것이다. 이 단계에 검토 기준까지 과하게 밀어 넣으면 초안이 오히려 경직될 수 있다.

검토 단계에서는 다른 시선으로 초안을 본다. 빠진 내용은 없는지, 요구사항을 제대로 반영했는지, 논리 흐름에 구멍은 없는지, 근거 없는 단정은 없는지 살핀다. 중요한 점은 검토 단계가 곧바로 새 글을 쓰는 단계가 아니라는 것이다. 먼저 무엇이 문제인지 식별하는 데 집중해야 한다.

정제 단계에서는 검토 결과를 반영해 결과물을 다듬는다. 문장을 더 읽기 쉽게 만들고, 형식을 정돈하고, 중복을 줄이고, 어색한 표현을 고친다. 이때는 이미 초안과 검토 의견이 있으므로, 모델은 훨씬 구체적인 수정 지시를 따를 수 있다.

이 구조의 장점은 역할이 명확하다는 데 있다. 생성 단계는 "무엇을 말할까"에 집중하고, 검토 단계는 "무엇이 빠졌거나 틀렸나"에 집중하며, 정제 단계는 "어떻게 더 잘 읽히게 만들까"에 집중한다. 한 번에 다 시킬 때보다 훨씬 안정적이다.

하나의 거대한 프롬프트와 무엇이 다른가

겉으로 보면 둘 다 결국 모델에게 글을 만들어 달라고 하는 것처럼 보일 수 있다. 하지만 내부 구조는 크게 다르다.

하나의 거대한 프롬프트는 모든 요구를 동시에 넣는다. 그래서 모델은 생성과 검토와 수정을 한 호흡에 수행해야 한다. 이 방식은 운이 좋으면 빠르게 괜찮은 결과가 나오지만, 실패했을 때 원인을 분석하기 어렵다. 왜냐하면 내부 과정이 드러나지 않기 때문이다.

반면 프롬프트 체이닝은 과정을 외부로 꺼낸다. 개요가 먼저 있고, 초안이 있고, 검토 결과가 있고, 최종 수정본이 있다. 이 구조는 품질을 올리는 데도 좋지만, 운영과 디버깅에 특히 강하다. 에이전트 시스템은 결국 제품이기 때문에, 잘 되는 순간보다 잘 안 되는 순간을 다루는 능력이 더 중요하다.

또 하나의 차이는 제어 가능성이다. 거대한 프롬프트에서는 모델이 검토를 충분히 하지 않았는지, 형식 지시를 일부 놓쳤는지 알아차리기 어렵다. 체이닝에서는 각 단계의 출력 형식을 제한할 수 있다. 예를 들어 검토 단계는 반드시 "문제 목록"만 출력하게 하고, 정제 단계는 그 목록을 하나씩 반영하게 만들 수 있다. 즉, 추상적인 부탁이 구체적인 절차로 바뀐다.

체이닝이 품질을 높이는 방식

프롬프트 체이닝이 품질을 높인다고 할 때, 그것은 단지 "더 좋아 보이는 문장"을 뜻하지 않는다. 실전에서 말하는 품질은 여러 층으로 이루어져 있다.

• 요구사항 충족도: 사용자가 부탁한 조건을 얼마나 빠짐없이 반영했는가

• 논리적 일관성: 앞뒤가 맞고, 구조가 자연스럽게 이어지는가

• 오류 감소: 사실 착오, 형식 실수, 누락이 줄어드는가

• 재현 가능성: 비슷한 입력에서 비슷한 수준의 결과를 안정적으로 내는가

체이닝은 이 네 가지를 동시에 개선하기 쉽다. 생성 단계는 아이디어를 만들고, 검토 단계는 요구사항 대비 누락을 찾고, 정제 단계는 표현의 완성도를 끌어올린다. 즉, 품질의 서로 다른 층을 각 단계가 나눠서 담당한다.

예를 들어 고객 문의에 대한 답변을 작성한다고 해보자. 한 번에 응답을 생성하면 정중한 문체는 맞췄지만 정책 조항 하나를 빠뜨릴 수 있다. 반대로 정책을 지나치게 강조하면 말투가 딱딱해질 수 있다. 체이닝을 쓰면 먼저 정책에 맞는 답변 초안을 만들고, 다음 단계에서 누락된 정책 항목을 검토하고, 마지막 단계에서 고객이 읽기 편하게 표현을 다듬을 수 있다. 결과적으로 답변은 더 정확하고 더 친절해진다.

체이닝이 통제 가능성을 높이는 이유

좋은 시스템은 똑똑하기만 한 시스템이 아니다. 예측 가능해야 하고, 수정 가능해야 하며, 문제가 생겼을 때 손댈 곳이 보여야 한다. 프롬프트 체이닝은 바로 이 통제 가능성을 키워준다.

가장 먼저 얻는 것은 관찰 가능성이다. 중간 단계가 있으면 시스템 내부에서 무슨 일이 일어났는지 볼 수 있다. 개요 단계가 엉성했는지, 검토 단계가 너무 관대했는지, 정제 단계가 원문 의미를 훼손했는지 확인할 수 있다.

다음으로 얻는 것은 부분 교체 가능성이다. 전체 시스템을 갈아엎지 않아도 검토 프롬프트만 강화하거나, 정제 단계에 더 작은 모델을 쓰거나, 특정 작업에서만 단계 수를 늘릴 수 있다. 시스템이 모듈처럼 다뤄진다.

마지막으로 얻는 것은 정책 주입의 용이성이다. 예를 들어 민감한 도메인에서는 생성 단계보다 검토 단계에 규정 체크를 넣는 편이 더 효과적일 수 있다. 어떤 제약은 창의적 발산을 막지 않도록 뒤 단계에 넣는 것이 낫고, 어떤 제약은 처음부터 강하게 걸어야 한다. 체이닝은 이런 선택을 가능하게 한다.

언제 단계 분리가 특히 효과적인가

모든 작업에 체이닝이 필요한 것은 아니다. 하지만 어떤 작업에서는 효과가 매우 크다.

첫째, 출력 품질 기준이 여러 개인 경우다. 내용, 형식, 톤, 정확성, 금칙어, 길이 제한이 한꺼번에 걸린 작업은 단일 프롬프트보다 단계 분리가 유리하다.

둘째, 중간 판단이 중요한 경우다. 예를 들어 긴 문서를 요약할 때는 먼저 핵심 포인트를 추출하고, 그다음 요약을 만드는 편이 안정적이다. 바로 요약만 시키면 중요한 세부 사항이 사라질 수 있다.

셋째, 실패 비용이 큰 경우다. 고객 응대, 내부 보고서, 코드 수정 제안, 정책 반영 문서처럼 틀렸을 때 부담이 큰 작업은 검토 단계를 따로 두는 것이 안전하다.

넷째, 결과를 반복 개선해야 하는 경우다. 한 번에 완성본을 뽑기보다 초안→피드백→수정 구조가 자연스러운 작업이라면 체이닝이 잘 맞는다.

대표적인 체이닝 패턴들

프롬프트 체이닝은 생성-검토-정제 말고도 다양한 형태로 쓸 수 있다. 실제로는 작업의 성격에 따라 단계 이름과 목적이 달라진다.

• 분석 → 계획 → 실행

• 추출 → 정리 → 요약

• 분류 → 라우팅 → 처리

• 초안 작성 → 규정 검토 → 사용자 친화적 수정

• 아이디어 발산 → 후보 평가 → 최종 선택

핵심은 늘 같다. 서로 다른 종류의 판단을 한 단계에 몰아넣지 않는 것이다. 모델이 잘해야 할 일이 많아질수록, 오히려 일을 나누는 편이 더 똑똑해진다.

예시 1: 고객 문의 답변 시스템

고객이 환불 정책을 묻는 문의를 보냈다고 해보자. 단일 프롬프트 방식이라면 문의 내용을 넣고 바로 답변을 생성하게 만들 수 있다. 이 방식은 빠르지만, 환불 가능 조건이나 예외 조항을 빼먹을 위험이 있다.

체이닝 방식은 이렇게 설계할 수 있다.

먼저 1단계에서 문의 의도를 분석한다. 사용자가 묻는 것이 단순 환불인지, 배송 지연에 따른 보상인지, 상품 하자에 대한 교환인지 구분한다. 2단계에서는 해당 의도에 맞는 정책 조항을 추출한다. 3단계에서는 정책을 바탕으로 답변 초안을 쓴다. 4단계에서는 초안이 정책과 일치하는지 검토한다. 5단계에서는 고객이 읽기 쉽게 말투를 다듬는다.

이 구조의 장점은 분명하다. 의도 분류가 틀리면 그 단계만 고치면 되고, 정책 추출이 부정확하면 그 부분만 개선하면 된다. 답변 품질은 물론, 운영자가 손댈 수 있는 지점도 많아진다.

예시 2: 긴 문서 요약 시스템

긴 회의록이나 리서치 문서를 요약할 때 바로 "세 줄로 요약해줘"라고 하면, 중요한 부분이 누락되거나 지나치게 일반적인 요약이 나올 수 있다. 사람도 긴 글을 읽고 바로 좋은 요약을 쓰기보다, 먼저 메모를 하고 구조를 잡은 뒤 정리한다.

체이닝은 이런 인간의 작업 습관과 닮아 있다. 먼저 문서를 구간별로 나눠 핵심 포인트를 추출하고, 다음 단계에서 포인트를 묶어 상위 주제로 정리한 뒤, 마지막에 독자 수준에 맞는 요약문으로 변환한다. 이렇게 하면 세부 정보와 전체 구조를 동시에 챙기기 쉬워진다.

특히 입력이 길수록 중간 표현이 중요해진다. 한 번에 요약하라고 하면 모델은 전체를 뭉뚱그려 처리하려고 하지만, 단계가 있으면 부분 이해와 전체 정리가 분리된다. 그래서 더 안정적인 요약이 가능해진다.

예시 3: 코드 생성보다 코드 수정에서 더 강하다

프롬프트 체이닝은 글쓰기뿐 아니라 코드 작업에서도 유용하다. 특히 기존 코드를 바꾸는 작업에서 효과가 크다. 이유는 수정 작업이 단순 생성이 아니라 이해, 계획, 변경, 검증의 연속이기 때문이다.

예를 들어 버그 수정 요청이 들어왔다고 하자. 바로 패치를 생성하기보다, 먼저 문제를 재진술하게 하고, 다음 단계에서 원인 후보를 정리하고, 그다음 수정 계획을 세운 뒤, 마지막에 실제 코드를 바꾸게 할 수 있다. 이후 테스트 관점의 검토 단계까지 붙이면 더 좋다.

이렇게 하면 모델이 "일단 그럴듯한 코드"를 내놓는 대신, 왜 이 변경이 필요한지 설명 가능한 흐름이 생긴다. 실무에서는 바로 이 설명 가능성이 매우 중요하다. 잘 고치는 것도 중요하지만, 왜 그렇게 고쳤는지 팀이 이해할 수 있어야 하기 때문이다.

단계는 많이 나눌수록 좋은가

여기서 흔한 오해가 하나 있다. 단계를 나누는 것이 좋다면, 최대한 잘게 쪼개는 것이 최고일까? 꼭 그렇지는 않다.

단계가 너무 많아지면 오히려 새로운 문제가 생긴다. 지연 시간이 늘어나고, 비용이 커지고, 각 단계 사이에 의미가 조금씩 손실될 수 있다. 무엇보다 시스템이 복잡해지면서 관리 포인트가 많아진다. 작은 계단은 오르기 쉽지만, 계단이 너무 많으면 피곤해지는 것과 비슷하다.

좋은 체이닝은 "최소한의 분리"를 목표로 해야 한다. 즉, 서로 다른 판단 종류가 충돌하는 지점만 나누면 된다. 생성과 검토가 서로 방해한다면 분리하고, 추출과 요약이 섞여 누락이 생긴다면 분리하는 식이다. 반대로 한 단계 안에서 충분히 안정적으로 처리되는 일이라면 굳이 쪼갤 필요가 없다.

실전에서는 보통 2단계에서 5단계 사이가 가장 다루기 좋다. 물론 작업 성격에 따라 다르지만, 대부분의 서비스는 이 범위 안에서 큰 효과를 얻는다.

좋은 체이닝을 설계하는 기준

프롬프트 체이닝은 단순히 단계를 늘리는 기술이 아니다. 어떤 경계로 나누는지가 핵심이다. 잘 나눈 체인은 각 단계의 책임이 명확하고, 입력과 출력이 분명하다.

첫 번째 기준은 단계의 목표가 하나인지 보는 것이다. 한 단계가 동시에 분류도 하고, 생성도 하고, 검토도 하려 한다면 다시 나누는 편이 낫다.

두 번째 기준은 출력이 다음 단계에 바로 쓰일 수 있는지 보는 것이다. 중간 결과가 애매하면 체인이 약해진다. 예를 들어 검토 단계는 막연한 감상이 아니라 수정 가능한 지적 사항을 내놓아야 한다.

세 번째 기준은 실패했을 때 복구가 쉬운지 보는 것이다. 어느 단계가 틀렸는지 찾기 어렵다면 체인 설계가 불투명한 것이다. 좋은 체인은 실패 지점이 잘 드러난다.

네 번째 기준은 단계별 모델 설정을 다르게 가져갈 수 있는지 보는 것이다. 어떤 단계는 창의성이 필요하고, 어떤 단계는 보수성이 필요하다. 체이닝은 이 차이를 활용할 수 있을 때 더 강해진다.

중간 출력은 가능한 한 구조화하라

체이닝에서 자주 놓치는 부분이 중간 산출물의 형식이다. 앞 단계 출력이 자유로운 산문 형태면, 다음 단계가 그것을 잘못 해석할 가능성이 높아진다. 반대로 핵심 항목이 구조화되어 있으면 체인이 훨씬 안정된다.

예를 들어 검토 단계는 "전체적으로 괜찮지만 조금 더 다듬으면 좋겠다" 같은 말을 하는 대신, 누락 사항, 사실 의심 지점, 형식 위반, 수정 제안으로 나눠 출력하는 편이 좋다. 그러면 정제 단계가 무엇을 어떻게 반영해야 하는지 명확해진다.

중간 출력이 잘 구조화되면 사람도 읽기 쉬워진다. 즉, 기계와 인간 모두에게 좋은 인터페이스가 된다. 에이전트 시스템은 결국 사람이 운영하는 시스템이므로, 이 점은 생각보다 중요하다.

체이닝과 상태 관리의 만남

프롬프트 체이닝은 단지 프롬프트의 문제만이 아니다. 상태를 어떻게 넘길 것인가의 문제이기도 하다. 앞 단계의 전체 출력을 다음 단계에 그대로 넘길지, 필요한 정보만 추려 넘길지에 따라 성능과 비용이 달라진다.

모든 중간 결과를 다 넣으면 컨텍스트가 길어지고 잡음도 늘어난다. 반대로 너무 요약해서 넘기면 중요한 뉘앙스가 사라질 수 있다. 그래서 체이닝을 설계할 때는 "다음 단계가 정말로 알아야 할 정보가 무엇인가"를 계속 물어야 한다.

예를 들어 검토 단계에는 최종 스타일 가이드보다 초안과 요구사항이 더 중요할 수 있다. 정제 단계에는 검토 결과와 수정 대상 문장이 중요하고, 초기 아이디어 발산 과정은 필요 없을 수 있다. 필요한 맥락만 넘기는 것이 좋은 체인의 핵심이다.

체이닝은 평가와도 잘 맞는다

프롬프트 체이닝의 큰 장점 중 하나는 평가가 쉬워진다는 점이다. 단일 프롬프트 시스템은 결과가 나쁘면 왜 나빴는지 알기 어렵다. 하지만 단계가 분리되어 있으면 각 단계별 품질을 따로 볼 수 있다.

개요 단계의 완성도를 평가하고, 초안 단계의 누락률을 보고, 검토 단계의 탐지율을 측정할 수 있다. 즉, 최종 결과 하나만 보는 대신, 시스템의 내부 성능을 나눠서 볼 수 있다. 이것은 운영 가능한 제품을 만드는 데 결정적으로 중요하다.

또한 어느 단계에 투자를 해야 효과가 큰지도 알 수 있다. 초안은 괜찮은데 검토가 약하면 검토 프롬프트를 개선하면 되고, 검토는 날카로운데 정제 단계가 원문을 망친다면 정제 단계를 바꾸면 된다. 문제를 정밀하게 수리할 수 있다.

체이닝의 한계도 분명하다

프롬프트 체이닝이 만능은 아니다. 우선 호출 수가 늘어나므로 지연 시간과 비용이 증가한다. 사용자가 즉시 답을 원하고, 작업 자체가 단순하다면 체이닝은 과할 수 있다.

또 중간 단계가 잘못되면 그 오류가 뒤 단계로 전달될 수 있다. 특히 초기 단계에서 잘못된 분류나 잘못된 요약이 발생하면 이후 단계가 그것을 사실처럼 받아들일 수 있다. 체이닝은 과정을 나누어 주지만, 각 단계의 품질이 자동으로 보장되는 것은 아니다.

게다가 단계가 늘수록 설계자가 책임져야 할 것이 많아진다. 어느 단계에서 어떤 형식을 쓰고, 어떤 정보를 넘기고, 실패 시 어떻게 재시도할지 정해야 한다. 즉, 단순한 데모는 더 빠르게 만들 수 있어도, 설계 감각이 부족하면 오히려 복잡한 시스템이 되기 쉽다.

그래서 체이닝의 목적은 "복잡하게 만들기"가 아니라 "복잡한 일을 다룰 수 있게 만들기"여야 한다. 둘은 비슷해 보이지만 완전히 다르다.

실전에서 자주 하는 실수

프롬프트 체이닝을 도입할 때 흔히 겪는 실수도 있다.

• 단계를 나눴지만 각 단계의 역할이 여전히 겹친다

• 중간 출력 형식이 애매해서 다음 단계가 흔들린다

• 모든 중간 결과를 무조건 넘겨 컨텍스트가 비대해진다

• 검토 단계가 비판만 하고 수정 가능한 지시를 주지 않는다

• 단계 수만 늘리고 실제 품질 개선은 측정하지 않는다

특히 마지막 실수가 많다. 체이닝은 좋아 보이기 쉽다. 하지만 실제로는 단일 프롬프트보다 조금 나아진 것인지, 비용 대비 효과가 있는지, 어떤 작업에서만 유리한지 측정해야 한다. 설계는 감으로 시작할 수 있어도, 운영은 숫자로 확인해야 한다.

단일 프롬프트에서 체이닝으로 넘어가는 실용적 방법

처음부터 완벽한 체인을 설계할 필요는 없다. 오히려 단일 프롬프트가 이미 있는 상태에서 가장 큰 충돌 지점 하나만 떼어내는 방식이 현실적이다.

예를 들어 결과는 그럴듯한데 요구사항 누락이 잦다면, 생성 뒤에 검토 단계 하나만 붙여도 된다. 문장은 괜찮은데 형식이 자꾸 흔들린다면, 마지막에 정제 단계만 추가해도 효과가 있다. 즉, 체이닝은 전면 재설계가 아니라 점진적 분해로 도입하는 편이 좋다.

좋은 출발점은 "모델이 한 번에 하라고 하면 자주 놓치는 일"을 찾는 것이다. 빠진 항목 점검, 형식 일치 확인, 정책 준수 검토, 요점 정리 같은 것들이 여기에 해당한다. 그런 역할은 대개 별도 단계로 분리했을 때 성과가 잘 나온다.

결국 체이닝은 사고를 절차로 바꾸는 일이다

사람이 어려운 일을 잘 풀 때를 떠올려보자. 바로 정답을 쓰기보다 먼저 문제를 이해하고, 계획을 세우고, 초안을 만들고, 검토하고, 다시 고친다. 프롬프트 체이닝은 이런 인간의 작업 방식을 시스템 설계로 옮겨 놓은 것이다.

중요한 것은 모델을 믿지 말라는 뜻이 아니다. 오히려 모델을 더 잘 활용하자는 뜻에 가깝다. 한 번에 모든 역할을 떠맡기기보다, 역할을 나눠 각 단계에서 강점을 발휘하게 만드는 것이다. 그래서 체이닝은 모델의 한계를 보완하는 기술이면서 동시에 모델의 장점을 확대하는 기술이다.

단일 프롬프트는 빠른 출발에 좋다. 하지만 시스템이 조금만 복잡해져도 통제와 품질의 문제가 드러난다. 이때 프롬프트 체이닝은 단순한 꼼수가 아니라, 에이전트를 설계 가능한 구조로 바꾸는 첫걸음이 된다.

다음 단계로 가기 위한 감각

이 장의 핵심은 단순하다. 에이전트가 복잡한 일을 하게 만들고 싶다면, 먼저 일을 나누는 법부터 배워야 한다는 것이다. 좋은 체이닝은 모델을 더 똑똑하게 만드는 마법이 아니다. 대신 작업을 더 선명하게 만들고, 실패를 더 잘 보이게 만들고, 결과를 더 다루기 쉽게 만든다.

실전에서 강한 시스템은 대개 한 번에 모든 것을 해결하려 하지 않는다. 작은 단계들이 각자 자기 일을 하고, 그 결과가 다음 단계로 자연스럽게 이어진다. 마치 잘 짜인 릴레이처럼, 바통이 흔들리지 않을수록 마지막 주자의 기록도 좋아진다.

다음 장에서는 이 생각을 한 단계 더 확장해본다. 작업을 순서대로만 나누는 것이 아니라, 요청의 성격에 따라 다른 경로로 보내고, 가능한 일은 동시에 처리하는 방법을 다룬다. 즉, 체이닝이 "순서를 설계하는 기술"이라면, 다음은 "흐름을 분기하고 병렬화하는 기술"의 이야기다.