Lauren Tan(SpaceX - Cursor & Grok Bot 개발자)의 AI 에이전트 개발 워크플로우

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

로렌 탄의 AI 에이전트 개발 워크플로우는 직접 실행·검증할 도구와 일관된 코드 구조를 갖추고, 외부 제보부터 수정·검토까지 연결하는 데 초점을 둔다.

📌 핵심 요점

1. 한 달 2,500개 PR 반영은 본인이 공개한 실적이며, 2,500개의 새 기능을 만들었다는 의미는 아니다. 핵심은 변경량을 뒷받침한 개발 환경이다.
2. 검증은 테스트 통과 보고를 넘어 실제 앱 실행, 사용자 조작, 화면·트레이스·스냅샷 확인까지 포함한다. 기능 위치와 동작을 설명하는 피처 맵도 필요하다.
3. 반복 절차와 기계적인 변경은 CLI 등 코드로 고정하고, 에이전트에는 맥락을 종합하거나 가설을 세우는 판단을 남긴다.
4. 기능별 디렉터리, 관례, 엄격한 린트 규칙은 잘못된 패턴의 확산을 막는 기반이다. 스킬 설치만으로 프로젝트의 검증 환경이 완성되지는 않는다.
5. 외부 제보를 받는 바깥쪽 루프와 수정·검증하는 안쪽 루프를 연결하되, 중복 작업 조정과 정기적인 표본 검토로 작업 방식 자체를 개선한다.

🧩 배경과 문제 정의

AI가 코드를 완성했다고 보고해도 실제 앱에는 문제가 남거나 재수정 과정에서 다른 기능이 깨질 수 있다. 이 영상은 로렌 탄이 공개한 월 2,500개 PR 반영 사례를 출발점으로, 많은 변경을 맡기기 전에 어떤 실행·검증 도구와 코드 구조를 갖췄는지 설명한다. 해당 수치는 본인의 공개 실적이며 새 기능 수와 같지 않다. 중심 문제는 사람이 실행 결과와 외부 맥락을 계속 전달해야 하는 병목을 줄이면서, 에이전트의 작업을 확인하고 개선할 수 있는 환경을 만드는 것이다.

🕒 시간순 섹션별 상세정리

1. 많은 변경을 맡기기 전에 필요한 신뢰

• AI의 완료 보고 뒤에도 오류가 남는 문제를 제시하고, 월 2,500개 PR 반영이라는 공개 실적이 새 기능 2,500개를 뜻하지 않는다고 구분한다. [00:26]
• 초기에는 로렌이 직접 성능 기록과 메모리 상태를 확인해 에이전트에 전달했으며, 이 병목을 줄이기 위해 실행·관찰 도구부터 만들었다. [00:57]
• 여러 작업을 위임할 신뢰는 실제 결과를 확인하고 잘못됐을 때 다시 고칠 수 있는 환경에서 생긴다고 보여준다. [01:08]

2. 에이전트에 실행과 관찰 능력 제공

• 가장 중요한 스킬로 검증을 꼽으며, 에이전트가 코드를 실행하고 사용자처럼 조작하며 트레이스와 스냅샷을 확인할 수 있어야 한다고 드러낸다. [01:54]
• 검증은 테스트 보고서에 그치지 않는다. 실제 앱의 버튼, 화면, 실행 기록을 확인하고 기능 위치와 동작을 설명하는 피처 맵으로 맥락을 보완한다. [02:34]
• 검증할 때마다 새 스크립트를 만들면 실행 방식까지 달라질 수 있으므로, 반복 실행할 도구를 미리 마련한다. [02:43]

3. 반복 절차를 코드로 고정하고 판단을 남기기

• 맥락을 종합하는 판단 작업과 패턴을 바꾸는 기계적인 리팩터링을 구분한다. 반복 작업마다 새로운 해결 방식을 생각할 필요는 없다는 설명이다. [03:41]
• 결정적인 절차는 CLI와 코드로 추출하고 실제로 판단이 필요한 부분만 에이전트에 남긴다. [03:56]
• 성능 문제는 측정, 가설 수립, 코드 변경, 재측정으로 이어지는 수정·검증 흐름으로 다룬다. [04:06]

4. 좋은 코드 패턴과 제약으로 오류 예방

• 기존 코드의 예외와 임시방편은 다음 변경에도 복제될 수 있다. 내부 프레임워크 사례는 설치 안내보다 기능을 추가할 경로를 어떻게 제한했는지에 초점을 맞춰 보여준다. [04:35]
• 기능별 디렉터리, 레지스트리, 관례와 엄격한 린트 규칙으로 작업 경로를 명확히 한다. 초기 Grok Bot의 거대한 파일들이 기능별 디렉터리 구조를 마련한 계기로 드러난다. [05:56]
• 스킬 모음은 버그 조사·기능 구현·성능 개선의 접근과 도구를 전달하지만, 설치만으로 프로젝트의 검증 환경이 생기지는 않는다. [06:19]

