늦은 밤, 어느 AI 개발자의 모니터 앞. 화면 속 브라우저에서는 AI 에이전트가 마우스 커서를 이리저리 움직이며 버튼을 찾고 있지만, 정작 클릭해야 할 입력창을 지나쳐 엉뚱한 곳을 누르는 장면이 반복됩니다. 개발자는 로그 창에 찍히는 '좌표 오류' 메시지를 보며 한숨을 내쉽니다.

지금까지의 웹 에이전트는 마치 눈을 가린 채 상대방의 설명만 듣고 화면의 특정 좌표를 찍어 누르는 방식과 비슷했습니다. 스크린샷이나 HTML 구조를 보고 "다음은 (x, y) 좌표를 클릭해"라고 예측하는 '한 단계씩 실행(action-at-a-time)' 구조였기 때문입니다. 하지만 모델의 코딩 능력이 비약적으로 상승한 지금, 이런 방식은 오히려 발목을 잡는 제약이 되었습니다.

마이크로소프트 리서치(Microsoft Research)의 AI 프론티어 랩은 이 지점에서 완전히 다른 접근법을 시도했습니다. 에이전트에게 브라우저 제어권을 주는 대신, 코드를 짤 수 있는 '터미널'을 쥐여준 것입니다. 이 단순한 관점의 전환이 웹 에이전트의 성능을 어디까지 끌어올렸는지, 그 구체적인 메커니즘을 살펴봅니다.

GPT-5.4 탑재 Webwright, Odysseys 벤치마크 60.1% 달성

개발팀이 공개한 수치는 여기서 갈린다. Webwright(웹브라우저 자동화 프레임워크)에 GPT-5.4를 탑재해 테스트한 결과, Odysseys(여러 웹사이트를 넘나드는 장기 작업 성능 측정 지표) 벤치마크에서 60.1%라는 성적을 기록했다. Odysseys는 평균 272.3단어에 달하는 긴 지침을 수행해야 하는 고난도 테스트다. 이는 기존의 SOTA(State-of-the-Art, 현재 기술 수준에서 가장 성능이 좋은 모델)였던 Opus 4.6이 기록한 44.5%와 비교했을 때 상대적으로 35.1%나 향상된 수치다. 특히 주목할 점은 모델 자체의 기본 성능과의 격차다. 동일한 GPT-5.4 모델을 사용하더라도 기존의 좌표 기반 방식으로는 33.5%에 그쳤으나, Webwright의 제어 방식을 도입하자 60.1%로 뛰었다. 절대 수치로 26.6포인트가 상승했으며, 상대적으로는 79.4%라는 폭발적인 성능 향상을 이뤄낸 셈이다.

이런 결과가 가능했던 이유는 웹을 다루는 근본적인 접근법을 바꿨기 때문이다. 쉽게 말하면 기존의 에이전트들이 화면의 x, y 좌표를 찍어 클릭하는 식으로 한 단계씩 움직였다면, Webwright는 직접 코드를 짜서 브라우저를 조종한다. 비유하자면 예전 방식이 눈을 가린 채 누군가 알려주는 대로 "오른쪽으로 세 걸음 가서 버튼을 눌러"라고 지시받는 수준이었다면, 이제는 "로그인 페이지로 가서 아이디와 비밀번호를 입력하고 접속해"라는 완성된 매뉴얼을 작성해 실행하는 것과 같다. 과거에는 모델의 추론 능력이 낮아 한 단계씩 지시하는 방식이 효율적이었지만, 이제는 코드를 짜고 디버깅하는 능력이 향상되면서 오히려 그런 경직된 루프가 제약이 되었다. 코드 기반 제어는 반복적인 작업이나 복잡한 양식 채우기를 하나의 압축된 프로그램으로 처리할 수 있어 훨씬 정확하고 효율적이다.

