Pstack은 과한 오버스펙일까? 그래도 써봐야 하는 이유

원문 제목: [한영자막] Pstack은 과한 오버스펙일까요? 그래도 써봐야 하는 이유
원문 링크: https://www.youtube.com/watch?v=lf75rqTaO8s
발행일: 2026-09-13
채널: Tech Bridge

---

📌 핵심 질문 / Pstack이 필요한 순간은 언제인가

==Pstack은 모든 작업에 적용하는 만능 프레임워크가 아니라, 에이전트 여러 개를 활용해 중요한 기능을 만들고 실제 동작까지 엄격하게 증명해야 할 때 쓰는 고비용·고신뢰 작업 스택이다.==

• Lauren Tan의 원칙, 플레이북, 개별 스킬과 슬래시 명령을 하나의 작업 체계로 묶는다.
• Potato Mode가 20개가 넘는 스킬 중 먼저 쓸 것을 고르고, 22개 플레이북이 사용 사례와 프롬프트를 제공한다.
• Arena·Swarm·TDD·다중 모델 심문·실행 검증으로 에이전트의 비결정성과 환각을 통제한다.
• 단순한 UI 수정에는 과하지만, 실제 산출물의 정확성과 유지보수성을 중시하는 핵심 기능에는 추가 토큰과 시간을 지불할 가치가 있다.

Pstack의 핵심은 코드를 많이 생성하는 데 있지 않다. 최소 변경과 단순한 구조를 지키면서, 여러 에이전트의 작업을 병렬화하고, 사람이 직접 확인해야 할 부분은 검증 스크립트와 하위 에이전트로 분산하는 데 있다. 비교 실험에서 일반적인 방식은 약 30분, Pstack 방식은 1시간이 걸렸지만 결과물의 견고함에는 상당한 차이가 났다.

1. Pstack의 배경과 전체 구조

Pstack은 숙련 엔지니어의 판단 기준을 재사용 가능한 에이전트 작업 규칙으로 바꾼 구조다.

1.1. Lauren Tan의 경험과 스택의 목적

1. 숙련 엔지니어의 판단을 추출한 배경

   1. Lauren Tan의 이력: Lauren Tan은 스스로를 Ninja 엔지니어로 소개하며 Netflix에서 일했고 React 핵심 팀의 멤버였으며, SpaceX와 Cursor에서 principal engineer로 활동했다.
   2. 재사용 가능한 경험: 코딩 에이전트나 소프트웨어 팩토리를 구축하는 사람은 Lauren의 스킬 모음을 통해 숙련 엔지니어가 규모 있게 에이전트를 운영하는 방식을 배울 수 있다.

2. Pstack을 읽는 것 자체의 가치

   1. 사용 여부와 무관한 학습: Pstack을 실제로 설치하지 않더라도 스킬 내용을 읽으면 진지한 에이전트 실무자가 어떤 원칙과 절차로 일하는지 파악할 수 있다.
   2. 개발자용 패턴 모음: 각 스킬은 단순한 프롬프트 모음이 아니라, 요구사항 탐색·병렬 작업·검증·문맥 관리처럼 개발자가 알아둘 만한 실전 패턴을 보여준다.

1.2. 원칙에서 실행까지 이어지는 세 층

1. 원칙과 엔지니어링 규칙

   1. 판단 기준: 코드 삭제를 우선하는 게으름 프로토콜, 독자의 이해 부담 최소화, 검증 우선 같은 Lauren의 원칙이 상위 규칙을 이룬다.
   2. 일관된 행동 기준: 개별 작업의 프롬프트가 달라져도 에이전트가 단순성·유지보수성·실증을 우선하도록 공통 기준을 제공한다.

2. 플레이북과 개별 도구

   1. 플레이북: 플레이북은 운영 절차(operating procedure)처럼 에이전트가 다음에 무엇을 해야 하는지 알려주며, 서로 다른 사용 사례와 프롬프트 예시를 포함한다.
   2. 스킬과 슬래시 명령: 실제 파일 수정·분석·검증을 수행하는 개별 스킬과 슬래시 명령이 플레이북의 단계를 실행한다.

1.3. 설치 경로와 스킬 관리자

1. 여러 코딩 에이전트에서의 사용

   1. 공식 배포: Cursor에서는 Cursor와 Lauren이 관리하는 공식 저장소를 플러그인으로 설치할 수 있으며, /add-plugin pstack 명령으로 추가한다.
   2. 비공식 포팅: Claude Code, Codex, OpenCode에서 쓰려면 Michael Dener가 각 에이전트에 맞게 포팅한 비공식 저장소를 플러그인 마켓플레이스에서 설치할 수 있다.

