어떤 LLM (Large Language Model) 작업이든 하나의 거대한 프롬프트를 작성하려는 본능이 있습니다: "이 모든 것을 읽고, 답을 찾아낸 다음, 작성해라." 이는 종종 거의 작동하는 것처럼 보입니다. 출력물은 유창하고 자신감이 넘치는데, 바로 이 점이 위험을 초래합니다. 내부적으로 모델은 추출 (extraction), 추론 (reasoning), 그리고 작성 (writing)을 동시에 수행하며, 어텐션 (attention)은 유한하기 때문에 세부 사항을 놓치거나, 숫자를 잘못 세거나, 잘못된 우선순위를 선택하거나, 전체 하위 작업을 조용히 건너뛰기도 합니다. 더 나은 문제는, 분해할 수 있는 경계가 없는 불투명한 단락 하나만을 돌려받게 된다는 점입니다. 저는 동일한 작업을 두 가지 방식으로 실행하는 대화형 데모를 만들었는데, 그 격차는 한 번 보면 잊기 어렵습니다.

거대한 프롬프트를 망가뜨리는 작업

이 데모는 다섯 개의 지저분한 고객 리뷰를 가져와 하나의 정량화된 경영진 인사이트 (executive insight)를 요구합니다: 긍정적인 점을 기록하고, 가장 큰 불만 사항을 명시하며, 이를 정량화하고, 해결책을 권장하는 것입니다. 단일 프롬프트는 그럴듯한 결과물을 반환합니다 — "고객들은 만족하고 있으며, 주요 불만 사항은 느린 배송으로 보입니다" — 하지만 이것은 틀렸습니다. 다섯 개의 리뷰 중 두 개에서 앱 충돌 (App crashes)이 나타났고, 배송은 한 개였습니다. 모델은 잘못된 주요 이슈를 선택했고, 아무것도 정량화하지 않았으며, 어디서 실수가 발생했는지 확인할 방법도 제공하지 않았습니다.

아이디어: 단일 목적 프롬프트의 파이프라인

프롬프트 체이닝 (Prompt chaining)은 작업을 일련의 작은 프롬프트 시퀀스로 분해하며, 각 단계의 출력이 다음 단계의 입력이 됩니다. 전형적인 형태는 추출 (extract) → 변환 (transform) → 요약 (summarize)입니다:

const rows   = await extract(rawInput);   // 1단계: 파싱 (parse) 하되, 생각하지 마라
const tally  = await transform(rows);     // 2단계: 구조를 바탕으로 추론 (reason) 하라
const answer = await summarize(tally);    // 3단계: 제시 (present) 하되, 계산하지 마라

이는 LLM 호출에 적용된 Unix 파이프 (Unix-pipe) 철학입니다 — 작은 도구들을 조합하는 것입니다.

추출 (Extract): 파싱하되, 생각하지 마라

첫 번째 연결 고리는 오직 추출만을 수행합니다. 지저분한 텍스트를 깨끗하고 기계가 읽을 수 있는 형태로 변환하고 그 외의 것은 아무것도 하지 마십시오 — 분석도, 산문 작성도 하지 않습니다. 이와 같이 좁은 범위의 프롬프트는 작은 모델조차 거의 매번 정확하게 수행할 수 있는 것입니다:

