AI 자동화의 최첨단은 단순히 대규모 언어 모델 (LLMs)을 더 똑똑하게 만드는 것에 그치지 않습니다. 그것은 모델에게 손과 눈을 부여하는 것에 관한 것입니다. 시각 기반 에이전트 아키텍처 (vision-driven agentic architectures)를 구축할 때, 우리는 거대한 격차를 넘어서야 합니다. 즉, LLM의 고수준 의미론적 추론 (high-level semantic reasoning)과 브라우저 자동화의 저수준 픽셀 정밀 메커니즘 (low-level, pixel-precise mechanics) 사이의 간극을 메우는 것입니다.

브라우저 에이전트 개발의 초기 단계에서는 click_element(selector)와 같은 텍스트 기반 도구 호출 (tool calls)에 크게 의존했습니다. 하지만 에이전트가 임의의 현대적인 웹 애플리케이션, 레거시 기업 포털, 또는 도구화되지 않은 캔버스 (canvas)를 마주하게 되면, 전통적인 DOM 선택자 (selectors)는 필연적으로 실패합니다. 난독화된 섀도우 루트 (shadow roots), 동적으로 생성된 해시 클래스 (hash classes), 그리고 복잡한 SVG 벡터는 문자열 기반 쿼리를 깨뜨립니다. 대신 에이전트는 멀티모달 (multimodal) 능력을 활용하여 스크린샷을 "보고" 상호작용 가능한 영역을 시각적으로 식별해야 합니다.

이는 엄청난 공학적 과제를 야기합니다: 화면-좌표 매핑 (Screen-to-Coordinate Mapping).

LLM이 스크린샷을 평가할 때, 내부적인 시각적 이해를 바탕으로 국소화된 경계 상자 (bounding box) 또는 2D 픽셀 좌표를 출력합니다. 그러나 호스트 브라우저는 문서 객체 모델 (DOM)을 대상으로 하는 MouseEvent 또는 CDP Input.dispatchMouseEvent와 같이 절대적이고 장치 픽셀에 정확한 (device-pixel-accurate) 포인터 이벤트를 요구합니다. 이러한 불일치를 해결하려면 컴퓨터 비전 좌표, 뷰포트 (viewports), 장치 픽셀 비율 (DPR), 그리고 복잡한 좌표 정규화 수학 (coordinate normalization mathematics)을 통합하는 엄격한 이론적 프레임워크가 필요합니다.

핵심 공간 변환 문제 (The Core Spatial Translation Problem)

화면-좌표 매핑의 핵심 과제를 이해하기 위해, 고전적인 웹 개발 비유인 **반응형 이미지 맵 스케일링 (Responsive Image Map Scaling) 및 CSS 좌표계 (CSS Coordinate Systems)**를 생각해 보십시오.

4000x3000 픽셀의 고정 해상도로 설계된 캔버스 위에 거대하고 매우 상세한 세계 지도를 만든다고 상상해 보십시오. 모든 랜드마크는 절대 좌표 쌍(예: 도시 X는 $x=1200, y=850$에 위치)을 가집니다. 이제 이 지도를 단 400x300 픽셀인 모바일 기기 화면의 유동적인 웹 컨테이너(fluid web container) 내부나, 디바이스 픽셀 비율 (Device Pixel Ratio (DPR))이 3인 Retina 디스플레이에 렌더링한다고 가정해 봅시다. 사용자가 도시 X를 클릭하면, 브라우저는 물리적 뷰포트 (viewport)를 기준으로 한 가공되지 않은 터치 좌표(예: $x=120, y=85$)를 제공합니다. 사용자가 어느 도시를 클릭했는지 알아내기 위해서는 단순히 가공되지 않은 숫자만 봐서는 안 됩니다. 스케일링 인자 (scaling factors), 종횡비 늘어남 (aspect ratio stretching), 레터박싱 (letterboxing), 그리고 하드웨어 픽셀 밀도를 모두 고려한 복잡한 아핀 변환 (affine transformation)을 수행해야 합니다.

