# pstack

> 한 개발자의 일하는 습관을 AI용 설명서로 옮긴 스킬 묶음입니다. 통째로는 안 들였고, 「직접 켜서 확인하는 법」을 만드는 스킬 하나만 후보로 남겼습니다.

- 수치: 스킬 61 · 후보 1
- 사람이 보는 화면: https://aitryed.com/ko/teardowns/harness/pstack/
- 반대 언어: https://aitryed.com/en/teardowns/harness/pstack/index.md
- 출처(원본 영상 (김플립)): https://www.youtube.com/watch?v=u2oDdU6z4Bw
- 출처(pstack 저장소): https://github.com/cursor/plugins/tree/main/pstack
- 이 사이트 안내(AI용): https://aitryed.com/ko/llms.txt

---

**pstack은 개발자 Lauren Tan(핸들 poteto)이 «자기가 일하는 습관»을 AI가 따라 하도록 글로 옮긴 스킬 묶음입니다. 프로그램이 아니라 설명서 파일 묶음이고, 핵심은 하나입니다 — AI가 «고쳤을 겁니다» 대신 «고쳤다는 증거가 여기 있습니다»라고 말하게 만드는 것.** 저는 통째로는 들이지 않았고, 그 안의 스킬 하나만 후보로 남겼습니다.

> **[도판]** 구조는 영상 설명과 저장소 실물(2026-10-29, 플레이북 23 · 서브에이전트 정의 2 · SKILL.md 61)을 대조해 그렸다.
>
> 요청이 들어오면 라우터 poteto-mode가 작업 종류를 보고 플레이북 23개 중 하나를 고르고, 플레이북은 원칙과 작업 스킬을 불러 순서대로 일하며, 모든 플레이북 끝에 진짜 된다는 증거가 있는지 묻는 단계가 붙는다.

## 「스킬 묶음」이 뭔가요

AI 코딩 도구(Claude Code·Cursor 같은 것)는 **「이럴 땐 이렇게 일해라」를 적은 글 파일**을 읽고 그대로 움직입니다. 그 글 한 장을 「스킬」이라고 부릅니다.

스킬 여러 장을 한 사람이 한 방향으로 묶어 이름을 붙이면 「○○스택」이 됩니다. pstack은 영어로 약 3만 단어, 책 한 권 분량의 설명서 묶음입니다. 모델을 바꾸지도, 별도 프로그램을 깔지도 않습니다.

## 비유하면 — 꼼꼼한 선배의 업무 수첩입니다

회사에 아주 꼼꼼한 선배가 있다고 해 봅시다. 버그가 나면 절대 바로 안 고칩니다. 먼저 똑같이 재현해 보고, 고친 뒤엔 꼭 직접 눌러 확인하고, 코드는 최소한만 바꿉니다.

이 선배의 습관을 전부 글로 적어 신입에게 주면, 신입은 선배만큼은 아니어도 선배 비슷하게 일합니다. **pstack이 그 수첩이고, 신입이 AI입니다.**

| | 비슷한 유행 묶음(gstack) | pstack |
|---|---|---|
| 흉내 내는 대상 | 회사 — CEO·QA 리드 같은 역할 | 장인 한 명 |
| 일을 나누는 기준 | 누가 보느냐 | 무슨 일이냐(버그·기능·리팩토링) |
| 끝에 묻는 것 | 올바른 걸 만들고 있나 | 만든 게 진짜 되나 |

## 제일 중요한 스킬은 「직접 켜서 확인하는 법」을 만드는 스킬입니다

이름은 `create-verification-skill`입니다. 만든 사람도 도구 상자에서 가장 중요한 스킬로 꼽습니다. 저장소에서 원문을 열어 확인했습니다.

새 알바생에게 주는 메모를 떠올리면 됩니다. 불은 어디서 켜는지, 켜졌는지는 어떻게 아는지, 어디를 확인하는지, 확인한 건 사진으로 어디에 올리는지, 끝나면 어떻게 정리하는지. **이 메모를 사람이 아니라 AI가 내 코드를 읽고 직접 씁니다.** 그리고 넘기기 전에 그 메모대로 한 바퀴 직접 돌려 봅니다.

