pstack 입문 가이드 — 투두앱으로 따라 하는 Claude Code 실전 사용법

요즘 X와 유튜브에서 자주 보이는 pstack을 Claude Code에서 처음 써 보는 사람을 위한 가이드다. 김플립 채널이 투두앱 하나로 pstack을 처음부터 끝까지 써 보며 원리까지 뜯어본 24분짜리 영상을 뼈대로 삼았다. 영상의 설명은 공식 저장소 cursor/plugins/pstack의 README, 가이드 문서, 스킬 파일로 하나씩 확인했다(확인 시점 v0.15.32, 영상은 v0.15.28 기준).

김플립 - LLM 코딩, “요즘 자꾸 뜨는 pstack 어설프게 말고 제대로 파헤쳐 보기” (2026-10-23, 24분 22초)

한 줄 요약

pstack은 프로그램이 아니라 SKILL.md 파일 묶음이다. 한 숙련 개발자의 일하는 습관(먼저 재현하고, 적게 고치고, 실제로 돌려서 증거를 남기는 것)을 글로 적어 AI에게 씌운다. 쓰는 법은 작업 앞에 /pstack:poteto-mode를 붙이는 것 하나다.

pstack은 무엇인가

만든 사람

만든 사람은 로렌 탄(Lauren Tan), 온라인 이름은 poteto다. README 첫 문장에서 Meta, Netflix, Cursor에서 수백만 줄의 코드를 다뤄 왔고 React 코어 팀에서 React Compiler를 만든다고 소개한다. 영상에 따르면 지금은 Cursor를 인수한 스페이스X의 AI 팀에 있다.

README 첫 문장은 “나는 사장도 CEO도 아니다(i’m not a president or ceo)”로 시작한다. 영상은 이것을 Y Combinator 대표 게리 탄이 만든 gstack을 의식한 문장으로 읽는다.

	gstack	pstack
흉내 내는 대상	회사 (CEO, 엔지니어링 매니저, 디자이너, QA 리드, 보안 책임자)	코딩 장인 한 명
일을 나누는 기준	누가 보느냐 (역할 모자를 바꿔 씌움)	무슨 일이냐 (버그, 기능, 리팩터링 레시피)
묻는 질문	올바른 것을 만들고 있나?	만든 게 진짜 되나?

영상의 평가는, gstack은 같은 모델에게 모자만 바꿔 씌우는 것이라 코딩 품질을 잡아 주는 힘이 약했지만 pstack은 다르다는 것이다.

구성

묶음	개수	하는 일
poteto-mode	1	라우터. 요청을 보고 플레이북 하나를 고른다
플레이북	23개	버그 수정, 기능, 리팩터링, 성능, 시안, 밤샘 실행 등 작업 종류별 레시피
원칙 스킬	24개	“가장 작은 변경”, “근본 원인을 고쳐라”, “실제로 돌려 증명하라” 같은 한 줄 규칙
작업 스킬	33개	how, why, architect, arena, interrogate, blast-radius 등
하위 에이전트	2개	poteto-agent(일꾼), Comment Sicko(주석 검토)

영상은 이를 “일 잘하는 선배의 업무 매뉴얼”에 비유한다. 버그가 나면 바로 고치지 않고 먼저 재현하고, 고친 뒤 직접 눌러 보고, 코드는 최대한 적게 바꾸는 선배다. 그 습관을 글로 써서 신입에게 주면 선배 비슷하게는 일한다는 것이다. 영상은 이런 장치를 말에 씌우는 마구에 빗대 하네스(harness)라고 부른다. 모델이 말이라면 하네스는 그 힘을 원하는 방향으로 쓰게 하는 장치다.

설치와 설정 (Claude Code)

10월 16일 공식 저장소에 Claude Code 설치 경로가 추가됐다. 터미널이 아니라 Claude Code를 실행한 뒤 대화창에 입력한다.

/plugin marketplace add cursor/plugins
/plugin install pstack@cursor-plugins
/pstack:setup-pstack