시각 기반 (Vision-driven) AI 에이전트들도 정확히 이와 같은 장애물에 직면합니다. LLM (Large Language Model)으로 전송되는 스크린샷은 멀티모달 토큰 제약 조건에 맞추기 위해 빈번하게 크기가 조정되거나, 압축되거나, 다운샘플링 (downsampled)됩니다. LLM이 가로 52%, 세로 38%를 나타내는 [0.52, 0.38]과 같은 정규화된 좌표 쌍 (normalized coordinate pair)으로 응답할 때, 해당 지점은 추상적이고 차원이 없는 공간에 존재하게 됩니다. 이를 구체적인 DOM 상호작용으로 변환하려면 다층적인 좌표 파이프라인 (coordinate pipeline)이 필요합니다:

1. 역정규화 (Denormalization): 차원이 없는 LLM 출력을 스크린샷의 픽셀 차원으로 다시 매핑합니다.
2. 뷰포트 스케일링 (Viewport Scaling): CSS 레이아웃 시프트 (layout shifts) 및 스크롤 오프셋 (scrolling offsets)을 조정하면서, 해당 차원을 브라우저의 논리적 뷰포트 픽셀로 스케일링합니다.
3. DOM 해상도 (DOM Resolution): 히트 테스트 (hit-testing)를 통해 픽셀을 상호작용 가능한 DOM 노드로 변환합니다.
4. 액션 디스패치 (Action Dispatch): 동작을 실행하기 위해 네이티브 포인터 이벤트 (native pointer events)를 발생시킵니다.

공간적 환각 (Spatial Hallucination)과 좌표 드리프트 (Coordinate Drift)의 구조

프로덕션급 (production-grade) 비전 에이전트 (vision agents)를 구축한다는 것은 확률적 공간 추론 (stochastic spatial reasoning)에서 발생하는 필연적인 실패 모드 (failure modes)에 직면함을 의미합니다. document.querySelector('button#submit')와 같은 프로그래밍 방식의 선택자 (programmatic selectors)를 실행하는 결정론적 (deterministic) 코드와 달리, 시각적 상호작용은 세 가지 주요 공간 오류 범주를 유발합니다: 양자화 드리프트 (quantization drift), 종횡비 왜곡 (aspect ratio distortion), 그리고 시간적 UI 변화 (temporal UI shift).

1. 양자화 드리프트 (Quantization Drift)

최신 멀티모달 LLM (multimodal LLMs)은 이미지를 패치 (patches, 예: 이산적인 토큰 그리드)로 나누어 처리합니다. LLM이 스크린샷을 평가할 때, 어텐션 메커니즘 (attention mechanism)은 이러한 이산적인 패치 전반에 걸쳐 특징 (features)을 국지화 (localize)합니다. 경계 상자 (bounding box) 또는 중심점 (centroid point)을 출력하도록 요청받을 때, 모델의 출력은 회귀 헤드 (regression head)에 의해 양자화 (quantized)됩니다. 만약 모델이 로그인 버튼이 패치의 대략적인 중앙에 있다고 판단한다면, 모델의 수치적 출력은 실제 광학적 중심 (optical center)으로부터 몇 픽셀 정도 드리프트 (drift)될 수 있습니다. 토글 스위치 (toggle switches)로 가득 찬 밀집된 UI에서 단 5~10 픽셀의 드리프트만으로도 에이전트는 인접한 레이블을 클릭하거나, 체크박스 선택을 해제하거나, 앵커 (anchor)를 완전히 놓치게 됩니다.

2. 종횡비 왜곡 (Aspect Ratio Distortion)

