P-E-V(Plan-Execute-Validate)는 LLM에게 “무엇을 하라”만 주지 않고 “어떻게 판단하고 어떻게 스스로 검사할지”까지 prompt에 넣는 설계 방식이다. 계획(Plan), 실행(Execute), 검증(Validate) 세 단계로 나뉘고, 답을 바로 요구하기 전에 판단용 checklist부터 깔아둔다는 점이 다른 prompt와 갈리는 부분이다. 이 글에서 P-E-V라고 부르는 건 정해진 표준 용어라기보다, 분류·생성 pipeline에서 반복해서 쓰게 된 prompt 구조에 붙인 이름이다.
왜 이런 구조가 필요했나
LLM에게 “이 keyword로 사람들이 실제로 검색할 법한 질문을 만들어줘”라고 하면 이런 답이 자주 나온다.
X 서비스의 핵심 기능과 장점은 무엇인가요?
사람이 정말 이렇게 검색할까. 거의 안 한다. prompt를 짤 때 가장 흔한 실수는 “무엇을 하라”만 적고 “어떻게 판단하라”를 빼먹는 것이다. LLM은 지시는 충실히 따르지만, 판단 기준이 없으면 가장 안전한 선택, 즉 가장 모호하고 넓은 category로 물러난다. 위 질문이 딱 그 모양이다. 틀리지는 않지만 아무 쓸모가 없다.
CoT, ReAct와 뭐가 다른가
| Pattern | 하는 일 | 차이 |
|---|---|---|
| CoT (Chain-of-Thought) | “단계별로 생각해봐” | reasoning을 드러내지만 출력 전 검증 단계는 없다 [1] |
| ReAct | “관찰하고 행동해” | 외부 tool 호출과 관찰-행동 loop에 초점이 있다 [2] |
| P-E-V | “계획 → 실행 → 검증” | 출력 직전 self-check(Validate) 단계를 둔다 |
CoT가 생각의 흐름을 만든다면 P-E-V는 생각의 checklist에 가깝다. 답을 내기 전에 모델이 “이게 맞나”를 한 번 더 따지게 만든다. Google의 prompt 설계 가이드도 모델에게 역할과 판단 기준을 구체적으로 줄수록 출력이 안정된다는 방향을 안내한다 [3].
세 단계
Plan은 입력에서 의도 신호를 찾고, Execute는 그 신호로 category를 정해 결과를 만들고, Validate는 출력 전에 checklist로 결과를 다시 본다.
Plan → 입력에서 의도 신호를 찾는다
"가격" → qualify, "vs" → compare, "방법" → action
Execute → 신호를 기준으로 category를 정하고 결과를 생성한다
신호가 모호하면 미리 정한 default를 따른다
Validate → 출력 전에 checklist로 self-check
"이 신호에 이 category가 정말 맞나?"
"제약(톤, 길이, 반복 표현)을 지켰나?"
모호한 입력이 엉뚱한 category로 갈 때 쓰는 세 가지
모호한 입력이 엉뚱한 category로 빠지는 문제는 세 장치로 막는다. 신호를 명시하는 decision tree, 출력 전에 거르는 validation checklist, 톤을 규칙으로 못 박는 명시적 제약이다.
1. decision tree로 신호를 명시한다
“분류해줘”만으로는 부족하다. “이 신호가 보이면 이 category다”라고 직접 적어줘야 한다.
신호 기반 routing 예시:
├─ "가격", "비용", "요금", "플랜" → qualify
├─ "vs", "비교", "대안", "말고" → compare
├─ "방법", "하는 법", "설정" → action
├─ "안 되", "오류", "문제" → solve
├─ "후기", "추천", "좋은" → recommend
├─ "뭐야", "무엇", "개념" → concept
└─ 모호한 경우 → default
여기서 실무적으로 가장 무거운 결정은 default다. 모호할 때의 default를 가장 넓은 category(예: 개념 설명)로 두면 결과가 계속 그쪽으로 쏠린다. 그런데 사람들이 브랜드에 대해 묻는 질문은 “이게 뭐야”보다 “이거 괜찮아”, “이거 써도 돼”에 가까운 경우가 흔하다. default를 실제 사용 패턴에 맞게 바꾸는 것만으로 분포가 크게 움직일 수 있다.
2. validation checklist로 한 번 더 거른다
결과를 만든 다음, 내보내기 전에 모델이 스스로 검사하게 한다.
| # | 검사 항목 | 실패 시 |
|---|---|---|
| 1 | 가격·비용 신호가 있는데 지금 분류가 맞나? | 재분류 |
| 2 | 비교 표현(“vs”, “대안”)이 있는데 지금 분류가 맞나? | 재분류 |
| 3 | 실행 동사(“설정하다”, “만들다”)가 있는데 지금 분류가 맞나? | 재분류 |
| 4 | 톤 규칙(어미 반복, 길이)을 지켰나? | 톤 수정 |
| 5 | 같은 어미가 3회 이상 반복되지 않았나? | 어미 변경 |
decision tree에서 놓친 오분류를 이 checklist가 두 번째로 잡는다. Plan과 Execute만 있으면 사실상 CoT와 크게 다르지 않다. P-E-V를 따로 부를 이유는 Validate에 있다.
checklist는 “신호와 category가 실제로 맞나”를 묻는 질문 목록으로 시작하면 된다. “가격을 언급했는데 이 category가 맞나” 같은 질문을 항목으로 만들고, 실패하면 재분류하라고 지시한다. 분류 기준이 늘면 checklist도 같이 늘린다.
3. 톤 규칙은 명시적 제약으로 넣는다
톤도 모델 판단에 맡기면 흔들린다. 한국어 출력이라면 “해요체 통일, 20–50자, 같은 어미 세 번 연속 금지” 같은 규칙을 적어야 결과가 고르게 나온다. 영어라면 단어 수 범위, 구어체 우선 같은 규칙을 넣는다.
prompt 로직은 한 곳에 모은다
P-E-V 로직이 여러 파일에 흩어지면 관리가 어려워진다. 하나의 prompt module을 single source of truth(SSOT)로 두는 편이 유지보수에 유리하다.
| 항목 | 분산 관리 | SSOT로 통합 |
|---|---|---|
| 수정이 필요할 때 | 여러 파일을 하나씩 수정 | 파일 1개만 수정 |
| 불일치 위험 | 높음 (따로 관리됨) | 낮음 |
| 테스트 범위 | 조각마다 따로 테스트 | 1곳 테스트로 전체 확인 |
decision tree의 신호 목록과 checklist 항목이 서로 다른 파일에 있으면, 신호를 하나 추가하고 checklist를 깜빡하는 일이 생긴다. 둘이 짝이라서 한 파일에 같이 둔다.
이 구조에서 반복해서 보이는 것
분류든 생성이든 pipeline에 이 구조를 넣으면 비슷한 패턴이 나온다.
model에 묶이지 않는다. P-E-V는 model이 아니라 prompt 구조다. decision tree와 validation checklist를 prompt에 넣는 방식이라 GPT·Gemini·Claude 계열 어디로 옮겨도 같은 구조로 쓸 수 있고, 비슷한 방향의 개선이 나온다. 다만 model마다 checklist를 얼마나 성실하게 따르는지는 다르니, 옮길 때는 정답 set으로 다시 재봐야 한다.
분포 균형에는 default가 가장 크게 작용한다. 모델은 모호한 입력에서 가장 넓은 category로 물러나니, default를 실제 사용 패턴에 가깝게 바꾸는 것만으로 쏠림이 꽤 풀리는 경우가 많다. 고치는 양은 가장 적은데 효과는 가장 크게 나는 지점이다.
decision tree만으로는 모자라다. decision tree가 1차 분류를 맡지만, “가격 비교”가 qualify인지 compare인지 같은 edge case는 검증 단계에서야 잡힌다. Validate가 빠지면 CoT와 다를 게 없다.
내가 prompt를 짠다면
엔지니어 입장에서 이 구조가 좋은 이유는 실패를 읽을 수 있게 만들어준다는 데 있다. “모델이 이상한 답을 냈다”가 아니라 “Plan에서 신호를 못 찾았다”, “default로 떨어졌다”, “checklist 3번에서 재분류됐어야 했다”처럼 어느 단계에서 틀렸는지 말할 수 있다. 그러면 고칠 곳도 그 단계 하나로 좁혀진다.
그래서 나는 새 분류·생성 prompt를 쓸 때 순서를 이렇게 잡는다. 먼저 신호 목록과 default를 정하고, 그다음 신호마다 짝이 되는 checklist 항목을 하나씩 만든다. 마지막으로 정답 label이 달린 작은 set을 두고 prompt를 바꿀 때마다 다시 돌린다. Validate 단계가 있어도 모델이 checklist를 건너뛰는 경우는 남으니, 정말 중요한 제약(길이, 금지어 같은 것)은 출력 뒤에 code로 한 번 더 검사한다. prompt 안의 self-check는 품질을 끌어올리는 장치이고, 보장은 code 쪽 검사가 맡는다.
