한 달에 PR 2,000개를 프로덕션에 반영한 Lauren Tan의 AI 개발 워크플로우

메타데이터

• 원문 URL: https://www.youtube.com/watch?v=zkmvCDSxqdc
• 날짜: 2026-09-25
• 채널: latentspacepod
• 출연 인물: Lauren Tan, 온라인 핸들 Potato on X
• 소속·업무: Cursor를 거쳐 xAI의 Grokbot 개발에 참여
• 원문 제목: [한글자막] Cursor&xAI 개발자 Lauren Tan: 한 달에 PR 2,000개를 프로덕션에 반영한 워크플로우

---

📌 핵심 질문 / 에이전트를 얼마나 믿고 병렬화할 수 있는가

Lauren Tan의 핵심 주장은 에이전트 수를 무작정 늘리는 데 있지 않다. 코드베이스·검증 도구·정적 분석·규칙·스킬을 에이전트 친화적으로 설계하면, 사람이 모든 작업을 붙잡고 교정하지 않아도 높은 품질의 코드를 대량으로 프로덕션에 보낼 수 있다는 주장이다.

• 한 달에 풀 리퀘스트(Pull Request, PR) 2,000개를 프로덕션에 반영한 원동력은 에이전트에 대한 신뢰다.
• 신뢰는 추상적인 낙관론이 아니라, 재현 가능한 검증과 자동화된 품질 장치에서 나온다.
• 좋은 코드베이스는 에이전트가 읽고 복제하는 ‘물질화된 기억(materialized memory)’이므로, 올바른 패턴을 기본값으로 만들고 나쁜 패턴의 전파를 막아야 한다.
• 목표는 조립 라인식 ‘소프트웨어 공장(software factory)’이 아니라, 숙련된 요리사·도구·동선·훈련이 결합된 미슐랭 주방(Michelin kitchen)이다.

1. PR 2,000개를 가능하게 한 관점 전환

1.1. 숫자보다 먼저 세운 신뢰

1. Lauren Tan의 출발점

   1. Lauren Tan은 자신을 X에서 Potato On X라는 이름으로 알 수도 있다고 소개한다.
   2. xAI에서 Grokbot을 개발하며, 지난달 프로덕션에 풀 리퀘스트 2,000개를 반영했다고 말한다.
   3. 2,000개라는 숫자는 처음부터 세운 목표가 아니었다. 스스로 정한 생산량 목표를 달성한 결과가 아니라, 스킬·도구·코드베이스를 계속 고친 결과가 누적된 수치다.

2. 신뢰의 정의

   1. Lauren Tan이 말하는 신뢰는 사람이 자리를 비운 동안에도 에이전트가 높은 품질의 작업을 내놓을 수 있다는 믿음이다.
   2. 에이전트가 잘할 것이라고 기대하는 데서 멈추지 않고, 잘못된 결과를 잡아낼 검증 증거를 수집해야 한다.
   3. 에이전트 환경을 매우 잘 설정하면 개인용 또는 팀용 생산 시스템처럼 높은 품질의 코드를 이전보다 훨씬 빠르게 만들 수 있다.

1.2. 소프트웨어 공장 대신 미슐랭 주방

1. 공장 비유를 거부한 이유

   1. Lauren Tan은 ‘소프트웨어 공장’이라는 표현을 좋아하지 않는다. 기술 작업은 컨베이어벨트에서 제품을 대량 생산하는 일이 아니라, 창의적으로 제품을 만드는 일이기 때문이다.
   2. 제품을 만드는 행위에는 예술적인 면이 있다. 에이전트가 개별 구성요소를 직접 요리하는 비중이 줄어도, 최종 결과에 대한 책임은 사람에게 남는다.

2. 미슐랭 주방의 구성요소

   1. 주방의 라인 쿡(line cook)과 수 셰프(sous-chef)를 어떻게 배치하는지, 어떤 장비와 훈련을 제공하는지에 따라 음식의 결과가 달라진다.
   2. 식기세척기의 수와 라인 쿡의 비율까지 최종 품질에 영향을 준다. 에이전트가 담당하는 작업, 검증기, 자동화의 비율도 같은 방식으로 설계해야 한다.
   3. 주방에서 작업자가 걸려 넘어지는 장애물을 발견하면 모두가 다치지 않도록 동선을 고치듯, 코드베이스에서 에이전트가 반복해서 실수하는 원인을 환경 차원에서 제거해야 한다.

2. Cursor에서 발견한 병목과 검증 스킬

2.1. 수작업 성능 개선의 벽

1. 새로운 팀과 코드베이스

   1. 약 6개월 전 Lauren Tan은 Cursor가 SpaceX AI에 합류하기 전 Cursor 팀에 들어갔다. 당시에는 사용할 에이전트 스킬이 전혀 없었고, 새로운 코드베이스와 새로운 제품을 동시에 익혀야 했다.
   2. Cursor는 기존 Cursor IDE를 대체할 새로운 에이전트 창(agents window)을 만들고 있었다.