또 다른 검증 지표인 Online-Mind2Web(실제 웹사이트에서의 작업 정확도를 측정하는 벤치마크)에서도 강력한 성능을 보였다. GPT-5.4 기반의 Webwright는 86.67%의 전체 정확도를 기록하며 해당 벤치마크의 자동 평가 카테고리에서 가장 높은 성적을 거두었다. 경쟁 모델인 Claude Opus 4.7의 경우 전체 정확도는 84.7%로 GPT-5.4보다 약간 낮게 나타났다. 다만 세부 항목으로 들어가면 양상이 조금 다르다. 고난도 작업에서는 Claude Opus 4.7이 80.5%의 정확도를 보이며 GPT-5.4의 76.6%를 앞섰다. 이는 전반적인 작업 수행 능력과 범용성 측면에서는 Webwright가 우세하지만, 매우 복잡한 추론이 필요한 특정 영역에서는 여전히 모델별 강점이 나뉜다는 점을 시사한다.

터미널 환경과 Playwright(브라우저 자동화 라이브러리)의 결합

기존의 웹 에이전트가 마치 사람이 마우스를 잡고 화면을 하나하나 클릭하며 따라가는 방식이었다면, 이번에 도입된 구조는 에이전트에게 직접 코드를 짜서 브라우저를 제어하게 만드는 방식이다. 쉽게 말하면, 이전에는 에이전트가 화면만 보고 즉흥적으로 반응했다면 이제는 필요한 기능을 코드로 작성해 실행하는 개발자의 작업 방식을 그대로 따르는 셈이다. 이를 위해 마이크로소프트가 개발한 오픈소스 브라우저 자동화 라이브러리인 Playwright를 핵심 도구로 활용한다. Playwright는 Chromium, Firefox, WebKit과 같은 주요 브라우저를 프로그램 코드로 자유롭게 조종할 수 있게 해주며, 에이전트는 이를 통해 브라우저 세션에 종속되지 않고 독립된 환경에서 유연하게 작업한다.

이 시스템의 구조는 크게 세 가지 핵심 요소로 나뉜다. 전체 흐름을 관리하는 Runner(약 150라인), 모델과 통신하며 지능적인 판단을 내리는 Model Endpoint(약 550라인), 그리고 실제 코드가 실행되는 터미널 환경인 Environment(약 300라인)가 그것이다. 비유하자면 Runner는 지휘자, Model Endpoint는 설계자, Environment는 실제 물건을 만드는 작업대 역할을 한다. 에이전트는 먼저 자신의 생각을 담은 Thinking block을 생성한 뒤, 실행할 셸 명령어를 반환한다. 그러면 Environment가 이 명령어를 수행하고, 그 결과로 나온 로그나 스크린샷을 다시 모델에게 전달해 다음 단계로 나아간다. 이 과정에서 브라우저는 에이전트가 필요할 때마다 띄우고 결과를 확인한 뒤 버릴 수 있는 일회성 도구가 되며, 대신 에이전트가 작성한 코드와 실행 기록이 작업의 핵심 자산으로 남는다.

에이전트가 스스로 판단을 내리는 과정에는 자기 성찰 게이트(Self-reflection gate)라는 안전장치가 존재한다. 단순히 작업이 끝났다고 판단하는 것을 넘어, 최종 스크립트를 별도의 새 폴더에서 다시 실행해보고 스스로 성공 여부를 검증해야만 비로소 'done: true'라는 완료 신호를 보낼 수 있다. 만약 검증 과정에서 오류가 발견되면 이 신호는 무시되고 다시 수정 작업을 반복하게 된다. 또한 긴 작업을 수행할 때 발생하는 컨텍스트 길이 제한 문제를 해결하기 위해, 20단계마다 누적된 기록을 하나의 요약본으로 압축하는 컨텍스트 압축 기술을 적용했다. 이러한 구조 덕분에 에이전트는 복잡한 다단계 작업을 작은 단위의 명령어가 아닌, 반복문과 함수가 포함된 하나의 완성된 프로그램으로 처리할 수 있게 되었고, 결과적으로 웹 자동화 성능을 획기적으로 높일 수 있었다.

'좌표 예측'과 '코드 작성'의 결정적 차이