2. Molton Base를 만든 이유

   1. 관리 문제: 에이전트를 2년 동안 사용하고 직접 스킬을 만들어온 진행자도 여러 에이전트 사이의 스킬을 한곳에서 관리할 적절한 도구를 찾지 못했다.
   2. 짧은 제작 실험: 그래서 단 한 오후에 모든 에이전트의 스킬을 관리하는 스킬 관리자 Molton Base를 직접 만들고, Pstack의 구조를 실제 제작 과정으로 살펴봤다.

2. Potato Mode와 에이전트 작업의 오케스트레이션

Potato Mode는 Pstack의 진입점으로서 작업 내용을 분석하고 필요한 스킬의 순서를 라우팅한다.

2.1. 스킬 라우터와 플레이북 트리

1. Potato Mode의 역할

   1. 첫 스킬 선택: 20개가 넘는 스킬 중 현재 요청에 가장 먼저 적용할 것을 결정하는 라우터다.
   2. 작업 경로 제시: 22개 플레이북과 각 플레이북의 사용 사례·프롬프트가 결합되어, 막연한 요청을 실행 순서로 바꾼다.

2. 직접 만든 스킬 관리자에 적용한 방식

   1. 하나의 출발 프롬프트: 스킬 관리자를 만들어달라는 단일 프롬프트를 Potato Mode에 주고 어떤 플레이북으로 시작하는지 관찰했다.
   2. Figure It Out 라우팅: Potato Mode는 처음부터 figure it out 플레이북으로 요청을 보냈으며, 이는 이미 존재하는 코드베이스에서 문제를 탐색하고 해결하는 흐름이다.

2.2. 계획보다 코드와 현실을 우선하는 관점

1. Pstack의 의도적인 빈자리

   1. 계획용 스택과의 차이: BMAD, Superpowers, OpenSpec처럼 명세와 계획을 먼저 만드는 체계를 기대할 수 있지만, Pstack은 이미 구축된 코드베이스에서 작동하도록 설계됐다.
   2. 계획 스킬의 부재: Lauren은 “최고의 명세는 코드”라고 보기 때문에 Pstack에 별도의 planning 스킬을 의도적으로 넣지 않았다.

2. 현실이 설계를 바꾸는 방식

   1. 선행 계획의 한계: 에이전트가 매우 상세한 계획을 세워도 실제 코드·환경·제약을 아직 겪지 않았으므로 계획 속 가정이 깨질 수 있다.
   2. 즉석 재계획: 구현이 진행되며 가정이 무너지면 그 현실에 맞춰 문제를 다시 정의하고 새 계획을 세우는 편이 더 정확하다.

2.3. Arena와 Swarm으로 병렬 작업하기

1. Arena의 경쟁형 병렬성

   1. 동일 문제의 다중 해법: Claude, GPT, Grok, Claude Opus 5 같은 세네 개의 모델·에이전트에 같은 설계 문제를 동시에 맡긴다.
   2. 최종 커밋 합성: 각 하위 에이전트가 만든 설계의 장점을 모아 최종 커밋에 반영하며, 각 결과에서 배운 내용을 바탕으로 graft(이식)할지 reject(거부)할지 결정한다.
   3. 비용과 선례: 토큰 예산을 크게 소모하며, Cursor에도 약 6개월 전 비슷한 기능이 내장됐다가 나중에 제거된 사례가 있었다.

2. Swarm의 분할형 병렬성

   1. 서로 다른 문제 조각: Swarm은 여러 작업자에게 문제의 서로 다른 부분을 나눠 맡긴다.
   2. 통합 보고서: 각 작업자의 결과를 다시 모아 하나의 집계 보고서로 만들며, feature branch나 worktree를 가로지르는 작업을 통합하는 흐름을 지향한다.
   3. 검증되지 않은 큰 주장: Pstack은 서로 겹치는 작업 없이 fearless parallelism을 제공한다고 설계돼 있지만, 실제로 중복이 항상 제거되는지는 충분히 사용해보지 않아 단정할 수 없다.

2.4. 개발 중 사용하는 핵심 스킬

