Anthropic은 Computer Use, Skills API, Files API 세 가지 기능을 동시에 정식 출시했고, Computer Use에는 새로운 브라우저 도구를 추가했다. 이 세 기능은 그동안 베타 형태로 제공되어 왔으며, 개발자가 API를 호출할 때 베타 헤더를 붙여야 했고 가용성과 속도 제한도 베타 수준으로 취급됐다.
Computer Use의 작동 방식 자체는 달라지지 않았다. 모델에 화면 스크린샷을 주면, 키보드 앞에 앉은 사람처럼 클릭하고 입력하고 스크롤한다. 이번 변경에서 가장 실질적인 것은 한 턴에 여러 동작을 처리할 수 있게 됐다는 점이다. 예전에는 API를 한 번 호출하면 동작 하나만 돌려받을 수 있어 마우스를 한 번 움직이는 데도 왕복이 필요했다. 이제는 한 턴 안에서 여러 단계를 연속으로 내려보낼 수 있어 전체 작업 시간이 그만큼 줄어든다. 동시에 Computer Use는 BAA 적용 범위에 들어가면서 HIPAA 요건을 충족하게 됐다. 의료와 보험 분야의 컴플라이언스 문턱이 한 단계 낮아진 셈이다.
브라우저 도구는 다른 길을 택했다
새로 추가된 Browser Use는 컴퓨터 조작 범위를 웹 애플리케이션까지 넓힌 기능이지만, 방식은 스크린샷을 보고 클릭하는 것과 다르다. 모델이 페이지 구조를 읽고 구체적인 요소를 직접 지정하며, 더 이상 픽셀 좌표에 의존하지 않는다.
이 방식의 차이는 실제 프로덕션 환경에서 크게 드러난다. 좌표를 기준으로 클릭하는 스크립트는 창 크기가 바뀌거나 폰트 렌더링이 달라지거나 페이지에 쿠키 배너가 뜨는 것만으로도 엉뚱한 위치를 클릭하게 되고, 그 실패는 조용히 일어난다. 모델은 자신이 “제출” 버튼을 눌렀다고 생각하지만 실제로는 빈 공간을 클릭했고, 전체 프로세스는 오류 상태를 안은 채 계속 진행된다. 요소를 기준으로 위치를 지정하는 모델은 “이것은 name이 submit인 버튼이다”와 같은 정보를 얻을 수 있어, 오류가 나더라도 상위 단계에서 더 쉽게 잡아낼 수 있다.
자동화 업계는 셀레니움 시대에 이미 같은 과정을 겪은 적이 있다. 이미지 매칭에서 DOM 셀렉터로 되돌아간 것이다. 이번 에이전트 흐름은 스크린샷에서 출발했지만 결국 같은 결론에 도달했다.
두 방식이 완전히 배타적인 것도 아니다. 스크린샷 기반 조작의 가치는 넓은 커버리지에 있다. 데스크톱 소프트웨어, 원격 터미널, 오래된 윈도우 클라이언트에는 읽을 수 있는 DOM이 없어 화면을 보는 수밖에 없다. 브라우저 도구가 해결하는 것은 웹 영역이고, 웹은 마침 기업 백오피스 시스템의 대부분을 차지한다. Anthropic은 두 방식을 같은 Computer Use 아래 묶어, 개발자가 두 API 중 하나를 선택할 필요 없이 모델이 대상 창의 종류에 따라 방식을 바꾸도록 했다.
스킬은 업로드 방식으로
Skills API는 다른 문제를 다룬다. Anthropic은 스킬을 지시문, 스크립트, 템플릿을 담은 폴더로 정의하며, 모델은 작업에 필요할 때만 이를 불러온다. 정식 출시된 API는 업로드와 버전 관리를 단순화했고, 스킬은 Claude에 내장된 코드 샌드박스에서 실행되므로 개발자가 직접 실행 환경을 준비할 필요가 없다.
호스팅을 대신 맡아주는 부분의 무게는 작지 않다. 한 팀이 사내 보고서 생성 워크플로를 스킬로 만들려면, 예전에는 스크립트를 어느 서버에서 돌릴지, 어떻게 격리할지, 오류가 났을 때 어떻게 복구할지를 먼저 정해야 했다. 이제 그 부분은 플랫폼 쪽으로 흡수됐다. 대가는 실행 환경의 주도권을 넘긴다는 점이다. 어떤 의존성을 설치할 수 있는지, 외부 네트워크로 나갈 수 있는지는 플랫폼의 규칙을 따르게 된다.
파일 용량은 1TB로
Files API의 변화는 인프라 튜닝에 가깝다. 파일은 자동 만료를 지원하고, 속도 제한 상한은 이전보다 5배 높아졌으며, 조직당 1TB의 저장 공간이 제공된다. 한 번 업로드한 뒤에는 이후 요청에서 ID로 참조할 수 있어, 같은 계약서나 재무제표를 매번 컨텍스트에 다시 밀어 넣을 필요가 없다.
1TB라는 숫자는 텍스트 위주 애플리케이션에는 차고 넘치지만, 스캔 문서나 녹음, 영상 프레임을 다루는 애플리케이션에는 이야기가 다르다. 자동 만료 기능은 쉽게 지나치기 쉬운데, 이는 “정리”라는 작업을 개발자의 할 일 목록에서 지워주는 것이다. 오래 실행되는 에이전트가 중간 산출물을 지우는 것을 깜빡해서 용량을 다 써버리는 일이 없어진다.
Asteroid의 세 가지 숫자
Anthropic이 제시한 고객 사례는 보험금 청구 자동화를 하는 Asteroid다. 가장 긴 청구 워크플로는 32분에서 13분으로 줄었고, 건당 비용은 약 30% 낮아졌으며, 완료율은 100%를 기록했다.
세 숫자 중 완료율이 가장 달성하기 어렵다. 청구 프로세스는 여러 백오피스 시스템을 넘나들고, 중간 어느 한 단계라도 잘못 클릭하면 전체 프로세스가 도중에 멈추며, 그때부터 사람이 넘겨받는 비용은 자동화를 쓰지 않는 것보다 더 크다. 소요 시간과 비용의 개선은 한 턴 다중 동작과 재시도 감소로 얻을 수 있지만, 완료율 향상은 브라우저 도구가 가져온 결과에 더 가까워 보인다.
공개된 숫자로 대략 계산해 보면, 32분짜리 프로세스가 13분으로 줄면서 같은 인력이 하루에 처리할 수 있는 건수는 거의 두 배가 된다. 여기에 비용이 30% 더 낮아지면서 건당 손익 계산이 비로소 맞아떨어진다. 보험금 청구는 오류에 대한 허용치가 극도로 낮은 업무여서, 더 많이 지급하든 덜 지급하든 책임을 물게 된다. 그런데도 완료율 100%를 공개할 수 있다는 것은, 이 회사가 사람이 개입하는 마지막 관문 없이 프로세스를 끝까지 돌릴 만큼 자신 있다는 뜻이다.
세 기능은 현재 Claude Platform과 Microsoft Foundry에서 사용할 수 있고, Google Cloud의 Vertex AI도 뒤이어 지원할 예정이다. 같은 시기에 여러 플랫폼이 같은 방향으로 기능을 채워가고 있다. OpenAI도 앞서 Codex의 추론 기능과 컴퓨터 조작을 하나의 모델로 합쳤는데, 방향성 면에서 이번 정식 출시와 겹친다. 누구의 조작이 더 안정적인지는 결국 이런 여러 시스템을 넘나드는 업무의 완료율로 갈릴 것이며, 벤치마크 점수의 의미는 제한적이다.
참고 출처: Anthropic 공식 발표, CocoLoop, Claude Platform 문서. 속도 제한 배율, 저장 용량, Asteroid 사례의 세 가지 지표는 각각 개별적으로 확인함.