pstack, 코딩 에이전트에게 일하는 순서를 가르치는 플러그인

Mr. Latte

2026년 11월 6일

코딩 에이전트에게 버그를 맡기면 대개 이런 일이 생긴다. 관련 있어 보이는 파일을 열고, 그럴듯하게 수정한 뒤 "고쳤습니다"라고 말한다. 직접 재현했는지, 원인이 정말 그것이었는지, 수정한 뒤 같은 절차로 다시 확인했는지는 사람이 매번 따로 물어야 한다. 이 질문을 되풀이하지 않아도 되게 만든 도구가 pstack 이다.

pstack 은 Cursor 공식 플러그인 저장소 cursor/plugins 에 들어 있는 플러그인이다. 만든 사람은 poteto 라는 이름으로 활동하는 Lauren Tan 이다. README 에는 React 코어 팀에서 React Compiler 를 만들고 Meta, Netflix, Cursor 에서 일했다는 소개가 있다[1]. 이 글은 2026년 11월 6일에 읽은 0.15.36 판(MIT 라이선스)을 기준으로 한다[2].

모델이 아니라 일하는 순서다

pstack 을 이해하려면 세 층으로 나눠 보면 된다.

그래서 pstack 을 깐다고 모델이 똑똑해지지는 않는다. 같은 모델이 서두르지 않고, 확인하지 않은 일을 끝났다고 말하지 않도록 일하는 순서를 고정한다. README 첫머리의 문장이 그 의도를 그대로 보여 준다. "if you want to go fast, go deep first."[1]

진입점 하나, 플레이북 스물셋, 원칙 스물넷

pstack 의 몸통은 스킬 묶음이다. 스킬은 SKILL.md 파일 하나에 언제 쓰고 어떤 절차를 따를지 적은 것이다. 에이전트는 필요할 때 이 파일을 읽고 따른다. 저장소에는 이런 스킬 폴더가 58개 있다.

사람이 기억할 것은 거의 하나뿐이다. 진입점 poteto-mode 를 부르고 할 일을 적으면, 이 스킬이 요청을 읽고 알맞은 플레이북을 고른다[3]. 플레이북은 일의 종류에 따른 순서표다. 버그 수정, 성능 문제, 기능, 리팩터링, 조사, 시제품, PR 상태 돌보기, 밤새 도는 자율 실행 등 23가지가 있다[1].

플레이북을 고른 뒤의 동작을 보면 pstack 의 성격이 잘 드러난다.

• 첫 메시지에서 사용자의 목표, 풀려는 문제, 예상하는 가장 작은 변경을 자기 말로 다시 적는다. 확인을 기다리지는 않는다[3].
• 고른 플레이북의 단계를 할 일 목록 맨 앞에 글자 그대로 옮긴다. 건너뛰는 단계도 지우지 않고 skip: 이유 를 붙여 남긴다[3].
• 원칙 스물네 개(재현해서 증명하기, 원인에서 고치기, 공유 상태를 먼저 떼어 내기 등) 가운데 이번 판단에 쓴 원칙의 이름을 답장에 밝힌다. 그 원칙의 파일을 이번 세션에서 읽었을 때만 이름을 밝힐 수 있다[3].
• 답장의 모든 주장에는 같은 문장 안에 근거나 꼬리표를 붙인다. 잰 결과인지, 추론인지, 추측인지 밝힌다[3].

버그 수정 플레이북의 절차는 구체적이다[4]. 먼저 같은 화면이나 명령에서 직접 재현한다. 도구가 닿지 않는 구체적인 이유가 있을 때만 사용자에게 재현을 부탁한다. 다음으로 원인 후보를 세우고 이분 탐색으로 하나씩 지운다. 수정한 뒤에는 처음 재현했던 바로 그 자리에서 다시 확인한다. "판단 불가"나 다른 화면에서 확인한 결과는 통과로 치지 않는다. 커밋도 실패하는 재현을 먼저 만들고, 그 위에 수정을 쌓는다.