1. TDD와 Why

   1. TDD(Test-Driven Development): 구현에 앞서 단위 테스트를 여러 개 만들고, 테스트가 통과하는지 확인한 다음 다음 단계로 진행한다.
   2. Why 스킬: 프로젝트 트랜스크립트만 확인하지 않고 관련된 MCP와 CLI를 훑는다. PostHog의 제품 정보, Slack의 기능 결정 대화, Sentry 로그와 ADR(Architecture Decision Record)을 엮어 어떤 결정이 왜 내려졌는지 큰 그림을 복원한다.

2. Recall과 문맥 복원

   1. 중단된 프로젝트 재개: 일주일 정도 프로젝트를 떠났다가 돌아왔을 때 현재 상태와 다음 작업을 파악하는 용도다.
   2. 다중 기록 탐색: 모든 트랜스크립트를 검색하고 Why 스킬을 통해 Notion·Linear·PostHog 같은 MCP도 확인하여 진행 상황과 다음 할 일을 복원한다.

3. 검증, 글쓰기, 사람의 인지 부담을 다루는 스킬

에이전트가 코드를 만들었다는 사실보다 실제 산출물이 올바르게 작동한다는 증명이 중요하다.

3.1. Interrogate와 검증 스크립트

1. Interrogate의 다중 모델 리뷰

   1. 교차 심문: 서로 다른 두세 모델이 동일한 코드를 기준과 표준에 맞춰 다시 심문하고 검토한다.
   2. 의견 비교: 각 모델의 판단을 나란히 받아 단일 모델의 실수나 놓친 문제를 드러낸다.

2. Create Verification과 Maintain Verification

   1. 행동 증명 자동화: Create Verification은 앱의 실제 동작을 증명하기 위한 스크립트, 교차 점검, 반복 가능한 확인 절차를 만든다.
   2. 넓은 실패 표면 다루기: 여러 프로젝트와 설정의 루트까지 살피고 계속 업데이트 여부를 점검한다. 앱이 겉으로 작동하는 것처럼 보여도 근본적으로 망가졌거나 잘못된 데이터를 줄 수 있기 때문이다.
   3. 검증기의 노후화 방지: 앱이 발전하면 기존 스크립트와 검증기가 구현과 어긋난다. Maintain Verification은 검증기 자체를 다시 확인하고 현재 개발 상태에 맞게 갱신한다.

3.2. Onslaught와 Bro

1. Onslaught의 글쓰기 정리

   1. AI 흔적 제거: 글에서 pivotal moment, crucial, delve, enduring처럼 반복적으로 등장하는 인상적인 표현을 찾아 제거한다.
   2. Em dash 처리: 긴 대시(EM dash)를 전부 없애는 규칙도 포함한다. 진행자는 AI가 썼다는 신호로 인식될 수 있다는 점에는 동의하지만, AI 이전부터 EM dash를 좋아했다며 아쉬움을 덧붙였다.

2. Bro의 인지 부하 완화

   1. 평이한 재서술: 병렬 에이전트를 오전 내내 돌려 머리가 멈출 만큼 복잡해졌을 때 마지막 메시지를 전문 용어 없이 평범한 인간의 말로 다시 쓴다.
   2. 명료성 회복: Bro는 에이전트의 장황한 결과를 빠르게 이해하고 다음 판단을 내리도록 돕는 명료성 도구다.

4. Show Me Your Work으로 본 실제 제작 흐름

단일 프롬프트로 시작한 작업은 탐색·설계 경쟁·검증·감사의 순서로 진행됐다.

4.1. Probe로 가능성과 제약 확인

1. 작은 실험으로 시작하기

   1. 가능성 점검: 전체 앱을 바로 만들지 않고 작은 스크립트를 작성해 원하는 결과가 실제로 가능한지 먼저 시험한다.
   2. 요구사항 프레임: 초기 단계에서 요구사항과 제약을 파악해 무엇을 만들 수 있고 무엇을 아직 결정하지 않았는지 경계를 만든다.

2. 플랫폼 범위 정하기

   1. 현재 대상: 첫 구현은 Mac에서 작동해야 한다는 조건을 반영했다.
   2. 확장 가능성: 이후 다른 시스템에서도 작동해야 하므로 현재 구현의 편의만 좇지 않고 이식 가능성까지 초기 프레임에 포함했다.

4.2. 스캐폴딩에서 Arena로 이동

