커서 엔지니어가 한 달 PR 2,500개 머지한 방법(내 저장소에 붙여 보니)

2026년 9월 22일,X에 영상 하나가 올라왔습니다. “지난달 PR 2,500개를 프로덕션에 배포한 방법”이라는 제목이었죠. 글쓴이는 커서에서 일하는 로런 탠이었습니다. 영상 길이는 38분이었고, 한 달 사이 조회 수 400만 회를 넘겼습니다.

그런데 영상보다 답글 하나에 먼저 눈길이 갔습니다. 한 사용자가 “PR 2,500개면 리뷰어한테는 지옥 아닌가요?”라고 물었고, 로런 탠은 “제 에이전트들이 자기 PR을 직접 머지해요. 사람 리뷰는 없어요.”라고 짧게 답했습니다.

이 답글을 보고 제 작업 화면이 먼저 떠올랐습니다. 저는 요즘 기업 교육 서비스인 에이전트 아카데미의 강의실과 과제 평가 시스템을 에이전트와 함께 만들고 있습니다. 해커톤 과제 평가 기능을 붙이던 주에는 열흘 남짓한 사이에 PR이 서른 개 가까이 쌓였죠. 모두 제가 맡긴 작업인데도 diff를 한 줄씩 읽고 머지하는 일이 가장 늦게 끝났습니다. 다 읽자니 다음 작업이 밀리고, 건너뛰자니 불안했습니다. 혼자 하는 프로젝트도 이런데, 한 달에 PR이 2,500개라면 어떤 모습일지 쉽게 그려지지 않았습니다.

처음에는 과장이거나 위험한 주장이라고 생각했습니다. 그런데 영상을 끝까지 보고 그가 공개한 저장소를 한 줄씩 읽고 나니 생각이 조금 바뀌었습니다. 그는 리뷰를 버린 것이 아니라, 리뷰가 하던 일을 쪼개서 다른 자리로 옮겨 두었습니다. 이 글은 그 자리가 어디인지 따라가 본 기록입니다. 끝에는 제 저장소에 비슷한 장치를 붙여 본 경험도 덧붙였습니다.

사실 그가 올린 X 게시물에서는 PR 2,500개라고 했지만, 영상 첫 화면과 발언에서는 2,000개라고 했습니다. 둘중 어느 쪽이 맞는지, 왜 차이가 있는지는 영상에 나오지 않았죠. 또 PR 하나의 평균 변경량, 되돌린 PR의 비율, 장애 건수, 들어간 비용 등 공개되지 않은 내용도 많습니다. 모든 PR에 사람 손이 한 번도 닿지 않았는지도 확인할 수 없습니다. 다만 그 진위를 꼼꼼히 따지기보다 이런 작업량을 가능하게 한 구조 자체를 살펴보는 것은 의미 있다고 생각했고, 이 글에서도 그 부분에 집중했습니다.

미리 요점만 콕 집어보면?

• 커서(Cursor)의 로런 탠(Lauren Tan, @poteto)은 한 달에 풀 리퀘스트(Pull Request, PR) 2,500개를 프로덕션에 보냈다고 밝혔습니다. 사람 리뷰는 없었다고 답했죠.
• 그렇다고 리뷰가 사라진 것은 아닙니다. 리뷰가 하던 일이 PR을 열기 전의 증거, 작성자가 아닌 검증 에이전트, 코드 구조와 린트(lint)로 나뉘어 옮겨 갔습니다.
• 그가 공개한 pstack 저장소에는 이 흐름이 문서와 스킬(skill)로 정리되어 있습니다. 이 글은 영상 38분과 pstack 저장소를 함께 읽고, 그 방식을 제 저장소에 붙여 본 기록입니다. 에이전트 덕분에 PR은 늘었는데 리뷰가 따라가지 못하는 팀이라면, 리뷰가 하던 일을 어디로 옮길 수 있을지 힌트를 얻을 수 있습니다.

에이전트를 늘리기 전 필요한 것

코드 리뷰 이야기를 하기 전, 로런 탠은 속도보다 신뢰 이야기부터 꺼냈습니다. 에이전트를 아무리 많이 띄워도 그 결과를 믿지 못하면 사람이 다시 하나하나 확인해야 하니까요. 그는 커서의 성능 문제를 직접 추적하던 시기를 떠올리며 “병목은 나 자신이다(I am the bottleneck)”라고 말했습니다.

그래서 그는 에이전트를 병렬로 늘리기 전에, 에이전트가 자기 작업을 스스로 확인할 수단부터 만들었습니다. 감독이 필요한 상태에서 에이전트 수만 늘리면 품질이 낮은 PR과 회귀(regression)가 같이 늘어난다는 이유였습니다.

