Lauren Tan이 AI 에이전트로 매달 수천 개의 PR을 안전하게 반영하는 방법

URL: https://www.youtube.com/watch?v=5tdMgKkX5dU
날짜: 2026-10-04
채널: latentspacepod
원제: [한영자막] 팟캐스트 풀버전 - SpaceX에서 매달 수천 개의 PR을 반영하는 방법을 알아봅니다 | Cursor & Grok Bot 개발자 Lauren Tan(poteto)

📌 핵심 질문 / AI 에이전트에게 어떻게 신뢰를 부여할 것인가

Lauren Tan은 SpaceX AI의 Grok Bot을 만들며 한 달에 2,000개의 Pull Request(PR)를 프로덕션에 반영했다. 핵심은 에이전트를 계속 지켜보는 능력이 아니라, 에이전트가 사람이 자리를 비운 상태에서도 높은 품질의 코드를 만들고 스스로 검증하도록 코드베이스·검증 도구·정적 분석·규칙·스킬을 설계하는 신뢰 엔지니어링(Trust Engineering)이다.

• 에이전트가 애플리케이션을 직접 실행하고 성능 트레이스·Heap Snapshot 같은 증거를 수집하게 만든다.
• 코드베이스에 나쁜 패턴이 들어오는 것 자체를 아키텍처·데이터 구조·의존성 경계로 불가능하게 만든다.
• 정적 분석(Static Analysis), CI, 규칙(Rules), Bugbot, Skills를 겹겹이 배치해 인간의 병목을 없앤다.
• Grok Bot을 외부 신호를 받아 Cloud Agent와 자동화를 시작하는 Outer Loop로 연결한다.

소프트웨어를 조립라인에서 대량 생산하는 ‘소프트웨어 공장(Software Factory)’보다, 각 조리사·수셰프·장비·훈련·식기세척기의 배치가 결과를 좌우하는 미슐랭 주방(Michelin kitchen)이 더 정확한 비유다. 에이전트가 재료를 직접 조리하더라도 최종 제품과 주방의 설계 책임은 엔지니어에게 남는다.

1. 2,000개 PR이라는 결과보다 먼저 바꾼 것

1.1. 생산량 목표가 아니라 병목 제거에서 시작한 변화

1. Lauren Tan의 역할과 출발점

   1. SpaceX AI와 Grok Bot: X에서 poteto라는 이름으로 알려진 Lauren Tan은 Grok Bot을 만드는 SpaceX AI에서 일한다. Cursor가 SpaceX AI의 일부가 되기 전, Cursor에 합류한 지 약 6개월이 지난 시점부터 쌓은 경험이 출발점이다.
   2. 새 코드베이스와 새 제품: Cursor에 처음 들어갔을 때는 에이전트 스킬이 전혀 없었고, 새 코드베이스에서 기존 Cursor IDE를 대체할 새로운 Agents Window를 만들고 있었다.
   3. React 경험의 연결: 합류 전 React 팀에서 성능 작업을 했기 때문에, 당시 성능 문제가 많던 Agents Window를 돕는 일이 자연스러운 배정이 됐다.

2. 수동 성능 분석이 만든 벽

   1. 끝없이 들어오는 PR: PR이 합쳐지는 속도가 너무 빨라서, 각각의 변경이 애플리케이션 성능을 퇴보시키는지 파악하기 어려웠다. PR의 벽이 계속 높아지는 동안 기존 방식으로는 추적할 수 없었다.
   2. 반복적인 도구 사용: 초기 업무는 Chrome DevTools를 열고, Performance Trace를 만들고, Heap Snapshot을 찍고, 결과를 사람이 읽는 과정의 반복이었다.
   3. 문제의 재정의: 에이전트를 쓰면서도 사람이 모든 검사를 수행하는 것은 모순이었다. “에이전트가 애플리케이션을 직접 실행하고, 트레이스를 수집하고, Hot Spot을 찾고, 성능을 더 좋은 방향으로 Hill Climbing할 수 없을까?”라는 질문이 검증 스킬의 출발점이 됐다.

1.2. 생산성 급증은 누적된 환경 변경의 결과

1. 2,000개 PR은 처음부터 세운 목표가 아니었다

   1. 한 달에 2,000개 PR을 배포하겠다는 KPI를 먼저 정한 것이 아니다.
   2. 검증 스킬, 도구, 코드베이스 변경을 하나씩 쌓아 올린 결과가 ‘신뢰’라는 하나의 축으로 수렴했고, 그 결과 생산성이 급격히 상승했다.

