Cursor 엔지니어가 한 달에 PR 1,000개를 머지하는 방법

AI 코딩 에이전트 Cursor의 엔지니어 로렌 탄(Lauren Tan)이 진행한 Maven 라이브 워크숍 "How Cursor Turned AI Agents Into Better Engineers" 세션이 2026년 8월 12일 Maven에서 진행되어 그 내용을 리뷰해봤습니다.

지난 뉴스레터에서 저는 "새로운 모델이 계속 출시되더라도 결국 중요한 건 나만의 하네스다."고 썼습니다. 

이번 세션은 그 연장선에 있습니다. 로렌 탄은 Cursor가 SpaceX에 인수된 뒤 내놓은 첫 번째 제품인 그록 봇(Grok Bot)의 아키텍처를 만든 엔지니어입니다. 그녀가 한 달에 PR 1,000개를 머지할 수 있었던 비결은 더 좋은 모델이 아니라, 에이전트를 믿을 수 있게 만드는 하네스였습니다.

들어가며

AI 코딩 에이전트를 쓰는 개발자라면 한 번쯤 겪어 본 장면이 있습니다. 에이전트가 "드디어 원인을 찾았습니다(smoking gun)"라고 자신 있게 선언하는데, 실제로는 엉뚱한 곳을 고치고 있는 장면입니다. 이런 일이 백 번쯤 반복되면 신뢰는 바닥으로 떨어지고, 개발자는 에이전트의 모든 출력을 한 줄씩 들여다보는 감시자가 됩니다.

로렌 탄은 이 문제를 정면으로 다룹니다. 그녀는 Cursor에 합류한 지 5개월 만에 한 달 동안 PR 1,000개를 머지했고, 이 워크숍이 열린 달에는 12일까지 이미 800개 가까이 머지했습니다. 아침에 일어나 보니 에이전트가 밤새 자동 머지한 PR이 20개 있었고, 이를 main 브랜치에서 사후 리뷰했는데 모두 괜찮았다는 이야기도 합니다.

숫자보다 중요한 것은 그 숫자에 이르는 과정입니다. 이 글은 그 과정을 정리합니다.

연사 소개: 로렌 탄은 누구인가

로렌 탄은 X(구 트위터)에서 @potetotes, 깃허브에서 poteto라는 이름으로 활동하는 프론트엔드 엔지니어입니다. 메타(Meta)의 React 코어 팀에서 React Compiler 개발을 이끌었고, 2024년 10월 React Compiler 베타 발표 글의 저자이기도 합니다. React Conf 연사 소개에 따르면 대학에서 컴퓨터공학이 아닌 재무를 전공했고, 엑셀로 코딩을 배웠습니다.

2026년 초 Cursor에 합류한 뒤에는 원래 클라우드 에이전트 팀으로 갈 예정이었지만, React 경험 덕분에 React로 만든 '에이전트 윈도우(Agents Window)' 출시 작업에 투입됐습니다. 이후 SpaceXAI(구 xAI)가 Cursor를 인수했고, 두 회사의 첫 공동 제품인 그록 봇(Grok Bot)이 2026년 8월 11일 베타로 출시됐습니다. 로렌 탄은 그록 봇의 아키텍처 작업에 깊이 관여했습니다. 이 워크숍은 그록 봇 출시 바로 다음 날 열렸습니다.

Grok Bot 실제 사용 화면

그녀가 공개한 pstack은 Cursor 내부에서 쓰던 자신의 에이전트 스킬 모음을 MIT 라이선스로 공개한 Cursor 플러그인입니다. 공개 시점에 Cursor 엔지니어링 팀이 그녀의 스킬을 일주일에 1만 번 사용하고 있었습니다.

1. AI는 도구가 아니라 페어 프로그래머입니다

로렌 탄은 AI 열풍 속에서 개발자들이 느끼는 압박을 솔직하게 짚습니다. 이번 주에 PR 100개를 내야 하고, 내가 무슨 일을 하는지도 잘 모르면서 바이브 코딩으로 연 매출 100만 달러를 찍어야 할 것 같은 압박입니다. 그리고 본인도 겪은 역설을 이야기합니다. AI로 코드 작성 시간은 줄었지만, AI가 한 일을 리뷰하고 바로잡는 데 오히려 더 많은 시간을 쓰게 됐다는 것입니다.

