제10장 Browser Subagent: UI 검증의 자동화

코드는 거짓말을 안 한다고들 말합니다. 그런데 UI 앞에서는 이야기가 조금 달라집니다. 코드만 보면 맞아 보이는데, 실제 브라우저를 열면 버튼이 찌그러져 있고, 모바일에서는 카드가 반쯤 잘려 있고, 제출 버튼을 누르는 순간 콘솔에서 빨간 에러가 터지는 일이 아주 흔합니다. 프론트엔드 작업이 유난히 피곤한 이유가 여기에 있습니다. 코드가 맞는지와 화면이 맞는지는 같은 질문이 아니기 때문입니다.

Antigravity의 Browser Subagent는 바로 이 간극을 메우기 위해 등장합니다. 에이전트가 파일과 터미널만 다루는 데서 멈추지 않고, 실제 Chrome 브라우저를 열어 클릭하고, 스크롤하고, 입력하고, 콘솔을 보고, 스크린샷과 녹화까지 남기며 결과를 검증하는 흐름입니다.¹ 이 순간부터 Antigravity는 "코드를 써 주는 도구"라기보다 "만든 것을 스스로 확인하는 작업자"에 가까워집니다.

코드 검토에서 화면 검증으로, 질문이 바뀐다

많은 AI 코딩 도구는 여기까지는 잘합니다. 코드를 수정하고, diff를 보여 주고, 테스트를 돌립니다. 문제는 그다음입니다. 정말 사용자가 보게 될 화면이 의도대로 바뀌었는가? 클릭했을 때 반응은 자연스러운가? 콘솔 에러는 없는가? 로딩 이후의 상태는 괜찮은가? 이 질문 앞에서는 갑자기 사람이 다시 브라우저를 열고 QA 담당자가 됩니다.

Browser Subagent가 주는 가장 큰 차별점은 이 마지막 수작업을 줄여 준다는 데 있습니다. Antigravity 공식 문서에 따르면 이 서브에이전트는 브라우저 안에서 클릭, 스크롤, 타이핑, 콘솔 로그 읽기 같은 상호작용 도구를 사용할 수 있고, 열린 페이지를 DOM 캡처, 스크린샷, 마크다운 파싱으로 읽고, 필요하면 비디오까지 남길 수 있습니다.¹ 즉, "코드를 바꿨다"에서 끝나지 않고 "그래서 실제로 어떻게 보였고, 어떻게 동작했다"까지 한 번에 이어집니다.

이 차이는 생각보다 큽니다. 예전에는 에이전트가 "수정 완료"라고 말하면 개발자가 브라우저를 열어 직접 확인해야 했습니다. 이제는 에이전트가 브라우저까지 열고, 자기 손으로 눌러 보고, 그 흔적을 Artifact로 남깁니다. 말보다 증거가 하나 더 붙는 셈입니다.

Browser Subagent는 어떻게 움직이는가

겉으로 보면 단순합니다. 에이전트가 브라우저를 조작합니다. 하지만 내부적으로는 역할이 분리되어 있습니다. 사전 리서치 자료에 따르면 브라우저 서브에이전트는 메인 에이전트와는 별도의, 브라우저 상호작용에 특화된 모델로 실행될 수 있습니다.² 이 말은 꽤 중요합니다. 코드를 잘 쓰는 능력과 화면에서 요소를 찾고 상호작용하는 능력은 완전히 같은 종류의 일이 아니기 때문입니다.

실무 감각으로 풀어보면 흐름은 대략 이렇습니다. 메인 에이전트가 "이제 UI를 확인해야 한다"고 판단하면 Chrome 통합을 통해 브라우저 작업을 위임합니다. 그러면 Browser Subagent가 페이지를 읽고, 필요한 요소를 찾고, 버튼을 누르고, 폼을 입력하고, 콘솔을 확인하고, 결과를 스크린샷이나 녹화로 남깁니다.³ 사용자가 보기엔 하나의 에이전트가 일하는 것처럼 보이지만, 사실상 브라우저 안에서는 더 시각적이고 상호작용 중심적인 작은 전문가가 따로 뛰는 셈입니다.

