이 영상에서 Cursor 엔지니어 로렌 탄(Lauren Tan, @poteto)은 AI 에이전트를 활용해 월 1,000개 이상의 PR을 병합할 수 있게 된 과정을 설명한다. 그의 핵심 주장은 AI 코딩의 가장 큰 문제는 코드 생성 자체가 아니라, 에이전트가 만든 결과를 어떻게 검증하고 신뢰할 것인가에 있다는 것이다. 이를 위해 검증 자동화, 기능 맵, 에이전트용 평가(Eval), 강력한 CI 제약과 아키텍처를 함께 구축해야 하며, 결국 개발자는 직접 모든 코드를 쓰는 사람이 아니라 에이전트가 잘 일하도록 시스템을 설계하는 사람이 되어야 한다고 말한다.

1. 로렌 탄의 배경과 오늘의 주제

로렌 탄은 트위터에서 poteto라는 이름으로 활동하며, Cursor에 합류한 지 약 5개월 된 엔지니어라고 자신을 소개한다. 이전에는 Meta의 React 팀에서 React Compiler를 작업했고, 여전히 코어 팀 및 오픈소스에 일부 기여하고 있다. Meta 이전에는 Netflix에서 테크 리드와 엔지니어링 매니저를 약 2년간 맡았다.

그는 개인 기여자(IC)와 관리자를 오가며 일해 본 경험 때문에, 사람을 관리하는 일과 AI 에이전트를 관리하는 일이 놀랄 만큼 비슷하다고 느낀다. 이번 대화의 핵심도 바로 이 연결점이다.

"관리 역량과 에이전트를 관리하는 방식 사이에는 정말 많은 유사점이 있어요."

진행자는 최근 Cursor가 출시한 Grokbot도 함께 다룰 예정이라고 소개한다. Grokbot은 여러 에이전트에 각각의 역할과 정체성을 부여하고, 이들을 조율하는 제품으로 설명된다. 잠시 화면 공유와 음소거 문제가 있었고, 로렌은 웃으며 말한다.

"2026년인데도 저는 아직 Zoom 쓰는 법을 모르겠네요."

2. 에이전트를 믿지 못하면 결국 사람이 병목이 된다

로렌이 AI 에이전트와 코딩할 때 가장 크게 느낀 문제는 단순하다.

"어떻게 이걸 믿을 수 있을까요?"

오랫동안 직접 코드를 작성해 온 엔지니어에게는 좋은 설계와 나쁜 설계를 구별하는 나름의 기준, 과거의 실패에서 얻은 교훈이 있다. 그런데 에이전트는 자신 있게 추측하거나, 실제 원인이 아닌 것을 "결정적 단서"라고 말하는 일이 잦다. 이런 경험이 반복되면 신뢰가 무너지고, 결국 에이전트를 충분히 활용할 수 없게 된다.

그는 이를 관리자의 마이크로매니지먼트에 비유한다. 만약 관리자가 팀원들을 신뢰하지 못하면, 팀원들이 버그를 배포하지 않는지 계속 옆에서 확인해야 한다. 에이전트도 마찬가지다. 하나의 에이전트 결과도 믿을 수 없다면 100개의 에이전트를 동시에 돌릴 수 없다.

"에이전트 하나의 결과도 신뢰하지 못하는데, 100개를 띄울 수는 없잖아요."

처음에는 에이전트 한두 개의 모든 출력과 도구 호출을 직접 지켜보며 프롬프트를 수정해야 한다. 이 단계에서는 사람이 검증자 역할을 하므로 병렬화가 거의 불가능하다. 에이전트가 무언가를 구현하면 사람이 앱을 열고, 오류를 재현하고, 스크린샷과 콘솔 로그를 복사해서 다시 전달해야 한다.

"검증 능력이 없으면, 당신이 검증자예요. 즉 당신이 병목이 됩니다."

