Cursor 핵심 개발자 Lauren Tan이 말하는 AI 에이전트를 신뢰하는 법

URL: https://www.youtube.com/watch?v=jLKQp4SgGr0
날짜: 2026-09-12
채널: Tech Bridge
원문 발행일: 2026-09-12

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==AI 에이전트를 병렬 실행하고 자동 병합할 만큼 신뢰하려면, 에이전트에게 더 많은 지시를 덧붙이는 것이 아니라 실제 애플리케이션을 스스로 실행·검증하는 루프와 반복 실수를 차단하는 하드 제약을 만들어야 한다.==

• Lauren Tan은 Cursor에서 에이전트가 코드를 실제로 실행하고, CPU trace·heap snapshot·시뮬레이터·UI 동작으로 결과를 확인하게 만드는 verification skill을 가장 중요한 기반으로 꼽는다.
• 애플리케이션의 기능 위치와 조작법을 기록한 feature map이 있으면 에이전트는 모호한 버그 신고나 스크린샷도 사용자 관점에서 재현할 수 있다.
• 좋은 아키텍처와 CI가 반복되는 실수를 하드 실패로 바꾸면, 사람의 코드 리뷰에만 의존하지 않고 PM·디자이너·다른 에이전트까지 같은 코드베이스에 안전하게 기여할 수 있다.

Lauren Tan이 말하는 핵심은 에이전트를 무조건 믿으라는 것이 아니다. 먼저 사람이 검증자가 되어 에이전트의 실패 양상을 관찰하고, 그 실패를 스킬·평가(eval)·feature map·정적 분석·CI 제약으로 계속 외부화해야 한다. 그 과정을 거쳐야만 한두 개의 로컬 에이전트에서 클라우드 에이전트 군단과 자동 병합으로 확장할 수 있다.

1. Lauren Tan의 배경과 에이전트 신뢰 문제

1.1. React와 관리 경험에서 에이전트로

1. Lauren Tan의 경력

   1. Cursor: 대화 시점 기준 약 5개월 전 Cursor에 합류했다. Twitter에서는 @poteto라는 이름을 사용하며, potato에 E가 들어간 철자라고 설명한다.
   2. Meta: React 팀에서 React Compiler를 작업했고, 현재도 코어 팀과 오픈소스에 때때로 기여하고 있다고 말한다.
   3. Netflix: 테크 리드로 일한 뒤 약 2년 동안 엔지니어링 매니저로 전환했다. 엔지니어링 매니저와 개인 기여자(IC)를 오간 경험이 에이전트 운영 방식과 연결된다.

2. 관리와 에이전트 운영의 평행선

   1. 신뢰가 낮을 때의 관리: 팀원을 믿지 못하는 매니저는 어깨 너머로 계속 확인하고, 운영 환경에 버그가 배포되지 않는지 직접 감시하는 마이크로매니지먼트에 빠진다.
   2. 에이전트에서도 같은 문제가 발생: 에이전트가 근거 없이 코드를 추측하거나 “smoking gun을 찾았다”고 자신 있게 말하면, 사람은 모든 도구 호출과 출력물을 직접 확인하게 된다.
   3. 병렬화의 한계: 한 에이전트의 결과도 믿지 못하는 상태에서는 100개의 에이전트를 띄울 수 없다. 수를 늘리면 생산성이 아니라 검증 비용과 토큰 낭비만 늘어난다.

1.2. 신뢰 곡선과 생산성의 변화

1. 초기 단계: 사람 중심의 검증

   1. 루프 안에 갇힌 작업: 에이전트 한두 개를 띄우고 모든 출력, 프롬프트, 수정 결과를 사람이 지켜본다.
   2. 사람이 병목이 됨: 에이전트가 코드를 쓴 뒤 사람이 로컬 빌드를 실행하고, 화면·콘솔 오류를 복사해 다시 전달해야 하므로 여러 작업을 동시에 진행하기 어렵다.

2. 현재 단계: 자동 병합

   1. PR 자동 병합: Lauren은 약 5개월 동안 신뢰 곡선을 올라 현재 에이전트가 PR을 자동 병합하도록 만들었다. 발표 당일 아침에는 이미 약 20개의 PR이 main에 들어와 있었고, 그녀는 main에서 결과만 리뷰했는데도 양호했다고 말한다.
   2. 높은 처리량: Cursor 합류 첫 달에는 코드베이스를 익히느라 생산성이 낮았지만, 최근에는 한 달에 약 1,000개의 PR을 배포했고 발표 당월 12일 시점에도 약 800개가 들어갔다고 설명한다.
   3. 품질에 대한 유보: PR 개수만으로 코드 품질이 보장되는 것은 아니다. Lauren도 “얼마나 많은 코드가 실제로 좋은가?”라는 의문은 정당하다고 인정하며, 신뢰를 만든 것은 숫자가 아니라 검증과 제약이라고 강조한다.