| | 이 메모가 없을 때 | 있을 때 |
|---|---|---|
| AI의 마지막 말 | «빌드 성공, 될 겁니다» | «켜서 눌러 봤고, 스크린샷 여기 있습니다» |

## 그런데 통째로는 들이지 않았습니다

이유는 셋입니다. 첫째, 핵심 규칙 여럿이 제 환경에 **이미 있었습니다** — 「확인 못 한 건 추측이라고 밝혀라」, 「건너뛴 단계는 이유를 적어라」 같은 것들입니다. 둘째, pstack은 **일을 자기 방식대로 나눕니다.** 저는 이미 정해 둔 작업 흐름이 있어서 둘이 부딪힙니다. 셋째, 늘 PR을 여는 흐름이라 혼자 하는 개인 작업과는 맞지 않습니다.

그래서 남긴 건 위의 검증 스킬 하나입니다. **아직 돌려 보지는 않았습니다** — 지금은 후보입니다.

## 같은 잔소리는 「더 강한 층」으로 옮깁니다

영상에서 가장 오래 남은 대목입니다. AI에게 같은 말을 반복하고 있다면, **그 말을 어디에 넣느냐에 따라 효과가 다릅니다.**

규칙 파일에 「주석 달지 마」라고 쓰면 가끔 무시합니다. 검사 도구(린트)로 막으면 거의 못 어깁니다. 아예 코드 구조에서 막으면 어길 길이 없습니다. 만든 사람의 팀은 마지막 방법을 썼습니다 — AI는 코드베이스에 **보이는 걸 따라 하기** 때문에, 따라 하면 안 되는 건 아예 안 보이게 치웠습니다.

## 여기부터는 자세한 기록입니다

**pstack은 Cursor 공식 플러그인 저장소에 있는 SKILL.md 묶음이다.** 라우터 `poteto-mode` 하나가 요청을 보고 플레이북 23개 중 하나를 고르고, 플레이북이 원칙 스킬과 작업 스킬을 불러 순서대로 일한다. 입구는 김플립의 해설 영상(24분, 2026-10-23)이었고, 숫자와 스킬 원문은 저장소에서 따로 확인했다. **판정은 통째 도입 안 함, `create-verification-skill` 하나만 후보.**

## 무엇을 뜯었나

| 항목 | 값 | 출처 |
|---|---|---|
| 만든 사람 | Lauren Tan(@poteto) — Meta·Netflix·Cursor 경력 | 영상 |
| 형태 | 마크다운 스킬 묶음, 영어 약 3만 단어 | 영상 |
| 플레이북 | **23** | 저장소 실측 |
| 서브에이전트 정의 | **2** | 저장소 실측 |
| SKILL.md 파일 | **61** | 저장소 실측 |
| 기준 판 | 0.15.28 (2026-10-18) | 영상 설명란 |
| 주당 1만 회 사용 · 월 2천 PR | 만든 사람 본인 주장 — 시점마다 1천~2천5백으로 달라진다 | 영상 |

원래는 Grok 계열 회사의 플러그인이라 기본 설정이 코드 작성은 Grok, 판단·글쓰기·어려운 작업은 Claude Opus 5.5에 맡긴다. 2026-10-16에 Claude Code 설치 경로가 추가됐다. Claude Code에는 Grok이 없어서 그 역할을 현재 세션 모델이 대신한다. **그래서 «다른 회사 모델끼리 서로의 코드를 까 보는» 스킬이 Claude Code에서는 같은 모델끼리의 검토가 될 수 있다** — 영상이 짚은 점이고, 교차 검증의 정보량이 거기서 사라진다.

## 라우터 한 장이 순서를 강제한다

`poteto-mode`의 실체는 긴 MD 한 장이다(플레이북 포함 약 1.7만 단어). 세 덩어리다.

| 덩어리 | 하는 일 |
|---|---|
| 라우터 | 요청을 보고 플레이북을 고른다. 사용자는 순서를 말하지 않는다 |
| 작업 규칙 | 이럴 땐 이 스킬, 이럴 땐 이 원칙. 되돌릴 수 있는 일은 묻지 않고 진행 |
| 답변 규칙 | 모든 주장에 «측정함 · 추론함 · 추측»을 붙인다. «동의가 기본값이 아니다» |

