커서 엔지니어, 대량 PR 검증 흐름 공개

커서 엔지니어 로런 탠(Lauren Tan)은 2026년 9월 22일 X에 올린 영상에서 지난달 한 달 동안 PR(코드 변경을 병합해 달라는 요청) 2,000개를 프로덕션에 보냈다고 말했습니다. X 게시물 제목에는 2,500개라고 적혀 있지만, 영상 첫 화면과 발언은 2,000개로 서로 다릅니다. 38분짜리 영상은 한 달 사이 조회 수 400만 회를 넘겼고, 탠은 에이전트가 자기 PR을 직접 머지해 사람 리뷰는 없다고 답했습니다. 다만 PR 평균 변경량, 되돌린 비율, 장애 건수와 비용은 공개되지 않았으며, 모든 PR에 사람 손이 전혀 닿지 않았는지도 확인할 수 없습니다.

탠이 공개한 pstack 저장소는 문서 가이드와 스킬, 상황별 플레이북으로 작업 흐름을 정리합니다. 글쓴이는 영상과 저장소를 살펴보고 자신의 에이전트 아카데미 저장소에도 비슷한 장치를 적용했습니다. 핵심은 리뷰를 없애는 대신 리뷰가 하던 일을 PR 전 검증, 작성자와 분리된 판정 에이전트, 코드 구조와 자동 검사로 옮기는 방식입니다.

탠은 에이전트를 늘리기 전에 결과를 믿을 수 있는 검증 수단을 마련해야 한다고 말했습니다. 결과를 신뢰하지 못하면 사람이 다시 확인해야 하며, 감독이 필요한 상태에서 에이전트만 늘리면 품질이 낮은 PR과 회귀가 함께 늘어난다는 설명입니다. 그는 성능 문제를 추적하던 시기를 돌아보며 “병목은 나 자신이다”라고 말했습니다. 스타일 가이드만 두면 규칙을 기억해 리뷰에서 지적하는 일이 사람에게 남습니다. 반복 지적은 사람의 기억에 맡기지 말고 코드나 자동 검사에 반영해야 한다고 탠은 설명했습니다.

탠이 제시한 교정 내용의 적용 층은 코드베이스, 린트·컴파일러·CI 같은 정적 분석, 규칙과 버그봇, 스킬, 스타일 가이드 등 다섯 가지입니다. 아래 층일수록 강제력이 약해져, 스타일 가이드는 사람이 리뷰에서 지적해야 지켜집니다. pstack 검증 가이드는 작업 시작 전에 완료 조건을 정하고 앱별 검증 스킬을 만들도록 안내합니다. 스킬은 앱 실행, 상태 점검, 사용자처럼 조작, 증거 기록과 정리 절차를 담습니다. 영상에서 기능 지도는 기능 위치와 접근 방법을 제공하고, CLI(명령줄에서 앱을 조작하는 도구)는 에이전트가 앱을 실행하고 조작하게 합니다. 따라서 PR이 열리기 전에 작동 여부를 보여 줄 증거를 준비하는 흐름입니다.

배포 플레이북은 PR마다 코드를 작성하지 않은 검증 에이전트를 붙여 변경을 사용자처럼 실행하게 하고, PASS·PASS+NOTES·FAIL 중 하나를 남기도록 합니다. 작성자는 자신이 만들려던 것을 확인할 뿐이라는 이유로 작성자 에이전트의 판정은 인정하지 않습니다. 초록색 CI나 승인한 봇 리뷰도 사용자가 실행해 본 결과가 아니라는 점에서 판정으로 보지 않습니다. 머지는 가장 아래 PR부터 진행하며, 검증되지 않은 PR이 있으면 그 위 PR은 기다립니다. 리베이스로 커밋이 바뀌면 git patch-id를 비교해 기존 판정이 새 코드에도 유효한지 확인합니다.

pstack의 interrogate 스킬은 같은 변경 내용과 의도, 평가 기준을 서로 다른 계열의 모델에 보내 리뷰를 받습니다. 두 모델이 독립적으로 같은 문제를 지적하면 신뢰할 신호로 보고, 결과를 바로 고치기, 검토하기, 기록만 하기, 기각하기로 분류합니다. 기각 이유를 적으며 어떤 지적도 자동 반영하지 않습니다. 버그봇 코멘트는 고치기·기각하기·사람에게 묻기로 나눕니다. 보안, 개인정보, 데이터 관련 지적이나 모호한 지적은 사람에게 묻도록 했습니다. 사소한 코드 품질 지적을 넘기는 비용보다 실제 데이터·보안 버그를 놓치는 비용이 크다는 이유입니다.

