# [[Plan-Execute-Verify (PEV) Loop]]

## 📌 Brief Summary
PEV(Plan-Execute-Verify) 루프는 에이전트의 계획 수립과 실행을 분리하고, 검증을 구조화된 피드백 루프로 강제하는 3단계 에이전트 아키텍처 패턴이다 [1]. 이 패턴은 대형 언어 모델(LLM)이 복잡한 다단계 문제를 단 한 번의 시도로 해결하도록 요구하는 대신, 작업을 명시적인 계획으로 분해(Plan)하고, 그 계획의 경계 내에서 실행(Execute)하며, 결과물을 계획 및 외부 품질 기준과 대조하여 검증(Verify)하도록 지시한다 [1]. 이를 통해 에이전트의 자율적 비결정성(non-determinism)을 통제하고 신뢰할 수 있는 실행 결과를 보장한다 [2].

## 📖 Core Content
PEV 루프는 전통적인 '생성 후 검사(Generate-and-Check)' 방식과 구조적으로 구별되는 특성을 가지며, 각 단계에서 에이전트의 자율성을 제한하고 검증을 강제한다 [3].

*   **Plan (계획 단계)**: 
    *   에이전트가 즉시 코드를 생성하거나 행동하는 대신, 문제를 명시적으로 분해하고 수용 기준(acceptance criteria)을 포함한 계획을 수립한다 [1, 3].
    *   계획 단계에서 자유도(degrees of freedom)를 줄임으로써, 동일한 작업에 대해 매번 다른 추론 경로가 생성되는 비결정성 문제를 해결한다 [2].
*   **Execute (실행 단계)**: 
    *   에이전트의 실행 범위는 수립된 계획에 의해 엄격하게 제한된다 [3].
    *   모든 도구 호출(tool call) 시마다 하네스 게이트가 작동한다. 실행 전 게이트(Pre-execution gates)는 도구 호출이 이루어지기 전에 개입하여 해당 도구가 알려진 도구인지, 인자가 유효한지, 사용자 승인이 필요한지, 요청된 작업 범위가 작업 공간 내에 있는지를 확인하고 범위를 벗어난 호출을 차단한다 [2, 3].
*   **Verify (검증 단계)**: 
    *   사후 검증(Post-hoc only)에 그치지 않고, 실행 전, 런타임, 실행 후 및 계획 일치성(plan alignment) 전반에 걸쳐 검증이 이루어진다 [3].
    *   단순한 이진 합격/실패(binary pass/fail)가 아니라, 컨텍스트가 포함된 에러 메시지를 에이전트의 추론 과정으로 다시 피드백(feedback)하여 자기 수정을 돕는다 [3].
    *   표준 테스트 러너(test runner)로는 파악할 수 없는 아키텍처적 질문들(예: 기존 인증 미들웨어를 사용했는가, 아니면 새로 만들었는가? 응답 형식 규칙을 따랐는가?)을 평가하는 '계획 일치성(plan alignment)' 검증 게이트가 존재한다 [2].

## ⚖️ Trade-offs & Caveats
PEV 루프 아키텍처를 도입할 때 다음과 같은 제약 사항 및 트레이드오프가 존재한다.

*   **실행 오버헤드 증가**: 에이전트가 단일 패스로 문제를 해결하는 것을 명시적으로 차단하고 계획-실행-검증의 3단계를 강제하므로, 간단한 작업에서도 시스템의 복잡도와 처리 대기 시간(Latency)이 증가할 수 있다 [1, 3].
*   **하네스 유지보수 부담**: PEV 루프가 제대로 작동하기 위해서는 런타임 및 실행 전후의 여러 단계에서 도구 호출을 차단하거나 허용하는 게이트(gates)를 촘촘하게 설계해야 한다. 인간은 결과물 자체를 리뷰하는 대신 하네스를 유지보수하고 영향력이 큰 결정 지점에서 승인하는 역할을 맡게 되어, 초기 인프라(하네스) 구축 및 관리 비용이 크게 증가한다 [3].
*   **검증 로직 구현의 어려움**: 코드가 실행되는지 여부를 판단하는 테스트 스위트 외에도, 에이전트가 수립된 계획과 기존 아키텍처 규칙을 준수했는지 확인하는 '계획 일치성(plan alignment)' 검증 로직을 하네스에 별도로 구축해야 하는 기술적 어려움이 따른다 [2].

## 🔗 Knowledge Connections

### Related Concepts

#### [아키텍처/패턴 (Architecture / Pattern)]
- [[Generate-and-Check]]
  - 연결 이유: PEV 패턴과 대비되는 전통적인 에이전트 실행 방식이기 때문이다.
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 계획 없이 자유롭게 실행한 후 사후 검증(Post-hoc)과 이진 피드백(binary pass/fail)만 제공하는 방식이 가진 한계를 이해하고, PEV 루프의 구조적 필요성을 명확히 할 수 있다 [3].

