Rihpig

Posted on May 8 • Originally published at apidog.com

컴퓨터 사용 vs 구조화된 API: 언제 유리할까 (2026)

컴퓨터 사용 모델로 LLM이 브라우저를 조작하게 하면, 같은 공급업체의 구조화된 API를 호출하는 방식보다 약 45배 더 비쌉니다. 핵심 원인은 스크린샷 루프가 매 단계마다 이미지 토큰과 재시도를 계속 소비하기 때문입니다.

지금 Apidog 사용해 보기

이 글에서는 45배 비용 차이가 어디서 발생하는지, 그래도 컴퓨터 사용이 필요한 경우는 언제인지, 그리고 Apidog로 구조화된 API 경로를 설계해 비용과 지연 시간을 줄이는 방법을 구현 관점에서 정리합니다. 이 기준은 OpenAI Operator, Anthropic Computer Use, Browser Use, Skyvern, 그리고 스크린샷 루프 기반의 다른 에이전트 도구에도 동일하게 적용됩니다.

AI 에이전트용 API를 설계하고 있다면 agents.md 파일 작성 방법도 함께 참고하십시오. 에이전트가 구조화된 API 경로를 기본값으로 선택하도록 만드는 규칙을 다룹니다.

요약

컴퓨터 사용은 LLM이 스크린샷을 보고 클릭, 키 입력, 스크롤을 출력하는 방식입니다.
구조화된 API는 LLM이 JSON 도구 호출을 만들고, 백엔드가 실제 API를 실행하는 방식입니다.
같은 작업에서도 컴퓨터 사용은 매 단계마다 스크린샷과 재시도를 보내므로 30~50배 더 많은 토큰을 소비합니다.
API가 없거나, API 접근이 제한되어 있거나, 워크플로가 스크립팅하기 어려운 인증 뒤에 있을 때만 컴퓨터 사용을 선택하십시오.
결제, 검색, CRM 업데이트, 내부 도구처럼 OpenAPI로 문서화할 수 있는 작업은 구조화된 API를 기본값으로 두십시오.
현실적인 구조는 하이브리드입니다. 구조화된 API가 대부분의 작업을 처리하고, 컴퓨터 사용은 긴 꼬리 예외만 처리합니다.

비용 격차가 큰 이유

45배라는 숫자는 특수한 벤치마크에서 나온 값이 아닙니다. 두 방식이 토큰을 소비하는 구조가 다르기 때문에 자연스럽게 발생합니다.

구조화된 API 호출은 보통 다음 흐름입니다.

사용자 요청을 모델에 전달합니다.
도구 스키마를 함께 제공합니다.
모델이 JSON 객체를 반환합니다.
런타임이 해당 JSON으로 실제 API를 호출합니다.

예를 들어 list_failed_payments 같은 도구 호출은 수백 개의 입력 토큰과 짧은 JSON 출력만 필요합니다.

반면 컴퓨터 사용 루프는 다음 과정을 반복합니다.

사용자 요청과 현재 화면 스크린샷을 모델에 보냅니다.
모델이 클릭 좌표나 키 입력을 반환합니다.
브라우저에서 동작을 실행합니다.
다시 스크린샷을 찍습니다.
다음 동작을 위해 다시 모델에 보냅니다.

일반적인 “항공권 예약” 같은 작업은 이 루프를 12~30회 반복할 수 있습니다. 일반 해상도 스크린샷 하나가 약 1,500 토큰을 소비한다고 보면, 스크린샷만으로도 비용이 빠르게 증가합니다.

Anthropic의 컴퓨터 사용 문서는 스크린샷 토큰 가격을 공개적으로 설명합니다. 실제 비용은 더 커질 수 있습니다. 모델이 잘못 클릭하거나, 올바른 요소를 지나쳐 스크롤하거나, 쿠키 배너를 닫는 데 추가 라운드를 쓰기 때문입니다.

컴퓨터 사용이 구조화된 API보다 45배 더 비싸다는 HN 논의에서도 일반적인 패널티를 30~50배로 봅니다. 이는 Apidog에서 같은 작업을 구조화된 API 경로와 브라우저 경로로 재생할 때 관찰되는 차이와도 일치합니다.

