Testing pstack in Grok Bot: Unleashing Poteto-Mode

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

Grok Bot에서 Pstack의 Potato Mode를 시험한 결과, 작업별 플레이북과 실행 검증을 활용해 게임 MVP를 만들었지만 내부 작업의 가시성과 제어권에는 한계가 드러났다.

📌 핵심 요점

1. Pstack은 엔지니어링 경험을 스킬과 원칙으로 묶은 플러그인이다. Potato Mode에 자연어로 작업을 전달하면 적합한 플레이북을 선택하고 필요한 스킬을 단계별로 사용한다.
2. 핵심 기준은 코드 생성량보다 실행 증거다. 앱 실행, 영상·트레이스, 실제 값 확인, 실패 테스트와 재현 절차를 통해 작업 완료를 입증하도록 설계됐다.
3. 긴 계획만 작성하기보다 여러 프로토타입을 비교하고, 데이터 구조를 먼저 정하며, 문제를 해결하는 최소 변경을 지향한다. 모델별 역할 분담도 설정할 수 있다.
4. 실습에서는 기존 Token Burn 프로젝트를 이어받아 단계별 계획, 스테이지 상태, 풀이 재현, 브라우저 플레이 화면을 구현했다. 직접 플레이로 스테이지 완료를 확인했으며, 이후 반복 이동·점프 버그도 발견했다.
5. 진행자는 Grok Bot의 간결한 UI와 속도를 긍정적으로 평가했다. 다만 사용 모델과 도구 호출을 파악하기 어렵고 일부 기능은 구독 제약을 받아, Pstack 전체 기능이나 순수한 성능 개선 효과를 검증한 실험으로 보기는 어렵다.

🧩 배경과 문제 정의

영상은 Pstack과 Grok Bot을 처음 본격적으로 탐색하는 진행자의 실습 기록이다. 진행자는 Pstack을 Lauren Tan이 자신의 엔지니어링 경험을 바탕으로 만든 스킬 묶음으로 소개하고, Potato Mode의 작동 원리를 설명한 뒤 기존 게임 프로젝트에 적용한다.

문제의식은 AI가 코드를 많이 생성하더라도 그 결과를 믿고 맡길 수 있느냐에 있다. Pstack은 작업별 플레이북, 작은 변경, 데이터 중심 설계와 실행 검증을 통해 이를 다루려 한다. 실습 대상인 Token Burn은 기존 기획과 자산이 있는 미완성 프로젝트이므로, 완전한 신규 개발이나 동일 조건의 도구 비교와는 출발점이 다르다.

🕒 시간순 섹션별 상세정리

1. Pstack 소개와 첫 탐색의 목적

• 진행자는 Pstack을 Potato Mode라는 이름과 연결해 소개하고, Cursor GitHub의 플러그인에서 소스를 찾을 수 있다고 보여준다. 제작자 Lauren Tan의 엔지니어링 경험을 스킬로 묶었다는 것이 소개의 중심이다. [00:51]
• 자신도 Pstack과 Grok Bot을 처음 본격적으로 탐색하는 상황이며, 개념 설명 뒤 실제 프로젝트에 적용해 보겠다고 드러낸다. 당시 자신의 구독으로 Grok Bot에 접근할 수 있게 됐다는 경험도 덧붙인다. [02:08]
• 중간에는 자신의 Agent Wikis 서비스와 유료 콘텐츠를 홍보한 뒤 본론으로 돌아온다. [02:48]

2. 적은 코드와 작업별 플레이북

• Pstack은 빠르게 가려면 먼저 문제를 깊이 이해해야 한다는 관점에서, 대량의 코드와 테스트를 무작정 생성하기보다 더 적고 나은 코드를 지향한다고 보여준다. 월 2,400건 이상의 PR 처리 성과는 제작자 측 주장으로 보여준다. [03:26]
• Potato Mode에 자연어로 작업을 전달하면 버그 수정 같은 유형에 맞는 플레이북을 선택한다. 예시 흐름은 재현 증거 확보, 증상 추적, 실패 테스트, 근본 원인의 최소 수정, 실제 결과 검증과 여러 모델의 비판적 리뷰로 계속된다. [04:15]
• 프로토타입 작업에도 별도 플레이북을 적용한다. 사용자가 모든 스킬을 직접 지정하기보다 작업에 맞는 절차를 자동으로 선택하는 구조다. [04:45]

3. 완료를 입증하는 검증 루프

• 진행자는 가장 중요한 요소로 검증을 꼽는다. 에이전트가 코드를 작성한 뒤 앱을 실행하고 영상이나 트레이스를 수집하며, 발견한 문제를 다시 수정하는 과정이다. [05:00]
• create a verification skill은 프로젝트에 맞는 검증 루프를 마련하는 기능으로 묶인다. 사용자의 상시 감시를 줄이려면 에이전트가 자신의 결과를 확인할 수 있어야 한다는 설명이다. [05:16]

