검증 가능한 환경으로 AI 에이전트 팀을 만드는 법

URL: https://www.youtube.com/watch?v=OLYuAekOBeA
날짜: 2026-10-03
채널: Tech Bridge
영상 길이: 697초(약 11분 37초)

---

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

==AI 에이전트 개발의 병목은 코드를 생성하는 능력이 아니라, 에이전트가 실제 결과를 확인하고 잘못된 결과를 스스로 되돌릴 수 있게 만드는 검증 환경이다.==

• Lauren Tan은 X에서 poteto라는 이름으로 활동하며 SpaceX AI의 Grok Bot과 Cursor 관련 개발을 해 온 엔지니어다.
• 한 달에 프로덕션으로 반영한 2,500개의 PR(Pull Request)은 2,500개의 새 기능을 뜻하지 않으며, 코드 변경을 검토하고 반영하는 작업 단위의 공개 실적이다.
• 에이전트에게 애플리케이션을 실행하고 사람처럼 조작하며 디버깅할 손과 눈을 주면, 성공했다는 텍스트 응답이 아니라 실행 증거를 근거로 판단할 수 있다.
• 검증 도구만으로 충분하지 않으며, 에이전트가 읽고 확장하는 코드베이스 자체를 한 가지 올바른 경로로 유도해야 나쁜 패턴의 확산을 막을 수 있다.
• Slack·이슈 관리 도구의 외부 맥락을 받아 수정·검증하는 내부 루프와 연결하면, 에이전트가 버그를 발견하고 재현하며 PR을 여는 자동화가 가능해진다.

AI 에이전트를 한두 개씩 감독하는 단계에서 여러 작업을 병렬 처리하는 단계로 넘어가려면 자신감 있는 답변이 아니라 반복 가능한 실행, 관찰, 측정, 교정의 기반이 필요하다. 사람이 매번 같은 실수를 채팅으로 지적하는 방식보다 코드 구조, 정적 분석(Static Analysis), 린트(Lint), 규칙, 스킬(Skill)에 실수를 예방하는 제약을 새겨 넣는 방식이 더 높은 신뢰를 만든다.

1. 생산성 확장의 출발점은 에이전트에 대한 신뢰다

에이전트 수를 늘리는 일보다 에이전트가 만든 결과를 믿을 수 있는 환경을 먼저 만드는 일이 중요하다.

1.1. 2,500개 PR이라는 결과가 뜻하는 것

1. PR 수와 기능 수의 구분

   1. PR(Pull Request)의 의미: PR은 코드 변경을 검토하고 프로덕션에 반영하기 위한 요청 단위다.
   2. 수치의 해석: 한 달에 2,500개의 PR을 반영했다는 말은 공개된 변경 작업의 규모를 뜻하며, 2,500개의 완전히 새로운 기능을 만들었다는 뜻은 아니다.

2. 생성량보다 환경 설계가 핵심인 이유

   1. 표면적 성공의 한계: 에이전트가 “완료했다”고 말해도 앱을 열어 보면 문제가 남아 있을 수 있다.
   2. 연쇄 회귀(Regression): 한 곳의 문제를 다시 고치게 하면 다른 부분이 깨질 수 있어, 생성 결과만 늘리면 사람의 확인 부담도 함께 커진다.
   3. 신뢰의 조건: 에이전트의 답변이 그럴듯한지가 아니라 실제 결과를 확인할 수 있고 잘못됐을 때 다시 고칠 수 있는지가 신뢰를 결정한다.

1.2. Lauren Tan이 개인 프로젝트와 Cursor에서 출발한 방식

1. 처음부터 여러 에이전트에 모든 일을 맡기지 않음

   1. 개인 프로젝트의 한계: 초기에는 사람이 계속 방향을 바로잡아야 했으므로 여러 에이전트의 작업을 한꺼번에 맡기기 어려웠다.
   2. 사람이 맡은 관찰 업무: 에이전트가 코드를 바꾸더라도 성능 기록과 메모리 상태를 확인하고 결과를 전달하는 일은 사람이 직접 수행했다.