탠은 에이전트가 주변 주석을 근거로 문제를 고치지 않고 임시방편을 정당화하는 일이 코드베이스에서 반복됐다고 말했습니다. 우회 코드가 여러 에이전트에 복사되면 며칠 만에 사실상의 표준이 될 수 있다고 설명했습니다. 그는 그록 봇 코드베이스에 에이전트용 프레임워크 듄을 만들고 주석을 금지했으며, 잘못된 임포트, 정해진 계약을 거치지 않은 RPC 직접 호출, 파일 크기 증가를 리뷰 전 린트와 빌드에서 잡도록 했습니다. 주석 금지는 그 팀의 선택으로 제시됐습니다.

pstack의 correct 스킬은 최근 커밋, 되돌린 커밋과 리뷰 코멘트를 읽어 두 번 이상 나온 실수를 묶고, 가능한 가장 높은 층에서 막도록 합니다. 먼저 코드 구조로 실수를 불가능하게 하고, 이어 타입·린트·CI, 테스트 순으로 검사하며 문서는 마지막에 씁니다. 새 검사는 과거 실제 실수에서 실패하는지 확인해야 합니다. 탠은 반복해서 같은 코멘트를 쓰는 대신 이를 규칙으로 옮기고, 나쁜 패턴을 일찍 찾아내는 ‘정원사’ 역할이 필요하다고 말했습니다.

사람의 책임은 남습니다. 탠은 최종 결과에 대한 책임은 사람에게 있다고 했으며, pstack은 보안과 데이터처럼 되돌리기 어려운 판단을 사람에게 묻습니다. 린트 예외에는 이유와 만료일, 사람 승인을 남깁니다. show-me-your-work 스킬은 에이전트의 결정 근거를 표로 기록해 사람이나 다른 모델이 나중에 확인하게 합니다. 이에 따라 사람은 모든 코드를 읽기보다 검증 기준을 정하고 반복 실수를 구조로 바꾸며 최종 결과를 책임지는 역할을 맡습니다.

글쓴이의 저장소에서는 커밋 훅이 메시지 형식과 결정 기록 번호를 확인하고, 푸시 직전 다른 훅이 테스트와 빌드를 실행하며 main 브랜치로 직접 푸시하는 것을 거부합니다. PR이 열리면 클라우드 빌드가 미리보기를 만들고, 별도 서버의 에이전트가 읽기 전용으로 변경 내용을 살펴 원래 목적과 무관한 변경을 댓글로 알립니다. 빌드가 깨지면 또 다른 에이전트가 원인을 고쳐 PR 브랜치에 다시 올리며, 머지는 글쓴이가 직접 합니다.

해커톤 과제 평가 기능을 고치는 PR에서는 빌드와 테스트가 통과했지만, 변경 검토 에이전트가 지각 제출 판정만 기록된 결정 기록과 달리 순위 정렬 코드도 바뀌었다고 알렸습니다. 글쓴이가 확인하자 코드를 작성한 에이전트가 주변 코드를 정리하며 순위 변경을 포함한 것이었습니다. 글쓴이는 해당 변경을 별도 PR로 분리해 재확인했고, 비슷한 일이 한 번 더 생긴 뒤 결정 기록과 변경 내용이 일치하는지 검사하는 규칙 일부를 스크립트로 옮겼습니다. 밤사이 깨진 빌드에 아침이면 수정 커밋이 붙는 날이 많아졌고, 리뷰는 결정 기록과 에이전트 댓글을 확인해 머지 여부를 판단하는 일로 바뀌었습니다.

글쓴이는 혼자 운영하는 작은 저장소에서 변경 검토 에이전트가 경고만 하고 머지를 막지는 않으며, 문제가 없는 변경에도 경고해 재확인이 필요한 경우가 있다고 밝혔습니다. 탠은 그록 봇 코드베이스에 많은 시간을 들였다고 했고, 검증 스킬과 기능 지도, 린트 규칙, 프레임워크를 마련한 뒤 에이전트에 더 많은 자유를 줬습니다. 커서 내부에서는 클라우드 에이전트, 오토메이션, 버그봇을 자유롭게 쓸 수 있지만 비용, 장애율, 되돌린 PR 비율과 보안 리뷰·권한 분리 방식은 공개되지 않았습니다. 따라서 PR 수만으로 생산성이 몇 배 늘었다고 계산할 수 없다고 글은 짚었습니다.