구조화된 API를 선택해야 하는 경우

다음 조건 중 하나라도 해당하면 컴퓨터 사용보다 구조화된 API를 먼저 설계하십시오.

1. 벤더가 API 문서를 제공한다

벤더가 OpenAPI 스펙, GraphQL 스키마, REST 문서 중 하나라도 제공한다면 해당 경로를 사용하십시오.

JSON 형식이 존재하면 LLM은 필드를 채울 수 있습니다. 문서화된 엔드포인트에서는 도구 호출 실패를 감지하기 쉽고, 재시도도 단순합니다.

2. 작업이 한두 개의 엔드포인트로 표현된다

다음 작업은 브라우저를 열 필요가 없습니다.

Stripe 고객 생성
HubSpot 거래 단계 업데이트
Slack 메시지 게시
CI 재실행 트리거
내부 승인 상태 변경

이런 작업은 단일 API 호출 또는 짧은 API 체인으로 끝납니다. 브라우저를 경유하면 비용, 지연 시간, 실패 지점만 늘어납니다.

3. 무인 워크플로로 실행된다

크론 작업, 웹훅, 큐 워커는 브라우저 스크린샷 루프를 안정적으로 감독하기 어렵습니다.

구조화된 API 호출은 네트워크 계층에서 실패 원인이 명확합니다.

400: 요청 스키마 문제
401/403: 인증 문제
429: 속도 제한
5xx: 서버 문제

반면 컴퓨터 사용은 “버튼을 찾지 못함”, “스크롤 위치가 다름”, “모달이 떠 있음” 같은 불안정한 상태를 자주 만납니다.

4. 지연 시간이 중요하다

구조화된 API 호출은 보통 수백 밀리초에서 1초 이내에 반환됩니다.

컴퓨터 사용 루프는 15라운드만 돌아도 30~90초가 걸릴 수 있습니다. 재시도가 포함되면 더 길어집니다.

사용자가 결과를 기다리는 흐름이라면 구조화된 API를 선택하십시오.

5. 배포 전 테스트가 필요하다

Apidog에서 JSON 엔드포인트를 모의하는 작업은 빠르게 끝납니다. 반면 브라우저 스크린샷 루프를 안정적으로 모의하는 것은 훨씬 어렵습니다.

컴퓨터 사용이 필요한 경우

컴퓨터 사용은 기본값이 아니라 예외 처리 수단입니다. 그래도 다음 상황에서는 실용적인 선택이 될 수 있습니다.

레거시 벤더 포털

일부 조달, 운송, 복리후생 포털은 REST API가 없고 오래된 ASP.NET 세션 뒤에 있습니다.

이 경우 컴퓨터 사용은 분기마다 깨지는 Selenium 스크립트보다 유지 보수 부담이 낮을 수 있습니다. 실행 비용은 높지만 유지 보수 비용을 줄이는 선택입니다.

수정할 수 없는 내부 도구

다음과 같은 시스템은 API를 추가하기 어려울 수 있습니다.

오래된 CRM
레거시 ERP
SharePoint 대시보드
고객사가 구매해 직접 수정할 수 없는 업무 시스템

통합을 배포할 수 없고 iPaaS도 사용할 수 없다면 컴퓨터 사용이 현실적인 대안입니다.

일회성 운영자 작업

예를 들어 창업자가 에이전트에게 다음과 같이 요청하는 경우입니다.

이 50개 경쟁사를 조사하고 Notion에 핵심 내용을 정리해줘.

이 작업은 장기적으로 유지할 구조화된 계약이 필요하지 않을 수 있습니다. 한 번 실행하고 끝나는 작업이라면 컴퓨터 사용 비용이 허용될 수 있습니다.

약관 위반 가능성이 있는 스크래핑은 제외

“컴퓨터 사용으로 이 사이트를 스크랩해줘” 유형의 요청은 벤더 약관을 위반할 수 있습니다. 이 경우 비용보다 법적·계약적 리스크가 더 큰 문제입니다.

의사결정 프레임워크

컴퓨터 사용을 선택하기 전에 다음 순서로 확인하십시오.

