# AI의 Computer Use 기능은 구조화 API보다 45배 더 비싸다 > Clean Markdown view of GeekNews topic #29227. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=29227](https://news.hada.io/topic?id=29227) - GeekNews Markdown: [https://news.hada.io/topic/29227.md](https://news.hada.io/topic/29227.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-05-06T22:36:23+09:00 - Updated: 2026-05-06T22:36:23+09:00 - Original source: [reflex.dev](https://reflex.dev/blog/computer-use-is-45x-more-expensive-than-structured-apis/) - Points: 1 - Comments: 1 ## Topic Body - 같은 관리자 패널 작업에서 **비전 에이전트**는 스크린샷과 클릭으로 UI를 조작했고, **API 에이전트**는 같은 애플리케이션 핸들러를 구조화 응답으로 호출해 인터페이스만 비용 차이의 변수로 둠 - 기본 프롬프트에서 **API 에이전트**는 8번의 호출로 작업을 끝냈지만, 비전 에이전트는 보이는 영역 아래에 있던 대기 중 리뷰 3개를 놓쳐 4개 중 1개만 승인함 - 14단계 **UI walkthrough**를 추가하자 비전 에이전트도 완료했지만, 실행에 약 14분과 약 50만 입력 토큰이 들었고 이런 구체적 안내 자체가 별도 엔지니어링 비용이 됨 - 전체 결과에서 Sonnet 기준 **비전 경로**는 평균 53단계, 1003초, 550,976 입력 토큰을 썼고, API 경로는 8호출, 19.7초, 12,151 입력 토큰으로 끝나 비용과 시간 변동성도 훨씬 작았음 - 비용 격차는 모델 성능보다 **인터페이스 구조**에서 나왔으며, Reflex 0.9처럼 이벤트 핸들러에서 HTTP 엔드포인트를 자동 생성하면 직접 만드는 내부 도구에서는 구조화 API 경로의 비용 계산이 유리해짐 --- ### 벤치마크 목적과 실험 구성 - **비전 에이전트**와 **구조화 API** 방식으로 같은 관리자 패널을 조작하게 해 브라우저 사용·컴퓨터 사용 방식의 비용을 측정함 - API를 제공하지 않는 웹앱을 AI 에이전트가 조작할 때 비전 에이전트가 기본 선택지가 되기 쉬움 - 팀마다 20개 이상의 내부 도구가 있는 상황에서 앱마다 MCP나 REST 표면을 작성하는 일은 별도 엔지니어링 프로젝트가 되므로, 많은 팀이 비전 에이전트를 선택함 - 테스트 앱은 고객, 주문, 리뷰를 관리하는 관리자 패널이며, [react-admin Posters Galore demo](https://marmelab.com/react-admin-demo/)를 모델로 삼음 - 두 에이전트는 같은 실행 중인 앱, 같은 Claude Sonnet, 같은 고정 데이터셋, 같은 작업을 사용했고, **인터페이스만 변수**로 둠 - 작업은 “Smith”라는 이름의 고객 중 주문이 가장 많은 고객을 찾고, 그 고객의 가장 최근 대기 중 주문을 찾은 뒤, 대기 중 리뷰를 모두 승인하고 주문을 배송 완료로 표시하는 것임 - 이 작업은 세 리소스를 건드리고, 필터링·페이지네이션·엔티티 간 조회·읽기와 쓰기를 모두 포함해 일반적인 내부 도구 업무 형태와 비슷함 ### 두 실행 경로 - ## 경로 A: Vision agent - Claude Sonnet이 **browser-use 0.12**를 비전 모드로 사용해 UI를 스크린샷과 클릭으로 조작함 - ## 경로 B: API agent - Claude Sonnet이 도구 사용 방식으로 앱의 HTTP 엔드포인트를 직접 호출함 - 각 도구는 앱 State의 하나 이상의 이벤트 핸들러에 매핑되며, 버튼 클릭이 호출하는 것과 같은 함수가 사용됨 - 에이전트는 렌더링된 페이지 대신 **구조화된 응답**을 받음 ### 비전 에이전트가 기본 프롬프트로 실패한 이유 - 두 에이전트에 같은 여섯 문장 작업을 주고 실행함 - **API 에이전트**는 8번의 호출로 작업을 완료함 - 대기 상태로 필터링한 고객 리뷰를 나열함 - 각 리뷰를 승인함 - 주문을 배송 완료로 표시함 - 두 에이전트 모두 같은 애플리케이션 로직을 호출하지만, API 에이전트는 렌더링된 페이지를 보는 대신 구조화된 응답을 직접 읽음 - **비전 에이전트**는 같은 프롬프트에서 대기 중 리뷰 4개 중 1개만 찾아 승인하고 다음 단계로 넘어감 - 남은 리뷰 3개는 리뷰 페이지의 보이는 영역 아래에 있었고, 에이전트에는 스크롤해야 한다는 신호가 없었음 - 이 실패는 모델의 추론 문제가 아니라, 렌더링된 페이지가 전체를 보여주지 않는다는 신호를 주지 못한 데서 생김 - API 에이전트는 UI가 호출하는 것과 같은 핸들러를 호출하지만, 응답에는 현재 렌더링된 행만이 아니라 핸들러가 반환한 전체 결과 집합이 포함됨 - API 에이전트는 픽셀에서 페이지네이션 컨트롤을 해석하지 않고, “50개씩 표시되는 4페이지 중 1페이지” 같은 정보를 직접 읽음 ### 14단계 UI 안내를 추가했을 때의 결과 - 공정한 비교를 위해 비전 프롬프트를 명시적인 **UI walkthrough**로 다시 작성함 - 사이드바 항목, 탭, 폼 필드 등 에이전트가 각 단계에서 상호작용해야 할 UI 요소를 이름으로 지정함 - 기존에 에이전트가 스스로 찾지 못했던 탐색 과정을 14개의 번호 매긴 지시로 작성함 - 이 안내를 제공하자 비전 에이전트는 작업을 완료함 - 다만 실행에는 **14분**이 걸렸고, 약 **50만 입력 토큰**을 소비함 - 각 번호 지시는 토큰 수에는 드러나지 않지만 실제 엔지니어링 비용을 뜻함 - 내부 도구에 비전 에이전트를 배포하려면 이 수준의 구체적 프롬프트를 작성하거나, 에이전트가 조용히 작업을 놓칠 가능성을 받아들여야 함 ### 실행 방식과 변동성 - API 경로는 5회, 비전 경로는 3회 실행함 - 비전 경로는 한 번 실행하는 데 14~22분이 걸리고 40만~75만 토큰을 소비해 3회로 제한함 - 비전 경로는 실행별 **분산**이 컸음 - 3회 실행에서 벽시계 시간은 749초부터 1257초까지 벌어짐 - 입력 토큰은 40만 7천부터 75만 1천까지 벌어짐 - 가장 짧은 실행은 43사이클, 가장 긴 실행은 68사이클이 걸림 - 스크린샷-추론-클릭 반복에는 비결정성이 충분히 있어, 단일 실행만으로는 대표적인 비용을 추정하기 어려움 - API 경로에는 이런 변동성이 없었음 - Sonnet은 모든 5회 실행에서 동일하게 8번의 도구 호출을 사용함 - 입력 토큰 수는 전체 5회 실행에서 ±27 범위로만 변함 - 구조화된 응답이 에이전트에 이탈할 이유를 주지 않아 같은 순서로 같은 핸들러를 호출함 ### 전체 결과 | 지표 | Vision agent (Sonnet) | API (Sonnet) | API (Haiku) | | --- | --- | --- | --- | | 단계 / 호출 | 53 ± 13 | 8 ± 0 | 8 ± 0 | | 벽시계 시간 | 1003초 ± 254초, 약 17분 | 19.7초 ± 2.8초 | 7.7초 ± 0.5초 | | 입력 토큰 | 550,976 ± 178,849 | 12,151 ± 27 | 9,478 ± 809 | | 출력 토큰 | 37,962 ± 10,850 | 934 ± 41 | 819 ± 52 | - 숫자는 평균 ± 표본 표준편차(n−1)이며, API 경로는 n=5, 비전 경로는 n=3임 - 전체 실행 세부 정보는 저장소에서 확인 가능함 - **Haiku**는 비전 경로를 완료하지 못함 - 실패는 browser-use 0.12의 구조화 출력 스키마에 한정되며, Haiku가 비전 모드와 텍스트 전용 모드 모두에서 이를 안정적으로 생성하지 못함 - API 경로에서 Haiku는 8초 미만, 1만 입력 토큰 미만으로 완료했으며, 테스트한 구성 중 가장 저렴했음 ### 구조적 비용 격차 - 비용 차이는 아키텍처에서 직접 나옴 - 보아야 행동할 수 있는 에이전트는 모델이 좋아져도 **보는 비용**을 항상 지불해야 함 - 더 나은 비전 모델은 스크린샷당 오류율을 낮출 수 있지만, 관련 데이터에 도달하기 위해 필요한 스크린샷 수를 줄이지는 않음 - 각 렌더링은 스크린샷이고, 스크린샷은 수천 입력 토큰이 됨 - 두 에이전트는 같은 애플리케이션 로직을 지나감 - 둘 다 UI와 같은 방식으로 필터링, 페이지네이션, 업데이트를 수행함 - 차이는 각 단계에서 무엇을 읽는지에 있음 - 비전 에이전트는 픽셀을 읽고, 모든 중간 상태를 렌더링해 해석해야 함 - API 에이전트는 같은 핸들러에서 나온 구조화 응답을 읽으며, 그 응답에는 UI가 표시하려던 데이터가 이미 들어 있음 - 더 나은 모델은 단계당 비용을 줄일 수 있지만, **단계 수**는 인터페이스가 결정하므로 줄어들지 않음 ### API 엔지니어링 비용이 낮아질 때 바뀌는 판단 - 벤치마크는 **Reflex 0.9** 덕분에 저렴하게 실행됨 - Reflex 0.9에는 Reflex 애플리케이션의 이벤트 핸들러에서 HTTP 엔드포인트를 자동 생성하는 플러그인이 포함됨 - 구조적 논지는 Reflex에 의존하지 않지만, Reflex가 API 경로를 별도 코드베이스 없이 실행 가능하게 만듦 - API 표면의 엔지니어링 비용이 0에 가까워질 때 무엇이 가능해지는지가 핵심임 - 비전 에이전트는 여전히 직접 제어하지 않는 애플리케이션에 적합함 - 서드파티 SaaS 제품 - 레거시 시스템 - 수정할 수 없는 애플리케이션 - 직접 만드는 내부 도구에서는 비용 계산이 반대로 기울어짐 ### 실험 범위와 주의점 - 비전 결과는 **browser-use 0.12** 비전 모드에 한정되며, 다른 비전 에이전트는 다르게 동작할 수 있음 - 경로 B 러너는 자동 생성 엔드포인트를 약 30줄 규모의 작은 REST 도구 표면으로 가공함 - 에이전트는 이를 `list_customers`, `update_order` 같은 도구로 봄 - 데이터셋은 고정되어 있고 작음 - 고객 900명 - 주문 600개 - 리뷰 324개 - 프로덕션 규모 데이터에서의 동작은 측정되지 않음 - 비전 에이전트는 LangChain의 `ChatAnthropic`을 통해 실행됨 - API 에이전트는 Anthropic SDK를 직접 사용해 실행됨 - 보고된 토큰 수는 캐시되지 않은 입력 토큰임 ### 재현 자료 - 저장소에는 시드 데이터 생성, 패치된 react-admin 데모, 두 에이전트 스크립트, 원시 결과가 포함됨 ## Comments ### Comment 56957 - Author: neo - Created: 2026-05-06T22:36:24+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=48024859) - 에이전트가 웹사이트를 탐색하기 **비싸게 만드는 방법**이 여기 숨어 있음: 마우스가 움직일 때 화면 요소를 옮기고, 자연스러운 마우스 이동을 강제해야 UI가 동작하게 만들고, 방문할 때마다 JS에서 버튼 라벨을 무작위 이름으로 바꾸고, 숨겨진 추가 작업을 확인하려면 화면 맨 아래까지 스크롤하게 만들면 됨 잠깐, 이거 흔한 **기업용 SaaS 앱** 같음 - 예전엔 믿지 않던 사람들이 AI 때문에 갑자기 좋은 소프트웨어 엔지니어링 관행, 특히 **명세서 작성**부터 열심히 하게 되는 게 이상함 인간을 위해서는 이런 걸 할 의지가 없었는데 AI가 필요로 하니 다들 달려드는 모습이 흥미롭고도 좀 우울함. 결국 추상적인 미래의 누군가보다 우리 개인에게 이득이 된다고 느껴서 AI를 위해서만 하는 듯함 - 핵심은 인간이 하고 싶어 하는 것으로 만드는 것임. [0]처럼 상호작용 요소가 움직이고, 맥락에 따라 환경과 상호작용하게 만들 수 있음 [0] [https://www.cs.unm.edu/~dlchao/papers/p152-chao.pdf]() - 결국 **ASP WebForms**가 우리가 줄곧 필요로 하던 기술이었나 봄 - 예전에 데스크톱 앱 하나가 모든 그리드 컨트롤 내용을 **Windows 접근성 API**에서 일부러 숨기고, 접근성 API로 체크박스나 라디오 버튼을 선택해도 반영되지 않게 막고, 데이터 내보내기 기능은 모두 CAPTCHA로 보호한 프로젝트가 있었음 생성형 AI가 있던 시절도 아니었지만, 앱을 구동하고 데이터를 내보내기 위해 OCR, 시뮬레이션된 사용자 입력, 인쇄 캡처를 조합해야 했음. 개발자들이 화면 캡처를 막는 Windows DRM API나 PostScript 파일에서 텍스트를 최소한의 서식과 함께 쉽게 복구할 수 있다는 사실을 알았다면 뭘 했을지 모르겠음 아이러니하게도 이걸 대체하기 전 프로세스는 저렴한 해외 인력에게 시스템의 모든 데이터에 읽기 전용 원격 접근권을 주는 방식이었고, 이는 신뢰할 수 있는 벤더의 로컬 도구로 승인된 직원이 네트워크 접근 없이 업무를 자동화하는 것보다 훨씬 심각한 보안 위험이었음 - 이 정확한 문제를 해결하는 걸 만들고 있음[1] 랜딩 페이지에는 아직 내세우지 않았지만, 본질적으로 에이전트에게 앱 표면을 탐색할 작은 도구 세트와, 특히 접근성과 관련된 일반적인 **macOS 기능 API**를 제공함 에이전트가 앱을 탐색한 뒤 반복 가능한 워크플로를 작성하고, 이후 CLI에서 `invoke chrome pinTab`처럼 실행할 수 있음 접근성을 쓰는 이유는 결국 앱을 위한 좋은 DOM이기 때문임. 모든 앱이 완벽히 구현하진 않지만, 충분히 많은 앱이 구현해서 매우 유용함 [1] [https://getinvoke.com]() - 현재 랜딩 페이지는 크리에이터 대상이라 아직 이 사용 사례는 다루지 않음 - 에이전트 덕분에 좋은 **접근성(a11y)** 이 확보된다면 받아들일 수 있음. 투덜대긴 하겠지만 그래도 받아들임 - macOS에서 이 분야에 관심 있다면 시스템 제공 **Accessibility Inspector.app**을 열어 앱과 브라우저를 직접 만져보는 걸 강력히 추천함 초록색 셀이 LLM이 화면의 특정 부분만 읽거나 OCR하면 되도록 어떻게 안내할 수 있는지, 이미 접근성 엔진에 기본 제공되는 텍스트가 얼마나 많은지, 그리고 이게 MCP뿐 아니라 워크플로의 접근성 계층을 크롤링하는 스크립트를 직접 만들고 실행하는 코드 생성기로 이어질 수 있음을 볼 수 있음 이건 매우 비옥한 영역이라고 봄. 대형 연구소들은 여러 플랫폼과 임의 워크플로에서 동작하는 접근을 써야 하고, 전체 화면 비전은 최저 공통분모임. 플랫폼별 접근 방식은 정말 흥미로운 열린 공간임 - 모두가 같은 컴퓨터 사용 작업을 반복하며 토큰을 낭비하는 대신, **워크플로 공유** 방식을 만드는 좋은 해법임 다만 비밀번호 같은 사용자 정보를 추출하는 워크플로가 공유되지 않도록 반드시 보장해야 할 듯함 - 흥미로움. 비슷하게 시작한 게 있는데, 완성도는 훨씬 낮고 꽤 다르지만 마찬가지로 **접근성 UI 요소**를 사용함 큰 문제는 너무 많은 앱이 이런 요소 노출을 형편없이 한다는 것임. 내 접근은 UIAccess 또는 비전 모델의 1회 패스를 이용해 UI 템플릿을 만드는 방식이었음: [https://github.com/willwade/app-automate?tab=readme-ov-file#...]() 이에 대한 [reddit]([https://www.reddit.com/r/openclaw/comments/1s1dzxq/comment/o...]()) 반론은 실제 경험이 반대에 가깝다는 것임. UIA는 문서상 균일해 보이지만 WPF, WinForms, Win32가 모두 다른 컨트롤 패턴을 노출해 결국 툴킷별 핸들러를 쓰게 됨. Qt는 QAccessible이 컴파일되고 접근성 플러그인이 런타임에 로드되어야 뭔가 노출하는데, 배포 바이너리에서는 거의 그런 일이 없음. Electron은 Windows에서도 macOS만큼 불투명한데, 결국 같은 Chromium이 캔버스에 그리기 때문임. 진짜 구분은 운영체제 대 운영체제가 아니라 네이티브 툴킷 대 그 외 전부임 - 앱마다 MCP나 REST 표면을 작성하는 게 별도 엔지니어링 프로젝트라는 말은, **백엔드가 프런트엔드와 충분히 분리**되어 있고 서버 측 작업이 신중하고 일반적으로 설계되어 있었다면 꼭 그렇진 않음 - 비전 에이전트에게 UI를 “지도화”하게 하고, 다른 에이전트에게 더 API처럼 보이는 인터페이스 집합으로 노출하게 할 수 있을지 궁금함 지금 비전 에이전트는 “다음 페이지”가 더 많은 결과를 보여준다는 것과, 애초에 더 많은 결과를 가져와야 한다는 것을 둘 다 알아야 하는 것으로 이해함 한 에이전트가 테스트 환경 같은 곳에서 UI만 탐색해 여러 UI 요소와 동작에 대한 어느 정도 구조화된 설명을 만들고, 다른 에이전트가 그 설명을 받는다면, UI 탐색과 과제 수행을 동시에 하는 에이전트보다 더 잘할지 궁금함 예를 들면 “모든 리뷰 가져오기”는 각 페이지로 가서 각 리뷰 요약마다 “전체 리뷰 보기”를 클릭해야 한다는 식으로, “각 페이지로 이동”은 리뷰 탭의 기본값인 1페이지에서 시작해 “다음” 버튼이 없어질 때까지 누른다는 식으로 정의할 수 있음 그러면 두 번째 에이전트는 이미 그 기술을 갖고 있으니 탐색 방법에 대한 사고를 줄일 수 있고, 첫 번째 에이전트는 테스트 환경에서 실수 걱정 없이 한 번만 UI를 탐색하면 됨. 글을 완전히 오해했을 수도 있지만 그래도 흥미로움 - 같은 생각을 먼저 했음. 요즘 웹 개발은 코드 생성에 크게 의존한 뒤 난독화와 압축을 얹고, 그 위에서 클라이언트 측 JavaScript가 다시 모든 것을 재구성함 결국 복잡한 **HTML/CSS/JavaScript**를 헤쳐 나가야 함. 좋든 나쁘든 웹 앱 하나가 5~10MiB인 것도 드물지 않음 브라우저 엔진이 하는 일을 사실상 거꾸로 하듯 “아래에서 위로” 접근하기보다, 인간처럼 시각 표현을 보고 “위에서 아래로” 접근하는 편이 더 쉬워 보임 - 맞는 듯함. 에이전트가 우리가 하듯 **웹사이트 작동 방식**을 학습하게 만들 수 있고, 그 모델을 단순한 API로 노출하면 됨 탐색에는 여전히 비전 작업이 조금 남겠지만, 그건 생각이 필요 없는 단순 비전 작업이 될 것임 - 비전 에이전트에게 “지도화”를 요청하는 건 어렵다고 봄. 대부분의 비전 모델은 **이미지→텍스트**를 할 때 한 번에 이미지의 일부 영역에 집중함 **이미지→이미지**는 전체 이미지를 사용함 - 전제가 잘 이해되지 않음. 내부 앱이라면 왜 컴퓨터 사용을 꺼내 들고, 에이전트가 CLI나 MCP를 만들게 하지 않는지 모르겠음 당연히 컴퓨터 사용은 더 나쁨. 그건 최후의 수단임. 내가 소유한 DB에 있는 상태를 다룰 때는 쓰면 안 됨 오히려 **50배밖에** 나쁘지 않다는 게 인상적임 - 전적으로 동의함. 최근 AI 시각 도구를 만들면서 두 접근을 모두 실험했는데, 범용 “에이전트식” 브라우저 사용의 **지연 시간과 비용**은 현재 실시간 소비자 앱에는 치명적임 구조화된 API, 심지어 엄격한 JSON 스키마를 쓰는 LLM 호출 체인만으로도 40배 저렴할 뿐 아니라, 실제로 안정적인 제품을 올릴 만큼 결정적임. 컴퓨터 사용은 멋진 데모지만, 서버 비용을 내주는 건 구조화된 API임 - “에이전트식 엔지니어링”은 토큰 제공업체 매출을 늘리기 위한 **유행**에 불과했음 LLM이 어떤 일에 좋다고 생각하면, 그 목적에 맞게 Openrouter 위에 잘 정의되고 매우 결정적인 미들웨어를 만듦 - 구조화된 API에는 실제 사고가 필요한데, 요즘은 **생각하는 것**이 좋게 여겨지지 않음 - 몇 달 전 `kubectl`에서 영감을 받아 GUI 앱을 제어하는 **desktopctl CLI**를 만들었음 Mac에서 OCR과 Accessibility API를 조합해 UI를 Markdown으로 표현하고, 마우스와 키보드 동작을 노출함 핵심 아이디어는 “빠른” 인식 루프는 완전히 로컬에서 UI 토큰화와 변경 감지에 GPU 최적화하고, “느린” 제어 루프는 LLM 왕복이 필요하며 CLI 출력에는 토큰 효율적인 Markdown 인터페이스를 쓰는 것임 컨트롤에는 비교적 안정적인 식별자를 쓰므로, 에이전트가 `desktopctl pointer click --id btn_save` 같은 일반 동작을 스크립트화할 수 있고 UI 토큰화 루프가 필요 없음 [https://github.com/yaroshevych/desktopctl/tree/main]() - API와 비교하면 인간용 인터페이스는 느리고 지저분하지만, 그 뒤에도 꽤 많은 과학이 있다는 걸 배웠음 좋은 앱은 정보를 잘 드러내고 클릭, 타이핑 등에 최적화되어 있음 최고의 GUI는 **근육 기억**을 잘 활용하므로 CLI로 스크립트화하기에 완벽한 후보가 됨. 예를 들어 “Notes 앱 열기, Cmd+F 누르기, 검색어 입력, 결과 목록 읽기” 같은 단순 시퀀스는 AI 에이전트가 호출하는 Bash 명령 하나가 될 수 있음 - “컴퓨터 사용”이라는 개념 전체가 늘 회의적임. 누군가를 고용해 집에 들여보내면서 침대에서 자고, 화장실을 쓰고, 냉장고 음식을 먹고, TV를 보고, 금고 비밀번호도 여기 있다고 말하는 것과 비슷함 그런데 고용한 그 누군가가 **원숭이**인 셈임 - 내가 미친 건가 싶음. 한 소프트웨어가 다른 소프트웨어에 질의하고 명령하는 방식을 만들 능력이 없어서, AI가 마우스를 어슬렁거리며 이것저것 클릭하게 하는 게 정말 맞는지 놀라움 - 공평하게 보자면, 내가 직접 하기 싫은 **원숭이 같은 작업**을 그 원숭이가 해주길 바라는 것임 - 현재 Claude Code나 다른 AI 에이전트를 막는 웹사이트들은 지는 싸움을 하고 있음 컴퓨터 사용은 초기 단계이고, 대중화를 막는 건 필요한 토큰 수로 보임. 에이전트가 맞는 명령을 찾기 전까지 CLI 명령 10개를 헛시도해도 우리는 거의 신경 쓰지 않음 하지만 브라우저 사용이나 컴퓨터 사용 같은 시각 에이전트는 결국 맞는 곳에 도달하더라도, 버튼 하나 클릭하는 데 20분을 기다릴 인내심이 없음. 토큰이 더 싸지고 빨라지면, UI 인터페이스를 CLI만큼 자연스럽게 쓰는 모델이 나올 가능성이 큼 - 토큰이 더 싸진다고 보긴 어려움. 벤처 자금으로 보조된 토큰은 사용자 기반을 만들기 위한 것이었고, 결국 성장에서 수익성으로 전환하면 **토큰 가격**은 오를 것 같음 - 그리고 **치명적 삼중 조건**도 있음. 지금으로선 모든 에이전트가 그렇긴 하지만, 모든 AI 제공업체가 브라우저에서 AI에 개인정보 접근을 허용하는 것에 대해 강한 경고를 붙이고 있음 - 실제 LLM 제공업체는 아무도 막을 수 없음. 콘텐츠를 스캔하려고 위장 요청을 쓰고, 때로는 **가정용 프록시**까지 사용함 - 100% 효과적일 필요는 없음. 계정이 정지될까 봐 시도할 생각을 접을 만큼 겁만 주면 됨 - 대중화를 막는 건 토큰 수보다 **막대한 비용**, 늘어나는 전력 낭비, 사용 가능한 물 낭비에 가까움