커서 엔지니어 로런 탠(Lauren Tan)은 2026년 9월 22일 X에 올린 영상에서 지난달 한 달 동안 PR(코드 변경을 병합해 달라는 요청) 2,000개를 프로덕션에 보냈다고 말했습니다. X 게시물 제목에는 2,500개라고 적혀 있지만, 영상 첫 화면과 발언은 2,000개로 서로 다릅니다. 38분짜리 영상은 한 달 사이 조회 수 400만 회를 넘겼고, 탠은 에이전트가 자기 PR을 직접 머지해 사람 리뷰는 없다고 답했습니다. 다만 PR 평균 변경량, 되돌린 비율, 장애 건수와 비용은 공개되지 않았으며, 모든 PR에 사람 손이 전혀 닿지 않았는지도 확인할 수 없습니다.

탠이 공개한 pstack 저장소는 문서 가이드와 스킬, 상황별 플레이북으로 작업 흐름을 정리합니다. 글쓴이는 영상과 저장소를 살펴보고 자신의 에이전트 아카데미 저장소에도 비슷한 장치를 적용했습니다. 핵심은 리뷰를 없애는 대신 리뷰가 하던 일을 PR 전 검증, 작성자와 분리된 판정 에이전트, 코드 구조와 자동 검사로 옮기는 방식입니다.

탠은 에이전트를 늘리기 전에 결과를 믿을 수 있는 검증 수단을 마련해야 한다고 말했습니다. 결과를 신뢰하지 못하면 사람이 다시 확인해야 하며, 감독이 필요한 상태에서 에이전트만 늘리면 품질이 낮은 PR과 회귀가 함께 늘어난다는 설명입니다. 그는 성능 문제를 추적하던 시기를 돌아보며 “병목은 나 자신이다”라고 말했습니다. 스타일 가이드만 두면 규칙을 기억해 리뷰에서 지적하는 일이 사람에게 남습니다. 반복 지적은 사람의 기억에 맡기지 말고 코드나 자동 검사에 반영해야 한다고 탠은 설명했습니다.

탠이 제시한 교정 내용의 적용 층은 코드베이스, 린트·컴파일러·CI 같은 정적 분석, 규칙과 버그봇, 스킬, 스타일 가이드 등 다섯 가지입니다. 아래 층일수록 강제력이 약해져, 스타일 가이드는 사람이 리뷰에서 지적해야 지켜집니다. pstack 검증 가이드는 작업 시작 전에 완료 조건을 정하고 앱별 검증 스킬을 만들도록 안내합니다. 스킬은 앱 실행, 상태 점검, 사용자처럼 조작, 증거 기록과 정리 절차를 담습니다. 영상에서 기능 지도는 기능 위치와 접근 방법을 제공하고, CLI(명령줄에서 앱을 조작하는 도구)는 에이전트가 앱을 실행하고 조작하게 합니다. 따라서 PR이 열리기 전에 작동 여부를 보여 줄 증거를 준비하는 흐름입니다.

배포 플레이북은 PR마다 코드를 작성하지 않은 검증 에이전트를 붙여 변경을 사용자처럼 실행하게 하고, PASS·PASS+NOTES·FAIL 중 하나를 남기도록 합니다. 작성자는 자신이 만들려던 것을 확인할 뿐이라는 이유로 작성자 에이전트의 판정은 인정하지 않습니다. 초록색 CI나 승인한 봇 리뷰도 사용자가 실행해 본 결과가 아니라는 점에서 판정으로 보지 않습니다. 머지는 가장 아래 PR부터 진행하며, 검증되지 않은 PR이 있으면 그 위 PR은 기다립니다. 리베이스로 커밋이 바뀌면 git patch-id를 비교해 기존 판정이 새 코드에도 유효한지 확인합니다.

pstack의 interrogate 스킬은 같은 변경 내용과 의도, 평가 기준을 서로 다른 계열의 모델에 보내 리뷰를 받습니다. 두 모델이 독립적으로 같은 문제를 지적하면 신뢰할 신호로 보고, 결과를 바로 고치기, 검토하기, 기록만 하기, 기각하기로 분류합니다. 기각 이유를 적으며 어떤 지적도 자동 반영하지 않습니다. 버그봇 코멘트는 고치기·기각하기·사람에게 묻기로 나눕니다. 보안, 개인정보, 데이터 관련 지적이나 모호한 지적은 사람에게 묻도록 했습니다. 사소한 코드 품질 지적을 넘기는 비용보다 실제 데이터·보안 버그를 놓치는 비용이 크다는 이유입니다.

