큰 작업을 여러 단계로 나눠 LLM을 여러 번 부르고, 앞 단계의 출력을 다음 단계의 입력으로 넘기는 방식이다. 한 프롬프트에 다 넣으면 모델이 헷갈리거나 일부를 빠뜨리는 작업, 처리 순서가 미리 정해진 작업에 쓴다.
| 방식 | 구조 | 이럴 때 쓴다 |
|---|---|---|
| 단일 프롬프트 | 한 번 호출 | 짧고 단순한 작업 |
| 프롬프트 체이닝 | 정해진 순서로 여러 번 호출 | 단계가 분명한 작업 |
| 에이전트 | 모델이 다음 행동을 스스로 정함 | 단계를 미리 정할 수 없는 작업 |
한 프롬프트에 조사·정리·작성·교정을 모두 넣으면 모델이 여러 지시를 한꺼번에 챙겨야 해서 일부를 놓치기 쉽다. 단계를 나누면 호출마다 한 가지 일에만 집중하므로 결과가 안정된다.
고치기도 쉬워진다. 결과가 이상하면 중간 출력을 보고 어느 단계에서 틀렸는지 바로 찾을 수 있고, 그 단계 프롬프트만 고치면 된다.
블로그 글이라면 "주제 브레인스토밍 → 개요 작성 → 섹션별 초안 → 편집·교정"처럼 네 번의 호출로 나눈다. 만드는 순서는 아래와 같다.
| 순서 | 할 일 | 팁 |
|---|---|---|
| 1. 단계 나누기 | 한 단계에 한 가지 일만 맡긴다 | 단계가 너무 많으면 느려진다 |
| 2. 출력 형식 정하기 | 다음 단계가 받을 형태를 정한다 | JSON이나 태그로 구분하면 넘기기 쉽다 |
| 3. 중간 검사 넣기 | 다음 단계 전에 결과를 확인한다 | 형식이 틀리면 다시 부르거나 멈춘다 |
| 4. 단계별 모델 고르기 | 난이도에 맞는 모델을 고른다 | 단순한 단계는 작고 싼 모델로 |
구현할 때 꼭 프레임워크가 필요하지는 않다. 코드에서 호출 결과를 변수에 담아 다음 프롬프트에 끼워 넣기만 해도 된다. 프레임워크를 쓴다면 LangChain의 SequentialChain(요즘은 LCEL의 | 연결을 주로 쓴다)이나 LangGraph의 선형 그래프로 만들 수 있다.
순서를 미리 정할 수 있고 속도보다 정확도가 중요하면 체이닝이 맞다. 문서를 요약한 뒤 번역하기, 데이터를 뽑아낸 뒤 보고서 쓰기, 초안을 쓴 뒤 스스로 검토하기가 대표적이다.
한 번에 잘 풀리는 단순한 질문이나 빠른 응답이 중요한 실시간 대화에는 맞지 않는다. 상황에 따라 다음 단계가 달라져야 한다면 체이닝보다 에이전트 방식이 낫다.
단계마다 호출이 하나씩 늘어나므로 응답 시간과 비용도 그만큼 늘어난다. 또 앞 단계의 실수가 다음 단계로 그대로 넘어가 점점 커질 수 있다. 그래서 중요한 단계 뒤에는 형식과 내용을 확인하는 검사를 두는 것이 좋다.
가장 흔한 건 정해진 순서로 도는 문서·글 처리 자동화다. 단계마다 프롬프트를 따로 두고, 중간 결과를 검사한 뒤 다음 단계로 넘긴다.
| 어디서 | 어떻게 쓰나 |
|---|---|
| 글쓰기 도구 | 브레인스토밍 → 개요 → 섹션별 초안 → 교정을 단계별 호출로 나눈다 |
| 문서 처리 자동화 | 긴 문서를 먼저 요약하고, 그 요약을 번역하거나 보고서로 바꾼다 |
| 데이터 추출 | 비정형 텍스트에서 항목을 JSON으로 뽑고, 형식 검사 후 다음 단계에서 정리한다 |
| 사내 문서 검색 | 질문을 검색용으로 다듬고 → 찾은 문서로 답변을 쓰고 → 근거를 다시 확인한다 |