브라우저가 복잡한 웹 애플리케이션의 스크린샷을 캡처할 때 (예: 1920x1080), 그 차원 (dimensions)이 LLM의 비전 인코더 (vision encoder)가 기대하는 토큰 효율적인 (token-efficient) 기본 종횡비와 일치하는 경우는 드뭅니다. 만약 자동화 하네스 (automation harness)가 정확한 종횡비를 보존하지 않은 채 스크린샷을 맹목적으로 크기 조정 (resize), 크롭 (crop), 또는 패딩 (pad)한다면 공간 기하학 (spatial geometry)이 왜곡됩니다. 와이드스크린 디스플레이의 좌표 (960, 540)에 있는 버튼이 찌그러지거나 늘어나는 식입니다. 이를 역산하려면 정밀한 행렬 수학 (matrix math)이 필요합니다. 레터박싱 (letterboxing)을 고려하지 않으면, 모든 클릭이 화면 가장자리를 향해 점진적으로 목표에서 벗어나는 체계적인 공간 오프셋 (spatial offsets)이 발생하게 됩니다.

3. 시간적 UI 변화 (Temporal UI Shift)

웹 애플리케이션은 CSS 전환 (CSS transitions), 비동기 데이터 페칭 (asynchronous data fetching), 무한 스크롤 (infinite scrolls), 그리고 반응형 프레임워크 업데이트 (reactive framework updates)에 의해 제어되는 살아있는 생태계입니다. 스크린샷을 캡처하고, 1,500밀리초 동안 이미지를 처리한 뒤, (800, 600) 위치에 있는 "결제 진행 (Proceed to Checkout)" 버튼을 클릭하기로 결정한 에이전트를 가정해 봅시다. 그 1,500밀리초 동안 비동기 네트워크 요청 (asynchronous network request)이 완료되어 DOM 상단에 정보 배너가 렌더링됩니다. 이 배너는 전체 문서 흐름 (document flow)을 아래로 50픽셀 밀어냅니다. 에이전트가 (800, 600)으로 클릭 이벤트 (click event)를 보낼 때, 이는 빈 공간이나 완전히 다른 요소를 타격하게 됩니다.

시간적 UI 변화 (Temporal UI shift)를 완화하려면 모든 클릭을 단발성 명령 (fire-and-forget command)이 아닌, 폐루프 제어 시스템 (closed-loop control system)으로 취급해야 합니다. 모든 상호작용은 새로운 스크린샷이나 DOM 변이 로그 (DOM mutation log)를 통한 실행 후 검증 (post-execution verification)을 요구해야 합니다.

좌표 정규화의 수학적 기초 (Mathematical Foundations of Coordinate Normalization)

화면-좌표 매핑 (screen-to-coordinate mapping)을 실행하기 위해, 우리는 세 가지 별개의 좌표 공간에 걸친 변환을 공식화합니다:

• 모델 공간 (Model Space, $M$): LLM에 의해 사용되는 무차원 또는 양자화된 좌표 공간으로, 일반적으로 $[0.0, 1.0]$으로 정규화됩니다.
• 스크린샷 픽셀 공간 (Screenshot Pixel Space, $S$): 캡처된 이미지 파일의 절대 픽셀 차원 ($W_s, H_s$).
• 뷰포트 CSS 픽셀 공간 (Viewport CSS Pixel Space, $V$): 디바이스 픽셀 비율 (Device Pixel Ratio, $DPR$)을 고려하여 DOM 요소가 존재하는 브라우저 뷰포트의 논리적 좌표계 ($W_v, H_v$).

LLM이 정규화된 점 $P_m = (x_m, y_m)$ (여기서 $x_m, y_m \in [0, 1]$)을 출력한다고 가정합시다. 이 점을 원본 스크린샷 픽셀 공간 $P_s = (x_s, y_s)$로 매핑하려면 선형 스케일링 변환 (linear scaling transformation)을 사용합니다:

$$x_s = x_m \times W_s$$
$$y_s = y_m \times H_s$$

스크린샷 픽셀 공간 ($S$)에서 뷰포트 CSS 픽셀 공간 ($V$)으로 스케일링하려면 캡처 스케일 계수 ($k_{cap}$)와 디바이스 픽셀 비율 ($DPR$)을 조정해야 합니다:

$$x_v = \frac{x_s}{k_{cap} \times DPR}$$
$$y_v = \frac{y_s}{k_{cap} \times DPR}$$

레터박싱 처리 (Handling Letterboxing)

