스크린샷은 브라우저 상태가 아니다

스크린샷은 브라우저 상태가 아닙니다. 스크린샷만 보는 코딩 에이전트(coding agent)는 디버깅 연극을 하고 있는 것입니다. 스크린샷은 무엇이 고장 났는지는 보여주지만, 왜 고장 났는지는 보여주지 않습니다. 유용한 루프(loop)는 실제 브라우저 상태(browser state)를 포함해야 합니다: 콘솔 에러(console errors), 네트워크 요청(network requests), 성능 추적(performance traces), DOM 상태(DOM state), 스토리지(storage), 쿠키(cookies), 세션 컨텍스트(session context), 그리고 사용자가 막혀 있는 정확한 페이지 말입니다. 이러한 차이는 오늘날 틈새 영역에서 명백한 사실로 옮겨갔습니다. Chrome for Developers는 에이전트를 위한 Chrome DevTools가 안정화되었다고 발표했습니다: 코딩 에이전트는 Chrome DevTools MCP를 사용하여 Chrome에서 웹 앱을 테스트하고 콘솔 로그(console logs), 네트워크 요청(network requests), 성능 추적(performance traces), 그리고 Lighthouse 보고서(Lighthouse reports)를 검사할 수 있습니다. 이것이 올바른 방향입니다. 에이전트에게 필요한 것은 더 예쁜 스크린샷이 아닙니다. 그들에게 필요한 것은 런타임 증거(runtime evidence)입니다.

스크린샷은 증상만을 보여줍니다
스크린샷은 에이전트에게 결제 버튼이 비활성화되었다는 사실을 알려줄 수 있습니다. 하지만 다음과 같은 사항들을 에이전트에게 신뢰성 있게 알려줄 수는 없습니다: 어떤 요청이 실패했는지; API가 401, 403, 429, 또는 500을 반환했는지; CSP 규칙이 스크립트를 차단했는지; 하이드레이션(hydration)이 실패했는지; 기능 플래그(feature flag)가 DOM을 변경했는지; 로컬 스토리지(local storage)가 오래되었는지; 사용자가 잘못된 워크스페이스(workspace)에 있는지; 버그가 로그인된 계정 뒤에서만 발생하는지 등 말입니다. HTML 스냅샷(HTML snapshots)도 유사한 문제를 가지고 있습니다. 유용하긴 하지만 여전히 부분적입니다. 런타임 동작(runtime behavior), 타이밍(timing), 인증 상태(auth state), 네트워크 엣지(network edges), 그리고 브라우저의 실제 실행 컨텍스트(execution context)를 놓치기 때문입니다. 개발자라면 DevTools를 열 것입니다. 유용한 코딩 에이전트 역시 똑같이 할 수 있어야 합니다.

진정한 브라우저 루프
진정한 브라우저 루프는 에이전트가 행동할 수 있는 증거를 제공합니다:
콘솔(Console): 스택 트레이스(stack traces), 경고(warnings), 하이드레이션 실패(failed hydration), 클라이언트 측 에러(client-side errors).
네트워크(Network): 요청 페이로드(request payloads), 응답 코드(response codes), 헤더(headers), 리다이렉트(redirects), CORS 실패(CORS failures).
성능(Performance): 긴 작업(long tasks), 레이아웃 이동(layout shifts), 느린 리소스(slow resources), Lighthouse 보고서(Lighthouse reports).
DOM 및 접근성 상태(DOM and accessibility state): 템플릿이 약속한 것이 아니라 페이지가 실제로 렌더링한 것.
쿠키 및 스토리지(Cookies and storage): 인증 상태(auth state), 워크스페이스 ID(workspace IDs), 오래된 토큰(stale tokens), 기능 플래그(feature flags).
세션 컨텍스트(Session context): 사용자가 실제로 문제에 부딪힌 로그인된 페이지.

이것이 바로 Chrome DevTools MCP가 중요한 이유입니다. 이는 브라우저를 단순한 사진이 아닌 증거 소스(evidence source)로 변화시킵니다. 동일한 패턴이 다른 곳에서도 나타나고 있습니다. 개발자들은 코딩 에이전트(coding agents)가 실제 Chrome을 제어하고, 멀티 탭 세션(multi-tab sessions)을 조사하며, 에이전트가 파싱(parse)할 수 있는 구조화된 결과(structured results)를 반환할 수 있게 하는 도구들을 구축하고 있습니다. 에이전트 작업 공간(agent workspaces) 내부의 브라우저 창은 단순한 미리보기를 넘어 검토 표면(review surfaces), 협업 표면(collaboration surfaces), 그리고 인계 표면(handoff surfaces)이 되어가고 있습니다. 방향은 명확합니다. 브라우저 작업이 에이전트 런타임(agent runtime)의 일부가 되고 있습니다.