자주 쓰는 스킬은 아래와 같다. poteto-mode 가 단계에 맞춰 부르지만, 직접 불러도 된다[1].

에이전트를 여럿 띄우는 세 가지 방식

pstack 이 내세우는 말은 "fearless parallelism"이다[1]. 에이전트 하나를 깊이 신뢰할 수 있어야 여럿을 동시에 돌릴 수 있다는 논리다. 동시 실행에는 성격이 다른 세 가지 방식이 있다.

arena 는 여러 후보에게 같은 과제를 똑같은 프롬프트로 맡긴다[5]. 후보마다 별도의 작업 트리를 받는다. 모두 끝나면 부모와 다른 계열의 모델 하나가 루브릭에 따라 후보를 채점한다. 부모도 따로 읽고 채점해 두 판정을 견준다. 가장 손보기 쉬운 후보를 바탕으로 삼고, 탈락한 후보에서 쓸 만한 부분 한두 개를 손으로 옮겨 붙인다. 후보들이 비슷한 결과로 모이면 강한 합의로 보고, 크게 갈리면 과제를 다시 정의하라고 한다.

swarm 은 일을 여러 조각으로 나누거나(패키지마다 검사 하나) 같은 일로 경주시킨다[6]. 일꾼은 결과를 PASS, ISSUES, BLOCKED 셋 중 하나로 정리해 증거와 함께 보고한다. 브리프에서 요구한 커밋과 측정 방법을 적지 않은 결과는 버리고 한 번 다시 띄운다. 두 번째에도 빠뜨리면 빈칸으로 남긴다. 빈칸은 통과로 치지 않는다.

interrogate 는 적대적 검토다[7]. 검토자에게 "이 변경을 깨뜨려라, 그리고 모든 지적을 실제 실행으로 증명하라"는 브리프를 준다. 실패하는 시험이나 재현 스크립트, 잘못된 출력이 없는 지적은 버린다. 스타일, 이름, 구조처럼 실행으로 드러나지 않는 의견도 버린다. 부모가 같은 명령을 다시 돌려 확인한 지적만 남기며, 고치는 일은 하지 않는다.

세 방식 모두 모델을 섞는 것을 전제로 한다. 기본값은 코드 작성에 Grok, 판단과 글에 Claude Opus 이다[1]. arena 의 심사는 부모와 같은 계열의 모델이 맡지 못하도록 막아 두었다[5]. 역할마다 어떤 모델을 쓸지는 설정에서 바꿀 수 있다[8].

설치와 첫 설정

Cursor 에서는 두 줄이면 된다[1].

/add-plugin pstack
/setup-pstack

setup-pstack 은 두 가지를 정한다[8]. 첫째는 추론 예산이다. unlimited(max), large(xhigh, 기본), medium(high), small(medium) 넷 중 하나를 고르면 역할마다 모델의 추론 강도가 해당 단계로 바뀐다. 이름은 예산이지만 돈이나 사용량의 상한은 아니다. 둘째는 역할마다 쓸 모델이다. 역할은 열일곱 줄이며, 기능과 리팩터링, 버그 수정, 성능, 탐색자, 일꾼은 Grok, 판단과 글, 가장 어려운 일, 설명과 종합은 Opus 가 기본이다. arena, architect, interrogate 처럼 여럿이 함께 보는 역할은 모델 목록을 받는다. 목록의 길이가 곧 띄우는 하위 에이전트 수다. 결과는 ~/.cursor/rules/pstack-models.mdc 에 저장된다.

Grok 을 쓸 수 없거나 쓰고 싶지 않다면 그 역할을 inherit-parent(또는 auto)로 두면 된다. 하위 에이전트의 모델 칸을 비워 부모 대화의 모델을 그대로 쓰게 하는 값이며, 실제 모델 이름은 아니다[9]. 설정 마지막에는 프로젝트 확인 스킬을 만들 것인지 한 번 묻는다. 가이드는 처음이라면 "예"를 고르라고 한다. 이 안내서 전체에서 가장 크게 돌려받는 것이 확인 스킬이라고 적혀 있다[9].