Cursor라면 /add-plugin pstack, /setup-pstack이다. Codex, Pi, GitHub Copilot용으로는 커뮤니티 포팅판 michael-denyer/pstack-claude가 있다. Claude Code에는 공식판과 포팅판 중 하나만 설치한다.

Claude Code에서 알아 둘 것:

• 명령 앞에 pstack:이 붙는다. /poteto-mode는 /pstack:poteto-mode다. 이 글에서 스킬 이름은 how처럼 짧게 적고, 실제로 입력하는 명령 예시에는 /pstack:을 붙여 적었다.
• 자동 업데이트가 꺼져 있다. 켜려면 대화창에서 /plugin → marketplaces 탭 → cursor-plugins → enable auto-update. 한 번만 올리려면 일반 터미널에서 claude plugin update pstack@cursor-plugins.
• Cursor 전용 기능은 바꾸거나 건너뛴다. 예약·자동 실행(Cursor Automations)이 필요한 단계는 Skipped in Claude Code: <단계>. <이유>. 한 줄을 남기고 넘어간다. PR 리뷰 봇(Bugbot)의 댓글은 일반 PR 리뷰로 처리하고, Cursor 클라우드 에이전트에 맡길 일은 로컬 git worktree(지금 작업 폴더와 분리된 별도 작업 폴더)에서 돌린다.

setup-pstack: 역할별 모델 고르기

/pstack:setup-pstack은 코드 쓰는 역할, 판단하는 역할, 검토하는 역할마다 어떤 모델을 쓸지 묻고, 결과를 ~/.claude/rules/pstack-models.md에 저장한다. 이 파일은 새 세션부터 자동으로 읽히니, 설정 뒤에는 새 대화를 연다.

기본값은 코드 작업(기능, 리팩터링, 버그 수정, 성능, 지표 개선)은 Grok, 가장 어려운 변경과 글쓰기와 판단은 Claude Opus 5.5다. 영상의 표현대로 “Grok 진영 회사의 공식 스킬인데 어려운 일은 Opus 5.5에게 넘기는” 구성이다. 추론 예산(모델이 얼마나 깊이 생각할지, 즉 토큰을 얼마나 쓸지)은 small, medium, large, unlimited 중에서 고르고 기본은 large다.

Claude Code 사용자가 꼭 알아야 할 점. Claude Code에는 Grok이 없다. Claude Code는 하위 에이전트(메인 에이전트가 일을 나눠 맡기려고 띄우는 보조 에이전트)에 Claude 모델(opus, sonnet, haiku, fable)만 지정할 수 있어서, Grok 역할은 inherit-parent로 바뀌어 지금 세션 모델로 대신 돈다.

그래서 pstack에서 “다른 회사 모델끼리 서로의 코드를 까 보는” 스킬(교차 검토 스킬 interrogate, 설계안 경쟁 스킬 arena 등)이 Claude Code에서는 사실상 같은 모델끼리 보는 검토가 될 수 있다. 영상 진행자는 그 역할을 Opus 5.5로 두고 추론 단계만 조절하는 쪽을 권했다(본인 취향이라고 덧붙였다).

설정 마지막에는 프로젝트에 아직 없으면 두 가지를 한 번씩 묻는다. 검증 스킬을 만들까?(이미 돌아가는 프로젝트라면 예. 빈 폴더에서 시작한다면 아니요로 넘기고, 뼈대 앱을 만든 뒤 아래 2단계에서 직접 실행한다)와 정형 검증(formal verification) 스킬을 만들까?다. 후자는 “같은 작업이 동시에 두 번 돌지 않는다” 같은 성질 하나를 모든 경우에 대해 증명하는 스킬로, 동시성·재시도·상태 기계·파서처럼 테스트로 잡기 어려운 코드가 있을 때만 예라고 하면 된다.

실전: 투두앱으로 따라 하기

먼저 알아 둘 사실이 하나 있다. pstack에는 “앱을 처음부터 만들어 줘” 플레이북이 없다. 23개 플레이북 어디에도 없다. pstack은 0에서 1을 만드는 도구가 아니라, 이미 돌아가는 앱을 1에서 n으로 키우고 고치고 다듬는 도구다. 그래서 첫 뼈대는 평소처럼 만들고, 그다음부터 pstack을 쓴다.

