pstack 스킬 분석과 사용법: 장단점부터 조사·설계·검증 흐름까지
스킬 55개와 작업 절차 23개를 소스 기준으로 분석합니다. 구조 다이어그램 2장, 장단점 비교표, Cursor·Claude Code 설치 방법과 상황별 요청 예시를 담았습니다.
코딩 에이전트에게 기능 하나를 맡기면 코드 작성 외에도 여러 판단이 따라온다. 기존 구조를 어디까지 읽을지, 설계를 먼저 비교할지, 작업을 어떻게 나눌지, 무엇을 확인해야 완료라고 할 수 있을지 정해야 한다.
pstack은 이런 판단을 스킬과 작업 절차로 묶은 플러그인이다. 중심에는 요청의 성격을 분류하는 /poteto-mode가 있고, 그 아래에 조사·설계·구현·리뷰·검증 절차가 연결된다. 소스를 읽으며 눈여겨본 부분은 작업을 나누는 방식과 검증 증거를 요구하는 방식이었다.
분석 기준: 2026년 10월 18일 확인한 커밋
0b8e952052d4, 플러그인 버전0.15.26. README, 주요 SKILL.md, playbook과 어댑터를 읽은 정적 분석이다. 플러그인을 설치해 개발 속도나 성공률을 측정한 글은 아니다.
1. 스킬 55개는 어떻게 구성되어 있나
소스 디렉터리를 기준으로 skills/*/SKILL.md를 세면 55개다. 이 중 이름이 principle-로 시작하는 원칙 스킬이 24개이고, 나머지 스킬이 31개다. 별도로 poteto-mode/playbooks에는 작업 절차 문서 23개, agents에는 에이전트 정의 2개가 있다.
이 숫자들은 서로 같은 단위가 아니다. playbook은 개별 스킬을 어떤 순서로 사용할지 정한 문서이고, 원칙 스킬은 그 과정에서 판단 기준으로 참조된다.
| 구성 | 역할 | 예시 |
|---|---|---|
| 진입점 | 요청에 맞는 절차를 고르고 진행을 관리 | poteto-mode |
| 작업 스킬 | 조사·설계·비교·리뷰 등 특정 작업 수행 | how, architect, arena |
| 원칙 스킬 | 변경 범위, 데이터 구조, 검증 등의 판단 기준 | 경계에서 검증하기, 실제 동작 입증하기 |
| playbook | 버그 수정·기능 개발·PR 등의 진행 순서 | Bug fix, Feature, Shipping |
| 에이전트 정의 | 위임받은 역할의 행동 규칙 | poteto-agent, comment-sicko |
소개 페이지의 개수는 업데이트 시점에 따라 달라질 수 있다. 이 글에서는 위 커밋에 실제로 들어 있는 파일을 기준으로 삼았다.
2. /poteto-mode는 요청에 맞는 절차를 고른다
/poteto-mode의 역할은 모든 스킬을 한 번씩 실행하는 것이 아니다. 버그 수정인지, 구조 조사인지, 기능 개발인지 판단해 해당 playbook을 선택한다.
그림 1. 전체 23개 playbook 중 대표 경로 세 개를 요약했다. 실제 호출 스킬은 작업의 범위와 불확실성에 따라 달라진다.
진행 책임은 메인 대화에 남는다. 메인 에이전트가 절차와 할 일 목록을 관리하고, 조사나 구현처럼 범위가 정해진 일을 하위 에이전트에게 맡긴다. 전체 작업을 통째로 넘긴 뒤 결과를 기다리는 구조는 지양한다.
예를 들어 버그 수정 playbook은 실제 UI나 CLI에서 문제를 재현하는 데서 출발한다. 가설을 세우고 실행 증거로 원인을 좁힌 다음, 수정 후에는 문제가 나타났던 경로로 다시 확인한다.
기능 개발 playbook은 기존 구조 조사와 설계를 거친 뒤, 병렬로 진행할 수 있는 작업과 순서를 지켜야 하는 작업을 구분한다. 같은 파일이나 공유 상태를 여러 작업자가 건드리는지 먼저 살피는 단계도 있다.
이 구조를 적용하면 완료 보고에서 확인할 항목이 구체적이 된다. 어떤 경로로 재현했는지, 누가 무엇을 구현했는지, 최종 결과를 어떤 조건에서 확인했는지를 물을 수 있다.
근거: poteto-mode, playbook 디렉터리.
3. how와 architect: 구현 전에 무엇을 알아야 하나
how는 코드베이스가 어떻게 작동하는지 설명하는 스킬이다. 단순한 질문에는 한 에이전트가 조사와 설명을 맡는다. 복잡한 질문에는 2~4개의 읽기 전용 조사 작업을 나누고, 별도의 설명 담당이 결과를 합친다.
최종 설명은 파일 목록을 나열하는 수준을 넘어야 한다. 주요 구성요소가 무엇을 책임지는지, 실행 중 데이터가 어디로 흐르는지, 변경할 때 조심할 경계가 어디인지를 다룬다.
architect는 이렇게 파악한 구조를 바탕으로 변경 설계를 만든다. 절차는 다음과 같다.
- 현재 코드와 제약을 읽어 설계의 근거를 확보한다.
- 타입, 함수 시그니처, 모듈 뼈대로 변경 형태를 드러낸다.
- 사용자가 사전 합의를 요청했다면 그 지점에서 확인받는다.
- 정한 경계 안에서 구현한다.
- 우회 코드가 반복해서 필요해지면 설계의 전제를 다시 검토한다.
여기서 주목할 부분은 마지막 단계다. 구현할수록 예외 처리나 탈출구가 계속 늘어난다면, 처음 정한 경계가 맞는지 다시 보도록 한다. 설계 문서를 작성했다는 사실만으로 그 설계를 끝까지 유지하지 않는다.
또한 사전 승인 단계는 선택 사항이다. 팀에서 “설계 검토 후 구현”이 필요하다면 요청에 명시해야 한다.
4. swarm·arena·interrogate는 각각 무엇을 병렬화하나
세 스킬 모두 여러 에이전트나 모델을 활용하지만, 목적과 산출물이 다르다.
그림 2. 작업 범위를 넓게 확인할지, 여러 해법을 만들지, 이미 만든 변경을 비판적으로 검토할지에 따라 선택이 달라진다.
swarm: 넓은 범위를 나누어 확인한다
swarm은 먼저 목표와 완료 조건을 정한다. 그다음 범위를 분할할지, 같은 문제를 여러 작업자가 풀게 할지, 두 방식을 섞을지 결정한다. 먼저 통과한 결과를 쓸지, 모든 결과를 비교할지도 시작 전에 정한다.
결과는 PASS, ISSUES, BLOCKED처럼 상태를 구분해 모은다. 응답하지 않은 작업자를 성공으로 처리하지 않는다. 검증 작업이라면 대상 커밋과 측정 방법도 구체적으로 남겨야 한다.
여러 서비스의 설정을 점검하거나 서로 독립적인 재현 경로를 확인하는 작업에 맞는 구조다.
arena: 같은 과제의 대안을 비교한다
arena는 후보들에게 같은 과제를 주고 서로 다른 결과물을 만들게 한다. 후보별 출력 위치를 분리하고, 가능하면 Git worktree를 사용한다.
평가 담당은 3~6개의 구체적인 기준으로 후보를 비교한다. 별도의 읽기 전용 심사자도 판단에 참여한다. 최종적으로 기준안을 선택하고, 다른 후보에서 가져올 가치가 있는 부분을 제한적으로 반영한다.
통합 결과는 다시 검증한다. 각 후보가 따로 성립했더라도 두 구현을 섞은 결과가 그대로 성립한다는 보장은 없기 때문이다.
산출물에는 어떤 안을 골랐는지, 무엇을 가져왔고 무엇을 버렸는지, 검증 결과는 어땠는지가 따라붙는다.
interrogate: 변경을 독립적으로 비판한다
interrogate는 같은 의도·변경 내용·맥락을 여러 모델에 전달해 검토받는다. 다른 이름의 역할을 부여하는 것보다 실제 모델의 다양성을 중시한다.
취합할 때는 중복 지적과 의견 차이를 드러내고, 지적을 즉시 반영할 것·추가 검토할 것·기록할 것·기각할 것으로 분류한다. 기각에도 이유를 남긴다.
이 스킬의 결과는 판정이다. 발견한 지적을 자동으로 코드에 적용하지 않는다. 검토와 변경을 별도 단계로 유지하는 셈이다.
근거: swarm, arena, interrogate.
5. 검증 절차 자체를 스킬로 만든다
pstack에서 실무에 옮겨 볼 만한 부분은 create-verification-skill이다. 프로젝트별로 실행 가능한 검증 절차를 만들어 .cursor/skills/verify-<app>/SKILL.md에 저장하도록 한다.
문서에는 앱을 어떻게 띄우는지, 준비 상태를 어떻게 확인하는지, 사용자가 어떤 경로로 기능을 실행하는지, 어떤 증거를 남기는지, 마지막에 무엇을 정리하는지가 들어간다.
| 항목 | 담아야 할 내용 |
|---|---|
| Launch | 실행 명령과 필요한 환경 |
| Doctor | 실행 전후의 준비 상태 확인 |
| Drive | 실제 UI·CLI 등 사용 경로 |
| Evidence | 성공을 판단할 결과와 증거 파일 |
| Cleanup | 테스트 자원 정리 |
| Helpers | 반복 실행을 돕는 보조 도구 |
작성 후에는 그 절차로 기능 하나를 처음부터 끝까지 실행해야 한다. 실행하지 못한 검증 스킬은 초안으로 취급한다. 정리 작업을 끝낸 뒤에도 증거 파일이 남는지도 확인한다.
블로그의 이미지 첨부 기능을 예로 들면, 업로드 함수만 호출하는 확인으로는 부족하다. 글 작성 화면에서 이미지를 넣고 저장한 뒤, 글 상세에서 해당 이미지가 보이는 경로까지 확인하도록 절차를 적을 수 있다. 이는 설명을 위한 예시이며 이번 분석에서 실행한 테스트는 아니다.
maintain-verification-skill은 시간이 지나 낡은 검증 절차를 관리한다. 수정 범위를 검증 스킬 디렉터리로 제한하고, 제품 코드의 문제는 별도로 보고하도록 한다. 제품이 잘못 동작하는데 기대 결과를 낮춰 검증만 통과시키는 일을 막으려는 규칙이다.
Shipping playbook에는 PR 작성자와 다른 검증 담당자를 두는 규칙도 있다. CI 통과와 실제 동작 확인을 함께 보고, 검증 후 코드가 바뀌었다면 이전 커밋의 증거를 그대로 재사용하지 않는다.
근거: 검증 스킬 생성, 검증 스킬 유지보수, Shipping을 포함한 playbook.
6. 긴 작업의 판단을 어떻게 남기나
show-me-your-work는 긴 자율 작업에서 결정과 근거를 TSV 로그로 남긴다. 열은 시각, 단계, 결정, 이유, 증거, 결과로 구성된다.
로그에는 검증 결과 파일이나 커밋처럼 다시 확인할 수 있는 대상을 연결한다. 잘못된 판단을 했을 때는 기존 기록을 지우기보다 이를 정정하는 기록을 추가한다. 리뷰에 필요할 때만 저장소에 포함하도록 해 작업 로그가 무조건 제품 변경에 섞이지 않게 한다.
reflect는 현재 대화의 작업 기록을 검토해 스킬 개선안을 만든다. 판단, 도구 사용, 다른 접근 가능성을 검토한 뒤 수용·기각·백로그로 정리한다. 수용한 개선안도 스킬에 적용하기 전에는 사용자 승인을 요구한다.
따라서 pstack의 회고 기능을 “사용할수록 스킬이 자동으로 학습된다”고 설명하면 부정확하다. 개선 후보를 만들고 승인받아 문서를 수정하는 절차에 가깝다.
근거: show-me-your-work, reflect.
7. 설치와 첫 작업
README가 안내하는 Cursor 설치 명령은 다음과 같다.
/add-plugin pstack
설치 후 /setup-pstack으로 역할별 모델과 추론 수준을 설정하고, /poteto-mode로 작업을 시작한다.
setup-pstack의 small·medium·large·unlimited는 추론 수준을 고르는 설정이다. 금액 기준의 지출 상한을 강제하는 기능으로 해석하면 안 된다. 설정은 ~/.cursor/rules/pstack-models.mdc에 기록되며 사용 가능한 모델을 확인하는 과정이 포함된다.
첫 작업은 범위와 완료 조건이 분명한 버그 수정이 적절해 보인다. 예를 들어 다음처럼 요청할 수 있다.
/poteto-mode
글 작성 화면에서 이미지를 첨부하면
저장은 성공하지만 글 상세에서 이미지가 보이지 않는다.
먼저 현재 코드에서 재현 경로와 원인을 확인해줘.
수정 범위는 이미지 업로드와 본문 렌더링 경로로 제한해줘.
완료 조건:
- 작성 화면에서 이미지 첨부와 저장이 가능하다.
- 저장 후 상세 페이지를 새로고침해도 이미지가 보인다.
- 수정한 커밋과 실제로 확인한 경로를 남긴다.
배포와 외부 메시지 전송은 이번 작업에 포함하지 않는다.
이 예시는 실제 실행 결과가 아니라 작업 범위를 전달하는 요청문이다. 사용 가능한 UI 조작 도구, 실행 환경, 접근 권한이 있어야 끝까지 검증할 수 있다.
README에는 Claude Code용 설치 경로도 있다.
/plugin marketplace add cursor/plugins
/plugin install pstack@cursor-plugins
Claude Code에서는 /pstack:poteto-mode, /pstack:setup-pstack처럼 접두사가 붙는다. 어댑터는 도구 호출과 작업 격리 방식을 환경에 맞게 바꾼다. Cursor 전용 기능은 그대로 사용할 수 없고, 비-Claude 모델 설정을 부모 모델로 대체하는 경우에는 원래 의도한 모델 다양성도 유지되지 않는다.
근거: README, setup-pstack. 명령과 지원 범위는 위 분석 커밋 기준이다.
실제 사용 순서: 설치 → 설정 → 요청 → 결과 확인
- 작업할 프로젝트를 Cursor에서 연다. 먼저 프로젝트의 기본 실행 명령이 동작하는지 확인한다. 실행 환경이 깨져 있으면 에이전트가 기능 수정과 환경 복구를 동시에 떠안게 된다.
/add-plugin pstack으로 설치한다. 이어서/setup-pstack을 실행해 현재 사용할 수 있는 모델과 역할별 추론 수준을 선택한다.- 슬래시 메뉴에서
/poteto-mode를 선택한 뒤 요청을 입력한다. README는 메뉴에서 스킬을 골라 메시지에 첨부하는 방식을 안내한다. - 목표·범위·완료 조건을 함께 적는다. 원하는 결과, 수정해도 되는 영역, 실제로 확인할 동작을 구분하면 작업이 불필요하게 커지는 것을 줄일 수 있다.
- 완료 보고에서 증거를 확인한다. 변경 파일과 커밋, 실행한 명령이나 사용 경로, 확인하지 못한 항목을 읽는다. 스크린샷이나 로그가 있다면 최종 변경을 대상으로 만든 자료인지 확인한다.
처음부터 모든 명령을 외울 필요는 없다. 보통은 /poteto-mode로 시작하고, 조사나 리뷰만 필요할 때 개별 스킬을 고르면 된다.
| 하고 싶은 일 | 선택할 명령 | 요청에 덧붙일 정보 |
|---|---|---|
| 어디서 시작할지 모르겠다 | /poteto-help |
지금 해결하려는 문제와 현재 막힌 지점 |
| 기존 구조를 이해하고 싶다 | /how |
조사 대상과 알고 싶은 실행 흐름 |
| 기능 구현이나 버그 수정을 맡긴다 | /poteto-mode |
범위, 재현 방법, 완료 조건 |
| 다른 설계를 비교하고 싶다 | /arena |
동일한 과제, 제약, 원하는 산출물 |
| 여러 영역을 나누어 점검한다 | /swarm |
점검 범위와 통과 기준 |
| 현재 변경을 리뷰받는다 | /interrogate |
대상 diff와 변경 의도 |
| 앱별 검증 절차를 만든다 | /create-verification-skill |
대상 앱과 검증하고 싶은 사용자 동작 |
바로 바꿔 쓸 수 있는 요청 예시
다음은 사용법을 설명하기 위한 예시다. 코드나 테스트를 실행해 얻은 결과는 아니다.
구조 조사
/how
로그인 요청이 들어온 뒤 세션이 저장되는 흐름을 설명해줘.
관련 모듈의 책임과 실패 시 처리 경로를 짚어줘.
이번에는 코드를 수정하지 말아줘.
기능 개발
/poteto-mode
글 목록에 카테고리 필터를 추가해줘.
기존 URL 구조를 확인한 뒤 현재 구현 방식에 맞춰 설계해줘.
완료 조건:
- 전체 글과 특정 카테고리를 전환할 수 있다.
- 필터 상태에서 새로고침해도 선택이 유지된다.
- 해당 카테고리에 글이 없을 때 빈 상태를 보여준다.
설계안을 먼저 보여주고, 내가 확인한 뒤 구현을 시작해줘.
현재 변경에 대한 리뷰
/interrogate
현재 브랜치의 변경을 기본 브랜치와 비교해 검토해줘.
이미지 업로드 실패 처리와 기존 글 호환성을 중점적으로 봐줘.
발견 사항을 근거와 함께 분류하고, 코드는 수정하지 말아줘.
첫 작업이 끝나면 결과를 보고 필요한 절차를 추가하는 편이 낫다. 실행 방법이 자꾸 바뀐다면 검증 스킬을 만들고, 설계 선택에서 자주 막힌다면 arena를 사용한다. 여러 모델을 투입하는 것 자체를 목표로 삼을 필요는 없다.
8. Claude Code에 적용하기
Claude Code가 설치되어 있고, 작업할 저장소를 연 상태를 기준으로 한다. 아래 슬래시 명령은 셸이 아니라 Claude Code 대화창에 입력한다.
1단계: 마켓플레이스 등록과 플러그인 설치
/plugin marketplace add cursor/plugins
/plugin install pstack@cursor-plugins
첫 줄은 플러그인을 찾을 저장소를 등록하고, 둘째 줄은 그 마켓플레이스의 pstack을 설치한다. 저장소 README에 따르면 Claude Code는 루트의 harness/pstack/에 생성된 배포용 사본을 사용한다. 일반 사용자는 이 사본을 직접 생성하거나 원본 스킬을 하나씩 복사할 필요가 없다.
2단계: Claude Code용 모델 설정
설치 후 다음을 실행한다.
/pstack:setup-pstack
사용 가능한 모델과 추론 수준을 확인하고 역할별 구성을 선택하는 단계다. 어댑터가 안내하는 설정 파일은 다음과 같다.
~/.claude/rules/pstack-models.md
Cursor의 ~/.cursor/rules/pstack-models.mdc와는 경로와 형식이 다르다. 모델 역할 설정은 CLAUDE.md나 AGENTS.md에 옮겨 적지 않고 위 파일에서 관리하도록 되어 있다. 어댑터는 이 규칙이 새 세션에 로드된다고 설명한다.
모델 이름은 현재 세션에서 허용하는 값으로 설정해야 한다. Cursor용 모델 식별자를 그대로 붙여 넣는 방법은 피하는 편이 좋다. pstack 어댑터는 비-Claude 모델을 지정한 역할을 부모 세션 모델로 대체하도록 한다. 따라서 Cursor에서 Grok과 Claude를 나누어 쓰던 구성이 Claude Code에서도 같은 조합으로 실행되는 것은 아니다.
3단계: 접두사를 붙여 작업 시작
Claude Code에서는 명령 앞에 pstack:이 붙는다.
| Cursor | Claude Code |
|---|---|
/poteto-mode |
/pstack:poteto-mode |
/setup-pstack |
/pstack:setup-pstack |
/how |
/pstack:how |
/arena |
/pstack:arena |
/interrogate |
/pstack:interrogate |
/create-verification-skill |
/pstack:create-verification-skill |
처음에는 다음처럼 읽기 전용 조사로 연결 상태와 응답 방식을 확인할 수 있다.
/pstack:how
이 저장소의 실행 진입점과 주요 모듈을 설명해줘.
앱 실행 명령과 테스트 명령을 파일에서 확인해줘.
파일은 수정하지 말아줘.
이후 실제 변경을 맡길 때는 목표와 완료 조건을 함께 적는다.
/pstack:poteto-mode
현재 저장소의 글 목록에 카테고리 필터를 추가해줘.
먼저 기존 라우팅과 글 데이터 구조를 확인해줘.
설계를 먼저 제시하고, 내 확인 후 구현을 시작해줘.
완료 조건:
- 카테고리 선택이 URL에 반영된다.
- 새로고침해도 같은 필터가 유지된다.
- 빈 결과 화면을 확인할 수 있다.
- 실제 확인한 동작과 확인하지 못한 항목을 구분해 보고한다.
이번 작업은 로컬 수정과 검증까지다.
위 요청은 사용 예시다. 실제 프로젝트의 데이터 구조나 실행 환경에 맞춰 완료 조건을 바꿔야 한다.
4단계: 프로젝트 전용 검증 스킬 생성
기능을 반복해서 확인해야 한다면 다음을 실행할 수 있다.
/pstack:create-verification-skill
이 앱의 실행과 사용자 동작 검증 절차를 만들어줘.
글 작성 → 저장 → 상세 확인 경로를 우선 대상으로 해줘.
절차를 작성한 뒤 실제로 한 번 실행하고 증거를 남겨줘.
어댑터의 경로 규칙을 따르면 프로젝트 스킬은 .claude/skills/ 아래에 위치한다. 검증 스킬의 예상 형태는 .claude/skills/verify-<app>/SKILL.md다. 서버 실행, 브라우저 조작, 테스트 계정 등이 필요하면 해당 환경도 갖춰져 있어야 한다.
Cursor와 달라지는 부분
| 항목 | Claude Code에서의 처리 |
|---|---|
| 하위 작업 위임 | Cursor의 Task 호출을 Agent 호출에 맞게 변환 |
| 클라우드 작업 격리 | 대응 가능한 작업을 Git worktree 격리로 전환 |
| 모델 구성 | Claude 계열 설정을 허용 값에 맞게 변환하고 비-Claude 설정은 부모 모델 사용 |
| Cursor Automations | 필요한 기능이 없으면 생략 사실과 이유를 보고 |
| Bugbot | 기존 PR 댓글은 다룰 수 있지만 Cursor 전용 실행·설정 단계는 지원 조건에 따라 생략 |
| PR 생성 | 내장 도구 대신 절차에서 지정한 gh 등의 명령 사용 |
gh로 PR을 만들려면 별도의 설치·인증·저장소 권한이 필요하다. worktree도 클라우드 머신 전체를 제공하는 기능은 아니다.
진행 결과에 Skipped in Claude Code가 있다면 어떤 단계가 빠졌는지 읽어야 한다. 빠진 단계가 완료 조건에 필요했다면 그 작업은 아직 검증된 것으로 볼 수 없다. 명령이 보이지 않는 경우에는 설치·활성화 상태와 /pstack: 접두사를 먼저 확인하고, 모델 오류가 나면 /pstack:setup-pstack으로 현재 허용되는 구성을 다시 선택한다.
근거: Claude Code 어댑터, 설치 안내. 지원 범위는 분석 커밋 기준이며, 실제 실행 도구가 허용하는 값이 우선한다.
9. 장점과 단점: 어떤 작업에 맞나
아래 평가는 스킬의 절차를 읽고 판단한 장단점이다. 개발 속도나 결함 감소율을 실측한 결과는 아니다.
| 장점 | 실제로 도움을 기대할 수 있는 지점 |
|---|---|
| 작업 절차가 명시되어 있다 | 조사·설계·구현·검증 중 빠진 단계가 무엇인지 확인하기 쉽다 |
| 병렬 작업의 목적을 구분한다 | 범위 분할, 대안 생성, 독립 리뷰를 상황에 맞게 선택할 수 있다 |
| 완료 판단에 실행 증거를 요구한다 | “수정했다”는 보고와 실제 사용 경로에서 확인한 결과를 구분할 수 있다 |
| 프로젝트별 검증 방법을 남긴다 | 다음 변경이나 다른 에이전트도 같은 실행·확인 절차를 참조할 수 있다 |
| 역할별 모델을 설정할 수 있다 | 계정에서 사용할 수 있는 모델과 작업의 성격에 맞춰 구성을 조정할 수 있다 |
| 판단 이유와 회고를 기록한다 | 어떤 근거로 안을 선택하거나 지적을 기각했는지 추적하기 쉽다 |
| 단점·부담 | 도입할 때 생기는 문제 |
|---|---|
| 병렬 호출과 평가의 비용 | 후보 생성과 교차 리뷰가 늘수록 호출량과 취합 시간이 증가한다 |
| 작은 작업에는 절차가 과할 수 있다 | 문구 한 줄 수정에도 큰 흐름을 적용하면 실제 변경보다 준비가 길어진다 |
| 실행 환경과 외부 도구에 의존한다 | UI 조작, 모델 선택, Git 작업 등 필요한 기능이 없으면 일부 단계가 막힌다 |
| 프로젝트별 유지보수가 필요하다 | 실행 명령이나 화면이 바뀌면 검증 스킬도 갱신해야 한다 |
| 지침 준수가 보장되지는 않는다 | 모델이 절차를 누락하거나 잘못된 증거를 해석할 가능성은 남는다 |
| 환경 간 동작이 완전히 같지 않다 | Claude Code 어댑터에서는 Cursor 전용 기능이나 모델 조합이 달라질 수 있다 |
기존 코드가 복잡하고 재현·검증 경로가 있는 작업에서 먼저 시험해 볼 만하다. 여러 모듈을 건드리는 기능 변경, 원인을 좁혀야 하는 버그, 설계 대안 비교가 여기에 들어간다.
문구 수정이나 범위가 분명한 단순 변경은 필요한 스킬만 쓰는 편이 가볍다. 앱을 실행할 방법부터 없는 프로젝트라면 병렬 작업을 늘리기 전에 실행과 검증 경로를 확보하는 일이 우선이다.
도입 효과는 비슷한 규모의 작업 몇 개에서 수정 시간, 검토 시간, 호출 비용, 검증 중 발견한 문제를 기록해 판단할 수 있다. 에이전트 수가 늘었다는 사실만으로 품질이 좋아졌다고 볼 수는 없다.
10. 도입할 때 확인할 세 가지
병렬 실행에는 호출 비용과 취합 비용이 든다. 후보를 여러 개 만들고 교차 평가하면 모델 호출이 늘어난다. 작은 수정에도 같은 절차를 모두 적용할 이유는 없다. 이 글에서 확인한 것은 절차의 설계이며, 비용 대비 효과는 실제 작업에서 따로 측정해야 한다.
문서가 참조하는 도구를 모두 pstack이 제공하지는 않는다. deslop, control-cli, control-ui 등은 별도의 cursor-team-kit에 속한다. 스킬에 적힌 절차와 현재 환경에서 실행할 수 있는 기능을 구분해야 한다.
스킬 문서는 실행 권한을 강제하는 장치가 아니다. pstack에는 자율 진행에 관한 적극적인 지침이 들어 있다. 팀의 배포 승인, 데이터 삭제 제한, 외부 서비스 접근 권한은 실행 환경에서도 관리해야 한다. 지시문에 제한을 적는 것과 실제 도구 권한을 제한하는 것은 별도의 작업이다.
소스를 읽고 가장 먼저 가져오고 싶은 부분은 프로젝트별 검증 스킬이었다. 앱을 띄우는 명령, 실제 사용 경로, 완료를 판단할 증거를 한곳에 적고 직접 실행해 두면 다음 변경에서도 같은 기준을 쓸 수 있다. 그 기반 위에서 조사 범위가 넓어질 때 swarm, 설계 대안이 필요할 때 arena, 변경에 대한 독립적인 비판이 필요할 때 interrogate를 붙이는 순서가 이해하기 쉽다.
원본: cursor/plugins의 pstack · 분석에 사용한 고정 커밋 · 플러그인 메타데이터
다이어그램 두 장은 해당 커밋의 스킬 문서를 바탕으로 작성한 해설 이미지다.