반대로 충분한 신뢰를 쌓은 현재의 로렌은 에이전트가 PR을 자동 병합하도록 운영한다. 어느 날 아침에는 이미 병합된 PR이 20개가량 있었고, 그는 메인 브랜치에서 이를 사후 검토했다. 그리고 그 결과물이 실제로 괜찮았다고 말한다.

"오늘 일어났더니 PR이 20개쯤 이미 병합돼 있었어요. 메인 브랜치에서 검토했는데, 좋았습니다."

3. 생산성 폭발의 기반은 코드 생성이 아닌 검증이다

로렌은 Cursor 입사 첫 달에는 코드베이스를 파악하느라 생산성이 낮았다고 말한다. 하지만 에이전트를 신뢰하는 방법을 점차 익히면서 생산성이 급격히 올라갔다. 지난달에는 1,000개의 PR을 배포했고, 이번 달은 12일밖에 지나지 않았는데도 거의 800개를 병합했다.

다만 이 수치는 자랑하려는 목적이 아니라, 신뢰 수준이 올라갈수록 처리 가능한 작업량이 어떻게 증가했는지 보여주기 위한 사례다. 많은 사람이 "그렇게 많은 코드가 정말 좋은 코드인가?"라고 의심할 수 있다는 점도 인정한다.

로렌이 꼽는 가장 중요한 능력은 검증(verification) 이다. 여기서 검증은 단순히 테스트를 실행한다는 뜻보다 넓다. 에이전트가 실제 애플리케이션을 구동하고, 사용자처럼 조작하며, 성능 트레이스를 찍고, 힙 스냅샷을 분석하고, iOS 시뮬레이터를 열어 실제로 문제가 해결됐는지 확인하는 능력을 말한다.

"검증은 에이전트가 실제로 코드를 실행하고, CPU 트레이스나 힙 스냅샷을 찍고, iOS 시뮬레이터를 열어서 사용자가 보는 방식 그대로 시험하는 능력입니다."

검증이 코드 품질을 완벽히 보장하지는 않는다. 그러나 최소한 코드가 정확하게 작동하는지 확인할 수 있게 해 준다. 로렌은 이것이 에이전트를 믿기 위한 "매우 큰 진전"이라고 강조한다.

"좋은 코드를 쓴다는 보장은 아니에요. 하지만 적어도 올바르게 작동하는 코드를 쓸 수 있게 해 줍니다."

4. 기능 맵으로 에이전트에게 제품 사용법을 가르치기

로렌은 Cursor의 에이전트 창, 내부 코드명으로는 Glass라고 불리는 영역을 개선했던 초기 경험을 들려준다. 원래는 클라우드 에이전트 팀에 합류할 예정이었지만, React 경험이 있었기에 출시를 앞둔 에이전트 창 작업을 도와달라는 요청을 받았다.

문제는 출시까지 약 일주일밖에 남지 않았고, 새 코드베이스를 거의 모르는 상태였다는 점이다. 그는 Chrome DevTools에서 성능 트레이스를 직접 뜨고 플레임 그래프를 해석해야 했다. 에이전트에게 트레이스 스크린샷을 보여 줘도, 에이전트는 그럴듯하게 원인을 추측했지만 실제 원인이 아닌 경우가 많았다.

"에이전트는 '아마 이거 같네요'라고 자신 있게 말했지만, 고쳐 보면 실제 문제는 그게 아니었어요."

이를 해결하기 위해 그가 만든 초기 도구 중 하나가 Control Glass라는 검증 스킬이다. 이 스킬은 에이전트가 애플리케이션을 실행하고, 성능 트레이스를 수집하고, 프로그램을 제어하도록 돕는다. Electron·웹·iOS 앱이라면 Chrome DevTools Protocol이나 Apple의 시뮬레이터 도구 등을 통해 비슷한 제어 체계를 만들 수 있다는 설명이다.