기계 판독 가능한 브라우저 증거 (Machine-readable browser evidence)
다음 단계는 단순히 "에이전트가 Chrome을 보게 하는 것"이 아닙니다. 에이전트가 사용할 수 있는 형태로 브라우저 증거를 받을 수 있게 하는 것입니다. 스크린샷은 모델이 추론(infer)하도록 강제합니다. 반면 구조화된 브라우저 결과는 에이전트가 추론(reason)할 수 있게 합니다. 예를 들어, 브라우저 실행 결과로 다음 항목들을 반환할 수 있습니다: 시도된 작업(action attempted), 실행된 URL 및 프레임(frame), 관찰된 콘솔 오류(console errors), 관찰된 네트워크 실패(network failures), 성능 경고(performance warnings), 결과적인 DOM 또는 접근성 상태(accessibility state), 의도한 사후 상태(after-state)의 나타남 여부. 이것이 중요한 이유는 에이전트가 반복적(iterative)이기 때문입니다. 한 브라우저 단계의 출력이 다음 코딩 단계의 입력이 됩니다. 브라우저 결과가 이미지뿐이라면 에이전트는 추측하는 것입니다. 브라우저 결과가 구조화된 증거라면, 에이전트는 수정(repair), 재실행(rerun), 그리고 검증(verify)할 수 있습니다. 이것이 "스크린샷은 브라우저 상태가 아니다"라는 말의 실질적인 의미입니다.

로그인된 Chrome은 문제를 변화시킵니다
로컬 개발(local development)의 경우, 실제 브라우저 증거는 주로 디버깅(debugging)에 관한 것입니다. 하지만 실제 브라우저 작업은 로컬 개발에서 끝나지 않습니다. 많은 유용한 작업들이 로그인 뒤에서 일어납니다: 결제 설정 업데이트, 지원 편지함 확인, CMS 포스트 게시, CRM 기록 확인, 클라이언트 포털에 파일 업로드, 주문 환불, 광고 캠페인 변경, 프로덕션 대시보드 조사 등. 그 시점에서 브라우저는 더 이상 단순한 조사 표면이 아닙니다. 그것은 권위(authority)입니다. 로그인된 Chrome 세션에는 쿠키(cookies), SaaS 액세스, 내부 도구, 실시간 고객 데이터, 그리고 상태를 변경할 수 있는 능력이 포함되어 있습니다.

만약 에이전트(agent)가 해당 세션을 조작할 수 있다면, 그것은 단순히 "브라우저를 사용하는 것"이 아닙니다. 그것은 위임된 권한(delegated authority)을 통해 행동하는 것입니다. 이는 서로 다른 제품 경계(product boundary)를 의미합니다. 프롬프트(Prompts)는 권한(permissions)이 아닙니다. "주의하세요"라고 말하는 프롬프트는 권한 시스템이 아닙니다. 삭제 전의 지연 시간도 권한 시스템이 아닙니다. 사후에 남는 로그(log)도 권한 시스템이 아닙니다. 로그인된 브라우저 워크플로(workflows)의 경우, 제어 계층(control layer)은 명시적이어야 합니다: 어떤 브라우저 세션이 노출되는지, 어떤 사이트나 워크스페이스(workspaces)가 범위(scope)에 포함되는지, 어떤 작업이 읽기 전용(read-only)인지, 어떤 쓰기(writes) 작업이 승인을 필요로 하는지, 승인 라인(approval line)이 어디에 위치하는지, 어떤 영수증(receipt)이 무엇이 변경되었음을 증명하는지, 액세스를 어떻게 취소(revoked)할 수 있는지 등이 포함되어야 합니다. 승인 라인은 중요합니다. 이는 브라우저-에이전트의 메모리(memory)가 단순한 메모(notes)를 넘어 제어 표면(control surface)이 되는 지점입니다. 라인 이전에는 에이전트가 페이지 상태(page state), 이전의 실패 사례, 현재의 인증 경계(auth boundary), 의도된 작업 등의 증거를 수집할 수 있습니다. 라인에서는 인간 또는 정책 게이트(policy gate)가 에이전트의 쓰기 권한 부여 여부를 결정합니다. 라인 이후에는 시스템에 영수증(receipt)이 필요합니다. 영수증은 로그(logs)가 아닙니다. 로그는 실행 과정을 디버깅(debugging)하는 데 유용합니다. 영수증은 위임된 작업(delegated work)을 신뢰하는 데 유용합니다. 브라우저 작업 영수증은 팀이 나중에 확인할 수 있는 질문들에 답할 수 있어야 합니다: 누가 또는 어떤 에이전트가 행동했는지, 어떤 브라우저 세션과 계정 컨텍스트(account context)가 사용되었는지, 어떤 권한이 위임되었는지, 왜 해당 작업이 허용되었는지, 어떤 데이터가 이동했는지, 페이지에서 무엇이 변경되었는지, 변경 사항이 반영되었음을 증명하는 사후 상태(after-state)는 무엇인지, 무엇을 롤백(rolled back)하거나 취소(revoked)할 수 있는지 등이 그것입니다. 이것은 "에이전트가 버튼을 클릭했다"는 것과는 다릅니다. 또한 스크린샷(screenshot)과도 다릅니다. 스크린샷은 최종 페이지를 보여줄 수 있지만, 영수증은 변경 사항을 둘러싼 권한, 결정, 작업, 그리고 증거 추적(evidence trail)을 보존해야 합니다. 이것이 바로 진정한 브라우저 루프(browser loops)와 위임된 브라우저 권한(delegated browser authority)이 만나는 지점입니다.