Cursor 에서 /poteto-mode 를 고를 때 엔터 대신 option+enter(윈도는 alt+enter)를 누르면 대화가 이어지는 동안 계속 켜진 모드가 된다. Cursor 의 /loop 와 함께 쓰면 몇 시간짜리 작업도 맡길 수 있다[1].

Claude Code 에서는 마켓플레이스를 추가하고 설치한다[1].

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

명령 앞에 플러그인 이름이 붙어서 /pstack:setup-pstack, /pstack:poteto-mode 로 부른다. 제3자 마켓플레이스라 자동 업데이트가 꺼져 있다. /plugin 의 마켓플레이스 탭에서 켜거나 claude plugin update pstack@cursor-plugins 로 직접 올린다[1].

Claude Code 판은 원본에서 자동으로 만든 사본이다. 어댑터 문서가 Cursor 의 이름을 Claude Code 의 이름으로 옮긴다[10]. 쓰기 전에 알아 둘 차이가 셋 있다.

• 모델이 한 계열로 모인다. Claude Code 의 하위 에이전트는 opus, sonnet, haiku, fable 만 고를 수 있다. Grok, GPT 같은 다른 계열을 지정한 역할은 모델 칸을 비운 채 세션 모델로 돌며, 그렇게 했다고 밝히게 되어 있다[10]. 설정의 Grok 기본값도 inherit-parent 로 바뀐다. 그래서 arena 의 다른 계열 심사는 맡을 모델이 없으면 건너뛰고 부모가 혼자 고른다[5]. 다른 회사 모델의 시각을 섞는 효과는 Claude Code 에서 기본으로 얻지 못한다.
• 스킬은 파일을 읽어서 따른다. Claude Code 의 스킬 도구가 pstack 스킬 대부분을 거부해서, 에이전트가 SKILL.md 를 직접 읽고 따르는 방식으로 옮겼다[10].
• Cursor 에만 있는 단계는 건너뛴다. Cursor Automations, Bugbot, Cursor 클라우드 에이전트, 내장 PR 도구가 필요한 단계는 Skipped in Claude Code 한 줄을 남기고 다음으로 넘어간다. PR 은 gh pr create 로 연다[10].

모델 설정은 ~/.claude/rules/pstack-models.md 에 저장된다. 어댑터 문서는 역할 줄을 CLAUDE.md 나 AGENTS.md 에 넣지 말라고 적는다[10].

Codex, OpenCode 와 그 밖의 환경 에는 공식 판이 없고 커뮤니티 이식판이 있다. 이식판마다 기준으로 삼은 원본 판과 제외한 스킬이 다르다. 하나를 골라 해당 저장소의 설치 절차만 따라야 한다. Claude Code 에 이식판과 원본을 함께 깔면 둘 다 pstack: 접두어를 써서 충돌한다는 경고도 있다[11].

잘 쓰는 법

요청에는 다섯 가지까지만 담는다. 가이드는 프롬프트에 목표, "됐다"를 판정할 기준, 보고 싶은 증거, 이미 아는 것, 실제 제약을 담으라고 한다[12]. 기준은 통과와 실패가 갈려야 한다. "더 좋게 해 줘"나 "한 시간 동안 해 줘"는 기준이 아니다. 반대로 빼야 할 것은 둘이다. 어떻게 할지와 처음부터 내놓는 원인에 대한 내 추측이다. 미리 말한 추측은 탐색 범위를 내가 가리킨 곳으로 좁힌다. 에이전트가 문제를 먼저 다시 말하게 한 뒤에 추측을 꺼내라는 뜻이다. 쓸 스킬을 프롬프트에 늘어놓지 말라는 당부도 있다. 스킬을 고르는 것은 poteto-mode 의 몫이다.