1. 기본 골격 만들기

   1. 최소 스캐폴딩: 가능성을 확인한 뒤 앱의 기본 구조를 먼저 세웠다.
   2. 현실을 만날 준비: 상세 계획으로 모든 것을 고정하기보다 구현 과정에서 설계가 바뀔 수 있도록 초기 골격을 가볍게 유지했다.

2. 네 개 에이전트의 설계 경쟁

   1. 병렬 구현: 기본 스캐폴딩 다음 Arena 단계에서 네 개의 병렬 에이전트가 같은 문제를 해결했다.
   2. 현실에 의해 강제된 설계 변경: 상세 계획이 아직 현실을 겪지 않은 상태에서 만들어졌기 때문에, 실제 개발 중 가정이 깨질 때 설계를 수정하고 새로운 접근을 세웠다.

4.3. 검증과 감사로 거짓 주장을 바로잡기

1. 마지막 단계의 구성

   1. Phase E 검증: 구현 뒤에는 검증 테스트가 이어졌고, 작업 흐름은 최종 audit으로 끝났다.
   2. 동작이 아닌 주장까지 검사: 테스트 통과만 확인하지 않고, 에이전트가 설명한 세부사항이 실제 산출물과 맞는지 살폈다.

2. 환각 발견 사례

   1. 세 가지 허위 주장: 에이전트는 일부 세부사항을 환각했다는 사실을 스스로 파악했고, 검증 과정에서 거짓 주장을 세 개 발견했다.
   2. 수정 가능성: 검증은 문제를 지적하는 데서 끝나지 않고 세 가지 잘못된 주장을 바로잡아 결과물의 신뢰성을 높였다.

5. Lauren Tan의 핵심 엔지니어링 원칙

Pstack을 특별하게 만드는 요소는 스킬 개수보다 각 스킬에 반복해서 적용되는 작업 철학이다.

5.1. 덜 만들고, 처음부터 다시 생각하고, 읽기 쉽게 만들기

1. Laziness Protocol

   1. 삭제 우선 리팩터링: 리팩터링할 때 코드를 더 추가하기 전에 지울 수 있는 코드를 찾고 구조를 단순하게 만든다.
   2. 최소 변경: 일을 끝내는 데 필요한 가장 작은 변경을 선택한다. 작은 변화는 장기적으로 유지보수하기 쉬운 코드로 이어질 가능성이 높다.

2. Redesigning from First Principles

   1. 처음부터 넣었다고 가정하기: 커지는 프로젝트에 새 기능을 덧붙일 때 단순히 기존 구조에 기능을 볼트로 붙이지 않고, 첫날부터 그 기능이 있었다면 구조를 어떻게 설계했을지 다시 묻는다.
   2. 구조의 재편: 데이터베이스·스캐폴딩·자료구조까지 원점에서 검토하며, 더 자연스러운 기능이 되려면 기존 구조와 코드 일부를 오히려 제거할 수도 있다.
   3. 최소 코드의 최대 효과: 목표는 코드의 양을 늘리는 것이 아니라 가장 적은 코드로 최대 효과를 내는 것이다.

3. Minimizing Reader Load

   1. 에이전트가 만든 거대한 PR 문제: 여러 추상화와 모듈에 코드가 흩어진 큰 PR은 리뷰어가 전체 동작을 이해하기 어렵게 만든다.
   2. 추상화 절제: 독자가 따라가야 할 경로를 짧게 유지하고, 필요한 최소한의 추상화만 사용해 구조를 단순하게 만든다.

5.2. 설계 공간을 탐색하고 반복 작업을 레버리지로 바꾸기

1. Exhaust the Design Space

   1. 다중 설계 비교: Arena로 여러 모델과 에이전트가 같은 문제의 서로 다른 해법을 만들게 한다.
   2. 최선의 조합: 각 설계의 좋은 부분을 비교한 뒤 최선의 요소를 최종 커밋에 이식한다.
   3. Design Mode와의 연결: 데이터베이스나 백엔드 코드를 만들기 전에 인터페이스 변형 몇 가지를 스캐폴딩해 디자인 선택지를 먼저 비교하는 방식과 같은 원리다.

2. Build a Lever

   1. 반복 작업의 도구화: 에이전트에게 같은 작업을 손으로 여러 번 시킬 예정이라면 CLI나 스크립트로 도구를 만들어 반복 비용을 낮춘다.
   2. 검증의 레버리지: 매번 수동으로 확인할 검증을 재실행 가능한 스크립트로 만들면, Create Verification처럼 같은 품질 기준을 지속적으로 적용할 수 있다.

