브라우저 에이전트는 잘못된 추상화 위에 구축되었다고 생각합니다 (그래서 컴파일러를 만들었습니다)

모든 브라우저 에이전트는 동일한 방식으로 시작합니다.

HTML을 다운로드합니다.

DOM을 구축합니다.

CSS 셀렉터(CSS selectors)를 검색합니다.

버튼을 찾습니다.

JavaScript를 기다립니다.

무언가를 클릭합니다.

더 많은 HTML을 읽습니다.

반복합니다.

우리는 LLM을 극적으로 더 똑똑하게 만들고 있지만...

...여전히 웹의 가장 낮은 수준의 표현 방식 중 하나를 바탕으로 추론하도록 요구하고 있습니다.

그것은 잘못된 것처럼 느껴졌습니다.

그래서 저는 다른 질문을 던지기 시작했습니다:

AI 에이전트가 웹사이트를 방문할 때마다 매번 새로 발견하는 대신, 웹사이트가 의미론적 인터페이스(semantic interfaces)로 컴파일될 수 있다면 어떨까?

그 질문은 결국 Shiny Fishstick이라는 오픈 소스 프로젝트가 되었습니다.

네.

실제로 그 이름이 맞습니다.

문제점

AI 에이전트에게 노트북을 구매하라고 요청하는 상황을 상상해 보세요.

오늘날 에이전트의 내부 추론은 다음과 같은 모습입니다:

로그인 버튼 찾기.

로그인 클릭.

대기.

이메일 필드 찾기.

이메일 입력.

비밀번호 필드 찾기.

비밀번호 입력.

제출 클릭.

페이지 이동 대기.

"Laptop" 검색.

장바구니 담기(Add to Cart) 찾기.

장바구니 담기 클릭.

이제 이것을 매번... 하는 것을 상상해 보세요.

매.

번.

마다.

웹사이트는 바뀌지 않았습니다.

워크플로우(workflow)도 바뀌지 않았습니다.

하지만 에이전트는 계속해서 그것을 새로 발견하고 있습니다.

HTML은 훌륭한 인간용 인터페이스입니다

HTML은 브라우저를 위해 설계되었습니다.

HTML은 브라우저에게 다음과 같은 정보를 알려줍니다:

텍스트가 어디에 위치하는지
어떤 버튼이 존재하는지
페이지가 어떻게 렌더링되어야 하는지

AI 에이전트는 그 중 어떤 것에도 관심이 없습니다.

버튼이 파란색인지 상관하지 않습니다.

개발자가 <a>를 <div>로 변경했는지도 상관하지 않습니다.

에이전트는 동작(actions)에 관심이 있습니다.

로그인 (Login)
검색 (Search)
결제 (Checkout)
파일 업로드 (Upload File)

이것들은 의미론적 개념(semantic concepts)입니다.

HTML은 이를 매우 잘 표현하지 못합니다.

컴파일러처럼 생각하기

컴파일러 설계에는 흥미로운 아이디어가 있습니다.

소스 코드(source code)를 직접 실행하지 않습니다.

먼저 그것을 중간 표현(Intermediate Representation (IR))으로 변환합니다.

그 이후의 모든 것이 거기서부터 구축됩니다.

저는 웹사이트도 같은 방식으로 작동할 수 있을지 궁금했습니다.

HTML을 반복적으로 추론하는 대신...

웹사이트를 한 번 컴파일합니다.

재사용 가능한 의미론적 표현을 생성합니다.

Preflight 진입

컴파일러는 preflight.yaml이라고 불리는 명세(specification)를 생성합니다.

간략한 예시:

version: 1.0.0

actions:

login:
action_type: browser

parameters:
  - email
  - password

add_to_cart:
action_type: api

api:
  method: POST
  url: /api/cart/add

무언가 눈치채셨을 겁니다.

HTML이 없습니다.

XPath도 없습니다.

취약한 셀렉터(selectors)도 없습니다.

오직 액션(actions)만 존재합니다.

API Disco

제가 가장 좋아하는 모듈 중 하나는 API Disco라고 불립니다.

(네, 실제 파일 이름입니다.)

크롤러(crawler)가 브라우저 상호작용을 수행하는 동안, 모든 네트워크 요청을 감시합니다.