검사	예인 경우	아니오인 경우
문서화된 API가 있는가?	API를 사용하십시오.	다음 검사로 이동하십시오.
비공개 엔드포인트를 감싸는 얇은 서버측 어댑터를 만들 수 있는가?	어댑터를 만들고 JSON으로 노출하십시오.	다음 검사로 이동하십시오.
작업이 일회성이거나 소량인가? 예: 하루 100회 미만	컴퓨터 사용을 고려할 수 있습니다.	다음 검사로 이동하십시오.
매 실행마다 30~50배 토큰 비용을 지불해도 되는가?	컴퓨터 사용을 선택하십시오.	중단하고 API 접근을 협상하십시오.

실무에서는 많은 워크플로가 첫 번째 또는 두 번째 검사에서 구조화된 API 후보로 분류됩니다. 컴퓨터 사용은 이 두 조건을 모두 통과하지 못할 때만 남겨두는 것이 좋습니다.

에이전트에서 구조화된 API가 작동하는 방식

예제 작업은 다음과 같습니다.

어제 실패한 결제 내역을 가져와줘.

구조화된 API 방식에서는 에이전트가 대시보드를 열지 않습니다. 대신 도구 스키마를 보고 JSON 인자를 생성합니다.

import json
from datetime import date, timedelta
from openai import OpenAI

client = OpenAI()

tools = [
    {
        "type": "function",
        "function": {
            "name": "list_failed_payments",
            "description": "List failed payments in a date range",
            "parameters": {
                "type": "object",
                "properties": {
                    "start": {"type": "string", "format": "date"},
                    "end": {"type": "string", "format": "date"}
                },
                "required": ["start", "end"]
            }
        }
    }
]

resp = client.chat.completions.create(
    model="gpt-5.5",
    messages=[
        {
            "role": "user",
            "content": "Show yesterday's failed payments."
        }
    ],
    tools=tools,
    tool_choice="auto"
)

call = resp.choices[0].message.tool_calls[0]
args = json.loads(call.function.arguments)

payments = stripe.PaymentIntent.list(
    created={
        "gte": args["start"],
        "lte": args["end"]
    },
    limit=100
)

이 방식의 실행 흐름은 단순합니다.

사용자 요청을 모델에 전달합니다.
모델이 start, end 값을 포함한 JSON을 반환합니다.
서버가 Stripe API를 호출합니다.
결과를 사용자에게 반환합니다.

브라우저를 열 필요가 없습니다. 날짜 선택기를 클릭할 필요도 없고, 대시보드에서 텍스트를 추출할 필요도 없습니다.

컴퓨터 사용으로 같은 작업을 처리하면 일반적으로 다음 흐름이 됩니다.

브라우저 실행
Stripe 로그인
대시보드 스크린샷 전송
날짜 선택기 클릭
다시 스크린샷 전송
날짜 범위 선택
다시 스크린샷 전송
실패 상태 필터 적용
다시 스크린샷 전송
화면에서 숫자와 행 추출

각 스크린샷이 약 1,500 입력 토큰을 소비합니다. 12라운드만 돌아도 구조화된 API보다 훨씬 비싸고 느립니다.

Apidog로 구조화된 경로 설계하기

팀이 컴퓨터 사용을 선택하는 이유는 대개 API가 불가능해서가 아닙니다. 에이전트가 사용할 수 있는 깔끔한 도구 인터페이스가 아직 설계되지 않았기 때문입니다.

Apidog를 사용하면 에이전트용 API 계약을 먼저 설계하고, 모의 서버로 검증한 뒤, 실제 런타임에 연결할 수 있습니다.

1단계: 에이전트 작업을 엔드포인트로 모델링하기

먼저 에이전트가 수행해야 하는 작업을 API 단위로 나눕니다.

예:

POST /invoices/search
POST /deals/update-stage
POST /messages/send
POST /payments/list-failed

운영자 데모에서 브라우저로 처리하던 작업의 상당수는 이런 소수의 POST 엔드포인트로 대체할 수 있습니다.

