AI 코드 리뷰 자동화 — 한 달 PR 2,500개, 사람 리뷰 대신 4가지 장치 (pstack)

기준: 요즘IT 기사(2026년 11월 5일 게시) · cursor/plugins 저장소의 pstack README · shipping 플레이북 · 검증 가이드(2026년 11월 6일 확인) · 저장소 별 15,511 · 라이선스 표시 없음 · 플레이북 23개

한 달 PR 2,500개, 사람 리뷰 0 — 커서 엔지니어 로런 탠이 밝힌 숫자(뒤 PR 목록은 설명용 가상 화면)

AI 에이전트를 쓰기 시작하면 코드는 금방 늘어납니다. 막히는 곳은 리뷰입니다. 사람이 PR을 하나하나 읽는 속도는 그대로인데, 에이전트가 여는 PR은 몇 배로 늘어나기 때문입니다.

커서(Cursor)에서 일하는 엔지니어 로런 탠(poteto)은 이 문제에 꽤 과감한 답을 내놨습니다. 그 답을 쓴 문서가 공개 저장소 pstack에 그대로 올라와 있어서, 우리 팀 저장소에도 바로 붙여 볼 수 있습니다. 이 글은 요즘IT 기사와 pstack 원문 문서를 기준으로 그 방식을 정리합니다.

정말 사람 리뷰 없이 머지했나요?

본인이 그렇게 밝혔습니다. 요즘IT 기사에 따르면, 로런 탠은 2026년 9월 22일 X에 "지난달 PR 2,500개를 프로덕션에 배포한 방법"이라는 38분짜리 영상을 올렸습니다. "PR 2,500개면 리뷰어한테는 지옥 아닌가요?"라는 답글에는 "제 에이전트들이 자기 PR을 직접 머지해요. 사람 리뷰는 없어요."라고 답했습니다.

숫자 차이 — X 게시물은 2,500개, 영상 속 발언은 2,000개

다만 숫자는 한 가지로 정해지지 않습니다. X 게시물에서는 PR 2,500개라고 했지만, 영상 첫 화면과 발언에서는 2,000개라고 했고, 왜 차이가 나는지는 영상에 나오지 않습니다. 영상은 한 달 사이 조회 400만 회를 넘겼다고 보도됐습니다. PR 하나의 평균 변경량, 되돌린 PR 비율, 장애 건수, 들어간 비용은 공개되지 않았습니다. 그래서 이 글은 "얼마나 잘 됐나"보다 "어떻게 하나"에 집중합니다.

리뷰가 하던 일은 어디로 갔나요?

리뷰를 버린 것이 아니라 네 곳으로 나눠 옮겼습니다. 사람 리뷰어 한 명이 하던 일을 쪼개 보면 "정말 작동하나", "누가 통과시키나", "놓친 문제는 없나", "같은 실수가 또 나오지 않나"입니다. pstack은 이 네 가지를 각각 다른 장치에 맡깁니다.

리뷰가 하던 일	pstack에서 맡는 곳	근거 문서
정말 작동하나	PR 전에 검증 스킬로 작동 증거를 남긴다	검증 가이드(06-verify-and-ship)
누가 통과시키나	코드를 쓰지 않은 검증 에이전트가 PASS · PASS+NOTES · FAIL	shipping 플레이북
놓친 문제는 없나	다른 계열 모델 여럿이 같은 변경(diff)을 리뷰	/interrogate
같은 실수 반복	구조 → 타입 · 린트 · CI → 테스트 → 문서 순으로 막기	/correct

아래에서 하나씩 원문과 함께 봅니다.

첫째, '작동한다'는 증거는 어떻게 남기나요?

일을 시작하기 전에 완료 조건부터 적고, 앱을 실제로 띄워서 사용자처럼 눌러 본 결과를 증거로 남깁니다. pstack 검증 가이드의 첫 문장은 "It compiles is not evidence", 즉 "컴파일된다는 증거가 아니다"입니다.

pstack 검증 가이드 — 완료 조건을 첫 프롬프트에 적는다(2026년 11월 6일 원문)

가이드는 첫 프롬프트에 "끝났다는 게 무슨 뜻인지"를 적으라고 합니다. 예시는 "JSON 출력을 추가하되, 기존 텍스트 출력은 한 글자도 바뀌지 않고, JSON은 파싱되며, 둘 다 샘플 프로젝트에서 돌아가야 한다"입니다. 이렇게 쓰면 에이전트는 기분이 아니라 실행해 볼 수 있는 확인 세 개를 갖게 됩니다. 증거 없이 자신 있게 끝났다고 답하면 오히려 경고 신호로 봅니다.