2. 엔지니어가 병목이라는 자각

   1. Lauren Tan은 자신이 모든 결정을 직접 쥐고 있는 병목이라고 판단했다.
   2. 엔지니어로서 가진 지식과 판단 기준을 에이전트 팀에 주입하면 모든 일을 자신이 통과시켜야 하는 구조를 없앨 수 있다고 봤다.
   3. 목표는 사람을 없애는 것이 아니라 한 사람의 지식이 여러 에이전트와 팀 구성원에게 재사용되는 환경을 만드는 것이다.

2. 신뢰 그래프: 에이전트 수를 늘리기 전에 검증을 늘린다

2.1. 1~5개 에이전트 단계가 가장 빠져나오기 어렵다

1. 베이비시팅(Babysitting) 단계

   1. 에이전트 한두 개에서 다섯 개를 다룰 때는 모든 채팅과 대화를 지켜보며 계속 방향을 수정한다.
   2. 사람이 자리를 비우면 아무 일도 진행되지 않거나, 에이전트가 잘못된 방향으로 진행한다.
   3. Pair Programming에서 동료의 모든 코드를 옆에서 지켜보며 질문하는 것과 비슷하다. 초기 수동 관찰은 실패 지점을 알아내는 데 유용하지만 영원한 운영 방식은 아니다.

2. 신뢰가 없는 병렬화의 실패

   1. 신뢰가 없는 상태에서 100개의 Sub-Agent나 Cloud Agent를 띄우면 생산량이 아니라 Slop PR이 쏟아진다.
   2. 회귀(Regression), 버그, 잘못된 변경이 함께 배포되고 사람이 결과를 다시 수습해야 한다.
   3. 1~5개에서 100개로 뛰는 비결은 에이전트 수를 먼저 늘리는 것이 아니라 결과를 믿을 수 있도록 환경을 바꾸는 것이다.

2.2. 검증에는 실용적인 층과 형식적인 층이 있다

1. 검증 스킬(Verification Skills)

   1. 에이전트가 애플리케이션을 실행하고 Chrome DevTools Protocol(CDP) 또는 디버깅에 맞는 다른 프로토콜을 사용하도록 가르친다.
   2. 성능 트레이스, Heap Snapshot, 디버깅 결과를 수집해 코드가 실제로 동작하고 성능 기준을 통과했다는 경험적 증거(Empirical Evidence)를 남긴다.
   3. 기능이 요구한 일을 수행하는지 직접 실행해 확인하므로 “체크아웃 버튼이 장바구니를 실제로 결제하는가?” 같은 정확성(Correctness) 질문에 답한다.

2. 형식 검증(Formal Verification)

   1. 더 높은 난도의 층에는 Formal Method, Lean, TLA+ 등이 있다.
   2. 비즈니스 로직의 불변식(Invariant)이 항상 참인지, 애플리케이션이 언제나 올바른 상태에 있는지를 수학적으로 검증한다.
   3. 대부분의 팀이 형식 검증까지 도입하기는 어렵지만, 실용적인 검증 스킬만으로도 신뢰 그래프를 상당히 위로 올릴 수 있다.

3. Control 스킬: 에이전트가 자기 작업을 검증하게 만드는 장치

3.1. 반복 가능한 CLI가 검증의 바닥을 만든다

1. Control/Verification Skill의 두 구성요소

   1. 첫째는 CLI다. 에이전트가 매 세션마다 제각각의 임시 스크립트를 만들지 않고 스킬 디렉터리에 있는 동일한 CLI를 반복 사용한다.
   2. CLI는 애플리케이션을 재현 가능하게 실행하고 트레이스를 수집하며, 코드가 제대로 작동하고 성능 기준을 충족하는지 증거를 수집한다.
   3. 다양한 사용 사례와 실행 조건을 처리하려면 CLI 자체에도 지속적으로 투자해야 한다.

2. 임시 스크립트와 전용 CLI의 차이

   1. 매번 만들어지는 스크립트는 세션마다 달라져 결과 비교가 어렵다.
   2. 전용 CLI는 실행 절차와 출력 형식을 고정해 여러 에이전트가 같은 방식으로 애플리케이션을 관찰하게 한다.
   3. 반복 가능한 측정이 생기면 “동작한다”라는 주장과 “트레이스로 확인됐다”라는 증거를 구분할 수 있다.

3.2. Feature Map은 애매한 사용자 신고를 실행 가능한 기억으로 바꾼다