2. 신뢰 곡선: 마이크로매니지먼트에서 자동 머지까지

로렌 탄은 에이전트와의 관계를 엔지니어링 매니저와 팀원의 관계에 빗댑니다.

그녀가 직접 그린 '신뢰 곡선'은 이렇습니다. 곡선의 아래쪽에서는 한두 개의 에이전트와 함께 루프 안에 깊이 들어가 모든 출력을 지켜보고 계속 프롬프트를 입력합니다. 에이전트 하나도 믿지 못하는데 100개를 띄울 수는 없으니, 병렬화도 불가능합니다. 곡선의 위쪽으로 올라가면 에이전트가 PR을 스스로 머지하는 단계에 이릅니다.

그녀의 PR 기여 그래프는 이 곡선과 정확히 겹칩니다. 합류 첫 달에는 코드베이스를 익히느라 생산성이 낮았고, 에이전트에 대한 신뢰가 쌓일수록 머지 속도가 가파르게 올라갔습니다. 그녀는 "AI에 의지해 마구 코드를 찍어낸 것처럼 들리겠지만 그렇지 않다"고 웃으며 덧붙였습니다.

3. 가장 중요한 스킬은 '검증'입니다

로렌 탄이 꼽는 에이전트 작업의 핵심 역량은 검증(verification)입니다.

검증이 좋은 코드를 보장하지는 않습니다. 하지만 최소한 올바른 코드를 보장합니다. 이것이 신뢰를 쌓는 첫걸음입니다. 그녀가 이 결론에 이른 계기는 에이전트 윈도우라는 기능의 출시 직전의 성능 작업이었습니다. 이 기능은 여러 AI 에이전트를 동시에 띄우고 관리하는 작업 화면으로 Cursor 3에 추가되었습니다.

입사 첫 주, 출시까지 일주일 남은 상황에서 그녀는 크롬 개발자 도구로 트레이스를 뜨고 플레임 그래프를 해석하려 애썼습니다. 코드베이스도 낯설었고, 에이전트는 더 몰랐습니다. 스크린샷과 트레이스 파일을 건네면 에이전트는 "이게 원인인 것 같다"고 자신 있게 말했지만 대부분 틀렸습니다.

에이전트가 코드를 쓰면 사람이 로컬 개발 빌드를 열고, 안 되면 스크린샷과 콘솔 에러를 복사해 붙여넣는 루프가 반복됩니다. 이 구조에서는 병렬화가 불가능합니다.

그래서 그녀가 Cursor에서 처음 만든 스킬이 control-glass입니다. 'Glass'는 에이전트 윈도우의 내부 코드명입니다. 이 스킬은 에이전트가 크롬 개발자 도구 프로토콜(CDP)을 통해 일렉트론(Electron) 앱을 직접 띄우고, 조작하고, 트레이스를 뜨도록 가르칩니다. 로렌 탄은 스킬 코드 자체는 특별하지 않으며, 에이전트에게 시키면 쉽게 만들어 준다고 말했습니다. 웹앱이라면 CDP, iOS 앱이라면 애플의 시뮬레이터 제어 도구를 쓰면 됩니다.

4. 피처 맵: 에이전트에게 제품 지도를 쥐여 주세요

검증 스킬을 만들고 나니 새로운 문제가 드러났습니다. 에이전트가 앱을 실행할 수는 있게 됐지만, 앱이 무엇인지는 몰랐습니다.

해법은 피처 맵(feature map) 파일입니다. 제품의 모든 기능에 대해 사용자 관점의 진입 경로, 하위 기능, 키보드 단축키, CDP로 요소를 선택할 때 쓰는 DOM 속성까지 기록합니다.

효과는 사내 슬랙 피드백 채널에서 특히 컸습니다. Cursor 내부 피드백은 품질이 낮은 경우가 많습니다. 스크린샷 한 장에 물음표 세 개만 달린 보고가 흔합니다. 피처 맵이 없으면 에이전트는 속수무책이지만, 피처 맵이 있으면 모호한 보고도 실제 기능과 연결할 수 있습니다.