2. 성능 문제와 수동 작업

   1. Lauren Tan이 합류하기 전 에이전트 창에는 성능 문제가 많았고, 당시 매니저가 개선 작업을 요청했다.
   2. React 팀에서 일한 경험이 있었기 때문에 적합한 업무였지만, 실제로는 PR이 계속 들어오는 동안 앱 성능이 퇴행하는지 알 수 없는 상태였다.
   3. 초기 업무는 Chrome DevTools에서 성능을 살피고, 성능 트레이스(performance trace)를 실행하고, 힙 스냅샷(heap snapshot)을 찍는 수작업의 반복이었다.
   4. PR의 유입 속도와 수동 분석의 속도 차이가 커서, 끝없이 쌓이는 PR 벽처럼 느껴졌다.

2.2. 에이전트가 애플리케이션을 직접 검증하게 만들기

1. 검증 스킬에 대한 문제의식

   1. Lauren Tan은 수작업에 좌절한 뒤 “잠깐, 우리에게 에이전트가 있는데 나는 지금 뭘 하고 있지?”라는 생각을 했다.
   2. 에이전트가 애플리케이션을 직접 실행하고, 성능 트레이스를 수집하고, 트레이스를 이해하고, 병목(hot spot)을 찾고, 성능이 좋아지는 방향으로 반복 개선(hill climbing)하게 만들 수 있다고 판단했다.
   3. 이 발상은 에이전트가 코드를 작성하는 능력보다, 자신이 만든 결과를 실제 실행 환경에서 증명하는 능력이 중요하다는 방향 전환이었다.

2. 개인 생산성에서 조직 생산성으로

   1. Cursor와 xAI에서 보낸 6개월 동안 Lauren Tan의 생산성이 급격히 상승했다.
   2. 2,000개 PR은 생산량을 높이려는 단일 목표의 결과가 아니라, 스킬·도구·코드베이스를 바꾼 결과가 신뢰라는 하나의 축으로 모인 결과다.
   3. Lauren Tan은 자신이 모든 일의 병목이라는 사실을 깨달았다. 엔지니어로서 가진 지식을 에이전트 팀에 주입하면 자신이 모든 일을 막는 사람이 되지 않을 수 있었다.
   4. “나는 병목이고, 엔지니어로서 가진 모든 지식을 에이전트 팀에 전달해야 한다”는 생각이 작업 방식의 중심이 됐다.

3. 신뢰 그래프를 올라가는 단계

3.1. 1~5개의 에이전트에서 멈추는 이유

1. 베이비시팅 단계

   1. 에이전트를 처음 사용하는 사람은 1~5개 정도의 에이전트를 동시에 다루면서 각 채팅을 붙잡고 있어야 한다.
   2. 매 대화가 끝날 때까지 지켜보며 계속 방향을 수정하고, 에이전트가 올바른 일을 하도록 개입하고, 실수를 고쳐야 한다.
   3. 사람이 자리를 비우면 아무 일도 진행되지 않거나 에이전트가 엉뚱한 일을 한다.

2. 가장 빠져나오기 어려운 구간

   1. 이 단계가 어려운 까닭은 더 높은 신뢰 단계로 이동하는 구체적인 방법이 항상 분명하지 않기 때문이다.
   2. 1~5개에서 약 100개의 에이전트로 확장하지 못하는 근본 원인은 에이전트의 작업을 아직 신뢰하지 못하기 때문이다.

3.2. 신뢰 없이 병렬화하면 생기는 문제

1. 100개 에이전트의 역효과

   1. 신뢰가 없는 상태에서 서브에이전트나 클라우드 에이전트 100개를 띄우면, 허술한 PR이 쏟아진다.
   2. 성능 회귀(regression), 버그, 낮은 품질의 변경사항이 함께 프로덕션에 들어가며 팀 누구도 만족하지 못한다.
   3. 따라서 병렬화는 신뢰의 대체재가 아니라, 신뢰를 쌓은 뒤 얻는 결과다.

2. 신뢰를 만드는 질문

   1. 핵심 질문은 “에이전트를 어떻게 더 믿을 수 있는가?”다.
   2. Lauren Tan은 Cursor에서 성능 업무를 시작하며 검증의 필요성을 직접 경험했고, 그때부터 신뢰를 구체적인 시스템으로 만들기 시작했다.

4. 검증(Verification)의 층위와 Control Glass

4.1. 경험적 검증에서 형식 검증까지

1. 실행 가능한 검증 스킬

   1. 낮은 단계의 검증은 에이전트에게 애플리케이션 실행 방법을 가르치는 검증 스킬이다.
   2. Chrome DevTools Protocol 또는 유사한 디버깅 프로토콜을 이용해 애플리케이션을 디버깅하고, 성능 트레이스와 힙 스냅샷을 수집하게 한다.
   3. 이렇게 얻은 결과는 “코드가 작동한다”거나 “성능 기준을 충족한다”는 경험적 증거(empirical evidence)가 된다.