하지만 애플리케이션을 실행할 수 있게 됐다고 해서 에이전트가 제품을 이해하는 것은 아니다. 사용자가 "왼쪽 사이드바가 느리다", "PR 탭이 작동하지 않는다"고 보고해도, 에이전트는 해당 기능으로 이동하는 방법조차 몰랐다. 개발 빌드를 띄운 뒤 여기저기 클릭하며 헤매는 상황이 이어졌다.

그래서 그는 기능 맵(feature map) 을 만들었다. 기능 맵은 에이전트에게 제품의 각 기능에 어떻게 접근하는지 알려주는 문서다. 사용자 관점의 진입 경로, 키보드 단축키, UI 구성, 자동화 제어에 필요한 DOM 선택자와 속성 등이 담긴다.

"기능 맵은 에이전트에게 우리가 가진 모든 기능에 어떻게 도달하는지 가르쳐 줍니다."

이 기능 맵 덕분에 매우 부실한 사용자 제보도 처리할 수 있게 된다. Cursor 내부 피드백 채널에는 스크린샷 하나와 물음표만 올리는 식의 모호한 제보도 많다고 한다. 기능 맵이 없으면 에이전트는 할 수 있는 일이 거의 없지만, 맵이 있으면 어떤 화면과 기능을 봐야 하는지 맥락을 잡을 수 있다.

"스크린샷과 물음표만 있는 제보도 많아요. 기능 맵이 없으면 에이전트는 '전혀 모르겠습니다'라고 할 수밖에 없죠."

그가 만든 P-stack 플러그인에는 이런 체계를 자동으로 시작하도록 돕는 create verification 스킬과, 변화한 제품에 맞게 계속 갱신하는 maintain verification 스킬이 포함돼 있다.

5. P-stack은 실패를 관찰하며 만든 에이전트 운영 지식이다

P-stack이라는 이름의 P는 로렌의 별명인 poteto와 sack을 합친 장난스러운 이름이다. Y Combinator CEO인 Garry Tan의 G-stack에서 영감을 받았으며, 성이 같지만 둘 사이에 친족 관계는 없다고 웃으며 설명한다.

"P-stack의 P는 poteto sack의 P예요."

처음부터 플러그인을 만들려 했던 것은 아니다. 그는 에이전트가 실패하는 방식을 자세히 관찰하다가, 반복되는 실패 하나하나를 스킬로 바꾸기 시작했다. 예를 들어 에이전트가 관련 코드를 제대로 읽지 않고 원인을 자신 있게 추측하는 모습을 보자, "추측하지 말고 코드를 검색하고 확인하라", "서브에이전트를 적극 활용하라"는 식의 지침을 만들었다.

"실패 모드를 볼 때마다 '좋아, 이걸 스킬로 만들자'고 했어요. 환각하지 말고, 실제 코드를 찾아보고, 추측을 멈추라고요."

그는 이것을 새로 입사한 훌륭한 엔지니어를 온보딩하는 일에 비유한다. 코딩 실력은 뛰어나지만 비즈니스 맥락이 전혀 없는 사람에게는, 업무에 필요한 맥락과 절차를 가르쳐야 한다. 에이전트 스킬도 본질적으로는 Markdown 문서지만, 이 문서 안에 규칙, 제품 맥락, 문제 해결 절차, 기대 행동을 담을 수 있다.

LLM은 다음 토큰을 예측하는 모델이므로, 처음부터 질 좋은 맥락을 주면 더 나은 방향으로 추론할 가능성이 높아진다. 로렌은 이를 일부 사람들이 "에이전트를 더 좋은 잠재 공간으로 끌고 간다"고 표현한다며, 어렵게 들리지만 결국 좋은 입력이 좋은 작업 방식을 유도한다는 뜻이라고 풀어 설명한다.

6. 스킬을 평가하고 개선하는 방법

진행자는 제품이 계속 바뀌는데 스킬은 어떻게 유지하는지, 또 검증 체계가 충분히 믿을 만한지 어떻게 판단하는지 묻는다. 로렌의 답은 Eval(평가) 이다.

