pstack-claude: Cursor 스킬 스택을 여러 코딩 에이전트로 이식하다

배경과 문제 정의

코딩 에이전트의 성능은 지난 1년간 빠르게 좋아졌지만, 같은 모델도 작업마다 행동이 크게 달라집니다. 약점은 모델이 아니라 그 주변의 절차에 있는 경우가 많습니다. 에이전트가 장애를 재현하기 전에 코드부터 고칩니다. 증거를 확인하지 않고 수정이 끝났다고 선언합니다. 작은 변경을 넓은 범위의 리팩터링으로 키웁니다. pstack이 겨냥하는 것은 바로 이런 절차의 공백입니다.

README에 따르면 Lauren Tan의 pstack은 에이전트의 결과를 개선하기 위한, 입장이 분명한 Cursor 스킬 스택입니다. pstack-claude는 그 이식판으로, Claude Code, Codex, Pi 등 다른 에이전트 환경을 대상으로 합니다. 저장소 설명에는 OpenCode, Gemini, Prime Agent도 나옵니다. 이식의 어려움은 글을 복사하는 데 있지 않습니다. Cursor가 제공하는 서브에이전트, 질문, 깨우기 같은 기본 요소를 다른 환경의 대응물로 옮기는 데 있습니다. 저장소는 이를 "Cursor primitives translated for other harnesses"라고 요약합니다.

이 문제는 현실적입니다. 팀은 여러 에이전트 도구를 함께 쓰는 일이 많고, 도구마다 스킬 형식과 호출 방식이 다릅니다. 좋은 워크플로가 한 편집기에 묶여 있으면 경험을 재사용할 수 없습니다. 이식판은 같은 방법이 여러 환경에서 일관되게 동작하도록 해 줍니다. 방법에 대한 안내를 덧붙입니다. 이 글은 저장소 README를 읽고 쓴 것입니다. 프로젝트를 설치하거나 실행하지 않았으므로, 효과에 대한 판단은 설계 분석이지 측정 결과가 아닙니다.

핵심 아키텍처와 기술 원리

README로부터 이 프로젝트를 네 개의 층으로 재구성할 수 있습니다. 첫째 층은 진입 스킬인 poteto-mode입니다. "페이지를 바꿀 때 검색 필터가 초기화되는 문제를 고쳐 줘"처럼 목표를 말하면 알맞은 워크플로를 고릅니다. README는 코드를 간결하고 단순하며 검증된 상태로 유지한다고 설명합니다. SKILL.md에는 계획, 기능 개발, 리팩터링, 성능 문제, 조사, 프로토타입, PR 유지보수, 배포, 장기 프로젝트를 다루는 플레이북이 나열되어 있습니다. 둘째 층은 조합할 수 있는 스킬 모음입니다. README 예시에는 `how`, `why`, `architect`가 나옵니다. 버그의 경우 흐름은 이렇습니다. 먼저 장애를 재현합니다. `how`와 `why`로 조사합니다. 수정을 위임합니다. 마지막으로 실패하던 사례를 다시 실행합니다. 수정이 함수 경계를 넘으면 구현 전에 poteto-mode가 `architect`를 불러옵니다. 사용자는 수정 결과와 함께 실패 증거와 통과 증거를 받습니다. 이렇게 증거를 먼저 내놓는 전달 방식이 설계에서 가장 값진 부분입니다.

셋째 층은 각 실행 환경에 맞춘 적응입니다. Claude Code에서는 플러그인 마켓플레이스로 `/plugin marketplace add michael-denyer/pstack-claude`와 `/plugin install pstack@pstack-claude`를 사용합니다. Codex는 `codex plugin marketplace add`와 `codex plugin add`를 씁니다. Pi는 `pi install git:github.com/michael-denyer/pstack-claude`를 씁니다. Pi에서는 패키지가 pstack 확장도 불러와 서브에이전트, 질문, 깨우기 도구와 `/loop` 명령, 라우팅 지침을 추가합니다. 즉 이 이식은 스킬 문장만 옮기는 것이 아니라, 기본 요소가 없는 환경에는 구현을 채워 넣습니다. 넷째 층은 정책과 설정입니다. 이식판은 업스트림을 추적하면서 이름 있는 정책 포크를 가지며, 각각 `tools/forks.json`에 선언됩니다. `setup-pstack` 스킬로 모델 기본값을 바꾸고 역할별 추론 강도를 정할 수 있습니다. README의 예는 `arena runners: opus @xhigh, fable @max`입니다. Claude Code에서는 이런 설정이 플러그인의 `pstack:effort-` 또는 `pstack:poteto-agent-` 에이전트를 통해 전달됩니다. 강도를 지정하지 않은 역할은 세션의 강도를 따르며, 설정 시트의 `default effort` 줄에 지정이 있으면 그것을 따릅니다. 자동 라우팅은 끌 수 있습니다.