스킬 대부분에는 `disable-model-invocation: true`가 걸려 있다. 「리팩터링」이라는 단어만 보고 엉뚱한 작업에 원칙을 끌어오지 못하게 막은 것이다. 그 대가로 **라우터를 안 부르면 아무 일도 안 일어난다.** 설치했다는 사실과 켰다는 사실 사이에 거리가 있다는 점은 [eli5](/ko/teardowns/harness/eli5/index.md) 편과 같은 모양이다.

실사용자들이 가장 효과가 컸다고 꼽는 장치는 따로 있다. **플레이북 단계를 할 일 목록에 글자 그대로 복사하고, 건너뛰는 단계도 지우지 않고 이유를 적게 한다.** AI는 검증처럼 귀찮은 단계를 조용히 빼먹는데, 빼먹으려면 이유를 써야 하니 슬쩍 넘어가지 못한다.

## 투두앱 시연에서 원칙이 작동한 자리

영상은 투두앱 하나로 일곱 단계를 돌렸다. pstack에는 앱을 처음부터 만드는 플레이북이 없다 — 0→1이 아니라 1→n 도구다.

| 단계 | 작동한 원칙 |
|---|---|
| 시안 | 품질 원칙이 여기서만 뒤집힌다. 목적이 코드가 아니라 결정이라 버리는 HTML로 빨리 비교한다 |
| 기능 | 「완료」 옆에 「기한 지남」 참거짓을 붙이지 않는다. 상태는 열림·완료, 기한 초과는 날짜로 계산(model-the-domain) |
| 버그 | 재현 전엔 고치지 않는다. **«혹시 몰라 넣는 이중 안전장치는 가설이지 수정이 아니다»** |
| 리팩토링 | 더하기 전에 뺀다. 읽기 쉬워지지 않았으면 리팩토링이 아니라 이사다 |
| 밤샘 작업 | 모든 결정을 표 한 줄씩 남긴다. 되돌릴 수 없는 일(강제 푸시·배포·삭제)만 멈춘다 |

## 검증 스킬 원문은 영상보다 엄격했다

`create-verification-skill` 원문을 열어 보니 영상 설명보다 기준이 하나 더 있었다. 순서는 네 단계다 — 저장소를 인터뷰한다(사람에게는 코드로 알 수 없는 것만 묻는다), 실행·점검·조작·증거·정리 다섯 칸짜리 스킬을 쓴다, 기능 지도를 3~5장 만든다, 넘기기 전에 직접 한 바퀴 돈다.

영상에 없던 기준은 증거와 정리 칸에 있었다.

| 원문 기준 | 무엇을 막나 |
|---|---|
| 내부 setter나 테스트 전용 경로가 아니라 **실제 사용자 경로**로 조작한다 | 지름길로 통과시키는 것 |
| 마지막 화면만이 아니라 **행동과 그 결과 상태**를 함께 남긴다 | 그럴듯한 최종 스크린샷 한 장 |
| dry-run은 이름을 믿지 말고 **실제로 무엇을 건너뛰는지 관찰**한다 | 「모의 실행」이 사실은 네트워크를 건드리는 것 |
| 정리 후에도 **증거가 남아 있는지** 확인한다 — 정리가 증거를 먹으면 실패 | 증거를 지운 채 «확인했다» |
| 이름으로 프로세스를 죽이지 않는다. **내가 띄운 것만** 죽인다 | 사용자의 다른 창까지 닫는 것 |
| 조건이 안 맞으면 시나리오를 약하게 고치지 말고 **실패로 보고**한다 | 통과시키려고 시험을 깎는 것 |

마지막 두 줄은 제 환경에 이미 같은 이름의 사고 기록이 있다. 같은 결론에 다른 길로 도착한 셈이다.

## 잔소리는 강한 층에 넣는다