5.3. 검증과 문맥 관리

1. 초록불과 실제 증명은 다르다

   1. 컴파일의 한계: 코드가 컴파일되고 테스트가 초록색이 됐다는 사실은 실제 산출물이 올바르게 작동한다는 뜻과 같지 않다.
   2. 깊은 검증: 컴퓨터 사용(computer use)이나 엔드투엔드 테스트를 통해 실제 아티팩트의 동작을 확인하고 증명해야 한다.

2. Context Window를 지키고 사람을 막지 않기

   1. 중앙 문맥 보호: 중앙 에이전트의 context window는 핵심 자원이므로 모든 세부 작업을 한 대화 안에 쌓지 않는다.
   2. 하위 에이전트 위임: 작업 조각을 고유한 context window를 가진 하위 에이전트에게 보내고, 결과만 중앙 스레드로 보고받아 사람이 전체 흐름을 잃지 않게 한다.

6. 비용 대비 효과와 적용 범위

Pstack은 더 엄격한 품질을 얻기 위해 시간·토큰·비용을 의도적으로 늘리는 선택이다.

6.1. 비교 실험이 보여준 트레이드오프

1. 소요 시간

   1. 기본 방식: Fable 5.1을 plan mode 없이, 연결된 스킬 없이 사용했을 때 프로젝트 완성까지 약 30분이 걸렸다.
   2. Pstack 방식: Pstack을 사용하자 약 1시간이 걸려 작업 시간이 두 배가 됐다.

2. 결과물과 비용

   1. 품질 차이: 시간은 두 배였지만 두 프로젝트 사이의 결과 차이는 상당했다. 검증과 감사가 포함된 Pstack 결과가 훨씬 더 hardened application에 가까웠다.
   2. 토큰 소모: 다중 모델 Arena, Swarm, 검증, 심문은 모두 토큰을 많이 사용한다. Pstack을 저장소에 구성하는 것 자체도 일반 방식보다 훨씬 많은 비용을 만든다.

6.2. 어떤 작업에 적용할 것인가

1. 적합한 작업

   1. 중요 기능: 실패 비용이 높거나 정확성과 엄격한 코드 품질이 중요한 기능은 여러 해법 비교와 실제 검증에 토큰을 쓸 가치가 있다.
   2. 복잡한 기존 코드베이스: 여러 프로젝트·설정·외부 기록을 함께 이해해야 하거나, 작업을 병렬로 쪼개야 하는 규모라면 Why·Recall·Swarm의 가치가 커진다.

2. 과한 작업

   1. 작은 디자인 변경: 작은 디자인 수정에 Arena와 전체 검증 체계를 동원하면 추가 시간과 비용이 결과의 가치보다 커질 수 있다.
   2. 프런트엔드 UI 작업: 단순한 프런트엔드 UI 작업은 Pstack의 고비용 병렬·검증 파이프라인 없이도 충분히 처리할 수 있다.
   3. 선별적 사용: 모든 프로젝트에 “감자(potato)를 던질” 필요는 없으며, 어떤 종류의 문제에서 Pstack이 강점을 보이는지 이해하고 필요한 단계만 선택해야 한다.

주요 발언 모음

“Pstack은 숙련 엔지니어의 뇌를 하나의 스택으로 추출한 것과 같다.”

“최고의 명세는 코드다.”

“목표는 더 많은 코드가 아니라, 가장 적은 코드로 최대의 효과를 내는 것이다.”

“컴파일되고 테스트가 초록색이라는 것은 실제 아티팩트가 작동한다는 것과 같지 않다.”

“문맥 창을 지키고, 사람을 절대 막히게 하지 마라.”

“모든 프로젝트에 감자를 던질 필요는 없지만, 무엇에 좋고 어디에 쓸 수 있는지는 알아야 한다.”

핵심 데이터 & 수치

• 20개 이상 스킬: Potato Mode가 작업에 먼저 적용할 스킬을 라우팅한다.
• 22개 플레이북: 서로 다른 사용 사례와 프롬프트를 제공한다.
• 세네 개 모델·에이전트: Arena가 동일한 문제에 병렬로 투입해 설계 장점을 비교한다.
• 네 개 병렬 에이전트: Molton Base 제작 실험의 Arena 단계에서 같은 문제를 작업했다.
• 세 가지 허위 주장: 검증·감사 과정에서 에이전트의 환각성 세부사항을 찾아 수정했다.
• 30분 대 1시간: 스킬과 plan mode가 없는 Fable 5.1 방식과 Pstack 방식의 프로젝트 완성 시간이다.
• 약 2배의 시간: Pstack은 더 오래 걸렸지만 결과물의 견고함에서 상당한 차이를 냈다.
• 약 6개월: Cursor에 Arena와 유사한 기능이 내장됐다가 제거된 시점에 대한 언급이다.