async function extract(rawReviews) {
  return llm(`각 리뷰에 대해 다음 형식으로 한 줄씩 출력하세요:
    + 긍정적인 주제  ·  - 부정적인 주제 (주제: {app,battery,shipping,price,comfort,sound})
...```

이제 까다로운 파싱 (parsing) 작업은 정확히 한 번만 수행되며, 이후의 모든 단계는 원문 텍스트를 다시 파싱하는 대신 깔끔하게 정리된 행 (rows)을 바탕으로 작동합니다.

## 변환 (Transform): 구조에 대한 추론 (reasoning)

중간 단계는 실제 추론(aggregate, count, rank)을 수행하지만, 원문 입력이 아닌 1단계에서 생성된 깨끗한 행을 대상으로 합니다:

async function transform(rows) {
return llm(`이 태그가 지정된 행들을 바탕으로, 주제별 부정적 언급 횟수를 집계하고,
내림차순으로 정렬한 뒤, 긍정적인 주제는 별도로 나열하세요.
...```

이는 거대 프롬프트 (mega-prompt) 내부에서 추론을 수행하는 것보다 훨씬 더 신뢰할 수 있습니다. 모델이 지저분한 텍스트를 파싱하기 위해 동시에 애쓸 필요가 없기 때문입니다.

요약 (Summarize): 계산하지 말고 제시하라

마지막 단계는 오직 작성만 수행하며, 파이프라인이 이미 계산해 놓은 결과만을 사용합니다:

async function summarize(tally) {
  return llm(`오직 이 집계 결과만을 사용하여 한 단락으로 작성하세요:
             전반적인 감정, 횟수와 함께 명시된 1위 불만 사항,
...```

"답을 결정하는 것"과 "답을 문장으로 표현하는 것"을 분리하는 것이, 유창한 산문이 조용히 다른 주요 이슈를 지어내거나 숫자를 잊어버리는 것을 방지하는 핵심입니다.

## 보상: 게이트 (gates)와 오류 격리 (error isolation)

체이닝 (chaining)은 단순히 세 번의 호출을 순서대로 실행하는 것뿐입니다. 하지만 모든 중간 결과가 가시적인 체크포인트 (checkpoint)가 되기 때문에, 단계 사이에 _게이트 (gate)_를 설정할 수 있으며, 답변이 틀렸을 때 실패 지점이 파묻히지 않고 국소화됩니다:

async function run(rawReviews) {
const rows = await extract(rawReviews);
assert(rows.includes("-"), "extract가 태그된 행을 생성하지 못했습니다"); // 게이트
...```

최종 답변이 틀렸다면, rows, tally, answer를 차례로 열어보고 정확히 어느 단계에서 실패했는지 확인할 수 있습니다. "아, extract 단계에서 4번 리뷰를 놓쳤기 때문에 집계가 틀렸구나"라고 말이죠. 단일 거대 프롬프트는 경계(seams)가 전혀 없기 때문에, 어디에서 버그가 발생하든 결과는 똑같이 잘못된 단락으로 나타날 뿐입니다.

체이닝을 해야 할 때 — 그리고 하지 말아야 할 때

이것은 공짜가 아닙니다. 더 많은 호출은 더 높은 지연 시간 (latency)과 토큰 비용을 의미하며, 초기 단계의 오류는 하류 단계로 전파됩니다 (garbage in, garbage out — 따라서 공격적으로 게이트를 설정해야 합니다). 작업이 진정으로 구별되는 단계들을 가지고 있고 신뢰성(reliability)이나 디버깅 가능성(debuggability)이 중요할 때 체이닝을 사용하세요. 단순한 싱글샷 (single-shot) 작업의 경우, 하나의 좋은 프롬프트가 더 빠르고 저렴합니다. 한 줄짜리 작업을 위해 파이프라인을 구축하는 것은 그 자체로 일종의 오버엔지니어링 (over-engineering)입니다. 신뢰성은 당신에게 유리하게 복리로 작용합니다. 하나의 광범위한 프롬프트는 모든 하위 작업을 한 번에 완벽히 수행해야 하지만, 각각의 좁은 단계는 단일 작업에 대해 훨씬 더 높은 성공률을 가집니다.

작업을 하나 선택하여, 단일 프롬프트와 체인 사이를 전환해 보고, 파이프라인을 단계별로 따라가며 상태 (state)가 단계에서 단계로 흐르는 것을 관찰해 보세요:
https://dev48v.infy.uk/prompt/day35-prompt-chaining.html