2. 형식 검증의 상한선

   1. 반대편에는 형식 방법(formal methods)을 이용해 애플리케이션의 비즈니스 로직 불변식(invariant)이 항상 참인지 검사하는 형식 검증이 있다.
   2. Lean이나 TLA+ 같은 언어로 애플리케이션이 항상 올바른 상태에 있는지 증명하는 방식이다.
   3. 형식 검증은 여전히 어려운 열린 문제이며, 실제로 형식 방법을 운용할 수 있는 팀은 많지 않다.
   4. 그럼에도 검증 스킬만으로도 매우 멀리 갈 수 있다. 모든 팀이 형식 검증을 도입할 필요는 없다.

4.2. Control Glass의 두 구성요소

1. 재현 가능한 CLI

   1. Cursor 에이전트 창 작업에서 Lauren Tan이 처음 만든 검증 스킬은 Control Glass였다.
   2. Control Glass는 Chrome DevTools Protocol을 통해 애플리케이션을 실행하고 트레이스를 수집하도록 에이전트를 가르친다.
   3. 첫 번째 구성요소는 CLI다. 에이전트가 언제나 같은 방식으로 애플리케이션을 실행하고, 트레이스와 작동 증거를 수집하게 해야 한다.
   4. 에이전트가 세션마다 임시 스크립트를 만들게 두면 세션마다 스크립트가 달라진다. 대신 스킬 디렉터리 안에 CLI를 넣고, 모든 에이전트가 같은 CLI를 사용하게 해야 한다.
   5. CLI는 다양한 사용 사례를 처리하고 애플리케이션을 정확히 실행하도록 지속적으로 투자하고 개선해야 한다.

2. 기능 지도(feature map)

   1. Slack에 사용자가 아주 작은 UI 조각이 찍힌 모호한 스크린샷과 물음표 세 개만 올리는 상황이 발생했다.
   2. 에이전트는 Control Glass로 애플리케이션을 실행할 수는 있었지만, 사용자가 무엇을 뜻하는지 알 수 없어 추측만 했다.
   3. 이를 해결하기 위해 사이트맵에서 영감을 받은 기능 지도를 만들었다.
   4. 기능 지도는 애플리케이션이 어떻게 작동하는지에 대한 ‘물질화된 기억’이다. 어떤 기능이 존재하는지, 사용자가 키보드 단축키나 클릭해야 하는 DOM 요소를 통해 어떻게 도달하는지, 각 기능이 무엇을 하는지를 기록한다.
   5. 기능 지도는 스킬 자체의 코드베이스인 스킬 디렉터리에 저장되며, 자동화가 그 내용을 유지한다.

4.3. CLI와 기능 지도가 만든 신뢰

1. 재현성과 이해의 결합

   1. CLI만 있으면 에이전트는 애플리케이션을 재현 가능하게 조작하고 트레이스를 수집할 수 있다.
   2. 기능 지도를 더하면 내부 사용자와 외부 사용자가 보내는 요청의 의도까지 이해할 수 있다.
   3. 에이전트가 작업 결과를 스스로 검증하는 능력은 신뢰를 만드는 데 매우 강력하다.

2. 팀의 핵심 인프라

   1. Control Glass 같은 제어·검증 스킬은 너무 유용해져서 팀의 핵심 인프라가 됐다.
   2. 핵심 인프라가 된 뒤에도 한 번 만들고 끝내지 않고 계속 유지보수한다.
   3. 검증은 단순히 “기능이 존재하는가”가 아니라, 실제 실행과 측정으로 작업 결과를 뒷받침하는 방식이다.

5. 정확성에서 품질까지 확장하는 스킬

5.1. 검증만으로는 충분하지 않은 이유

1. 정확성의 의미

   1. 검증은 기능이나 코드가 원하는 일을 하는지 확인한다. 예를 들어 결제 버튼이 실제로 카드를 결제하는지가 정확성의 질문이다.
   2. 검증은 기능이 작동한다는 경험적 증거를 주지만, 성능이나 코드 품질까지 자동으로 보장하지는 않는다.

2. 소프트웨어 엔지니어처럼 일하게 하는 스킬

   1. 성능·품질까지 다루려면 에이전트가 실제 소프트웨어 엔지니어의 작업 방식으로 일하도록 가르치는 스킬이 필요하다.
   2. Lauren Tan은 자신의 엔지니어링 경험에서 디버깅, 기능 개발, 프로토타이핑 등 여러 업무 흐름을 추출해 PAC 플러그인에 플레이북과 스킬로 담았다.
   3. 숙련된 엔지니어는 팀 저장소에 스킬을 모아 에이전트를 더 똑똑하게 만들 수 있다.

5.2. 검증과 작업 스킬의 결합