영상의 순서는 이렇다.

단계	할 일	고르는 플레이북·스킬
0	설치, setup-pstack
1	디자인 정하기 (아직 코드 없이 시안만)	Prototype
-	고른 시안으로 뼈대 앱 만들기 (pstack 없이 평소처럼)
2	검증 스킬 만들기	create-verification-skill
3	기능 추가	Feature
4	버그 수정	Bug fix
5	구조 정리	Refactoring
6	스킬 하나만 꺼내 쓰기	blast-radius 등
7	자는 동안 맡기기	밤샘 실행, show-me-your-work

1단계: 디자인 정하기 (Prototype)

/pstack:poteto-mode 투두 목록 화면을 카드형, 리스트형, 칸반 세 가지로 만들어서 비교하고 싶어

poteto-mode가 Prototype 플레이북을 고르고, 그 절차를 에이전트 화면의 할 일(Todo) 목록에 그대로 옮겨 적은 뒤 이렇게 움직인다.

1. 이 시안으로 무엇을 결정하려는지부터 정한다. 결정할 게 없으면 시안을 만들지 않는다.
2. 실제 소스와 분리된 임시 폴더에 순수 HTML로 대충 만든다. 테스트는 없다.
3. 세 시안을 버튼 하나로 바꿔 볼 수 있게 한 화면에 묶는다.
4. 각각 스크린샷을 찍고 장단점과 추천안을 준다.
5. “이 코드는 버리는 것”이라고 분명히 말한다.

평소 코드 품질에 깐깐한 pstack이 여기서만 원칙을 뒤집는다. 플레이북에 “속도가 다듬기보다 우선, 코드 품질은 중요하지 않다”고 적혀 있다. 목적이 코드가 아니라 결정이기 때문이다.

이 단계는 만든 사람의 철학과 이어진다. pstack에는 계획 스킬이 없다. README에 “나는 계획을 믿지 않는다. 최고의 명세는 코드다(the best spec is code)”라고 적혀 있다. 실행해 보면 알 수 있는 질문이면 사람에게 묻지도 말라고 한다.

2단계: 검증 스킬부터 만들기

1단계에서 고른 시안으로 뼈대 앱을 평소처럼 만들었다면, 기능을 넣기 전에 검증 스킬부터 만든다. AI가 내 앱을 직접 띄우고 눌러 보고 증거를 남기는 방법을 적은 설명서다. 자세한 내용은 아래 “이건 꼭 쓰세요” 절에서 다룬다.

/pstack:create-verification-skill

3단계: 기능 추가 (Feature)

/pstack:poteto-mode 할 일에 마감일을 넣고 지난 건 빨간색으로 보여 줘. 새로고침해도 유지되는지 확인해.

1. how 스킬로 지금 할 일이 어떻게 저장되고 그려지는지 먼저 파악한다.
2. architect 스킬로 데이터 모양부터 정한다. 여기서 원칙 하나가 작동한다. 보통 AI는 done이라는 참/거짓 옆에 overdue라는 참/거짓을 하나 더 붙인다. 그러면 “완료인데 기한 지남” 같은 말이 안 되는 조합이 생긴다. pstack은 상태를 참/거짓 여러 개로 흩뿌리지 말고 구조로 표현하라고 한다. 상태는 열림/완료로 두고, 기한이 지났는지는 날짜로 계산한다. 원칙 이름은 model-the-domain이다.
3. 병렬로 나눌 수 있는지 점검한다. 투두앱 정도면 파일 두 개라 나눌 필요가 없다. 그래도 항목을 지우지 않고 n/a: <이유>를 적어 남긴다.