pstack에는 코드를 탐색해 초기 피처 맵을 만들어 주는 create-verification 스킬과, 이를 최신 상태로 유지하는 maintain-verification 스킬이 함께 들어 있습니다.

5. pstack의 탄생: 실패 모드 하나당 스킬 하나

pstack이라는 이름에는 농담이 담겨 있습니다. Y 콤비네이터 CEO 개리 탄(Garry Tan)이 만든 'GStack(Garry Stack)' 플러그인을 비튼 것이고, P는 로렌이 사용하는 트위터 아이디 poteto(감자)의 P입니다. 두 사람은 성이 같지만 아무 관계도 없습니다.

로렌 탄의 트위터 프로필

로렌 탄은 처음부터 pstack을 만들려던 것이 아닙니다. 에이전트의 실패를 관찰할 때마다 스킬을 하나씩 추가하다 보니 쌓인 결과물입니다. 대표적인 예가 how 스킬입니다.

이 경험은 불신으로 이어지기 쉽습니다. 그런데 로렌 탄은 여기서 다시 매니지먼트 비유를 꺼냅니다. 코딩 실력은 뛰어나지만 비즈니스 맥락이 전혀 없는, 5초 전에 온보딩한 신입이 있다면 어떻게 가르칠까요? 그 방법이 바로 스킬입니다. 스킬은 결국 마크다운 파일이지만, 좋은 토큰을 먼저 제공하면 모델이 더 높은 수준의 패턴에 맞춰 답을 생성합니다. 일부에서는 이를 "에이전트를 다른 잠재 공간(latent space)으로 끌어당긴다"고 표현합니다.

그래서 pstack의 스킬들은 이런 지시로 가득합니다. 추측하지 말 것, 직접 코드를 찾아볼 것, 서브에이전트를 적극적으로 쓸 것.

6. 스킬도 테스트해야 합니다: eval과 힐클라이밍

제품은 계속 바뀌고, 수많은 사람이 코드베이스에 PR을 올립니다. 스킬은 어떻게 유지할까요? 로렌 탄의 답은 eval입니다.

pstack에는 eval-playbook이 들어 있고, 절차는 꽤 엄격합니다.

Cursor는 여러 모델을 지원하므로, 같은 스킬을 다양한 모델에서 돌려 보고 성능 편차를 확인할 수도 있습니다. 로렌 탄은 검증 스킬 자체도 이 방식으로 검증했습니다.

그러면서도 그는 스킬 유지보수가 쉽지 않다는 점을 인정합니다. 취향과 관찰력이 필요하고, 좋은 '뒷좌석 운전자'가 되어야 합니다. 초기에는 수동적인 관찰자가 아니라 운전석에 앉아 도구 호출 기록과 사고 과정(thinking block)을 직접 읽으며 에이전트가 어디서 무너지는지 찾아야 합니다.

7. 로컬에서 시작해 클라우드로: 버그 재현 에이전트 '베니'

실제로 검증 시스템을 만들려면 어디서 시작해야 할까요? 로렌 탄의 답은 로컬입니다. 처음에는 에이전트가 앱을 어떻게 띄우고, 어디를 클릭하고, 어떤 API를 호출하는지 내 눈으로 지켜봐야 하기 때문입니다. 그래야 어디서 헤매는지 보이고, 그 지점을 스킬로 보완할 수 있습니다.

로컬에서 신뢰가 쌓이면 다음 단계는 클라우드입니다. 로렌 탄 자신은 지금 거의 전적으로 클라우드 에이전트를 씁니다. 클라우드로 옮겨 가면 검증 스킬이 내 컴퓨터를 벗어나, 팀 전체와 회사 전체가 함께 쓰는 자산이 됩니다. 환경 설정에 들인 약간의 시간이 몇 배로 돌아오는 셈입니다.

대표적인 사례가 '베니(Benny)'라는 자동화 에이전트입니다. 베니는 들어오는 버그 리포트를 받아 클라우드에서 자기만의 데스크톱을 열고, Cursor를 실행하고, 같은 control 스킬로 버그를 재현합니다. 워크숍에서 보여 준 사례에서 베니는 버그를 재현했을 뿐 아니라 main 브랜치에서는 이미 고쳐졌다는 사실까지 확인했습니다. 남은 일은 새 빌드를 배포하는 것뿐이었습니다. 사람이 한 시간 동안 에이전트와 씨름했을 일을 자동으로 끝낸 셈입니다.