- [[Agent Harness]]
  - 연결 이유: PEV 루프는 에이전트 하네스가 제공하는 결정론적 제어(게이트, 피드백 루프) 위에서 작동하는 하네스 설계 패턴이기 때문이다.
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 언어 모델(LLM) 자체의 지능을 넘어, 주변을 둘러싼 실행 환경과 규칙(하네스)이 에이전트의 신뢰성을 어떻게 보장하는지 이해할 수 있다 [1].

#### [검증 및 제어 메커니즘 (Verification & Control Mechanisms)]
- [[Pre-execution gates]]
  - 연결 이유: PEV 루프의 실행(Execute) 단계에서 에이전트의 도구 호출을 실제로 통제하는 핵심 하네스 메커니즘이기 때문이다.
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 에이전트가 승인되지 않은 도구를 사용하거나 작업 범위를 벗어난 행동을 시도할 때, 시스템이 이를 실행 전에 결정론적으로 어떻게 차단하는지 파악할 수 있다 [2].

- [[Plan alignment]]
  - 연결 이유: PEV 루프의 검증(Verify) 단계에서 중요하게 다루어지는 평가 기준으로, 에이전트 산출물의 아키텍처적 일관성을 의미하기 때문이다.
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 단순히 단위 테스트를 통과하는 것을 넘어, 기존 코드베이스의 규칙이나 구조(예: 미들웨어 재사용, 응답 포맷)를 준수했는지 검증하는 심층적인 평가 방식을 이해할 수 있다 [2].

### Deeper Research Questions
- 단순한 Generate-and-Check 패턴과 비교하여, PEV 루프 아키텍처를 사용할 때 필연적으로 증가하는 API 호출 횟수 및 토큰 소모 비용을 하네스 레벨에서 어떻게 최적화할 수 있는가?
- 실행 전 게이트(Pre-execution gates)는 에이전트의 도구 인자(argument) 및 접근 권한의 유효성을 어떠한 결정론적(deterministic) 방식으로 평가하는가?
- 코드 테스트 러너(test runner)로는 확인 불가능한 '계획 일치성(Plan alignment)' 및 아키텍처 준수 여부를 자동화된 하네스 게이트로 구현하기 위해 어떤 기술적 접근이 필요한가?
- PEV 루프를 통해 에이전트에게 제공되는 '컨텍스트가 포함된 에러 피드백'은 에이전트의 자가 수정(self-correction) 성공률을 얼마나 향상시키는가?
- 계획 단계(Plan)에서 자유도를 의도적으로 제한하는 것이, 예기치 않은 창의적 해법을 도출할 수 있는 에이전트의 능력을 저해하는 부작용(Trade-off)은 없는가?

### Practical Application Contexts
- **Implementation:** 복잡한 소프트웨어 개발 작업을 자율 에이전트에게 위임할 때, 한 번의 프롬프트로 전체 코드를 짜게 하지 않고 요구사항 분석 및 계획서 작성, 승인, 실행, 검증의 다단계 워크플로우로 나누어 구현할 때 적용된다.
- **System Design:** 에이전트가 호스트 시스템에서 파괴적인 도구(예: 셸 명령어, 파일 덮어쓰기)를 무분별하게 사용하는 것을 막기 위해 툴 호출 인터셉터(Pre-execution gates)를 설계할 때 활용된다.
- **Operation / Maintenance:** 인간 작업자가 에이전트가 만든 코드를 일일이 리뷰하는 방식에서 벗어나, 에이전트의 계획을 승인하고 하네스 검증 규칙을 유지보수하는 방향으로 운영 모델을 전환할 때 핵심적인 기준이 된다.
- **Learning Path:** LLM을 단순한 추론 엔진을 넘어, 엔터프라이즈 환경에서 안전하게 배포 가능한 '신뢰할 수 있는 워크엔진'으로 격상시키는 하네스 엔지니어링의 핵심 아키텍처 패턴을 학습할 때 필수적이다.
- **My Project Relevance:** 다중 에이전트 시스템이나 자율 코딩 에이전트를 개발할 때, 에이전트가 무한 루프에 빠지거나 엉뚱한 라이브러리를 임의로 생성하여 사용하는 문제(환각)를 통제하기 위한 파이프라인 설계에 직접적으로 적용 가능하다.

### Adjacent Topics
- [[Self-verification]]
  - 확장 방향: 에이전트가 외부의 하네스 피드백뿐만 아니라 스스로 자신의 산출물을 평가하고 비판(critique)하여 수정하는 메커니즘이 PEV의 검증 단계와 어떻게 통합되는지 탐구.
- [[Human-in-the-Loop (HITL)]]
  - 확장 방향: PEV 루프 내에서 인간이 개입해야 하는 영향력이 큰 결정 지점(high-leverage decision points)을 어떻게 식별하고 승인 워크플로우를 설계할지에 대한 연구.

---
*Last updated: 2026-05-01*