2. Cursor 에이전트 창의 성능 문제

   1. 수동 분석: Cursor의 애플리케이션 성능 문제를 Chrome DevTools로 직접 분석하고 성능 기록과 메모리 상태를 살폈다.
   2. 반복 작업의 병목: 코드 변경은 에이전트가 할 수 있었지만 실행, 성능 측정, 결과 확인을 사람이 맡으면 PR이 늘어날수록 검토 벽이 커졌다.
   3. 발상의 전환: 에이전트가 애플리케이션을 직접 실행하고 관찰하도록 도구부터 만들어야 성능 문제를 수정하는 반복 루프를 자동화할 수 있었다.

1.3. 신뢰의 사다리와 에이전트 규모 확장

1. 감독이 필요한 초기 단계

   1. 지속적인 코스 수정: 초기 에이전트는 대화마다 사람이 방향을 교정하고 개입해야 올바른 결과를 냈다.
   2. 확장의 위험: 신뢰가 없는 상태에서 에이전트 100개나 클라우드 에이전트를 병렬 실행하면 PR이 쏟아지고 회귀와 버그가 함께 늘어난다.

2. 병렬화의 전제

   1. 검증 가능한 결과: 에이전트가 실제 애플리케이션을 실행해 증거를 남겨야 사람이 모든 대화를 지켜보지 않아도 된다.
   2. 교정 가능한 환경: 잘못된 변경을 발견했을 때 원인을 추적하고 다시 실행할 수 있어야 신뢰가 누적된다.
   3. 사람의 역할 변화: 사람이 모든 코드 변경을 직접 만드는 병목에서 벗어나, 에이전트가 좋은 결과를 내도록 도구·규칙·코드베이스를 설계하는 역할로 이동한다.

2. 가장 중요한 스킬은 검증(Verification)이다

에이전트의 자기검증 능력은 성공 보고서보다 실제 실행 증거를 우선하게 만든다.

2.1. 에이전트에게 손과 눈을 주는 검증

1. 검증의 정의

   1. 애플리케이션 실행: 에이전트가 코드를 바꾸는 데 그치지 않고 애플리케이션을 직접 실행한다.
   2. 사용자처럼 상호작용: 실제 사용자가 누르는 버튼을 누르고 화면의 상태 변화를 확인한다.
   3. 실행 증거 수집: 디버깅(Debugging), 실행 추적(Trace), 스냅샷(Snapshot), 화면과 로그를 함께 확인한다.

2. 검증이 답변보다 강한 이유

   1. 보고서의 한계: 테스트가 통과했다는 텍스트 보고서는 화면이 깨졌거나 사용자의 실제 경로가 실패했다는 사실을 놓칠 수 있다.
   2. 행동 기반 확인: 앱을 열고 기능을 찾아 실제 버튼을 누르면 코드 경로와 사용자 경험을 동시에 확인할 수 있다.
   3. 성능 문제 적용: 성능 문제는 먼저 측정하고, 가설을 세우고, 코드를 바꾸고, 다시 측정하는 순환으로 접근한다.

2.2. 반복 가능한 검증 CLI와 기능 지도(Feature Map)

1. 검증 스킬의 CLI(Command-Line Interface)

   1. 재현성: 검증 때마다 에이전트가 새 스크립트를 만들게 하면 세션마다 실행 방법과 측정 방식이 달라진다.
   2. 고정된 실행 경로: 스킬 디렉터리 안에 CLI를 두고 모든 에이전트가 같은 방식으로 앱을 실행하고 증거를 수집하게 한다.
   3. 투자 대상: CLI는 다양한 사용 사례를 처리하고 애플리케이션을 올바르게 실행할 만큼 충분히 견고해야 한다.