Apidog의 디자인 보기에서 엔드포인트를 정의하면 OpenAPI 3.1 문서를 생성할 수 있습니다.

2단계: OpenAPI 문서를 에이전트 프레임워크에 연결하기

생성한 OpenAPI 문서를 에이전트 런타임에 입력합니다.

사용 가능한 경로는 다음과 같습니다.

OpenAI tools 배열
Anthropic tool_use 스키마
LangChain OpenAPI 로더
자체 도구 라우터

이제 에이전트는 자연어로 화면을 탐색하지 않고, 타입이 정의된 함수 호출을 생성합니다.

3단계: 모의 서버 켜기

Apidog의 모의 서버를 켜면 각 엔드포인트가 현실적인 JSON 응답을 반환합니다.

이를 통해 다음을 프로덕션 연결 없이 테스트할 수 있습니다.

에이전트가 올바른 도구를 선택하는지
필수 필드를 빠뜨리지 않는지
잘못된 날짜 형식을 보내지 않는지
재시도 로직이 동작하는지
실패 응답을 사용자에게 제대로 설명하는지

같은 패턴은 Apidog의 계약 우선 개발 가이드에서도 다룹니다.

4단계: 요청과 응답 재생하기

에이전트 실행 중 발생한 요청과 응답을 기록하면 성공한 실행과 실패한 실행을 비교할 수 있습니다.

확인할 항목은 다음과 같습니다.

잘못 선택된 도구
누락된 필수 필드
잘못된 enum 값
예상과 다른 응답 스키마
과도한 재시도

이 방식은 “어제는 동작했는데 오늘은 실패했다”는 에이전트 문제를 디버깅하는 데 유용합니다.

5단계: 배포하기

같은 Apidog 프로젝트를 다음 용도로 계속 사용할 수 있습니다.

공개 API 문서
내부 API 계약
QA 테스트 하네스
모의 서버
에이전트 도구 스키마
요청/응답 검증 기준

하이브리드 구조 설계하기

실제 환경에서는 구조화된 API와 컴퓨터 사용을 함께 쓰는 경우가 많습니다.

권장 기본값은 다음과 같습니다.

90%: 설계된 구조화 도구 인터페이스 사용
10%: 레거시 포털이나 예외 작업에 컴퓨터 사용 폴백
라우터 프롬프트가 작업 이름 또는 도구 존재 여부에 따라 경로 선택

라우터는 간단하게 시작할 수 있습니다.

사용자의 요청을 확인한다.
요청을 처리할 수 있는 tool_name이 known_tools 안에 있으면 해당 도구를 호출한다.
적절한 도구가 없으면 browser_agent로 넘긴다.

Anthropic Claude 4.5와 OpenAI GPT-5.5는 이런 라우팅을 안정적으로 처리할 수 있습니다. DeepSeek V4에서도 같은 패턴을 구현할 수 있습니다. 요청 형태는 DeepSeek V4 API 사용 방법을 참고하십시오.

관측 가능성에서는 두 경로를 반드시 분리해서 추적하십시오.

권장 지표는 다음과 같습니다.

구조화된 API 호출 수
컴퓨터 사용 폴백 호출 수
경로별 평균 토큰 비용
경로별 평균 지연 시간
경로별 실패율
폴백으로 전환된 작업 이름

정상적인 하이브리드 구조라면 구조화된 호출이 볼륨 대부분을 차지해야 합니다. 컴퓨터 사용 폴백 비율이 커진다면 누락된 API 엔드포인트를 설계해야 한다는 신호입니다.

피해야 할 실수

스키마 없이 프롬프트만 작성하기

“필요하면 결제 API를 호출해” 같은 산문 프롬프트만으로는 안정적인 도구 호출을 기대하기 어렵습니다.

항상 JSON 스키마를 제공하십시오.

{
  "type": "object",
  "properties": {
    "customer_id": {
      "type": "string"
    },
    "limit": {
      "type": "integer",
      "minimum": 1,
      "maximum": 100
    }
  },
  "required": ["customer_id"]
}

스키마가 엄격할수록 모델의 도구 호출 정확도는 높아지고, 실패 원인도 명확해집니다.

에이전트가 런타임에 스키마를 만들게 하기

