Copilot 브라우저 도구가 프론트엔드를 검토 가능하게 만든다

GitHub는 지난주 VS Code용 Copilot을 위한 브라우저 도구(browser tools)를 정식 출시(generally available)했으며, 이에 대한 당연한 반응은 '좋다, 이제 에이전트(agent)가 웹 앱을 돌아다니며 클릭할 수 있겠구나'일 것입니다.

그것은 유용합니다.

하지만 그것은 가장 흥미롭지 않은 부분입니다.

더 중요한 점은, 이제 에이전트가 사용자가 하는 것과 똑같이 무질서한 환경인 실제 브라우저에서, 실제 탐색(navigation), 실제 클릭, 실제 콘솔 오류(console errors), 실제 스크린샷, 그리고 실제 UI 상태(UI state)를 가지고 프론트엔드(frontend)와 상호작용할 수 있다는 것입니다.

이는 AI 지원 프론트엔드 작업의 형태를 변화시킵니다.

왜냐하면 프론트엔드 풀 리퀘스트(pull request)는 항상 약간은 부정직한 검토 표면(review surface)을 가지고 있었기 때문입니다. 우리는 디프(diffs)를 검토합니다. 우리는 컴포넌트(component) 코드를 검토합니다. 테스트가 있다면 테스트를 검토합니다. 누군가 스크린샷을 올릴 수도 있습니다. 누군가 "로컬에서 테스트함"이라고 적으면 모두가 그 문장을 얼마나 신뢰할지 결정하곤 합니다.

하지만 사용자가 경험하는 것은 디프(diff)가 아닙니다.

사용자가 경험하는 것은 일련의 브라우저 상태(browser states)입니다.

만약 에이전트가 브라우저를 제어할 수 있다면, 풀 리퀘스트(pull request)는 코드가 유일한 결과물(artifact)인 척하는 것을 멈춰야 합니다.

프론트엔드 작업에는 항상 증빙(receipts)이 필요했다

백엔드(Backend) 변경 사항은 보통 더 명확한 검토 스토리를 가집니다. 완벽하지는 않지만, 더 명확합니다.

API가 변경됩니다. 테스트가 동작을 단언(assert)합니다. 마이그레이션(migration)이 실행됩니다. 로그 라인(log line)이 나타납니다. 계약(contract)을 확인할 수 있습니다. 실패는 종종 README에 적힌 명령어로 재현할 수 있습니다.

프론트엔드(Frontend) 작업은 더 미끄러운(slippery) 성질을 가집니다.

모달(modal)이 포커스(focus)를 올바르게 가두었나요? 요청 중에 버튼이 비활성화(disabled)되었나요? 레이아웃(layout)이 긴 고객 이름을 견뎌냈나요? 토스트(toast) 메시지가 모바일에서 저장 버튼을 가렸나요? 에러 메시지가 올바른 위치에 나타났나요? 로딩 상태(loading state)가 80밀리초 동안 깜빡여서 전체적인 느낌을 망치지는 않았나요?

이것들은 실제 제품의 동작(product behaviors)이지만, 디프(diff)에 항상 자연스럽게 나타나는 것은 아닙니다.

그래서 팀들은 의식(rituals)을 만들어냅니다. Slack에 올리는 스크린샷. Loom 영상. Storybook 링크. 프리뷰 배포(Preview deployments). Playwright 트레이스(traces). 리뷰어가 직접 브랜치를 가져와서 흐름을 클릭해 보는 것.

이 모든 것들은 합리적입니다.

또한 이는 취약하기도 합니다. 왜냐하면 증거(evidence)가 변경 사항과 분리되어 있는 경우가 많기 때문입니다. 리뷰어는 한 곳에서는 코드를 보고, 다른 곳에서는 스크린샷을 보며, 또 다른 곳에서는 테스트 결과를 확인하고, 설명(description)란에 적힌 "확인했습니다"라는 문장을 읽어야 합니다.

에이전트(Agents)는 그 간극의 비용을 더 높게 만듭니다.

만약 에이전트가 프론트엔드(frontend) 코드를 작성한다면, 저는 에이전트가 어떤 파일을 변경했는지만 알고 싶은 것이 아닙니다. 변경 후에 무엇을 보았는지도 알고 싶습니다.

클릭은 검증이 아니다

이 워크플로우에는 유혹적이지만 잘못된 버전이 존재합니다.

에이전트가 앱을 열고, 버튼을 클릭한 뒤, "작동합니다"라고 말하면, PR(Pull Request) 설명에 UI가 브라우저에서 테스트되었다고 당당하게 선언하는 방식입니다.