2. 기능 지도가 필요한 이유

   1. 불완전한 버그 제보: Slack에 사용자가 아주 작은 화면 캡처와 물음표 몇 개만 올리면, 앱을 실행할 수 있는 에이전트도 그 캡처가 무엇을 뜻하는지 추측해야 한다.
   2. 사용자 관점의 맥락: 기능 지도는 사이트맵(Sitemap)처럼 기능이 무엇인지, 사용자가 어디에서 어떻게 접근하는지, 어떤 키보드 단축키와 DOM 요소를 사용하는지 기록한다.
   3. 행동 경로의 명시: 어떤 기능을 어디서 찾고 무엇을 눌러 어떤 결과를 얻는지 적어 두면 에이전트가 작은 캡처만 보고도 재현 경로를 찾을 수 있다.
   4. 유지 관리: 애플리케이션이 바뀌면 기능 지도도 바뀌므로 자동화로 최신 상태를 유지해야 한다.

3. CLI와 기능 지도의 결합

   1. 실행과 해석의 결합: CLI는 앱을 반복적으로 조작하고 추적을 수집하며, 기능 지도는 내부·외부 사용자의 모호한 요청을 앱의 실제 기능과 연결한다.
   2. 핵심 인프라화: 두 요소가 합쳐지면 에이전트가 자기 작업을 검증하는 기반이 되며, 팀의 지속적으로 관리해야 하는 핵심 인프라가 된다.

2.3. 검증 수준과 판단의 배분

1. 검증 스킬이 담당하는 영역

   1. 경험적 증거: 앱이 실제로 동작하는지와 성능 기준을 충족하는지 실행 결과, 추적, 스냅샷, 텔레메트리(Telemetry)로 확인한다.
   2. 결정론적 작업: 정해진 패턴으로 코드를 리팩터링하는 것처럼 매번 새로운 판단이 필요 없는 작업은 CLI와 코드로 고정한다.

2. 사람의 판단이 남아야 하는 영역

   1. 맥락 조합: 여러 정보 조각을 모아 무엇을 만들지 정하고, 서로 다른 요구사항의 우선순위를 판단하는 일은 여전히 사고가 필요하다.
   2. 검증 결과 해석: 측정값이 왜 변했는지, 사용자 경험이 요구사항에 맞는지, 어떤 가설을 다음에 시험할지는 사람이 판단하거나 그 판단을 명시적인 스킬로 전환해야 한다.

3. CLI 설계 원칙

   1. 결정론적 부분의 코드화: 반복되고 정해진 절차를 코드로 추출한다.
   2. 판단의 보존: 자동화가 오히려 잘못된 확신을 만들지 않도록 실제 판단이 필요한 부분만 남긴다.

3. 에이전트 친화적 코드베이스가 나쁜 패턴을 막는다

검증 도구가 결과를 확인한다면 코드베이스는 다음 에이전트가 어떤 패턴을 복사할지 결정한다.

3.1. 채팅 교정 대신 구조적 예방

1. 기존 코드의 영향

   1. 코드베이스는 기억: 에이전트는 매 PR마다 구조를 새로 설계하기보다 읽고 연 코드에 이미 있는 패턴을 확장한다.
   2. 좋은 패턴의 재사용: 잘 정리된 기존 코드와 일관된 규칙은 적은 맥락을 가진 에이전트도 올바른 변경을 이어가게 한다.

2. 임시방편의 전염

   1. 예외와 우회책의 확산: 한 번의 임시방편이나 이를 정당화하는 주석이 남으면 에이전트가 그것을 복사해 여러 위치에 퍼뜨릴 수 있다.
   2. 반복 지적의 한계: 같은 실수를 채팅에서 매번 지적하는 방식은 다음 세션의 에이전트와 다른 파일에 적용되지 않는다.
   3. 구조적 해결: 실수가 생기기 어렵게 데이터 구조·아키텍처·코드 경로를 바꾸거나, 최소한 린트 규칙으로 추가 확산을 막는다.

3.2. Dune 프레임워크와 하나의 포장된 경로