1. 작은 스크린샷과 물음표 세 개의 문제

   1. Slack에 사용자가 아주 작은 UI 조각과 물음표 세 개만 올리는 상황이 있었다.
   2. 애플리케이션을 실행할 수 있더라도 에이전트는 사용자가 어떤 기능을 가리키는지 알 수 없어 추측할 수밖에 없었다.

2. Feature Map의 구성

   1. Feature Map은 애플리케이션의 기능, 사용자가 그 기능에 도달하는 경로, 각 기능의 동작을 정리한 애플리케이션 지도다.
   2. 키보드 단축키, 클릭해야 하는 DOM Element, 화면의 진입 경로와 기능의 역할을 기록한다.
   3. 사이트맵(Sitemap)에서 영감을 얻은 ‘Materialized Memory’이며 스킬 디렉터리와 코드베이스 안에 저장된다.
   4. 자동화가 Feature Map을 계속 유지하므로 제품이 바뀌어도 지도가 낡지 않는다.

3. CLI와 Feature Map의 결합 효과

   1. CLI가 애플리케이션을 재현 가능하게 조작하고 트레이스를 수집한다.
   2. Feature Map이 내부·외부 사용자의 모호한 요청을 실제 기능과 조작 경로로 번역한다.
   3. 에이전트는 무엇을 실행하고 무엇을 관찰해야 하는지 동시에 알게 되어 스스로 결과를 검증할 수 있다.
   4. Control 스킬은 팀의 Critical Infrastructure가 됐고, 한 번 만들고 끝나는 도구가 아니라 계속 유지보수하는 기반 시설이 됐다.

3.3. 검증과 품질을 분리한 뒤 다시 결합한다

1. 검증은 정확성에 답한다

   1. 기능이 요구사항을 수행하는지, 버튼이 올바른 동작을 하는지 실제 애플리케이션에서 확인한다.
   2. 단순히 코드를 읽고 그럴듯하다고 결론 내리지 않고 실행 결과를 증거로 삼는다.

2. 품질은 엔지니어링 스킬이 답한다

   1. 성능과 코드 품질은 기능이 동작한다는 사실만으로 보장되지 않는다.
   2. Lauren Tan은 디버깅, 기능 개발, 프로토타이핑 같은 작업별 Playbook과 Skill을 모은 Pystack 플러그인을 만들었다.
   3. 숙련된 엔지니어는 팀 저장소에 스킬을 기여해 각 에이전트가 원하는 방식으로 코드를 작성하도록 경험과 관행을 전달한다.
   4. 두 스킬을 결합하면 에이전트가 “정확하게 작동하는가”와 “높은 품질로 구현됐는가”를 함께 확인한다.

4. 신뢰를 쌓는 다섯 겹의 방어선

4.1. 가장 강한 방어선은 코드베이스 자체다

1. 코드베이스는 에이전트의 가장 강력한 기억이다

   1. LLM은 컨텍스트 윈도우에 들어온 기존 패턴을 새 코드에 확장하는 경향이 있다.
   2. 에이전트가 읽고 열어본 파일은 컨텍스트가 되므로 코드베이스의 현재 상태가 다음 변경의 재료가 된다.
   3. 에이전트는 모든 PR에서 전체 코드를 재설계하지 않고 이미 존재하는 패턴을 이어 붙인다.

2. 실수를 ‘불가능’하게 만들기

   1. 같은 실수를 반복해서 고쳐야 한다면 Lint Rule로 금지할 수 있다.
   2. 더 좋은 방법은 아키텍처·알고리즘·데이터 구조를 리팩터링해 잘못된 패턴이 구조적으로 들어올 수 없게 만드는 것이다.
   3. 사람이 매 PR의 같은 실수를 발견하는 대신 시스템이 처음부터 선택지를 제거한다.

4.2. 정적 분석과 자동 규칙은 반복되는 교정을 시스템화한다

1. 정적 분석(Static Analysis)

   1. Linter, Compiler Diagnostic, Continuous Integration(CI)은 코드베이스에 적용되는 제약과 가이드다.
   2. 에이전트가 같은 실수를 반복하면 인간의 설명을 반복하기보다 정적 분석으로 오류를 자동 검출한다.

2. 규칙·Bugbot·Skills

   1. Rules와 Bugbot은 에이전트가 따라야 할 작업 지침과 코드 리뷰 자동화를 제공한다.
   2. Skills는 작업 절차와 도메인 지식을 제공해 에이전트가 더 나은 구현 경로를 선택하게 한다.
   3. 이 층은 강력하지만 절대적인 강제는 아니다. 에이전트가 규칙 읽기를 잊거나 사용자가 지침을 무시할 가능성이 있다.