사람이 모든 줄을 읽는 코드 리뷰는 왜 무너질까

코드 리뷰에 관한 그의 발언은 영상 18분 무렵에 나옵니다. 팀의 규칙을 스타일 가이드에만 적어 두면, 그 규칙을 지키게 하는 방법은 사람이 리뷰에서 지적하는 것뿐입니다. 리뷰어는 바뀐 모든 줄을 보고, 규칙을 기억하고, 잊지 않고 코멘트를 남겨야 하죠. 그는 “지금처럼 PR이 들어오는 속도라면 그 일은 불가능해진다”고 말했습니다.

여기서 눈여겨볼 대목이 있습니다. 그는 사람 리뷰를 쓸모없다고 하지 않았습니다. 사람 리뷰는 “무엇이 빠졌는지 찾는 좋은 출발점”이라고 했습니다. 리뷰에서 같은 지적이 반복된다면, 그 지적은 사람의 기억이 아니라 코드나 자동 검사에 들어가야 한다는 뜻입니다.

슬라이드에는 에이전트를 교정할 때마다 그 내용을 넣을 곳이 다섯 개 적혀 있습니다. 코드베이스(codebase), 린트·컴파일러·CI 같은 정적 분석, 규칙(rules)과 버그봇(Bugbot), 스킬, 스타일 가이드(style guide) 순입니다. 아래로 갈수록 강제력이 약해집니다. 맨 아래 스타일 가이드는 사람이 리뷰에서 지적해야만 지켜지는 층입니다.

그렇다면 리뷰가 하던 일은 구체적으로 어디로 갔을까요. pstack 저장소를 열어 보면 그 답이 단계별로 적혀 있습니다.

PR 열기 전: 검증 스킬로 작동 증거부터 남긴다

pstack은 로런 탠이 커서의 공개 플러그인 저장소(cursor/plugins)에 올린 작업 방식 묶음입니다. 문서 가이드와 스킬, 상황별 플레이북(playbook)으로 이뤄져 있습니다. 검증 가이드에는 “‘컴파일된다’는 증거가 아니다”라는 문장이 맨 앞에 나옵니다.

가이드에 따르면 작업을 시작하기 전에 완료 조건부터 정하고, 앱마다 검증 스킬을 하나씩 만들어 둡니다. 이 스킬은 앱을 띄우고, 상태를 점검하고, 사용자처럼 조작하고, 증거를 남기고, 정리하는 절차를 담습니다. 영상에서는 이것을 기능 지도(feature map)와 CLI의 조합으로 설명합니다. 기능 지도는 어떤 기능이 어디에 있고 어떻게 들어가는지를 적은 문서입니다. 명령줄 인터페이스(CLI)는 에이전트가 앱을 직접 실행하고 조작하는 도구입니다. 화면에는 “기능 지도는 맥락을 주고, CLI는 조작 수단을 준다”는 문장이 적혀 있었습니다.

사람 리뷰어가 PR을 열고 가장 먼저 묻는 질문은 보통 “이거 돌려 봤어요?”입니다. pstack에서는 PR이 열리기 전에 에이전트가 이 질문의 답을 증거로 준비해 둡니다.

머지 판정: 코드를 쓰지 않은 검증 에이전트가 PASS·FAIL을 내린다

배포 절차를 담은 shipping 플레이북에서 제가 가장 오래 들여다본 규칙은 누가 판정하느냐였습니다. PR마다 검증 에이전트를 하나씩 붙이고, 이 에이전트가 사용자처럼 변경을 실행해 본 뒤 PASS, PASS+NOTES, FAIL 중 하나를 PR에 남깁니다. 그리고 코드를 쓰지 않은 에이전트의 판정만 인정합니다. 작성자는 자기가 만들려고 했던 것을 확인할 뿐이라는 이유입니다.

같은 문서에는 이런 문장도 있습니다. “초록색 CI와 승인한 봇 리뷰는 판정이 아니다.” 둘 다 사용자처럼 변경을 실행해 보지 않기 때문입니다. 머지는 가장 아래 PR부터 차례로 하고, 검증받지 않은 PR이 나오면 그 위는 기다립니다. 리베이스(rebase)로 커밋(commit)이 바뀌면 git patch-id를 비교해서 이전 판정이 지금 코드에도 유효한지 다시 확인합니다.

많은 개발팀이 쓰는 ‘작성자가 아닌 사람이 승인해야 머지(merge)할 수 있다’는 규칙과 닮았습니다. 다른 점은 승인자가 변경 내용(diff)을 읽는 대신 직접 실행해 본다는 것입니다.

리뷰 코멘트: 여러 모델과 버그봇의 지적을 걸러 읽는다

