--- title: "AI 에이전트, 화면 보고 클릭하게 하면 구조화 API보다 45배 비싸다" published: 2026-05-05T16:34:48.000Z canonical: https://jeff.news/article/2218 --- # AI 에이전트, 화면 보고 클릭하게 하면 구조화 API보다 45배 비싸다 Reflex가 같은 어드민 작업을 비전 에이전트와 구조화 API 에이전트로 돌려 비교했더니, 화면 기반 방식은 평균 17분과 55만 입력 토큰을 먹었다. 반면 API 방식은 Sonnet 기준 20초 안팎, Haiku 기준 8초 미만에 끝났고 호출 수도 매번 8번으로 고정됐다. ## 같은 작업, 다른 인터페이스 - Reflex 팀이 AI 에이전트에게 같은 어드민 패널 작업을 시켜놓고 비용을 비교함 - 테스트 앱은 고객, 주문, 리뷰를 관리하는 어드민 패널임 - react-admin의 Posters Galore 데모를 모델로 삼았고, 데이터셋은 고정됨 - 모델은 같은 Claude Sonnet을 썼고, 차이는 화면을 보느냐 API를 호출하느냐뿐임 - 작업은 꽤 현실적인 내부툴 시나리오였음 - 이름이 “Smith”인 고객 중 주문이 가장 많은 사람을 찾음 - 그 고객의 가장 최근 pending 주문을 찾음 - pending 리뷰를 전부 승인함 - 해당 주문을 delivered 상태로 바꿈 - 필터링, 페이지네이션, 엔티티 간 조회, 읽기와 쓰기가 다 들어간 일상적인 백오피스 작업임 ```mermaid sequenceDiagram participant 에이전트 participant 화면 participant 앱핸들러 participant 데이터 에이전트->>화면: 스크린샷 확인 화면->>에이전트: 렌더링된 일부 행만 노출 에이전트->>앱핸들러: 클릭과 입력으로 작업 요청 앱핸들러->>데이터: 조회와 업데이트 실행 데이터-->>앱핸들러: 전체 결과 반환 앱핸들러-->>화면: 현재 페이지 렌더링 ``` ## 비전 에이전트가 놓친 것 - 처음에는 양쪽 에이전트에게 똑같은 6문장짜리 지시만 줬음 - API 에이전트는 8번 호출로 작업을 끝냄 - pending 리뷰만 필터링해서 전부 승인하고, 주문 상태까지 delivered로 바꿈 - 같은 앱 로직을 호출하지만 결과를 구조화 데이터로 직접 읽었기 때문에 헷갈릴 여지가 적었음 - 비전 에이전트는 같은 프롬프트에서 pending 리뷰 4개 중 1개만 승인하고 넘어감 - 나머지 3개 리뷰는 리뷰 페이지의 visible fold 아래에 있었음 - 에이전트 입장에서는 화면에 안 보이는 데이터가 더 있다는 신호가 약했음 - 저자는 이걸 모델 문제가 아니라 인터페이스 문제로 봄 > [!IMPORTANT] > 핵심은 “똑똑한 모델이면 화면도 잘 보겠지”가 아님. 화면 기반 에이전트는 보려면 렌더링해야 하고, 렌더링할 때마다 스크린샷 토큰 비용을 계속 냄. - 공정 비교를 위해 비전 에이전트용 프롬프트를 14단계 UI 안내로 다시 작성함 - 사이드바 항목, 탭, 폼 필드, 이동 순서를 하나씩 찍어줌 - 그제야 비전 에이전트도 작업을 완료함 - 대신 실행 시간이 14분까지 늘었고 입력 토큰은 약 50만 개를 먹음 - 이 14단계 안내 자체가 비용이라는 지적이 꽤 뼈아픔 - 토큰 비용표에는 안 잡히지만, 누군가는 내부 도구마다 이런 워크스루 프롬프트를 써야 함 - 안 쓰면 조용히 일부 작업을 빼먹는 리스크를 감수해야 함 ## 숫자로 보면 차이가 너무 큼 - 비전 경로는 3번만 돌렸는데도 변동성이 컸음 - 각 실행이 14-22분 걸리고 40만-75만 입력 토큰을 써서 더 많이 돌리기 어려웠다고 함 - 평균 wall-clock time은 1003초, 표준편차는 254초였음 - 입력 토큰은 평균 550,976개, 표준편차 178,849개였음 - 단계 수는 평균 53회, 표준편차 13회였음 - API 경로는 거의 기계처럼 일정했음 - Sonnet은 5번 모두 8번 호출로 끝냄 - 입력 토큰 수는 전체 실행에서 ±27개 수준으로만 흔들림 - 평균 시간은 19.7초, 입력 토큰은 12,151개였음 - Haiku는 API 경로에서 더 싸고 빨랐음 - 평균 7.7초에 완료함 - 입력 토큰은 9,478개, 출력 토큰은 819개였음 - 다만 비전 경로에서는 browser-use 0.12의 구조화 출력 스키마를 안정적으로 만들지 못해 실패함 > [!IMPORTANT] > 원문 제목의 45배는 입력 토큰 기준으로 보면 바로 감이 옴. 비전 에이전트 평균 550,976개 대 API Sonnet 평균 12,151개라서, 같은 작업인데 인터페이스 때문에 비용이 폭발함. ## 왜 이런 차이가 나는가 - 비전 에이전트는 행동하려면 먼저 봐야 함 - 화면을 보고, 판단하고, 클릭하고, 다시 화면을 보는 루프를 반복함 - 각 스크린샷은 수천 입력 토큰으로 들어감 - 모델이 좋아져도 관련 데이터에 도달하기 위해 필요한 화면 전환 수 자체는 쉽게 줄지 않음 - API 에이전트는 UI가 호출하는 같은 핸들러를 직접 호출함 - 버튼 클릭이 결국 호출할 애플리케이션 State의 이벤트 핸들러에 연결됨 - 응답은 렌더링된 페이지가 아니라 구조화 데이터임 - “페이지 1/4, 페이지당 50개 결과” 같은 정보를 픽셀에서 추론하지 않고 바로 읽음 - 저자 주장은 내부 도구에서는 이제 계산이 바뀐다는 쪽임 - 비전 에이전트는 내가 통제하지 못하는 외부 SaaS, 오래된 시스템, 수정 불가능한 앱에 여전히 맞음 - 하지만 내가 만든 내부 도구라면 API 표면을 만드는 비용과 비전 에이전트 운영 비용을 다시 비교해야 함 - Reflex 0.9의 플러그인은 이벤트 핸들러에서 HTTP 엔드포인트를 자동 생성해, API 표면을 별도 프로젝트로 만드는 부담을 줄였다고 함 - 단, 벤치마크 해석에는 제한이 있음 - 비전 결과는 browser-use 0.12 비전 모드 기준임 - API 도구 표면은 약 30줄짜리 REST runner로 정리됨 - 데이터셋은 고객 900명, 주문 600건, 리뷰 324건으로 작고 고정돼 있음 - 토큰 수는 캐시되지 않은 입력 토큰 기준임 --- ## 기술 맥락 - 여기서 중요한 선택은 에이전트에게 화면을 보여줄지, 앱 내부 기능을 도구 호출로 열어줄지예요. 둘 다 같은 업무 자동화처럼 보이지만, 화면 방식은 사람이 보는 UI를 모델이 따라가게 만드는 거고 API 방식은 앱이 이미 알고 있는 구조화 상태를 바로 넘기는 거예요. - Reflex 팀이 API 방식을 실험할 수 있었던 이유는 이벤트 핸들러에서 HTTP 엔드포인트를 자동 생성했기 때문이에요. 보통 내부 도구 20개마다 MCP나 REST API를 따로 만드는 건 꽤 큰 일이거든요. 이 생성 비용이 낮아지면 비전 에이전트를 기본값으로 둘 이유가 약해져요. - 페이지네이션 사례가 핵심이에요. 화면에는 현재 보이는 행만 있고, 아래에 더 있는지 모델이 매번 추론해야 해요. 반면 구조화 응답에는 전체 결과 수나 페이지 정보가 들어갈 수 있으니, 에이전트가 빠뜨린 일을 만들 가능성이 줄어들어요. - 그래서 이 글은 “비전 에이전트가 별로다”라는 얘기보다는 “내가 소유한 시스템에서는 에이전트용 인터페이스를 설계하자”에 가까워요. 외부 SaaS처럼 수정할 수 없는 앱은 화면 자동화가 필요하지만, 내부 어드민은 핸들러와 상태를 도구로 노출하는 편이 비용과 신뢰성 면에서 더 낫다는 거예요. ## 핵심 포인트 - 비전 에이전트는 스크린샷을 보고 클릭하느라 평균 55만 입력 토큰을 사용함 - API 에이전트는 같은 애플리케이션 로직을 구조화 응답으로 받아 8번 호출로 작업을 끝냄 - 처음 프롬프트에서 비전 에이전트는 페이지 아래에 있는 리뷰 3개를 놓쳤고, 14단계짜리 UI 안내를 추가해야 성공함 - 저자는 내부 도구라면 비전 에이전트보다 자동 생성 API 표면을 붙이는 쪽이 비용상 유리하다고 봄 ## 인사이트 에이전트 자동화에서 진짜 비용은 모델 지능만이 아니라 인터페이스 형태에서 나온다는 얘기다. 내가 만든 내부 툴이면 픽셀을 읽게 할 게 아니라, UI가 이미 호출하는 핸들러를 에이전트용 구조화 API로 열어주는 쪽이 훨씬 현실적임.