3. 스타일 가이드와 사람의 리뷰

   1. 스타일 가이드는 인간 코드 리뷰에서 가장 쉽게 적용되는 층이다.
   2. 자동화되지 않은 스타일 규칙에만 의존하면 사람이 모든 변경 라인을 읽고 모든 규칙을 기억해야 한다.
   3. PR의 양이 커질수록 스타일 가이드는 신뢰 시스템의 큰 구멍이 된다. 사람의 리뷰는 마지막 층이어야 한다.

5. Dune: 에이전트가 지름길을 택해도 정답에 도착하는 프레임워크

5.1. 가장 짧은 경로를 올바른 경로로 만든다

1. Dune의 목적

   1. Dune은 Grok Bot을 구동하는 에이전트 친화적 클라이언트 프레임워크다.
   2. Cursor Agents Window에서 겪은 성능 문제와 회귀를 교훈으로 삼아 에이전트가 코드를 작성하는 방식에 맞춰 설계했다.
   3. 핵심 원칙은 에이전트가 지름길을 좋아한다는 사실을 인정하고 가장 쉬운 길이 올바른 길이 되도록 만드는 것이다.

2. 인간에게는 답답하지만 에이전트에게는 안전한 구조

   1. Dune은 사람이 자유롭게 코드를 쓰기에는 제한적이고 귀찮은 프레임워크다.
   2. 대신 규칙과 관례가 강해서 컨텍스트가 부족한 에이전트도 기본값으로 좋은 코드를 작성할 수 있다.
   3. 디자이너, Product Manager, CEO처럼 코드베이스를 깊이 모르는 사람도 에이전트를 통해 기능을 기여할 수 있다.

5.2. 기능을 한곳에 모으고 경계를 강제한다

1. Dune의 명시적인 구성요소

   1. Feature는 하나의 폴더에 함께 배치해 기능에 기여하는 코드의 탐색 경로를 짧게 만든다.
   2. Entry Point는 React 코드에서 Route와 비슷한 역할을 하며 기능 진입점을 결정한다.
   3. Transcript Card는 Grok Bot 화면의 채팅 카드 구성요소다.
   4. Host는 Grok Bot Virtual Machine에서 실행되고 Client는 전체 Dune 애플리케이션을 구동한다.

2. Import와 프로세스 경계

   1. Electron의 Main Process/Main Thread에서 실행돼야 하는 코드는 Renderer Thread에서 실행할 수 없게 엄격한 경계를 둔다.
   2. Dune은 Import Dependency Graph를 이용해 이 경계를 CI와 구조 차원에서 강제한다.
   3. Cursor Agents Window에서 무거운 코드가 Renderer Thread로 끌려 들어가던 문제가 계기가 됐다.

3. 프레임 예산을 구조에 반영한다

   1. 60 FPS를 유지하려면 한 프레임을 16밀리초 안에 그려야 한다.
   2. 120 FPS라면 프레임당 허용 시간은 8밀리초로 줄어든다.
   3. 무거운 계산이나 I/O가 Renderer Thread로 들어오면 긴 작업(Long Task)이 생기고 프레임이 손실되며 UI가 끊긴다.
   4. Dune은 이런 성능 회귀 패턴을 사후 리뷰가 아니라 아키텍처 경계로 분류해 처음부터 제거한다.

6. 코드베이스 정원과 Gardener의 역할

6.1. 작은 우회가 에이전트에 의해 바이러스처럼 퍼진다

1. 코드베이스는 정원이다

   1. 처음에는 무해해 보이는 Workaround도 에이전트가 기존 패턴으로 인식하면 반복해서 복사한다.
   2. 며칠 또는 몇 주가 지나면 우회가 코드베이스 전체로 번지고 유지보수하기 힘든 Vibe-Coded Codebase와 성능 문제가 남는다.

2. 정원의 상태를 다음 복사에 적합하게 유지한다

   1. 완벽한 에이전트 코드베이스는 인간에게 코딩하기 귀찮을 정도로 잠겨 있다.
   2. 관례와 표준화가 충분해 무해해 보이는 안티패턴도 허용하지 않는다.
   3. 다음 에이전트가 현재 코드를 그대로 복사해도 만족스러운 상태가 기준이다.

6.2. 주석 금지는 반창고를 정답으로 굳히지 않기 위한 조치다