4. 에이전트를 감독하며 배우는 방법

• 먼저 에이전트가 문제를 자기 말로 설명하도록 요청해 이해를 확인하고, 사용자의 가정을 먼저 주입하기보다 목표를 분명히 하도록 권한다. [05:39]
• teach를 통해 구현 방식의 이유와 대안의 절충점을 설명받으면, 작업을 맡기면서 설계 판단도 배울 수 있다고 드러낸다. [06:04]
• how는 구현 탐색, why는 연결된 MCP 자료 조회, recall은 과거 대화의 맥락 요약에 활용한다고 보여준다. 이러한 스킬은 진행 방향과 판단 근거를 파악하는 감독 수단이다. [06:46]

5. 프로토타입과 여러 모델의 설계 비교

• 긴 문서 계획에만 의존하기보다 실제 코드로 두세 가지 프로토타입을 만들고 비교하는 접근을 보여준다. arena와 architect는 이러한 대안 탐색에 연결된다. [07:10]
• 문제 이해, 설계 초안, 모델 간 교차 평가와 종합, 구현 순으로 진행하고 잘못된 설계는 폐기한다. 시연 예시에서는 타입을 깔끔하게 유지하고 캐스트를 쓰지 않는 접근이 심사에서 앞섰다고 보여준다. [07:45]

6. 모델 역할 분담과 24개 원칙

• 기본 역할은 Grok이 코드를 작성하고 Opus가 어려운 판단과 글쓰기를 맡는 것으로 보여준다. setup Pstack을 통해 모델 구성을 바꿀 수 있다고 덧붙인다. [08:04]
• 24개 원칙 중 기존 자원 활용, 삭제 선호, 문제를 해결하는 최소 변경을 주요 원칙으로 보여준다. 짧은 원칙들이 각 작업 전에 에이전트에 주어진다는 설명이다. [08:25]
• 데이터 구조를 먼저 올바르게 정하고, 결정 전에 두세 가지 경쟁 프로토타입을 만드는 원칙도 강조한다. [08:44]

7. 실행 증거와 개인화로 요약한 Pstack

• 완료의 기준은 컴파일 성공만으로 끝나지 않는다. 실제 실행 결과, 영상, 트레이스와 읽어 확인한 값처럼 확인 가능한 증거를 요구한다고 정리한다. [08:59]
• 실제 도구, 프로토타입, 여러 모델과 에이전트의 협업을 핵심으로 요약한다. automate me는 과거 대화를 읽고 사용자에게 맞는 모드를 초안으로 만드는 기능으로 보여준다. [09:25]

8. Grok Bot 설치와 Pstack 설정

• 데스크톱 앱에 로그인하며 구독 사용량이 실습 도중 소진될 가능성을 우려한다. 자신이 평소 사용하는 다른 저렴한 모델 경로와 달리 이번에는 Grok 구독을 사용한다고 보여준다. [10:11]
• Grok Bot에 Pstack 플러그인 설치를 요청하고, 설치 결과로 엔지니어링 중심 스킬 58개가 추가됐다고 확인한다. 개별 스킬 사용과 Potato Mode 사용이 모두 가능하다고 드러낸다. [10:46]
• 추론 수준은 medium을 선택하고 모델 관련 설정을 진행한다. Grok Bot이 설정 파일을 작성해 수동 편집 없이 준비를 마친다. [11:09]

9. Token Burn 연결과 인터페이스 관찰

• 기존 기획과 스프라이트가 있는 Token Burn 프로젝트에 Potato Mode를 켜고, 절반 정도 구현된 작업을 이어가도록 요청한다. 연결된 앱 목록에서도 Pstack 설치를 확인한다. [12:13]
• UI는 깔끔하지만 도구 호출과 사용 스킬을 모두 보기 어려워 내부 작업을 얼마나 확인할 수 있을지 의문을 제기한다. Hermes Agent에서는 더 많은 제어가 가능하다는 자신의 경험과 비교한다. [12:56]
• 플러그인과 커넥터는 확인할 수 있지만 모델 선택기를 찾지 못한다. 설정상 Opus도 일부 작업에 쓰도록 했으나 실제 사용 모델을 명확히 알기 어렵다고 드러낸다. [13:50]

10. 토큰 예산으로 푸는 게임 구상

• Token Burn은 플레이어와 로봇 동료가 도구와 스킬을 활용해 문제를 해결하는 플랫폼 퍼즐 게임이다. 에이전트의 도구 사용과 모델별 능력 차이를 게임 요소에 반영하려는 구상이다. [14:23]
• 진행에 따라 로봇을 강화하되, 이동과 도구 사용 등에 해당하는 토큰 예산 안에서 각 스테이지를 해결하도록 설계했다고 보여준다. [14:49]