탠은 에이전트가 주변 주석을 근거로 문제를 고치지 않고 임시방편을 정당화하는 일이 코드베이스에서 반복됐다고 말했습니다. 우회 코드가 여러 에이전트에 복사되면 며칠 만에 사실상의 표준이 될 수 있다고 설명했습니다. 그는 그록 봇 코드베이스에 에이전트용 프레임워크 듄을 만들고 주석을 금지했으며, 잘못된 임포트, 정해진 계약을 거치지 않은 RPC 직접 호출, 파일 크기 증가를 리뷰 전 린트와 빌드에서 잡도록 했습니다. 주석 금지는 그 팀의 선택으로 제시됐습니다.

pstack의 correct 스킬은 최근 커밋, 되돌린 커밋과 리뷰 코멘트를 읽어 두 번 이상 나온 실수를 묶고, 가능한 가장 높은 층에서 막도록 합니다. 먼저 코드 구조로 실수를 불가능하게 하고, 이어 타입·린트·CI, 테스트 순으로 검사하며 문서는 마지막에 씁니다. 새 검사는 과거 실제 실수에서 실패하는지 확인해야 합니다. 탠은 반복해서 같은 코멘트를 쓰는 대신 이를 규칙으로 옮기고, 나쁜 패턴을 일찍 찾아내는 ‘정원사’ 역할이 필요하다고 말했습니다.

사람의 책임은 남습니다. 탠은 최종 결과에 대한 책임은 사람에게 있다고 했으며, pstack은 보안과 데이터처럼 되돌리기 어려운 판단을 사람에게 묻습니다. 린트 예외에는 이유와 만료일, 사람 승인을 남깁니다. show-me-your-work 스킬은 에이전트의 결정 근거를 표로 기록해 사람이나 다른 모델이 나중에 확인하게 합니다. 이에 따라 사람은 모든 코드를 읽기보다 검증 기준을 정하고 반복 실수를 구조로 바꾸며 최종 결과를 책임지는 역할을 맡습니다.

글쓴이의 저장소에서는 커밋 훅이 메시지 형식과 결정 기록 번호를 확인하고, 푸시 직전 다른 훅이 테스트와 빌드를 실행하며 main 브랜치로 직접 푸시하는 것을 거부합니다. PR이 열리면 클라우드 빌드가 미리보기를 만들고, 별도 서버의 에이전트가 읽기 전용으로 변경 내용을 살펴 원래 목적과 무관한 변경을 댓글로 알립니다. 빌드가 깨지면 또 다른 에이전트가 원인을 고쳐 PR 브랜치에 다시 올리며, 머지는 글쓴이가 직접 합니다.

해커톤 과제 평가 기능을 고치는 PR에서는 빌드와 테스트가 통과했지만, 변경 검토 에이전트가 지각 제출 판정만 기록된 결정 기록과 달리 순위 정렬 코드도 바뀌었다고 알렸습니다. 글쓴이가 확인하자 코드를 작성한 에이전트가 주변 코드를 정리하며 순위 변경을 포함한 것이었습니다. 글쓴이는 해당 변경을 별도 PR로 분리해 재확인했고, 비슷한 일이 한 번 더 생긴 뒤 결정 기록과 변경 내용이 일치하는지 검사하는 규칙 일부를 스크립트로 옮겼습니다. 밤사이 깨진 빌드에 아침이면 수정 커밋이 붙는 날이 많아졌고, 리뷰는 결정 기록과 에이전트 댓글을 확인해 머지 여부를 판단하는 일로 바뀌었습니다.

글쓴이는 혼자 운영하는 작은 저장소에서 변경 검토 에이전트가 경고만 하고 머지를 막지는 않으며, 문제가 없는 변경에도 경고해 재확인이 필요한 경우가 있다고 밝혔습니다. 탠은 그록 봇 코드베이스에 많은 시간을 들였다고 했고, 검증 스킬과 기능 지도, 린트 규칙, 프레임워크를 마련한 뒤 에이전트에 더 많은 자유를 줬습니다. 커서 내부에서는 클라우드 에이전트, 오토메이션, 버그봇을 자유롭게 쓸 수 있지만 비용, 장애율, 되돌린 PR 비율과 보안 리뷰·권한 분리 방식은 공개되지 않았습니다. 따라서 PR 수만으로 생산성이 몇 배 늘었다고 계산할 수 없다고 글은 짚었습니다.