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

[아키텍처/패턴 (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

8.9 KiB Raw Blame History