브라우저 탭 안에서 돌아가는 "AI 서브루틴" – 토큰 0으로 자동화하는 법

자동화는 왜 이렇게 비싸고 느릴까

웹 자동화를 AI로 해보신 분들은 공감하실 텐데요, 매번 LLM한테 "이 페이지에서 로그인 버튼 눌러줘", "검색창에 이거 입력해줘" 하고 시키면 두 가지 문제가 생겨요. 하나는 느리다는 것이에요. 모델이 페이지 전체를 보고 어디를 클릭할지 판단하는 데 몇 초씩 걸리거든요. 두 번째는 매번 돈이 나간다는 것이에요. 똑같은 로그인 플로우를 100번 돌리면 LLM 호출도 100번 나가요. 게다가 결정론적이지 않아서 어제는 되던 게 오늘은 엉뚱한 버튼을 누르기도 하죠.

rtrvr.ai라는 팀이 내놓은 AI Subroutines가 딱 이 문제를 겨냥하고 있어요. 발상은 단순해요. "AI로 한 번 배운 자동화는 두 번째부터는 AI 없이 실행하자"는 거예요. 마치 사람이 처음엔 지도를 보고 길을 찾다가, 몇 번 다녀보면 지도 없이도 갈 수 있게 되는 것과 비슷해요.

어떻게 동작하나요

이게 뭐냐면요, 기본 아이디어는 LLM의 "탐색 실행"과 "재생 실행"을 분리하는 거예요. 처음 한 번은 LLM이 페이지를 보고 DOM을 분석해서 "아, 로그인 버튼은 이 셀렉터고, 이메일 입력칸은 이 셀렉터구나" 하고 학습을 해요. 이 과정을 거치면 클릭, 입력, 대기, 스크롤 같은 구체적인 액션 시퀀스가 서브루틴이라는 이름의 결정론적 스크립트로 저장돼요.

두 번째부터는 이 저장된 서브루틴을 브라우저 확장 프로그램이 탭 안에서 직접 실행해요. LLM을 전혀 호출하지 않죠. 그래서 제목에 "zero-token"이라는 말이 붙은 거예요. 실행 속도는 사람이 클릭하는 속도에 가깝고, 비용은 0에 수렴해요. 기존 Playwright나 Puppeteer 스크립트랑 비슷한 느낌인데, 그걸 사람이 코드로 짜는 게 아니라 AI가 관찰을 통해 만들어준다는 점이 다르죠.

그런데 현실에서 웹페이지는 수시로 바뀌잖아요. 셀렉터가 깨지거나 버튼 위치가 달라지면 결정론적 스크립트는 그 순간 멈춰버려요. 이걸 위해 fallback to LLM 구조를 갖추고 있어요. 서브루틴이 실행 중에 "어, 이 셀렉터가 안 보이네?" 하고 실패하면 그 순간에만 LLM을 다시 불러서 재학습하고, 새 서브루틴으로 업데이트하는 거예요. 평상시엔 싸고 빠른 길로 달리다가 문제가 생겼을 때만 비싼 길로 우회하는 셈이에요.

기존 방식과 뭐가 다른가

비슷한 공간에 있는 제품으로 Browser Use, Skyvern, OpenAI Operator, Anthropic Computer Use 같은 것들이 있어요. 이들 대부분은 매 단계마다 LLM이 화면을 보고 판단하는 구조예요. 품질은 좋지만 느리고 비싸요. 반대쪽 끝에는 Playwright, Selenium 같은 전통적인 자동화 도구가 있는데, 빠르고 싸지만 스크립트를 사람이 짜야 하고 페이지가 바뀌면 유지보수가 지옥이에요.

AI Subroutines는 이 둘의 중간을 노리는 거예요. "처음 한 번은 AI로 짜주고, 평소엔 전통 자동화처럼 돌고, 깨지면 AI가 고친다"는 하이브리드 모델이죠. 생각해보면 사람 개발자도 비슷하게 일해요. 새 워크플로우는 수동으로 탐색하면서 짜고, 익숙해지면 자동으로 실행하고, 뭔가 이상하면 다시 수동으로 확인하잖아요.

또 하나 눈에 띄는 점은 브라우저 탭 안에서 직접 실행한다는 거예요. 요즘 유행하는 서버 사이드 헤드리스 브라우저 방식이 아니라 사용자의 실제 탭에서 돌아가기 때문에, 로그인 세션이나 쿠키, 2FA 같은 걸 그대로 활용할 수 있어요. 외부 서버로 내 로그인 정보를 보내지 않아도 되니 보안 측면에서도 장점이 있고요.

한국 개발자 관점에서 볼 점

국내 기업들이 RPA(로봇 프로세스 자동화)에 꽤 많이 투자해왔잖아요. 유아이패스나 오토메이션 애니웨어 같은 걸 도입한 곳도 많고요. 그런데 RPA의 고질병이 유지보수 비용이에요. 업무 시스템 UI가 조금만 바뀌어도 봇이 멈추고, 그걸 고치려면 전담 인력이 필요했어요. AI Subroutines 같은 접근이 성숙해지면, 이런 "셀렉터 깨지면 AI가 알아서 고치는" 자가복구형 자동화가 RPA의 다음 세대가 될 가능성이 있어요.

실무에서 당장 써볼 만한 곳도 있어요. 예를 들어 사내 어드민 페이지에서 반복되는 데이터 입력, 경쟁사 가격 모니터링, 여러 SaaS에서 리포트 긁어오는 작업 같은 거요. 이런 건 LLM 기반 에이전트로 돌리자니 비용이 부담스럽고, 직접 스크립트를 짜자니 유지보수가 귀찮은 애매한 영역이거든요.

다만 주의할 점도 있어요. 많은 서비스의 이용약관은 자동화된 접근을 금지하고 있고, reCAPTCHA나 봇 탐지 시스템에 걸리면 계정이 정지될 수도 있어요. 내부 시스템이나 명시적으로 자동화가 허용된 곳부터 시작하시는 게 안전해요. 또 저장되는 서브루틴 자체가 일종의 코드이기 때문에, 버전 관리나 리뷰 프로세스를 어떻게 갖출지도 고민해봐야 해요.