/poteto-mode 로그인하고 새로고침하면 세션이 풀린다.
먼저 재현하고, 원인을 확인한 범위만 고쳐 줘.
됐다의 기준: 같은 재현 절차에서 고치기 전 실패와 고친 뒤 성공을 보여 줄 것.
push 와 배포는 하지 말 것.

첫 작업은 실제 일이되 작은 것으로 고르라고 한다. 가이드의 예는 "이 명령에 --json 플래그를 더해 줘. 텍스트 출력은 한 바이트도 바뀌면 안 된다. 둘 다 확인해 줘"다[9]. 결과를 확인하는 방법까지 한 문장에 들어 있다.

확인 수단부터 만든다. pstack 의 원칙은 "실제 산출물로 증명하라"인데, 앱을 띄우고 눌러 볼 방법이 없다면 이 원칙이 설 자리가 없다. 확인 스크립트가 없는 프로젝트라면 첫 작업으로 create-verification-skill 을 돌려서 그 프로젝트의 확인 스킬을 만들어 두는 편이 낫다[1][9].

처음 보는 코드는 how 와 why 로 연다. 고치기 전에 현재 흐름과 그렇게 된 이유를 읽게 하면, 엉뚱한 곳에 그럴듯한 수정을 넣는 일이 줄어든다.

설계가 갈리면 묻지 말고 만들어 본다. poteto-mode 는 "어떤 방식으로 할까"라는 질문을 실행으로 확인할 수 있다면 사람에게 묻지 말고 시제품으로 정하라고 지시한다[3]. 사람에게 남겨 두는 질문은 실험으로 정할 수 없는 제품 판단과 취향뿐이다. 후보가 둘 이상이라면 arena 를 쓸 자리다.

병합 전에는 interrogate 를 한 번 돌린다. 실행으로 증명된 지적만 남기므로 검토 결과를 읽는 시간이 짧다.

밤샘 작업은 믿을 만해진 뒤에 맡긴다. 가이드는 자율 반복을 걸기 전에 목표, 끝나는 조건, 허락하는 행동, 멈출 길 네 가지를 계약처럼 적으라고 한다[13]. "네 시간 동안 해 줘"는 끝나는 조건이 아니다. 아침에는 네 시간짜리 결과가 아니라 네 시간짜리 움직임을 보게 된다. 돌아와서는 show-me-your-work 기록의 "Attention" 절부터 읽는다.

작은 일에는 쓰지 않는다. 문구 한 줄이나 정답이 뻔한 한 줄 수정에 플레이북과 다중 검토를 붙이면 시간과 사용량만 든다. 가이드도 비용을 줄이려면 예산을 낮추고 패널을 줄이며, poteto-mode 는 엄밀함이 필요한 일에만 쓰라고 한다[9].

내 방식으로 바꾼다. README 는 poteto-mode 가 자기 취향이라고 밝히며, automate-me 로 내 대화 기록에서 나만의 모드를 만들라고 권한다[1]. 팀의 검증 방법, 배포 순서, 금지 사항이 다르다면 그쪽에 맞추면 된다.

Claude Code 를 쓴다면 다음 순서로 시작할 수 있다.

1. 설치한 뒤 /pstack:setup-pstack 에서 예산은 large 로 두고, 다른 계열 모델이 없으므로 역할을 inherit-parent 로 둔다.
2. 확인 스킬을 만들겠냐는 물음에 "예"를 고른다. CI 가 유일한 확인 수단인 프로젝트라면 push 뒤 CI 결과와 배포된 주소를 확인하는 방법을 그 스킬에 적게 한다.
3. 첫 작업은 재현되는 작은 버그 하나를 고르고, 위의 다섯 가지를 담아 맡긴다.
4. 병합 전에 /pstack:interrogate 로 한 번 깨뜨려 본다.
5. 다른 회사 모델의 검토가 필요하면 해당 모델의 CLI 로 따로 돌리거나, 여러 계열을 묶는 이식판을 검토한다. 이때 원본과 이식판을 함께 깔지 않는다.