기존의 웹 에이전트들은 브라우저 화면을 한 장의 사진처럼 보고 다음 행동을 결정했다. 모델이 스크린샷이나 DOM(Document Object Model, 웹페이지의 구조를 트리 형태로 나타낸 문서)을 분석해 다음에 클릭할 x, y 좌표나 입력할 키보드 값을 하나씩 예측하는 방식이다. 비유하자면 마치 눈을 가린 사람에게 오른쪽으로 1cm, 아래로 2cm 이동하라고 아주 세밀하게 지시하는 것과 같다. 이런 단발성 행동 예측 방식은 모델의 추론 능력이 낮았던 초기에는 유효했지만, 이제는 오히려 모델의 성능을 제한하는 족쇄가 되었다.

반면 웹라이트(Webwright)는 브라우저를 직접 조작하는 대신 터미널을 통해 코드를 작성한다. 모델이 플레이라이트(Playwright, 브라우저 자동화 라이브러리) 코드를 짜서 브라우저를 제어하고, 셸 명령어를 실행하며 로그를 확인해 스크립트를 수정하는 식이다. 쉽게 말하면 개별 클릭 좌표를 찍는 대신 날짜 선택이나 폼 채우기 같은 다단계 작업을 하나의 콤팩트한 프로그램으로 만드는 것이다. 루프나 함수 같은 프로그래밍 개념을 활용해 복잡한 상호작용을 추상화하므로, 매번 저수준의 좌표를 예측할 필요 없이 효율적으로 작업을 수행한다.

작업의 영속성을 관리하는 관점에서도 큰 차이가 있다. 기존 방식은 브라우저 세션 자체가 중심이었기에 세션이 끊기면 그동안의 맥락을 잃기 쉬웠다. 하지만 웹라이트는 로컬 워크스페이스에 저장되는 코드와 로그를 중심으로 움직인다. 이는 개발자가 RPA(Robotic Process Automation, 반복적인 업무를 자동화하는 소프트웨어) 스크립트를 짜는 과정과 매우 유사하다. 브라우저를 단순히 실행하고 검사한 뒤 버릴 수 있는 도구로 취급하며, 실제로 남는 결과물은 수정 가능한 코드와 실행 기록이라는 점이 핵심이다.

이러한 접근 방식의 변화는 실제 성능 차이로 이어진다. 동일한 GPT-5.4 모델을 사용해 테스트했을 때, 좌표를 예측하는 기존 방식보다 코드를 작성하는 터미널 방식이 모든 난이도 영역에서 우세한 결과를 보였다. 단순한 클릭의 반복이 아니라 논리적인 프로그램 구조로 웹을 제어하는 것이 LLM의 추론 능력을 훨씬 더 잘 끌어낸다는 사실이 증명된 셈이다.

토큰 비용과 효율성: GPT-5.4 vs Claude Opus 4.7

개발팀이 공개한 수치는 여기서 갈린다. 작업을 완료하는 데 필요한 평균 단계 수를 보면 클로드 오푸스 4.7(Claude Opus 4.7)이 21.9단계로, GPT-5.4의 26.3단계보다 더 빠르게 목표에 도달했다. 쉽게 말하면 클로드가 더 적은 횟수의 시도로 정답을 찾아내는 효율적인 경로를 택했다는 뜻이다. 비유하자면 목적지까지 가는 길을 찾을 때 GPT-5.4가 여러 갈래 길을 꼼꼼하게 확인하며 이동했다면, 클로드는 더 직관적으로 최단 거리를 찾아 움직인 셈이다. 웹 에이전트에게 한 단계란 코드를 작성하고 실행한 뒤 로그를 확인하고 다시 수정하는 한 번의 사이클을 의미한다. 따라서 단계 수가 적다는 것은 AI가 불필요한 시행착오를 줄이고 더 명확한 논리로 브라우저를 제어했다는 증거가 된다.