2. 첫 번째 기반: 에이전트가 실제 결과를 검증하게 하라

2.1. verification이 신뢰를 닫는 고리다

1. 가장 중요한 기술은 검증

   1. 실행 가능한 검증: 에이전트가 코드를 읽고 그럴듯한 설명을 만드는 데서 멈추지 않고, 실제 코드를 실행해야 한다. 애플리케이션이 사용자에게 노출되는 방식과 동일한 경로로 동작을 확인해야 한다.
   2. 표면에 맞는 도구: 웹·Electron 앱이라면 Chrome DevTools Protocol(CDP)을 사용하고, iOS 앱이라면 시뮬레이터 제어와 trace 수집을 활용한다. CPU trace, heap snapshot, 콘솔 상태 등도 검증 증거가 될 수 있다.
   3. 정답과 좋은 코드의 구분: 검증 루프가 있다고 좋은 코드가 자동으로 작성되는 것은 아니다. 하지만 적어도 코드가 문제를 실제로 해결했는지 확인할 수 있게 해 신뢰를 쌓는 중요한 진전이 된다.

2. 사람이 검증자일 때의 병목

   1. 반복되는 전달 과정: 에이전트가 코드를 작성하면 사람이 개발 빌드를 열고, 작동하지 않는 부분을 확인하고, 스크린샷이나 오류를 복사해 에이전트에 전달한다.
   2. 느린 피드백: 에이전트는 전달받은 자료를 다시 해석한 뒤 수정하지만, 수정이 맞는지 확인하려면 사람이 또 앱을 실행해야 한다. 이 구조에서는 에이전트 수를 늘릴수록 사람이 더 큰 병목이 된다.

2.2. Cursor Agents Window에서 만든 control-glass

1. 문제의 출발점

   1. 새 코드베이스와 촉박한 일정: Lauren은 Cursor에 처음 합류했을 때 원래 클라우드 에이전트 팀에 갈 예정이었지만, React 경험 때문에 Agents Window 작업을 돕게 됐다. 출시까지 약 일주일밖에 남지 않은 상황에서 새 코드베이스의 성능을 파악해야 했다.
   2. 수동 프로파일링의 한계: Chrome DevTools를 열어 flame graph를 직접 보고 trace를 해석했지만, 그녀 자신도 새 코드베이스를 막 배운 상태였다. 스크린샷과 trace를 에이전트에 보내도 에이전트는 실제 코드를 확인하지 않고 원인을 자신 있게 추측했고, 그 추측이 틀린 경우가 많았다.

2. control-glass 스킬

   1. 내부 코드명: Glass는 내부에서 Agents Window를 부르던 코드명이며, control-glass는 해당 애플리케이션을 에이전트가 직접 제어하고 성능을 측정하게 하는 첫 번째 스킬이었다.
   2. 프로그램 방식의 제어: Electron·웹 앱은 CDP로 실행·클릭·상태 확인·trace 수집을 할 수 있고, iOS 앱은 Apple의 시뮬레이터 및 성능 도구로 비슷한 자동화를 구성할 수 있다.
   3. 효과: 에이전트가 “이럴 것이다”라고 설명하는 대신 앱을 실제로 실행해 문제를 재현하고, 수정 후 같은 경로를 다시 검증할 수 있게 된다.

3. 두 번째 기반: feature map으로 애플리케이션을 가르쳐라

3.1. 검증 도구만으로는 부족한 이유

1. 앱을 조작할 지식의 부재

   1. 기능을 찾지 못하는 에이전트: control-glass를 만들어도 에이전트가 Agents Window의 왼쪽 사이드바, 오른쪽 PR 탭, 특정 설정 화면이 어디에 있는지 모르면 기능 앞에서 계속 헤맨다.
   2. 모호한 신고와의 충돌: 실제 내부 피드백에는 “이게 뭐죠?”라는 문장과 스크린샷 하나만 올라오는 경우가 많다. 에이전트가 UI 구조와 이동 방법을 모르면 어떤 코드를 조사해야 할지조차 결정하지 못한다.

2. feature map의 역할

   1. 사용자 관점의 지도: 기능이 UI 어디에 있고 어떤 순서로 접근하는지, 어떤 결과가 정상인지 기록한다.
   2. 조작 정보의 집합: 기능별 키보드 단축키, DOM 요소, CDP로 요소를 선택할 때 쓰는 attribute, 하위 기능 목록을 함께 제공한다.
   3. 신고를 검증 작업으로 변환: “사이드바가 느리다” 같은 추상적 신고도 feature map을 기준으로 해당 화면을 열고, 실제 동작을 재현하고, trace를 수집하는 작업으로 바뀐다.