1. 코드는 하위 에이전트(poteto-agent)가 쓰고, 메인 AI는 반장처럼 그 결과(diff)를 직접 검토만 한다.
2. 2단계의 검증 스킬로 실제 브라우저를 띄워, 어제 날짜로 할 일을 넣고 빨간색인지 스크린샷을 찍고 새로고침 뒤에도 남는지 확인한다.
3. 작은 커밋으로 정리하고 PR을 연다. PR 본문은 형식이 정해져 있다: 왜 바꿨는지(Why), 무엇을 바꿨는지(What changed), 무엇을 다루고 무엇을 일부러 뺐는지(Scope), 무엇을 깨뜨릴 수 있는지(Blast Radius), 어떻게 검증했는지(Verification). 검토자가 물어볼 만한 다른 선택지를 버렸다면 Tradeoffs도 붙인다.

4단계: 버그 수정 (Bug fix)

/pstack:poteto-mode 완료 체크하고 새로고침하면 다시 미완료로 돌아와. 재현부터 해

1. 재현부터. 검증 스킬로 브라우저를 띄워 체크하고 새로고침한 뒤, 풀린 화면을 증거로 남긴다. 재현되기 전에는 고치지 않는다.
2. 원인을 좁힌다. 저장이 안 되는 건지, 저장은 되는데 읽을 때 덮어쓰는 건지 가설을 세우고 로그로 하나씩 지운다. 위 화면처럼 가설에는 “(추측)”, 확인한 원인에는 “(측정함)”이 붙는다.
3. 딱 그 자리만 고친다. 위 화면의 실제 원인은 “기본값을 저장값 뒤에 펼쳐서 done이 false로 덮였다”였고, 그 한 줄만 고친다.
4. 같은 절차로 다시 확인한다. “아마 될 거예요”는 통과가 아니다.
5. 실패하는 테스트 커밋을 먼저, 수정 커밋을 그 위에 쌓는다. 나중에 기록을 보는 사람이 “이게 실패했었고, 이걸로 고쳐졌다”를 순서대로 볼 수 있다.

버그 수정 플레이북에서 영상이 짚은 문장이 있다. “혹시 도움이 될까 봐 넣는 이중 안전장치는 가설이지 수정이 아니다. 내보내지 않는다.” AI가 버그를 고칠 때 가장 흔한 실수가 원인을 모르니 여기저기 방어 코드를 넣는 것이다. 버그는 사라진 것 같지만 코드는 지저분해지고 진짜 원인은 숨는다. pstack은 이걸 금지한다.

5단계: 구조 정리 (Refactoring)

/pstack:poteto-mode 컴포넌트마다 흩어진 상태를 reducer 하나로 정리해. 동작은 그대로.

1. 지금 동작을 못 박는다. 추가·체크·삭제·마감일 시나리오를 기록하는 테스트를 먼저 쓴다.
2. 새 구조를 넣기 전에 안 쓰는 코드부터 지운다(원칙 subtract-before-you-add, 더하기 전에 빼라).
3. 작은 단계로 옮기면서 매번 1번 테스트가 통과하는지 본다.
4. 마지막에 “그래서 읽기 쉬워졌나”를 따진다. 아니면 되돌린다. 읽기 쉬워지지 않았다면 리팩터링이 아니라 코드를 옮겨 놓은 것뿐이라는 뜻이다.

6단계: 스킬 하나만 꺼내 쓰기

플레이북 전체를 돌릴 필요 없이 질문 하나만 하고 싶을 때는 스킬을 직접 부른다.

/pstack:blast-radius Todo 타입에 priority 필드 추가하면 뭐가 깨져?

blast-radius(폭발 반경)는 작아 보이는 변경이 어디까지 영향을 주는지 찾고, “이래서 안전하다”는 근거 하나를 실제 코드를 돌려서 증명한다. 이 밖에 /pstack:how(지금 어떻게 돌아가나), /pstack:why(왜 이렇게 만들었나), /pstack:interrogate(여러 모델로 검토) 등도 따로 부를 수 있다.

7단계: 자는 동안 맡기기

/pstack:poteto-mode 자러 갈게. 태그 기능이랑 검색 기능 각각 PR로 만들어서 머지 가능한 상태로 해 놔. 결정 기록은 남겨.