리뷰 코멘트가 많다고 리뷰가 잘된 것은 아닙니다. pstack의 interrogate 스킬은 같은 diff와 의도, 평가 기준을 서로 다른 계열의 모델 여러 개에 보냅니다. 모델마다 놓치는 곳이 다르니, 두 모델이 따로 같은 문제를 짚으면 가장 믿을 만한 신호로 봅니다. 결과는 바로 고치기(Act on), 검토하기(Consider), 기록만 하기(Noted), 기각하기(Dismissed)로 나뉩니다. 기각할 때는 이유를 적고, 어느 것도 자동으로 반영하지 않습니다.

버그봇 코멘트를 다루는 규칙도 따로 있습니다. 고치기(fix), 기각하기(dismiss), 물어보기(ask) 중 하나로 분류하는데, 보안이나 개인정보, 데이터에 관한 지적이나 애매한 지적은 사람에게 묻습니다. 문서에는 애매하면 물어보라는 원칙과 함께 그 이유가 적혀 있습니다. 사소한 코드 품질 코멘트를 넘기는 비용은 작지만, 진짜 데이터 버그나 보안 버그를 넘기는 비용은 크다는 것이죠.

반복 실수: 같은 지적은 린트·CI와 코드 구조로 막는다

영상에서 가장 현실적인 장면은 코드 주석 이야기였습니다. 처음에는 에이전트가 남기는 주석이 별문제 아니라고 생각했다고 합니다. 그런데 커서 코드베이스에서 에이전트가 주변 주석을 근거로 진짜 문제를 고치지 않고 임시방편을 정당화하는 일이 반복됐습니다. 우회 코드 하나가 여러 에이전트에게 복사되면 며칠 만에 사실상의 표준이 됩니다. 화면에는 “한 번 복사될 때마다 다음 복사가 더 쉬워진다”는 문장이 적혀 있었습니다.

그래서 그는 그록 봇(Grok Bot) 코드베이스에 에이전트용 프레임워크 듄(Dune)을 만들고, 주석을 금지했습니다. 잘못된 임포트(import), 정해진 계약을 거치지 않은 RPC 직접 호출, 파일 크기 증가 같은 지름길은 리뷰 전에 린트와 빌드에서 걸리게 했습니다. 화면 제목은 “가드레일은 리뷰 전에 지름길을 잡는다”였습니다. 이 주석 금지는 그 팀의 선택입니다. 모든 팀에 맞는 규칙이라는 근거는 영상에 없습니다.

pstack의 correct 스킬은 이 생각을 절차로 만든 것입니다. 최근 커밋, 되돌린 커밋, 리뷰 코멘트를 읽고 두 번 이상 나온 실수를 묶습니다. 그리고 가능한 가장 높은 층에서 막습니다. 먼저 구조로 실수가 불가능하게 만들고, 안 되면 타입과 린트와 CI로, 그다음 테스트로 막고, 문서는 마지막에 씁니다. 새로 만든 검사는 과거의 실제 실수에서 실패하는지 확인해야 합니다.

리뷰어가 같은 코멘트를 세 번째 쓰고 있다면, 그 지적은 사람보다 규칙에 맡기는 편이 낫습니다. 그는 팀에 이런 나쁜 패턴을 일찍 찾아 뽑아내는 “정원사(gardener)” 역할이 필요하다고 말했습니다.

그래도 사람이 맡는 일: 보안·데이터 판단과 검증 기준

이 구조에서 사람의 역할은 사라지지 않고 달라집니다. 영상 앞부분에서 그는 “최종 결과에 대한 책임은 여전히 우리에게 있다”고 말했습니다. pstack에서도 사람의 자리는 분명합니다. 보안과 데이터처럼 되돌리기 어려운 판단은 사람에게 묻습니다. 린트 예외를 둘 때는 이유와 만료일, 사람의 승인을 함께 남깁니다. show-me-your-work 스킬은 에이전트가 내린 결정을 근거와 함께 표로 남기게 하고, 사람이나 다른 모델이 나중에 그 표를 위에서부터 읽으며 확인합니다.

사람이 하던 일은 모든 줄을 읽는 일에서, 검증 기준을 정하고 반복되는 실수를 구조로 바꾸고 최종 결과를 책임지는 일로 옮겨 갑니다.

제 저장소에 붙여 보니: 커밋 훅·푸시 훅·변경 검토 에이전트

pstack 문서를 읽으며 고개를 끄덕인 대목이 많았습니다. 에이전트 아카데미 저장소에도 비슷한 장치를 하나씩 붙여 왔기 때문입니다. 처음부터 설계한 구조는 아니었습니다. 같은 실수를 두 번 겪을 때마다 제 기억 대신 훅(hook)이나 자동 검사에 맡기다 보니 지금 모양이 됐죠.