3.2. pstack의 생성·유지 스킬

1. pstack의 정체

   1. 이름과 배경: Lauren은 자신의 plugin을 pstack이라고 부른다. P는 Potato를 뜻하며, Y Combinator CEO Gary Tan의 GStack을 농담 삼아 변형한 이름이다. 성은 같지만 친척은 아니라고 덧붙인다.
   2. 점진적으로 쌓인 결과: pstack은 처음부터 설계한 하나의 거대한 제품이 아니었다. control-glass처럼 에이전트의 반복적인 실패를 관찰할 때마다 그 실패를 막는 스킬을 하나씩 추가한 결과다.
   3. 스킬의 본질: 스킬은 Markdown으로 작성한 지시와 맥락이다. 새로 입사했지만 업무 맥락을 모르는 엔지니어에게 팀의 규칙과 문제 해결법을 가르치는 것과 같은 역할을 한다.

2. create-verification-skill

   1. 자동 생성: pstack의 create-verification-skill은 저장소와 애플리케이션을 살펴보고, 앱을 실행하고, 기능을 조작하고, 결과를 확인하는 프로젝트 전용 검증 스킬을 만든다.
   2. 초기 feature map: 생성 과정에서 앱의 기능과 사용자 관점의 접근법을 정리한 feature map도 만든다. 에이전트는 이 지도를 사용해 코드만 읽는 것이 아니라 실제 앱을 사용자처럼 탐색한다.
   3. 검증 우선: 스킬을 만든 뒤에는 앱을 실행하고, 상태를 확인하고, 기능 하나를 조작하고, 증거를 수집하고, 정리하는 전체 경로를 한 번 증명해야 한다.

3. maintain-verification-skill

   1. 변경에 취약한 지도: 애플리케이션이 빠르게 바뀌면 feature map도 곧 낡는다. 현재 존재하지 않는 DOM selector나 예전 화면 이동법이 남으면 검증 스킬이 다시 에이전트를 오도한다.
   2. 지속적인 갱신: maintain-verification-skill은 코드와 앱의 변화를 확인하고 feature map을 최신 상태로 유지한다.
   3. 팀 인프라: 검증 스킬은 한 사람의 편의 기능이 아니라 팀 전체의 품질 기반이다. 에이전트 자동화와 버그 재현을 가능하게 하는 공용 인프라가 된다.

4. 세 번째 기반: 스킬을 eval로 검증하고 반복 개선하라

4.1. eval은 에이전트 스킬의 단위 테스트다

1. 스킬도 테스트 대상

   1. 평가의 의미: eval은 스킬이 의도한 행동을 실제로 수행하는지 측정하는 방법이다. 특정 프레임워크가 없어도 루브릭과 실행 환경을 직접 만들 수 있다.
   2. 결과 점수화: 조정자(coordinator) 에이전트가 스킬의 성공 조건과 루브릭을 만들고, 여러 하위 에이전트가 독립된 환경에서 같은 작업을 수행하게 한다.
   3. 모델별 비교: Cursor는 여러 모델을 지원하므로 동일한 스킬을 여러 모델 조합에서 평가할 수 있다. 실제로 사용하는 모델에서 성능이 안정적인지 확인할 수 있다.

2. pstack의 eval playbook

   1. 독립된 실행 디렉터리: Potato Mode 아래의 eval playbook은 하위 에이전트마다 별도 디렉터리를 만든다.
   2. 평가 사실을 숨기는 이유: 디렉터리 이름을 평가 중이라는 사실을 드러내지 않도록 정한다. 에이전트가 자신이 평가받는다는 것을 알아차리면 평소보다 조심스럽게 행동해 실제 사용 성능과 다른 결과를 낼 수 있기 때문이다.
   3. 교차 판단: 실행한 모델이 자기 결과를 편향되게 평가하지 않도록 다른 모델을 judge로 두어 루브릭과 결과를 교차 확인한다.

4.2. 실패 관찰과 hill climbing

1. 스킬을 유지하는 방법

   1. backseat driver가 되기: 초기에는 에이전트를 수동적으로 지켜보지 말고, 페어 프로그래밍에서 동료의 작업을 관찰하듯 도구 호출·코드 탐색·사고 흐름을 면밀히 본다.
   2. 실패를 규칙으로 추출: 에이전트가 코드를 읽지 않고 추측했는지, 잘못된 파일을 조사했는지, 검증 증거를 생략했는지 확인하고 해당 실패를 새 스킬이나 규칙으로 만든다.
   3. 취향과 판단: 좋은 스킬을 유지하려면 무엇이 중요한지, 어느 검증이 충분한지 판단하는 엔지니어링 감각이 필요하다.