PR 전에 작동 증거 — 앱 띄우기 → 사용자처럼 눌러 보기 → 증거 남기기(스크린샷 · 로그)

앱을 직접 조작할 방법이 없으면 /create-verification-skill로 프로젝트 전용 검증 스킬을 만듭니다. 11월 6일 원문을 보면 이 스킬에는 띄우기(Launch) · 상태 점검(Doctor) · 조작(Drive) · 증거(Evidence) · 정리(Cleanup) 단계가 들어가고, 앱 기능마다 "무엇을 보면 작동한다고 할 수 있는지"를 적은 기능 지도가 붙습니다. 한 번 만들어 두면 "앱에서 확인해"가 어떤 에이전트든 실행할 수 있는 한 단계가 됩니다.

둘째, 머지 판정은 누가 내리나요?

코드를 쓰지 않은 검증 에이전트가 내립니다. shipping 플레이북은 PR마다 검증 에이전트를 하나씩 붙이고, 이 에이전트가 사용자처럼 변경을 실행해 본 뒤 PR에 PASS, PASS+NOTES, FAIL 중 하나를 남기게 합니다.

shipping 플레이북 — 코드를 쓰지 않은 에이전트의 판정만 인정, 초록색 CI와 봇 승인은 판정이 아니다(2026년 11월 6일 원문)

이유도 원문에 적혀 있습니다. 코드를 쓴 에이전트는 자기가 만들려던 것을 확인하기 때문에, 그 판정은 세지 않습니다. 같은 문단에는 "초록색 CI와 승인한 봇 리뷰는 판정이 아니다"라는 문장도 있습니다. 둘 다 사용자처럼 변경을 실행해 보지 않기 때문입니다. 머지는 가장 아래 PR부터 차례로 하고, 판정을 받지 못한 PR이 나오면 그 위 PR은 기다립니다.

셋째·넷째, 놓친 문제와 반복되는 실수는 어떻게 막나요?

놓친 문제는 여러 모델에게 같이 보게 해서, 반복되는 실수는 규칙으로 만들어서 막습니다.

/interrogate는 같은 변경(diff)과 의도, 평가 기준을 서로 다른 계열의 모델 여러 개에 보냅니다. 요즘IT 기사는 모델마다 놓치는 곳이 다르니 두 모델이 따로 같은 문제를 짚으면 가장 믿을 만한 신호로 본다고 설명합니다. README도 이 스킬을 "다른 모델들이 변경을 깨뜨려 보게 하고, 실행으로 증명된 지적만 남긴다"고 소개합니다.

두 번 나온 실수 막는 순서 — 구조 → 타입 · 린트 · CI → 테스트 → 문서는 마지막

/correct는 에이전트가 같은 실수를 되풀이할 때 씁니다. 커밋 · 되돌림 · 리뷰 코멘트를 읽고 실수를 묶는데, 두 번 나오면 하나의 유형으로 칩니다. 그리고 가장 높은 단계에서 막습니다.

/correct 원문 — 구조로 없애고, 타입 · 린트 · CI로 강제하고, 테스트하고, 문서는 마지막(2026년 11월 6일 원문)

구조로 없앤다: 상태마다 주인을 하나로, 할 일마다 정해진 방법을 하나로 둡니다.
타입으로 강제한다: 그래도 잘못된 코드가 컴파일되면 린트나 CI 검사를 더하고, 에러 메시지에 대신 쓸 파일 · 타입 · 함수를 적습니다.
동작을 테스트한다: 내부만 바뀌어도 깨지거나, 동작이 깨져도 통과하는 테스트는 고치거나 지웁니다.
문서는 마지막: 판단이 필요한 일만 문서나 에이전트 규칙으로 남깁니다. 에이전트가 문서를 건너뛰어도 아무것도 실패하지 않기 때문입니다.

리뷰에서 같은 말을 세 번째 하고 있다면, 그 말은 코멘트가 아니라 린트나 CI 규칙이 되어야 한다는 뜻으로 읽으면 됩니다.

설치는 얼마나 걸리나요?

명령 한두 줄이면 됩니다. 11월 6일 README 기준 설치 방법은 아래와 같습니다.

pstack README의 설치 부분 — Cursor 한 줄, Claude Code 두 줄(2026년 11월 6일 원문)

Cursor: /add-plugin pstack
Claude Code: /plugin marketplace add cursor/plugins 다음에 /plugin install pstack@cursor-plugins
시작: /setup-pstack으로 쓸 모델과 추론 예산을 고르고, 일을 시킬 때 /poteto-mode를 붙입니다. /poteto-mode는 요청을 읽고 플레이북 23개 가운데 맞는 것을 골라 나머지 스킬을 알아서 부릅니다.