지금은 변경 하나가 머지되기 전에 몇 단계를 거칩니다. 커밋할 때는 훅이 메시지 형식과 결정 기록 번호를 확인합니다. 푸시하기 직전에는 다른 훅이 테스트와 빌드를 돌리고, main 브랜치로 곧장 올리는 푸시는 거부합니다. PR이 열리면 클라우드 빌드가 미리보기를 만들고, 별도 서버의 에이전트가 읽기 전용으로 diff를 살펴 원래 목적과 상관없는 변경이 섞였는지 댓글로 알려 줍니다. 빌드가 깨지면 또 다른 에이전트가 원인을 고쳐 PR 브랜치에 다시 올립니다. 머지 버튼은 지금도 제가 누릅니다.

효과를 실감한 건 해커톤 평가 기능을 다듬던 날이었습니다. 마감 뒤에 올라온 과제를 어떻게 판정할지 바꾸는 PR이었죠. 빌드와 테스트는 모두 통과했습니다. 그런데 변경 검토 에이전트가 댓글 하나를 남겼습니다. 결정 기록에는 지각 제출 판정만 적혀 있는데, diff에는 순위를 정렬하는 코드도 바뀌어 있다는 내용이었습니다. 열어 보니 코드를 쓴 에이전트가 근처 코드를 ‘정리하는 김에’ 손댄 것이었습니다. 그대로 머지했다면 참가자 순위가 아무도 모르게 바뀌었을 겁니다.

저는 그 변경을 떼어 내 별도 PR로 다시 확인했습니다. 비슷한 일이 한 번 더 생긴 뒤에는, 결정 기록과 diff가 맞는지 보는 규칙 일부를 스크립트 검사로 옮겼습니다. 같은 지적을 두 번 하지 말라는 pstack의 correct 스킬과 같은 방향입니다. 밤사이 깨진 빌드에는 아침이면 수정 커밋이 붙어 있는 날이 많아졌습니다. 그러자 제 리뷰도 달라졌습니다. 모든 줄을 읽는 대신, 결정 기록과 에이전트가 남긴 댓글을 보고 머지할지 판단하는 일이 됐죠.

물론 한계도 분명합니다. 혼자 운영하는 저장소라 규모가 작고, 변경 검토 에이전트는 경고만 할 뿐 머지를 막지 않습니다. 가끔은 문제없는 변경에도 경고를 남겨 다시 확인하는 수고가 생깁니다. 그래도 리뷰 부담이 어디서 줄어드는지는 분명히 느꼈습니다. 작동 증거와 판정, 반복되는 지적을 루프에 맡기자 제가 직접 봐야 할 것만 남았습니다.

우리 팀에 도입하기 전에 확인할 것

이 사례를 우리 팀에 그대로 옮기기는 어렵습니다. 로런 탠은 그록 봇 코드베이스에 많은 시간을 투자했다고 말했습니다. 비밀이라기보다 노력이 많이 든다는 말도 덧붙였죠. 검증 스킬, 기능 지도, 린트 규칙, 프레임워크를 먼저 만든 뒤에야 에이전트에게 더 많은 자유를 줬습니다.

조건도 다릅니다. 그는 커서 내부에서 클라우드 에이전트, 오토메이션(Automations), 버그봇을 자유롭게 쓸 수 있는 환경에 있습니다. 비용, 장애율, 되돌린 PR 비율은 공개하지 않았습니다. 보안 리뷰와 권한 분리를 어떻게 하는지도 영상에는 나오지 않습니다. PR 수만 보고 생산성이 몇 배 늘었다고 계산할 수는 없습니다.

마치며

한 달 PR 2,500개라는 숫자는 눈길을 끌기 쉽습니다. 하지만 제가 이 사례에서 가져가고 싶은 것은 숫자보다 몇 가지 질문입니다. 우리 팀 리뷰어가 매주 쓰는 코멘트 중 몇 개가 지난주와 같은 내용일까요. 그 코멘트는 린트 규칙이나 타입이 될 수 없을까요. PR을 연 사람과 그 PR이 작동한다고 판정하는 사람은 같은 사람일까요. 초록색 CI를 보고 머지 버튼을 누를 때, 누가 실제로 그 변경을 돌려 봤을까요.

에이전트가 PR을 여는 속도는 앞으로 더 빨라질 겁니다. 그 속도를 사람의 눈으로 따라가려 하면 리뷰어가 먼저 지칩니다. 다음 리뷰에서 같은 지적을 쓰려는 순간, 그 지적을 어디에 남길지 한 번 생각해 보면 어떨까요.

ⓒ요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.