2. 검증 스킬 자체도 검증

   1. hill climbing: eval이 점수를 만들면, 그 점수를 높이는 방향으로 스킬을 반복 수정한다.
   2. 반복 자동화: Cursor의 /loop 같은 기능으로 eval을 계속 실행해 모든 항목이 10점 만점에 가까워질 때까지 개선할 수 있다.
   3. control-glass에 적용: Lauren은 control-glass도 같은 방식으로 개선했다. 처음부터 완벽하지 않았지만 실패를 관찰하고 평가를 반복하면서 실사용에 충분한 수준으로 끌어올렸다.

3. 주방의 헤드 셰프 비유

   1. 역할의 변화: 에이전트를 많이 운영하게 된 엔지니어는 모든 음식을 직접 만드는 요리사가 아니라 주방을 설계하는 헤드 셰프에 가깝다.
   2. 환경 설계: 주방의 구조, 조리대별 역할, 작업 분배, 품질 기준을 정하고 각 요리사가 같은 기준으로 일하게 해야 한다.
   3. 에이전트 시대의 엔지니어링: 코드를 직접 쓰는 양보다 에이전트가 올바르게 일할 환경을 설계하고, 그 환경이 실제로 작동하는지 측정하는 일이 중요해진다.

5. 로컬 검증에서 클라우드 에이전트 자동화로

5.1. 출발점은 로컬이어야 한다

1. 관찰 가능한 환경
   1. 로컬 우선: 검증 스킬을 처음 만들 때는 로컬에서 시작해야 한다. 에이전트가 앱을 어떻게 실행하고 어떤 API를 호출하며 어느 단계에서 실패하는지 직접 볼 수 있기 때문이다.
   2. 앱 종류에 따른 제어: CLI는 터미널과 출력 상태를, 웹 앱은 브라우저·CDP·HTTP를, 데스크톱 앱은 프로세스와 UI 제어를, 모바일 앱은 시뮬레이터를 이용해 검증한다.
   3. 검증 방식의 명시: “코드가 컴파일된다”가 아니라 “사용자가 이 기능을 실행하고, 이 결과와 증거를 얻는다”를 완료 조건으로 정해야 한다.

5.2. 클라우드에서 팀 전체를 확장하는 Benny

1. 버그 신고 자동 처리

   1. Benny의 입력: Cursor 내부에서 Benny라는 에이전트가 들어오는 버그 신고와 사용자 리포트를 수집한다.
   2. 클라우드 실행: Benny는 클라우드에 별도의 데스크톱 환경을 열고 그 안에서 Cursor를 실행한다. control-glass와 feature map을 이용해 앱을 실제 사용자처럼 조작한다.
   3. 재현과 결과 반환: 버그를 재현하고 필요한 정보를 모아 수정 PR을 만들거나, 이미 main에서 해결된 문제인지 판별한다.

2. 자동화가 주는 정보의 가치

   1. 이미 고쳐진 버그 확인: Lauren이 든 사례에서 Benny는 신고된 버그를 실제로 재현했지만, 현재 main에서는 문제가 사라진 상태임을 확인했다.
   2. 사람의 조사 시간 절약: Lauren이 직접 에이전트와 한 시간 동안 “고쳐졌는가?”를 확인하지 않아도 되고, 다음 릴리스만 진행하면 된다는 결론을 얻는다.
   3. 개인에서 조직으로: 같은 검증 인프라가 Lauren 한 사람의 생산성뿐 아니라 팀 전체와 회사의 버그 대응 능력을 높인다.

3. 확장 순서

   1. 검증 가능한 로컬 에이전트: 먼저 한두 개의 에이전트가 실제 앱을 조작하고 증거를 내도록 만든다.
   2. 클라우드 자동화: 신뢰할 수 있는 검증 스킬을 버그 신고·이슈·반복 업무와 연결한다.
   3. 대규모 병렬화와 자동 병합: 마지막으로 여러 에이전트가 독립적으로 PR을 만들고, CI와 검증을 통과한 변경을 자동 병합한다.
   4. 성급한 확장의 위험: 아직 한 에이전트도 믿지 못하는 상태에서 100개나 1,000개의 클라우드 에이전트를 띄우면 토큰과 비용만 폭증한다. 신뢰 곡선은 개인의 판단과 검증 경험을 거치며 올라가야 한다.

6. 리팩터링·재작성과 에이전트 시대의 코드베이스

6.1. “다시 쓰지 말라”는 원칙을 재검토하기