하지만 실제 운영 비용으로 시선을 돌리면 이야기가 완전히 달라진다. 2026년 4월 기준 입력 토큰 비용은 GPT-5.4가 100만 토큰당 2.50달러인 반면 클로드 오푸스 4.7은 5달러로 정확히 두 배 비싸다. 출력 토큰 비용 역시 GPT-5.4는 15.00달러, 클로드 오푸스 4.7은 25달러로 상당한 격차를 보인다. 토큰(Token)은 AI가 글자를 읽고 쓰는 최소 단위이며, 이 단위가 많아질수록 청구되는 금액이 늘어나는 구조다. 특히 출력 토큰은 모델이 사고 과정을 생성하는 비용이기에 단가가 더 높게 책정된다. 비유하자면 클로드가 일 처리 속도는 더 빠르지만 시간당 인건비가 훨씬 높은 고단가 전문가인 셈이다. 결국 작업당 평균 비용을 계산하면 GPT-5.4는 2.37달러가 소요되지만 클로드는 6.09달러가 들어 GPT-5.4가 약 2.5배 더 경제적인 선택지가 된다.

실무 관점에서 가장 흥미로운 지점은 정확도가 급격히 상승하는 구간이다. 두 모델 모두 첫 50단계 내에서 이미 82%의 정확도를 달성했다는 사실이 확인되었다. 이는 매우 복잡한 웹 작업이라도 초반의 집중적인 코드 실행과 수정만으로 대부분의 정답을 찾아낼 수 있음을 시사한다. 실제로 이후 50단계를 더 추가해 총 100단계를 사용해도 정확도는 겨우 3~4%포인트 정도만 소폭 상승하는 수준에 그쳤다. 개발자나 기업 운영자 입장에서는 무조건 단계를 늘려 완벽함을 추구하기보다, 비용 효율이 극대화되는 지점에서 작업을 마무리하는 전략을 세울 수 있다. 특히 수만 건의 작업을 자동화해야 하는 환경에서 작업당 3.72달러의 비용 차이는 전체 예산 규모를 결정짓는 결정적인 변수가 된다.

소형 모델의 가능성과 한국 AI 실무자의 시사점

거대 언어 모델이 모든 문제를 해결할 것이라는 기대와 달리, 실제 산업 현장에서는 비용과 효율성이라는 현실적인 벽에 부딪히기 마련이다. 이번 연구에서 주목할 만한 지점은 알리바바가 개발한 소형 모델인 Qwen3.5-9B의 성능이다. 테스트 결과, 이 모델은 사전 구축된 재사용 도구 스크립트를 활용했을 때 Online-Mind2Web(웹 기반 에이전트의 복잡한 작업 수행 능력을 측정하는 벤치마크)의 고난도 작업에서 66.2%라는 높은 성공률을 기록했다. 쉽게 말하면, 모델의 덩치를 무작정 키우지 않아도 잘 짜여진 도구 상자만 쥐여주면 복잡한 웹 작업도 충분히 수행할 수 있다는 뜻이다. 비유하자면, 숙련된 요리사에게 모든 재료를 직접 다듬으라고 시키는 대신, 이미 손질된 식재료와 잘 정리된 조리 도구를 제공함으로써 주방의 회전율을 극대화한 것과 같다.

이러한 결과는 한국의 AI 실무자들에게 명확한 시사점을 던진다. 그동안 기업들은 성능을 위해 무조건적인 거대 모델 도입을 고민해 왔지만, 이제는 도구 라이브러리와 소형 모델을 조합하는 방식이 훨씬 비용 효율적인 대안이 될 수 있다. 특히 단순 반복 작업을 자동화하는 RPA(로봇 프로세스 자동화) 수준을 넘어, 에이전트가 스스로 코드를 수정하고 오류를 바로잡으며 목표를 달성하는 코딩 에이전트로의 전환이 필수적이다. 단순히 버튼을 클릭하는 로봇이 아니라, 상황에 맞춰 스크립트를 재작성하는 능동적인 해결사를 현장에 배치해야 한다는 의미다. 실무 환경에서 미리 구축된 도구 라이브러리는 에이전트가 매번 처음부터 고민하지 않게 돕는 일종의 매뉴얼 역할을 수행한다. 결과적으로 한국 기업들은 인프라 비용 부담을 획기적으로 줄이면서도, 복잡한 웹 업무를 자동화하는 실질적인 생산성 향상을 꾀할 수 있게 되었다. 이제는 모델의 규모보다 어떻게 도구를 연결하고 에이전트에게 코딩이라는 언어를 학습시킬 것인가가 기술 경쟁력의 핵심이 될 것이다.