개념
프롬프트 체이닝(prompt chaining)은 복잡한 작업을 한 번의 호출로 끝내려 하지 않고, 작은 단계로 쪼갠 뒤 각 단계의 결과를 다음 단계의 입력으로 넘기는 설계 방식이다. 예를 들어 긴 보고서를 요약해 이메일로 만드는 작업이라면, 핵심 문단을 뽑는 호출, 그것을 요약하는 호출, 요약을 이메일 문체로 다듬는 호출로 나눈다.
이렇게 나누는 이유는 한 번의 호출에 여러 지시를 담을수록 모델이 일부를 놓치기 때문이다. "핵심만 뽑고, 다섯 문장으로 줄이고, 존댓말로 쓰고, 제목도 달아라"를 한꺼번에 요구하면 어느 하나가 흐려진다. 단계를 나누면 각 호출의 지시가 하나로 좁아지고, 그만큼 지시를 지킬 확률이 올라간다.
부수적인 이점은 관찰 가능성이다. 결과가 이상할 때 어느 단계에서 어긋났는지 중간 산출물을 열어 확인할 수 있고, 그 단계의 프롬프트만 고치면 된다. 단계 사이에 검증 로직을 끼워 넣거나, 조건에 따라 경로를 갈라 보내는 것도 가능하다. 단계 사이에 넘기는 값은 구조화 출력으로 고정해 두면 안정적이다.
비용 측면에서도 유리한 구석이 있다. 한 번의 호출로 처리하려면 필요한 자료를 전부 프롬프트에 넣어야 하지만, 단계를 나누면 각 단계가 자기 몫의 자료만 보면 된다. 앞 단계에서 추린 결과만 뒤로 넘기기 때문에 뒤로 갈수록 프롬프트가 짧아지고, 그만큼 컨텍스트 윈도우 압박도 줄어든다.
쓰임새
번역 후 문체 교정, 초안 작성 후 사실 확인, 문의 분류 후 유형별 응답 생성처럼 성격이 다른 작업이 이어지는 곳에 잘 맞는다. 비용이 비싼 모델은 판단이 필요한 단계에만 쓰고 단순 정리는 가벼운 모델에 맡기는 식으로, 단계마다 다른 모델을 배정하는 최적화도 흔하다.
에이전트와는 다음 단계를 누가 정하느냐로 갈린다. 체이닝은 단계와 순서를 사람이 미리 고정하고, 에이전트는 실행 중에 모델이 스스로 정한다. 흐름이 예측 가능한 작업이라면 고정된 체인이 더 저렴하고 안정적이다. 실무에서는 전체 흐름을 체인으로 고정해 두고 판단이 필요한 한두 단계에만 에이전트를 두는 절충이 자주 쓰인다.
앞 단계의 결과가 비어 있거나 형식이 어긋난 경우를 어떻게 처리할지도 미리 정해야 한다. 그대로 다음 단계로 흘려보내면 엉뚱한 입력을 받은 모델이 그럴듯한 결과를 지어내기 때문에, 흐름을 멈추거나 재시도하는 분기를 단계 사이에 두는 편이 낫다.
자주 하는 오해
프롬프트 체이닝과 생각의 사슬은 같은 말 아닌가?
생각의 사슬은 한 번의 호출 안에서 모델이 추론 과정을 풀어 쓰게 하는 기법인 반면, 체이닝은 호출 자체를 여러 개로 나누는 시스템 설계다.
단계를 잘게 나눌수록 좋지 않나?
단계마다 호출 비용과 지연이 더해지고, 앞 단계에서 잘려 나간 정보는 뒤에서 복구되지 않는다. 하나의 호출로 안정적으로 처리되는 작업을 굳이 쪼갤 이유는 없으며, 나누기 전에 단일 호출이 실패하는 지점을 먼저 확인하는 것이 순서다.
각 단계가 정확하면 전체도 정확하지 않나?
단계별 성공률이 곱해지기 때문에, 각 단계가 충분히 정확해 보여도 단계가 길어지면 전체 성공률은 눈에 띄게 떨어진다. 실패가 뒤로 번지지 않도록 중간 검증을 두어야 하고, 단계 수를 늘릴 때는 그만큼 검증 지점도 함께 늘려야 한다.