• 기능마다 담당 하위 에이전트를 따로 둔다.
• show-me-your-work가 모든 결정을 표 한 줄씩(시각, 단계, 결정, 이유, 근거, 결과) decisions.tsv에 남긴다. 왜 이 방법을 골랐는지, 왜 이 단계를 건너뛰었는지가 남는다.
• 되돌릴 수 있는 일은 묻지 않고 진행하고, 공유 브랜치 강제 push, 배포, 데이터 삭제, 고객에게 보내는 메시지처럼 되돌릴 수 없는 일만 멈추고 기다린다. 팀 채팅이나 티켓 갱신 같은 일은 묻지 않고 한다(poteto-mode의 작업 규칙).
• 아침에는 /pstack:ketchup(catch-up, 따라잡기)으로 밤사이 바뀐 것과 내가 결정해야 할 것만 정리해 받는다.

pstack을 쓰지 말아야 할 때

• 작은 수정. “완료 버튼을 파란색으로” 같은 일을 poteto-mode로 돌리면 재현하고 검증까지 다 하느라 시간과 토큰만 몇 배로 든다. 로렌 탄 본인도 “엄격함이 필요할 때” 쓰라고 했다.
• main에 바로 push하는 개인 작업. PR을 여는 플레이북(Opening a PR)이 다른 모든 플레이북 끝에 불린다. PR 없이 혼자 작업하는 흐름과는 맞지 않을 수 있다.
• 이미 정해진 방식이 있는 팀. pstack은 자기 방식대로 일을 나누므로, 그런 팀이라면 how나 blast-radius 같은 스킬만 골라 쓰는 게 나을 수 있다.

영상의 결론은 팀에서 프로덕션 코드를 다룰 때, 코드베이스가 클 때 더 잘 맞는다는 것이다.

작동 원리: poteto-mode 해부

poteto-mode는 말 그대로 “poteto처럼 일해라” 모드다. 실체는 긴 MD 파일 하나로, 영상에 따르면 플레이북까지 합쳐 영어로 약 1만 7천 단어다. 안에는 세 가지가 들어 있다.

1. 라우터. 요청을 보고 23개 플레이북 중 하나를 고른다. 플레이북은 작업 종류별 레시피 카드다. 그래서 우리는 순서를 말할 필요 없이 원하는 것만 말하면 된다.
2. 작업 규칙. “이럴 땐 이 스킬”, “이럴 땐 이 원칙”, “되돌릴 수 있는 일은 묻지 말고 진행” 같은 규칙.
3. 답변 규칙. 모든 주장에 “측정함(Measured), 추론함(inferred), 추측(guess)” 중 하나를 같은 문장에 붙인다. “아마 이게 원인입니다”와 “로그로 확인한 원인입니다”를 구분하게 만드는 장치다. “동의가 기본값이 아니다(Agreement is not the default)”라는 문장도 있다. AI가 맞장구치는 것을 구조적으로 막는다.

poteto-mode 없이는 아무 일도 일어나지 않는다

pstack 스킬 58개 중 57개(setup-pstack만 예외)에는 disable-model-invocation: true가 걸려 있다. AI가 키워드만 보고 알아서 불러오지 못하게 막아 둔 것이다. “리팩터링”이라는 단어만 나와도 리팩터링 원칙을 엉뚱한 작업에 끌어오면 안 되니까. 그래서 poteto-mode 없는 pstack은 바닥에 놓인 연장통이다. 작업 반장(poteto-mode)이 지시하거나 내가 직접 이름을 불러야 움직인다.

위 화면처럼 poteto-mode 없이 같은 버그를 맡기면, 코드를 읽고 원인을 짐작하고 혹시 몰라 방어 코드를 넣고 빌드를 돌린 뒤 “이제 정상 동작할 겁니다”로 끝나기 쉽다. 실제로 눌러 본 사람은 없다. 오른쪽처럼 poteto-mode를 붙이면 4단계에서 본 대로 재현하고, 좁히고, 고치고, 같은 화면에서 다시 확인한 증거를 붙여 끝낸다.

슬쩍 건너뛰지 못하게 하는 장치

