AI 코딩 에이전트를 믿으려면: Lauren Tan의 검증·스킬·CI 설계

AI가 코드를 빨리 작성해도, 사람이 매번 앱을 열고 오류를 복사해서 돌려줘야 한다면 전체 작업은 쉽게 빨라지지 않는다. 코드 생성이 아니라 검증하는 사람이 병목이 되기 때문이다.

Lauren Tan의 발표에서 가장 중요한 메시지는 이 지점이다. 에이전트 수를 늘리기 전에, 에이전트가 자기 작업을 직접 확인할 수 있는 환경부터 만들어야 한다. 그리고 검증 능력만으로 부족한 부분은 코드 구조와 CI의 강제 규칙으로 보완한다.

이 글은 약 55분 분량의 사용자 공유 영상의 영어 자동 자막을 바탕으로 정리했다. 영상 화면의 데모를 직접 재현한 리뷰는 아니다. 업로드 제목은 SpaceX AI Engineer Lauren Tan: Part 1이며, 본문은 소속이나 제품 홍보보다 발표에서 설명하는 개발 방식에 초점을 맞춘다. 자동 자막의 고유명사 표기가 불안정한 부분은 상세 명칭을 생략했다.

1. 신뢰는 프롬프트가 아니라 검증에서 나온다

초반부에서 발표자는 에이전트를 신뢰하지 못하면 사람이 모든 출력을 감시하게 된다고 설명한다. 한 에이전트의 결과도 확인하기 힘든데 열 개를 병렬로 실행하면 검토할 일만 늘어난다.

여기서 말하는 신뢰는 “모델이 똑똑하니까 맞을 것”이라는 기대가 아니다. 결과가 맞는지 확인할 수 있기 때문에 위임할 수 있는 상태에 가깝다.

발표자는 많은 PR을 처리하고 일부 PR을 자동 병합하는 자신의 경험도 소개한다. 하지만 이는 발표자의 자기 보고이지, 누구나 동일한 생산성이나 품질을 얻는다는 비교 실험은 아니다. 오히려 후반부에서 그 상태에 도달하기까지 상당한 리팩터링과 토큰 투자가 필요했다고 설명한다.

2. Verification skill: 에이전트가 앱을 직접 사용하게 한다

검증 스킬 설명에서 핵심은 에이전트가 코드를 읽는 데 그치지 않고 실제 실행 결과에 접근하는 것이다.

애플리케이션을 실행하고 문제가 생기는 화면에 진입한다.
사용자 동작을 재현한다.
필요하면 CPU trace나 heap snapshot 같은 진단 자료를 수집한다.
수정 후 같은 상황에서 동작이 달라졌는지 확인한다.

발표에서 소개하는 개발 방식은 다음처럼 요약할 수 있다.

문제 보고 → 실제 재현 → 코드 조사·수정 → 같은 경로로 재검증
                      ↑                         │
                      └──── 실패하면 반복 ───────┘

이 루프가 없으면 사람은 에이전트와 앱 사이에서 스크린샷과 오류 메시지를 전달하는 중계자가 된다. 반대로 실행·관찰·수정이 연결되면 에이전트가 자기 가설이 틀렸다는 사실을 확인할 수 있다.

중요한 구분도 있다. 실행 결과가 맞는 코드와 장기적으로 좋은 코드는 다르다. 특정 시나리오가 성공했다고 설계 품질이나 모든 예외 상황까지 보장되지는 않는다. 그래서 발표는 검증 다음에 아키텍처와 강제 규칙을 이야기한다.

3. Feature map: 조작 도구만 있어서는 부족하다

약 10분부터 등장하는 feature map은 특히 실용적이다. 에이전트에게 브라우저나 앱 조작 기능을 줘도, 제품의 어느 화면에 어떤 기능이 있는지 모르면 시간을 낭비한다.

“왼쪽 사이드바가 느리다”는 제보를 받았다고 하자. 에이전트는 사이드바가 무엇인지, 어떻게 진입하는지, 어떤 하위 기능을 조작해야 하는지 알아야 한다. Feature map은 이런 제품 탐색 지식을 제공한다. 발표에서는 진입 경로, 단축키, UI 요소를 선택하는 속성 등이 언급된다.

아래는 이 아이디어를 우리 제품에 적용한다면 작성할 수 있는 예시다. 영상에 나온 원본 파일은 아니다.

기능: 검색 결과 필터
진입 경로: 프로젝트 열기 → 검색 실행 → 결과 화면의 필터 패널
준비 상태: 검색 가능한 테스트 문서가 있는 프로젝트
조작 대상: 문서 유형 필터와 결과 목록
확인 사항: 필터 변경 후 결과 목록이 선택 조건과 일치하는가
진단 자료: 실패 시 화면, 콘솔 오류, 관련 요청 결과

즉, 조작 도구가 손이라면 feature map은 제품 안내서다. UI가 바뀌면 이 안내서도 함께 갱신해야 검증 스킬이 계속 유효하다.

4. 스킬은 실패를 관찰해서 만들고, eval로 확인한다

스킬을 만든 과정에서 발표자는 처음부터 거대한 지침 체계를 설계한 것이 아니라고 설명한다. 실제 에이전트가 실패하는 모습을 보고 조금씩 스킬을 추가했다.

예를 들어, 관련 코드를 제대로 읽지도 않고 원인을 단정하는 문제가 반복된다면 “추측하지 마”라는 지적만으로 끝내지 않는다. 어떤 코드를 조사하고 어떤 근거를 확인해야 하는지 작업 절차로 만든다. 발표에서 소개하는 Pstack은 이런 엔지니어링 관행을 묶은 스킬·플러그인 사례다.