다만 그는 단계를 건너뛰지 말라고 강조합니다.

진행자가 정리한 순서는 이렇습니다. 먼저 검증 스킬로 에이전트가 최소한 올바른 코드를 만든다는 것을 확인하고, 로컬에서 신뢰가 쌓이면 클라우드로 확장해 버그 리포트 같은 신호를 에이전트가 스스로 처리하게 하고, 마지막으로 PR 자동 머지로 넘어갑니다. 로렌 탄은 이 곡선에 지름길은 없다고 답했습니다. 결국 개인이 에이전트를 얼마나 신뢰하느냐의 문제이기 때문입니다.

8. 엔지니어는 이제 헤드 셰프입니다

로렌 탄은 엔지니어의 역할 변화를 식당 주방에 빗댑니다.

9. 새 프로젝트가 가장 위험합니다

워크숍 후반부에서 로렌 탄은 업계에서 가장 논쟁적인 주제 중 하나를 꺼냅니다. 기존 앱을 갈아엎고 새로 짜야 할까요? 새 회사에 들어간 엔지니어가 코드베이스를 보고 "누가 이렇게 짰지? 전부 다시 쓰고 싶다"고 느끼는 것은 흔한 일이고, 업계의 통념은 대체로 "다시 쓰지 말라"입니다. 로렌 탄은 에이전트 시대라면 이야기가 달라질 수 있다는 입장입니다.

출발점은 빅테크에서의 경험입니다. 수많은 손이 동시에 코드를 쏟아내는 환경은 예전에는 빅테크만의 문제였지만, 에이전트가 코드를 대량으로 쓰는 지금은 모든 팀의 문제가 됐습니다. 메타 시절, 수만 명의 엔지니어가 거대한 모노레포에 코드를 쏟아냈고, 뛰어난 엔지니어가 많았지만 코드 품질은 생각보다 좋지 않았습니다.

빅테크의 인프라는 바로 그 문제를 위해 설계됐습니다. 프레임워크와 컨벤션, 가드레일, 인턴이 프로덕션 DB를 날리지 못하도록 제한한 권한까지 갖춰져 있습니다. 이런 인프라가 있는 코드베이스라면 에이전트도 이미 상당히 잘 작동합니다.

오히려 위험한 쪽은 그린필드(신규) 프로젝트입니다. 그록 봇도 프로토타입 단계에서는 사람이 코드를 전혀 읽지 않는 바이브 코딩으로 빠르게 만들어졌습니다. 가드레일이 없으면 에이전트는 매번 가장 편한 방법으로 문제를 풉니다. 로렌 탄은 이를 '유기적 아키텍처(organic architecture)'라고 부릅니다. 지름길에 최적화된 코드가 쌓이면서 코드베이스는 통제 불능으로 치닫습니다.

그녀는 600개가 넘는 PR로 그록 봇 전체를 새 아키텍처로 리팩터링했습니다. 그 결과 이제는 코드를 거의 보지 않습니다. 그녀는 이 말이 Grok 모델로 토큰을 많이 쓰라는 이야기가 아니라, 에이전트를 믿고 일을 맡기기까지 막대한 작업과 토큰이 들었다는 뜻이라고 분명히 했습니다.

10. Dune: 가장 짧은 경로가 최선의 경로가 되게 하세요

그록 봇의 새 아키텍처 코드명은 'Dune'입니다. 로렌 탄은 이를 "일렉트론 앱을 위한 Next.js"이자, 에이전트가 쓰도록 설계된 프레임워크라고 설명합니다. 핵심 원칙은 한 문장입니다.

에이전트는 언제나 지름길을 택합니다. 그렇다면 지름길 자체를 정답으로 만들면 됩니다. Dune의 CI는 사람이 쓰기에는 짜증스러울 만큼 엄격하지만, 그 짜증은 에이전트가 흡수합니다.

로렌 탄은 Dune을 오픈소스로 공개할 계획은 없으며, 코드라기보다 아이디어와 원칙의 모음이라고 설명했습니다. 슬라이드를 캡처해 에이전트에게 비슷한 것을 만들어 달라고 해도 된다고 덧붙였습니다.