1. Dune의 목적

   1. 내부 프레임워크: Dune은 Grok Bot을 구동하는 에이전트 친화적 프레임워크이며, Cursor 에이전트 창에서 겪은 성능 문제의 교훈을 코드 구조에 반영한다.
   2. 지름길의 재정의: 에이전트가 지름길을 택하는 경향을 인정하고, 가장 쉬운 경로가 올바른 구현이 되도록 프레임워크를 설계한다.

2. 강한 제약과 관례

   1. 제한적인 린트 규칙: 나쁜 코드를 쓰기 어렵게 만드는 매우 제한적인 린트 규칙을 둔다.
   2. 한 가지 방식: 같은 일을 여러 방식으로 구현하게 두기보다 사실상 한 가지 올바른 경로를 제공한다.
   3. 기능별 디렉터리: 모든 기능은 정해진 위치에 들어가고, 각 기능은 자체 디렉터리를 갖는다.
   4. 기능 탐색: 레지스트리(Registry)와 코드베이스 탐색으로 기능을 발견할 수 있게 한다.

3. 사람과 에이전트의 인지 부담 감소

   1. 선택지 축소: 새 기능을 추가할 때 어디에 둘지 고민하지 않고 기능 디렉터리에 코드를 넣으면 되도록 만든다.
   2. God File 방지: 여러 책임을 한 파일에 계속 덧붙이는 거대한 God File을 만들지 않도록 기능별 경계를 둔다.
   3. 구조의 기억화: 에이전트가 매번 설계를 발명하지 않고 이미 정해진 관례를 따라가므로 사람의 정신적 부담과 에이전트의 판단 부담이 동시에 줄어든다.
   4. 초기 문제의 교훈: Grok Bot 초기 버전에는 거대한 파일이 여러 개 모여 있었고, 그 구조가 기능 디렉터리와 강한 경계를 도입한 배경이 됐다.

3.3. pstack과 경험의 스킬화

1. pstack의 역할

   1. 스킬 모음: pstack(P-Stack)은 Lauren Tan이 버그 조사, 기능 구현, 프로토타이핑, 성능 개선 등 자신의 개발 경험을 재사용 가능한 스킬과 작업 방식으로 정리한 컬렉션이다.
   2. 개발 방식의 전달: 단순 설치 패키지가 아니라 원하는 방식으로 코드를 작성하고 문제를 조사하도록 에이전트에 절차와 판단 기준을 전달한다.

2. pstack의 한계와 전제

   1. 검증 환경은 별도 구축: 스킬 모음을 설치하는 것만으로 프로젝트의 실행·관찰·성능 측정 환경이 생기지는 않는다.
   2. 프로젝트별 기반: 실제로 동작하는 도구와 좋은 코드 패턴, 프로젝트에 맞는 기능 지도가 함께 있어야 작업을 맡길 수 있다.
   3. 팀 지식의 저장소: 경험 많은 엔지니어는 개인 노하우를 팀 저장소의 스킬로 만들고, 검증 스킬과 결합해 정확성과 품질을 함께 높일 수 있다.

4. 외부 맥락과 내부 실행을 연결하는 에이전트 루프

버그 제보를 사람이 복사해 에이전트 채팅에 붙여 넣는 병목을 없애려면 외부 이벤트를 내부 검증 루프로 연결해야 한다.

4.1. 안쪽 루프와 바깥쪽 루프

1. 안쪽 루프(Inner Loop)

   1. 코드 작업: 에이전트가 코드를 수정하고 애플리케이션을 실행한다.
   2. 검증 작업: 기능을 재현하고 화면, 추적, 성능 기록을 확인하며 결과를 교정한다.

2. 바깥쪽 루프(Outer Loop)

   1. 외부 정보 수집: Slack, 이슈 관리 도구, 사용자 제보 같은 제품 바깥의 맥락을 받아온다.
   2. 다음 작업 선택: 여러 제보와 신호를 모아 어떤 문제를 재현하고 어떤 기능을 만들지 결정한다.

