Plan-and-Solve 논문은 zero-shot CoT가 자주 놓치는 중간 단계를 줄이기 위해 나온 프롬프팅 전략입니다. 핵심은 바로 답으로 뛰어들지 않고, 먼저 해야 할 일을 계획으로 꺼내 놓는 데 있습니다.
이 글은 Plan-and-Solve Prompting 논문을 바탕으로 missing-step error가 무엇인지, 왜 plan-first decomposition이 도움이 되는지, zero-shot CoT와 어떤 차이가 있는지, practical limitations는 무엇인지 쉽게 정리합니다.
먼저 결론: Plan-and-Solve 논문이 바꾸는 것은 답이 아니라 순서다
이 논문의 메시지는 생각보다 소박합니다. 모델이 틀리는 이유가 항상 계산을 못해서가 아니라, 무엇을 먼저 해야 하는지 정리하지 않은 채 바로 추론을 시작해서 필요한 중간 단계를 빼먹기 때문이라는 점입니다.
그래서 Plan-and-Solve는 먼저 계획을 세우고, 그 계획을 따라 문제를 풀게 합니다. 이 단순한 분리가 missing-step error를 줄이는 핵심 아이디어입니다.
missing-step error는 무엇일까
missing-step error는 숫자 계산을 한 자리 틀리는 실수와는 다릅니다. 아예 필요한 중간 단계를 건너뛰는 문제에 더 가깝습니다.
- 문제에서 무엇을 구해야 하는지 정한다
- 필요한 조건을 정리한다
- 조건 사이 관계를 세운다
- 계산 또는 추론을 수행한다
- 결과가 질문에 맞는지 확인한다
zero-shot CoT는 겉으로는 단계별로 설명하는 것처럼 보여도, 실제로는 위 단계 중 일부를 흐릿하게 처리한 채 뒤 단계로 바로 들어갈 수 있습니다. 그래서 missing-step error는 단순 오답이 아니라 해결 절차의 뼈대가 빠지는 문제라고 이해하면 쉽습니다.
Plan-and-Solve는 무엇을 바꾸나
- 먼저 계획을 만든다
- 그 계획에 따라 문제를 푼다
이 차이는 작아 보이지만 효과는 꽤 큽니다. 계획 단계가 일종의 체크리스트 역할을 하기 때문입니다. 먼저 계획을 쓰게 하면 필요한 하위 작업이 겉으로 드러나고, 그 결과 해야 할 단계가 보이고 중간 단계 누락을 더 쉽게 잡을 수 있습니다.
결국 Plan-and-Solve의 본질은 더 똑똑한 답변이 아니라, 답으로 가는 길을 먼저 구조화하는 데 있습니다.
zero-shot CoT와 관계는 어떻게 봐야 할까
Plan-and-Solve를 이해할 때 가장 중요한 비교 대상은 zero-shot CoT입니다. 두 방식 모두 사람이 예시를 여러 개 넣지 않아도 reasoning을 끌어내려는 시도라는 점에서는 비슷합니다.
- zero-shot CoT는 문제를 보고 곧바로 단계적 추론을 시작한다
- Plan-and-Solve는 추론 전에 먼저 전체 계획을 세운다
즉 zero-shot CoT가 풀면서 생각한다면, Plan-and-Solve는 무엇을 어떻게 풀지 먼저 적고 그다음 풉니다. 그래서 단계가 여러 개이고 중간 조건 정리가 중요한 문제에서는 plan-first가 분명한 장점을 줄 수 있습니다.
왜 먼저 계획하면 단계 누락이 줄어들까
1. 전체 경로를 먼저 외부화한다
계획을 먼저 쓰면 모델 내부에서만 흐르던 경로가 바깥으로 드러납니다. 그러면 어떤 단계가 필요한지 더 분명해지고, 사람의 메모처럼 빠뜨릴 가능성이 줄어듭니다.
2. 큰 문제를 작은 하위 작업으로 나눈다
Plan-and-Solve는 전체 문제를 바로 한 번에 해결하려고 하지 않습니다. 대신 subtasks로 나누고 그 순서를 잡습니다. 이 분해가 중요한 이유는 큰 문제 하나를 붙잡고 길게 추론할수록 중간 단계 관계가 흐려질 위험이 커지기 때문입니다.
작업을 나누면 각 단계의 목적이 선명해집니다. 무엇을 계산하는 단계인지, 무엇을 해석하는 단계인지, 무엇을 검산하는 단계인지가 분리되기 때문입니다.
Plan-and-Solve가 해결하려는 문제와 해결하지 못하는 문제
- calculation errors
- missing-step errors
- semantic misunderstanding errors
여기서 Plan-and-Solve가 특히 겨냥하는 것은 missing-step errors입니다. 즉 단계가 빠지는 문제입니다. 계획을 먼저 세운다고 해서 모든 계산 실수가 사라지는 것은 아니고, 문제 뜻을 잘못 이해한 경우도 자동으로 해결되지는 않습니다.
논문이 PS+를 따로 제안하는 이유도 여기에 있습니다. 계획만으로 부족한 부분, 특히 계산과 reasoning 품질 문제를 더 자세한 지시로 보완하려는 것입니다.
ReAct와는 어떤 식으로 이어질까
에이전트 planning 글에서 정리했듯이, planning은 점점 작업 분해와 재조정의 문제로 확장됩니다. Plan-and-Solve는 그 흐름을 아주 깔끔한 프롬프팅 형태로 보여주지만, 초점은 도구 사용보다 reasoning 과정에서 단계 누락을 줄이는 데 있습니다.
반대로 ReAct는 reasoning과 acting을 교차시키며 필요할 때 외부 정보원과 상호작용하는 구조를 보여줍니다. 그래서 ReAct가 생각과 행동의 연결을 보여준다면, Plan-and-Solve는 생각 내부의 단계 분해를 더 또렷하게 보여준다고 볼 수 있습니다.
실무에서는 언제 plan-first가 특히 유리할까
- 중간 조건을 여러 개 정리해야 하는 문제
- 계산보다 절차 누락이 더 위험한 문제
- 한 번에 답하면 경로가 자주 흐려지는 문제
- 최종 답보다 중간 reasoning 품질이 중요한 작업
예를 들면 여러 조건이 얽힌 수학 문장제, 긴 정책 문서 요약 전에 체크 항목을 먼저 뽑는 작업, 여러 파일을 분석하기 전에 검사 순서를 먼저 세우는 작업 같은 경우입니다. 반대로 아주 짧고 단순한 문제라면 계획 단계 자체가 오버헤드가 될 수 있습니다.
practical limitations도 같이 봐야 한다
계획이 틀리면 그다음도 같이 흔들린다
좋은 계획이면 도움이 되지만 나쁜 계획이면 그 나쁜 경로를 더 또렷하게 따라가게 될 수도 있습니다. 즉 단계 누락은 줄여도, 잘못된 분해가 들어가면 다른 종류의 실패가 생길 수 있습니다.
짧은 작업에는 과할 수 있다
문제 자체가 짧고 명확하면 먼저 계획을 세우는 비용이 실제 이득보다 클 수 있습니다. 이 경우에는 zero-shot CoT나 단순 직접 답변이 더 빠르고 충분할 수 있습니다.
의미를 잘못 이해한 문제는 별개다
질문 자체를 오해했거나 핵심 제약을 잘못 읽었다면, 계획을 예쁘게 세워도 출발점이 틀렸기 때문에 결과는 여전히 위험합니다. 즉 semantic misunderstanding를 해결하는 장치로 과장하면 안 됩니다.
검증 루프가 없으면 계획도 그대로 믿기 쉽다
실무 에이전트나 워크플로에서는 계획 뒤에 검증과 재계획이 붙는 경우가 많습니다. 하지만 단순 프롬프트만으로 쓰면 처음 계획 자체를 다시 의심하지 않을 수 있습니다. 그래서 실전에서는 계획 생성 뒤에 확인 단계나 재검토 단계를 붙이는 편이 더 안전합니다.
정리
Plan-and-Solve 논문은 성능 경쟁보다 구조 변화로 읽는 편이 더 정확합니다. 이 논문은 reasoning을 더 길게 만들자는 주장보다, 문제를 풀기 전에 경로를 먼저 정리하자는 주장에 가깝습니다.
Plan-and-Solve의 핵심은 더 많이 생각하는 것이 아니라, 먼저 무엇을 해야 하는지 보이게 만드는 데 있습니다. 단계가 자주 빠지는 작업이라면 꽤 실용적이지만, 계획이 틀릴 수 있고 짧은 작업에는 과할 수 있으며 의미 오해까지 해결해주지는 않는다는 한계도 함께 기억해야 합니다.
공식 1차 자료는 Plan-and-Solve Prompting 논문을, 배경 비교용으로는 ReAct 논문과 에이전트 planning 글을 함께 보면 흐름이 더 잘 잡힙니다.