11. 첫 스테이지의 다단계 계획

• 첫 스테이지 MVP 요청에는 multi-phase plan 플레이북이 선택된다. 이 단계에서는 구현하지 않고 계획을 작성하며, 진행자는 어떤 Pstack 요소를 사용했는지 더 명확히 밝혀 달라고 요청한다. [15:19]
• 계획은 여섯 개의 작은 작업으로 나뉘며, 각각 테스트를 먼저 작성하고 전체 테스트를 통과시킨 상태에서 별도 커밋을 만드는 방식이다. 검증 흐름에는 정의 검증기, 상태, 리플레이, 플레이 화면, 브라우저 테스트와 직접 플레이가 포함된다. [15:57]
• 스테이지 형식과 검증기를 먼저 정하고 단계 및 통과 조건을 타입으로 표현하는 등, 데이터 구조와 검증 가능한 작업 단위에 관한 원칙이 계획에 반영됐다고 보여준다. [16:34]

12. 기존 기획 활용과 기능 접근 제약

• 도메인을 흩어진 조건문보다 구조로 표현하는 원칙과 실제 작동을 입증하는 원칙을 다시 확인한다. 기존 로드맵이 있어 how를 생략했다고 보여준다. [17:25]
• architect와 interrogate도 이번 과정에서 생략됐다고 보여준다. 따라서 앞서 설명한 모든 스킬이 이번 실습에 사용된 것은 아니다. [17:42]
• 클라우드 머신과 하위 에이전트를 사용할 수 없는 이유를 Cursor 플랜 조건과 연결해 보여준다. 자신의 X Premium Plus 계정과 첫 사용 설정에 한계가 있을 수 있음을 인정하고 구현을 시작한다. [18:18]

13. 기능 플레이북으로 상태 구현

• 첫 구현 작업에는 feature 플레이북이 선택된다. 계획 단계와 다른 플레이북이 적용되고, 데이터 구조와 검증 가능한 작업 단위에 관한 원칙을 활용했다고 보고한다. [18:47]
• Potato Mode에 들어간 뒤에는 매번 구체적인 스킬을 호출하지 않아도 모델이 작업에 맞춰 선택한다는 점을 장점으로 꼽는다. 다음 작업은 명령 실행과 동료 위치에 따른 문 열림 등을 다루는 실시간 스테이지 상태다. [19:41]
• 두 번째 작업까지 완료됐다고 보고하며 테스트 우선과 커밋 단위를 확인한다. 기존 체크포인트와 명령 코드를 재사용한 점도 보여준다. [20:19]

14. 풀이 리플레이와 브라우저 화면

• 세 번째 작업은 실제 이동과 점프를 사용하는 리플레이로 스테이지를 풀 수 있음을 입증하는 것이다. 이어 네 번째 작업으로 브라우저에서 조작할 수 있는 장면을 구현한다. [20:45]
• 진행자는 도구 호출을 자세히 볼 수 없는 점을 다시 언급한다. 사용량은 당시 3%로 표시됐으며, 브라우저 장면이 준비되자 직접 테스트로 넘어간다. [21:16]

15. 직접 플레이와 반복 동작 버그

• 방향키 또는 A·D 이동과 스페이스 점프를 시험한다. 화면과 자산은 기초적인 수준이며 UI에는 상당한 개선이 필요하다고 평가한다. [21:56]
• 로봇 동료를 출구로 이동시키는 명령을 실행해 스테이지 완료를 확인한다. 기본 동작은 되지만 게임플레이는 더 다듬어야 한다고 드러낸다. [22:24]
• 이후 캐릭터가 계속 점프하거나 달리는 문제를 발견하고 재현을 시도하도록 한다. 기능이 작동하는 것과 실제 조작 중 결함이 없는 것은 별도로 확인해야 함을 보여준다. [22:43]

16. Grok Bot의 편의성과 통제권 평가

• 진행자는 실제 사용 모델을 알기 어려워 다른 모델만 썼을 때의 결과를 판단할 수 없다고 드러낸다. 이번 코딩 실습이 Grok Bot의 장점을 가장 잘 보여주는 사용 사례인지도 의문을 제기한다. [23:26]
• 플러그인이 오픈소스이므로 다른 코딩 에이전트나 Hermes Agent에서 재시험할 가능성을 언급한다. Grok Bot 자체의 UI, 속도와 사용 편의성은 긍정적으로 평가한다. [24:03]
• 워크플로를 서비스에 집중하면 정책 변경에 영향을 받고 통제권을 잃을 수 있다는 우려를 드러낸다. 최종적인 첫인상은 부드럽고 빠르지만 내부 가시성과 제어가 부족하다는 것이다. [25:01]

