에이전트가 웹사이트를 탐색하기 비싸게 만드는 방법이 여기 숨어 있음: 마우스가 움직일 때 화면 요소를 옮기고, 자연스러운 마우스 이동을 강제해야 UI가 동작하게 만들고, 방문할 때마다 JS에서 버튼 라벨을 무작위 이름으로 바꾸고, 숨겨진 추가 작업을 확인하려면 화면 맨 아래까지 스크롤하게 만들면 됨
잠깐, 이거 흔한 기업용 SaaS 앱 같음
예전엔 믿지 않던 사람들이 AI 때문에 갑자기 좋은 소프트웨어 엔지니어링 관행, 특히 명세서 작성부터 열심히 하게 되는 게 이상함
인간을 위해서는 이런 걸 할 의지가 없었는데 AI가 필요로 하니 다들 달려드는 모습이 흥미롭고도 좀 우울함. 결국 추상적인 미래의 누군가보다 우리 개인에게 이득이 된다고 느껴서 AI를 위해서만 하는 듯함
예전에 데스크톱 앱 하나가 모든 그리드 컨트롤 내용을 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 반론은 실제 경험이 반대에 가깝다는 것임. 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% 효과적일 필요는 없음. 계정이 정지될까 봐 시도할 생각을 접을 만큼 겁만 주면 됨
대중화를 막는 건 토큰 수보다 막대한 비용, 늘어나는 전력 낭비, 사용 가능한 물 낭비에 가까움
Hacker News 의견들
에이전트가 웹사이트를 탐색하기 비싸게 만드는 방법이 여기 숨어 있음: 마우스가 움직일 때 화면 요소를 옮기고, 자연스러운 마우스 이동을 강제해야 UI가 동작하게 만들고, 방문할 때마다 JS에서 버튼 라벨을 무작위 이름으로 바꾸고, 숨겨진 추가 작업을 확인하려면 화면 맨 아래까지 스크롤하게 만들면 됨
잠깐, 이거 흔한 기업용 SaaS 앱 같음
인간을 위해서는 이런 걸 할 의지가 없었는데 AI가 필요로 하니 다들 달려드는 모습이 흥미롭고도 좀 우울함. 결국 추상적인 미래의 누군가보다 우리 개인에게 이득이 된다고 느껴서 AI를 위해서만 하는 듯함
[0] https://www.cs.unm.edu/~dlchao/papers/p152-chao.pdf
생성형 AI가 있던 시절도 아니었지만, 앱을 구동하고 데이터를 내보내기 위해 OCR, 시뮬레이션된 사용자 입력, 인쇄 캡처를 조합해야 했음. 개발자들이 화면 캡처를 막는 Windows DRM API나 PostScript 파일에서 텍스트를 최소한의 서식과 함께 쉽게 복구할 수 있다는 사실을 알았다면 뭘 했을지 모르겠음
아이러니하게도 이걸 대체하기 전 프로세스는 저렴한 해외 인력에게 시스템의 모든 데이터에 읽기 전용 원격 접근권을 주는 방식이었고, 이는 신뢰할 수 있는 벤더의 로컬 도구로 승인된 직원이 네트워크 접근 없이 업무를 자동화하는 것보다 훨씬 심각한 보안 위험이었음
이 정확한 문제를 해결하는 걸 만들고 있음[1]
랜딩 페이지에는 아직 내세우지 않았지만, 본질적으로 에이전트에게 앱 표면을 탐색할 작은 도구 세트와, 특히 접근성과 관련된 일반적인 macOS 기능 API를 제공함
에이전트가 앱을 탐색한 뒤 반복 가능한 워크플로를 작성하고, 이후 CLI에서
invoke chrome pinTab처럼 실행할 수 있음접근성을 쓰는 이유는 결국 앱을 위한 좋은 DOM이기 때문임. 모든 앱이 완벽히 구현하진 않지만, 충분히 많은 앱이 구현해서 매우 유용함
[1] https://getinvoke.com - 현재 랜딩 페이지는 크리에이터 대상이라 아직 이 사용 사례는 다루지 않음
초록색 셀이 LLM이 화면의 특정 부분만 읽거나 OCR하면 되도록 어떻게 안내할 수 있는지, 이미 접근성 엔진에 기본 제공되는 텍스트가 얼마나 많은지, 그리고 이게 MCP뿐 아니라 워크플로의 접근성 계층을 크롤링하는 스크립트를 직접 만들고 실행하는 코드 생성기로 이어질 수 있음을 볼 수 있음
이건 매우 비옥한 영역이라고 봄. 대형 연구소들은 여러 플랫폼과 임의 워크플로에서 동작하는 접근을 써야 하고, 전체 화면 비전은 최저 공통분모임. 플랫폼별 접근 방식은 정말 흥미로운 열린 공간임
다만 비밀번호 같은 사용자 정보를 추출하는 워크플로가 공유되지 않도록 반드시 보장해야 할 듯함
큰 문제는 너무 많은 앱이 이런 요소 노출을 형편없이 한다는 것임. 내 접근은 UIAccess 또는 비전 모델의 1회 패스를 이용해 UI 템플릿을 만드는 방식이었음: https://github.com/willwade/app-automate?tab=readme-ov-file#...
이에 대한 reddit 반론은 실제 경험이 반대에 가깝다는 것임. UIA는 문서상 균일해 보이지만 WPF, WinForms, Win32가 모두 다른 컨트롤 패턴을 노출해 결국 툴킷별 핸들러를 쓰게 됨. Qt는 QAccessible이 컴파일되고 접근성 플러그인이 런타임에 로드되어야 뭔가 노출하는데, 배포 바이너리에서는 거의 그런 일이 없음. Electron은 Windows에서도 macOS만큼 불투명한데, 결국 같은 Chromium이 캔버스에 그리기 때문임. 진짜 구분은 운영체제 대 운영체제가 아니라 네이티브 툴킷 대 그 외 전부임
앱마다 MCP나 REST 표면을 작성하는 게 별도 엔지니어링 프로젝트라는 말은, 백엔드가 프런트엔드와 충분히 분리되어 있고 서버 측 작업이 신중하고 일반적으로 설계되어 있었다면 꼭 그렇진 않음
비전 에이전트에게 UI를 “지도화”하게 하고, 다른 에이전트에게 더 API처럼 보이는 인터페이스 집합으로 노출하게 할 수 있을지 궁금함
지금 비전 에이전트는 “다음 페이지”가 더 많은 결과를 보여준다는 것과, 애초에 더 많은 결과를 가져와야 한다는 것을 둘 다 알아야 하는 것으로 이해함
한 에이전트가 테스트 환경 같은 곳에서 UI만 탐색해 여러 UI 요소와 동작에 대한 어느 정도 구조화된 설명을 만들고, 다른 에이전트가 그 설명을 받는다면, UI 탐색과 과제 수행을 동시에 하는 에이전트보다 더 잘할지 궁금함
예를 들면 “모든 리뷰 가져오기”는 각 페이지로 가서 각 리뷰 요약마다 “전체 리뷰 보기”를 클릭해야 한다는 식으로, “각 페이지로 이동”은 리뷰 탭의 기본값인 1페이지에서 시작해 “다음” 버튼이 없어질 때까지 누른다는 식으로 정의할 수 있음
그러면 두 번째 에이전트는 이미 그 기술을 갖고 있으니 탐색 방법에 대한 사고를 줄일 수 있고, 첫 번째 에이전트는 테스트 환경에서 실수 걱정 없이 한 번만 UI를 탐색하면 됨. 글을 완전히 오해했을 수도 있지만 그래도 흥미로움
결국 복잡한 HTML/CSS/JavaScript를 헤쳐 나가야 함. 좋든 나쁘든 웹 앱 하나가 5~10MiB인 것도 드물지 않음
브라우저 엔진이 하는 일을 사실상 거꾸로 하듯 “아래에서 위로” 접근하기보다, 인간처럼 시각 표현을 보고 “위에서 아래로” 접근하는 편이 더 쉬워 보임
탐색에는 여전히 비전 작업이 조금 남겠지만, 그건 생각이 필요 없는 단순 비전 작업이 될 것임
이미지→이미지는 전체 이미지를 사용함
전제가 잘 이해되지 않음. 내부 앱이라면 왜 컴퓨터 사용을 꺼내 들고, 에이전트가 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
좋은 앱은 정보를 잘 드러내고 클릭, 타이핑 등에 최적화되어 있음
최고의 GUI는 근육 기억을 잘 활용하므로 CLI로 스크립트화하기에 완벽한 후보가 됨. 예를 들어 “Notes 앱 열기, Cmd+F 누르기, 검색어 입력, 결과 목록 읽기” 같은 단순 시퀀스는 AI 에이전트가 호출하는 Bash 명령 하나가 될 수 있음
“컴퓨터 사용”이라는 개념 전체가 늘 회의적임. 누군가를 고용해 집에 들여보내면서 침대에서 자고, 화장실을 쓰고, 냉장고 음식을 먹고, TV를 보고, 금고 비밀번호도 여기 있다고 말하는 것과 비슷함
그런데 고용한 그 누군가가 원숭이인 셈임
현재 Claude Code나 다른 AI 에이전트를 막는 웹사이트들은 지는 싸움을 하고 있음
컴퓨터 사용은 초기 단계이고, 대중화를 막는 건 필요한 토큰 수로 보임. 에이전트가 맞는 명령을 찾기 전까지 CLI 명령 10개를 헛시도해도 우리는 거의 신경 쓰지 않음
하지만 브라우저 사용이나 컴퓨터 사용 같은 시각 에이전트는 결국 맞는 곳에 도달하더라도, 버튼 하나 클릭하는 데 20분을 기다릴 인내심이 없음. 토큰이 더 싸지고 빨라지면, UI 인터페이스를 CLI만큼 자연스럽게 쓰는 모델이 나올 가능성이 큼