월 2,000건 PR을 올리는 방법론, 교본 1부가 북마크 7,112개를 모았습니다

"pstack 완전 가이드 1부(The Complete Guide to pstack Pt. 1)." 그록봇 제작 총괄 로렌 탄(@poteto)이 자기 작업 방식을 통째로 문서화해 공개했습니다. 공유 트윗은 조회 322,335, 북마크 7,112를 기록했어요.

pstack은 그녀가 AI 코딩 에이전트를 부리는 개인 스킬셋입니다. 품질을 지킨 채 월 2,000건 PR을 프로덕션에 올리고, 그록봇 코드베이스를 다듬는 가드너·리팩터 역할까지 이걸로 돌립니다.

목차 흐름만 봐도 설계가 읽힙니다. 물량과 품질을 같이 잡는다는 도입에서 출발해, 검증 → 검증 스킬 만들기 → 재현 가능하게 만들기(CLI) → 클라우드 에이전트 대 워크트리 → 피처 맵 → 실전 사용법 순서로 내려가고, 마지막에 2부를 예고합니다.

교본 전체를 꿰는 단어는 하나입니다. 검증. 첫 소제목부터 "Verification is all you need"예요.

검증이 왜 전부라는 걸까요

교본은 검증이라는 말부터 다시 정의합니다.

"검증이란 에이전트가 자기 일을 스스로 검증할 수 있다는 것. 이제 네가 병목이 되지 않고도 루프를 닫을 수 있으니, 과제에 성공할 때까지 계속 갈 수 있다."

에이전트가 코드를 쓰는 속도는 이미 사람을 넘었습니다. 문제는 언제나 그다음이었어요. 맞게 했는지 사람이 눈으로 확인하는 구간, 거기서 전체 속도가 사람 속도로 주저앉습니다.

검증을 에이전트 손에 쥐여주면 이 구간이 사라집니다. 틀리면 스스로 알아채고, 고치고, 다시 검사합니다. 통과할 때까지 이 루프가 돌아요. 사람은 승인 도장이 아니라 방향 설정으로 물러나요.

월 2,000건이라는 숫자는 이 구조가 만든 결과입니다. 사람이 2,000건을 일일이 눈으로 검사하는 그림은 애초에 성립하지 않거든요. 사람이 검사를 더 빨리 하는 게 아니라, 검사 자체를 에이전트 루프 안으로 밀어 넣는 순서예요.

왜 마크다운 대신 도구를 줄까요

두 번째 축은 도구입니다. 원문 표현이 명확해요.

"우리는 에이전트에게 그냥 마크다운보다 도구를 주는 쪽을 선호한다(we prefer to give agents tools rather than just markdown)."

에이전트가 헤매면 보통 지시문을 늘립니다. 규칙 하나 추가, 예외 설명 하나 추가. 교본은 반대로 갑니다. 설명서를 살찌우는 대신 에이전트 전용 CLI를 만들어 쥐여줘요. 레버를 만들라(Build the Lever)는 이름이 붙은 원칙입니다.

재현성이 이 원칙과 한 몸입니다. 목차에 "재현 가능하게 만들라(Make it Reproducible)"가 따로 한 장으로 잡혀 있어요. 말로 "이렇게 검사해라" 백 줄을 쓰는 대신, 명령 한 번이면 같은 검사가 같은 방식으로 재현됩니다. 마크다운 지시문은 읽을 때마다 해석이 흔들리지만, CLI는 어제도 오늘도 같은 답을 내놓거든요.

검증 스킬 자체도 명령으로 만듭니다. /create-verification-skill로 만들고, /maintain-verification-skill로 매일 손질해요. 만드는 명령과 유지하는 명령을 따로 둔 게 눈에 띕니다. 검증은 한 번 세우고 끝나는 물건이 아니라, 코드가 바뀌는 만큼 매일 따라 움직여야 하는 물건이라는 뜻이니까요. 예제 레포(verification-skill-example)도 같이 공개됐습니다. 글만 읽고 끝나지 않게 따라 만들 실물을 붙여둔 겁니다.

이 대목에서 교본 전체를 통틀어 가장 센 문장이 나옵니다.

"온콜 로테이션을 붙일 가치까지 있다 — 팀 생산성 100~1000배를 여는 열쇠가 그만큼 중요하니까."

검증 스킬을 스크립트가 아니라 서비스처럼, 죽으면 사람을 깨우는 인프라처럼 다루라는 말입니다.

피처 맵은 뭘 기억하는 지도일까요

세 번째 장치는 피처 맵(Feature Map)입니다.

코드 구조가 아니라 사용자 시점에서 그린 기능 지도예요. 교본은 이걸 "구체화된 기억(materialized memory)"이라고 부릅니다.

에이전트는 세션이 끝나면 잊습니다. 매번 코드베이스를 처음부터 뒤지게 두는 대신, 어떤 기능이 어디 있고 사용자에게 어떻게 보이는지를 지도로 박제해두고 꺼내 쓰게 하는 겁니다.

쓰임새도 구체적으로 적혀 있습니다. 기능 개발, 성능 작업, 사용자 리포트 대응. 들어오는 일감마다 피처 맵이 출발점이 됩니다. 사용자 리포트가 들어오면 에이전트는 지도에서 해당 기능을 찾고, 거기 묶인 코드로 바로 내려가고, 고친 다음에는 검증 스킬로 스스로 확인합니다. 앞서 나온 장치들이 여기서 한 줄로 이어져요. 장난기 섞인 부록도 있어요. Dr Eggbot이라는 캐릭터, 커서에서 Opt+Enter로 고정하는 /poteto-mode 커스텀 모드까지 같이 들어 있습니다.

워크트리 열 대 다음은 뭘까요

규모 이야기에서 교본은 현재와 다음을 나눠 말합니다.

지금은 깃 워크트리로 에이전트 열 대 안팎을 병렬로 돌립니다. 로컬 머신 하나에서 소화 가능한 상한이 대략 그 언저리라는 거예요.

다음 편 예고가 더 큽니다. 클라우드 서브에이전트 수백 대 운용. /swarm, /control-app 같은 명령이 이미 목차에 올라 있고, 봇을 클라우드 에이전트 코디네이터로 쓰는 구도까지 걸려 있습니다.

그록봇 코드베이스는 이미 하루 수백 건 PR을 이 체제로 소화합니다. 검증 없이 수백 대를 띄우면 사고가 수백 배로 늘 뿐이니, 순서가 뒤집히지 않게 짜놓은 겁니다. 1부가 기초 체력이고, 2부가 물량전이라는 구성이에요.

남는 생각

저는 온콜 문장이 이 교본의 급소라고 봅니다.

검증 스킬에 온콜을 붙이라는 건, 검증을 프롬프트가 아니라 인프라로 다루라는 말이거든요. 서버가 죽으면 사람을 깨우듯, 검증이 무뎌져도 사람을 깨워라. 에이전트를 몇 대 띄우느냐는 그다음 문제입니다.

북마크 7,112개가 붙은 이유도 여기 있다고 봐요. 에이전트 잘 쓰는 팁은 이미 넘칩니다. 이 글은 팁이 아니라 체제 설계도예요. 사람이 병목에서 빠지는 순간부터, 규모는 루프를 닫아둔 쪽이 가져갑니다.

---

원문·소스

• pstack 완전 가이드 1부 공유 트윗 (@poteto): https://x.com/poteto/status/2094457600259842065
• 검증 스킬 예제 레포: https://github.com/poteto/verification-skill-example
• 로렌 탄 블로그: https://www.no.lol/