한 달에 PR 2,000개, 에이전트를 믿게 만드는 다섯 가지: Lauren Tan 발표 정리

「한 달에 PR 2,000개를 프로덕션에 반영한 워크플로우」라는 영상 제목을 보고, 2,000이라는 숫자에 끌려 클릭했습니다.¹ 발표자인 Lauren Tan은 Cursor가 SpaceX AI에 속하기 전에 그곳에 합류했고, 지금은 SpaceX AI에서 Grokbot을 만들고 있다고 자신을 소개합니다.

📺 Lauren Tan: 한 달에 PR 2,000개를 프로덕션에 반영한 워크플로우 (Tech Bridge 한글 자막)

저는 코딩 에이전트 운영에는 자신이 있는 편이라, 한 달에 PR을 몇 개나 머지하는지 궁금해서 세어 봤습니다. 2026년 10월 한 달 동안 개인 GitHub 계정으로 머지된 PR은 137개였고, 회사 프로젝트의 프런트엔드 저장소에 팀 전체가 머지한 PR은 418개였습니다. 숫자를 보고 나니 한 사람이 한 달에 2,000개를 머지한다는 것이 얼마나 어려운 일인지 실감이 났습니다.

발표를 끝까지 보면 주제는 PR 개수가 아니라, 사람이 자리를 비워도 에이전트가 좋은 결과를 내도록 환경을 만드는 방법입니다. 발표는 그 방법을 다섯 가지로 요약합니다.

다섯 개에서 백 개로

에이전트를 한두 개에서 다섯 개 정도 띄워 놓고 대화마다 붙잡고 교정하는 단계가 있습니다. 사람이 손을 떼면 에이전트가 엉뚱한 일을 하니 떠날 수가 없습니다. Lauren Tan은 빠져나올 방법이 분명하지 않은 이 단계가 가장 벗어나기 어렵다고 봅니다. 다섯 개에서 백 개로 넘어가지 못하는 것은 아직 에이전트의 결과를 믿지 못해서입니다. 믿지 못하는 상태에서 서브에이전트나 클라우드 에이전트를 백 개씩 띄우면 저품질 PR과 회귀, 버그만 늘어납니다.

Lauren Tan은 2,000개를 목표로 삼은 적이 없습니다. 모든 일의 병목이 자신이라고 보고 엔지니어로서 가진 지식을 에이전트가 쓸 수 있는 형태로 옮기다 보니 따라온 숫자입니다.

발표에는 미슐랭 주방 비유가 나옵니다. 재료 하나하나는 에이전트가 조리하더라도 최종 요리의 책임은 사람에게 있고, 누구를 어디에 배치하고 어떤 장비와 훈련을 줄지 정하는 주방 구성이 결과를 좌우합니다. 요리사가 같은 곳에서 자꾸 무언가에 걸려 넘어지면 그것을 치우듯, 에이전트가 같은 실수를 반복하면 환경을 고쳐야 합니다.

다섯 가지

발표 마지막 슬라이드의 제목은 “whenever you correct your agent”(에이전트를 교정할 때마다)입니다. 그 아래에 다섯 가지가 순서대로 적혀 있습니다.

1. codebase
2. static analysis (lint/compiler/ci)
3. rules/bugbot
4. skills
5. “style guide”

다섯 가지는 단단한 제약에서 느슨한 안내로 이어집니다. 앞의 두 가지는 코드베이스와 도구로 에이전트의 행동을 직접 제약하는 방법입니다. 세 번째와 네 번째는 에이전트가 따르기를 기대하는 안내이고, 다섯 번째는 사람이 리뷰에서만 강제할 수 있는 규칙입니다.

1. 코드베이스

코드베이스는 에이전트에게 가장 좋은 형태의 기억입니다. 에이전트는 컨텍스트 윈도우에 들어온 것을 쓰려 하고, 열어 본 파일이 곧 컨텍스트가 됩니다. 그래서 에이전트는 PR마다 구조를 바꾸기보다 이미 있는 패턴을 확장합니다.

이 성질은 반대로도 작동합니다. 우회 코드 하나, 혹은 우회를 설명하는 주석 하나가 있으면 에이전트가 그것을 베끼기 시작합니다. 그 우회는 며칠이나 몇 주 만에 바이러스처럼 퍼져 사실상의 표준이 됩니다.

겉보기엔 무해하지만 실제로는 나쁜 패턴도 있습니다. 에이전트가 코드에 남기는 주석이 대표적입니다. 사람도 경계 사례나 까다로운 우회를 설명하려고 주석을 남겨 왔으니, Lauren Tan도 처음에는 에이전트의 주석이 나쁘지 않다고 생각했습니다. 그런데 Cursor 코드베이스에서 에이전트는 주변 주석을 근거로 근본 문제를 풀지 않고 임시방편으로 덮고 있었습니다. 이 때문에 Grokbot 코드베이스의 프레임워크인 Dune에서는 주석을 아예 금지했습니다.