흥미로운 디테일도 있습니다. 브라우저가 실제로 에이전트의 제어를 받을 때는 창 가장자리에 시각적 표시가 나타나 사용자가 "지금은 사람이 아니라 에이전트가 운전 중"이라는 사실을 알 수 있습니다.³ 이건 작은 UX처럼 보이지만, 신뢰에는 꽤 중요합니다. 어느 순간 누가 클릭하고 있는지 모르면 자동화는 순식간에 공포 영화가 되기 때문입니다.

브라우저 안에서 에이전트가 할 수 있는 일

Browser Subagent의 핵심은 "브라우저를 연다"가 아닙니다. 브라우저를 읽고, 행동하고, 확인한다는 데 있습니다.

할 수 있는 일은 생각보다 넓습니다.

• 버튼과 링크를 클릭하고 페이지를 이동한다

• 입력창에 값을 넣고 드롭다운을 선택한다

• 스크롤하며 화면의 아래쪽 상태를 확인한다

• DOM 구조를 읽고 현재 페이지 내용을 해석한다

• DevTools 콘솔 로그를 읽어 오류를 찾는다

• 스크린샷과 브라우저 녹화를 Artifact로 남긴다¹³

여기서 중요한 것은 도구 목록 자체가 아닙니다. 이 조합이 만들어내는 검증 방식입니다. 예를 들어 "로그인 폼을 수정했다"는 작업은 이제 단순히 파일 diff만 보는 문제가 아닙니다. 입력창에 실제로 값을 넣어 보고, 제출해 보고, 에러 메시지가 어디 뜨는지 보고, 성공 후 리다이렉트가 자연스러운지 보는 일까지 포함됩니다. 코드는 구현이고, 브라우저는 증명입니다.

Chrome 통합이 왜 중요한가

Antigravity는 브라우저를 별도의 외부 테스트 도구처럼 취급하지 않습니다. 개발 워크플로우 안에 붙어 있는 실행 표면으로 다룹니다. Chrome 확장과 연동되면 에이전트는 로컬에서 실행 중인 앱을 열고, 그 앱을 사람처럼 검사할 수 있습니다.³ 설치 이야기는 앞 장에서 했으니 여기서는 핵심만 보겠습니다. 중요한 건 이 통합 덕분에 브라우저 검증이 "나중에 따로 하는 QA"가 아니라 "구현 직후 이어지는 자동 확인"으로 바뀐다는 점입니다.

예를 들어 Next.js 앱에서 헤더를 수정했다고 합시다. 기존 방식이라면 코드를 생성한 뒤 개발자가 직접 npm run dev 상태를 보고 브라우저를 띄워 헤더를 확인합니다. Browser Subagent가 있으면 에이전트가 변경 후 페이지를 열고, 헤더 정렬을 보고, 메뉴를 눌러 보고, 콘솔 에러까지 확인한 뒤 스크린샷을 남길 수 있습니다. 이 흐름은 별것 아닌 것처럼 보여도, 사람이 하던 "마지막 확인 루프"를 상당 부분 없애 줍니다.

특히 UI 작업에서 이 체감은 강합니다. 텍스트 기반 코드 리뷰는 여전히 필요하지만, 화면이 개입되는 순간 최종 판정은 거의 늘 브라우저가 내립니다. Antigravity는 그 브라우저 판정을 에이전트의 책임 범위 안으로 끌어옵니다.

콘솔까지 본다는 것은, 눈뿐 아니라 귀도 생긴다는 뜻이다

브라우저 자동화라고 하면 많은 사람이 클릭과 스크린샷만 떠올립니다. 하지만 실전에서는 콘솔 로그 확인이 아주 중요합니다. 화면은 얼핏 멀쩡해 보여도 콘솔에는 경고와 에러가 줄줄이 쌓여 있는 경우가 많기 때문입니다. Antigravity의 Browser Subagent는 DevTools 콘솔 로그를 읽을 수 있습니다.¹³

이 기능이 좋은 이유는 단순합니다. 사람이 놓치기 쉬운 실패를 먼저 잡아 주기 때문입니다. 예를 들어 버튼을 눌렀더니 화면은 얼핏 유지되지만, 실제로는 Cannot read properties of undefined가 발생하고 있을 수 있습니다. 또는 API 500 에러가 나는데 프론트엔드가 어설프게 삼켜서 사용자는 "그냥 잠깐 느렸나?" 정도로 느낄 수도 있습니다. 이런 상황에서 에이전트가 콘솔 로그까지 같이 읽으면, 스크린샷 한 장으로는 절대 보이지 않는 사실이 드러납니다.