1. 재작성 논쟁의 배경
   1. 엔지니어의 본능: 새 회사에 합류해 낡은 코드베이스를 보면 “누가 이렇게 작성했지?”라는 생각과 함께 전부 다시 쓰고 싶어지는 경우가 많다.
   2. 전통적인 경고: 에이전트 이전에는 기존 시스템의 숨은 요구사항과 운영 지식을 잃을 수 있어 재작성을 대체로 경계했다.
   3. 새로운 조건: 에이전트는 대규모 마이그레이션과 반복 검증을 빠르게 수행할 수 있으므로, 검증 가능한 환경과 충분한 제약이 있다면 재작성의 ROI를 다시 계산할 수 있다.

6.2. 브라운필드와 그린필드의 서로 다른 위험

1. 브라운필드의 숨은 장점

   1. 대기업의 문제는 모두의 문제가 됨: Meta나 Google처럼 거대한 조직이 오랫동안 해결해 온 문제, 즉 수많은 사람이 같은 코드베이스를 건드릴 때 품질을 유지하는 문제가 이제 소규모 팀에도 나타난다.
   2. 이미 존재하는 가드레일: 대기업의 모노레포, 프레임워크, 컨벤션, 권한 제한, CI는 가장 경험이 적은 엔지니어도 큰 사고를 내지 않도록 만들어져 있다.
   3. 인간의 슬롭: Lauren은 AI slop 이전에 human slop이 있었다고 농담한다. 사람 수만 명이 코드를 작성해도 코드 품질이 자동으로 높아지는 것은 아니며, 에이전트가 이미 있는 가드레일을 활용할 수 있다.

2. 그린필드의 기회와 위험

   1. 빠른 프로토타이핑: GrokBot은 매우 빠르게 시작된 그린필드 애플리케이션이며, 초기에는 vibe coding으로 프로토타입을 만들고 사람이 코드를 거의 읽지 않았다.
   2. 유기적 아키텍처의 악순환: 명확한 제약이 없으면 에이전트는 당장 편한 지름길을 택한다. 시간이 지나면 에이전트는 코드를 어느 정도 이해하더라도, 사람이 전체 구조를 이해하지 못하는 통제 불능의 코드베이스가 된다.
   3. 강한 시작의 필요성: 새 프로젝트일수록 초기부터 기능 경계, 디렉터리 규칙, import 방향, CI 검사를 설계해야 한다. 짧은 경로가 가장 좋은 경로가 되도록 만들면 에이전트의 지름길 선호가 오히려 장점이 된다.

7. Dune 아키텍처와 하드 제약의 계층

7.1. GrokBot을 위한 구조적 제약

1. Dune의 방향

   1. Electron용 프레임워크: Dune은 GrokBot을 위해 만든 내부 아키텍처의 코드명이다. 개념적으로는 Electron 앱을 위한 Next.js처럼, 에이전트가 기능을 일관된 방식으로 만들도록 설계됐다.
   2. 기능의 응집: 기능 하나에 필요한 코드를 하나의 디렉터리에 모으고, entry point와 transcript card 같은 공통 개념을 정해 에이전트가 기존 패턴을 그대로 복사할 수 있게 한다.
   3. 가장 짧은 경로: 에이전트가 가장 빨리 문제를 해결하려고 한다면, 그 짧은 경로가 구조적으로 올바른 길이 되도록 프레임워크를 만든다.

2. 구체적인 금지 규칙

   1. React useEffect 금지: Dune과 GrokBot에서는 React의 대표적인 실수 유발 요소로 보는 useEffect를 금지한다. CI가 이를 발견하면 실패한다.
   2. 코드 주석 금지: 에이전트가 현재 코드에 필요하지 않은 역사적 설명을 주석으로 남기는 경우가 많아 코드 주석도 금지한다. 예를 들어 특정 PR에서 들은 “이렇게 하지 말라”는 조언이 영구적인 시스템 규칙처럼 주석에 박히는 문제를 막는다.
   3. main과 renderer 분리: Electron의 electron main과 electron renderer를 분리하고, 의존성 그래프를 검사해 한 영역의 코드를 다른 영역으로 잘못 import하지 못하게 한다.

7.2. 성능·품질을 CI로 고정하기

1. 렌더러의 16ms 예산

   1. 프레임 시간: 60fps를 유지하려면 한 프레임을 약 16ms 안에 그려야 한다.
   2. 실수하기 쉬운 구조: Electron에서 무거운 계산이나 I/O가 renderer 프로세스로 끌려오면 렌더링과 경쟁해 긴 작업과 프레임 드롭을 만든다.
   3. 하드 실패: 이런 import 패턴과 프로세스 경계 위반을 CI에서 실패시키면 매 PR을 사람이 눈으로 찾아내지 않아도 된다.

