복잡한 문제에서 LLM이 틀리는 이유는 대개 한 가지로 모입니다. 생각은 했는데, 생각을 '검증'하지 않았거나, 애초에 생각이 갈 수 있는 길(탐색 공간)을 잘못 잡았기 때문입니다. 그래서 고급 기법의 목표는 단순합니다.
첫째, 모델이 문제를 한 번에 뛰어넘지 못하게 사고 과정을 유도하고(CoT), 둘째, 단일 해답으로 직진하지 말고 여러 갈래를 탐색하게 만들며(ToT), 셋째, 스스로 자기검토 루프를 돌려 오류를 잡게 하고(리플렉션), 넷째, 프롬프트 자체를 생성·개선·역공학하여 재현성을 확보합니다(메타 프롬프팅/Reverse Prompt Engineering).
핵심은 이 한 문장입니다.
'왜 틀리는지'가 보이면 '어떻게 맞추는지'도 보입니다.
CoT(Chain-of-Thought): "답"을 묻지 말고 "풀이 전략"을 설계하기
CoT는 모델이 문제를 중간 단계로 쪼개며 결론에 도달하도록 유도하는 방식입니다. 여기서 중요한 포인트는 "설명을 길게 쓰게 한다"가 아니라, 실수하기 쉬운 지점을 단계로 분리해 누락을 줄인다는 데 있습니다.
다만 실무에서는 매번 긴 풀이를 출력하게 만들 필요가 없습니다. 오히려 길게 쓰게 하면 표면적으로 그럴듯하지만 틀린 논리를 늘어놓는 경우도 생깁니다. 그래서 CoT는 보통 다음처럼 설계합니다.
문제 해결은 모델이 내부적으로 단계적 사고를 하도록 유도하되, 출력은 (1) 결론 (2) 핵심 근거/핵심 단계 요약 (3) 체크 포인트로 제한합니다.
CoT 프롬프트 패턴 1: "계획 → 실행"으로 사고를 분리
복잡한 작업은 계획과 실행을 분리하면 누락이 줄어듭니다.
너는 [역할]이다.
[문제]
...
[요청]
1) 먼저 '해결 계획'을 5단계 이내로 작성하라.
2) 그 계획을 그대로 따라 최종 답을 작성하라.
[출력]
- 해결 계획(5단계 이내)
- 최종 답
- 마지막에 '내 답이 틀릴 수 있는 지점' 2개와 확인 방법여기서 마지막 줄이 중요합니다. 모델이 "내가 틀릴 수 있는 이유"를 먼저 떠올리면, 그 이유가 곧 검증 항목이 됩니다.
CoT 프롬프트 패턴 2: "요구사항 체크"를 의무화
CoT가 실패하는 흔한 이유는 풀이가 아니라 과제 해석이 틀렸기 때문입니다(요구사항 누락, 금지사항 위반). 그래서 문제 풀이 전에 요구사항을 리스트업하게 만듭니다.
아래 요청을 수행하기 전에, 요구사항을 체크리스트로 재진술하라.
그 다음 답을 작성하고, 마지막에 체크리스트 기준으로 PASS/FAIL을 표시하라.
[요청]
...
[출력]
- 요구사항 체크리스트
- 답
- 체크리스트 검증(PASS/FAIL + 근거 1줄)이 패턴은 9장(피드백/리비전)의 "검증"을, 이번 장에서는 모델이 먼저 하게 만드는 버전이라고 보면 됩니다.
ToT(Tree-of-Thoughts): 한 줄로 가기 전에, 여러 길을 한번 보고 가기
CoT가 "한 줄로 푸는 사고"라면, ToT는 "갈림길을 만들어 탐색하는 사고"입니다. ToT는 중간 단계(thought)를 노드로 두고, 여러 후보를 뻗어 나가게 만든 뒤, 자체 평가와 탐색(BFS/DFS 등)을 결합해 되돌아가기(백트래킹)까지 가능하게 합니다.1
Prompting 관점에서 ToT의 요점은 세 가지입니다.
첫째, 한 단계에서 생각 후보를 여러 개 만든다.
둘째, 각 후보를 평가한다(예: sure/maybe/impossible 같은 판정).1
셋째, 좋은 후보만 남겨 다음 단계로 확장한다.1
ToT 프롬프트 패턴: "후보 생성 → 후보 평가 → 선택 → 확장"
너는 전략적 문제 해결자다.
[문제]
...
[ToT 규칙]
- 1단계에서 접근법 후보를 3개 만든다.
- 각 후보를 다음 기준으로 평가한다: 성공 가능성, 리스크, 필요한 정보.
- 가장 좋은 후보 1개를 선택해 2단계 실행 계획을 작성한다.
- 마지막에 '다른 후보를 버린 이유'를 2줄로만 적어라.
[출력]
1) 후보 3개
2) 후보 평가 표
3) 선택된 후보의 실행 계획ToT는 특히 "정답이 하나가 아닌 문제"에서 강합니다. 전략, 기획, 디버깅, 설계처럼 대안 비교가 중요한 작업에서, 단일 답안 직진의 위험을 줄여줍니다.
CoT와 ToT를 섞는 법: ToT로 길을 고르고, CoT로 걷기
실전에서는 둘을 경쟁시키기보다 순서를 나눠 쓰는 편이 좋습니다.
먼저 ToT로 선택지를 펼치고, 그중 최선의 가지를 고른 뒤, 선택된 가지를 CoT로 정교하게 실행합니다. ToT가 "탐색", CoT가 "집행"을 담당하는 셈입니다.1
리플렉션(Reflection): '답을 내기'보다 '틀릴 이유를 찾기'
리플렉션은 모델이 자신이 만든 결과를 다시 보고 비판·수정하는 루프입니다. 9장에서 다룬 피드백/리비전이 "사용자가 검토자 역할을 수행"하는 루틴이라면, 여기의 리플렉션은 "모델이 스스로 검토자 역할을 수행하도록 설계"하는 고급 기법입니다.
Learn Prompting은 이런 자기비판(Self-Criticism) 계열 기법으로 Self-Calibration, Self-Refine, RCoT, Self-Verification, Chain-of-Verification(CoVe), Cumulative Reasoning 등을 묶어 소개합니다.2
리플렉션이 특히 잘 듣는 실패 유형
환각/단정: 근거 없는 사실을 확신하는 경우
요구사항 누락: 형식·범위·금지사항을 놓친 경우
얕은 추론: 말은 그럴듯하지만 핵심 반론을 못 견딘 경우
이때 리플렉션의 요령은 "다시 생각해 봐"가 아니라, 검토 관점(루브릭)을 고정하는 것입니다.
리플렉션 프롬프트 패턴 1: "검토자 분리" (Self-Refine의 감각)
1) 먼저 아래 초안에 대해 '검토자'로서 문제를 5개만 지적하라.
- 범주: 정확성 / 논리 / 요구사항 / 표현 / 누락
- 각 항목은 한 문장으로.
2) 그 다음 '작성자'로 돌아와, 방금 지적한 5개를 모두 반영해 수정본을 작성하라.
[초안]
...핵심은 역할을 분리하는 것입니다. 같은 턴에서 "쓰면서 동시에 검사"하면 둘 다 흐려집니다.
리플렉션 프롬프트 패턴 2: CoVe 감각으로 "검증 질문"을 먼저 만들기
CoVe는 답을 내고 끝내지 않고, 검증 질문을 만들어 스스로 답하며 최종 답을 다듬는 흐름을 강조합니다.2
아래 질문에 답하되, 먼저 '검증 질문' 5개를 만들어라.
그 다음:
- 초안 답변 작성
- 검증 질문 5개에 답하며 초안의 오류/누락을 찾아라
- 최종 답변 작성
[질문]
...
[출력]
1) 검증 질문 5개
2) 최종 답변
3) 수정 로그(무엇을 왜 바꿨는지 5줄)이 방식은 "왜 틀렸는지"를 질문으로 바꿔 검사 도구로 만드는 설계입니다.
메타 프롬프팅(Meta Prompting): "정답" 대신 "정답을 뽑는 틀"을 만들기
메타 프롬프팅은 프롬프트가 프롬프트를 다루게 만드는 기법입니다. 즉, 모델에게 어떤 문제의 답을 직접 시키기보다, 문제를 푸는 구조(형식/문법/패턴)를 먼저 만들게 합니다.
Prompting Guide는 메타 프롬프팅을 "내용 자체보다 과제/문제의 구조와 문법적 측면에 초점을 두는 고급 기법"으로 설명하고, 구조 중심, 문법 중심, 추상 예시 활용 등의 특징을 정리합니다.3
실무적으로 메타 프롬프팅이 강한 지점은 다음입니다.
프롬프트를 팀 표준으로 만들고 싶을 때(재현성)
업무가 바뀔 때마다 프롬프트를 새로 짜기 싫을 때(확장성)
"무엇을 물어야 할지"가 불명확할 때(요구사항 발굴)
메타 프롬프트 템플릿: "프롬프트 설계자"에게 맡기기
너는 프롬프트 설계자다.
내 목표를 달성하기 위한 '최종 프롬프트'를 작성해라.
[내 목표]
- 작업: ...
- 독자/사용처: ...
- 입력 형태: ...
- 출력 형태: ...
- 제약/금지: ...
[요구]
- 최종 프롬프트는 역할/목표/맥락/제약/출력 형식을 포함해야 한다.
- 모호한 부분이 있으면 먼저 확인 질문 5개를 제시하라.
- 내가 답하면, 그 답을 반영해 최종 프롬프트를 1개로 확정해라.이 템플릿을 쓰면, 사용자는 "프롬프트를 잘 쓰는 사람"이 아니라 "좋은 요구를 가진 사람"으로 역할이 바뀝니다.
Reverse Prompt Engineering(RPE): 좋은 출력에서 좋은 프롬프트를 '복원'하기
프롬프트는 종종 대화가 끝나면 사라집니다. 그런데 팀에서 진짜 필요한 건 "그때 잘 됐던 한 번"이 아니라 다음에도 잘 되게 만드는 재현성입니다.
RPE는 모델의 출력만을 가지고, 그 출력을 만들었을 법한 원래 프롬프트를 복원(reconstruct)하는 기법입니다. Learn Prompting은 RPE를 "텍스트 출력만으로 원래 프롬프트를 재구성"하며, 모델 내부(logits 등)에 접근하지 않는 블랙박스 환경에서도 가능하고, 유전 알고리즘에서 영감을 받은 반복 최적화로 추정 프롬프트를 개선한다고 설명합니다.4
여기서 실무자가 얻는 이득은 단순합니다.
"좋은 결과물"을 프롬프트 라이브러리(레시피)로 바꾸는 방법이 생깁니다.
실무형 RPE 절차: 대화 로그를 '레시피'로 바꾸기
잘 나온 결과물(또는 답변) 3~5개를 모읍니다.
그 결과물들에 공통으로 나타나는 요소를 표시합니다. 예컨대 톤, 구조, 금지사항 준수, 근거 표기 방식 같은 것들입니다.
모델에게 "이 출력이 나오려면 어떤 지시가 필요했는지"를 추론시켜, 후보 프롬프트를 만듭니다.
후보 프롬프트를 실제로 다시 실행해 보고, 원하는 품질이 재현되도록 문장을 다듬습니다.
이때 RPE는 '디버깅'에도 도움이 됩니다. 결과가 이상할 때, 거꾸로 물어보면 "내 프롬프트가 무엇을 암묵적으로 허용했는지"가 드러나기 때문입니다. 특히 RPE의 가장 단순한 형태(출력 1개로 복원)는 과도하게 구체적이거나 잘못된 가정을 끼워 넣는 문제가 있어, 여러 출력(예: 5개)을 모아 균형을 잡는 접근이 유리하다고 설명합니다.4
실패 원인 → 처방 매칭: '왜 틀리는지'로 기법을 고르기
복잡한 문제에서의 실패는 보통 아래 네 가지 중 하나입니다.
첫째, 프레이밍 오류입니다. 사실은 "요약"인데 "평가"로 답하거나, "정책 적용"인데 "일반 상식"으로 답합니다.
둘째, 탐색 부족입니다. 여러 대안을 비교해야 하는데 첫 생각으로 결론을 냅니다.
셋째, 검증 부재입니다. 맞는지 확인하지 않고 그럴듯한 결론을 냅니다.
넷째, 프롬프트의 암묵성입니다. 내 기준이 프롬프트에 없어서 모델이 임의로 기준을 채웁니다.
이때 처방은 간단히 매칭됩니다.
프레이밍 오류가 잦다면: 메타 프롬프팅으로 "과제 정의/출력 규격"을 먼저 고정합니다.3
탐색 부족이 문제라면: ToT로 후보를 펼치고 비교한 뒤 선택합니다.1
검증 부재가 문제라면: 리플렉션(검토자 분리, 검증 질문, Self-Refine/CoVe류)을 붙입니다.2
암묵성이 문제라면: RPE로 "내가 사실상 무엇을 요구했는지"를 역으로 드러내고 문장으로 고정합니다.4
미니 워크플로(권장): ToT 1턴 + CoT 1턴 + 리플렉션 1턴
복잡한 일을 한 번에 끝내려다 실패할 때, 아래 3턴을 습관처럼 붙이면 성공률이 올라갑니다.
1턴(ToT): 대안과 리스크를 펼친다
이 문제의 해결 접근법을 3개 제안하고,
각각의 장단점/리스크/필요한 추가정보를 비교한 뒤,
가장 안전한 1개를 선택해라.2턴(CoT): 선택한 접근법으로 실행 계획을 만든다
방금 선택한 접근법으로, 실행 계획을 5단계로 작성하고
그 계획을 따라 결과를 작성해라.
출력은 '계획 + 결과'만.3턴(리플렉션): 스스로 틀릴 이유를 찾아 고친다
방금 결과물을 감사(audit)해라.
- 요구사항 위반 3개
- 사실/논리 취약점 3개
- 최소 수정으로 고친 최종본이 3턴은 비용(시간/토큰)을 조금 더 쓰는 대신, "한 번에 맞추기"가 아니라 "틀릴 이유를 제거하며 맞추기"로 방향을 바꿔 줍니다.
정리
고급 기법은 화려한 주문이 아닙니다. 사고(생성)·탐색(비교)·검증(자기검토)·표준화(프롬프트화)를 분리해, 사람이 하던 문제 해결 습관을 대화에 이식하는 방법입니다.
그리고 이 장의 메시지는 끝까지 같습니다.
왜 틀리는지(탐색 부족, 검증 부재, 암묵적 기준)가 보이면, 어떻게 맞추는지(ToT, 리플렉션, 메타 프롬프트, RPE)가 자연스럽게 선택됩니다.
참고
1Tree of Thoughts (ToT) — Prompting Guide
2🟢 Introduction to Self-Criticism Prompting Techniques — Learn Prompting
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.