컴퓨터 사용이란 무엇이며, 왜 중요한가? 컴퓨터 사용은 간단하지만 파급력이 큰 개념입니다. 모델에 질문의 답을 요구하는 대신 웹사이트 탐색, 양식 작성, 워크플로 클릭, 전체 작업의 자율적 완료 등 소프트웨어 조작을 맡기는 것입니다.
이를 통해 전체 예약 절차, 전자상거래 결제, 여러 단계의 여행 계획, 깔끔하게 대응되는 API가 없는 백오피스 워크플로처럼 현재 여러 인터페이스에 분산된 다양한 현실 세계의 작업을 수행할 수 있습니다. 이는 새로운 문제가 아닙니다. 새로운 점은 범용 모델로 이러한 문제를 해결할 수 있게 되었다는 것입니다.
Anthropic과 OpenAI의 최신 시스템은 행동에 그치지 않고 상태를 추론하고 오류를 복구하며 작업별 해법을 즉석에서 구성하는 에이전트를 선보였습니다. 이에 따라 브라우저는 에이전트를 위한 범용 실행 환경이 되지만, 곧바로 한 가지 설계 문제가 제기됩니다. 이 환경을 모델에 어느 정도까지 공개해야 할까요?
초기 시스템은 브라우저를 안전한 사전 정의 작업의 고정된 집합으로 감싸는 방식을 택했습니다. 이 글에서 설명하겠지만, 그 접근 방식은 한계에 다다르고 있습니다.
브라우저 에이전트를 구축할 때 흔히 드는 생각이 있습니다. 모델을 지나치게 신뢰하지 말자는 것입니다.
그래서 브라우저를 래퍼로 감쌉니다. click, type, scroll, select, read_text처럼 사전 정의된 도구를 제공합니다. 문서 객체 모델(DOM)을 단순화합니다. 가능한 작업의 범위를 줄입니다. 직접 설계한 추상화를 통해 동작을 이해하고 제어하기 쉽게 만들려고 합니다.
이는 합리적인 출발점입니다. 하지만 장기적인 관점에서는 갈수록 잘못된 아키텍처가 되고 있습니다.
프런티어 모델이 발전하면서 더 이상 문제는 모델에 도구가 부족하다는 데만 있지 않습니다. 근본 시스템의 정보를 지나치게 제거하는 추상화를 통해 모델이 작동하도록 강요하고 있다는 점이 문제입니다. 복잡하고 역동적인 환경을 고정된 작업 인터페이스로 압축한 다음, 정보가 손실된 그 환경 안에서 모델이 좋은 성능을 내기를 요구합니다.
이러한 절충안의 매력은 갈수록 떨어지고 있습니다.
우리가 탐구해 온 전환은 설명하기는 쉽지만 그 결과는 중대합니다. 에이전트를 사전 정의된 작업의 선택기로 보는 대신, 제약된 런타임 안에서 작동하는 프로그램 합성기로 봅니다.
모델의 성능은 크게 향상되었고 더 이상 추상화된 가드레일이 필요하지 않습니다. 목표를 달성할 때까지 작업을 설계하고 실행하며 반복할 수 있는 완전한 작업 공간이 필요합니다.
이 글에서는 추상화 중심의 브라우저 자동화에서 제약된 컴퓨터 사용으로의 전환과, 시스템을 이런 방식으로 설계할 때 무엇이 달라지는지 살펴봅니다.
고정된 작업 인터페이스의 개념 자체가 잘못된 것은 아닙니다. 웹이 그 방식에 맞춰 움직이지 않는다는 것이 문제입니다.
최신 인터페이스는 React, Vue, Angular를 기반으로 하며, 비동기 상태 업데이트와 합성 이벤트 시스템, 자체 수명 주기를 지닌 교차 출처 iframe 안의 서드 파티 위젯을 사용합니다. “이 입력란에 입력”이라는 래퍼는 페이지가 입력에 대한 래퍼의 정의를 따를 때만 올바르게 작동합니다. 많은 페이지가 그렇지 않습니다. 값을 직접 설정하면 프레임워크의 변경 감지를 완전히 우회하는 경우가 많습니다. 입력란은 채워진 것처럼 보입니다. 검증은 전혀 실행되지 않습니다. 양식은 여전히 작동하지 않습니다.
패치를 적용할 수는 있습니다. React 입력란을 위한 예외 처리를 추가하고, 포커스 후 blur 이벤트를 보내고, 상태를 읽기 전에 네트워크가 유휴 상태가 될 때까지 기다릴 수 있습니다. 각 패치는 해당 상황에서는 올바릅니다. 하지만 패치가 쌓이면 시스템은 갈수록 유지 관리하기 어려워지고, 이미 접해 본 사이트에만 점점 더 특화됩니다.
더 근본적인 문제는 상호작용 방식에 대한 가정을 추상화 계층에 구현한 뒤, 웹에는 그와 다른 가정이 있다는 사실을 뒤늦게 알게 된다는 것입니다.
Stripe나 Adyen을 통해 교차 출처 iframe 안에 삽입된 결제 양식을 생각해 보겠습니다. 이 양식은 별도의 출처에 있으므로 래퍼가 직접 접근할 수 없습니다. read_text 도구는 내부 상태를 확인할 수 없습니다. type 도구는 그 안의 입력란에 접근할 수 없습니다. 래퍼 기반 에이전트는 여기서 막힙니다. 추상화는 기본 문서를 대상으로 설계되었습니다. 실제 작업은 추상화가 볼 수 없는 곳에 있습니다.
덜 명확한 절차에서도 비슷한 불일치가 나타납니다. 프레임워크가 제어하는 드롭다운은 직접 클릭해도 전혀 반응하지 않을 수 있습니다. 화면에 보이는 요소가 실제 컨트롤이 아니기 때문입니다. 내부 상태 전환을 일으키려면 일련의 키보드 이벤트가 필요할 수도 있습니다. 겉으로 보면 UI는 클릭할 수 있는 것처럼 보입니다. 추상화는 “클릭”하라고 합니다. 아무 일도 일어나지 않습니다.
또는 표시된 DOM의 업데이트가 내부 상태 변경보다 늦는 여러 단계의 모달 절차를 생각해 보겠습니다. 다음에 수행할 올바른 작업은 래퍼에 보이는 요소에는 아직 반영되지 않은 상태 전환에 따라 달라집니다. 래퍼 기반 에이전트는 시스템을 불완전하게 파악한 채 작동하므로 너무 일찍 행동하거나 오래된 상태를 읽게 됩니다.
각 사례에서 추상화는 에이전트에게 실제로 필요한 신호를 숨깁니다.
더 낮은 수준에서 작동하며 실시간 DOM을 점검하고 프레임 경계를 추론하며 해당 인터페이스에 맞는 상호작용 순서를 합성하는 모델은 이런 상황을 헤쳐 나갈 수 있습니다. 모델 자체가 본질적으로 더 똑똑해서가 아닙니다. 제거되었던 정보에 접근할 수 있기 때문입니다.
우리가 추진해 온 변화는 간단히 설명할 수 있습니다. 모델에 사전 정의된 작업 중 하나를 선택하게 하는 대신, 더 낮은 수준의 실행 인터페이스를 제공하고 추상화 설계가 아닌 런타임 정책으로 이를 제약하는 것입니다.
이러한 설계 선택은 더 낮은 수준의 기본 도구를 선호하기 시작한 업계 전반의 변화에서 비롯되었습니다. 견고하지만 모델의 다양한 환경 적응 능력을 없애는 하드 코딩된 전용 도구 대신, 런타임에 오류를 수정하고 고품질 코드를 생성하는 에이전트 고유의 역량을 활용하는 도구입니다.
많은 개발자의 도구 상자에서 Claude Code가 주요 선택지로 자리 잡은 성공 사례와, 터미널 기반 에이전트로 향하는 업계 전반의 흐름을 생각해 보십시오. Claude Code의 가장 큰 장점은 모델 자체가 아니라 더 낮은 수준의 하네스입니다. 모델에 더 적고 모듈화된 저수준 도구, 즉 터미널을 제공하면 도구 호출 성능이 향상됩니다. 주된 이유는 에이전트가 컨텍스트 윈도우를 어지럽히는 범용 도구를 억지로 사용하는 대신 당면한 작업을 추론하고 맞춤형 스크립트를 작성할 수 있기 때문입니다.
브라우저 자동화에서는 모든 것을 사전 제작된 고정 작업 집합에 대응시키는 대신, 모델이 실시간 페이지 상태를 직접 점검하고 프레임을 탐색하며 현재 인터페이스에 맞는 상호작용 코드를 구성할 수 있다는 의미입니다.
모델은 선택기보다는 런타임 작성자에 가깝게 동작합니다. 현재 상태를 점검하고 인터페이스를 추론한 뒤 해당 상황에 맞는 상호작용 로직을 합성합니다. 여러 단계의 순서를 구성하고, 이례적인 절차에 적응하며, 계속 진행하기 전에 결과를 검증할 수 있습니다. 작업이 실패하면 모델은 근본 원인이 된 오류를 확인하고 스스로 수정합니다. 이는 더 강력하고 더 위험하지만, 문제의 실제 모습에 훨씬 가깝습니다.
중요한 점은 추상화 계층을 제거한다고 해서 시스템의 규율이 약해지는 것은 아니라는 것입니다. 규율이 적용되는 위치가 바뀔 뿐입니다.
기존에 래퍼 설계와 예외 처리에 있던 역할은 세 곳으로 옮겨갑니다. 운영 교육의 한 형태가 되는 프롬프트, 이동 범위와 민감한 작업 및 재시도 동작 같은 경계를 적용하는 런타임, 작업의 성공 여부뿐 아니라 중간 단계가 올바랐는지도 평가하는 평가 계층입니다. 취약한 추상화는 줄이고, 주변 시스템은 강화합니다.
이러한 전환의 결과로 전체 시스템의 역량은 향상되는 동시에 제품 코드는 오히려 더 단순해지는 경우가 많습니다. 상호작용 패턴을 재사용 가능한 래퍼로 구현하는 대신, 에이전트가 런타임에 동작을 합성합니다. 전문화된 도구와 예외 처리 로직을 계속 늘리는 대신, 강력한 기본 요소 몇 가지와 제약된 실행 환경을 유지합니다.
이로 인해 시스템의 일반화 방식도 달라집니다. 래퍼 기반 에이전트는 이미 구축된 래퍼와 유사한 작업을 잘 일반화합니다. 제약된 런타임 에이전트는 겉으로 드러나는 인터페이스가 달라도 실행 기반이 같은 작업을 일반화합니다.
예를 들어 검색 양식, 예약 절차, 설정 페이지는 UI 수준에서 서로 완전히 다르게 보일 수 있습니다. 하지만 그 이면에는 상태 읽기, 이벤트 트리거, 결과 검증, 비동기 업데이트 처리라는 공통 패턴이 있습니다. 이 수준에서 작동하는 시스템은 여러 작업에 더 자연스럽게 적용됩니다.
재사용 가능한 구성 요소는 작업 목록이 아닙니다. 상태를 점검하고 안전하게 행동하며 결과를 검증하는 모델의 능력입니다.
이 작업에서 얻은 가장 분명한 교훈은 모델에 더 많은 보조 함수를 제공한다고 신뢰성이 확보되는 것은 아니라는 점입니다. 오히려 더 적지만 강력한 기본 요소를 제공하고 이를 적절히 제약할 때 신뢰성이 높아지는 경우가 많습니다. 과도한 지원은 작업 수행 방식에 관한 가정을 코드에 고정합니다. 제약 조건은 안전한 작동 범위를 정하고 모델이 상황에 더 적합한 해법을 찾도록 합니다.
더 강력한 실행 인터페이스에는 더 정교한 안전 모델도 필요합니다. 에이전트가 사전 정의된 소수의 작업에만 국한되지 않는 순간, 사실상 실제 소프트웨어를 직접 조작하게 됩니다. 그러면 위험 프로필도 즉시 달라집니다.
설계 시 고려해야 할 사항은 네 가지입니다.
데이터 노출. 에이전트가 실제 인터페이스와 상호작용하면 민감한 정보를 접하는 경우가 많습니다. 따라서 마스킹과 접근 제어에 엄격한 원칙을 적용해야 합니다. 데이터는 실행에 필요할 때만 공개해야 하며, 관측 가능성을 위한 로그와 추적 정보가 시스템에서 가장 민감한 부분이 되지 않도록 신중하게 취급해야 합니다.
실행 범위. 강력한 에이전트가 임의로 작동할 수 있어서는 안 됩니다. 실제로는 이동 가능한 위치, 접근 가능한 도메인, 상호작용이 허용된 시스템을 제한해야 합니다. 이러한 제약은 프롬프트상의 규칙으로 남겨 두지 말고 런타임 수준에서 적용해야 합니다.
환경 신뢰성. 최신 인터페이스에는 오해를 유도하거나 적극적으로 공격을 시도하는 지침, 콘텐츠, 절차가 포함될 수 있습니다. 페이지 콘텐츠를 통한 프롬프트 인젝션은 실제 공격 경로입니다. 에이전트가 의도치 않은 지침을 따르지 않도록 시스템에 명확한 지침 우선순위와 검증 절차, 종료 조건이 필요합니다.
자율성의 스펙트럼. 모든 행동을 완전히 자율화해서는 안 됩니다. 많은 프로덕션 환경에서는 자율성을 스펙트럼으로 다루는 것이 중요합니다. 시스템이 탐색과 실행에서는 높은 에이전트성을 발휘하되, 특정 범주의 행동에는 승인을 요구할 수 있습니다.
기본 원칙은 간단합니다. 모델에 더 큰 권한을 부여하려면 주변 시스템도 그만큼 강화해야 합니다. 정책 없는 자율성은 프로덕션에 적용할 준비가 되지 않은 것입니다.
우리는 “어떤 브라우저 작업을 제공해야 하는가?”라는 질문을 멈췄습니다.
대신 “모델에 완전한 작업 공간을 제공하려면 무엇을 해야 하며, 그 주변에 안전을 보장할 런타임 정책을 어떻게 구축해야 하는가?”라고 묻기 시작했습니다.
이러한 관점의 전환은 중요하게 여기는 요소를 바꿉니다. 작업 분류 체계와 래퍼의 완전성은 덜 중요해집니다. 런타임 정책, 관측 가능성, 단계별 평가는 더 중요해집니다. 모델의 역량과 시스템 설계는 서로를 대신할 수 없습니다. 모델이 발전할수록 시스템의 역할은 줄어드는 것이 아니라 더 중요해집니다.
데모에서 작동하는 브라우저 에이전트가 성공하는 이유는 작업 범위가 좁고 환경이 협조적이기 때문인 경우가 많습니다. 프로덕션 시스템에는 제약된 실행, 계측된 동작, 올바른 결과와 우연히 얻은 결과를 구별할 수 있는 평가가 필요합니다.
래퍼 설계는 줄이고, 시스템 엔지니어링은 늘려야 합니다.
브라우저 에이전트에 초점을 맞췄지만, 이는 컴퓨터 사용을 시스템 분야로 바라보는 더 폭넓은 관점으로 이어집니다.