2. 제약의 강도

   1. 가장 강한 층: 구조적으로 올바른 아키텍처, 기능 디렉터리, import 경계, 정적 분석, 컴파일러 진단, lint와 CI 실패가 가장 강력하다.
   2. 보조 층: Bugbot, rules, skills, style guide, AGENTS.md는 에이전트의 행동을 유도하지만 에이전트가 잊거나 일관되게 적용하지 못할 수 있다.
   3. 코드 리뷰의 냄새: 사람이 매번 “이 패턴을 쓰지 말라”고 PR에 댓글을 달아야 한다면 그것은 코드 냄새다. 그 지적을 lint·CI·타입 시스템으로 바꾸거나, 아예 해당 실수가 불가능한 구조를 만들어야 한다.

3. 언어와 도구 선택

   1. Rust의 사례: Rust의 엄격한 컴파일러와 borrow checker는 많은 제약을 강제한다.
   2. 신뢰의 효과: 에이전트가 unsafe 블록을 함부로 쓰지 못하게 하면, 컴파일에 성공한 코드가 실제로 동작할 가능성에 대한 인간의 신뢰가 높아진다.
   3. 결론: 에이전트의 행동을 모두 프롬프트로 통제하려 하지 말고, 컴파일러와 정적 분석이 보장할 수 있는 것을 최대한 그쪽으로 옮겨야 한다.

8. PR 크기와 Git 히스토리의 의미

8.1. 원자적 PR을 선호하는 이유

1. 크기는 유동적

   1. 범위: PR은 약 50줄이나 수백 줄에서 1,000줄 정도까지 다양하다. 삭제가 중심인 PR은 추가 코드가 거의 없을 수도 있다.
   2. 하드 캡 없음: Lauren은 PR 크기에 절대적인 상한을 두지 않는다.
   3. 작업 분할 권장: 대신 에이전트가 하나의 큰 작업을 여러 PR로 나누도록 유도한다.

2. Git 히스토리를 컨텍스트로 사용

   1. 원자적 의미: 각 PR이 작고 하나의 변화를 설명하면 Git 히스토리가 코드베이스의 풍부한 맥락이 된다.
   2. 되돌리기 쉬움: 버그가 발생했을 때 어느 변경이 원인인지 찾고 해당 PR만 revert하기 쉽다.
   3. 거대한 PR 회피: 무엇이 함께 들어갔는지 알 수 없는 4만 줄짜리 PR보다, 목적이 분리된 여러 PR이 사람과 에이전트 모두에게 검증 가능하다.

9. 토큰 비용과 투자수익률(ROI)

9.1. 무제한 토큰 환경을 일반화하지 않기

1. 환경 차이 인정
   1. AI 연구소의 조건: Lauren은 AI 연구소에서 일하기 때문에 토큰이 사실상 무제한인 환경에 있다고 말한다.
   2. 모든 팀의 표준은 아님: 따라서 모든 사람이 같은 규모의 자동화와 리팩터링을 그대로 따라 해야 한다고 주장하지 않는다.
   3. 가능성은 ROI로 판단: 초기 비용을 감당할 수 있는지, 그 비용이 이후의 개발·검증·채용 비용을 얼마나 줄이는지 계산해야 한다.

9.2. 초기 토큰 투자와 장기 효과

1. 선행 비용

   1. 리팩터링 비용: 코드베이스를 새로운 구조로 옮기고, 제약과 검증을 추가하고, 실제 앱에서 다시 테스트하는 일에는 많은 토큰이 든다.
   2. 대안과 비교: 엔지니어링 리더는 이 작업을 사람을 추가 채용해 수행할지, 토큰을 사용해 에이전트가 잘 일할 수 있는 기반을 만들지 비교해야 한다.
   3. 작은 팀의 레버리지: 장기적으로는 거대한 엔지니어링 조직을 만들지 않고도 더 많은 일을 처리하는 것이 에이전트의 가치다.

2. Grok 4.6의 비용 대비 지능

   1. 새 모델 출시: 대화 당일 Grok 4.6이 발표됐다고 소개한다.
   2. 동일한 토큰 비용: Lauren은 정확한 수치는 조심스럽게 말하면서도, 4.5와 토큰당 비용이 같고 같은 비용으로 더 높은 지능을 얻는 방향이라고 설명한다.
   3. 최대 모델보다 효율적인 모델: Cursor와 xAI는 가장 큰 모델을 만드는 것보다 추론 비용과 지능 사이의 좋은 지점을 찾는 데 집중한다고 말한다.

10. 비개발자까지 참여시키는 GrokBot

10.1. 개발자 도구에서 익숙한 인터페이스로

