Datasette Agent app_debug 업데이트: AI가 만든 웹앱을 브라우저에서 직접 검증하는 흐름

Datasette Agent의 app_debug 업데이트는 작아 보이지만 AI 개발 워크플로우에서 꽤 중요한 방향을 보여준다. Simon Willison은 2026년 8월 1일 Datasette Apps를 Datasette Agent로 만들고 수정할 때 쓸 수 있는 app_debug() 도구와 app_list() 도구를 소개했다. 핵심은 에이전트가 만든 앱을 보이지 않는 iframe 안에서 열고, JavaScript를 실행해 동작과 화면 크기를 직접 확인할 수 있다는 점이다.

지금까지 AI 코딩 에이전트는 코드를 읽고 수정하는 데 강해졌지만, 브라우저에서 실제 UI가 깨졌는지 확인하는 단계는 약했다. ‘테스트를 추가했다’고 말해도 실제 버튼이 보이지 않거나, 모바일 폭에서 레이아웃이 밀리거나, 렌더링 에러가 콘솔에 남는 문제는 놓치기 쉬웠다. app_debug 같은 도구는 이 간극을 줄인다.

무엇이 새로 나왔나

이번 업데이트에는 두 가지 도구가 포함됐다. app_list()는 사용자가 수정 권한을 가진 앱 목록을 보여준다. 에이전트가 어떤 앱을 편집할 수 있는지 확인하는 진입점이다. app_debug()는 앱을 브라우저 환경에서 열고, 에이전트가 제공한 JavaScript를 sandboxed iframe 안에서 실행한다. iframe은 opacity 0, pointer-events none으로 보이지 않고 직접 상호작용도 막는다.

이 구조가 흥미로운 이유는 에이전트가 코드만 보는 것이 아니라 실행 결과를 관찰한다는 점이다. DOM을 읽고, 특정 요소가 있는지 확인하고, 버튼 클릭 후 상태가 바뀌는지 검사하고, 요소 크기를 측정할 수 있다. 단순한 unit test가 아니라 브라우저 smoke test에 가깝다.

도구 자체는 Datasette 생태계에 속하지만 패턴은 범용적이다. AI가 웹앱을 만들면 바로 headless browser나 sandbox iframe에서 검증하고, 실패 결과를 다시 모델에게 돌려 수정하게 만드는 루프다. 앞으로 많은 개발 도구가 이 방식을 기본 기능으로 넣을 가능성이 높다.

왜 브라우저 검증이 필요한가

프론트엔드 버그는 타입 검사만으로 잡히지 않는다. CSS overflow, z-index 충돌, hydration mismatch, 버튼 접근성, 다크모드 대비, 모바일 viewport 문제는 코드 diff만 봐서는 놓치기 쉽다. 사람 개발자도 브라우저를 열어 확인한다. AI 에이전트도 같은 단계를 가져야 한다.

특히 AI가 만든 UI는 ‘컴파일은 되지만 이상한’ 상태가 자주 나온다. 예를 들어 카드 그리드가 3열이어야 하는데 긴 텍스트에서 깨지거나, submit 버튼이 disabled 상태로 고정되거나, 데이터가 비었을 때 skeleton만 무한히 보일 수 있다. 이런 문제는 DOM과 화면 상태를 직접 봐야 한다.

브라우저 검증은 에이전트의 자기 보고를 줄이는 효과도 있다. 모델이 “작동할 것입니다”라고 추정하는 대신 실제로 앱을 열고 document.querySelector() 결과와 console error를 확인한다. 개발팀 입장에서는 AI 결과물을 신뢰하기 쉬워진다.

실무 도입 시 조심할 점

브라우저 자동 검증을 붙인다고 모든 문제가 해결되지는 않는다. 첫 번째 리스크는 sandbox 권한이다. 에이전트가 실행하는 JavaScript는 가능한 한 제한된 컨텍스트에서 돌아야 한다. 쿠키, localStorage, 민감 API, 외부 네트워크 호출에 접근할 수 있다면 보안 문제가 생긴다.

두 번째 리스크는 flaky test다. 애니메이션, 비동기 로딩, 네트워크 지연이 섞이면 같은 검사가 성공했다가 실패할 수 있다. smoke test는 작고 결정적이어야 한다. ‘페이지가 열린다’, ‘핵심 버튼이 존재한다’, ‘콘솔 에러가 없다’, ‘모바일 폭에서 주요 CTA가 viewport 안에 있다’ 정도부터 시작하는 편이 좋다.

세 번째 리스크는 AI가 테스트를 통과하기 위해 UI를 망치는 경우다. 예를 들어 특정 selector만 만족하도록 의미 없는 hidden element를 넣을 수 있다. 따라서 검사 기준은 사용자 행동 중심이어야 한다. 텍스트 존재 여부, aria-label, 실제 클릭 결과, 화면 크기 측정처럼 사용자 관찰과 연결된 기준을 써야 한다.

적용 가능한 워크플로우

작은 팀이라면 PR마다 세 단계만 붙여도 효과가 있다. 첫째, AI가 코드를 수정한 뒤 dev server를 띄운다. 둘째, 브라우저 smoke test로 핵심 페이지 3개를 확인한다. 셋째, 실패 로그를 모델에게 다시 넣고 수정 요청을 한다. 이때 에이전트에게 무제한 수정을 허용하지 말고, 실패한 selector와 관련 파일만 보게 한다.

검사 항목은 페이지별로 다르게 둔다. 랜딩 페이지는 hero 텍스트, CTA, 이미지 로딩, 모바일 overflow를 본다. 대시보드는 데이터 empty state, 필터, 테이블 스크롤, 숫자 포맷을 본다. 폼 페이지는 validation message, submit disabled 조건, 성공 toast를 본다.

팀이 이미 Playwright를 쓴다면 AI 전용 smoke spec을 따로 만드는 것이 좋다. 전체 E2E는 느리고 유지비가 높다. AI 작업 후 빠르게 돌리는 검사는 30초 안에 끝나는 것이 이상적이다.

실행 체크리스트

• AI가 수정한 웹앱은 코드 리뷰 전에 브라우저 smoke test를 한 번 실행한다.
• 검사 기준은 selector 존재보다 사용자 행동과 화면 상태 중심으로 작성한다.
• sandbox iframe 또는 headless browser에는 쿠키, secret, production 데이터 접근을 최소화한다.
• 콘솔 에러, hydration mismatch, 모바일 overflow, CTA visibility를 기본 항목으로 둔다.
• 실패 로그는 파일 전체가 아니라 관련 DOM, console message, screenshot 요약만 모델에게 전달한다.
• AI가 테스트 통과용 hidden element를 추가하지 못하도록 accessibility와 실제 클릭 결과를 함께 본다.
• 전체 E2E와 별개로 30초 이내 AI smoke test suite를 운영한다.

출처: Simon Willison’s Weblog, Datasette Apps PR #33, Datasette Agent 0.4a0 관련 공개 기록.