Eval은 에이전트 스킬을 위한 단위 테스트처럼 생각할 수 있다. 특별한 프레임워크가 반드시 필요한 것은 아니며, 원하는 수준의 엄밀성에 따라 직접 만들 수 있다. P-stack의 eval playbook은 상당히 체계적인 방식으로 스킬을 시험한다.

로렌의 방식에서는 메인 조정 에이전트가 먼저 스킬의 기대 행동을 평가할 루브릭을 만든다. 이후 여러 서브에이전트를 별도 디렉터리에서 실행해 작업하게 하고, 에이전트가 자신이 평가 대상이라는 사실을 눈치채지 못하도록 디렉터리 이름도 신경 쓴다. 에이전트는 평가받는다는 사실을 알면 행동이 달라질 수 있기 때문이다.

"에이전트는 자기가 평가받는다는 걸 알아차릴 수 있고, 알아차리면 행동을 바꿔요."

Cursor가 여러 모델을 지원한다는 점도 장점이다. 같은 스킬을 여러 모델에서 평가하여 어떤 모델에서 얼마나 잘 작동하는지 확인할 수 있다. 로렌은 스킬을 수정할 때마다 평가를 실행해 기대한 결과가 정말 나오는지 확인한다.

또 평가에는 점수를 매길 수 있고, 한 모델이 낸 평가 결과를 다른 모델이 심사하게 만들어 편향을 줄일 수도 있다. Cursor의 반복 기능을 이용해 "모든 항목이 10점 만점이 될 때까지 평가와 개선을 반복하라"는 작업도 가능하다. 그는 Control Glass 스킬도 이런 식으로 반복 개선했다고 설명한다.

그러나 스킬 유지에는 자동화만으로 해결되지 않는 부분도 있다. 사람은 초기 단계에서 에이전트의 도구 호출, 읽은 코드, 사고 과정 등을 유심히 보고 어디에서 실패하는지 포착해야 한다.

"좋은 스킬을 유지하려면 관찰력과 감각이 많이 필요해요. 일종의 아주 뛰어난 뒷좌석 운전자가 되어야 합니다."

그는 에이전트를 수동적으로 지켜보기보다, 초기에는 적극적으로 행동을 분석하고 결함을 발견해야 한다고 조언한다. 동료와 페어 프로그래밍을 하며 "왜 이렇게 했지?"라고 생각하는 것처럼, 에이전트의 결정을 추적하면서 반복 패턴을 찾고 이를 규칙이나 스킬로 바꾸는 방식이다.

7. 로컬 검증에서 클라우드 자동화로 확장하기

검증 시스템을 처음 만들 때는 로컬 환경에서 시작하는 것이 좋다고 로렌은 권한다. 로컬에서는 에이전트가 애플리케이션을 어떻게 띄우는지, 어떤 API를 호출하는지, 화면을 어떻게 조작하는지를 사람이 직접 관찰할 수 있기 때문이다.

"검증 스킬을 만든다면 로컬에서 시작하세요. 에이전트가 실제로 무엇을 하는지 관찰할 수 있으니까요."

하지만 로렌 자신은 현재 클라우드 에이전트를 적극적으로 사용하고 있다. 환경과 검증 스킬을 잘 마련하면, 클라우드 에이전트는 한 명의 개발자만 돕는 도구가 아니라 팀과 회사 전체를 강화하는 자동화 기반이 될 수 있다.

그 사례가 버그 리포트를 처리하는 내부 에이전트 Benny다. Benny는 들어오는 버그 보고를 받아 클라우드 환경에서 별도의 컴퓨터를 띄우고, Cursor를 실행해, 동일한 제어 스킬로 버그를 재현하려 한다. 단순히 "문제를 찾았다"는 수준을 넘어, 버그가 현재 메인 브랜치에서는 이미 수정됐는지도 확인할 수 있다.

"Benny가 버그를 재현했는데, 메인 브랜치에서는 이미 고쳐져 있다는 걸 확인해 줬어요. 그러면 저는 새 빌드만 릴리스하면 됩니다."