스키마는 제품 인터페이스입니다. 런타임에서 모델이 임의로 만들게 두면 프로덕션 중단이 발생하기 쉽습니다.

권장 방식은 다음과 같습니다.

Apidog에서 스키마 작성
버전 관리
변경 사항 리뷰
모의 서버로 테스트
에이전트 런타임에 배포

토큰만 기록하고 비용은 기록하지 않기

컴퓨터 사용 비용은 이미지 입력 토큰에 숨어 있습니다. 일부 관측 가능성 도구는 텍스트 토큰과 이미지 토큰을 다르게 표시하거나, 실제 청구 비용과 차이가 날 수 있습니다.

반드시 모델 공급업체의 청구 콘솔과 함께 비교하십시오.

컴퓨터 사용과 RPA를 혼동하기

RPA는 알려진 DOM 요소나 좌표에 대해 스크립트화된 동작을 반복합니다.

컴퓨터 사용은 매 스크린샷마다 모델이 다시 판단합니다.

RPA: 반복 가능하고 저렴하지만 UI 변경에 취약
컴퓨터 사용: 유연하지만 느리고 비쌈
API: 빠르고 안정적이며 테스트 가능

RPA로 충분한 작업에 컴퓨터 사용을 쓰지 마십시오.

지연 시간 비용을 무시하기

45배 토큰 비용도 문제지만, 60초짜리 스크린샷 루프가 사용자 흐름을 막는 것도 큰 문제입니다.

사용자가 기다리는 기능이라면 거의 항상 API 경로가 필요합니다.

고려할 대안

벤더에 공식 API가 없더라도 컴퓨터 사용 전에 검토할 옵션이 있습니다.

Playwright 또는 Puppeteer

헤드리스 브라우저 스크립트는 개발 비용은 들지만 실행당 LLM 토큰 비용은 없습니다.

단점은 UI 변경에 취약하다는 점입니다. 유지 보수 예산을 함께 잡아야 합니다.

Zapier 또는 Make 커넥터

벤더가 Zapier나 Make 커넥터를 제공한다면 iPaaS가 이미 통합 비용을 부담한 것입니다.

빠르게 배포해야 한다면 직접 브라우저 에이전트를 만드는 것보다 유리할 수 있습니다.

비공개 API 래핑

브라우저 개발자 도구의 네트워크 탭을 보면 많은 대시보드가 내부 JSON 엔드포인트와 통신합니다.

이 경우 다음 방식으로 처리할 수 있습니다.

네트워크 요청 확인
인증 방식 파악
서버측 어댑터로 래핑
Apidog에 문서화
준안정 API로 취급

이 패턴은 Postman 없이 API 테스트하기에서도 다룹니다.

컴퓨터 사용은 최후의 수단이어야 합니다.

실제 사용 사례

핀테크 규제 준수 팀

한 팀은 6단계 컴퓨터 사용 기반 Stripe 보고서 생성을 세 개의 구조화된 호출로 대체했습니다.

결과는 다음과 같았습니다.

토큰 비용 92% 감소
실행 시간 41초에서 2초로 감소
실패 원인 추적이 쉬워짐

B2B SaaS 지원 에이전트

지원 에이전트는 API가 없는 벤더 조달 포털에만 컴퓨터 사용을 유지했습니다.

나머지 작업은 Apidog에서 설계한 OpenAPI 도구 호출로 라우팅했습니다.

결과적으로 전체 토큰 지출은 월 $4,200에서 $310으로 줄었습니다.

개인 창업자

한 창업자는 레거시 ERP에서 Notion 대시보드를 새로 고치는 작업에만 주 1회 컴퓨터 사용을 사용했습니다.

주 1회 실행 비용은 몇 센트 수준이었고, 대안은 몇 주짜리 통합 프로젝트였습니다. 이런 낮은 빈도의 예외 작업은 컴퓨터 사용에 적합합니다.

결론

45배 비용 차이는 실제로 발생할 수 있으며, 에이전트 아키텍처를 설계할 때 반드시 고려해야 합니다.