그것만으로는 충분하지 않습니다.

브라우저를 사용하는 에이전트가 코드를 읽는 에이전트보다 자동으로 더 신뢰할 수 있는 것은 아닙니다. 에이전트는 해피 패스(happy path)만 클릭하고 엣지 케이스(edge case)를 놓칠 수 있습니다. 페이지가 여전히 렌더링된다는 이유로 콘솔 경고(console warning)를 무시할 수 있습니다. 데스크톱에서 테스트하고 모바일 레이아웃은 전혀 알아차리지 못할 수 있습니다. 버그가 실제 데이터가 있는 계정에서만 나타나는데, 로그아웃된 사용자로 흐름(flow)을 실행할 수도 있습니다.

브라우저 접근 권한은 에이전트에게 더 나은 도구를 제공할 뿐, 판단력(judgment)을 제공하는 것은 아닙니다.

가치는 브라우저 세션(browser session)을 검토 가능한 아티팩트(artifact)의 일부로 만드는 데서 옵니다.

어떤 페이지를 열었는가? 어떤 뷰포트(viewport)를 사용했는가? 어떤 단계(steps)를 거쳤는가? 어떤 어설션(assertions)을 수행했는가? 어떤 콘솔 에러(console errors)가 나타났는가? 어떤 스크린샷(screenshot)을 캡처했는가? 무엇을 검증하는 데 실패했는가? 키보드 네비게이션(keyboard navigation)을 테스트했는가, 아니면 단순히 마우스로 클릭만 했는가? 하드 새로고침(hard refresh) 후에 흐름을 실행했는가? 빈 상태(empty state)를 테스트했는가?

"에이전트가 이를 테스트했습니다"라는 문장은 유용하지 않습니다.

"에이전트가 로컬 프리뷰(local preview)를 열고, 1440px와 390px에서 결제 흐름(checkout flow)을 실행했으며, 스크린샷을 캡처하고, 콘솔 에러가 없음을 확인했으나, 결제 제공업체 콜백(payment-provider callback)은 테스트하지 않았습니다"가 훨씬 더 낫습니다.

마지막 절(clause)이 중요합니다.

좋은 증거에는 증거의 경계(boundary)가 포함되어야 합니다.

브라우저가 진실의 원천(source of truth)이 된다

GitHub의 변경 로그(changelog)는 Playwright나 Cypress를 사용해 본 사람이라면 누구나 익숙할 브라우저 동작들을 설명합니다: 페이지 열기, 탐색(navigate), 클릭, 타이핑, 호버(hover), 드래그, 대화 상자(dialogs) 처리, 페이지 콘텐츠 읽기, 콘솔 에러 캡처, 스크린샷 찍기, 그리고 더 효율적인 경우 스크립트된 흐름(scripted flows) 실행 등이 그것입니다.

이것은 마법이 아닙니다. 에디터 내에서의 브라우저 자동화(browser automation)입니다.

하지만 이를 코딩 에이전트(coding agent)와 같은 위치에 배치(colocating)함으로써 인체공학적 사용성(ergonomics)이 변화합니다.

컴포넌트를 편집하는 동일한 작업자(worker)가 앱을 실행하고, 결과를 검사하며, 피드백을 코딩 루프(coding loop)로 다시 가져올 수 있습니다. 이는 프론트엔드 작업이 진행되는 동안 프론트엔드가 에이전트에게 반론을 제기할 수 있음을 의미합니다.

콘솔 에러는 컨텍스트(context)가 됩니다. 깨진 셀렉터(selector)는 컨텍스트가 됩니다. 이상한 간격이 보이는 스크린샷은 컨텍스트가 됩니다. "테마 변수가 누락되어 버튼이 보이지 않는다"는 상황이 풀 리퀘스트(pull request)가 생성되기 전에 발생할 수 있습니다.

이것은 좋은 현상입니다.

또한 브라우저 관찰 결과가 이제 코드 생성의 입력값(inputs)이 된다는 것을 의미합니다. 입력값은 기록되어야 합니다.

사람이 브라우저에서 버그를 발견하여 코드를 수정할 때, 그 관찰 결과는 종종 그 사람의 머릿속에만 머뭅니다. 그것은 정상입니다. 인간은 머리를 가질 권리가 있으니까요.

에이전트가 브라우저에서 무언가를 관찰하여 코드를 변경할 때, 플랫폼은 리뷰어가 해당 루프를 이해할 수 있도록 그 관찰 내용의 충분한 부분을 보유해야 합니다. 그렇지 않으면 최종 디프(diff)가 왜 그런 형태를 갖게 되었는지에 대한 이유 없이 도착하게 됩니다.