> **[도판]** 영상의 「잔소리 다섯 층」. 보통 「주석 달지 마」는 3층에 쓰고, 만든 사람의 팀은 1층에서 막았다.
>
> AI에게 반복하는 잔소리를 넣는 자리 다섯 층. 위가 가장 강하다. 1층 코드 구조, 2층 린트와 CI, 3층 규칙 파일과 리뷰봇, 4층 스킬, 5층 스타일 가이드. 막대가 아래로 갈수록 짧아져 강도가 약해짐을 보인다.

만든 사람의 팀은 내부 프레임워크에서 주석 자체를 금지했다. 「임시 방편, 나중에 고칠 것」 같은 주석을 본 AI가 «여기선 대충해도 되는구나» 하고 따라 하더라는 이유다. 같은 이유로 대충 짠 옛 코드도 지우고, 같은 일을 하는 방법은 하나만 남겼다. pstack의 `cut` 스킬이 이 일을 한다 — 반복 지적한 실수를 찾아 가능한 가장 강한 층에서 고친다.

같은 논리로 **자동화는 맨 마지막**이다. 버그 리포트가 오면 AI가 알아서 고치게 하는 배선은 멋져 보이지만, 저장소가 성숙하기 전에 붙이면 엉성한 PR만 자동으로 불어난다. 영상의 표현으로는 «소프트웨어 공장이 아니라 미슐랭 주방» — 하나를 믿을 수 있기 전에 백 개를 돌리면 쓰레기도 백 배로 나온다.

## 정직한 한계는 만든 쪽 기록에 있었다

| 한계 | 근거 |
|---|---|
| 모델이 좋아질수록 차이가 준다 | 2026-09-23 커밋 제목이 «Opus 5.5에 필요 없는 지식 19개 추가 삭제». 가치가 «일하는 법 가르치기»에서 «순서 강제 + 증거 요구»로 옮겨 가는 중 |
| 느리다 | 한 사례에서 30분 작업이 1시간이 됐다. 대신 AI의 거짓 보고를 잡았다 |
| 대부분 강제가 아니라 문장이다 | «검증 없이 머지 금지»도 코드로 막힌 게 아니다 — 위 다섯 층으로 치면 4층이다 |

세 번째 줄이 이 편에서 제일 재미있는 자리다. **pstack은 «잔소리는 강한 층으로»를 가르치면서, 자기 자신은 대부분 4층에 산다.** 이 칸에서 여러 번 본 «깨는 도구를 대상이 들고 있다»의 또 한 사례다.

## 판정 — 통째로는 안 들이고 하나만 후보

| 대상 | 판정 | 이유 |
|---|---|---|
| poteto-mode 통째 | 안 들임 | 답변 규칙(측정·추론·추측)과 「건너뛴 단계 이유 기록」은 이미 있다. 라우터가 기존 작업 흐름과 부딪힌다. 늘 PR을 여는 흐름이 개인 작업과 안 맞는다 |
| `create-verification-skill` | **후보** | 「코드가 들어갔다」와 「화면에서 돈다」를 가르는 칸이 제 환경에서 실제로 비었던 적이 있다. 원문의 증거 기준이 그 빈칸을 정확히 겨눈다 |
| 잔소리 다섯 층 | 점검표로만 | 규칙 파일(3층)에만 있고 자주 어겨지는 항목을 훅·게이트(2층)로 내릴 수 있는지 보는 데 쓴다 |

## 못 한 것

- **pstack을 설치하지 않았다.** 위 판정은 영상과 저장소 원문을 읽고 낸 것이고, 실행해서 낸 것이 아니다.
- **검증 스킬도 아직 한 번도 돌리지 않았다.** 원문의 기준대로라면 지금 이 판정은 «초안»이다 — 돌려 보기 전엔 후보 이상이 아니다.
- 주당 사용 수·월 PR 수·«30분→1시간» 사례는 전부 남이 잰 숫자다. 재현하지 않았다.
- 영상 자막은 자동 자막이라 고유명사가 자주 틀렸다. 이름과 숫자는 영상 설명란과 저장소로 바로잡았다.

## 남는 문장

> **«한 번도 실행 안 된 스킬은 초안이지 결과물이 아니다.»** — 검증 스킬 원문의 기준이고, 이 편의 판정에도 그대로 걸린다.