Dune의 출발점은 Cursor IDE를 대체하려고 만든 새 에이전트 창(agents window)의 성능 문제였습니다. 그 문제를 겪으며 팀이 세운 핵심 원칙은 에이전트가 지름길을 좋아한다는 것이었고, 그래서 지름길이 곧 올바른 길이 되도록 설계했습니다. 코드가 어디에 있어야 하고 무엇을 어디서 import할 수 있는지가 엄격히 정해져 있습니다. 예를 들어 Electron의 메인 프로세스에서 돌아야 할 코드는 렌더러에서 import할 수 없습니다. 에이전트 창에서 무거운 코드가 실수로 렌더러에 import되어 UI가 느려진 일이 있었습니다. 렌더러는 60fps라면 16ms, 120fps라면 8ms를 넘는 작업이 없어야 부드럽게 유지됩니다. Dune은 이 경계를 import와 의존성 그래프로 강제해, 성능 문제를 일으켰던 패턴을 구조적으로 없앴습니다. 아키텍처만이 아니라 더 나은 데이터 구조나 알고리즘으로도 잘못된 길을 없앨 수 있습니다.

Dune처럼 할 수 있는 것과 없는 것이 엄격하게 정해진 코드베이스는 사람에게 답답합니다. 하지만 맥락이 적은 에이전트에게는 그런 코드베이스가 완벽한 환경입니다. 이제는 엔지니어 말고도 디자이너, PM, CEO가 에이전트로 기능을 내보낼 수 있어서, 바쁘고 맥락이 적은 사람이 조종하는 에이전트도 기본적으로 좋은 결과를 내야 합니다. 숙련 엔지니어가 리뷰 코멘트로 전하던 암묵지를 프레임워크가 대신 강제합니다.

Lauren Tan은 코드베이스를 정원에 빗대며 정원사(gardener)라는 역할을 말합니다. 잡초처럼 원치 않는 패턴이 자라기 시작하면 퍼지기 전에 잘라내는 사람입니다. Dune의 원칙도 같은 방향입니다. 이미 있는 기술 부채는 지우고, 에이전트가 그대로 베껴도 괜찮은 상태로 코드베이스를 유지합니다.

2. 정적 분석

두 번째는 린터, 컴파일러 진단, CI입니다. 교정해도 에이전트가 같은 실수를 반복한다면 그 실수를 막는 린트 규칙을 만듭니다. 더 좋은 방법은 코드베이스를 바꿔 그 실수가 아예 일어날 수 없게 하는 것입니다.

당장 모두 고치지 못하더라도 규칙부터 걸어 두면 문제가 더 번지지는 않습니다. 대부분의 일에는 정해진 길(paved path)을 하나만 두고, 코드베이스와 CI, 린터가 그 길로 안내하면 에이전트는 추측할 필요가 없어집니다.

3. rules와 Bugbot

세 번째는 에이전트가 읽는 규칙 문서(rules)와, PR을 검토해 버그와 코드 품질 문제를 찾는 Cursor의 Bugbot입니다.² 에이전트는 대부분 규칙을 따르지만, 규칙을 읽지 않고 넘어가거나 에이전트를 조종하는 사람이 무시할 수도 있습니다. 강제력은 앞의 두 가지보다 약합니다.

4. skills

네 번째는 skills입니다. Lauren Tan은 Cursor에 합류한 뒤 에이전트 창의 성능 문제를 맡아 Chrome DevTools로 트레이스와 힙 스냅샷을 뜨는 일을 손으로 했는데, 쏟아지는 PR이 성능을 떨어뜨리는지 일일이 확인할 수 없었습니다. 그래서 에이전트가 직접 앱을 실행하고 트레이스를 분석해 핫스팟을 찾도록 가르쳤고, 그렇게 처음 만든 스킬이 검증 스킬입니다.

이 스킬은 두 부분으로 이루어져 있습니다. 첫째는 스킬 디렉터리 안에 둔 CLI입니다. 에이전트가 세션마다 다른 스크립트를 새로 짜지 않고 같은 도구로 앱을 실행하고 증거를 모으게 합니다. 둘째는 기능 지도(feature map)입니다. 앱에 어떤 기능이 있고 사용자가 어떤 단축키나 DOM 요소를 거쳐 그 기능에 도달하는지를 적은 문서입니다. 화면 일부만 잘린 스크린샷에 물음표만 붙은 제보가 와도, 에이전트가 기능 지도를 보고 사용자가 말하는 기능을 찾아갈 수 있습니다. 기능 지도는 자동화로 계속 갱신됩니다. CLI와 기능 지도를 갖춘 이 스킬은 지금 팀의 핵심 인프라가 되었습니다.