결론 및 시사점

1. Pstack은 에이전트에게 일을 시키는 프롬프트 모음이 아니라 원칙·플레이북·실행 스킬·검증 체계를 연결한 운영 시스템이다.
2. Potato Mode는 복잡한 스킬 목록을 라우팅해 사용자가 매번 어떤 도구부터 골라야 하는지 판단하는 부담을 줄인다.
3. Arena는 같은 문제의 여러 해법에서 좋은 부분을 선택하고, Swarm은 문제를 분할해 병렬로 처리한 뒤 결과를 통합한다.
4. Why와 Recall은 코드만 읽지 않고 제품 데이터·대화·로그·의사결정 기록까지 연결해 프로젝트의 맥락을 복원한다.
5. Interrogate와 Create Verification은 다중 모델 리뷰와 실행 가능한 증거를 통해 단일 에이전트의 환각을 줄인다.
6. TDD의 초록불만으로는 충분하지 않으며 컴퓨터 사용이나 엔드투엔드 테스트로 실제 결과물을 검증해야 한다.
7. 가장 실용적인 원칙은 코드를 추가하기 전에 삭제하고, 새 기능을 처음부터 설계했다고 가정하며, 독자의 읽기 부담을 낮추는 것이다.
8. 모든 단계를 매번 적용하지 말고 작은 UI 변경은 가볍게 처리하되, 실패 비용이 높은 핵심 기능에는 Pstack의 비용을 투자하는 편이 합리적이다.

핵심 요약 (20줄)

Lauren Tan은 Netflix, React 핵심 팀, SpaceX, Cursor를 거친 엔지니어로 소개된다. Pstack은 숙련 엔지니어의 원칙과 작업 방식을 에이전트가 재사용할 수 있는 스택으로 묶는다. Pstack은 엔지니어링 규칙, 운영 절차인 플레이북, 실행 스킬과 슬래시 명령으로 구성된다. Cursor에서는 공식 플러그인을 /add-plugin pstack으로 설치할 수 있다. Claude Code, Codex, OpenCode에서는 Michael Dener의 비공식 포팅 저장소를 활용할 수 있다. Molton Base는 여러 에이전트에 흩어진 스킬을 관리하기 위해 한 오후에 만들어진 스킬 관리자다. Potato Mode는 20개가 넘는 스킬 중 현재 작업에 먼저 적용할 것을 고르는 라우터다. Pstack에는 22개 플레이북과 다양한 사용 사례 및 프롬프트가 들어 있다. Pstack은 명세와 계획보다 이미 존재하는 코드베이스에서의 실행을 중시한다. Arena는 같은 문제를 세네 개 에이전트에 맡겨 최선의 설계를 최종 커밋으로 합친다. Swarm은 문제를 여러 조각으로 나눠 병렬 처리한 뒤 하나의 보고서로 통합한다. TDD 스킬은 구현 전에 단위 테스트를 만들고 통과 여부를 확인한다. Why 스킬은 PostHog, Slack, Sentry와 ADR을 살펴 결정의 배경을 복원한다. Recall은 오랫동안 중단한 프로젝트의 트랜스크립트와 외부 기록을 검색해 다음 일을 찾는다. Interrogate는 두세 모델의 독립적인 코드 리뷰를 받아 기준 위반을 교차 점검한다. Create Verification과 Maintain Verification은 실행 검증기와 검증기 자체의 최신 상태를 관리한다. Onslaught는 AI 특유의 상투어와 EM dash를 제거하고 Bro는 복잡한 결과를 쉬운 말로 다시 쓴다. 실험에서 Probe, 스캐폴딩, 네 에이전트 Arena, 검증, 감사가 하나의 단일 프롬프트 흐름으로 이어졌다. 검증은 에이전트가 만든 세 가지 허위 주장을 찾아 수정했으며 테스트 통과 이상의 안전장치가 됐다. Pstack은 약 30분을 1시간으로 늘리지만, 중요한 기능에 더 견고한 결과를 제공하므로 작업별로 선별 적용해야 한다.