실전 유즈케이스 1 — 프론트엔드: 브라우저-인-더-루프 UI 반복 작업 자동화
프론트엔드 작업에서 시간이 가장 많이 새는 구간은 '코드를 바꾸는 시간'이 아니라 '바꾼 뒤 확인하는 시간'입니다. 버튼 간격을 조금 조정하고, 한 컴포넌트의 상태를 추가하고, 다시 빌드하고, 브라우저에서 클릭해 보고, 반응형에서 깨지지 않는지 확인하는 일을 하루에도 몇 번씩 반복합니다.
이 반복은 사람에게는 쉽게 흔들리지만, 에이전트에게는 오히려 강점입니다. 에이전트는 같은 조건에서 같은 경로로 들어가 같은 기준으로 확인을 수행합니다. 특히 픽셀 맞추기처럼 "판단"이 아니라 "일관된 실행"이 중요한 구간에서 더 꾸준합니다.
이 챕터의 목표는 하나입니다. 반복되는 UI 변경과 회귀 확인을 브라우저-인-더-루프(브라우저에서 직접 확인까지 포함)로 묶어, 에이전트에게 맡기는 시나리오를 여러분의 팀에 바로 적용 가능한 형태로 만드는 것입니다.
브라우저-인-더-루프가 필요한 이유
전통적인 UI 자동화는 셀렉터가 바뀌거나 레이아웃이 조금만 흔들려도 깨지기 쉽습니다. 반면 '브라우저 에이전트'는 화면 상태를 관찰하고(Observe), 다음 행동을 결정하고(Decide), 실행하고(Act), 결과를 검증(Verify)하는 루프를 반복하며 변화에 적응하는 방식으로 설명됩니다.1 즉, "클릭하고 끝"이 아니라 "클릭한 뒤 기대 상태가 되었는지 확인"이 기본값입니다.
실무에서는 여기에 한 가지가 더 들어갑니다. 로그인 2FA, CAPTCHA, 결제 같은 예외 구간은 자동으로만 처리하기 어렵습니다. 이때는 자동화가 멈추고 사람이 잠깐 개입한 뒤 다시 에이전트가 이어받는 하이브리드 방식이 현실적입니다.23
이번 실전 시나리오: "디자인 픽셀 맞추기 + 컴포넌트 수정 + 회귀 확인"
가장 흔한 작업을 하나로 묶어보겠습니다.
상황은 이렇습니다. 디자이너가 버튼/입력 폼의 높이, 간격, 라운드 값, 포커스 링을 업데이트했습니다. 여러분은 공통 컴포넌트(Button, TextField)를 수정해야 하고, 영향을 받는 화면(로그인, 회원가입, 설정)을 다시 확인해야 합니다.
여기서 '완료(Definition of Done)'를 코드 머지로 두면, 결국 사람의 눈으로 다시 돌아옵니다. 그래서 완료 조건을 아티팩트로 고정합니다.
이 시나리오의 완료 조건은 다음처럼 잡는 것이 안전합니다.
데스크톱/모바일 2개 뷰포트에서, 변경 전/후 스크린샷이 남아 있다.
핵심 플로우(로그인 → 설정 진입)가 짧은 브라우저 녹화로 남아 있다.
콘솔 에러/네트워크 실패(예: 4xx/5xx)가 없는지 확인 기록이 있다.
이 세 가지는 UI 변화가 코드 diff만으로는 충분히 검증되지 않는다는 문제를, '재검증 가능한 증거물'로 해결합니다.4
준비 단계: 에이전트가 흔들리지 않게 "기준"부터 고정하기
브라우저-인-더-루프가 잘 굴러가려면, 에이전트가 확인할 기준이 선명해야 합니다. 특히 픽셀 작업은 "그럴듯함"이 아니라 "수치"가 필요합니다.
시작 전에 아래 두 가지를 먼저 정리합니다.
첫째, 디자인 기준을 텍스트로 바꿉니다. 예를 들어 "버튼 높이 44px, 라운드 12px, 좌우 패딩 16px, 포커스 링 2px"처럼 숫자로 적습니다. 디자인 링크만 던지면 에이전트가 해석을 섞기 쉽습니다.
둘째, 검증 경로를 고정합니다. "/login → 로그인 성공 → /settings 진입" 같은 네비게이션을 명시해야, 에이전트가 임의로 다른 경로를 선택하지 않습니다.
미션(프롬프트) 템플릿: 'UI 변경'이 아니라 '검증까지' 맡기는 문장
아래 템플릿은 Antigravity의 기본 사고방식(Plan–Execute–Verify, 크로스-서피스, 아티팩트)을 그대로 전개하도록 설계했습니다.
미션 템플릿
목표: Button과 TextField 컴포넌트의 디자인 스펙을 반영하고, 영향 화면(/login, /signup, /settings)에서 회귀가 없는지 브라우저에서 확인한다.
Plan 단계에서: 변경 범위(파일/컴포넌트/영향 화면), 리스크(반응형/접근성), 검증 방법(터미널 테스트, 브라우저 체크, 스크린샷/녹화)을 1페이지로 정리해라.
Execute 단계에서:
변경 전 기준 스크린샷을 데스크톱 1440×900, 모바일 390×844로 각각 저장해라.
컴포넌트를 수정하고, 영향 화면에서 스타일이 일관되게 적용되도록 필요한 수정을 함께 해라.
터미널에서 lint/test/build를 실행해 통과시켜라.
Verify 단계에서:
브라우저에서 /login → /settings 플로우를 직접 수행해 정상 동작을 확인하고 30~60초 녹화를 남겨라.
콘솔 에러가 없는지 확인 결과를 포함해라.
변경 후 동일 조건의 스크린샷을 남기고, 전/후 비교가 가능한 형태로 정리해라.
결과물: Plan 문서 + 실행 커맨드/결과 워크스루 + 전/후 스크린샷 세트 + 플로우 녹화 링크를 하나의 Artifact Pack으로 묶어라.
핵심은 "수정해줘"가 아니라 "같은 조건으로 전/후를 남기고, 브라우저에서 동작을 증명해줘"라고 맡기는 것입니다.
단계별 실행 시나리오: Baseline → 수정 → 브라우저 검증 → 아티팩트 패키징
여기부터는 실제로 에이전트에게 일을 맡길 때의 흐름입니다. 중요한 건 단계가 아니라 루프가 끊기지 않게 설계하는 것입니다.
1단계: Baseline 수집(변경 전 '증거' 확보)
에이전트가 먼저 해야 할 일은 코드를 고치는 것이 아니라, 변경 전 상태를 기준으로 박제하는 것입니다.
브라우저 에이전트는 관찰(스크린샷/DOM/콘솔/네트워크)을 기반으로 다음 행동을 결정하고 검증하는 구조로 설명됩니다.1 이 장점을 UI 작업에 그대로 적용하면, 기준이 사라져 논쟁이 생기는 일을 줄일 수 있습니다.
이 단계에서 에이전트가 남겨야 하는 것은 "현재 UI가 어떤 상태인지"를 보여주는 자료입니다. 화면마다 '같은 뷰포트'로 찍는 것이 중요합니다.
2단계: 컴포넌트 수정(기계적인 반복을 대량 처리)
사람이 지치기 쉬운 작업은 대개 기계적인 규칙 적용입니다. 예를 들어 토큰 변경, 클래스명 정리, 공통 컴포넌트의 변형(variants) 추가는 "규칙을 알고 꾸준히 적용하는 능력"이 성능입니다.
반복 UI 코딩은 컴포넌트 생성, 스타일 일괄 변경, 토큰 적용, UI 테스트 생성처럼 패턴화된 작업이 많고, 이런 작업을 에이전트가 PR 단위로 처리하는 방식이 효과적이라고 정리됩니다.5 이 단계에서 중요한 운영 원칙은 하나입니다. 한 PR에는 하나의 목표만 담는다. "버튼 높이/간격 통일"을 하고 싶다면 거기에만 집중시키는 편이 검증이 쉬워집니다.
3단계: 터미널 검증(실행 가능한 상태로 만들기)
UI가 맞아도 빌드가 깨지면 의미가 없습니다. 이 단계에서 에이전트가 터미널에서 실행해야 할 커맨드는 팀 표준을 따르되, 최소한 다음 범주를 포함시키는 것이 좋습니다.
정적 분석(lint)
단위/컴포넌트 테스트
빌드(build)
브라우저에서 안정적으로 확인하려면, 결국 "재현 가능한 실행 상태"가 전제입니다.
4단계: 브라우저 검증(브라우저-인-더-루프의 핵심)
여기서부터가 진짜 시간 절약 구간입니다. 사람은 이 단계에서 가장 쉽게 빠뜨립니다. "일단 화면은 괜찮네" 하고 넘어가지만, 다른 해상도나 다른 경로에서 깨지는 일이 많습니다.
UI 자동화가 CI에서 특히 불안정해지는 이유로 동적 컴포넌트, 비동기 렌더링, 네트워크 변동, 미세한 DOM 변화, 애니메이션 지연 같은 요인이 반복해서 언급됩니다.6 그래서 에이전트에게 브라우저 검증을 맡길 때는, 다음 두 원칙이 효율을 만듭니다.
첫째, 검증을 '경로'로 고정합니다. 예를 들어 로그인 이후 설정까지, 실제 사용자가 밟는 경로를 그대로 수행하게 합니다.
둘째, 검증을 '아티팩트'로 고정합니다. 스크린샷과 녹화가 남아야 "해봤다"가 아니라 "증명했다"가 됩니다.
추가로, 로그인 2FA나 CAPTCHA가 끼어 있는 경우 자동화만으로는 막히는 구간이 생깁니다. 이때는 라이브 URL을 공유해 사람이 잠깐 조작한 뒤 다시 자동화가 이어가는 하이브리드 방식이 일반적인 해법입니다.2 엔터프라이즈 브라우저 자동화 사례에서도 CAPTCHA 등 예외 상황에서 사람이 개입하고, 이후 에이전트가 같은 세션에서 이어받는 흐름을 핵심으로 둡니다.3
5단계: Artifact Pack으로 정리(리뷰가 빨라지는 형태로 제출)
마지막으로, 결과물을 한데 모읍니다. 아티팩트는 "많이"가 아니라 "같은 규칙으로" 남길수록 효과가 커집니다.4
Artifact Pack은 다음처럼 구성하면 리뷰어가 가장 빨리 판단합니다.
변경 요약(왜 바꿨는지, 영향 범위)
적용한 스펙(숫자 기준)
실행 커맨드와 결과
전/후 스크린샷(동일 뷰포트)
핵심 플로우 녹화
이 패키지로 제출하면 "코드를 읽고 상상하기"가 아니라 "증거를 보고 확인하기"로 리뷰가 바뀝니다.
픽셀 맞추기에서 에이전트가 꾸준해지는 운영 팁
픽셀 작업은 작은 차이가 누적되어 번아웃을 부릅니다. 에이전트가 꾸준해지려면, 사람 쪽에서 기준을 몇 가지 고정해야 합니다.
첫째, 스크린샷은 해상도와 데이터 상태를 고정합니다. 같은 화면이라도 데이터가 다르면 레이아웃이 달라집니다.
둘째, 애니메이션/로딩은 검증을 방해하는 요인이므로 가능하면 줄이거나(테스트 환경에서) 안정화합니다. UI 테스트가 흔들리는 원인이 애니메이션 지연 같은 타이밍 이슈라는 점은 반복해서 지적됩니다.6
셋째, "맞췄다"를 말로 끝내지 않고, 비교 가능한 전/후 증거로 마무리합니다. 이 습관이 생기면, UI 논쟁이 사라지고 진행 속도가 올라갑니다.4
사람은 무엇을 맡고, 에이전트는 무엇을 맡나
이 시나리오에서 사람의 역할은 '손'이 아니라 '기준'입니다. 에이전트는 기준을 받으면 꾸준히 실행합니다.
에이전트에게 위임하기 좋은 일은 컴포넌트/스타일의 기계적 적용과, 같은 경로로 반복하는 브라우저 검증입니다.5 반대로 사람에게 남겨야 하는 것은 "트레이드오프가 있는 결정"입니다. 예를 들어 버튼 문구의 톤, 미세한 여백의 우선순위(다른 UI와의 조화), 접근성에서의 예외 처리 같은 것들은 제품 판단이 섞입니다.
요약: 프론트엔드 자동화의 핵심은 '수정'이 아니라 '확인 루프'를 위임하는 것
브라우저-인-더-루프 자동화는 화려한 스크립트가 아니라, 관찰–행동–검증 루프를 UI 작업에 붙이는 일입니다.1 그리고 그 루프의 끝은 "완료했습니다"가 아니라 "전/후 스크린샷과 플로우 녹화" 같은 아티팩트입니다.4
이제 여러분은 픽셀 맞추기, 컴포넌트 수정, 회귀 확인을 '사람이 클릭해보는 노동'이 아니라 '에이전트가 꾸준히 반복하는 루틴'으로 바꿀 수 있습니다.
참고
1How Browser Agents Work: A Step-by-Step Architectural Guide
2Hybrid automation - human in the loop (browserless docs)
3AI agent-driven browser automation for enterprise workflow management (AWS ML Blog)
4Artifacts로 검증하기: 로그 대신 '증거물'로 신뢰를 만든다
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.