11. 강제의 계층: 부드러운 규칙만으로는 무너집니다

로렌 탄은 좋은 코드베이스를 만드는 장치를 계층으로 설명합니다.

약한 계층도 쓸모가 있지만, 에이전트가 잊어버리거나 일관되게 적용하지 않을 수 있습니다.

이 관점에서 기술 스택 선택도 중요해집니다. 러스트(Rust)가 다시 주목받는 이유 중 하나는 컴파일러가 많은 것을 강제하기 때문입니다. 러스트 컴파일러에는 '대여 검사기(borrow checker)'라는 장치가 있어서, 메모리를 잘못 다룰 위험이 있는 코드는 아예 컴파일되지 않습니다. 그래서 에이전트가 이 안전장치를 끄는 unsafe 블록만 쓰지 않는다면, 일단 컴파일에 성공한 코드는 대체로 믿을 만합니다. 사람이 일일이 확인하지 않아도 컴파일러가 1차 검증을 대신해 주는 셈입니다.

가장 나쁜 상태는 코드 리뷰에서 사람이 일일이 지적하는 방식으로 불변 조건을 지키는 것입니다.

12. PR 크기와 git 히스토리

PR 크기에 상한은 없습니다. 몇십 줄부터 천 줄까지 다양합니다. 다만 로렌 탄은 에이전트에게 작업을 여러 PR로 쪼개도록 권합니다. git 히스토리는 풍부한 맥락의 원천이고, PR 하나가 작은 변경 하나를 원자적으로 설명해야 되돌리기도 쉽고 버그 원인도 찾기 쉽기 때문입니다. 4만 줄짜리 PR 안에서는 무엇이 들어갔는지 아무도 모릅니다.

참고로 그록 봇과 Cursor의 가상화(virtualization)는 청 루(Cheng Lou)가 만든 텍스트 레이아웃 라이브러리 프리텍스트(Pretext)로 구현돼 있습니다. 프리텍스트는 DOM 리플로우 없이 텍스트를 측정하고 배치하는 라이브러리입니다.

13. 토큰 비용은 ROI의 문제입니다

토큰이 무제한인 AI 회사 사람의 이야기가 일반 개발자에게도 현실적일까요? 로렌 탄은 자신이 무제한 토큰 환경에 있다는 점을 인정하면서, 이는 ROI의 문제라고 답합니다.

리팩터링과 가드레일 구축에는 초기에 많은 토큰이 듭니다. 하지만 혼자서 이런 수준의 제약을 코드베이스에 강제하려면 에이전트 이전 시대라면 몇 년이 걸렸을 것입니다. 엔지니어링 리더가 따져야 할 질문은 이것입니다. 이 일을 할 사람을 채용할 것인가, 아니면 가장 순진한 에이전트도 좋은 코드를 쓸 수 있는 코드베이스를 만드는 데 토큰을 쓸 것인가? 그 지점에 도달하면 초대형 모델이 아니어도 훌륭한 코드를 씁니다.

그는 1만 명짜리 엔지니어링 조직이 되는 대신 작고 민첩하게 유지할 수 있다는 점을 에이전트의 진짜 가치로 꼽았습니다. 워크숍 당일 발표된 그록 4.6(Grok 4.6)에 대해서는 토큰당 비용이 4.5와 같으면서 더 똑똑하다고 소개하며, Cursor와 SpaceXAI가 비용과 지능 사이의 파레토 프론티어를 최적화하려 한다고 설명했습니다.

14. PM과 디자이너도 코드를 내보냅니다

엔지니어가 이렇게 빨리 내보내면 제품 팀은 어떻게 따라갈까요? 로렌 탄은 그록 봇이 그 답이라고 말합니다. Cursor의 기존 제품(에이전트 윈도우, CLI, IDE)은 개발자 중심의 파워 유저 도구였습니다. 그록 봇은 Apple의 iMessage처럼 익숙한 인터페이스에서 에이전트에게 이름과 역할을 주고 사람처럼 협업하게 합니다. PM은 "로렌이 어젯밤에 한 일을 요약해 줘"라고 시킬 수 있습니다.