• 플레이북 단계를 할 일 목록에 글자 그대로 복사하고, 건너뛰는 단계도 지우지 않고 skip: <이유>를 적게 한다. AI는 검증 같은 귀찮은 단계를 조용히 빼먹는데, 빼먹으려면 이유를 써야 하니 슬쩍 넘어가기 어렵다. 영상에 따르면 써 본 개발자들도 이 장치가 실전에서 가장 많은 일을 했다고 평가한다.
• 하위 에이전트(poteto-agent)는 일을 시작하기 전에 poteto-mode 지시서를 전부 읽고 온다. 그래서 일꾼을 여럿 불러도 같은 방식으로 일한다.

정직하게 덧붙일 점

• 모델이 좋아질수록 차이는 줄어든다. 9월 23일 커밋 제목이 “cut 19 more instructions Opus 5.5 does not need”(Opus 5.5에 필요 없는 지시 19개를 더 덜어냄)다. 만든 사람도 모델이 좋아지는 만큼 덜어내고 있다. pstack의 가치는 “일하는 법 가르치기”에서 “순서를 강제하고 증거를 요구하기”로 옮겨 가는 중이다.
• 비용이 더 든다. 영상이 든 한 사례에서는 30분 걸리던 작업이 한 시간 걸렸고, 대신 AI의 거짓 보고를 잡아냈다. 덜 틀리는 대신 더 드는 셈이고, 이게 맞는지는 각자 판단해야 한다.
• 대부분은 강제가 아니라 문장이다. “검증 없이 머지 금지” 같은 규칙도 코드로 막힌 게 아니라 글이다.
• 숫자는 본인 주장이다. “Cursor 안에서 주당 1만 회 사용”, “한 달에 PR 2,000개”는 본인 주장이고, 시점마다 1,000개, 2,000개, 2,500개로 다르다. 본인도 PR 개수가 목표는 아니었다고 했다.

이건 꼭 쓰세요: create-verification-skill

영상이 가장 강조한 부분이다. pstack 스킬이 50개가 넘지만 이것 하나만 써도 결과물이 확 달라진다고 한다. 로렌 탄도 도구 상자에 있어야 할 가장 중요한 스킬로 검증 스킬을 꼽았다.

create-verification-skill은 스킬을 만들어 주는 스킬이다. 새 테스터에게 주는 인수인계 문서를 떠올리면 된다.

항목	내용
Launch	앱을 어떻게 켜나
Doctor	켜졌는지 어떻게 아나
Drive	어디를 누르나
Evidence	무엇을 찍어서 보고하나
Cleanup	끝나면 어떻게 정리하나

이 문서를 AI가 사람이 아니라 저장소를 인터뷰해서 직접 쓴다. 예시가 아니라 이 저장소의 실제 버튼 이름과 실제 명령으로 쓴다. 이미 Playwright나 Cypress 테스트가 있으면 그것부터 가져다 쓴다. 앱의 기능 목록(features/ 폴더의 feature map)도 함께 만든다. 로렌 탄은 이걸 “굳혀 둔 기억”이라고 부른다. 매번 기억을 잃는 AI가 코드를 다시 뒤지지 않고 바로 펼쳐 보는 지도다.

그리고 넘겨주기 전에 직접 한 바퀴 돌려 본다. 한 번도 실행되지 않은 스킬은 초안이지 결과물이 아니라는 것이다. 공식 가이드도 이 검증에 실패하면 결과물을 쓰지 말라고 한다. 결과 스킬은 Claude Code에서 .claude/skills/verify-<앱 이름>/에 생긴다.

“E2E 테스트랑 뭐가 다르냐”는 질문에 영상은 이렇게 답한다. E2E 테스트는 이미 되던 게 안 깨졌는지 보는 것이고, 검증 스킬은 방금 만든 게 진짜 되는지 AI가 직접 확인하는 것이다. 다만 원리를 모르고 쓰면, 검증 스킬이 엉뚱한 버튼을 누르고 있어도 알아채지 못해 “그럴듯한 스크린샷이 붙었습니다”가 하나 더 생길 뿐이다. 모바일 앱이면 시뮬레이터, CLI면 터미널을 조작하도록 직접 고칠 줄도 알아야 한다.

pstack에 숨은 하네스의 규칙