1. 정확성과 고품질의 동시 확보
   1. 작업 스킬과 검증 스킬을 결합하면 에이전트가 코드가 올바르게 작동하는지뿐 아니라 높은 품질로 작성했는지도 확인할 수 있다.
   2. 검증 스킬은 애플리케이션 성능에 관한 실제 수치, 통계, 텔레메트리(telemetry)를 수집하게 한다.
   3. 품질을 감각이나 사람의 기억에만 맡기지 않고 측정 가능한 기준으로 바꾸는 것이 신뢰의 핵심이다.

6. 에이전트 친화적인 코드베이스 설계

6.1. 코드베이스는 가장 강력한 기억이다

1. 기본값으로 올바르게 작동하는 구조

   1. 미래에 에이전트가 대부분의 코드를 작성한다고 진지하게 믿는다면, 코드베이스 자체가 올바른 일을 기본값으로 수행하도록 설계해야 한다.
   2. LLM은 컨텍스트 윈도우 안에 있는 패턴을 확장하는 경향이 강하다. 에이전트가 읽고 여는 파일은 컨텍스트에 들어가므로, 코드베이스는 에이전트가 참고하는 가장 중요한 기억이 된다.
   3. 에이전트는 매 PR마다 코드를 대대적으로 리팩터링하지 않는다. 이미 있는 패턴을 보고 다음 수준으로 확장한다.

2. 신뢰를 만드는 여러 층

   1. 코드베이스·아키텍처·데이터 구조는 나쁜 선택이 애초에 불가능하도록 만드는 가장 강한 층이다.
   2. 정적 분석(static analysis)은 린터(linter), 컴파일러 진단, 지속적 통합(CI)으로 반복 실수를 제약한다.
   3. 규칙(rules), Bugbot, 스킬은 에이전트에게 방향을 주는 안내 층이다. 다만 에이전트가 규칙을 읽지 못하거나, 에이전트를 조종하는 사용자가 무시할 가능성이 있어 강제력은 낮다.
   4. 스타일 가이드는 사람이 코드 리뷰에서 적용하는 최후의 층이다. PR 속도가 높아질수록 사람이 모든 변경 라인을 보고 기억에 의존해 댓글을 다는 방식은 큰 공백을 만든다.
   5. 스타일 가이드는 무엇이 아직 자동화되지 않았는지 찾는 출발점으로 활용하되, 핵심 규칙은 코드베이스·정적 분석·규칙·Bugbot·스킬로 옮겨야 한다.

6.2. 강제와 안내의 경계

1. 강제 가능한 규칙

   1. 반복되는 실수를 발견하면 린트 규칙이나 컴파일러 진단으로 바꿔야 한다.
   2. 더 좋은 방법은 데이터 구조나 알고리즘을 리팩터링해 실수 자체를 범주적으로 불가능하게 만드는 것이다.
   3. 코드베이스가 강제할수록 에이전트의 추론 능력이나 기억에 덜 의존하게 된다.

2. 강제력이 낮은 규칙

   1. 규칙·Bugbot·스킬은 중요한 안내지만, 에이전트가 여러 이유로 읽지 않을 수 있다.
   2. 사용자가 에이전트에 지시하면서 해당 규칙을 무시할 수도 있다.
   3. 따라서 안내만 쌓는 것보다, 가능한 항목을 코드와 정적 분석으로 내리는 작업이 중요하다.

7. Dune: Grokbot을 위한 에이전트 친화적 프레임워크

7.1. 지름길이 정답이 되도록 만들기

1. Cursor의 성능 교훈을 프레임워크로 추출

   1. Grokbot 코드베이스에는 Dune이라는 에이전트 친화적 프레임워크가 있다.
   2. Dune의 출발점에는 Cursor 에이전트 창에서 겪은 성능 문제가 있었다.
   3. 가장 중요한 원칙은 에이전트가 지름길을 좋아한다는 사실이다. 그렇다면 쉬운 길이 곧 올바른 길이 되도록 프레임워크를 설계해야 한다.

2. 사람에게는 답답하고 에이전트에게는 안전한 구조

   1. Dune은 사람이 작업하기에는 무엇을 할 수 있고 할 수 없는지가 너무 엄격해 다소 성가실 수 있다.
   2. 그러나 컨텍스트가 거의 없는 에이전트에게는 이런 잠금장치가 오히려 완벽한 환경이 된다.
   3. 앞으로 모든 코드 기여자가 엔지니어일 필요는 없다. 디자이너, 프로덕트 매니저, CEO도 코드베이스에 들어와 기능을 배포할 수 있으므로, 맥락이 부족한 사람의 에이전트도 기본적으로 좋은 결과를 내야 한다.

7.2. 나쁜 패턴은 바이러스처럼 번진다