3. 두 루프를 연결하는 이유

   1. 맥락의 자율 획득: 에이전트가 사람이 전달해 준 요약만 기다리지 않고 필요한 원문과 상황을 직접 얻는다.
   2. 자동화의 연쇄: 외부 사건이 내부 실행과 검증을 자동으로 시작하므로 코드 변경과 제품 운영 사이의 지연이 줄어든다.

4.2. Slack 제보에서 재현 가능한 PR까지

1. 연결 구성

   1. Slack 접근: Slack MCP(Model Context Protocol)를 연결하거나 특정 채널을 구독하는 자체 하니스를 만든다.
   2. 이벤트 트리거: 버그 제보가 채널에 올라오면 에이전트가 해당 사건을 감지하도록 한다.

2. 에이전트의 처리 순서

   1. 제보 이해: 기능 지도와 외부 맥락을 이용해 제보가 가리키는 기능을 찾는다.
   2. 문제 재현: 이미 구축한 검증 스킬로 애플리케이션을 실행하고 사용자 행동을 재현한다.
   3. 현재 상태 확인: 문제가 현재 main 브랜치에도 존재하는지 확인한다.
   4. 원인 분리: 사용자의 설정이나 데이터, 의존성 미설치처럼 특정 환경에서만 생긴 현상인지 분리한다.
   5. 수정과 증거화: 원인을 수정하고 검증 결과를 남긴 뒤 PR을 연다.

3. 신뢰가 만들어지는 지점

   1. 도구의 조합: 검증 스킬 하나가 아니라 앱 실행, 기능 지도, 코드 규칙, 프로젝트별 스킬이 함께 작동해야 한다.
   2. 재현 가능한 판단: 에이전트가 “버그를 이해했다”고 주장하는 것보다 main에서 실제로 재현되고 수정 후 사라졌다는 증거가 중요하다.

4.3. 조정자와 반복 문제 관리

1. 중복 작업 방지

   1. 여러 제보의 통합: 비슷한 제보가 여러 건 들어오면 조정자 역할이 각 제보의 공통 원인을 비교한다.
   2. 에이전트 중복 투입 방지: 유사한 제보마다 에이전트를 하나씩 붙이면 같은 문제를 각각 수정해 충돌과 낭비가 생길 수 있다.

2. 나쁜 패턴의 기록

   1. 즉시 수정하지 않기: 나쁜 코드 패턴을 발견해도 매번 그 자리에서 고치는 대신 문서에 기록해 둔다.
   2. 패턴 분석: 기록이 쌓이면 서로 다른 버그의 공통 원인과 반복되는 문제를 찾아 구조나 린트 규칙으로 해결할 수 있다.
   3. 위임과 분해의 차이: 많은 일을 맡기는 것과 일을 중복 없이 잘 나누는 것은 별개의 문제다.

5. 대량 변경을 품질 감독하는 방법

모든 변경을 사람이 직접 맛보는 방식은 에이전트 생산량이 커질수록 유지되지 않으므로 표본과 프로세스의 품질을 관리해야 한다.

5.1. 주방과 공장 비유의 차이

1. 미슐랭 주방의 비유

   1. 창의적 결과물: 소프트웨어는 조립 라인에서 대량 생산하는 단순 제품보다 제품을 만드는 창의적 작업에 가깝다.
   2. 최종 책임: 에이전트가 개별 재료를 조리하더라도 사람은 최종 결과와 주방의 구성, 도구, 교육, 작업자 간 비율을 책임진다.
   3. 환경 설계: 좋은 요리사가 좋은 결과를 내도록 주방을 설계하듯, 에이전트가 기본값으로 올바른 코드를 만들도록 개발 환경을 설계한다.

2. 품질 감독자의 표본 검사

   1. 전수 검토의 불가능성: 공장 품질 감독자가 생산품 하나하나를 모두 맛보거나 검사할 수 없듯, 사람이 모든 PR의 모든 줄을 직접 확인할 수는 없다.
   2. 규칙적 샘플링: 매일 일정한 빈도로 PR 품질과 에이전트가 쓴 코드를 살펴보고 프로세스가 제대로 작동하는지 확인한다.
   3. 프로세스 개선: 샘플에서 반복되는 문제가 발견되면 특정 PR만 고치는 것이 아니라 규칙, 스킬, 타입, 제약을 수정한다.