쉽게 말해 Browser Subagent는 화면을 보는 눈만 얻는 것이 아닙니다. 브라우저 내부에서 들려오는 비명도 함께 듣습니다.

모바일 뷰포트 테스트가 쉬워지는 순간

브라우저 서브에이전트가 특히 빛나는 장면은 반응형 UI입니다. 데스크톱에서는 잘 보이는데 모바일에서 망가지는 문제는 프론트엔드의 고전입니다. 카드 그리드가 갑자기 한 줄로 무너지고, 버튼이 화면 밖으로 밀리고, 고정 헤더가 콘텐츠를 가리고, 입력창이 키보드와 겹치는 식의 문제는 코드만 읽어서는 잘 안 보입니다.

Antigravity 관련 가이드는 여러 에이전트를 사용해 서로 다른 뷰포트와 설정을 병렬로 검증하는 패턴도 소개합니다.³ 이 아이디어는 꽤 실용적입니다. 하나의 에이전트가 데스크톱 레이아웃을 보고, 다른 에이전트가 모바일 뷰포트를 보고, 필요하면 또 다른 에이전트가 태블릿 폭을 확인하게 만들 수 있습니다. 그러면 같은 기능을 고친 뒤 "큰 화면에서는 되는데 작은 화면에서 터졌다"는 사고를 훨씬 빨리 잡을 수 있습니다.

예를 들어 대시보드의 사이드바를 수정했다고 해봅시다. 데스크톱에서는 사이드바가 자연스럽게 접히는데, 모바일에서는 햄버거 버튼을 눌렀을 때 오버레이가 닫히지 않는 문제가 있을 수 있습니다. Browser Subagent는 이런 상호작용을 실제로 눌러 보고, 그 결과를 스크린샷과 녹화로 남길 수 있습니다. 이때 중요한 건 "모바일 지원합니다"라는 말이 아니라, 모바일에서 실제로 눌러 본 증거입니다.

Playwright 없이 회귀 테스트하기

이 장의 제목에 많은 독자가 가장 민감하게 반응할 부분이 아마 이것일 겁니다. 정말 Playwright 없이도 회귀 테스트가 가능할까?

짧게 답하면 이렇습니다. 일부는 가능하고, 전부는 아니다.

Browser Subagent는 일상적인 UI 회귀 검증을 아주 많이 흡수할 수 있습니다. 화면이 깨지지 않았는지, 주요 버튼이 눌리는지, 폼 제출 후 성공 상태가 나오는지, 콘솔 에러가 없는지, 모바일에서 레이아웃이 무너지지 않았는지 같은 것들은 브라우저를 실제로 조작하며 확인할 수 있습니다.¹³ 특히 AI가 막 만든 기능을 사람이 일일이 다시 클릭해 보는 대신, 에이전트가 먼저 스모크 테스트처럼 훑어 주는 용도로 탁월합니다.

이 지점에서는 전통적인 Playwright 스크립트보다 오히려 빠를 때가 많습니다. Playwright는 사람이 먼저 테스트 코드를 써야 합니다. 반면 Browser Subagent는 "회원가입 플로우를 열어 보고, 오류 없이 완료되는지 확인해 줘" 같은 자연어 수준의 요청으로 바로 브라우저 검증에 들어갈 수 있습니다. 개발 초기, 프로토타이핑, 빈번한 UI 수정 구간에서는 이 속도 차이가 꽤 큽니다.

하지만 여기서 욕심을 내면 안 됩니다. Browser Subagent는 사람과 에이전트의 검증 루프를 줄여 주는 도구이지, 곧바로 완전한 CI 회귀 테스트 체계를 대체하는 도구는 아닙니다. 이유는 간단합니다. scripted E2E 테스트는 재현성과 결정성이 강점이고, Browser Subagent는 탐색성과 유연성이 강점이기 때문입니다.

둘의 차이를 감각적으로 이해해 봅시다.

• Playwright는 "항상 같은 절차를 같은 방식으로 실행하는 검사표"에 가깝다

• Browser Subagent는 "실제 브라우저를 보고 만지며 확인하는 숙련된 시연자"에 가깝다

• 전자는 릴리스 게이트에 강하고, 후자는 개발 중 빠른 확인에 강하다