1. 안티패턴의 복제

   1. 좋은 패턴이 복제되는 것과 마찬가지로, 기존 안티패턴도 에이전트에 의해 복제된다.
   2. 작은 우회책이나 그 우회책을 설명하는 주석 하나가 며칠 또는 몇 주 만에 코드베이스 전체로 퍼질 수 있다.
   3. 결국 우회책이 모든 에이전트의 사실상 표준 패턴이 되며, 유지보수하기 어려운 코드와 성능 문제를 만든다.

2. 정원과 바이브 코딩의 비유

   1. 코드베이스는 정원과 같다. 처음에는 무해해 보이는 잡초나 원치 않는 유기적 성장이 방치되면 전체를 뒤덮는다.
   2. 작은 우회책을 계속 복사하면 ‘바이브 코딩된(vibecoded)’ 코드베이스가 되고, 유지보수가 고통스러워지며 성능 문제도 쌓인다.
   3. 완벽한 에이전트 코드베이스는 인간에게는 지나치게 잠겨 있고, 에이전트에게는 매우 관습적이며 표준화돼 있어 무해해 보이는 나쁜 패턴조차 금지하는 구조다.

7.3. 코드 주석을 금지한 이유

1. 사람에게 유용했던 주석의 양면성

   1. 사람은 엣지 케이스, 우회책, 동료에게 남길 메모, 특히 까다로운 코드 영역을 위해 주석을 작성한다.
   2. Lauren Tan도 처음에는 에이전트가 주석을 남기는 것이 반드시 나쁘지는 않다고 생각했다. 사람도 주석을 남겼기 때문이다.

2. 에이전트 주석의 실제 역할

   1. Cursor 코드베이스에서 에이전트가 남긴 주석은 문제를 해결하지 못한 이유를 정당화하는 용도로 쓰이는 경우가 많았다.
   2. 주석으로 실제 문제를 덮고 반창고 같은 단기 해결책을 남긴 뒤, 그 패턴을 다른 코드에 전파했다.
   3. Dune은 이 이유로 코드 주석을 금지했다. 주석이라는 나쁜 패턴을 에이전트가 복사하지 못하게 하려는 선택이다.

7.4. ‘정원사’ 역할

1. 전담 관리자의 필요성

   1. 모든 팀에는 코드베이스의 정원사(gardener) 역할이 필요하다.
   2. 정원사가 잡초와 해충이 퍼지기 전에 싹을 자르듯, 코드베이스에 들어온 안티패턴을 초기에 발견하고 전파를 차단해야 한다.
   3. Lauren Tan은 “정원을 잘 아는 편은 아니지만”이라는 식으로 농담하면서도, 원치 않는 성장이 코드베이스에 스며든다는 핵심 비유를 유지한다.

2. 정원사가 던지는 질문

   1. 에이전트가 반복해서 만든 나쁜 패턴은 무엇인가?
   2. 그 패턴을 린트 규칙으로 막을 수 있는가?
   3. 이미 퍼진 코드를 정리해 다음 에이전트가 복사해도 괜찮은 상태로 되돌렸는가?

8. Dune의 운영 원칙과 구체적인 경계

8.1. 세 가지 운영 원칙

1. 기술 부채 삭제

   1. 이미 존재하는 기술 부채를 삭제한다.
   2. 기술 부채를 계속 남겨둔 채 새 기능만 추가하면 에이전트가 그 부채를 정상 패턴으로 인식한다.

2. 하나의 포장된 길(single paved path)

   1. 대부분의 축복받은 패턴(blessed pattern)에 하나의 관습적인 구현 경로를 둔다.
   2. 구현 방법이 여러 개면 에이전트가 선택을 추측해야 하므로, 코드베이스·CI·린트 규칙에 충분한 안내를 넣어 한 경로로 유도한다.

3. 나쁜 패턴을 보면 린트 규칙을 만든다

   1. 나쁜 패턴을 발견했을 때 즉시 전부 정리하지 못하더라도 린트 규칙부터 작성하면 추가 확산을 멈출 수 있다.
   2. 린트 규칙은 문제를 완전히 해결하지 않지만, 최소한 출혈을 막는다.
   3. 이후 에이전트에게 기존 안티패턴을 정리하게 해, 다음 작업자가 복사해도 괜찮은 상태를 지속적으로 유지한다.

8.2. Dune의 구조적 관습

1. 코드 위치와 의존성

   1. Dune 애플리케이션은 코드가 어디에 있어야 하는지, 서로 어떻게 import해야 하는지에 관한 관습을 강하게 갖는다.
   2. 기능은 한 폴더에 함께 배치(collocation)한다.
   3. React 코드의 진입점(entry point)은 라우트처럼 작동하며, 애플리케이션에서 기능으로 들어가는 경로를 결정한다.

2. Grokbot 애플리케이션의 주요 구성

   1. Grokbot 애플리케이션에는 그래프봇에 나타나는 트랜스크립트 카드(transcript card)가 있다.
   2. Grokbot 가상 머신에서 실행되는 호스트(host)가 있다.
   3. 전체 애플리케이션을 구동하는 클라이언트(client)가 있다.
   4. 각 구성요소 사이에는 명확하고 엄격한 경계가 있다.