5.2. 가드너(Gardener) 역할

1. 코드 정원 관리

   1. 잡초의 조기 제거: 작은 우회책과 임시 예외가 에이전트를 통해 코드 전체로 번지기 전에 찾아낸다.
   2. 깨끗한 상태 유지: 다음 에이전트가 그대로 복사해도 괜찮은 상태로 코드베이스를 계속 다듬는다.

2. 예방을 위한 세 가지 방향

   1. 기존 기술 부채 삭제: 이미 쌓인 나쁜 패턴과 기술 부채를 정리한다.
   2. 단일 포장 경로 유지: 대부분의 작업에 가장 권장되는 하나의 관례적 구현 경로를 유지해 에이전트가 추측하지 않게 한다.
   3. 린트 규칙으로 출혈 중단: 기술 부채를 즉시 전부 고치지 못하더라도 같은 패턴이 더 늘어나지 않도록 린트 규칙을 먼저 작성한다.

5.3. 쉽게 도달할 수 없는 고신뢰 환경

1. 설계에 필요한 노력

   1. 실패 지점 관찰: 에이전트가 어디에서 실패하는지 찾아야 한다.
   2. 의도적인 제약 설정: 에이전트가 기본적으로 올바른 일을 하도록 코드, 도구, 스킬, 규칙에 제약을 설계해야 한다.
   3. 시간과 토큰 비용: 검증을 여러 번 실행하는 데는 시간과 모델 토큰 비용이 들며, 높은 신뢰는 단순한 설정 하나로 얻어지지 않는다.

2. 적용 범위의 한계

   1. 되돌리기 어려운 변경: 롤백이나 재실행이 어려운 작업은 동일한 자동화 전략을 그대로 적용하기 어렵다.
   2. 프로그램으로 검증하기 어려운 영역: 형식화된 실행 증거를 얻기 힘든 분야에는 추가적인 사람의 판단과 전문성이 필요하다.
   3. 정답 없는 경우: 모든 상황에 통하는 하나의 해법이 있는 것은 아니므로, 먼저 어디에서 에이전트가 멈추는지 관찰하고 그 지점에 맞는 도구와 구조를 선택해야 한다.

6. 실행에 옮길 수 있는 워크플로우

에이전트에게 긴 지침을 계속 추가하기보다 실제로 확인할 수 있는 결과와 반복 가능한 경로를 먼저 제공한다.

6.1. 병목을 찾는 진단 순서

1. 실행 병목

   1. 에이전트가 앱을 실행해 보지 못하고 매번 사람에게 실행을 요청하는지 확인한다.
   2. 앱 실행, 버튼 조작, 로그·추적·스냅샷 수집을 하나의 재현 가능한 CLI로 만든다.

2. 맥락 병목

   1. 에이전트가 기능의 위치와 사용자 접근 경로를 몰라 작은 캡처를 해석하지 못하는지 확인한다.
   2. 기능 지도에 기능 위치, 조작법, 기대 결과, 알려진 주의점을 적고 앱 변경 시 자동으로 갱신한다.

3. 구조 병목

   1. 에이전트가 같은 코드 패턴을 반복해서 잘못 작성하는지 확인한다.
   2. 코드 구조를 바꾸고 린트·타입·정적 분석·CI 제약을 추가해 실수를 반복하기 어렵게 만든다.

6.2. 높은 신뢰를 쌓는 순서