프론트엔드 에이전트 작업에는 다음과 같은 작은 증거 패킷(evidence packet)이 포함되어야 합니다:

테스트된 경로(route) 또는 URL
뷰포트(viewport) 및 환경
사용된 사용자 상태(user state) 또는 픽스처(fixture)
수행된 단계(steps)
중요한 상태에 대한 스크린샷 또는 트레이스(traces)
콘솔 및 네트워크 실패
브라우저 통과 후 실행된 테스트
알려진 격차(gaps)

거대하게 자동 생성된 소설 같은 것이 아닙니다. 제발 사양합니다.

그저 리뷰어가 에이전트가 올바른 것을 확인했는지 결정할 수 있을 정도의 영수증(receipts)이면 충분합니다.

엔터프라이즈 제어는 중요하지만 지루한 부분입니다

변경 로그(changelog)에는 이 기능을 회사에 배포하는 상황을 상상해 보기 전까지는 지루하게 들릴 법한 종류의 세부 사항들도 포함되어 있습니다.

일반적으로 사용 가능(general availability) 상태에서는 브라우저 도구가 기본적으로 켜져 있지만, 관리자(admins)에게는 이를 켜거나 끌 수 있는 전용 설정이 제공됩니다. 기존의 에이전트 네트워크 도메인 제어(agent network domain controls)를 통해 에이전트와 통합된 브라우저가 접속할 수 있는 사이트를 제한할 수 있습니다. 사용자가 연 탭은 에이전트와 공유되지 않는 한 비공개로 유지됩니다. 에이전트가 연 탭은 격리된 세션(isolated sessions)에서 실행됩니다. 카메라, 마이크, 위치, 알림, 클립보드 읽기와 같은 민감한 권한은 명시적인 승인이 필요합니다.

이것이 올바른 형태입니다.

브라우저는 해롭지 않은 장난감이 아닙니다. 브라우저는 자격 증명 표면(credential surface)이자 데이터 표면(data surface)이며, 의도하지 않은 곳으로 내부 정보를 실수로 전송하게 만드는 매우 편리한 통로입니다.

브라우저 접근 권한을 가진 에이전트는 페이지를 읽고, 양식을 채우고, 버튼을 클릭하며, 눈앞에 놓인 무엇과도 상호작용할 수 있습니다. 만약 그 브라우저가 사용자의 일상적인 쿠키, 내부 관리 패널, 프로덕션 대시보드 또는 고객 데이터에 접근할 수 있다면, 폭발 반경(blast radius)은 순식간에 기괴해질 정도로 커집니다.

여기서 격리(Isolation)는 각주 수준의 부차적인 기능이 아닙니다. 격리는 유용한 기능을 실제로 사용할 수 있게 만드는 핵심 기능입니다.

도메인 제어(domain controls)도 마찬가지입니다. 로컬 프리뷰를 테스트하는 프론트엔드 에이전트는 아마도 localhost, 프리뷰 배포 환경, 어쩌면 디자인 시스템 문서 사이트와 테스트용 ID 제공자(identity provider)가 필요할 것입니다. 하지만 전체 공개 인터넷이 필요하지는 않을 것입니다. 프롬프트가 그 방향으로 흘러갔다고 해서 프로덕션 도구를 아무렇지 않게 탐색해서는 절대로 안 됩니다.

이는 에이전트 툴링(agent tooling)의 모든 곳에서 나타나는 동일한 패턴입니다. 기능(capability)을 시연하는 것은 쉽지만, 제어(control)가 가능하게 만드는 것은 바로 그 기능의 배포 가능성(deployable)을 결정합니다.

이것은 pull request 템플릿을 바꿔야 합니다

브라우저 기능이 있는 에이전트가 일반적이 된다면, 프론트엔드 PR(pull request) 템플릿도 바뀌어야 합니다.

극적으로 바뀔 필요는 없습니다. 그저 정직해지면 됩니다.

"로컬에서 테스트됨"이라고 적힌 체크박스 대신, 다음과 같이 증거를 요구하십시오:

실행된 브라우저 흐름 (Browser flows exercised)
확인된 뷰포트 (Viewports checked)
스크린샷 또는 트레이스 링크 (Screenshots or trace links)
관찰된 콘솔 에러 (Console errors observed)
시도된 접근성 검사 (Accessibility checks attempted)
테스트되지 않은 상태 (States not tested)