먼저 알아 둘 함정

자율성의 기본값이 넓다. poteto-mode 의 자율 규칙은 되돌릴 수 있는 작업은 물론, 팀 채팅, 티켓 갱신, 평가 실행 같은 바깥 행동도 묻지 않고 하라고 적는다[3]. 멈추는 것은 공유 브랜치 강제 push, 배포, 데이터 삭제, 고객에게 가는 메시지다. 사용자가 생각한 "코드만 고쳐 줘"보다 범위가 넓을 수 있다. 처음에는 버려도 되는 브랜치에서 돌리고 운영 자격 증명은 주지 않는 편이 안전하다. 프롬프트에 "하지 말라"고 적는 것과 실행 권한으로 막는 것은 다르다.

지침은 강제 장치가 아니다. pstack 의 순서는 모두 문장으로 적혀 있다. 2026년 11월 3일 올라온 이슈 #1160 은 자동 실행 플레이북에서 주석 정리 단계가 검증 스웜과 동시에 돌아가서, 검증이 끝난 뒤 코드가 바뀐 사례를 보고했다[14]. 같은 이슈는 deslop, control-ui, control-cli 가 다른 플러그인(cursor-team-kit)에 들어 있어 없을 때 에이전트가 임기응변으로 처리한다는 점, 확인 수단이 없으면 PASS 가 아니라 BLOCKED 로 처리해야 한다는 점도 제안했다. 이 세 스킬을 쓰려면 cursor-team-kit 을 함께 설치해야 한다[1]. 11월 5일에는 기능 플레이북의 위임 단계가 Claude Code 에서는 무시되고 Codex 에서는 지나치게 적용된다는 보고도 올라왔다가 같은 날 닫혔다[15]. 환경에 따라 같은 문장이 다르게 지켜진다는 뜻이다.

빠르게 바뀐다. pstack 은 2026년 5월 23일 0.1.0 으로 저장소에 들어왔고, 10월 27일 0.15.36 까지 다섯 달 남짓 동안 79개 판이 나왔다. pstack 을 고친 커밋 169개 가운데 163개는 만든 사람이 직접 올렸다[16]. 이 글의 세부 내용, 특히 기본 모델과 역할 이름은 금방 낡을 수 있다. 쓰기 전에 지금 판의 README 를 다시 봐야 한다.

효과를 보여 주는 숫자는 아직 없다. pstack 이 버그를 몇 퍼센트 줄이는지, 개발이 몇 배 빨라지는지 보여 주는 공개 측정은 찾지 못했다. pstack 에 블라인드 평가 플레이북이 들어 있으므로[17], 도입을 고민한다면 그 방식대로 내 저장소에서 직접 재 보는 것이 가장 정확하다.

다시 검토하면 또 나오는 문제

에이전트와 일하다 보면 흔히 겪는 일이 있다. 검토에서 가장 큰 문제를 짚어 고쳤는데, 다시 검토하면 다른 문제가 나온다. 다른 AI 로 검토하면 또 다른 문제가 나온다. pstack 의 interrogate 는 실행으로 증명된 지적만 남겨 헛지적을 줄인다. 하지만 스킬 자체에는 다시 돌릴 조건이나 멈출 기준이 없다[7]. 아래에서는 이 현상을 원인별로 나누고, pstack 위에 얹어 쓸 만한 보완책을 정리했다. 측정한 결과가 아니라 설계 판단이다.