만약 특정 액션이 실제로 재사용 가능한 API에 의해 뒷받침되고 있다는 것을 발견하면...

컴파일러가 해당 액션을 자동으로 업그레이드합니다.

브라우저 자동화(browser automation)를 생성하는 대신...

API 기반의 SDK 메서드를 생성합니다.

만약 API가 존재하지 않는다면?

문제없습니다.

생성된 SDK는 단순히 회복 탄력성이 있는 브라우저 실행(resilient browser execution) 방식으로 전환됩니다.

개발자는 그 차이에 대해 전혀 고민할 필요가 없습니다.

하나의 명세, 다중 출력

컴파일러가 preflight.yaml을 생성하고 나면, 그 외의 모든 것은 코드 생성(code generation)의 영역이 됩니다.

현재는 다음을 생성합니다:

Python SDKs
TypeScript SDKs
Rust SDKs
MCP Servers

내일은 다음과 같은 것들도 아주 쉽게 생성할 수 있습니다:

Go SDKs
Java SDKs
C# SDKs

컴파일러는 변하지 않습니다.

오직 백엔드 생성기(backend generator)만 바뀔 뿐입니다.

이것이 흥미롭다고 생각하는 이유

제가 가장 기대하는 것은 사실 컴파일러 자체가 아닙니다.

바로 명세(specification)입니다.

여러 도구가 동일한 의미론적 웹사이트 형식(semantic website format)을 이해하는 미래를 상상해 보세요.

서로 다른 컴파일러.

서로 다른 검증기(validators).

서로 다른 SDK 생성기.

서로 다른 실행 엔진(execution engines).

모두가 동일한 표현(representation)을 공유합니다.

이것은 또 다른 브라우저 자동화 라이브러리보다 훨씬 더 강력하게 느껴집니다.

벤치마크

저 또한 막연한 성능 주장은 피하고 싶었습니다.

그래서 이 리포지토리(repository)에는 다음을 측정하는 공개 벤치마크 방법론이 포함되어 있습니다:

토큰 감소 (Token reduction)
실행 속도 (Execution speed)
신뢰성 (Reliability)
메모리 사용량 (Memory usage)
자가 치유 능력 (Self-healing capability)
개발자 구현 노력 (Developer implementation effort)

목표는 단순히 "벤치마크에서 이기는 것"이 아니었습니다.

목표는 모든 주장을 재현 가능하게 (reproducible) 만드는 것이었습니다.

이것이 브라우저 자동화(Browser automation)의 대체제인가요?

아니요.

어떤 웹사이트들은 재사용 가능한 API를 제공하지 않습니다.

어떤 인증 흐름(authentication flows)은 브라우저 상호작용을 필요로 합니다.

어떤 워크플로우(workflows)는 본질적으로 시각적입니다.

브라우저 자동화는 사라지지 않을 것입니다.

핵심 아이디어는 다음을 분리하는 것입니다:

에이전트가 무엇을 하고자 하는가 (What an agent wants to do)

와

그 동작이 어떻게 실행되는가 (How that action gets executed)

때로는 그것이 API일 수 있습니다.

때로는 브라우저일 수 있습니다.

인터페이스는 동일하게 유지됩니다.

다음 단계는?

현재 로드맵에는 다음이 포함되어 있습니다:

더 많은 SDK 타겟 (Go & Java)
더 나은 API 탐색 (API discovery)
플러그인 아키텍처 (Plugin architecture)
시각적 회귀 지원 (Visual regression support)
최신 웹 프레임워크 전반에 걸친 향상된 호환성

하지만 더 중요한 것은...

다른 개발자분들은 어떻게 생각하시는지 듣고 싶습니다.

제가 잘못된 문제를 풀고 있는 걸까요?

더 나은 추상화 (abstraction)가 있을까요?

preflight.yaml 같은 것이 실제로 이 프로젝트 외부에서도 유용하게 쓰일 수 있을까요?

진심으로 여러분의 논의를 듣고 싶습니다.

링크

🌐 웹사이트

https://adityapdixit.me/shiny-fishstick/

⭐ GitHub

https://github.com/Hootsworth/shiny-fishstick

다른 건 몰라도, 이름만 보고도 클릭하고 싶을 만큼 궁금증이 생기셨기를 바랍니다.

읽어주셔서 감사합니다.