요즘 에이전트 10개, 20개를 동시에 돌린다는 자랑이 많다. 로렌 탄은 반대로 말한다. 하나를 믿을 수 있기 전에 100개를 돌리면 엉망인 PR만 100배로 나온다. “소프트웨어 공장이 아니라 미슐랭 주방이다. 나가는 접시마다 책임지는 셰프가 있다.”

AI에게 같은 잔소리를 반복하고 있다면, 그 잔소리를 어디에 넣느냐에 따라 효과가 다르다. 위 발표 화면의 순서대로 강하다.

1. 코드베이스와 아키텍처. 나쁜 패턴을 아예 쓸 수 없게 만든다.
2. 정적 분석. 린트, 컴파일러, CI.
3. 규칙 파일과 리뷰 봇. CLAUDE.md, Bugbot 같은 것.
4. 스킬.
5. 스타일 가이드.

예를 들어 AI가 쓸데없는 주석을 자꾸 단다고 하자. 보통은 CLAUDE.md에 “주석 달지 마”라고 쓴다. 3층이고, 가끔 무시된다. 린트로 막으면 2층이라 거의 무시할 수 없다.

로렌 탄의 팀은 1층에서 막았다. 내부 프레임워크에서 주석을 금지했다. “임시방편, 나중에 고칠 것” 같은 주석을 보면 AI가 “여기선 대충 해도 되는구나” 하고 따라 하더라는 것이다. 같은 이유로 대충 한 옛날 코드도 지우고, 같은 일을 하는 방법은 하나만 남겼다. AI는 코드베이스에 보이는 것을 따라 한다.

pstack의 /pstack:correct가 이 일을 해 준다. 최근 커밋, 되돌린 커밋, 리뷰 댓글, 에이전트 지시 파일, 임시방편을 설명하는 주석을 읽어 두 번 이상 반복된 실수 유형을 찾고, 가능한 한 강한 층에서 고친다. 공식 설명의 순서는 구조 → 타입 → 고칠 방법을 알려 주는 린트 → 테스트 → 문서이고, 각 검사가 실제 과거 실수에서 실패하는지 증명하게 한다.

자동화는 맨 마지막에

Slack이나 Sentry를 연결해 버그 리포트가 오면 AI가 알아서 고치게 하는 자동화는 멋져 보인다. 하지만 맨 마지막에 해야 한다. 저장소가 성숙하기 전에 붙이면 엉성한 PR이 자동으로 늘어날 뿐이다.

정리

pstack은	SKILL.md 묶음. 회사가 아니라 장인 한 명을 흉내 낸다
쓰는 법	작업 앞에 /pstack:poteto-mode. 없으면 연장통일 뿐
잘 맞는 일	돌아가는 앱을 키우고 고치는 일(1→n), 팀 프로덕션 코드
안 맞는 일	처음부터 만들기, 한 줄 수정, PR 없는 개인 작업
Claude Code 주의	Grok 역할이 세션 모델로 돌아 다른 모델 교차 검토가 같은 모델 검토가 될 수 있다
꼭 쓸 것	create-verification-skill

다른 건 몰라도 검증 스킬 하나는 써 보자. “AI가 고쳤을 겁니다”가 아니라 “고쳤다는 증거가 여기 있습니다”라고 말하게 되는 순간 결과물이 달라진다. 영상의 마지막 조언처럼, 원리를 알면 pstack 없이도 나만의 하네스를 만들 수 있다. /pstack:automate-me를 실행하면 내 대화 기록으로 <내 이름>-mode 스킬 초안을 만들어 준다. 목표는 poteto-mode가 아니라 내 모드를 만드는 것이다.

더 깊이 보려면 공식 pstack 가이드가 10개 장으로 정리돼 있다. 5분 요약 영상으로 먼저 훑고 싶다면 민둥이 채널의 소개 영상도 있다.

// reading compass

이 글과 이어지는 경로

시리즈, 카테고리, 태그 겹침, 최신도를 점수화해 가까운 글일수록 중심에 배치합니다.

hover nodes or cards · click a node to pin

Next reads 0