1. 실제 결과 확인: 성공 보고서가 아니라 앱 실행, 사용자 상호작용, 추적과 측정값으로 결과를 검증한다.
2. 결정론적 절차 고정: 반복 절차를 CLI와 스킬로 코드화하고 세션마다 다른 스크립트가 생기지 않게 한다.
3. 코드베이스 정리: 기능 디렉터리, 관례, 단일 경로를 만들고 에이전트가 좋은 기존 패턴을 확장하게 한다.
4. 정적 제약 추가: 린트, 타입, 컴파일러 진단, CI로 나쁜 구현을 조기에 차단한다.
5. 규칙과 스킬 층화: 코드 구조 위에 규칙, 버그 봇(Bug Bot), pstack 같은 스킬을 쌓아 전문 지식과 작업 절차를 전달한다.
6. 외부 이벤트 연결: Slack과 이슈 도구를 바깥쪽 루프에 연결하고 재현·수정·검증·PR 생성까지 이어 붙인다.
7. 표본과 정원 관리: 모든 변경을 전수 검사하는 대신 규칙적으로 샘플링하고 반복되는 문제를 가드너 역할로 구조에 반영한다.

6.3. 분야 전문성의 지속적인 중요성

1. 무엇을 만들지 전달하는 능력

   1. 에이전트가 코드를 쓸 수 있어도 제품의 목적과 요구사항을 분명하게 전달할 사람은 필요하다.
   2. 모호한 요청을 기능 지도와 작업 계획으로 바꾸는 도메인 지식이 외부 루프의 품질을 결정한다.

2. 결과가 맞는지 판단하는 능력

   1. 측정값과 화면 결과가 요구사항을 충족하는지 판정할 전문성이 필요하다.
   2. 에이전트가 기다리는 것이 더 긴 지침인지, 직접 결과를 확인할 도구인지 먼저 구분해야 한다.

주요 발언 모음

“도구 상자에 넣어야 할 가장 중요한 단일 스킬은 검증(verification)이다.”

“에이전트에게 손과 눈을 주는 것과 같다. 에이전트가 코드를 실행하고, 일반 사용자처럼 애플리케이션과 상호작용하고, 디버깅하고, 추적과 스냅샷을 수집하게 한다.”

“결정론적인 부분을 코드로 추출하고 실제로 판단이 필요한 부분만 남기려 했다.”

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

“코드베이스는 에이전트가 확장하는 상태의 물질화된 기억이다.”

“공장 품질 감독자처럼 모든 항목을 볼 수는 없으므로 표본을 검사하고 프로세스를 계속 살펴봐야 한다.”

핵심 데이터 & 수치

• 영상 길이: 697초, 약 11분 37초다.
• 월간 PR 처리량: Lauren Tan이 공개적으로 소개한 프로덕션 반영 PR은 한 달 2,500개다.
• PR 해석: 2,500개의 PR은 코드 변경 반영 요청의 수이며 2,500개의 신규 기능 수와 동일하지 않다.
• 초기 성능 업무: Cursor 애플리케이션의 성능 기록과 메모리 상태를 사람이 직접 확인하던 업무가 검증 스킬 개발의 출발점이 됐다.
• 검증 증거: 앱 실행, 사용자 상호작용, 디버깅, 실행 추적, 스냅샷, 화면과 로그가 검증 재료다.
• 주요 시스템: 검증 CLI, 기능 지도(Feature Map), pstack 스킬 모음, Dune 에이전트 친화적 프레임워크가 서로 다른 층의 기반을 이룬다.
• 외부 연결: Slack 채널 구독과 MCP 또는 자체 하니스를 통해 버그 제보를 내부 수정·검증 루프로 전달한다.

결론 및 시사점

