원문: How we built the SOTA browser agent that outperforms Fable — Aside 팀 번역일: 2026-07-29
Aside는 여러 에이전틱 브라우징 벤치마크에서 최고 점수를 받았다. 인터넷 반응은 "그거 그냥 너희들 말이잖아(trust me bro)"였다.
맞는 말이다. 솔직히 우리도 처음엔 안 믿었다. 진짜로, 벤치마크를 돌린 시간보다 결과를 검증하는 데 더 많은 시간을 썼다.
하지만 이건 운이 아니다. 우리는 에이전트 하네스(harness)를 처음부터 직접 만들었고, 우리만의 원칙에 맞춰 촘촘하게 설계했다. 이 글에서 그 비법을 공유한다.
Aside는 무엇인가?
Aside는 이미 쓰고 있는 웹사이트 위에서 실제 업무를 처리하도록 만들어진 브라우저다.
나는 브라우저를 정말 좋아하는 사람인데, Dia, Perplexity Comet, ChatGPT Atlas에는 실망했다. 이들의 에이전트가 너무 멍청해서 단 하나의 작업도 끝까지 완수하지 못했기 때문이다.
그래서 우리는 진짜 AI 브라우저를 처음부터 만들었다.
- 가볍고 빠른 Chromium 포크. 세심하게 다듬은 디자인 디테일.
- 여러분이 이미 로그인해 둔 계정을 그대로 사용한다. 사람이 쓰는 것과 똑같은 방식으로. 별도 연동도, API 접착제도 없다.
- 로컬 임베딩 모델로 구동되는 자기조직화 메모리로 작업 내역을 기억한다.
- 인증 정보(credentials)는 모델에게 절대 노출되지 않은 채 페이지에 자동으로 채워진다. 민감한 작업은 사용자 승인을 기다린다.
벤치마크 결과
우리는 Online-Mind2Web, BU-Bench-V1, Odyssey 세 개의 브라우저 에이전트 벤치마크에서 1위를 차지했다. 모든 벤치마크 실행 데이터는 https://github.com/at-inc/aside-benchmarks에 공개돼 있다.
Online-Mind2Web
가장 널리 보고되는 브라우저 에이전트 벤치마크다. 136개의 실제 운영 중인 웹사이트에서 300개의 실전 과제(real-world tasks)를 다루며, 다양한 소비자 워크플로를 포괄한다. 모든 웹 에이전트가 비교당하는 바로 그 벤치마크다.
Aside + GPT 5.5는 99.0%를 기록했다. GPT-5.4 + CUA는 92.8%, Opus 4.8 + Claude Code(Playwright MCP)는 84.0%(우리 실행 기준), ChatGPT Atlas는 70.0%였다.
Odyssey
Odyssey는 CMU가 만든 장기 호라이즌(long-horizon) 벤치마크다. 실제 사용자의 브라우징 히스토리에서 뽑아낸 200개의 멀티사이트 과제로, 예를 들어 "MLB 구장 30곳을 모두 도는 여행을 계획해라"나 "LA에서 테슬라 모델3 리스와 1만 달러 이하 대체 상품을 비교하라" 같은 과제다.
Aside는 GPT 5.5로 75.5%를 기록해 최고 점수를 세웠다.
BU-Bench-V1
Browser Use의 공개 벤치마크다. WebBench, Mind2Web 2, GAIA, BrowseComp에서 뽑은 100개의 엄선된 고난도 과제로 구성된다.
Aside + GPT 5.5는 93.0%를 기록했다. Fable 5 + Claude Code(Playwright MCP)는 우리 실행 기준 80%를 받았고, Fable 5 + Browser Use OSS도 80%를 기록했다.
재미있는 사실 하나: Aside + Kimi K2.6은 Fable 5 + Claude Code를 이기기까지 했다.
그런데 모델을 자기 하네스랑 비교하는 게 말이 안 되는 거 아닌가?
맞다. 여러분 말이 백 번 옳고, 어그로 끌어서 미안하다.
하지만 내가 진짜 하고 싶은 얘기는 우리 하네스의 효율성이다.
하네스는 정말 중요하다. 모델이 여전히 성능의 천장을 결정하긴 하지만, 더 나은 에이전트 하네스를 만들면 최적화할 수 있는 여지가 상당히 많다.
가장 똑똑한 브라우저 하네스를 만든 방법
우리는 하네스 대부분을 처음부터 직접 만들었다.
토대로는 pi-mono/core를 선택했지만, 그 위에 올라가는 나머지(예: 컴팩션, 스킬, 훅, 샌드박스, REPL, bash, 브라우저 자동화)는 전부 직접 만들어야 했다. 우리만의 원칙을 지키고 싶었기 때문이다.
원칙
1. 모델의 학습 데이터를 따라가라.
Aside는 코딩 에이전트다. 그렇다, 제대로 들었다. Aside를 처음 설계할 때 나는 스스로에게 물었다: LLM이 가장 많이 본 데이터가 뭘까? 코드다.
내가 2016년에 머신러닝 연구를 시작했을 때, 내 핵심 믿음은 단순했다. 모든 ML 모델은 그저 통계적인 비선형 함수일 뿐이라는 것. 그러니 여러분이 프론티어 모델을 직접 만드는 게 아니라면, 최선의 선택은 모델의 학습 데이터 분포를 따라가는 것이다.
그래서 우리의 핵심 도구는 Playwright 문법 위에 구축한 JS REPL이다. Playwright가 가장 널리 쓰이는 문법이기 때문이다.
2. 최소한의 지시가 더 높은 지능을 만든다.
우리는 환각(hallucination)과 멍청한 행동이 대부분 두 가지에서 나온다는 걸 발견했다. 현재 상태에 대한 부실한 설명, 그리고 서로 충돌하는 지시.
그래서 우리는 시스템 프롬프트를 최대한 짧게 유지한다. 우리 프롬프트는 도구 정의를 포함해서 1만 토큰이 든다. Claude Code는 2만 토큰을 태운다.
우리는 또한 AI가 프롬프트를 쓰게 두지 않는다. 그러면 슬롭(slop) 위에 슬롭만 쌓일 뿐이다. 벤치마크에 대해 오토리서치(autoresearch)를 돌리면 "X일 때는 Y를 해라" 같은 벤치맥싱(benchmaxxing) 규칙이 홍수처럼 쏟아진다.
3. 컨텍스트 윈도우를 지켜라.
컨텍스트 윈도우 안의 쓸모없는 토큰은 만악의 근원이다. 도구 출력이 노이즈로 가득할 때(예를 들어 div와 스타일이 콘텐츠의 90%를 차지하는 DOM 캡처), 혹은 지시문이 관련 없는 디테일로 부풀어 있을 때, 모델의 성능은 빠르게 저하된다.
좋은 하네스는 도구 출력을 신호는 높고 노이즈는 낮게 유지한다. 예를 들어 CDP나 원시 DOM은 브라우저 제어에 좋지 않은 선택이다. 프로토콜이 모델이 파싱하기엔 너무 원시적(raw)이다. 그래서 우리는 대신 커스터마이즈한 접근성 트리(a11y tree)를 쓴다.
4. 거인의 어깨 위에 서라.
우리가 모든 걸 처음부터 발명한 건 아니다. Codex, Claude Code, OpenCode, oh-my-opencode 같은 훌륭한 오픈소스 프로젝트에서 많이 빌려왔다.
Aside는 코딩 에이전트다.
Aside는 기본적으로 코딩 에이전트다. 핵심 도구는 딱 두 개, REPL과 bash뿐이다. Aside는 브라우저를 제어할 때 Playwright JS 코드를 작성하는데, 이는 전용 브라우저 제어 툴셋을 쓰는 OpenClaw나 Hermes와는 다른 방식이다.
왜 JS REPL이냐고? 모델의 학습 데이터와 가장 가깝고, 코드가 논리와 데이터를 표현하는 가장 명확한 방법이기 때문이다. 이게 실전 과제에서 중요하다. Aside가 복잡한 폼을 채우고 유튜브 영상을 프레임 단위로 살펴볼 수 있는 건, 에이전트가 코드를 직접 쓸 수 있기 때문이다.
가끔 Aside는 사이트의 API를 역공학(reverse-engineer)한다. 정상적인 경로가 막혀 있으면, 네트워크 요청을 캡처해서 내부 API를 알아내고 이를 우회 수단으로 쓴다. 이 요청은 사이트 자체의 요청과 똑같아 보여서 봇으로 플래그되지 않는다. Aside를 코딩 에이전트에 더 가깝게 만들었더니 이런 영리한 부수 효과가 생겼다는 점이 마음에 든다.
Playwright는 LLM이 이미 알고 있는 브라우저 언어다.
왜 Playwright냐고? LLM이 가장 많이 본 브라우저 자동화 API이기 때문이다. OpenAI조차 GPT-5.4가 Playwright를 잘 쓰도록 학습됐다고 밝힌 바 있다. 내 첫 반응은 단순했다. 모델이 이미 이 인터페이스를 알고 있는데, 왜 새 걸 발명하지?
놀라운 점은 우리 프롬프트가 Playwright를 가르치지 않는다는 것이다. Playwright MCP는 이걸 설명하는 데 1만 3천 토큰을 쓴다. 우리는 그냥 "Playwright를 쓸 수 있다"고만 말한다. 그런데도 Aside가 더 잘 작동하는 건, 토큰을 아끼고 불필요한 지시를 피했기 때문이다.
참고: CDP는 나쁜 선택이다.
최근 브라우저 제어에 CDP를 쓰는 흐름을 봤다. 우리는 이게 대체로 나쁜 생각이라고 본다(browser-harness에겐 미안하지만). 엔지니어 관점에서는 하나의 인터페이스로 모든 걸 다루니 근사해 보인다. 하지만 문제는 단순하다.
- LLM은 CDP를 쓰도록 학습되지 않았다
- CDP는 저수준 디버거 프로토콜이다
- 토큰을 낭비하고, LLM이 다루기 어려워한다
앞서 말했듯, LLM의 학습 데이터 분포와 싸우지 않는 게 낫다. 핵심은 모델이 이미 이해하는 올바른 추상화를 선택하는 것이다.
Playwright → Asidewright
하지만 Playwright는 E2E 테스트 자동화용으로 설계된 것이라 에이전트용으로 쓰기엔 무겁고 비대하다. 그래서 우리는 자체 버전인 Asidewright를 만들었다.
- LLM에게 익숙함: 인터페이스가 Playwright와 100% 동일하다
- 경량: 각 API는 CDP 메서드를 얇게 감싼 견고한 래퍼일 뿐이다. 주입 스크립트도, 미들 레이어도, 불필요한 요소도 없다
- 토큰 효율적: agent-browser 대비 최대 80% 적은 토큰을 쓴다
- 에이전트 시그널: 팝업이 열림, 다운로드 시작됨, 탭이 닫힘 같은 스티어링(steering) 메시지로 비동기 이벤트를 에이전트에 보고한다
토큰 효율적인 a11y 스냅샷
최근 웹 상호작용의 표준은 접근성 트리(accessibility tree)다. Claude, agent-browser, Playwright MCP, OpenClaw 모두 ref ID가 붙은 접근성 트리를 사용한다.
우리는 자체 수정된 접근성 트리를 만들었다. 휴리스틱으로 많은 중간 요소를 제거하고, 포커스 상태·iframe ID·클릭 가능 상태 같은 LLM에 도움이 되는 정보를 추가했다.
aside.com/sota를 스냅샷 찍어 agent-browser와 비교해본 결과, Aside의 출력이 70% 더 작으면서도 핵심 정보가 앞쪽에 꽉 채워져 있었다. 즉 도구 결과가 잘려 나갈 때도 에이전트가 중요한 디테일을 놓칠 가능성이 훨씬 낮다는 뜻이다.
폴백: 스크린샷 기반 컴퓨터 사용(Computer Use)
물론 일부 웹사이트는 DOM으로 제어할 수 없다. 그래서 필요할 때 Aside가 시각 정보와 클릭 좌표를 쓸 수 있도록 Asidewright에 CUA 인터페이스를 추가했다.
실제 사용자 브라우저 안에서 작동하게 만드는 기술적 디테일
헤드리스(headless) 브라우징 에이전트를 만드는 것과, 실제 사용자의 브라우저 안에 사는 에이전트를 만드는 것은 완전히 다른 이야기다.
탭이 백그라운드에서 열린다. 크롬 확장 기반 AI 에이전트는 실행할 때마다 사용자의 포커스를 뺏어간다. 우리는 크로미움의 Blink 엔진을 패치해서, 에이전트가 연 탭이 포커스를 가져가지도, 팝업을 열지도, 사용자의 포그라운드 작업을 방해하지도 않도록 만들었다.
봇 탐지 회피. Browserbase와 Browser Use가 쓰는 것과 같은 기법으로 크로미움 내부를 수정했다.
뷰포트를 1440x900으로 고정. Codex Browser를 써본 적이 있다면 이 혼란을 알 것이다. 화면 크기를 조절할 때마다 브라우저 창이 이동하고, 모든 액션이 깨진다.
우리는 Blink를 패치해서, 사용자의 창 크기와 무관하게 에이전트가 연 백그라운드 탭이 항상 1440x900으로 렌더링되도록 만들었다.
Aside의 백그라운드 탭 모드: Aside는 뷰포트를 고정 크기로 잠근다.
덤으로, 대부분의 CUA 학습 데이터가 이 해상도 근처에 몰려 있다. 그래서 CUA 모델이 이 해상도에서 훨씬 잘 작동한다. 첫 번째 원칙을 기억하라: 모델의 학습 데이터를 따라가라.
결론
Aside가 Fable을 이겼다는 주장은 솔직히 약간의 어그로다. 하지만 스텔스 모드로 지낸 지난 4개월 동안 우리는 최상위 성능을 내는 SOTA 에이전트를 만들었다. 이는 실험, 리서치, 그리고 세심한 엔지니어링의 결과물이다.
우리가 이렇게까지 신경 쓰는 이유는, Aside가 웹사이트를 도구 삼아 사용자의 일상적인 업무를 대신 처리하는 에이전트이기 때문이다. 실제 업무는 코딩보다 훨씬 지저분하다. 그래서 범용 에이전트에게는 잘 만든 하네스가 사람들이 생각하는 것보다 훨씬 더 중요하다.
궁금한가? 지금 Aside를 다운로드하라: Aside.com
핵심 요약 (20줄)
- AI 브라우저 스타트업 Aside가 Online-Mind2Web·Odyssey·BU-Bench-V1 세 개의 브라우저 에이전트 벤치마크에서 모두 1위를 차지했다고 발표한다.
- Dia, Perplexity Comet, ChatGPT Atlas의 에이전트가 실제 작업을 끝까지 완수하지 못하는 데 실망해 처음부터 새 브라우저를 만들었다고 밝힌다.
- Aside는 사용자가 이미 로그인한 계정을 그대로 사용하고, 로컬 임베딩 기반 자기조직화 메모리로 작업 내역을 기억하며, 인증 정보는 모델에 노출되지 않는다.
- Online-Mind2Web(136개 사이트 300개 과제)에서 Aside+GPT 5.5가 99.0%를 기록해 GPT-5.4+CUA(92.8%), Opus 4.8+Claude Code(84.0%), ChatGPT Atlas(70.0%)를 앞섰다.
- CMU의 장기 호라이즌 벤치마크 Odyssey에서 Aside+GPT 5.5가 75.5%로 최고 점수를 세웠다.
- Browser Use의 BU-Bench-V1에서 Aside+GPT 5.5가 93.0%를 기록해 Fable 5+Claude Code(80%)를 앞질렀고, Aside+Kimi K2.6조차 Fable 5+Claude Code를 이겼다.
- 모델을 자기 하네스와 비교하는 것이 불공정하다는 비판을 인정하면서도, 모델이 성능의 천장을 정하지만 더 나은 에이전트 하네스로 최적화할 여지가 크다고 반박한다.
- 핵심 원칙 1은 "모델의 학습 데이터를 따라가라"로, LLM이 가장 많이 본 데이터가 코드이기 때문에 Aside를 코딩 에이전트로 설계하고 Playwright 문법 기반 JS REPL을 핵심 도구로 삼았다.
- 핵심 원칙 2는 "최소한의 지시가 더 높은 지능을 만든다"로, 시스템 프롬프트를 도구 정의 포함 1만 토큰으로 압축했으며 이는 클로드 코드의 2만 토큰의 절반 수준이다.
- AI에게 프롬프트를 직접 쓰게 하면 슬롭 위에 슬롭이 쌓이고 벤치맥싱 규칙만 늘어난다며 이를 지양한다고 밝힌다.
- 핵심 원칙 3은 "컨텍스트 윈도우를 지켜라"로, CDP나 원시 DOM 대신 커스터마이즈한 접근성 트리(a11y tree)를 사용해 신호 대비 노이즈를 낮췄다고 설명한다.
- 핵심 원칙 4는 "거인의 어깨 위에 서라"로, Codex·Claude Code·OpenCode 등 오픈소스 프로젝트에서 많은 부분을 차용했다고 밝힌다.
- Aside의 도구는 REPL과 bash 단 두 개뿐이며, 코드를 직접 작성할 수 있어 복잡한 폼 작성이나 유튜브 프레임 단위 분석은 물론 사이트 API를 역공학해 우회하는 부수 효과까지 얻었다고 설명한다.
- Playwright MCP가 문법 설명에만 1만 3천 토큰을 쓰는 반면, Aside는 "Playwright를 쓸 수 있다"는 한 문장만으로 토큰을 아끼면서도 더 나은 성능을 낸다고 주장한다.
- CDP는 LLM이 학습하지 않은 저수준 디버거 프로토콜이라 토큰을 낭비하고 다루기 어렵다며, 모델이 이미 이해하는 추상화를 골라야 한다고 강조한다.
- Playwright가 E2E 테스트용이라 무겁다는 문제를 해결하기 위해, 인터페이스는 동일하지만 CDP를 얇게 감싸 최대 80% 적은 토큰을 쓰는 자체 경량 버전 'Asidewright'를 만들었다.
- 자체 수정한 접근성 트리는 불필요한 중간 요소를 제거하고 포커스 상태 등 유용한 정보를 추가해, 동일 페이지 스냅샷에서 agent-browser 대비 70% 더 작은 출력을 만들어낸다.
- 크로미움 Blink 엔진을 직접 패치해 에이전트가 연 백그라운드 탭이 사용자 포커스를 뺏지 않고, 화면 크기와 무관하게 항상 1440x900 해상도로 고정 렌더링되도록 만들었다(대부분의 CUA 학습 데이터가 이 해상도에 몰려 있어서다).
- 봇 탐지를 피하기 위해 Browserbase·Browser Use와 같은 방식으로 크로미움 내부를 수정했다고 밝힌다.
- 벤치마크 결과 발표를 어그로로 인정하면서도, 4개월간의 스텔스 개발 끝에 나온 SOTA 성능은 실험과 정교한 엔지니어링의 결과이며, 실제 업무는 코딩보다 지저분하기 때문에 범용 에이전트일수록 잘 만든 하네스가 더 중요하다고 결론짓는다.