1. 에이전트 주석의 위험

   1. 사람은 엣지 케이스, Workaround, 동료에게 남길 복잡한 맥락을 기록하기 위해 주석을 쓴다.
   2. 하지만 Cursor 코드베이스에서 에이전트는 주석을 실제 문제를 해결하지 않은 이유를 정당화하는 근거로 사용했다.
   3. “Lauren이 절대 이렇게 하지 말라고 했다”는 주석도 특정 PR 피드백을 영구적인 전역 규칙으로 잘못 확장한 사례다.

2. Dune의 선택

   1. Dune은 에이전트가 주석 패턴을 복사해 코드베이스 전체에 퍼뜨리지 못하도록 코드 주석을 금지했다.
   2. 주석으로 문제를 덮는 대신 코드 구조와 Lint Rule로 문제의 원인을 해결하도록 유도한다.

6.3. Gardener는 기술 부채의 확산을 먼저 막는다

1. 새로운 역할로서의 Gardener

   1. 실제 정원에 잡초와 해충이 번지기 전에 관리하는 사람이 필요하듯 코드베이스에도 원치 않는 성장을 감시하는 역할이 필요하다.
   2. 기술 부채와 안티패턴이 퍼진 뒤 수습하는 대신 싹이 트는 순간 발견하고 제거한다.

2. Dune의 세 가지 운영 원칙

   1. 기존 기술 부채 삭제: 이미 쌓인 부채와 나쁜 패턴을 다음 에이전트에게 물려주지 않는다.
   2. 하나의 Paved Path 유지: 대부분의 Blessed Pattern에는 하나의 관례적인 구현 방식만 둬 에이전트가 추측하지 않게 한다.
   3. 안티패턴에는 Lint Rule 작성: 당장 모든 코드를 정리하지 못해도 규칙을 먼저 추가해 확산을 멈춘다. 규칙은 문제를 완전히 고치지는 않지만 출혈을 멈춘다.

3. 정리와 차단의 병행

   1. 나쁜 패턴을 차단하는 규칙만 추가하면 기존 부채는 남는다.
   2. 규칙으로 더 이상 커지지 않게 막으면서 에이전트에게 기존 코드를 정리하게 해야 한다.
   3. 코드베이스가 에이전트의 복사를 환영할 수 있는 상태에 가까워지는 것이 목표다.

7. Grok Bot과 Cursor의 Outer Loop 자동화

7.1. 도구 신호를 모아 스스로 다음 행동을 고른다

1. Grok Bot은 Outer Loop다

   1. Cursor가 개발자 중심의 내부 작업과 에이전트 실행을 담당한다면 Grok Bot은 외부 서비스의 신호를 모아 다음 작업을 시작하는 바깥 루프다.
   2. Slack, DataDog, Sentry, PlanetScale 같은 서비스를 연결할 수 있다.
   3. 여러 도구의 정보를 모아 에이전트가 상황을 판단하고 후속 조치를 선택하게 한다.

2. 회사 두뇌보다 도구 연결이 중요하다

   1. 일부는 이런 집계를 Company Brain이라고 부르지만 거대한 지능 시스템을 먼저 만들 필요는 없다.
   2. 에이전트는 도구를 잘 사용하므로 필요한 도구를 연결하는 것만으로 충분한 자동화가 가능하다.
   3. 복잡한 중앙 지식 계층보다 신뢰할 수 있는 코드베이스와 관찰·실행 도구 조합이 실용적이다.

7.2. Routines와 Cloud Agent가 사건을 PR로 바꾼다

1. 자동 실행 흐름

   1. Grok Bot Routine으로 Slack Thread를 Sentry Alert에 구독시킬 수 있다.
   2. 특정 오류나 사용자 신고가 들어오면 Cloud Agent를 자동으로 시작한다.
   3. 에이전트는 버그를 재현하고 원인을 파악하고 변경을 만들고 Pull Request를 연다.

2. Cursor 자동화와 SDK

   1. Cursor Automations와 SDK를 이용해 같은 에이전트 인프라를 재사용하는 추가 Bot을 만들 수 있다.
   2. 외부 사건 감지 → 애플리케이션 재현 → 수정 → 검증 → PR 생성까지 복잡한 작업을 연결한다.
   3. 자동으로 버그 리포트를 재현하고 PR을 여는 자동화가 실제로 운영되고 있으며 각 계층의 개선이 서로를 증폭시킨다.

7.3. 자동화가 팀 전체의 기여 범위를 넓힌다