앱을 직접 실행해 확인하는 방식이 검증의 한쪽 끝이라면, 반대쪽 끝에는 Lean이나 TLA+ 같은 형식 검증이 있습니다. 형식 검증을 실제로 쓰는 팀은 드물지만, 검증 스킬만으로도 충분히 많은 것을 확인할 수 있습니다.

검증이 확인하는 것은 기능이 의도대로 동작하는지입니다. 동작한다는 증거만으로는 그 기능의 성능이나 코드 품질을 판단하기 어렵습니다. 그래서 디버깅, 기능 개발, 프로토타이핑 같은 작업 방식을 담은 스킬이 함께 필요합니다. 숙련 엔지니어가 이런 스킬을 팀 저장소에 모아 두면 에이전트가 더 똑똑해집니다. 작업 방식을 담은 스킬과 검증 스킬을 함께 쓰면 에이전트의 작업은 정확하면서 품질도 좋아집니다. 또 검증 스킬은 동작 여부와 별개로 실제 성능 수치를 모으므로, 성능은 그 수치로 확인할 수 있습니다.

5. 스타일 가이드

마지막은 스타일 가이드입니다. 앞의 네 가지에 담지 않은 규칙은 사람이 바뀐 줄을 전부 읽고 기억해서 지적해야 합니다. 지금의 PR 속도에서는 불가능한 일입니다. 스타일 가이드와 사람의 리뷰는 무엇이 빠졌는지 찾는 출발점으로 삼고, 찾아낸 규칙은 시간을 들여 앞의 네 가지로 옮겨야 합니다.

바깥 루프

바깥 루프(outer loop)는 사람이 에이전트를 직접 띄우는 대신, 외부 서비스에서 생긴 이벤트로 에이전트 작업이 시작되는 흐름입니다. Grokbot은 Slack, Datadog, Sentry, PlanetScale 같은 서비스에 연결해 정보를 모을 수 있고, Grokbot routines로 Slack 스레드나 Sentry 알림을 구독하면 이벤트가 생길 때 클라우드 에이전트를 자동으로 띄울 수 있습니다. Lauren Tan은 에이전트가 이미 도구를 잘 쓰니 “company brain”이라 불리는 정교한 인프라까지는 필요 없다고 봅니다. Cursor 자동화와 SDK로 만든 봇도 앞에서 쌓은 코드베이스, 규칙, 스킬을 재사용합니다.

발표에서는 Cursor 개발에 쓰는 자동화와 에이전트의 스크린샷으로, 버그 제보를 자동으로 재현하는 예와 PR을 자동으로 여는 예를 보여 줍니다.

교정할 때마다 위에서부터

발표는 다섯 가지를 다시 짚으며 끝납니다. 에이전트를 교정하거나 작업에 개입할 때마다 다섯 가지 중 어디에서 막는 것이 가장 효과적인지 순서대로 따져 보라고 권합니다. 먼저 교정하게 만든 실수를 코드베이스로 아예 불가능하게 만들 수 있는지 보고, 안 되면 정적 분석으로 막고, 그 위에 rules와 Bugbot, skills를 얹습니다. 이렇게 쌓은 환경을 믿을 수 있게 되면 에이전트를 자유롭게 풀어 둘 수 있습니다.

정리하며

발표에서 가장 인상 깊었던 것은 에이전트가 우회 코드를 퍼뜨린다는 문제와, 이를 막으려면 코드베이스를 사람이 작업하기 힘들 정도로 까다롭게 만들어야 한다는 처방이었습니다. 누구나 떠올릴 수 있는 이야기이기도 하지만, 이렇게 정리하기는 쉽지 않다고 느꼈습니다. 그래서 실제 저장소도 그렇게 까다롭게 만들어 볼 생각입니다.

이 글을 함께 일하는 팀원들에게도 공유하려고 합니다. 앞으로 우리 저장소의 정원사 역할을 해 보려고 하거든요. 그래서 저장소가 조금 답답해질 수도 있습니다. :)

Footnotes

1. 발표: Lauren Tan, 2026-09-21 공개(https://x.com/poteto/status/2102050467505430555). 한글 자막 영상: Tech Bridge, 「[한글자막] Cursor&xAI 개발자 Lauren Tan: 한 달에 PR 2,000개를 프로덕션에 반영한 워크플로우」, 2026-09-25 게시. https://youtu.be/zkmvCDSxqdc ↩

2. Cursor 문서, Bugbot. https://cursor.com/docs/bugbot ↩