17. 도입 전후 비교와 후속 과제

• Hermes Agent에 Token Burn의 도입 전후 작업을 비교하게 했다. 기존에도 여러 에이전트 환경을 사용했고 기준 작업의 커밋 구성이 달라 Pstack의 영향만 분리하거나 커밋 수를 공정하게 비교하기 어렵다고 인정한다. [25:41]
• 비교 결과로 변경 이유를 설명하는 커밋, 선언적인 스테이지 정의와 검증기, 타입 엄격성, 실제 동작 리플레이, 이유를 설명하는 주석을 보여준다. 반복 이동·점프 문제에는 버그 수정 플레이북을 사용해 수정했다고 보고한다. [26:49]
• 다른 에이전트 환경과 architect 등 개별 스킬, 이번에 사용하지 못한 기능을 후속으로 시험하고 싶다고 드러낸다. 경험 있는 시청자에게 조언을 요청하며 영상을 마친다. [27:37]

🧾 결론

• Pstack의 특징은 작업 유형에 맞춰 플레이북·스킬·설계 원칙·검증 절차를 연결하는 데 있다. 실습에서는 계획 단계와 기능 구현 단계에 서로 다른 플레이북이 적용됐다.
• Token Burn 사례에서는 데이터 중심 설계, 검증기, 실제 움직임을 사용하는 리플레이, 변경 이유를 설명하는 커밋 등 구체적인 작업 방식이 관찰됐다. 다만 완성된 게임의 품질이나 장기 유지보수성까지 확인된 것은 아니다.
• 진행자는 다른 에이전트 환경에서 Pstack을 다시 사용하고 architect 같은 개별 스킬도 시험할 의사를 밝혔다. 이번 영상의 결과는 Grok Bot에서 수행한 첫 사용 경험으로 해석하는 것이 적절하다.

📈 투자·시사 포인트

• AI 개발 도구를 평가할 때 생성 속도와 함께 실행 증거, 재현 가능성, 변경 이유의 기록을 확인필요가 있다. 영상에서 강조하는 가치는 검증 가능한 작업 과정이다.
• 도입 비용을 판단할 때 구독료뿐 아니라 모델 선택권, 사용량 제한, 클라우드 기능 접근 조건도 살펴야 한다. 영상에서는 사용량이 3%로 표시됐지만 이를 일반적인 비용 효율로 확대 해석할 근거는 없다.
• 편리한 UI와 자동화는 운영 통제권과 함께 평가해야 한다. 진행자는 모델·도구 호출의 낮은 가시성과 서비스 정책 변경에 따른 워크플로 의존을 주요 우려로 제시했다.
• 오픈소스 플러그인을 다른 에이전트 환경에서 사용할 수 있다는 점은 비교 실험의 여지를 제공한다. 다만 환경을 바꿨을 때 기능과 품질이 얼마나 유지되는지는 후속 검증이 필요하다.

⚠️ 불확실하거나 확인이 필요한 부분

• 월 2,400건 이상의 PR을 처리했다는 수치는 진행자가 제작자 측 성과로 소개한 주장이다. 영상에는 집계 기준이나 독립적인 검증 자료가 제시되지 않는다.
• 초반에는 스킬이 20여 개라고 설명하지만 설치 화면에서는 58개가 추가됐다고 말한다. 버전 차이인지 집계 범위 차이인지는 확인되지 않는다.
• 실제 작업에 어떤 모델이 얼마나 사용됐는지 명확하지 않다. 후반의 모델명과 품질 비교는 진행자의 추정이며, 모델별 실행 기록이나 통제된 비교 실험이 없다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 설치된 Pstack의 스킬 목록과 버전을 기록하고, 영상에서 언급된 플레이북과 검증 스킬이 실제로 제공되는지 확인한다.
• 작은 기존 프로젝트에서 Potato Mode를 실행해 선택한 플레이북, 사용한 원칙, 단계별 산출물을 명시적으로 설명하도록 요청한다.
• 완료 기준에 실제 앱 실행, 재현 가능한 테스트, 영상·트레이스 또는 결과 값 확인을 포함한다.
• 모델 선택·도구 호출·하위 에이전트 실행 기록을 얼마나 확인할 수 있는지 점검하고 구독별 제한을 기록한다.

❓ 열린 질문

• 같은 초기 코드와 작업 요구사항을 사용했을 때 Pstack이 일반적인 에이전트 작업보다 품질과 검증 수준을 얼마나 개선할까?
• 도구 호출과 모델 선택을 더 자세히 볼 수 있는 환경에서는 Potato Mode의 작동 방식과 비용을 얼마나 명확히 평가할 수 있을까?
• 이번에 사용하지 못한 architect, interrogate와 하위 에이전트 기능을 활용하면 결과가 어떻게 달라질까?