1. AI 에이전트의 생산성은 모델의 코딩 속도보다 결과를 반복 검증할 수 있는 환경의 품질에 좌우된다.
2. 첫 단계는 에이전트가 앱을 실행하고 사용자처럼 조작하며 추적과 스냅샷을 수집하게 만드는 검증 스킬이다.
3. 반복 절차는 고정 CLI로 만들고, 판단이 필요한 부분만 사람과 에이전트의 사고 영역으로 남겨야 한다.
4. 기능 지도는 모호한 버그 제보를 앱의 실제 기능·접근 경로·기대 결과로 변환하는 실행 가능한 기억이다.
5. 코드베이스를 에이전트의 기억으로 보고, 좋은 패턴만 복사되도록 기능 경계와 단일 구현 경로를 설계해야 한다.
6. 나쁜 패턴을 대화로만 교정하지 말고 아키텍처, 타입, 린트, 정적 분석, CI에 예방책을 새겨야 한다.
7. Slack과 이슈 관리 도구의 바깥쪽 루프를 앱 실행·수정·검증의 안쪽 루프와 연결하면 사람이 맥락을 전달하는 병목이 사라진다.
8. 에이전트 수를 늘리기 전에 신뢰를 쌓아야 하며, 신뢰 없는 병렬화는 PR·회귀·버그의 병렬 생산으로 이어진다.
9. 높은 신뢰 환경은 간단한 프롬프트가 아니라 실패 지점을 관찰하고 제약을 설계하는 장기 투자로 완성된다.
10. 전문가는 모든 변경을 직접 처리하는 사람이 아니라, 에이전트가 기본적으로 좋은 결과를 내는 주방과 정원을 운영하는 사람으로 역할을 확장한다.

핵심 요약 (20줄)

AI 에이전트 개발의 병목은 코드 생성보다 결과를 실제로 검증하는 능력에 있다.

Lauren Tan은 한 달에 2,500개의 PR을 프로덕션에 반영한 경험을 에이전트 신뢰의 사례로 제시했다.

2,500개의 PR은 2,500개의 신규 기능이 아니라 코드 변경을 검토하고 반영한 요청 단위다.

에이전트가 완료했다고 말해도 앱을 직접 열어 보면 문제가 남아 있거나 다른 부분이 깨질 수 있다.

가장 중요한 에이전트 스킬은 애플리케이션을 실행하고 결과를 확인하는 검증(Verification)이다.

검증 스킬은 에이전트에게 코드를 실행하고 사용자를 흉내 내며 디버깅할 손과 눈을 제공한다.

성공 보고서보다 화면, 로그, 실행 추적, 스냅샷으로 남긴 경험적 증거가 더 신뢰할 만하다.

반복 검증은 매번 새 스크립트를 만들지 않고 고정된 CLI로 실행해야 결과가 재현된다.

기능 지도(Feature Map)는 기능 위치, 사용자 접근 경로, 조작법, 기대 결과를 에이전트에게 알려 준다.

기능 지도는 앱이 변경될 때마다 갱신해야 하며 자동화된 유지 관리가 필요하다.

결정론적인 절차는 코드로 만들고 여러 맥락을 조합하는 판단만 사람과 에이전트에게 남겨야 한다.

검증 도구만으로 부족하므로 에이전트가 읽고 확장하는 코드베이스 자체를 에이전트 친화적으로 바꿔야 한다.

Dune은 정해진 관례와 강한 린트 규칙으로 에이전트가 올바른 단일 경로를 택하게 하는 내부 프레임워크다.

pstack은 버그 조사, 기능 구현, 프로토타이핑, 성능 개선 경험을 재사용 가능한 개발 스킬로 묶은 모음이다.

작은 우회책과 예외는 에이전트가 복사해 코드베이스 전체로 퍼뜨릴 수 있으므로 구조적으로 차단해야 한다.

Slack과 이슈 관리 도구의 바깥쪽 루프를 내부 수정·검증 루프와 연결하면 에이전트가 버그를 스스로 재현할 수 있다.

여러 제보에 에이전트를 중복 배치하지 않으려면 공통 원인을 찾는 조정자와 기록 체계가 필요하다.

모든 PR을 사람이 직접 검사할 수 없으므로 품질 감독자는 표본을 검사하고 반복 문제를 프로세스에 반영해야 한다.

높은 신뢰 환경은 실패 지점을 관찰하고 코드·도구·규칙에 제약을 설계하는 시간과 노력을 요구한다.

에이전트가 기다리는 것은 더 긴 지침이 아니라 직접 실행하고 결과를 확인할 수 있는 도구일 수 있다.