멀티모달 모델 (Multimodal models)이 큰 웹 페이지를 다운스케일링할 때, 프레임워크는 종종 레터박싱 (Letterboxing, 종횡비를 유지하기 위해 균일한 패딩을 추가하는 방식)을 적용합니다. 원본 스크린샷 $W_s \times H_s$가 정사각형 타겟 해상도 $T \times T$에 맞게 패딩되었다고 가정해 봅시다. 균일 스케일링 계수 (Uniform scaling factor) $s$는 다음과 같습니다:

$$s = \min\left(\frac{T}{W_s}, \frac{T}{H_s}\right)$$

스케일링된 차원은 $W_{scaled} = W_s \times s$ 및 $H_{scaled} = H_s \times s$가 됩니다. 중앙 패딩 오프셋 (Center padding offsets) $(P_x, P_y)$는 다음과 같이 도입됩니다:

$$P_x = \frac{T - W_{scaled}}{2}$$
$$P_y = \frac{T - H_{scaled}}{2}$$

LLM이 캔버스 공간 (Canvas space)에서의 좌표 $P_{model} = (x_{model}, y_{model})$를 출력하면, 역스케일 계수 (Inverse scale factor)를 적용하기 전에 패딩 오프셋을 제거합니다:

$$x_s = \frac{x_{model} - P_x}{s}$$
$$y_s = \frac{y_{model} - P_y}{s}$$

만약 $x_{model}$이 패딩 영역 내에 있다면, 해당 좌표는 웹 페이지 경계 외부의 공간적 환각 (Spatial hallucination)을 나타내며, 에이전트에게 뷰포트 (Viewport)를 다시 스캔하도록 신호를 보냅니다.

고급 히트 테스팅 및 DOM 요소 해상 (Advanced Hit-Testing and DOM Element Resolution)

절대 뷰포트 좌표 $P_v = (x_v, y_v)$가 계산되면, 클릭 이벤트를 전송하는 것이 실제로 의도한 DOM 요소와 상호작용하는지 확인해야 합니다. 레이어링 (Layering), 절대 위치 지정 (Absolute positioning), 투명한 오버레이 (Transparent overlays), 고정된 내비게이션 바 (Fixed navigation bars)가 많이 사용되는 현대적인 웹 앱에서는, 가공되지 않은 좌표 클릭이 보이지 않는 래퍼 div (Wrapper div)나 플로팅 채팅 위젯 (Floating chat widget)에 의해 쉽게 가로채질 수 있습니다.

이를 극복하기 위해, 견고한 파이프라인 (Pipelines)은 브라우저의 네이티브 document.elementFromPoint(x, y) API를 사용하여 프로그래밍 방식의 히트 테스팅 (Hit-testing)을 구현합니다. 프로덕션급 오케스트레이션 엔진 (Orchestration engines)은 다음과 같은 다단계 DOM 해상 (DOM resolution) 알고리즘을 실행합니다:

1. Primary Raycast (기본 레이캐스트): document.elementFromPoint(x_v, y_v)를 실행하여 최상위 요소를 식별합니다.
2. Target Validation (대상 검증): 반환된 노드의 태그 이름(tag name), ARIA 역할(ARIA roles), 텍스트 콘텐츠, 그리고 경계 클라이언트 사각형(getBoundingClientRect())을 검사합니다.
3. Deep Shadow Traversal (심층 섀도우 탐색): 해당 요소가 Shadow Root를 포함하는 호스트인 경우, 실제 리프 노드(leaf node)가 격리될 때까지 shadowRoot.elementFromPoint(x, y)를 사용하여 섀도우 트리(shadow tree)를 재귀적으로 탐색합니다.
4. Occlusion Check (가려짐 확인): 최상위 요소가 의도한 상호작용 대상인지, 아니면 가로막고 있는 오버레이(occluding overlay, 예: 모달 백드롭 또는 쿠키 배너)인지 확인합니다. 만약 오버레이가 해당 좌표를 차지하고 있다면, 엔진은 이를 해제하거나 차단되지 않은 영역으로 좌표를 조정해야 합니다.

