AI 에이전트, 화면 보고 클릭하게 하면 구조화 API보다 45배 비싸다

같은 작업, 다른 인터페이스

• Reflex 팀이 AI 에이전트에게 같은 어드민 패널 작업을 시켜놓고 비용을 비교함

  • 테스트 앱은 고객, 주문, 리뷰를 관리하는 어드민 패널임
  • react-admin의 Posters Galore 데모를 모델로 삼았고, 데이터셋은 고정됨
  • 모델은 같은 Claude Sonnet을 썼고, 차이는 화면을 보느냐 API를 호출하느냐뿐임

• 작업은 꽤 현실적인 내부툴 시나리오였음

  • 이름이 “Smith”인 고객 중 주문이 가장 많은 사람을 찾음
  • 그 고객의 가장 최근 pending 주문을 찾음
  • pending 리뷰를 전부 승인함
  • 해당 주문을 delivered 상태로 바꿈
  • 필터링, 페이지네이션, 엔티티 간 조회, 읽기와 쓰기가 다 들어간 일상적인 백오피스 작업임

sequenceDiagram
    participant 에이전트
    participant 화면
    participant 앱핸들러
    participant 데이터
    에이전트->>화면: 스크린샷 확인
    화면->>에이전트: 렌더링된 일부 행만 노출
    에이전트->>앱핸들러: 클릭과 입력으로 작업 요청
    앱핸들러->>데이터: 조회와 업데이트 실행
    데이터-->>앱핸들러: 전체 결과 반환
    앱핸들러-->>화면: 현재 페이지 렌더링

비전 에이전트가 놓친 것

• 처음에는 양쪽 에이전트에게 똑같은 6문장짜리 지시만 줬음

  • API 에이전트는 8번 호출로 작업을 끝냄
  • pending 리뷰만 필터링해서 전부 승인하고, 주문 상태까지 delivered로 바꿈
  • 같은 앱 로직을 호출하지만 결과를 구조화 데이터로 직접 읽었기 때문에 헷갈릴 여지가 적었음

• 비전 에이전트는 같은 프롬프트에서 pending 리뷰 4개 중 1개만 승인하고 넘어감

  • 나머지 3개 리뷰는 리뷰 페이지의 visible fold 아래에 있었음
  • 에이전트 입장에서는 화면에 안 보이는 데이터가 더 있다는 신호가 약했음
  • 저자는 이걸 모델 문제가 아니라 인터페이스 문제로 봄

• 공정 비교를 위해 비전 에이전트용 프롬프트를 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의 구조화 출력 스키마를 안정적으로 만들지 못해 실패함

왜 이런 차이가 나는가

• 비전 에이전트는 행동하려면 먼저 봐야 함

  • 화면을 보고, 판단하고, 클릭하고, 다시 화면을 보는 루프를 반복함
  • 각 스크린샷은 수천 입력 토큰으로 들어감
  • 모델이 좋아져도 관련 데이터에 도달하기 위해 필요한 화면 전환 수 자체는 쉽게 줄지 않음

• 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처럼 수정할 수 없는 앱은 화면 자동화가 필요하지만, 내부 어드민은 핸들러와 상태를 도구로 노출하는 편이 비용과 신뢰성 면에서 더 낫다는 거예요.