그래서 현실적인 전략은 대체가 아니라 분업입니다. 개발 중에는 Browser Subagent로 빠르게 확인하고, 반복 가치가 높은 핵심 사용자 흐름만 Playwright 같은 스크립트 테스트로 고정하는 것입니다. 말하자면 Antigravity가 먼저 "이 기능, 사람 눈으로 봐도 괜찮다"를 확인해 주고, 그중 중요한 경로만 나중에 정식 회귀 테스트로 승격시키는 식입니다.

실제로 어디에 가장 잘 듣는가

Browser Subagent는 모든 UI 작업에 도움이 되지만, 특히 효율이 좋은 구간이 있습니다.

첫째, 폼과 상태 변화가 많은 화면입니다. 회원가입, 로그인, 비밀번호 재설정, 결제 단계, 관리자 필터 패널 같은 곳은 눈으로 봐도 맞는지 헷갈리고, 눌러 봐야만 아는 문제가 많습니다. 이런 흐름에서 브라우저 자동 검증은 사람 시간을 크게 아껴 줍니다.

둘째, CSS와 레이아웃 수정입니다. Tailwind 클래스 몇 줄 바꾸는 일은 사소해 보여도, 실제 레이아웃에는 연쇄 효과를 일으킵니다. 카드 간격 하나 줄였더니 전체 줄바꿈이 어긋나는 식입니다. Browser Subagent는 결과 화면을 바로 확인하게 해 줍니다.

셋째, 버그 재현과 수정 확인입니다. 사용자가 "모바일에서 저장 버튼이 안 눌린다"고 제보했을 때, 에이전트가 그 경로를 따라가며 같은 증상을 재현하고, 수정 뒤 다시 눌러 보는 흐름을 수행할 수 있습니다. 이때 녹화 Artifact는 팀 내 공유에도 유용합니다.

넷째, 데모와 리뷰 준비입니다. 기능이 작동한다는 사실을 말로 설명하는 것보다, 브라우저 녹화 한 편이 훨씬 빠릅니다. 특히 PM, 디자이너, 테크 리드처럼 코드를 직접 읽지 않는 이해관계자에게는 더 그렇습니다.

Artifacts와 만날 때 진짜 힘이 생긴다

이 장의 주인공은 Browser Subagent지만, 진짜 힘은 그것이 Artifacts와 결합될 때 나옵니다. 브라우저 자동화 자체만으로도 유용하지만, Antigravity가 특별한 이유는 그 실행 흔적이 스크린샷과 브라우저 녹화, 그리고 리뷰 가능한 결과물로 남는다는 데 있습니다.¹³

이건 단순 자동화와 다릅니다. 자동화만 있으면 "실행은 됐겠지"에서 멈추기 쉽습니다. 하지만 Artifact가 붙으면 사용자는 에이전트가 어디를 클릭했는지, 무엇을 확인했는지, 최종 화면이 어땠는지 검토할 수 있습니다. 즉, 브라우저 조작이 블랙박스가 아니라 리뷰 가능한 산출물이 됩니다.

이렇게 되면 UI 검증은 더 이상 혼자만의 체험이 아닙니다. 에이전트가 검증했고, 그 흔적을 사람이 나중에 비동기로 다시 볼 수 있습니다. 이것이 Agent-First 워크플로우와 잘 맞는 이유입니다. 사람은 모든 순간을 동기적으로 지켜보지 않아도 됩니다. 대신 필요할 때 결과물 위에서 판단하면 됩니다.

한계는 분명하다

여기까지 읽으면 Browser Subagent가 거의 만능처럼 들릴 수 있습니다. 하지만 아직은 아니다. 오히려 한계를 정확히 알아야 제대로 쓸 수 있습니다.

가장 먼저, 브라우저 서브에이전트는 기본적으로 Chrome 통합 중심입니다. 다른 브라우저에서 동일한 수준의 네이티브 지원을 기대하면 실망할 수 있습니다.³ 즉, "실제 사용자는 Safari도 많이 쓰는데?" 같은 질문은 여전히 남습니다. Chrome에서 통과했다고 모든 브라우저가 통과한 것은 아닙니다.