이 자동화는 사람이 한 시간 동안 "정말 고쳐진 문제인가?"를 확인하는 시간을 절약한다. 다만 로렌은 신뢰가 없는 상태에서 곧바로 수백·수천 개의 클라우드 에이전트를 돌리는 것은 피하라고 경고한다. 검증 체계가 없는 대량 실행은 토큰만 낭비하고 비용만 커질 수 있다.

진행자는 그의 여정을 다음처럼 정리한다.

1. 먼저 로컬에서 에이전트가 실제로 올바른 코드를 만드는지 검증하는 스킬을 만든다.
2. 신뢰가 생기면 클라우드에서 더 많은 에이전트가 버그 보고 같은 신호를 스스로 처리하도록 확장한다.
3. 마지막에는 PR 자동 병합까지 도달할 수 있다.

로렌은 이 요약에 동의하며, 이 과정에 지름길은 없다고 말한다.

"이건 에이전트에 대한 개인적인 신뢰 수준의 문제라서, 여기서 저기로 단번에 뛰어갈 수는 없어요."

8. AI 시대에는 리팩터링과 재작성도 다시 생각해야 한다

로렌은 AI 에이전트 시대에 리팩터링과 재작성(rewrite) 을 보는 관점도 바뀔 수 있다고 말한다. 전통적으로 엔지니어들은 "기존 시스템을 함부로 다시 쓰지 말라"고 조언한다. 새 회사에 입사해 낡은 코드를 보면 모두 갈아엎고 싶어지는 충동이 흔하지만, 대체로 위험한 일로 여겨진다.

그는 상황에 따라서는 재작성을 진지하게 고려할 이유가 있다고 주장한다. 특히 대형 기술 기업에서만 겪던 문제가 이제는 많은 조직의 문제가 되고 있다는 점을 지적한다. Meta처럼 수만 명의 개발자가 하나의 거대한 모노레포에 기여하면, 뛰어난 엔지니어가 많아도 코드 품질은 균일하게 높기 어렵다.

"AI 슬롭 코드 이전에는 인간 슬롭 코드가 있었죠."

대기업의 인프라와 개발 규칙은 대체로 팀에서 가장 경험이 적거나 실수할 가능성이 큰 구성원도 큰 사고를 내지 않도록 설계된다. 프레임워크, 관례, 권한 제한, 가드레일은 인턴이 실수로 운영 데이터베이스를 지우지 못하게 하는 식의 보호 장치다.

이런 장치가 잘 갖춰진 기존 코드베이스, 즉 브라운필드 애플리케이션은 AI 에이전트에게 오히려 좋은 환경일 수 있다. 에이전트는 이미 존재하는 제약과 관례 안에서 움직이므로 큰 사고를 낼 가능성이 줄어든다.

반면 새로 시작하는 그린필드 애플리케이션은 가장 큰 기회이면서도 위험한 영역이다. Grokbot처럼 빠르게 프로토타입을 만들고, 사람이 코드를 거의 읽지 않는 상태로 "바이브 코딩"을 하면, 에이전트는 매번 가장 빠르고 편한 길을 택한다. 시간이 지나면 코드베이스는 단기 해결책 위주로 쌓여 통제하기 어려워진다.

"가드레일이 전혀 없는 바이브 코딩 앱에서는 에이전트가 가장 편한 방식으로만 문제를 풀어요. 그러면 코드베이스가 점점 통제 불능으로 갑니다."

따라서 처음부터 강한 구조와 제약을 갖춰야 한다. 로렌은 Grokbot을 새 아키텍처로 재구성하는 데 600개 이상의 PR을 사용했고, 이 작업을 통해 이제는 모든 코드를 직접 읽지 않아도 될 정도의 신뢰를 얻었다고 말한다.