1. 개인의 자동화에서 팀 인프라로

   1. 코드베이스·규칙·스킬이 한 사람의 개인 설정에 머물지 않고 팀 공용 기반이 된다.
   2. 모든 엔지니어와 Builder가 같은 신뢰 인프라 위에서 병렬로 작업할 수 있다.
   3. 디자이너, PM, GTM 구성원도 Grok Bot에 기능을 요청하거나 직접 기능 PR을 만들 수 있다.

2. 신뢰가 충분할 때의 운영 상태

   1. 에이전트가 자유롭게 움직이되 CI와 구조적 제약이 품질을 지킨다.
   2. 사람이 밤중에 성능 회귀를 걱정하지 않아도 된다.
   3. 사람은 모든 코드를 읽는 최종 방어벽이 아니라 환경을 개선하는 설계자와 Gardener가 된다.

8. PR 크기·CI·비용에 대한 Q&A

8.1. PR은 작게 쪼개되 고정된 상한은 두지 않는다

1. PR 크기의 범위

   1. 평균 PR 크기를 하나의 고정 숫자로 제시하기는 어렵다.
   2. 대략 50줄 정도에서 수백 줄, 작업에 따라 1,000줄 안팎까지 다양하다.
   3. 파일을 대량 삭제하는 작업이라면 변경량 대부분이 삭제로 구성될 수 있다.

2. Atomic PR 원칙

   1. 50줄 PR만 허용하는 하드캡은 없다.
   2. 다만 에이전트가 하나의 큰 작업을 여러 PR로 분리하도록 권장한다.
   3. 각 PR이 하나의 작은 변경을 원자적으로 설명하면 Git History가 풍부한 컨텍스트가 된다.
   4. 40,000줄짜리 거대한 PR 대신 작은 PR에서 버그를 추적하고 쉽게 되돌릴 수 있다.

8.2. Dune의 CI는 짜증 날 정도로 구체적이다

1. React의 대표적 지뢰를 금지한다

   1. React에서 흔한 Footgun인 useEffect를 Dune과 Grok Bot에서 금지했다.
   2. CI가 useEffect를 발견하면 실패하고 에이전트에게 즉시 오류를 알린다.

2. 에이전트가 나쁜 일을 잘하는 지점을 전부 차단한다

   1. Dune은 에이전트가 잘못하기 쉬운 모든 패턴을 가능한 한 금지한다.
   2. Agents MD, CI, Bugbot은 경계와 규칙을 코드베이스 전체에서 반복해서 알려 준다.
   3. Cursor의 Bugbot은 CI에서 실행되는 코드 리뷰 도구로 성능·안정성·신뢰성 회귀를 잡는다.

3. Agents Window의 미해결 과제

   1. Agents Window에는 아직 Dune과 같은 아키텍처가 완전히 적용되지 않았다.
   2. 많은 PR이 계속 합쳐지는 동안 각각이 성능·안정성을 회귀시킬 가능성이 남아 있다.
   3. Electron의 Renderer와 Main Process 사이 격리가 약하면 무거운 연산이나 I/O가 Renderer로 들어가 16밀리초 프레임 예산을 침범한다.
   4. Dune에서 얻은 학습을 Agents Window에도 가져가 구조를 리팩터링하는 방향이 제시됐다.

8.3. 토큰 비용과 모델 크기의 트레이드오프

1. 사람의 시간과 토큰의 비교

   1. Dune과 Grok Bot 수준의 프레임워크를 사람이 직접 만들고 리팩터링하고 테스트하고 검증하려면 수년이 걸릴 수 있다.
   2. 엔지니어의 급여와 기회비용을 생각하면 토큰을 투자해 코드베이스를 에이전트 친화적으로 만드는 선택과 사람을 더 채용하는 선택을 비교해야 한다.
   3. 토큰도 공짜가 아니지만 구조가 갖춰지면 작은 모델과 단순한 에이전트도 좋은 코드를 만들 수 있어 장기적으로 배당이 생긴다.

2. 지능과 추론 비용의 Pareto Frontier

   1. 가장 큰 모델을 만드는 것이 항상 목표는 아니다. 큰 모델은 추론 비용이 매우 비싸다.
   2. 충분히 똑똑하면서 추론 비용이 과도하지 않은 Sweet Spot을 찾는 것이 중요하다.
   3. 당시 발표된 Grok 4.6은 Grok 4.5와 토큰 가격이 같으면서 더 높은 지능을 제공할 가능성이 언급됐다. Lauren Tan은 “혹시 말하면 안 되는 내용을 말하는 것일 수 있다”고 농담하며 조심스럽게 덧붙였다.