8.3. Electron 렌더러의 성능을 구조로 보장하기

1. 메인 프로세스와 렌더러 스레드의 분리

   1. Electron의 메인 프로세스에서 실행되는 코드는 렌더러 스레드에서 실행되면 안 된다.
   2. Cursor 에이전트 창에서 코드가 실수로 렌더러에 import돼 UI를 느리게 만든 경험이 이 경계를 만들었다.
   3. 렌더러는 부드러운 UI를 유지해야 하므로 긴 작업(long task)을 실행해서는 안 된다.

2. 프레임 속도 기준

   1. 초당 60프레임을 유지하려면 작업 하나가 16밀리초보다 길어지면 안 된다.
   2. 초당 120프레임을 유지하려면 기준이 8밀리초로 더 엄격해진다.
   3. 렌더러는 일을 한 번에 몰아서 처리하지 않고 작은 단위로 쪼개 실행해야 한다.

3. 범주적 차단

   1. Dune은 import 그래프와 의존성 그래프로 메인 프로세스와 렌더러 사이의 경계를 강제한다.
   2. 성능을 악화시키는 특정 패턴을 사람의 리뷰 코멘트에만 맡기지 않고 아키텍처에서 범주적으로 제거한다.

9. 코드베이스를 팀의 기억으로 만드는 방법

9.1. 스타일 가이드에서 실행 가능한 시스템으로

1. 암묵지를 코드로 추출하기

   1. 숙련된 엔지니어가 가진 팀의 암묵지(tribal knowledge)는 스타일 가이드나 코드 리뷰 코멘트에만 머물러서는 안 된다.
   2. 그 지식을 프레임워크와 코드베이스에 인코딩하면, 다음 에이전트가 자동으로 참고하는 실행 가능한 기억이 된다.
   3. 사람이 매 PR에서 같은 설명을 반복하는 대신, 시스템이 올바른 경로를 제공하게 된다.

2. 깨끗한 상태의 스냅샷

   1. 코드베이스는 에이전트가 확장해야 하는 원하는 상태의 물질화된 스냅샷이다.
   2. 다음 에이전트가 들어왔을 때 현재 패턴을 계속 유지할 가능성이 높도록 코드베이스를 깨끗하게 만들어야 한다.
   3. “에이전트가 이 코드를 복사해도 기쁘겠는가?”라는 질문이 지속적인 관리 기준이 된다.

9.2. 신뢰 층의 누적 효과

1. 저맥락 에이전트도 좋은 결과를 내는 환경

   1. 코드베이스, 린트 규칙, 컴파일러 진단, 규칙, Bugbot, 스킬이 한꺼번에 작동하면 코드 작성 자체가 강하게 잠긴다.
   2. Grokbot 코드베이스처럼 나쁜 코드를 쓰기 거의 불가능한 환경이라면, 맥락이 적은 에이전트나 추론 능력이 높지 않은 에이전트도 좋은 코드를 작성할 수 있다.

2. 미슐랭 주방의 반복 개선

   1. 숙련된 조리사만 잘하는 주방이 아니라, 장비·동선·훈련·규칙이 모든 조리사가 올바른 행동을 기본으로 하게 만드는 주방을 만든다.
   2. 누군가 반복해서 걸려 넘어지는 문제가 보이면 개인의 주의력을 탓하지 않고 주방의 장애물을 고친다.
   3. 코드베이스도 같은 방식으로 에이전트가 넘어지는 원인을 환경에서 제거해야 한다.

10. Grokbot과 Cursor가 만드는 외부 루프

10.1. Grokbot은 외부 루프를 담당한다

1. 도구를 연결하는 바깥쪽 루프

   1. Grokbot은 Slack, Datadog, Sentry, PlanetScale 같은 다양한 커넥터를 연결할 수 있다.
   2. 여러 서비스의 신호를 한곳에 모아 에이전트가 다음 행동을 결정하는 외부 루프(outer loop)를 만든다.
   3. 모든 것을 하나의 거대한 ‘회사 두뇌(company brain)’로 만들 필요는 없다. 에이전트는 도구를 잘 사용하므로 필요한 도구를 연결하는 것으로 충분하다.

2. 자동화 루틴

   1. Grokbot 루틴은 Slack 스레드나 Sentry 알림을 구독할 수 있다.
   2. 특정 사건이 발생하면 클라우드 에이전트를 자동으로 시작할 수 있다.
   3. 코드베이스·규칙·스킬을 갖춘 상태에서 외부 이벤트가 들어오면, Grokbot이 그 이벤트에 반응해 작업을 열고 PR을 만드는 흐름이 가능해진다.

10.2. 자동화가 팀 전체로 확장되는 방식