둘째, 화면에 보인다고 해서 모든 미디어나 문서를 완벽하게 이해하는 것은 아닙니다. PDF 뷰어 안의 복잡한 콘텐츠, 동영상 플레이어, 오디오 상태, 캔버스 중심 인터페이스처럼 구조적으로 읽기 어려운 대상은 검증 품질이 떨어질 수 있습니다. 스크린샷은 남길 수 있어도, 그 안의 의미를 안정적으로 판독하는 일은 여전히 까다롭습니다.

셋째, 상호작용은 잘하지만 의도까지 완벽하게 읽는 것은 아닙니다. 예를 들어 화면상으로는 버튼을 눌렀고 성공 토스트도 떴지만, 그 경험이 정말 좋은 UX인지까지는 별도 판단이 필요합니다. 에이전트는 "작동했다"를 비교적 잘 확인하지만, "좋게 작동했다"의 미묘한 차이는 아직 사람의 눈이 더 낫습니다.

넷째, 탐색 기반 검증은 반복성이 강한 테스트에 비해 덜 결정적일 수 있습니다. 같은 흐름이라도 타이밍, 네트워크, 애니메이션, 외부 API 상태에 영향을 받을 수 있습니다. 그래서 릴리스 차단선 역할까지 모두 맡기기에는 아직 조심해야 합니다.

결국 Browser Subagent의 한계는 약점이라기보다 경계선입니다. 어디까지 맡기고, 어디서부터 사람 리뷰나 정식 테스트 코드로 넘길지를 구분하는 감각이 중요합니다.

잘 쓰는 팀은 Browser Subagent를 이렇게 본다

Browser Subagent를 잘 쓰는 팀은 이것을 "Playwright의 경쟁자"로만 보지 않습니다. 더 정확히 말하면, 개발 중 검증 마찰을 줄여 주는 운영 계층으로 봅니다.

좋은 사용법은 이렇습니다. 기능을 구현한 뒤 에이전트가 먼저 브라우저에서 동작을 확인하게 합니다. 그 결과를 스크린샷, 녹화, 콘솔 확인으로 남깁니다. 사람은 그 Artifact를 보고 빠르게 피드백합니다. 그리고 반복 가치가 높은 핵심 흐름만 스크립트 테스트로 승격합니다. 이 순서가 가장 싸고, 가장 현실적입니다.

반대로 나쁜 사용법은 두 가지입니다. 하나는 "브라우저까지 봤으니 이제 아무도 확인 안 해도 된다"는 과신입니다. 다른 하나는 "어차피 완벽하지 않으니 그냥 내가 다 직접 할래"라는 체념입니다. Antigravity가 잘하는 일은 사람의 판단을 없애는 것이 아니라, 사람이 봐야 할 범위를 줄이는 것입니다.

실제 화면을 검증하는 순간, Antigravity의 철학이 선명해진다

Antigravity의 핵심 철학은 처음부터 같았습니다. 코드를 더 빨리 쓰게 해 주는 것이 아니라, 더 큰 작업을 더 믿을 수 있게 위임하게 해 주는 것. Browser Subagent는 그 철학이 가장 눈에 보이는 기능입니다.

에이전트가 코드를 고치고, 터미널에서 서버를 띄우고, 브라우저를 열고, 버튼을 눌러 보고, 콘솔을 확인하고, 스크린샷과 녹화를 남긴다. 이 일련의 흐름을 보면 비로소 Antigravity가 왜 "에디터 안의 챗봇"이 아니라 "작업을 수행하는 에이전트 시스템"이라고 말하는지 체감됩니다.

중요한 것은 브라우저를 자동으로 조작한다는 사실 자체가 아닙니다. 실제 사용자 세계에 가까운 표면에서 검증이 일어난다는 점입니다. 코드가 아니라 화면, 추측이 아니라 상호작용, 설명이 아니라 증거. Browser Subagent는 바로 그 전환을 담당합니다.

그래서 이 기능은 단순히 편한 부가기능이 아닙니다. Antigravity가 다른 AI 코딩 도구와 다른 길을 간다는 것을 가장 분명하게 보여 주는 장면입니다. 코드가 아니라 실제 화면과 동작을 검증하는 순간, 에이전트는 비로소 "도와주는 존재"를 넘어 "맡길 수 있는 존재"에 가까워집니다.

참고

¹Google Antigravity Documentation — Browser Subagent

²06 브라우저 서브 에이전트 (Browser Subagent) - Google Antigravity

³Antigravity Browser Extension: Complete Guide