에이전트가 작성한 변경 사항에 대해서는, 에이전트가 해당 내용을 직접 채우도록 만드십시오.

리뷰어는 여전히 의견이 다를 수 있습니다. 사실, 리뷰어는 그래야만 합니다. 증거가 리뷰를 대체할 수는 없습니다. 증거는 리뷰를 위한 더 나은 시작점일 뿐입니다.

만약 에이전트가 설정 페이지를 테스트했다고 말했는데 변경 사항이 온보딩 (onboarding)에 영향을 미친다면, 리뷰어는 즉시 그 불일치를 잡아낼 수 있습니다. 데스크톱에서만 테스트했다면, 누군가 모바일 테스트를 요구할 수 있습니다. 콘솔 경고를 무시했다면, 적어도 그 경고는 눈에 보이게 됩니다. 스크린샷이 잘못된 빈 상태 (empty state)를 보여준다면, 대화는 막연한 느낌 (vibes)이 아닌 현실에서 시작됩니다.

이것이 제가 브라우저 도구에서 좋아하는 부분입니다. 브라우저 도구는 AI 프론트엔드 작업을 "내가 생성한 요약을 믿으세요"에서 "내가 실제로 수행한 것을 검사하세요"로 옮겨놓을 수 있습니다.

그것이 더 건강한 리뷰 문화입니다.

에이전트는 눈에 보이게 실패해야 한다

최고의 브라우저-에이전트 워크플로우는 에이전트가 항상 성공하는 워크플로우가 아닙니다.

실패의 비용이 저렴하고 눈에 잘 보이는 워크플로우입니다.

앱이 시작되지 않았습니다. 로그인 흐름에 테스트 사용자가 필요했습니다. 로컬 API가 잘못된 피스처 (fixture) 데이터를 반환했습니다. 뷰포트가 너무 작았습니다. 셀렉터 (selector)가 불안정했습니다. 콘솔에 관련 없어 보이는 에러가 있었습니다. 에이전트가 드래그 앤 드롭 (drag-and-drop) 상호작용을 검증할 수 없었습니다.

이 모든 것들이 PR (Pull Request)에 나타난다면 유용한 결과물입니다.

이것들은 인간에게 어디에 여전히 판단이 필요한지를 알려줍니다.

이 지점에서 팀들은 에이전트의 결과물을 자신감 있어 보이도록 다듬고 싶은 충동을 억제해야 한다고 생각합니다. 성공 사례만 포함된 생성된 PR 설명은 마케팅입니다. 에이전트가 증명할 수 없었던 것까지 포함된 생성된 PR 설명이 엔지니어링입니다.

목표는 에이전트를 인상적으로 들리게 만드는 것이 아닙니다.

목표는 변경 사항을 리뷰 가능하게 만드는 것입니다.

핵심 (the punchline)

VS Code의 Copilot 브라우저 도구가 흥미로운 이유는 버튼을 클릭하는 것이 인상적이기 때문이 아닙니다.

이 도구들이 흥미로운 이유는 프론트엔드 작업이 마침내 그 증거를 함께 지니고 다닐 수 있는 더 나은 기회를 얻었기 때문입니다.

만약 에이전트(agent)가 UI 코드를 변경한다면, 해당 코드가 브라우저에서 실행되었을 때 어떤 일이 일어났는지도 함께 보여주어야 합니다. 라우트(Routes), 단계(steps), 스크린샷(screenshots), 콘솔 에러(console errors), 뷰포트(viewports), 간극(gaps) 등 말이죠. 리뷰어가 처음부터 모든 과정을 다시 재현하지 않고도 해당 작업을 신뢰하거나 거부할 수 있도록 돕는 지루하지만 중요한 요소들입니다.

이것이 바로 AI 지원 프론트엔드 개발(AI-assisted frontend development)이 나아가야 할 방향입니다.

더 큰 디프(diffs)가 아닙니다. 더 자신감 있는 요약도 아닙니다. 맥락 없이 채팅창에 붙여넣은 스크린샷도 아닙니다.

에이전트가 무엇을 보았는지, 무엇을 시도했는지, 그리고 무엇을 검증할 수 없었는지에 대한 작고 지속적인 기록입니다.

브라우저는 단순한 또 다른 도구 호출(tool call)이 아닙니다.

프론트엔드 작업에 있어, 브라우저는 진실이 드러나는 곳입니다.

references

제 프로젝트를 테스트하기 위해 저는 Railway를 사용합니다. 시작하기 위해 20달러(USD)를 받고 싶다면, 이 링크를 사용하세요.

Insights