"더 이상 코드를 거의 보지 않는 상태까지 왔어요. 토큰을 팔려고 하는 말이 아니라, 코드를 안 봐도 되는 상태를 만들기 위해 엄청난 작업을 했다는 뜻입니다."

9. Dune 아키텍처와 강제되는 가드레일

Grokbot의 새 아키텍처는 내부적으로 Dune이라는 코드명으로 불린다. 로렌은 이를 Electron 앱을 위한 Next.js 같은 것으로 비유하며, 특히 에이전트가 코드를 잘 작성할 수 있도록 설계한 프레임워크라고 설명한다.

이 환경의 CI는 상당히 엄격하다. 에이전트가 자주 실패하거나 나쁜 습관을 보이는 부분은 가능한 한 모두 하드 규칙으로 막는다.

대표적으로 React의 useEffect 사용을 금지했다. 로렌은 useEffect가 React에서 큰 실수를 유발하기 쉬운 요소라고 본다. Dune에서 이를 쓰면 CI가 실패한다.

또 흥미롭게도 코드 주석도 금지했다. 에이전트가 맥락을 이해하지 못한 채, 일시적인 리뷰 피드백이나 과거의 대화를 영구적인 규칙처럼 주석에 기록하는 일이 많았기 때문이다.

"에이전트는 '로렌이 절대 이렇게 하지 말라고 했다' 같은 말을 주석으로 남겨요. 그런데 저는 그 PR의 특정 부분을 고치라는 것이었지, 전역 규칙을 만든 게 아니었죠."

그의 기본 원칙은 명확하다.

"에이전트가 못하는 것은 전부 금지합니다."

특히 Electron 앱에서는 렌더러 프로세스와 메인 프로세스의 분리가 중요하다. 렌더러 스레드는 UI를 그리므로, 60fps를 유지하려면 한 프레임이 약 16밀리초 안에 처리돼야 한다. 무거운 계산이나 많은 I/O 작업이 렌더러에 섞이면 프레임 드롭, 긴 작업, 버벅임이 발생한다.

Grokbot은 electron-main, electron-renderer처럼 디렉터리를 나누고, CI가 의존성 그래프를 검사해 한쪽 코드가 다른 쪽으로 잘못 import되지 않는지 강제한다. 즉 성능 문제를 리뷰어의 주의력에만 맡기지 않는다.

"렌더러에서 무거운 계산이나 I/O가 돌면 16밀리초를 넘는 긴 작업이 생기고, 결국 UI가 끊기게 됩니다."

로렌은 좋은 코드베이스를 위한 보호 체계를 여러 층으로 설명한다.

• 아키텍처와 디렉터리 구조: 기능별 코드를 한곳에 모으고, 가장 자연스러운 구현 경로가 곧 올바른 구현 경로가 되게 만든다.
• 정적 분석과 CI: 잘못된 import, 금지된 패턴, 성능 위험 요소 등을 빌드 단계에서 막는다.
• 린트와 컴파일러 진단: 반복되는 나쁜 패턴을 자동으로 탐지한다.
• 규칙·스킬·Bugbot: 에이전트에 지침을 제공하고, 코드 리뷰 도구로 문제를 추가로 찾는다.
• 명확한 기능 관례: 에이전트가 기존 패턴을 모방하기 쉽게 만들어 검색과 추측의 비용을 줄인다.

그는 특히 에이전트가 기존 코드를 복사하고 빠른 경로를 택하는 경향이 강하므로, "가장 짧은 길이 최선의 길" 이 되도록 설계해야 한다고 말한다.

"에이전트는 지름길을 좋아합니다. 그렇다면 그 지름길 자체가 가장 좋은 해결책이 되게 만들면 됩니다."

기능 단위 코드를 하나의 디렉터리에 모아 두면, 에이전트는 전역 검색을 반복할 필요 없이 해당 폴더에 들어가서 대부분의 작업을 끝낼 수 있다. 이는 에이전트를 "가장 능력이 낮은 에이전트" 기준으로 설계한다는 뜻이기도 하다.