9. Grok Bot은 비개발자의 Cursor 순간이 된다

9.1. 개발자용 IDE의 한계를 넘어선 인터페이스

1. Cursor의 강점과 한계

   1. Cursor는 개발자를 위해 설계된 Power User Tool이며 UI가 매우 개발자 중심이다.
   2. 지식 노동도 수행할 수 있지만 비개발자 업무에 맞춰 UI가 최적화된 제품은 아니었다.
   3. GTM과 Product 팀도 Cursor를 사용할 수는 있었지만 즐거운 경험이라고 하기는 어려웠다.

2. Grok Bot의 접근성

   1. Grok Bot은 기술 분야 밖의 사람에게 Cursor와 비슷한 전환점을 제공한다.
   2. iMessage처럼 익숙한 인터페이스에서 에이전트를 사용할 수 있고 에이전트에게 재미있는 이름을 붙일 수 있다.
   3. 각 에이전트를 팀원처럼 다루며 자연스러운 방식으로 여러 에이전트를 오케스트레이션할 수 있다.

9.2. PM과 비개발자도 안전하게 코드에 기여한다

1. 에이전트 팀의 활용 예

   1. 고객 계정마다 관리용 에이전트를 하나씩 둘 수 있다.
   2. PM은 Lauren이 전날 밤 작업한 내용을 요약하는 에이전트를 두고 아침에 무엇이 진행됐는지 확인할 수 있다.
   3. 실제 PM들이 이런 방식으로 대량 활용하고 있다.

2. 엄격한 구조가 비개발자의 품질을 지킨다

   1. 비개발자가 “여기에 버그가 있어서 고쳤는데 봐 달라”고 PR을 가져오는 일이 생긴다.
   2. Dune의 제약이 충분히 강하면 Lauren이 확인하고 바로 승인할 수 있는 수준의 변경이 나온다.
   3. 아키텍처와 CI가 실수할 수 있는 공간을 줄였기 때문에 가능한 결과다.

주요 발언 모음

“에이전트가 높은 품질의 작업을 만들 것이라고, 내가 자리에 없어도 믿을 수 있어야 한다.”

“소프트웨어 공장보다 미슐랭 주방이라는 비유가 더 좋다. 우리는 조립라인에서 제품을 대량 생산하는 것이 아니라, 제품을 만드는 창의적인 일을 한다.”

“나는 병목이다. 엔지니어로서 가진 모든 지식을 에이전트 팀에 전달해 모든 일의 차단점이 되지 않아야 한다.”

“신뢰 없이 100개의 Sub-Agent나 Cloud Agent를 띄우면 Slop PR과 회귀와 버그가 쏟아진다.”

“에이전트가 지름길을 좋아한다면, 지름길이 올바른 길이 되도록 프레임워크를 설계해야 한다.”

“코드베이스는 에이전트가 확장할 상태를 물질화한 기억이다.”

“안티패턴을 발견하면 Lint Rule을 작성해야 한다. 당장 정리하지 못해도 적어도 출혈은 멈출 수 있다.”

“신뢰할 수 있는 환경을 만드는 비결은 비밀이 아니라 많은 노력이다.”

핵심 데이터 & 수치

• 월간 2,000개 PR: Lauren Tan이 SpaceX AI의 Grok Bot에서 한 달 동안 프로덕션에 반영한 PR 수다.
• 약 6개월: Cursor 합류 후 성능 문제를 수동 분석하던 단계에서 검증 스킬과 에이전트 친화적 인프라를 축적한 기간이다.
• 1~5개 에이전트: 모든 대화를 사람이 베이비시팅하고 계속 교정하는 신뢰 형성 초기 단계다.
• 100개 에이전트: 검증과 가드레일 없이 바로 늘리면 Slop PR·회귀·버그가 폭증하는 위험 구간이다.
• 50줄~수백 줄~약 1,000줄: 작업 성격에 따른 PR 규모의 대략적인 범위이며 하드캡은 없다.
• 16밀리초: 60 FPS를 유지하기 위해 Renderer Thread가 한 프레임에 지켜야 하는 시간 예산이다.
• 8밀리초: 120 FPS를 목표로 할 때의 프레임당 시간 예산이다.
• 5단계 신뢰 순서: 코드베이스·아키텍처·데이터 구조로 불가능하게 만들기, 정적 분석, 규칙, Bugbot·Skills, 마지막 인간 스타일 리뷰 순서로 방어선을 쌓는다.
• 금지된 패턴: Dune은 React의 useEffect와 에이전트가 남기는 코드 주석을 대표적으로 금지한다.
• 연결되는 외부 신호: Slack, DataDog, Sentry, PlanetScale 등이 Grok Bot Outer Loop에 연결될 수 있다.