그리고 PM도 직접 코드를 내보냅니다. PM이 "버그를 고쳤는데 봐 줄래요?"라고 가져온 PR이 완벽해서 바로 승인한 적도 있습니다. 로렌 탄은 이것이 Dune 아키텍처가 제대로 작동한다는 증거라고 봅니다. 엄격한 제약 덕분에 엔지니어링 전문가가 아닌 사람도 높은 수준으로 기여할 수 있다는 것입니다.

맺으며: 신뢰는 설계하는 것입니다

로렌 탄의 이야기를 한 줄로 요약하면 이렇습니다. 에이전트에 대한 신뢰는 기대하는 것이 아니라 설계하는 것입니다.

로렌 탄의 방법론을 한 발 물러서서 보면 두 가지로 요약됩니다. 에이전트가 무엇을 했는지 들여다보는 것, 그리고 그 결과를 점수로 평가하고 개선하는 것입니다. 도구 호출 기록과 사고 과정을 직접 읽으며 실패 지점을 찾고, 채점 기준표를 만들어 다른 AI에게 스킬을 채점하게 하고, 10점이 될 때까지 힐클라이밍한 과정이 모두 여기에 속합니다.

검증 기준을 세우고, 목표 점수에 도달하도록 루프(/loop)를 돌며 품질을 높이고, 안정화되면 클라우드로 확산해서 생산성을 높인다. 저 역시 6개월 전 같은 방식으로 검색엔진의 품질을 높이면서 체험한 방법론이고 로렌은 이 방법론을 Grok Bot이라는 제품 개발에 적용해본 것입니다.

지난 뉴스레터에서 저는 하네스가 핵심 경쟁력이 된 이후의 경쟁은 세 가지에서 갈릴 것이라고 썼습니다. 루프를 잘 돌릴 수 있는 데이터셋, 하네스가 안전하게 스스로 개선되도록 통제하는 거버넌스, 그리고 품질과 비용을 통제하는 능력입니다. 로렌 탄의 세션은 이 세 가지가 실제 제품 개발 현장에서 어떻게 작동하는지 보여 줍니다.

데이터셋. 로렌 탄이 가장 먼저 만든 것은 에이전트가 아니라 피처 맵과 검증 스킬, 그리고 스킬을 채점할 eval이었습니다. 루프는 목표 점수를 향해 쉬지 않고 달리지만, 그 점수가 무엇을 재는지는 사람이 정해야 합니다. 채점 기준이 허술하면 에이전트는 허술한 기준에 맞춰 빠르게 최적화될 뿐입니다.

거버넌스. 에이전트가 PR을 스스로 머지하는 단계는 신뢰가 충분히 쌓인 뒤에야 왔습니다. 그 신뢰를 떠받치는 것은 useEffect 금지, import 경계 검사처럼 CI가 강제하는 딱딱한 제약입니다. 에이전트에게 자율성을 주려면 그만큼 단단한 울타리가 먼저 있어야 한다는 것입니다.

품질과 비용. 가장 반가웠던 대목입니다. 로렌 탄은 코드베이스에 제약을 충분히 걸어 두면, Fable급 초대형 모델이 아니어도 에이전트가 훌륭한 코드를 쓴다고 말했습니다. 앤드류 응(Andrew Ng) 교수가 제시한 비전, 즉 하네스를 잘 구성하면 낮은 사양의 모델도 고성능 모델을 이길 수 있다는 주장을 실제 제품 개발에서 확인한 셈입니다. 로렌 탄은 스킬을 수정할 때마다 여러 모델에서 eval을 돌려 성능을 비교합니다. 특정 모델에 묶이지 않고 벤치마크로 모델을 골라 쓰는 구조가 이미 일상적인 작업 방식이 된 것입니다.

로렌 탄이 공유한 이 방식은 일종의 성공 방정식입니다. 제가 알고 있는 많은 엔터프라이즈에서 이미 이 방식으로 에이전트를 만들고 있습니다. 이전에도 이야기했지만 이제부터는 데이터셋과 검증의 싸움입니다. 본격적으로 확산되고 있는 이 방식으로 여러분의 에이전트도 한 단계 끌어올려 보시길 바랍니다.