5. 외부 제보와 내부 검증 연결

• 슬랙이나 이슈 도구의 제보를 사람이 매번 옮기는 병목을 설명하고, 외부 맥락을 받는 바깥쪽 루프와 코드 수정·검증의 안쪽 루프를 구분한다. [06:37]
• 슬랙 채널의 버그 제보를 받아 기존 검증 스킬로 재현하고, 현재 메인 코드의 문제인지 사용자 설정·데이터·의존성 문제인지 확인하는 흐름을 제시한다. [08:06]
• 비슷한 제보에 각각 에이전트를 붙이면 중복 수정이 생길 수 있다. 문제 패턴을 문서에 모아 공통 원인을 찾는 조정 역할이 필요하다고 보여준다. [08:33]

6. 표본 검토와 환경 개선, 적용 조건

• 모든 변경을 직접 확인하기 어려운 상황에서는 PR과 생성 코드를 정기적으로 표본 검토하며 품질과 작업 과정을 살핀다고 보여준다. [09:29]
• 발견한 문제를 스킬·타입·제약에 반영해 개입 지점을 줄이되, 이런 환경에는 코드와 실패 지점을 분석하는 상당한 시간과 노력이 필요하다. [10:37]
• 반복 검증의 토큰 비용과 적용하기 어려운 분야를 짚고, 사람이 개입하는 병목에 맞춰 도구와 구조를 갖추라고 제안한다. 분야 전문성과 결과 판단의 중요성을 강조한 뒤 원본 대담·강의 링크 안내와 감사 인사로 마무리한다. [11:33]

🧾 결론

• 에이전트에 대한 신뢰는 자신 있는 답변보다 결과를 관찰하고 실패를 수정할 수 있는 환경에서 쌓인다.
• 반복되는 오류는 대화에서 계속 지적하는 데 그치지 않고 도구, 코드 패턴, 타입과 제약에 반영해야 한다.
• 사람의 역할은 무엇을 만들지 명확히 전달하고 결과를 판단하며, 에이전트가 자주 실패하는 환경을 개선하는 쪽으로 이동한다.

📈 투자·시사 포인트

• AI 개발 도구를 평가할 때 코드 생성 능력과 함께 실행·관찰·검증 도구, 외부 업무 맥락과의 연결 능력을 살펴볼 필요가 있다.
• PR 처리량만으로 생산성을 판단하기 어렵다. 변경의 내용과 품질, 사람이 검증에 들이는 작업을 함께 봐야 한다.
• 자동화의 효과를 평가하려면 도구 구축 시간, 피처 맵과 코드 구조의 유지 비용, 반복 검증에 드는 토큰 비용을 함께 고려해야 한다.

⚠️ 불확실하거나 확인이 필요한 부분

• 월 2,500개 PR은 본인의 공개 실적이다. 영상에는 개별 변경의 규모, 오류율, 검토 방식의 세부 수치나 독립적인 검증 자료가 제시되지 않는다.
• 내부 프레임워크와 스킬 모음의 명칭에는 전사상 불명확한 부분이 있다. 내부 프레임워크를 공개 설치 도구로 받아들이지 말라는 설명도 포함된다.
• 표본 검토의 비율과 선정 기준, 반복 검증의 토큰 비용, 도구 구축에 필요한 시간은 구체적으로 제시되지 않는다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 최근 에이전트 작업에서 사람이 앱 실행, 기능 위치 설명, 반복 오류 수정 때문에 개입한 지점을 기록한다.
• 자주 확인하는 사용자 흐름을 직접 실행하고 화면·실행 기록을 수집할 수 있는 재사용 도구를 마련한다.
• 기능 위치와 조작 결과를 설명하는 피처 맵을 만들고 앱 변경 시 함께 갱신한다.
• 기계적인 변경과 반복 검증 절차를 코드로 고정하고, 에이전트가 판단해야 할 부분을 구분한다.

❓ 열린 질문

• 어떤 변경을 표본 검토 대상으로 삼고, 어느 수준의 오류가 나오면 검토 범위를 넓혀야 할까?
• 검증 도구와 제약을 추가하는 비용이 사람의 개입 감소 효과를 넘어서는 지점은 어디일까?
• 되돌리기 어렵거나 자동 검증이 어려운 작업에서는 어떤 확인 절차를 추가해야 할까?