기본값은 Apidog에서 설계한 구조화된 API여야 합니다. 컴퓨터 사용은 API가 없고, 실행 빈도가 낮으며, 토큰 비용보다 통합 비용이 더 큰 경우에만 선택하십시오.

배포 전 체크리스트는 다음과 같습니다.

컴퓨터 사용은 같은 작업의 구조화된 API 호출보다 30~50배 더 많은 토큰을 소비할 수 있습니다.
문서화된 엔드포인트와 JSON 스키마는 비용, 지연 시간, 안정성에서 스크린샷 루프보다 유리합니다.
하이브리드 구조를 기본으로 두십시오. Apidog에서 대부분의 도구를 설계하고, 긴 꼬리 예외만 컴퓨터 사용으로 넘기십시오.
라이브 모델에 연결하기 전에 모의 서버로 도구 인터페이스를 검증하십시오.
관측 가능성에서 구조화된 API와 컴퓨터 사용 폴백을 분리해서 추적하십시오.

다음 단계는 단순합니다. Apidog에서 에이전트 도구 인터페이스용 프로젝트를 만들고 모의 서버를 켜십시오. 컴퓨터 사용으로 배포하려던 워크플로가 두세 개의 구조화된 호출로 줄어드는지 빠르게 확인할 수 있습니다.

FAQ

컴퓨터 사용이 구조화된 API보다 저렴할 때가 있습니까?

실행당 기준으로는 거의 없습니다. 스크린샷 토큰이 대부분의 비용을 차지하기 때문입니다.

다만 통합 개발 비용이 장기간의 실행 비용보다 훨씬 큰 경우에는 총비용 관점에서 컴퓨터 사용이 더 나을 수 있습니다. 일반적으로 API가 없고 실행 빈도가 매우 낮은 워크플로에 해당합니다.

에이전트용 JSON 도구 인터페이스를 어떻게 모의합니까?

Apidog에서 엔드포인트를 설계하고 내장 모의 서버를 켠 다음, 에이전트의 base URL을 모의 서버 URL로 지정하십시오.

그러면 실제 백엔드나 프로덕션 데이터 없이도 현실적인 JSON 응답으로 에이전트 흐름을 테스트할 수 있습니다. 자세한 흐름은 QA 엔지니어를 위한 API 테스트 도구를 참고하십시오.

어떤 모델에서든 도구 호출에 OpenAPI를 사용할 수 있습니까?

네. OpenAI의 tools 매개변수, Anthropic의 tool_use 블록, DeepSeek V4의 도구 호출 엔드포인트는 모두 OpenAPI 3.1 기반 스키마를 활용할 수 있습니다.

Apidog는 에이전트 런타임에 연결하기 쉬운 형태로 스키마를 내보낼 수 있습니다. DeepSeek 요청 형식은 DeepSeek V4 API 사용 방법을 참고하십시오.

GPT-5.5는 여전히 컴퓨터 사용을 지원합니까?

OpenAI는 Operator 제품과 Responses API를 통해 컴퓨터 사용 기능을 제공합니다. 비용 구조는 Anthropic의 스크린샷 기반 비용과 유사한 형태로 이해할 수 있습니다.

이 글의 권장 사항은 특정 벤더와 무관하게 적용됩니다.

Skyvern, Browser Use 같은 오픈 소스 에이전트는 어떻습니까?

계산 방식은 같습니다. 더 저렴한 오픈 모델을 사용하면 호출당 가격은 낮출 수 있지만, 라운드 수와 스크린샷 크기는 크게 달라지지 않습니다.

API가 존재한다면 구조화된 API 호출이 여전히 더 빠르고 저렴하며 안정적입니다.

에이전트 작업에 필요한 엔드포인트가 누락되었는지 어떻게 알 수 있습니까?

에이전트가 반복적으로 브라우저 폴백을 선택하는 작업을 추적하십시오.

특정 작업에서 계속 컴퓨터 사용으로 넘어간다면 도구 인터페이스에 엔드포인트가 빠져 있을 가능성이 큽니다. 해당 작업을 Apidog에 추가하고 스키마를 다시 생성하면 에이전트가 구조화된 API 경로를 선택할 수 있습니다.