결론 및 시사점

1. 에이전트 생산량은 프롬프트 한 줄의 문제가 아니라 에이전트가 실패하기 어렵도록 만든 환경의 문제다.
2. 사람이 에이전트를 교정할 때마다 그 교정을 더 강한 방어선으로 옮겨야 한다. 구조적으로 불가능하게 만들 수 있으면 코드베이스와 아키텍처에 반영하고, 그렇지 않으면 정적 분석·규칙·Bugbot·Skill로 내린다.
3. 애플리케이션을 실행하고 증거를 수집하는 Verification Skill과 작업 방식을 가르치는 Engineering Skill을 결합하면 정확성과 품질을 동시에 관리할 수 있다.
4. 코드베이스를 에이전트의 기억으로 보고 기존 패턴을 복사해도 괜찮은 상태로 지속해서 가꿔야 한다.
5. Gardener는 기술 부채를 삭제하고 하나의 Paved Path를 유지하며 Lint Rule로 안티패턴의 확산을 막는다.
6. PR을 원자적 단위로 쪼개면 Git History가 복구와 디버깅을 위한 실행 가능한 컨텍스트가 된다.
7. Grok Bot은 외부 신호를 받아 Cloud Agent를 시작하는 Outer Loop로 기능한다.
8. 신뢰가 쌓이면 사람은 모든 코드 라인을 감시하는 역할에서 벗어나 팀 전체가 좋은 코드를 만들 수 있는 주방과 프레임워크를 설계한다.

핵심 요약 (20줄)

Lauren Tan은 SpaceX AI의 Grok Bot에서 한 달에 2,000개의 PR을 프로덕션에 반영했다.

2,000개 PR의 핵심은 에이전트 수가 아니라 에이전트를 믿을 수 있는 환경을 만든 데 있다.

소프트웨어 개발 환경은 조립라인보다 조리사와 장비의 배치가 결과를 좌우하는 미슐랭 주방에 가깝다.

Cursor Agents Window의 성능 문제는 Chrome DevTools와 수동 트레이스를 반복하던 병목에서 시작됐다.

Lauren Tan은 에이전트가 애플리케이션을 실행하고 트레이스를 수집하도록 Verification Skill을 만들었다.

Control Skill의 전용 CLI는 세션마다 달라지는 임시 스크립트 대신 재현 가능한 검증 절차를 제공한다.

Feature Map은 모호한 스크린샷과 사용자 신고를 실제 기능과 조작 경로로 번역한다.

Verification Skill은 기능의 정확성을 확인하고 Engineering Skill은 성능과 코드 품질을 높인다.

신뢰가 없는 상태에서 100개의 에이전트를 실행하면 Slop PR과 회귀와 버그가 함께 늘어난다.

코드베이스는 에이전트가 기존 패턴을 복사하고 확장하는 가장 강력한 기억이다.

첫 번째 방어선은 아키텍처와 데이터 구조로 나쁜 패턴이 들어오는 것을 불가능하게 만드는 일이다.

정적 분석과 CI는 사람이 반복해서 지적하던 실수를 자동으로 검출하고 차단한다.

Rules와 Bugbot과 Skills는 에이전트에게 구현 절차와 품질 기준을 제공한다.

Dune은 에이전트가 좋아하는 지름길이 항상 올바른 코드로 이어지도록 만든 Grok Bot용 프레임워크다.

Dune은 Feature를 한 폴더에 모으고 Electron의 Main과 Renderer 경계를 Import Dependency Graph로 강제한다.

60 FPS의 16밀리초와 120 FPS의 8밀리초 프레임 예산은 아키텍처 제약으로 코드에 반영된다.

Dune은 React의 useEffect와 에이전트가 남기는 문제 정당화용 코드 주석을 금지한다.

Gardener는 기술 부채를 지우고 하나의 Paved Path를 유지하며 Lint Rule로 안티패턴의 확산을 막는다.

Grok Bot은 Slack·DataDog·Sentry·PlanetScale 신호를 받아 버그 재현과 PR 생성을 자동으로 시작하는 Outer Loop다.

신뢰할 수 있는 주방을 만들면 엔지니어·디자이너·PM·GTM 구성원 모두가 높은 품질의 코드를 지속적으로 기여할 수 있다.