배경 및 맥락

브라우저 에이전트는 지난 1년 동안 빠르게 발전했지만, 실제 운영에서는 여전히 자주 막히는 구간이 있었다. DOM 기반 자동화는 폼 입력, 버튼 클릭, 텍스트 추출에는 강하지만, 인쇄 대화상자, 인증서 선택창, 브라우저 권한 프롬프트, 우클릭 메뉴처럼 운영체제가 그리는 UI에는 접근하지 못했다. 테스트 환경에서는 잘 되는데 production에서만 깨지는 이유가 여기에 있었다.

AWS는 이 공백을 단순한 편의 기능이 아니라 런타임 구조 문제로 다루고 있다. 에이전트가 화면을 보고 판단할 수 있는데 실제로는 클릭할 수 없는 상태를 없애기 위해, OS surface 자체를 agent action 대상에 포함시켰다.

---

핵심 내용

OS Level Actions는 AgentCore Browser session 안에서 InvokeBrowser API로 호출된다. AWS는 mouseClick, mouseMove, mouseDrag, mouseScroll, keyType, keyPress, keyShortcut, screenshot의 8개 액션을 제공하며, screenshot은 full OS desktop을 base64 PNG로 반환한다. 핵심 실행 패턴은 action -> screenshot -> reaction이다. 에이전트가 액션을 실행하고, 바뀐 전체 화면을 다시 캡처한 뒤, vision model이 다음 액션을 결정하는 방식이다.

문서상으로는 브라우저의 web layer를 넘어 native dialogs, OS modals, browser chrome, certificate chooser 같은 요소까지 다룰 수 있다. 특히 keyboard shortcut과 right-click context menu가 공식 지원되는 점은 기존 DOM 자동화 대비 실전성이 크게 높아졌다는 뜻이다.

---

경쟁 구도 / 비교

Playwright와 CDP는 여전히 웹 자동화의 핵심 도구지만, 본질적으로 DOM 밖 OS 요소를 다루는 데 한계가 있다. 별도 desktop automation을 섞어 해결할 수는 있었지만, 브라우저 세션 컨텍스트와 observability가 분리되는 문제가 있었다. AgentCore Browser는 이를 하나의 managed browser runtime 안에 합치려 한다.

즉 경쟁 포인트가 웹 페이지를 얼마나 잘 읽느냐에서 웹과 OS가 섞인 실제 사용자 환경을 얼마나 끝까지 완주하느냐로 이동하고 있다. 이는 browser agent가 단순 테스트 자동화보다 훨씬 넓은 workflow automation 시장으로 확장될 수 있음을 의미한다.

---

의미

기술적으로는 browser agent가 더 이상 DOM automation wrapper가 아니라 computer-use runtime에 가까워지고 있다. vision loop, coordinate actions, session state, native UI handling이 기본 기능으로 편입되면, 웹 기반 업무 자동화의 적용 범위가 크게 넓어진다.

실무적으로는 product team과 platform team이 production 브라우저 플로우를 설계할 때 OS prompt, certificate flow, print/export, clipboard 대체 경로 같은 비웹 표면까지 acceptance 범위에 넣어야 한다. 앞으로 robust browser agent의 기준은 selector 성공률이 아니라 전체 세션 완료율이 된다.