270억 개 파라미터짜리 모델 하나가 복잡한 컴퓨터 작업에서 최상위권 성적을 내면서 작업당 비용을 10분의 1 수준으로 낮췄습니다. 한 AI agent 스타트업이 공개한 Navigator n2는 multimodal(화면 이미지와 텍스트를 함께 입력받는) computer-use(화면을 인식해 마우스와 키보드로 컴퓨터를 조작하는 방식) 모델로, OSWorld-v2에서 부분 정확도 65.2%, 작업당 약 $1.46을 기록했습니다. 같은 정확도대에서 frontier 모델(각 연구소의 최상위 대형 모델)을 돌리면 작업당 $15에서 $40 이상이 듭니다.
비용 격차가 모델 크기만의 문제는 아닙니다. 컴퓨터를 조작하는 agent와 코딩 agent를 데이터 생성 과정 전 단계에 넣은 재귀적 학습 구조, 그리고 성공한 시도만 골라 fine-tuning(이미 학습한 모델을 특정 작업에 맞게 더 학습시키는 방법)하는 RFT(rejection sampling fine-tuning)와 RL(reinforcement learning, 강화학습)을 번갈아 돌리는 2단계 학습 설계가 함께 작동했습니다. agent 도입을 검토하는 팀이라면 정확도와 작업당 비용을 같은 저울에 올려야 하는 이유가 여기에 있습니다.
상시 실행 agent가 넘어야 할 세 가지
이 스타트업의 서비스는 사용자가 자리를 비운 동안에도 계속 돌아갑니다. Scouts는 웹을 지속적으로 감시하다가 조건이 맞으면 예약까지 처리하고, Delegate는 여러 단계를 거치는 개인 비서 역할을 하며, 로컬 버전은 사용자 컴퓨터의 운영체제 위에서 동작합니다. 좁은 공연장의 티켓이 풀리는 순간을 감시해 자동으로 구매하는 일이 이런 서비스가 노리는 작업입니다.
이 방식이 성립하려면 모델이 세 가지를 동시에 만족해야 합니다. 믿을 만하고, 빠르고, 아주 싸야 합니다. 그런데 최신 웹의 상당 부분에는 프로그램이 호출할 수 있는 API가 없습니다. 예약 페이지, 부동산 매물 사이트, 지역 공연장 예약 창구가 그렇습니다. 유료 API를 여는 플랫폼도 일부 있지만, 실제 업무가 벌어지는 대부분의 사이트는 사람이 브라우저를 다루듯 조작해야 합니다. 조건이 하나 더 붙습니다. 상시 agent는 사용자가 저장해 둔 자격 증명과 세션 쿠키를 그대로 쓰면서, 사용자가 화면을 보고 있지 않은 시간에 움직여야 합니다.
1년 반쯤 전만 해도 frontier 모델은 이런 일에서 기본적인 웹 탐색조차 버거워했습니다. 화면 속 요소의 위치를 정확히 짚어내는 grounding에서 자주 실수했고, 드롭다운 메뉴를 놓치거나 작업 도중 상태를 잃었습니다. 처음 보는 화면에서는 되돌리기 어려운 오류 연쇄에 빠지기도 했습니다. 이후 성능은 눈에 띄게 좋아졌지만, 항상 켜 두기에는 여전히 너무 느리고 비쌌습니다. 단순한 양식(폼) 입력 하나에 몇 분이 걸리고 실행할 때마다 적지 않은 비용이 나가는 구조로는 상시 감시 서비스를 만들 수 없습니다.
이 스타트업은 자사 모델을 직접 학습시키는 쪽을 택했습니다. 브라우저 안에서만 움직이는 Navigator n1과 n1.5를 거쳐, 데스크톱과 브라우저를 아우르는 첫 본격 computer-use 모델로 Navigator n2를 내놓았습니다.
성능과 비용의 좌표
Navigator n2는 270억 개 파라미터의 multimodal computer-use 모델입니다. 5개 주요 benchmark 가운데 4개에서 1위에 올랐고, OSWorld-v2에서는 근소한 차이로 2위를 기록했습니다. OSWorld 2.0, OSWorld-Verified, MyPCBench, MacAgentBench, WeaveBench 같은 평가에서 최상위권 자리를 지켰습니다.
OSWorld-v2의 과제는 사람이 직접 처리하면 1~2시간이 걸리는 복잡한 데스크톱 작업입니다. 여기서 Navigator n2는 65.2%의 부분 정확도를 내면서 작업 하나에 약 $1.46을 썼습니다.
| 구분 | 작업당 비용 |
|---|---|
| Navigator n2 (OSWorld-v2) | 약 $1.46 |
| frontier 모델(Claude 3.5 Sonnet, Claude Opus, GPT-4o 등) | $15~40 이상 |
같은 정확도 수준에서 비교하면 경쟁 frontier 모델은 n2보다 약 10배 비쌉니다. 반대로 같은 비용을 쓴다고 가정하면 n2의 작업 완료 정확도가 경쟁 모델의 3배를 넘습니다. API 가격은 입력 token(모델이 텍스트를 처리하는 단위) 100만 개당 $0.50, 캐시된 입력 token 100만 개당 $0.05, 출력 token 100만 개당 $4.00입니다.
컴퓨터를 컴퓨터답게 쓰는 원칙
설계 원칙은 ’computer use the computer way’입니다. 사람은 GUI(그래픽 사용자 인터페이스)를 거쳐 클릭하고 스크롤하고 타이핑합니다. 그러나 agent는 생물이 아니니 사람의 물리적 조작 방식에 가둘 이유가 없습니다. 좋은 agent는 GUI 조작, 프로그램 코드 실행(Python, Bash), 도구 호출(API) 세 가지를 한 작업 안에서 자유롭게 오갑니다.
기준은 분명합니다. 검색이나 데이터베이스 조회처럼 API가 있으면 API를 직접 불러 즉각적이고 결정적인 결과를 얻습니다. 데이터를 변환하거나 문서를 만들어야 할 때는 GUI를 수백 번 클릭하는 대신 Python 스크립트를 짜는 편이 훨씬 빠르고 오류가 적습니다. 슬라이드 14장짜리 발표자료를 만드는 일이 대표적입니다. 편집기에서 한 장씩 손으로 채우는 것과 스크립트를 한 번 돌리는 것의 차이입니다.
어려운 지점은 이 세 가지를 언제 어떻게 섞을지 학습시키는 것입니다. 같은 작업 안에서 적절한 순간에 방식을 바꿔야 합니다.
스캔 보고서를 Excel로 바꾸는 작업
50~60쪽 분량의 스캔 연간보고서 PDF를 쓸 수 있는 Excel 스프레드시트로 바꾸는 작업을 보면 이 원칙이 어떻게 작동하는지 드러납니다. 이 PDF의 재무 표는 이미지로 들어가 있어 골라낼 텍스트가 없습니다.
1단계에서 모델은 GUI로 화면 픽셀을 직접 읽습니다. 보이는 표를 눈으로 해석하는 방식입니다. 2단계에서 곧바로 bash 터미널로 넘어가 Python 스크립트를 작성하고 실행해 데이터를 추출하고 구조화하고 계산해 Excel 통합문서를 만듭니다. 3단계에서는 다시 GUI로 돌아와 만들어진 파일을 LibreOffice Calc에서 열고 원본 스캔 문서와 레이아웃과 수치를 눈으로 대조합니다. 칸마다 손으로 입력했다면 생겼을 오류가 사라지고 처리 속도도 크게 달라집니다. 읽기는 화면으로, 처리는 코드로, 검증은 다시 화면으로 돌아오는 흐름입니다.
▲ 스캔 문서의 스프레드시트 변환
데이터를 만드는 파이프라인에 agent를 넣다
성능을 좌우하는 가장 중요한 요소는 데이터 품질입니다. 개발사는 다섯 단계가 맞물린 재귀적 학습 구조를 만들었습니다. 작업 생성, 스트레스 테스트, 모델 학습, 실패 유형 분석, 다음 라운드 생성입니다.
핵심은 각 단계 안에 computer-use agent와 코딩 agent가 들어가 있다는 점입니다. 작업 생성 단계에서는 코딩 agent와 탐색 agent가 실제 가상 머신 환경을 돌아다니며 수만 개의 다양한 작업과 검증 스크립트를 만듭니다. 스트레스 테스트에서는 여러 후보 verifier(작업 성공 여부를 판정하는 검증 스크립트)로 rollout(모델이 작업을 실제로 한 번 수행해 남긴 기록)을 돌려 거짓 통과, 거짓 실패, reward hack(검증 허점을 파고들어 성공한 것처럼 보이게 하는 행동), 환경 결함을 찾아냅니다. 학습이 끝나면 실패 유형 분석이 rollout 오류를 묶어 어떤 역량이 계속 비어 있는지 드러내고, 그 결과가 다음 라운드의 작업 생성으로 이어집니다.
이 순환이 수 주 동안 만들어낸 검증된 작업은 10,000개가 넘고, 대상 응용 프로그램은 수백 개의 데스크톱 앱과 브라우저 앱에 걸쳐 있습니다.
▲ 재귀적 학습 파이프라인
RFT와 RL을 교차하는 학습
학습은 RFT와 RL을 반복해 교차하는 구조입니다. 역할은 뚜렷하게 나뉩니다.
RFT는 빠르고 연산 부담이 적습니다. 목표는 pass@k(여러 번 시도했을 때 적어도 한 번 성공할 수 있는 잠재력)를 끌어올리고 기본 동작을 익히는 것입니다. 이전 checkpoint(학습 중간에 저장한 모델 상태)의 실패 로그를 코딩 agent가 분석해 빠진 역량을 묶고, 그 약점에 맞춘 새 작업과 결정적 verifier, 가상 머신 sandbox(격리된 실행 환경)를 만들고, 가장 강한 checkpoint로 rollout을 돌려 성공 궤적을 모으고, 모델이 도저히 풀지 못하는 작업에는 작은 system prompt(모델에 주는 기본 지시문) 힌트를 넣어 궤적을 뚫고, 자동 감사로 거짓 통과와 결함 있는 verifier 스크립트를 걸러내고, 정제된 데이터셋으로 모델을 처음부터 학습하거나 fine-tuning합니다. 이전 라운드의 낡고 품질이 낮은 궤적은 주기적으로 버립니다. 의심스러운 데이터는 물량을 잃더라도 버리는 편이 낫습니다.
RL은 더 느리고 연산을 많이 씁니다. 목표는 pass@k로 확인한 잠재력을 pass@1(한 번의 시도에서 성공하는 확률)로 굳히는 것입니다. 예상치 못한 대화상자나 충돌, 지연이 실제 실행에서 생겼을 때 복구하는 행동도 RL에서 만들어집니다. verifier 스크립트에 논리적 허점이 있으면 학습이 reward hack으로 빠르게 무너질 수 있어, 후보 작업과 verifier를 여러 rollout으로 미리 찔러보는 과정이 필수입니다.
RL에서 중요한 선별 원칙도 있습니다. 모델이 항상 실패하는 작업과 항상 성공하는 작업은 버리고 중간 난이도 구간만 남깁니다. 너무 쉬운 작업은 기울기를 만들지 못한 채 연산만 쓰고, 너무 어려운 작업은 긍정 보상 신호를 만들지 못합니다.
구현도 실무적입니다. 완전 비동기 GRPO(여러 시도를 묶어 상대 비교로 정책을 개선하는 RL 알고리즘)를 오픈소스 Miles 프레임워크로 구현했고, rollout 생성은 GPU 기울기 갱신과 나란히 비동기로 돌리되 rollout이 얼마나 뒤처져도 되는지에 상한을 둡니다. 온라인 학습 중 너무 쉬워지거나 어려워진 작업은 dynamic sampling(학습 도중 표본을 난이도에 따라 다시 고르는 방식)으로 걸러내고, 학습 정밀도는 bf16(표현 범위를 넓힌 16비트 부동소수점 형식)이 아니라 fp16(16비트 부동소수점 정밀도)을 씁니다. 배포되는 추론 엔진과 학습 인프라 사이의 수치 어긋남을 없애기 위해서입니다. 참조 모델에 대한 KL divergence penalty, 할인율, 과정 기반 보상, 응답 길이 정규화는 넣지 않았습니다.
RFT와 RL, 무엇이 다르게 남는가
RFT만 거친 모델은 기본적인 bash 스크립팅 수준에 머물 수 있지만, 온라인 RL은 Python 코딩과 문서 처리 전반으로 일반화된 합성을 가능하게 합니다. 지도학습 방식의 fine-tuning이 이전 데이터 분포를 잊기 쉬운 반면, on-policy RL은 더 단순한 작업에 대한 역량을 비교적 잘 보존합니다. 비동기 RL 프레임워크로는 Miles 외에 VeRL, TRL도 쓸 만한 선택지입니다. 270억 개 파라미터 모델의 weight(학습된 모델 가중치)를 공개할지는 내부 논의가 있었지만 결정된 바는 없습니다.
benchmark 점수만으로 판단하지 않으려면
React 같은 최신 프런트엔드로 만든 웹 앱에는 버튼이 화면에는 보이는데 DOM(웹 페이지의 요소를 트리 구조로 나타낸 문서 객체 모델)이나 접근성 트리(화면 낭독기 같은 보조 기술에 제공되는 화면 요소 구조)에는 항목이 없는 경우가 있습니다. Navigator n2는 화면 픽셀과 DOM 텍스트를 함께 입력받는 multimodal 구조라 접근성 태그가 없어도 시각적 요소를 찾아 클릭합니다. 운영체제가 macOS에서 Windows나 Linux로 바뀌어 UI 배치나 단축키가 달라지는 상황도 같은 방식으로 다룹니다.
OSWorld 같은 benchmark 점수만으로 실제 신뢰성을 판단하기는 어렵습니다. 경로가 합리적인지, 도구 선택이 타당한지, 오류에서 스스로 복구하는지가 더 중요한 신호입니다.
사용자 대신 움직이는 agent와 봇 차단, captcha, walled garden(자사 서비스 안에서만 통제하려는 폐쇄형 환경)을 세우는 웹사이트 사이의 긴장은 피하기 어려운 구도로 보입니다. agent 전용 결제 규약도 새로 등장하고 있습니다. agent가 잘못된 결제를 했을 때 책임이 사용자에게 있는지 모델 개발자에게 있는지 결제 처리자에게 있는지는 아직 정리되지 않은 회색지대이며, 지출 한도 같은 안전장치가 필요합니다.
정리: 도입 전에 확인할 것
Navigator n2가 보여준 것은 전용 모델의 효율입니다. 270억 개 파라미터 규모로 복잡한 computer-use 작업에서 frontier 모델과 겨루면서 작업당 비용을 약 10분의 1로 낮췄습니다. 바탕에는 GUI·코드·API를 상황에 따라 섞는 실행 방식, 다섯 단계가 맞물린 재귀적 데이터 파이프라인, pass@k를 올리는 RFT와 pass@1을 굳히는 RL의 교차 학습이 있습니다.
agent 도입을 검토하는 팀이 표에서 확인할 것은 순위만이 아닙니다. 작업당 비용이 얼마인지, 같은 비용을 썼을 때 정확도가 어떻게 되는지, 실패했을 때 스스로 복구하는지, 도구 선택이 합리적인지를 함께 봐야 합니다.
출발점은 자사 업무를 API로 접근할 수 있는 구간과 GUI로만 접근할 수 있는 구간으로 나눠 보는 것입니다. API가 있으면 호출로 처리하고, 데이터 변환과 문서 생성은 스크립트로 돌리고, 검증은 화면으로 되돌아오는 구조가 비용을 줄이는 방향입니다. 상시 실행 agent라면 지출 한도와 결제 책임 소재 같은 안전장치도 함께 정리해 두어야 합니다.