출처: https://youtu.be/lf75rqTaO8s · 채널: Tech Bridge · 길이: 00:11:34 포맷: 발표자 1인의 설명형 영상(A형). 발표자 화면과 Pstack의 슬라이드·저장소·코드 화면을 교차 편집한다. 자막: YouTube
ko자동 트랙을 본문 기준으로 사용하고en자동 트랙을 대조용으로 보존했다. 자동자막의 반복 cue는 raw에 그대로 남겼고, 아래 설명에서만 중복을 제거했다. Pstack의 실제 저장소·구현·효과는 이 영상에서 주장·소개한 범위만 기록하며, 별도 검증한 사실로 확장하지 않는다.
한눈에 보는 요약
- Pstack은 단순 프롬프트 모음이 아니라 원칙(principles)·플레이북(playbooks)·스킬(skills)을 묶어 코딩 에이전트의 작업 방식을 규정하는 스택으로 소개된다.
- 핵심은 계획 문서를 먼저 완성하는 것이 아니라, 이미 존재하는 코드베이스에서 조사·구현·검증·회고를 반복하는 운영 규율이다.
- Arena와 Swarm은 여러 에이전트를 병렬로 사용해 설계 공간을 넓히지만, 그만큼 토큰·시간 비용과 통합 복잡성이 늘어난다.
- Recall, probe,
show-me-your-work,create-verification-skill같은 패턴은 에이전트의 기억·탐색·증거·실제 결과물 검증을 보강한다. - 결론은 “모든 작업에 Pstack을 던지지 말라”이다. 작은 UI 변경에는 과하고, 오래 유지할 애플리케이션이나 검증 비용이 큰 작업에는 강한 하네스로 쓸 수 있다는 영상 속 판단이다.
핵심 한 줄: Pstack의 가치는 에이전트를 더 많이 부르는 데 있지 않고, 병렬성·컨텍스트·검증을 반복 가능한 개발 규율로 묶는 데 있다.
장면별 상세 설명
[00:10] 1. Pstack을 보는 관점 — 엔지니어링 원칙의 압축
영상은 Pstack을 특정 모델의 프롬프트 팩이라기보다 로렌 탄의 엔지니어링 원칙을 하나의 작업 스택으로 압축한 것으로 소개한다. 슬라이드는 principles, playbooks, skills를 별도 층으로 보여주며, 코딩 에이전트를 만들거나 소프트웨어 팩토리를 운영하는 사람이 실제 개발 습관을 관찰하는 사례로도 읽을 수 있다고 말한다.
[00:45] 2. 세 층 구조 — 원칙, 절차, 개별 행동
Pstack의 원칙은 “어떻게 엔지니어링할 것인가”를, 플레이북은 “다음에 무엇을 할 것인가”를, 스킬과 슬래시 명령어는 실제 작업 단위를 담당한다. 따라서 에이전트가 매번 빈 프롬프트에서 판단하지 않고, 조사·수정·검증 같은 반복 동작을 재사용할 수 있다는 설명이다. 이 계층화는 에이전트 하네스가 모델 자체보다 작업 환경과 루프를 설계하는 문제라는 관점과 닿아 있다. moc-ai-agents-harness
[01:15] 3. 설치 예시 — 기존 도구 안으로 가져오기
영상은 Cursor에서 /add-plugin pstack을 입력하는 예시와 plugins/pstack 경로를 보여준다. 영상에서 언급한 플러그인은 pstack이다. 발표자가 제시한 설치 흐름일 뿐, 이 노트는 해당 저장소의 현재 공개 상태나 호환성을 별도로 검증하지 않는다. 핵심 메시지는 Pstack을 독립 실행 제품이라기보다 기존 코딩 에이전트에 주입하는 작업 규칙 묶음으로 설명한다는 점이다.
[01:43] 4. 플레이북은 작업 선택기다
화면에는 investigation, bug fix, perf, feature 같은 플레이북 목록이 보인다. 발표자는 이를 “감자 모드(potato mode)”라고 부르며, 20개가 넘는 스킬 가운데 어떤 작업부터 적용할지 라우팅하는 입구로 설명한다. 플레이북은 각 프롬프트와 사용 사례 예시를 함께 제공해, 에이전트가 문제를 곧바로 코딩으로 오인하지 않게 하는 역할을 한다.
[02:10] 5. 계획 우선 도구와의 차이 — 이미 있는 코드베이스에서 시작하기
Pstack은 BMAD·Superpowers·OpenSpec 같은 사양·계획 중심 도구를 대체하려는 것으로 소개되지 않는다. 영상 속 구분은 새로운 설계를 문서로 확정하는 단계보다 이미 만들어진 코드베이스를 운영하고 개선하는 단계에 초점을 둔다는 것이다. 발표자는 “최고의 사양은 코드”라는 로렌의 관점을 전하며, 계획을 완성한 뒤 현실을 맞추기보다 구현 과정에서 가정을 검증한다고 설명한다. 이는 영상 속 설계 철학이지 모든 프로젝트에 적용해야 할 규칙으로 검증된 것은 아니다.
[02:45] 6. Arena — 같은 문제를 여러 에이전트에게 맡기기
Arena는 서너 개의 서로 다른 에이전트가 같은 문제를 각각 풀게 한 뒤, 결과에서 가장 좋은 부분을 모으는 방식으로 설명된다. 영상의 다이어그램은 여러 입력이 하나의 결과로 합쳐지는 구조다. 중요한 전제는 병렬 호출 그 자체가 정답을 보장하지 않는다는 점이다. 설계 후보를 넓히고 비교하는 비용을 지불해 더 나은 결정을 얻는 패턴이다.
[03:30] 7. 조사와 테스트 — 에이전트가 근거를 먼저 찾게 하기
영상은 먼저 단위 테스트를 작성하고 통과 여부를 확인한 뒤 진행하는 TDD를 좋은 사례로 든다. 또 프로젝트 성적표만 읽는 데서 멈추지 않고 MCP·CLI, Slack의 결정 스레드, Sentry 로그, ADR까지 확인해 “왜 이렇게 만들어졌는가”를 복원하는 조사 스킬을 소개한다. 코드를 고치는 능력보다 현재 시스템의 의도와 제약을 회수하는 능력이 먼저라는 메시지다.
[04:20] 8. Recall — 중단한 작업을 다시 시작하는 컨텍스트 회수
일주일 뒤 중단한 프로젝트를 다시 열었을 때 Recall은 녹취록과 작업 흔적을 훑고, 무엇을 했는지·왜 했는지·다음에 무엇을 할지를 복원한다. 화면에는 “왜?”라는 질문으로 Notion·Linear·PostHog 같은 외부 맥락을 확인하는 지침이 보인다. 단순히 이전 답변을 기억하는 것이 아니라, 결정 기록과 현재 상태를 다시 읽어 컨텍스트를 재구성하는 방식이다. moc-ai-agents-memory
[05:10] 9. 검증 스킬 — 컴파일보다 실제 동작을 확인하기
Pstack에는 두세 개의 서로 다른 모델로 코드를 심문하듯 검토하는 interrogate와, 애플리케이션의 동작을 증명할 스크립트를 만드는 create-verification-skill이 소개된다. 발표자는 앱이 작동하는 것처럼 보이는 상태와, 결과물을 실제로 확인한 상태를 구분한다. 비결정적인 에이전트를 쓸수록 검증을 별도 단계로 강제해야 한다는 주장이다.
[06:00] 10. 글쓰기 품질도 스킬로 규율하기
unslop은 “중요한 순간”, “결정적인”, “탐구하다”처럼 AI 문장에서 반복되는 상투어를 찾아 없애고, 문장을 사람이 쓴 것처럼 다듬는 스킬로 소개된다. 영상은 EM dash 제거 같은 취향까지 자동화할 수 있다고 말하지만, 이 부분은 품질의 객관적 기준이라기보다 발표자의 편집 선호에 가깝다. 모든 규칙을 그대로 채택하기보다 팀의 문체 기준으로 선택해야 한다.
[06:55] 11. Probe — 전체 제품을 만들기 전에 가능성을 확인하기
show-me-your-work와 probe는 처음부터 애플리케이션 전체를 만들지 않고, 핵심 가정이 실제로 가능한지 작은 스크립트로 확인하는 패턴이다. 화면의 표는 시점·단계·결정·증거를 남기는 형태를 보여준다. macOS에서 먼저 작동시키고 다른 시스템으로 넓히려는 경우처럼 요구사항과 제약을 초기에 확인하면, 불필요한 구조를 큰 규모로 만들 위험을 줄일 수 있다.
[07:45] 12. 현실이 계획을 깨뜨릴 때 — 다시 설계하고 감사하기
상세한 계획을 세워도 실제로 만들기 시작하면 가정이 무너지고, 문제를 다시 정의하거나 즉석에서 계획을 바꿔야 한다. Pstack의 흐름은 이 변화를 실패로 숨기지 않고 검증 표와 감사 단계에 반영하는 쪽이다. 화면에는 구현 결과와 검증 기록을 함께 남기는 작업 로그가 보인다. 계획은 출발점일 뿐이며, 실제 결과가 계획보다 강한 증거라는 주장이다.
[08:30] 13. First principles — 기능을 붙이기보다 구조를 다시 보기
프로젝트가 커지며 기능을 추가할 때, 기존 구조에 코드를 덧대는 대신 그 기능을 처음부터 네이티브하게 설계한다. Redesign from First Principles 슬라이드는 기존 코어에 나중에 볼트를 붙이는 그림과, 처음부터 코어에 포함하는 그림을 대비한다. 영상의 실천 규칙은 코드를 많이 쓰는 것이 아니라 최소한의 코드로 최대 효과를 내고, 독자의 읽기 부하를 줄이는 것이다.
[09:25] 14. Design space를 소진하고 최선안을 고르기
Exhaust the Design Space는 여러 모델·에이전트에게 같은 문제를 풀게 하고, 후보를 비교한 뒤 좋은 부분을 최종 설계에 반영하는 방식이다. 별도의 디자인 모드에서는 데이터베이스나 실제 코드에 들어가기 전에 인터페이스 변형을 여러 개 만들어 볼 수 있다고 설명한다. Arena가 구현 후보의 경쟁이라면 디자인 모드는 구현 비용을 지불하기 전 설계 후보를 좁히는 단계다.
[10:20] 15. Prove It Works — 초록불과 실제 결과물은 다르다
슬라이드의 문장은 “컴파일되고 테스트가 통과하는 것”과 “실제 결과물로 제대로 작동함을 증명하는 것”을 구분한다. 후자는 컴퓨터 사용이나 엔드투엔드 테스트가 될 수 있다. 컨텍스트 창을 보호하고 사람의 입력을 막지 않으면서, 하위 에이전트는 각자 작업한 뒤 중앙 스레드에 보고하도록 하는 운영 원칙도 이 검증 흐름에 포함된다. moc-ai-agents-orchestration
[11:05] 16. 비용 경계 — 모든 프로젝트에 감자를 던지지 말 것
영상 속 비교에서는 계획 모드나 스킬 없이 Fable 5.1을 쓴 프로젝트가 약 30분, Pstack을 쓴 프로젝트가 약 1시간 걸렸다고 말한다. 발표자는 Pstack이 더 많은 검증과 스웜을 사용해 토큰을 많이 소모하지만 결과 애플리케이션은 훨씬 견고해졌다고 주장한다. 이 시간·품질 비교는 영상 발표자의 사례이지 독립 벤치마크가 아니다. 그래서 작은 디자인 변경이나 프런트엔드 UI 작업에는 굳이 Pstack을 적용하지 말고, 복잡하고 오래 유지할 작업에서 비용 대비 효과를 따져 쓰라는 결론으로 끝난다. moc-ai-coding
부록 — 실전 체크리스트
- 먼저 전체 제품을 만들지 말고 핵심 가정을 확인하는
probe를 만든다. - 기존 코드베이스의 결정 기록·로그·MCP·CLI를 읽어 현재 의도와 제약을 회수한다.
- 컴파일·단위 테스트와 실제 결과물 검증을 분리한다.
- 병렬 에이전트는 설계 공간을 넓히는 데만 쓰고, 통합 비용과 토큰 예산을 함께 기록한다.
- 반복 작업은 스킬·플레이북으로 자산화하되, 작은 UI 변경에는 무거운 하네스를 적용하지 않는다.
원문 인용 모음
- [00:47] “Pstack is broken down into all of her principles and engineering rules.” — Pstack을 원칙과 규칙의 묶음으로 설명.
- [01:42] “The core of Pstack is potato mode.” — 스킬 라우터 역할을 하는 감자 모드.
- [02:17] “The best spec is the code.” — 계획보다 실행 중인 코드와 검증을 중시하는 관점.
- [02:46] “It pits three or four different agents against the same problem.” — Arena의 기본 동작.
- [04:17] “Recall is really useful when you want to resume a project.” — 중단한 작업을 다시 시작하는 목적.
- [05:36] “When you’re dealing with nondeterministic agents, these verification steps are really important.” — 검증 단계를 별도로 두는 이유.
- [07:36] “Sometimes the problem with planning too much upfront…” — 구현 전 계획의 한계.
- [10:20] “Having it compile and go green on tests is not the same as actually testing and proving it works.” — 테스트 통과와 실제 결과물 검증의 차이.
- [11:04] “Using the Pstack, it took 1 hour.” — 영상 속 시간 비교 사례.
- [11:29] “You might not need to throw the potato at every single project.” — 적용 범위를 제한하라는 결론.
관련 노트
- moc-ai-agents-harness — 에이전트 하네스·검증·실행 루프를 모은 MOC.
- moc-ai-agents-memory — Recall과 스킬·컨텍스트 관리 관점.
- moc-ai-agents-orchestration — Arena·Swarm과 병렬 에이전트 운영 관점.
- moc-ai-coding — AI 코딩 도구와 운영 규율을 모은 MOC.