실용성과 검증 결과

주목할 기능은 세 가지입니다. 첫째는 자동 라우팅입니다. Claude Code와 Codex에서는 플러그인이 라우팅 훅을 설치해, 들어오는 작업이 먼저 poteto-mode를 거치게 합니다. Codex는 훅이 실행되기 전에 `/hooks`로 신뢰를 허용하라고 요구합니다. 훅은 에이전트의 동작을 바꾸므로 조용히 켜져서는 안 된다는 점에서 타당한 보안 설계입니다. Pi에서는 확장이 같은 라우팅 지침을 주입합니다. 둘째는 역할별 모델과 추론 강도 설정입니다. 비용이 큰 고강도 추론은 필요한 역할에만 주고 나머지는 낮은 강도로 돌릴 수 있습니다. 품질과 비용 사이의 균형을 세밀하게 조절할 수 있습니다. 셋째는 데이터 처리의 경계입니다. README는 pstack에 서버도 텔레메트리도 없다고 분명히 밝힙니다. 스킬이 에이전트에게 읽게 하는 모든 내용은 세션 기록을 포함해 사용자의 모델 제공자에게 전달됩니다. 스크립트는 로컬에서 실행되고, PR 도구는 사용자의 GitHub CLI 로그인을 씁니다. 데이터가 기기 밖으로 나가지 않는다고 약속하지 않고, 데이터가 어디로 가는지를 솔직하게 적은 점이 돋보입니다.

사용 면에서는 실패하는 테스트 사례로 쓸 수 있는 버그처럼 합격 기준이 분명한 작업에 맞습니다. 요구가 모호한 탐색적 작업에는 계획과 조사 플레이북이 더 어울립니다. 한계도 적어 둡니다. 절차가 엄격할수록 작업 하나에 드는 호출과 시간이 늘어납니다. 결과는 기반 모델이 지시를 따르는 능력에 달려 있습니다. 기본 요소의 번역이 모든 환경에서 완전히 같은지는 사용자가 자신의 대상 환경에서 직접 확인해야 합니다. 작성 시점에 저장소의 별은 약 1,194개입니다. 재현 가능한 비교 평가를 찾지 못했으므로 결과가 얼마나 좋아지는지는 결론짓지 않습니다.

업계에 미치는 영향과 전망

pstack-claude는 형태를 갖춰 가는 흐름을 보여 줍니다. 스킬과 워크플로가 특정 에이전트 제품에서 독립한, 옮길 수 있는 자산이 되고 있다는 것입니다. 예전에는 프롬프트와 절차가 한 편집기의 설정 안에 갇혀 있었습니다. 이제는 플러그인 마켓플레이스, 스킬 디렉터리, 훅 장치가 여러 도구에서 비슷한 모습을 띠어, "한 번 쓰고 여러 곳에 설치"가 현실적으로 되고 있습니다. 또한 업스트림과 다운스트림을 나란히 유지하는 방식도 보여 줍니다. 이식판은 업스트림을 추적하면서 자신의 정책 차이를 `tools/forks.json`이라는 명시적 목록에 적습니다. 조용히 고치는 것보다 투명하고, 사용자는 자신이 어떤 규칙을 설치했는지 알 수 있습니다. 작성자는 별도 플러그인 agent-formal-verify도 공개합니다. 테스트가 닿지 않는 동시성 버그와 불변식을 위해 TLA+ 모델 검사와 Lean 증명을 더하는 것입니다. 역할 분담은 분명합니다. pstack은 일상 워크플로의 엄밀함을 맡고, 형식 검증은 테스트가 놓치는 구석을 맡습니다.

앞으로의 쟁점은 두 가지입니다. 하나는 각 도구가 진화하면서 환경 간 기본 요소의 차이가 커지고, 이식 비용도 계속 오르지 않을까 하는 점입니다. 다른 하나는 워크플로의 품질을 객관적으로 측정할 수 있느냐는 점입니다. 공개되고 재현 가능한 평가가 나와야 스킬 스택이 "그럴듯해 보인다"에서 "효과가 입증되었다"로 넘어갈 수 있습니다. 써 보려는 팀은 위험이 낮은 저장소에서 이미 있는 실패 사례 하나로 시작해, 전달된 증거가 재작업을 실제로 줄이는지 확인해 보길 권합니다.