1. 기존 Cursor의 한계

   1. 파워 유저 도구: Agents Window, CLI, IDE는 개발자에게 강력하지만 개발자 중심으로 설계되어 PM·GTM·디자이너에게는 지식 작업을 하기 좋은 인터페이스가 아니었다.
   2. 사용 장벽: 비개발자가 Cursor를 사용할 수는 있어도 편안하고 즐거운 경험은 아니었다.

2. GrokBot의 접근성

   1. iMessage와 비슷한 UI: GrokBot은 익숙한 메시징 인터페이스를 사용하며, 에이전트마다 이름과 정체성을 부여할 수 있다.
   2. 자연스러운 오케스트레이션: 각 에이전트를 한 명의 팀원처럼 다루고, 여러 에이전트를 계정별로 관리하며, 서로 다른 일을 맡길 수 있다.
   3. 비개발자의 코드 기여: PM이 Lauren이 밤새 한 작업을 요약하게 하거나 버그를 고치도록 에이전트에 맡기고, Lauren이 결과를 리뷰하는 흐름이 실제로 일어난다.

10.2. 강한 제약이 조직 속도를 높인다

1. Dune의 효과
   1. 낯선 사람도 기여 가능: Dune의 엄격한 규칙이 에이전트와 비전문가의 실수를 제한하므로, GrokBot 코드베이스에 익숙하지 않은 PM과 디자이너도 기능을 추가할 수 있다.
   2. 검토의 기준 통일: 사람이 모든 코드를 직접 가르치는 대신 구조·CI·검증 스킬이 공통 기준이 된다.
   3. 팀의 속도: Lauren은 이런 구조가 GrokBot 팀이 매우 빠르게 기능과 버그 수정을 배포하는 데 기여한다고 말한다.

11. 결론 및 실용적 시사점

1. 에이전트를 신뢰하는 일은 모델을 믿는 선언이 아니라, 실제 애플리케이션에서 스스로 실행하고 검증할 수 있는 폐쇄 루프를 만드는 일이다.
2. 첫 번째 투자 대상은 프롬프트 모음이 아니라 앱을 실행하고, 사용자 경로를 조작하고, 로그·trace·스크린샷 같은 증거를 수집하는 verification skill이다.
3. 에이전트가 기능을 찾지 못하면 검증도 실패하므로, UI 위치·접근 순서·단축키·DOM selector·정상 결과를 feature map으로 기록해야 한다.
4. feature map은 빠르게 낡기 때문에 생성 스킬과 함께 유지 스킬을 두고, 클라우드 에이전트가 정기적으로 최신 상태를 확인하게 해야 한다.
5. 스킬은 한 번 작성하고 끝나는 문서가 아니다. 도구 호출과 실패를 관찰해 eval 루브릭을 만들고, 여러 모델과 독립 환경에서 반복 평가해야 한다.
6. 사람의 PR 댓글로 반복해서 지적하는 규칙은 lint·타입·정적 분석·CI 실패로 옮겨야 한다. 가장 좋은 제약은 애초에 잘못된 코드를 쓰기 어렵게 만드는 구조다.
7. 검증 가능한 로컬 에이전트에서 출발해 클라우드 자동화로 확장하고, 마지막에야 병렬 에이전트와 자동 병합을 도입해야 한다.
8. 초기 리팩터링과 제약 구축에 드는 토큰 비용은 크지만, 장기적으로는 한 사람과 작은 팀이 더 많은 기능·버그 수정·품질 검증을 처리하게 하는 레버리지가 될 수 있다.
9. 새 코드베이스에는 강한 규칙을 일찍 넣고, 기존 코드베이스에는 이미 있는 가드레일을 분석해 에이전트가 따라갈 수 있는 가장 짧은 정상 경로로 정리해야 한다.
10. 에이전트 시대의 엔지니어는 모든 코드를 직접 작성하는 사람에서, 에이전트가 올바르게 일할 주방과 품질 시스템을 설계하는 헤드 셰프로 역할이 바뀐다.

주요 발언 모음

“에이전트와 일할 때 도구 상자에서 가장 중요한 기술은 검증이다.”

“검증은 에이전트가 실제로 코드를 실행하게 하고, 애플리케이션이 사용자에게 노출되는 방식과 같은 방식으로 테스트하게 하는 것이다.”

“한 에이전트의 결과도 믿지 못하면서 100개의 에이전트를 띄울 수는 없다.”

“사람이 코드 리뷰에서 매번 같은 불변식을 지적해야 한다면, 그것은 코드 냄새다. 그 규칙을 lint나 CI 실패로 바꿔야 한다.”