10. 사람의 코드 리뷰에만 의존하지 말고 규칙을 코드화하라

로렌은 규칙, 스킬, Bugbot만으로는 충분하지 않다고 강조한다. 이런 요소는 유용하지만 에이전트가 잊거나 일관되게 따르지 않을 수 있는 소프트한 제약이기 때문이다. 강력한 CI, 타입 시스템, 아키텍처 제약처럼 위반 시 실제로 실패하는 장치가 필요하다.

"규칙과 스킬, Bugbot, 스타일 가이드만 있으면 코드베이스가 엉망이 되는 건 시간문제예요."

그는 Rust가 다시 주목받는 이유도 비슷하다고 본다. Rust 컴파일러와 소유권 검사기는 강한 제약을 제공한다. 물론 안전하지 않은 코드를 쓰지 않도록 해야 하지만, 적어도 코드가 컴파일되면 일정 수준의 신뢰를 얻을 수 있다.

"컴파일러가 강하게 강제해 주면, 사람이 일일이 가서 확인하지 않아도 됩니다."

반대로 최악의 상태는 모든 불변 조건과 규칙을 인간 리뷰어가 PR마다 직접 찾아내야 하는 '코드 리뷰 지옥' 이다. 리뷰에서 같은 지적을 반복하게 된다면, 그것은 시스템적으로 해결해야 할 코드 스멜이라고 본다.

"매번 PR에 '이렇게 하면 안 됩니다'라고 댓글을 달아야 한다면, 그걸 린트 규칙이나 CI 실패로 바꿀 방법을 생각해야 합니다."

즉 사람이 반복해서 발견하는 문제는 다음 중 하나로 바꿔야 한다.

1. 린트 규칙으로 자동 탐지한다.
2. CI 실패 조건으로 강제한다.
3. 아키텍처를 바꿔 그 실수 자체가 일어날 수 없게 만든다.

11. PR 크기와 Git 히지리의 의미

로렌의 PR은 수십 줄부터 수백 줄, 때로는 수천 줄까지 다양하다. 엄격한 크기 제한은 없지만, 그는 에이전트에게 큰 작업을 여러 개의 PR로 나누도록 권한다.

그 이유는 Git 히스토리가 중요한 맥락 정보이기 때문이다. 하나의 PR이 작은 단위의 변경을 명확히 설명하면, 버그가 생겼을 때 되돌리기 쉽고, 어떤 변경이 문제를 만들었는지 추적하기 좋다.

"Git 히스토리는 굉장히 풍부한 맥락의 원천이에요."

모든 변경을 수만 줄짜리 PR 하나에 넣으면 무엇이 왜 바뀌었는지 알기 어렵다. 원자적인 PR은 사람이 이해하기 위해서만이 아니라, 에이전트와 미래의 자동화 시스템이 변경 이력을 활용하기 위해서도 의미가 있다.

12. 토큰 비용은 지출이 아니라 투자 대비 효과의 문제다

시청자들은 로렌의 방식이 무제한에 가까운 토큰을 쓸 수 있는 AI 기업에서나 가능한 일인지 질문한다. 로렌은 자신이 AI 연구소에서 일하고 있어 토큰 사용에 큰 제약이 없다는 점을 솔직히 인정한다. 모두가 자신의 방식을 그대로 따라야 한다고 말할 수는 없다고 한다.

다만 토큰 사용을 단순 비용으로만 보면 안 되며, 특히 엔지니어링 리더나 스타트업 창업자라면 ROI(투자 대비 효과) 관점에서 판단해야 한다고 본다. 처음에 코드베이스를 리팩터링하고, 검증 체계와 CI 제약을 구축하는 데는 많은 토큰이 든다. 그러나 에이전트가 앞으로 코드의 대부분을 작성할 세계를 가정한다면, 그 초기 비용은 장기적으로 큰 효율을 가져올 수 있다.