BrowserMan이 적합한 위치
Chrome DevTools MCP는 로컬 코딩 루프(local coding loops)를 위한 강력한 해답입니다. 이는 에이전트에게 콘솔(console), 네트워크(network), 성능(performance), Lighthouse, 그리고 실제 페이지와 같은 런타임 브라우저 증거를 제공합니다. BrowserMan의 영역은 그와 인접해 있습니다.

BrowserMan은 에이전트에게 사용자의 실제 Chrome 세션에 대한 제어된 접근 권한을 부여합니다. 에이전트는 어디에서나 실행될 수 있는 반면, 로그인된 브라우저는 사용자의 장치에 그대로 유지됩니다. 쿠키(Cookies) 또한 로컬에 머뭅니다. 접근 권한은 범위 지정(scoped), 게이트 관리(gated), 감사(audited), 승인(approved) 및 취소(revoked)가 가능합니다. 여기서 유용한 프레임워크는 "더 많은 브라우저 제어"가 아니라, 실제 브라우저 권한의 "제어된 위임 (controlled delegation)"입니다. 로컬 개발 루프(Local dev loop): 에이전트가 Chrome에서 일어나고 있는 일을 조사하고 수정할 수 있는가? 위임된 브라우저 워크플로우(Delegated browser workflow): 에이전트가 적절한 범위 내에서, 적절한 로그인 세션을 사용하며, 위험한 쓰기(writes) 작업 전에는 승인을 받고 변경 후에는 영수증(receipts)을 받을 수 있는가? 이 두 가지 모두 중요합니다. 이들은 동일한 변화의 서로 다른 부분을 해결합니다. 즉, 에이전트가 텍스트를 넘어 실제 브라우저 작업으로 이동하고 있다는 점입니다. 브라우저는 에이전트 런타임 (agent runtime)이 되고 있습니다. 브라우저는 더 이상 단순한 뷰포트 (viewport)가 아닙니다. 코딩 에이전트에게 브라우저는 증거 소스 (evidence source)입니다. 워크플로우 에이전트에게 브라우저는 실행 표면 (action surface)입니다. 로그인된 작업에 있어 브라우저는 권한 표면 (authority surface)입니다. 이는 차세대 브라우저-에이전트 도구가 단순히 에이전트가 페이지를 클릭할 수 있는지 여부만으로 판단되어서는 안 된다는 것을 의미합니다. 시스템이 작업 주변의 상태(state), 권한(authority), 승인(approval) 및 증거(proof)를 보존할 수 있는지에 따라 판단되어야 합니다. 스크린샷만으로는 충분하지 않습니다. 실제 브라우저 상태가 증거입니다. 로그인된 브라우저 상태가 권한입니다. 그리고 위임된 권한에는 승인 라인(approval lines)과 영수증(receipts)이 필요합니다.