Claude Code에서는 명령 앞에 이름이 붙어 /pstack:poteto-mode처럼 씁니다. 버그봇이나 자동화처럼 Cursor에만 있는 기능이 필요한 단계는 한 줄 메모를 남기고 건너뜁니다. 서드파티 마켓플레이스는 자동 업데이트가 꺼져 있어서, 새 버전을 받으려면 /plugin 메뉴에서 켜거나 claude plugin update pstack@cursor-plugins를 직접 실행합니다.

사람은 무엇을 맡고, 무엇을 조심해야 하나요?

사람 리뷰가 사라지는 건 아닙니다. 사람은 검증 기준을 정하고, 보안 · 개인정보 · 데이터처럼 판단이 필요한 일을 맡습니다.

초록색 CI는 판정이 아니다 — 보안 · 데이터 문제는 사람에게

요즘IT 기사에 따르면 pstack에는 버그봇 코멘트를 다루는 규칙이 따로 있습니다. 고치기(fix) · 기각하기(dismiss) · 물어보기(ask) 중 하나로 나누는데, 보안이나 개인정보, 데이터에 관한 지적과 애매한 지적은 사람에게 묻습니다. 사소한 코드 품질 코멘트를 넘기는 비용은 작지만, 진짜 데이터 버그나 보안 버그를 넘기는 비용은 크기 때문입니다. "이제 코드 리뷰는 필요 없다"가 아니라 "사람 리뷰어가 매번 읽던 일을 장치로 옮기고, 사람은 기준과 위험한 판단에 집중한다"에 가깝습니다.

쓰기 전에 확인할 점도 표로 모았습니다.

항목	내용(2026년 11월 6일 확인)
라이선스	cursor/plugins 저장소에 라이선스 표시가 없습니다. "오픈소스 라이선스"가 아니라 "공개 저장소"로 보고, 회사에서 고쳐 쓰거나 배포하기 전에는 확인이 필요합니다
숫자	PR 2,500개(X 게시물)와 2,000개(영상)는 본인 발표이고, 조회 400만 회는 보도 1건입니다
공개 안 된 것	되돌린 PR 비율 · 장애 건수 · 비용은 나오지 않았습니다
사람 몫	보안 · 개인정보 · 데이터 지적, 애매한 지적은 사람이 판단합니다

한 번에 정리

완료 조건부터: 첫 프롬프트에 "끝났다"의 뜻을 실행해 볼 수 있는 확인으로 적습니다. "컴파일된다"는 증거가 아닙니다.
앱마다 검증 스킬 하나: 띄우기 → 상태 점검 → 사용자처럼 조작 → 증거(스크린샷 · 로그) → 정리.
판정은 다른 에이전트가: 코드를 쓴 쪽이 아니라 검증 에이전트가 PASS · PASS+NOTES · FAIL. 초록색 CI와 봇 승인은 판정이 아닙니다.
여러 모델 리뷰: 다른 계열 모델 둘이 같은 문제를 짚으면 가장 믿을 신호입니다.
반복 실수는 규칙으로: 구조 → 타입 · 린트 · CI → 테스트 → 문서 순서.
바로 써 보기: Cursor /add-plugin pstack, Claude Code는 마켓플레이스 두 줄.

다음 글에서는 AI가 쓴 테스트를 얼마나 믿어도 되는지 살펴봅니다.

출처

요즘IT, '커서 엔지니어가 한 달 PR 2,500개 머지한 방법(내 저장소에 붙여 보니)'(2026년 11월 5일 게시): https://yozm.wishket.com/magazine/detail/4027/
pstack README: https://github.com/cursor/plugins/tree/main/pstack
pstack shipping 플레이북: https://github.com/cursor/plugins/blob/main/pstack/skills/poteto-mode/playbooks/shipping.md
pstack 검증 가이드: https://github.com/cursor/plugins/blob/main/pstack/docs/guide/06-verify-and-ship.md
pstack /correct: https://github.com/cursor/plugins/blob/main/pstack/skills/correct/SKILL.md
첫 이미지 뒤의 PR 목록은 설명용으로 새로 만든 가상 화면입니다.
영상으로 보기: AItoZ 유튜브 쇼츠 'AI 코드 리뷰 자동화 — 한 달 PR 2,500개, 사람 리뷰 대신 4가지 장치' — https://youtube.com/shorts/QnbwR116Ins