"초기 단계에서 토큰을 많이 쓰게 되는 건 맞아요. 하지만 에이전트가 모든 코드를 쓰는 세상으로 가고 있다면, 그건 투자 대비 효과의 문제입니다."

그는 이런 시스템을 사람 혼자 구축하려면 수년이 걸릴 수도 있다고 말한다. 자신의 시간과 급여 역시 비용이므로, "사람을 추가로 고용할 것인가, 아니면 토큰을 써서 가장 단순한 에이전트도 잘 일할 수 있는 코드베이스를 만들 것인가"를 비교해야 한다는 것이다.

"제가 혼자 에이전트 이전 시대에 이 모든 리팩터링과 검증을 했다면 엄청 오래 걸렸을 거예요."

그 결과는 개인 생산성에만 머물지 않는다. PM, 디자이너, 익숙하지 않은 엔지니어도 지속 가능한 방식으로 코드에 기여할 수 있게 된다. 그는 토큰이 결코 공짜는 아니지만, 제대로 투자하면 팀 전체의 역량을 키우는 효과가 크다고 본다.

13. 비개발자도 에이전트와 함께 제품을 만드는 조직

마지막으로 진행자는 엔지니어들이 이렇게 빠르게 기능을 출시하면, PM이나 다른 직군은 어떻게 따라가는지 묻는다. 로렌은 이 지점에서 Grokbot의 역할이 매우 크다고 답한다.

기존 Cursor의 IDE, CLI, 에이전트 창은 강력하지만 기본적으로 개발자 중심 도구였다. 비개발자가 지식 노동에 활용할 수는 있어도, 그들의 작업 방식에 맞는 편안한 인터페이스라고 보기는 어려웠다.

반면 Grokbot은 기술 직군이 아닌 사람들에게 "Cursor를 처음 써 보는 순간"과 같은 경험을 제공한다고 설명한다. iMessage와 비슷하게 친숙한 인터페이스에서 에이전트에게 이름을 붙이고, 여러 에이전트를 팀원처럼 조율할 수 있다.

"Grokbot은 제 생각에 기술 분야 밖의 사람들을 위한 Cursor 순간이에요."

예를 들어 PM은 로렌이 밤사이 작업한 내용을 요약하는 에이전트를 둘 수 있다. 디자이너나 PM도 버그를 발견한 뒤 직접 수정하고 "이거 고쳤는데 검토해 줄래요?"라고 요청할 수 있다. 로렌은 실제로 그런 PR을 검토해 보면 완벽한 경우가 있다고 말한다.

"PM이 '버그가 있어서 제가 고쳤어요. 봐 줄래요?'라고 하면, 검토해 보고 '좋아, 승인'이라고 할 때가 있어요."

이것은 단지 AI가 코드를 잘 써서가 아니라, Dune 아키텍처와 엄격한 제약이 비전문가의 변경도 안전한 경로 안에서 이뤄지게 하기 때문이다. 결과적으로 디자이너와 PM도 직접 기능을 출시할 수 있고, Grokbot 팀은 훨씬 빠르게 움직일 수 있다. 🚀

14. 마무리

로렌 탄의 메시지는 AI 에이전트의 생산성을 높이는 핵심이 더 긴 프롬프트나 더 많은 에이전트를 무작정 돌리는 데 있지 않다는 것이다. 핵심은 검증 가능한 실행 환경, 제품 사용법을 알려주는 기능 맵, 반복 평가되는 스킬, 그리고 사람의 리뷰를 대체할 만큼 강제력 있는 아키텍처와 CI를 구축하는 데 있다.

"에이전트가 잘할 수 있는 환경을 만드는 것이 중요합니다."

결국 개발자의 역할은 모든 코드를 직접 쓰고 검토하는 데서, 에이전트와 비개발자까지도 안전하게 기여할 수 있는 시스템을 설계하는 방향으로 옮겨가고 있다. 로렌은 추가 질문이 있다면 트위터 DM으로 연락해 달라며 세션을 마무리한다.