멀티 스텝 프롬프트 워크플로우가 실패하는 이유: 프롬프트 자체가 아닌 연결 지점(Join points)을 엔지니어링하세요.
Most multi-step prompt workflows fail at the join points, not the prompts. Here's what changes when you engineer the chain instead of the steps.
핵심 요약
프롬프트 체인 실패의 원인은 개별 프롬프트가 아닌 연결 지점의 구조적 문제이며, 이를 해결하기 위한 4가지 엔지니어링 원칙을 제시함.
- 출력 스키마 — 읽기 쉬운 형식이 아닌 다음 프롬프트가 파싱 가능한 구조화된 형식을 사용함.
- 명시적 핸드오프 — 각 프롬프트가 다음 단계에서 어떻게 사용될지 명시하여 모델의 분석력을 높임.
- 실패 모드 방지 — 각 연결 지점에서 입력 데이터의 구조를 검증하여 오류 전파를 차단함.
- 상태 고정(Anchoring) — 체인 중간 단계에서 원본 지시사항을 재주입하여 결과물의 일관성을 유지함.
저는 약 18개월 동안 멀티 스텝 프롬프트 체인을 구축해 왔습니다. 한 프롬프트의 출력이 다음 프롬프트의 구조화된 입력이 되고, 그것이 또 다음으로 이어지는 워크플로우죠. 모호한 입력("사업 아이디어가 하나 있어요")을 받아 5~6개의 프롬프트를 순차적으로 실행해 결과물("포지셔닝 성명서, 시장 분석, 브랜드 기반")을 만들어내는 그런 종류의 작업입니다.
지난 18개월 대부분의 기간 동안 제 체인은 기대 이하의 성능을 보였습니다. 개별 프롬프트는 탄탄했지만, 체인 전체로 보면 결과물이 표류하거나 초점을 잃거나 단계 간에 서로 모순되는 경우가 발생했습니다. 개별 프롬프트를 계속 개선했지만 체인은 눈에 띄게 나아지지 않았습니다.
문제는 프롬프트가 아니었습니다. 제가 체인을 독립적인 프롬프트들의 연속으로 취급하고 있었던 게 문제였습니다. 사실 체인은 여러 단계를 가진 하나의 엔지니어링 아티팩트입니다. 완전히 다른 문제죠.
독립적인 프롬프트와 체인형 프롬프트의 구조적 차이:
독립적인 프롬프트는 하나의 작업만 수행합니다: 알려진 입력에서 유용한 출력을 생성하는 것. 입력은 사용자가 붙여넣는 것이고, 출력은 사용자가 다음에 무엇을 하느냐에 달려 있습니다. 프롬프트는 둘 다 신경 쓰지 않습니다.
체인형 프롬프트는 두 가지 작업을 수행합니다: 유용한 출력을 생성하고, 그리고 다음 프롬프트가 안정적으로 소비할 수 있는 구조로 그 출력을 생성하는 것입니다. 출력은 사용자를 위한 것이 아니라 다른 프롬프트를 위한 것입니다. 이것이 설계 방식을 바꿔야 하는 이유입니다.
대부분의 체인 실패는 연결 지점(join points)에서 발생합니다. 프롬프트 1은 사람이 읽기에는 유용한 출력을 생성하지만, 프롬프트 2가 필요로 하는 구조는 갖추지 못합니다. 프롬프트 2는 구조를 추측하거나 추가적인 파싱 작업을 수행해야 하며, 이는 결과물의 질을 떨어뜨립니다. 4~5단계에 이르면 세 겹의 성능 저하가 누적되어, 처음부터 모든 것을 한 번에 처리하는 하나의 큰 프롬프트를 썼을 때보다 최종 결과물이 훨씬 나빠지게 됩니다.
제가 모든 체인에 적용하는 4가지 엔지니어링 원칙:
1. 출력 스타일이 아닌 출력 스키마. 체인의 각 프롬프트는 단순히 읽기 쉬운 구조가 아니라 파싱 가능한 구조로 출력을 생성해야 합니다. 이는 보통 출력 형식을 명시적으로 지정하는 것을 의미합니다: 레이블이 지정된 섹션 구조, 열 이름이 있는 마크다운 표, 일관된 필드가 있는 번호 매기기 목록 등. 구조가 강제되기 때문에 다음 프롬프트는 각 정보가 어디에 있는지 알 수 있습니다.
독립적인 프롬프트 출력: "여기 당신의 사업을 위한 포지셔닝 성명서가 있습니다..." 체인형 프롬프트 출력:
## POSITIONING STATEMENT
[one sentence]
## TARGET AUDIENCE
[paragraph]
## CORE DIFFERENTIATOR
[paragraph]
## ASSUMPTIONS REQUIRING VALIDATION
[bullet list]
두 번째 버전은 프롬프트 2가 파싱할 수 있습니다. 첫 번째 버전은 안정적으로 파싱할 수 없습니다.
2. 명시적인 핸드오프 지침. 각 프롬프트는 자신의 출력이 다운스트림에서 무엇을 위해 사용될지 명시해야 합니다. 모델이 알아야 해서가 아니라, 그렇게 작성하는 훈련을 함으로써 일반적인 유용성이 아닌 실제 사용 사례에 맞게 출력을 설계하게 되기 때문입니다.
"이 출력은 다음 시장 조사 프롬프트로 전달되며, 타겟 오디언스와 차별화 섹션을 사용하여 경쟁 포지셔닝 격차를 식별하는 데 사용될 것입니다"라는 한 줄을 추가하는 것만으로도 출력은 의미 있게 바뀝니다. 모델은 오디언스와 차별화 섹션이 단순히 읽히는 것이 아니라 분석될 것임을 알기 때문에 더 분석적인 날카로움을 가지고 생성합니다.
3. 실패 모드 전파. 프롬프트 1이 실패하거나 품질이 낮은 출력을 생성할 때, 프롬프트 2는 자신이 나쁜 입력을 가지고 작업하고 있다는 것을 모릅니다. 그냥 입력보다 한 단계 더 나쁜 출력을 생성할 뿐입니다. 5단계가 되면 실패는 조용히 누적됩니다.