1. Cursor 자동화와 SDK

   1. Cursor 자동화와 SDK로 추가 봇을 만들고, 이미 마련한 에이전트 인프라를 재사용할 수 있다.
   2. 동일한 검증·품질·코드베이스 규칙을 여러 봇이 공유하므로 복잡한 작업도 일관된 기준으로 처리한다.

2. 실제 자동화 사례

   1. 버그 리포트를 자동으로 재현한다.
   2. 재현 결과를 바탕으로 풀 리퀘스트를 자동으로 연다.
   3. 이런 자동화가 한 팀의 반복 업무를 줄이고 전체 팀에 가치를 더한다.
   4. 각각의 장치가 따로 작동하는 것이 아니라, 코드베이스·정적 분석·규칙·스킬·외부 이벤트 루프가 서로 누적되면서 효과가 커진다.

11. 최종 실행 순서: 에이전트가 자유롭게 일할 때까지

11.1. 에이전트를 교정할 때 찾아야 할 지점

1. 다섯 가지 질문

   1. 에이전트를 교정하거나 개입해야 할 때, 문제가 코드베이스·아키텍처·데이터 구조에 있는지 먼저 묻는다.
   2. 구조로 막을 수 없다면 정적 분석으로 실수를 탐지하거나 차단할 수 있는지 본다.
   3. 그다음 규칙, Bugbot, 스킬로 에이전트를 안내하는 방법을 찾는다.
   4. 코드 품질과 실제 작업 방식은 별도의 스킬로 가르쳐야 한다.
   5. 스타일 가이드에만 남은 지식이 있다면 자동화할 후보로 삼는다.

2. 권장되는 순서

   1. 데이터 구조·알고리즘·아키텍처·코드베이스를 바꿔 패턴을 범주적으로 불가능하게 만든다.
   2. 정적 분석으로 반복 실수를 검출하고 CI에서 멈춘다.
   3. 규칙·Bugbot·스킬을 겹겹이 올려 올바른 경로를 안내한다.
   4. 검증 스킬과 품질 스킬로 실제 작동·성능·코드 품질의 증거를 수집한다.
   5. 환경 전체를 신뢰할 수 있을 때 에이전트를 자유롭게 병렬화한다.

11.2. 병렬화와 팀 생산성

1. 신뢰 그래프의 상단

   1. 필요한 환경을 충분히 마련하면 에이전트를 더 믿고 작업을 병렬화할 수 있다.
   2. 한 엔지니어의 개인 생산성만 높이는 것이 아니라, 팀의 모든 엔지니어와 모든 빌더가 같은 기반 위에서 고품질 코드를 만들게 된다.

2. 마지막 핵심 메시지

   1. “환경을 충분히 신뢰하게 되면 에이전트가 자유로워진다”는 결론이다.
   2. 이것은 비밀스러운 요령이 아니라 많은 하드워크의 결과다.
   3. Lauren Tan은 각 팀이 자신의 미슐랭 주방을 만들고, 에이전트가 잘할 수 있는 조건을 직접 설계하길 권한다.

주요 발언 모음

“지난달 나는 프로덕션에 풀 리퀘스트 2,000개를 반영했다.”

“에이전트를 위한 환경을 정말 정말 잘 설정하면, 개인용 또는 팀용 소프트웨어 공장처럼 보이는 것을 만들 수 있다.”

“나는 소프트웨어 공장이라는 표현을 좋아하지 않는다. 미슐랭 주방이라는 비유가 더 좋다.”

“나는 병목이고, 엔지니어로서 가진 모든 지식을 에이전트 팀에 전달해야 한다.”

“신뢰가 없는데 서브에이전트나 클라우드 에이전트 100개를 띄우면, 허술한 풀 리퀘스트와 회귀와 버그가 쏟아질 것이다.”

“에이전트가 스스로 작업을 검증할 수 있는 능력은 신뢰를 만드는 데 매우 강력하다.”

“에이전트는 지름길을 좋아한다. 그렇다면 지름길이 에이전트에게 올바른 길이 되도록 프레임워크를 설계하면 된다.”

“코드베이스는 에이전트가 확장해야 할 상태의 물질화된 스냅샷이다.”

“나쁜 패턴을 보면 본능적으로 그 패턴에 대한 린트 규칙을 작성해야 한다.”

“이것은 비밀이 아니다. 많은 하드워크다.”

핵심 데이터 & 수치

• 월간 PR 2,000개: Lauren Tan이 지난달 프로덕션에 반영했다고 밝힌 풀 리퀘스트 수다.
• 약 6개월: Cursor 합류부터 Cursor와 xAI에서 검증·스킬·코드베이스를 발전시킨 기간이다.
• 1~5개 에이전트: 각 채팅을 지켜보고 계속 교정해야 하는 초기 베이비시팅 구간이다.
• 약 100개 에이전트: 신뢰가 없을 때 병렬화하면 허술한 PR·회귀·버그를 대량으로 만들 수 있는 규모다.
• 16밀리초: 초당 60프레임 UI에서 렌더러 작업 하나가 넘지 않아야 할 기준이다.
• 8밀리초: 초당 120프레임 UI에서 렌더러 작업 하나가 넘지 않아야 할 기준이다.
• 2,000개는 목표가 아니었음: 높은 처리량은 단일 목표가 아니라 신뢰 인프라가 누적된 결과다.