TypeScript 구현: SaaS 대시보드 에이전트 클릭 실행

다음의 독립적인 TypeScript 구현은 자율 에이전트가 LLM의 가공되지 않은 시각적 출력(visual output)을 어떻게 처리하고, 이를 현대적인 SaaS 분석 대시보드 애플리케이션 내에서 정밀한 네이티브 DOM 클릭 이벤트로 변환하는지를 보여줍니다.

import { JSDOM } from 'jsdom';

/**
...

상태 동기화, 폴백(Fallbacks) 및 오류 복구

화면-좌표 매핑 아키텍처의 궁극적인 테스트는 클릭이 실패하거나 예상치 못한 상태 전이(state transitions)를 일으킬 때의 오류 복구 메커니즘입니다. 전통적인 소프트웨어 공학에서는 예외(exceptions)를 포착하여 로그를 남기고 개발자에게 알립니다. 하지만 에이전트 기반 자동화(agentic automation)에서 예외는 에이전트가 동적으로 추론해야 하는 운영 데이터 포인트입니다.

이벤트 디스패치(event dispatch) 후, 에이전트는 검증 단계에 진입합니다. 에이전트는 새로운 스크린샷을 캡처하고, 구조적 유사성 지수(structural similarity indices) 또는 DOM 변이 관찰자(DOM mutation observers)를 사용하여 동작 전의 상태와 비교합니다. 만약 검증 결과 상태 변화가 전혀 감지되지 않으면, 에이전트는 단계별 폴백 계층(progressive fallback tier)을 트리거합니다:

• Tier 1: 공간적 지터 (Spatial Jitter, 미세 조정): 초기 클릭이 버튼 패딩 (padding)의 절대적인 가장자리에 떨어졌을 수 있습니다. 엔진은 원래 지점을 중심으로 미세 조정된 좌표 클러스터(±3 픽셀 오프셋)를 생성하고, 히트 테스트 (hit-test) 및 클릭 시퀀스를 신속하게 재시도합니다.
• Tier 2: 중심점 재계산 (Centroid Recalculation): LLM이 식별한 경계 상자 (bounding box)가 왜곡되었을 수 있습니다. 엔진은 getBoundingClientRect()를 사용하여 DOM에서 대상 요소의 정확한 경계 상자를 쿼리하고, 뷰포트 (viewport) 공간에서의 실제 기하학적 중심을 계산한 뒤, 해당 중심점으로 고정밀 클릭을 직접 전송합니다.
• Tier 3: 의미론적 폴백 (Semantic Fallback): 이 단계에서는 시각적 좌표 매핑을 포기합니다. 엔진은 표준 도구 실행으로 폴백하여, 접근성 트리 (accessibility tree)를 쿼리하거나 텍스트 기반 선택자(aria-label, data-testid)를 통해 검색합니다.
• Tier 4: 에이전트 재계획 (Agentic Re-planning): 모든 기술적 폴백이 실패하면, 에이전트는 실패 상태를 공유 메모리 그래프 (shared memory graph)에 기록하고, 상위 목표를 재평가하며, 페이지 새로고침이나 사용자에게 명확한 설명을 요청하는 것과 같은 대안 경로를 수립합니다.

엄격한 좌표 수학, 세밀한 뷰포트 스케일링 변환 (viewport scaling transformations), 심층적인 DOM 히트 테스트 (hit-testing), 그리고 강력한 자가 치유 오류 복구 (self-healing error recovery)를 결합함으로써, 개발자는 현존하는 가장 복잡한 웹 애플리케이션 전반에서 초인적인 회복탄력성으로 작동하는 시각 기반 브라우저 자동화 시스템을 구축할 수 있습니다.

여기서 시연된 개념과 코드는 도서 Model Context Protocol (MCP) & Computer Use. Standardizing Tool Integration, Vision-Driven Browser Automation, and Agent Governance in TypeScript에 제시된 포괄적인 로드맵에서 직접 가져온 것입니다. 해당 도서는 여기에서 확인하실 수 있습니다. 다른 많은 전자책들도 확인해 보세요.