세 번째 줄의 어림은 소프트웨어 인스펙션 연구가 1990년대부터 다뤄 온 포획-재포획 방법이다[18][19]. 원래는 연못의 물고기 수처럼 모두 셀 수 없는 개체 수를 어림하던 통계다. 두 검토자가 각각 n1, n2 개를 찾고 그중 m 개가 겹치면 전체는 대략 n1 × n2 / m 개다. 둘이 10개와 8개를 찾았는데 4개가 겹쳤다면 전체는 20개 안팎이다. 둘이 합쳐 찾은 14개 말고도 6개쯤 남아 있다는 뜻이다. 같은 계열 모델끼리는 같은 곳을 함께 놓치기 쉬워서 이 어림이 낮게 나온다. 따라서 계열이 다른 검토자를 섞는 것이 이 방법의 전제다. Claude Code 에서 pstack 원본만 쓰면 모든 검토자가 같은 계열이 된다는 앞의 차이가 여기서 다시 걸린다.

도입을 판단하는 기준

지금 일하는 방식에 따라 얻을 수 있는 것이 다르다.

효과를 재 볼 때는 세 가지로 나눠 돌린다. 플러그인 없는 에이전트, 같은 모델에 pstack, 여러 모델에 pstack 이다. 그래야 절차의 효과와 모델을 섞은 효과를 구분할 수 있다. 봐야 할 숫자는 첫 답이 나오는 속도가 아니다. 미리 정한 기준을 실제로 통과했는지, 끝났다고 했지만 끝나지 않았던 비율, 사람이 다시 일러 준 횟수, 확인까지 걸린 시간, 하위 에이전트와 재시도를 합친 사용량이다. 앞 절의 지표도 하나 더한다. 끝났다고 한 뒤 처음 보는 다른 AI 가 새로 찾아서 재현까지 한 결함의 수다.

참고

[1] Lauren Tan. pstack README. cursor/plugins, 2026-11-06 확인.

[2] pstack plugin.json (0.15.36). cursor/plugins, 2026-11-06 확인.

[3] Lauren Tan. poteto-mode SKILL.md. cursor/plugins, 2026-11-06 확인.

[4] Lauren Tan. Bug fix 플레이북. cursor/plugins, 2026-11-06 확인.

[5] Lauren Tan. arena SKILL.md. cursor/plugins, 2026-11-06 확인.

[6] Lauren Tan. swarm SKILL.md. cursor/plugins, 2026-11-06 확인.

[7] Lauren Tan. interrogate SKILL.md. cursor/plugins, 2026-11-06 확인.

[8] Lauren Tan. setup-pstack SKILL.md. cursor/plugins, 2026-11-06 확인.

[9] Lauren Tan. pstack guide 1. Setup. cursor/plugins, 2026-11-06 확인.

[10] Lauren Tan. pstack in Claude Code. cursor/plugins, 2026-11-06 확인.

[11] open-pstack README. ericlitman/open-pstack, 2026-11-06 확인.

[12] Lauren Tan. pstack guide 2. poteto-mode. cursor/plugins, 2026-11-06 확인.

[13] Lauren Tan. pstack guide 7. Overnight. cursor/plugins, 2026-11-06 확인.

[14] pstack autopilot-full: require comment/slop passes before the swarm (#1160). cursor/plugins 이슈, 2026-11-03.

[15] poteto-mode Feature step 4 delegation is ignored on Claude Code and over-applied on Codex (#1176). cursor/plugins 이슈, 2026-11-05.

[16] pstack 커밋 이력. cursor/plugins, 2026-11-06 확인.

[17] Lauren Tan. Eval 플레이북. cursor/plugins, 2026-11-06 확인.

[18] S. G. Eick, C. R. Loader, M. D. Long, L. G. Votta, S. Vander Wiel. Estimating Software Fault Content Before Coding. ICSE 1992, pp. 59-65.

[19] L. C. Briand, K. El Emam, B. G. Freimut, O. Laitenberger. A Comprehensive Evaluation of Capture-Recapture Models for Estimating Software Defect Content. IEEE Transactions on Software Engineering 26(6), 2000, pp. 518-540.