핵심 요약 (20줄)

1. Lauren Tan은 지난달 풀 리퀘스트 2,000개를 프로덕션에 반영했다고 밝혔다.
2. 높은 처리량의 핵심은 에이전트가 자리를 비운 사람 대신 높은 품질을 유지한다는 신뢰다.
3. 소프트웨어 생산 시스템은 조립 라인보다 사람·도구·훈련이 맞물린 미슐랭 주방에 가깝다.
4. Cursor 합류 초기에 성능 트레이스와 힙 스냅샷을 수동으로 수집하는 일은 끝없는 PR 벽이 됐다.
5. 에이전트가 애플리케이션을 실행하고 병목을 찾도록 검증 스킬을 만들어 수작업 병목을 줄였다.
6. 1~5개의 에이전트를 계속 지켜봐야 하는 단계는 신뢰를 쌓기 전 가장 벗어나기 어렵다.
7. 신뢰 없이 100개의 서브에이전트를 띄우면 허술한 PR과 회귀와 버그가 쏟아진다.
8. Control Glass는 Chrome DevTools Protocol로 애플리케이션 실행과 트레이스 수집을 재현한다.
9. 스킬 디렉터리의 CLI는 세션마다 다른 임시 스크립트가 생기는 문제를 막는다.
10. 기능 지도는 애플리케이션 기능과 사용자 접근 경로를 저장하는 물질화된 기억이다.
11. 검증은 기능의 정확성을 증명하지만 성능과 코드 품질까지 보장하지는 않는다.
12. 디버깅·기능 개발·프로토타이핑 플레이북을 팀 스킬 저장소에 모으면 에이전트의 작업 품질이 높아진다.
13. 코드베이스는 에이전트가 가장 쉽게 복제하는 패턴을 담은 강력한 기억이다.
14. 반복 실수는 린트와 CI로 강제하고, 가능하면 데이터 구조와 아키텍처에서 불가능하게 만들어야 한다.
15. Dune은 에이전트의 쉬운 지름길이 올바른 경로가 되도록 잠근 Grokbot 프레임워크다.
16. 작은 우회책과 나쁜 주석은 에이전트에 의해 며칠 또는 몇 주 만에 코드베이스 전체로 번진다.
17. Dune은 문제를 덮는 반창고 주석의 전파를 막기 위해 코드 주석을 금지했다.
18. 메인 프로세스와 렌더러의 의존성 경계는 60프레임과 120프레임 UI 성능을 지키도록 강제된다.
19. Grokbot은 Slack·Datadog·Sentry·PlanetScale 신호로 외부 루프를 만들고 클라우드 에이전트를 자동 실행한다.
20. 코드베이스·정적 분석·규칙·Bugbot·스킬을 누적하면 팀 전체가 에이전트를 자유롭게 병렬화할 수 있다.

결론 및 시사점

1. 처리량을 먼저 목표로 삼지 말고 신뢰 인프라를 먼저 만든다: PR 수를 늘리려는 압박보다 에이전트가 올바르게 일했다는 실행 증거를 확보해야 한다.
2. 교정은 환경 개선 티켓으로 바꾼다: 같은 실수를 두 번 발견하면 사람의 주의력에 의존하지 말고 린트·CI·데이터 구조·아키텍처 중 가장 강한 층에 규칙을 내린다.
3. 검증과 품질을 분리해 설계한다: 기능이 동작하는지 확인하는 검증 스킬과 성능·코드 품질을 높이는 작업 스킬을 함께 운영한다.
4. 코드베이스를 복사 가능한 모범 답안으로 유지한다: 에이전트는 기존 패턴을 확장하므로, 나쁜 패턴을 남겨두는 일은 미래의 자동화에 나쁜 지시를 내리는 것과 같다.
5. 단일 경로와 엄격한 경계를 선호한다: 선택지가 많을수록 에이전트의 추측이 늘어나므로, 표준화된 폴더·import·의존성 규칙으로 올바른 지름길을 만든다.
6. 외부 이벤트와 에이전트 작업을 연결한다: Slack 스레드·Sentry 알림·Datadog 신호를 자동화 루틴으로 연결하면 에이전트가 버그 재현과 PR 생성을 먼저 수행하게 할 수 있다.
7. 에이전트를 자유롭게 하는 일은 사람의 책임을 없애지 않는다: 사람은 최종 결과, 주방의 설계, 품질 기준, 잡초 제거를 계속 책임져야 한다.