“가장 짧은 경로가 가장 좋은 경로가 되도록 만들어라. 에이전트는 어차피 지름길을 찾기 때문이다.”

“AI slop 이전에 human slop이 있었다.”

핵심 데이터 & 수치

• Cursor 근무 기간: Lauren Tan은 발표 시점 기준 약 5개월 전 Cursor에 합류했다.
• PR 처리량: 최근 한 달 약 1,000개, 발표 당월 12일 시점 약 800개의 PR을 배포했다고 설명했다.
• 당일 자동 병합: 발표 당일 아침 에이전트가 약 20개의 PR을 이미 main에 병합해 두었고, Lauren은 main에서 결과를 리뷰했다.
• Electron 프레임 예산: 60fps를 유지하려면 프레임 하나를 약 16ms 안에 처리해야 한다.
• PR 크기: 약 50줄에서 수백 줄, 최대 1,000줄 정도까지 다양하며 하드 캡은 두지 않는다.
• 검증 스킬 평가: eval playbook은 여러 하위 에이전트와 별도 디렉터리, 루브릭, 교차 judge를 사용한다.

핵심 요약 (20줄)

1. AI 에이전트를 병렬화하고 자동 병합하려면 모델의 낙관적 설명이 아니라 실제 앱 실행과 검증 증거를 신뢰의 기반으로 삼아야 한다.
2. Lauren Tan은 Cursor·Meta React Compiler·Netflix 엔지니어링 관리 경험을 바탕으로 에이전트 운영과 팀 관리의 공통점을 설명한다.
3. 에이전트를 믿지 못하는 엔지니어는 모든 출력을 직접 확인하는 마이크로매니저가 되고, 한두 개 이상의 에이전트를 병렬화할 수 없다.
4. Lauren은 Cursor에서 약 5개월 동안 신뢰 곡선을 올라 에이전트의 PR 자동 병합과 대규모 배포를 가능하게 만들었다.
5. PR 개수는 품질의 증거가 아니며, 실제 앱에서 문제가 해결됐는지 확인하는 verification 루프가 품질 신뢰를 만든다.
6. 웹·Electron 앱은 CDP를, iOS 앱은 시뮬레이터와 Apple 성능 도구를 사용해 사용자가 접하는 표면에서 검증할 수 있다.
7. Lauren이 만든 control-glass는 Cursor Agents Window를 실행하고 조작하고 성능 trace를 수집하도록 에이전트를 가르치는 스킬이다.
8. 검증 도구만 있어도 에이전트가 기능의 위치와 접근법을 모르면 UI 버그를 재현하지 못하므로 feature map이 필요하다.
9. feature map에는 사용자 관점의 이동 경로, 단축키, DOM selector, 하위 기능, 정상 동작의 증거가 들어간다.
10. pstack은 Potato Stack을 뜻하며 에이전트의 실패 양상을 관찰할 때마다 스킬을 추가해 점진적으로 만들어졌다.
11. pstack의 create-verification-skill은 앱을 조사해 프로젝트 전용 검증 절차와 초기 feature map을 생성한다.
12. maintain-verification-skill은 빠르게 변하는 코드베이스에 맞춰 검증 절차와 feature map을 계속 갱신한다.
13. eval은 에이전트 스킬의 단위 테스트이며, 루브릭·독립 디렉터리·여러 하위 에이전트·교차 judge로 실제 사용 성능을 측정한다.
14. 스킬은 실패를 관찰하고 /loop 같은 반복 실행으로 점수를 높이는 hill climbing 방식으로 개선해야 한다.
15. 검증 가능한 로컬 환경에서 시작해 클라우드 자동화로 확장하면 Benny 같은 에이전트가 버그를 재현하고 이미 해결됐는지도 판별할 수 있다.
16. 신뢰가 없는 상태에서 수백 개의 클라우드 에이전트를 띄우면 품질보다 토큰 비용과 검증 부담이 커진다.
17. GrokBot의 Dune 아키텍처는 기능 디렉터리, import 경계, useEffect 금지, 프로세스 분리 같은 규칙을 CI의 하드 실패로 만든다.
18. 반복적으로 사람의 코드 리뷰에서 지적하는 규칙은 lint·정적 분석·컴파일러·CI로 옮기고, 가능하면 잘못된 코드가 구조적으로 불가능하게 해야 한다.
19. 강한 제약은 PM과 디자이너도 안전하게 코드를 기여하게 하며, 에이전트 시대의 엔지니어를 코더에서 품질 시스템을 설계하는 헤드 셰프로 바꾼다.
20. 에이전트에 대한 신뢰는 맹목적인 믿음이 아니라 관찰·검증·eval·하드 제약을 반복해 쌓는 조직의 실행 인프라다.