그러나 Markdown 지침을 잘 썼다고 실제 행동이 개선되는 것은 아니다. 약 17분 이후에는 스킬 자체를 평가하는 eval이 등장한다.

스킬이 유도해야 할 행동을 평가 기준으로 정의한다.
여러 실행에서 그 행동이 실제로 나타나는지 관찰한다.
사용하는 모델이 여러 개라면 모델별 차이도 확인한다.
스킬을 수정한 뒤 다시 평가한다.

발표자는 다른 모델을 평가자로 활용하는 방식도 언급한다. 다만 평가자의 점수가 높다는 것과 실제 제품 품질이 높다는 것은 같지 않다. 실무적으로는 점수뿐 아니라 문제 재현 여부, 실행 기록, 실제 결과물을 함께 보는 편이 타당하다. 이는 발표 내용을 바탕으로 덧붙인 적용 관점이다.

5. 아키텍처와 CI: 좋은 방법을 가장 쉬운 방법으로 만든다

아키텍처 논의의 요지는 에이전트가 기존 패턴과 손쉬운 해결책을 따라간다는 것이다. 그러므로 올바른 구현 경로 자체를 단순하고 일관되게 만들어야 한다.

발표에서 설명하는 사례에는 기능별 코드 모으기, 프로세스별 디렉터리 분리, 의존성 경계 검사 등이 있다. 특히 Electron 앱에서 렌더러 쪽으로 무거운 작업이 잘못 유입되면 UI 응답성이 나빠질 수 있다는 문제를 다룬다. 디렉터리 이름만 나누는 것이 아니라, 경계를 넘는 import를 CI가 검사하도록 만든다.

약 38분 이후 설명을 정리하면 강제력의 차이가 선명하다.

계층	역할	주의할 점
코드 구조와 관례	정상 구현의 경로를 단순하게 만든다	기존 예제가 나쁘면 그 패턴도 복제된다
정적 분석·컴파일러·CI 검사	명시한 위반을 기계적으로 차단한다	검사하지 않는 문제까지 보장하지 않는다
규칙 문서·스킬·AI 리뷰	맥락과 판단 기준을 제공한다	잊거나 일관되게 적용하지 못할 수 있다

발표자는 특정 프로젝트에서 useEffect나 코드 주석을 금지한 사례도 소개한다. 이것을 모든 React 프로젝트의 보편 규칙으로 받아들일 필요는 없다. 배울 부분은 반복해서 발견한 실패 패턴을 사람의 리뷰 지적에만 남겨두지 않고 자동 검사로 옮긴다는 원칙이다.

이 구분은 중요하다. “이런 import는 하지 마”라고 문서에 쓰는 것과 해당 import 때문에 CI가 실패하는 것은 강제력이 다르다.

6. 로컬에서 검증하고, 신뢰가 쌓이면 확장한다

약 24분 전후에서 발표자는 처음에는 로컬에서 시작하라고 권한다. 에이전트가 앱을 제대로 실행하는지, 엉뚱한 UI를 누르는지, 검증을 건너뛰는지 관찰하기 쉽기 때문이다.

이후 동일한 검증 능력을 클라우드 환경으로 옮기면 팀 전체가 활용할 수 있다. 발표의 버그 처리 사례에서는 에이전트가 제보를 재현하고, 현재 main에서는 이미 고쳐졌다는 사실을 확인한다. 무조건 새 코드를 만드는 것이 아니라 추가 수정이 필요한지부터 판별하는 것도 자동화의 가치다.

바로 수많은 에이전트나 자동 병합부터 도입하라는 이야기는 아니다. 비용 관련 Q&A에서도 발표자는 자신에게 풍부한 토큰 자원이 있으며, 모두가 같은 방식으로 투자할 수 있는 것은 아니라고 인정한다.

실무 적용: 가장 자주 반복하는 검증 하나부터

아래 순서는 발표 내용을 바탕으로 정리한 적용 제안이다.

자주 발생하는 버그나 사용자 흐름 하나를 고른다. 처음부터 제품 전체를 자동 검증하려 하지 않는다.
실행 방법과 feature map을 정리한다. 필요한 테스트 데이터와 재현 조건도 명시한다.
수정 전후를 같은 방법으로 확인하게 한다. 완료 보고가 아니라 실행 결과를 근거로 삼는다.
반복되는 리뷰 지적 하나를 자동 검사로 옮긴다. 기존 린터·타입 검사·의존성 검사로 표현할 수 있는지 먼저 살펴본다.
스킬 변경의 효과를 평가한다. 성공률뿐 아니라 사람이 다시 손댄 횟수, 회귀, 실행 비용을 함께 본다.
검증이 안정된 작업부터 위임 범위를 넓힌다. 자동 병합 여부는 변경 위험도와 검사 범위를 별도로 판단한다.

결국 이 발표는 “AI가 알아서 개발해준다”는 이야기보다 AI가 제대로 일할 수 있도록 개발 환경을 설계하는 일에 가깝다. 사람이 모든 변경의 검증자가 되는 대신, 반복 가능한 검증과 실패를 막는 구조를 만든다. 에이전트의 수보다 그 기반이 먼저다.

출처: SpaceX AI Engineer Lauren Tan: Part 1 — 사용자 공유 영상. 영어 자동 자막 기준으로 요약했으며, 타임스탬프는 해당 업로드 기준이다. 발표자의 생산성·자동 병합 사례는 독립적으로 검증하지 않았고, 실무 적용 예시와 제안은 원문 설명과 구분해 덧붙였다.