AI 브라우저 Aside에 계정 6개짜리 결제 추적을 맡겨봤다 2026 — 해낸 것과 멈춘 지점

Posted on by

지난 8월에 Aside를 한 번 다뤄보려다 접었다. 공식 문서만 읽고 쓰려니 “브라우저 안에서 자연어로 일을 시킨다”는 소개 이상을 쓸 수가 없었다. 브라우저 에이전트 제품은 소개 문구가 다 비슷해서, 실제로 뭘 어디까지 해내는지는 붙여보기 전엔 모른다. 그래서 초안만 남겨두고 발행을 미뤘다.

그 앵커가 9월에 생겼다. 카드 승인 문자 한 통 때문이었다. 9월 9일 오후 1시 43분, 가맹점 GOOGLE*GOOGLEONE에 USD 19.99. 구글에 돈을 낸 건 알겠는데 내 구글 계정이 여섯 개가 넘는다. 어느 계정에서 나간 돈인지 문자만으로는 알 수가 없었다. 딱 브라우저 에이전트가 잘하거나 처참하게 실패할 종류의 일이었고, 그래서 Aside에게 넘겼다.

이 작업이 에이전트에게 까다로운 이유

먼저 왜 이게 시험대가 되는지부터 짚고 가자. 이 일에는 API가 없다. 카드사 앱은 가맹점과 금액만 알려주고 구글 계정이라는 개념 자체를 모른다. Google Play 고객센터도 명세서 청구명이 GOOGLE*앱 이름이나 GOOGLE*콘텐츠 유형 형식이라고만 안내한다. 서비스는 알려주지만 계정은 안 알려준다는 뜻이다.

그러니까 남는 방법은 하나다. 계정마다 직접 로그인해서 Gmail 영수증, 결제센터 거래내역, 활성 구독 목록, 등록된 결제수단을 일일이 대조하는 것. 계정 여섯 개에 항목 네 개면 스물네 번의 대조다. 사람이 하면 지겹고, 지겨우면 순서가 흐트러지고, 순서가 흐트러지면 “확인했나?” 싶은 칸이 생긴다.

통합 API로 붙는 기존 자동화 도구는 여기서 아예 시작을 못 한다. 붙일 API가 없기 때문이다. 로그인된 브라우저 세션 안에서 움직이는 도구만 후보가 된다. Aside가 스스로 내세우는 게 정확히 이 지점이다. 회사 소개에도 통합에 의존하지 않고 로그인된 웹사이트에서 직접 일을 끝낸다고 적혀 있다.

Aside가 어떤 물건인지부터

Aside는 2025년 가을 Y Combinator 배치에서 나온 샌프란시스코 스타트업이고, 공식 프로필 기준 8명 규모다. 슬로건은 “실제 업무를 대신 해주는 브라우저”다. 챗봇을 브라우저 옆에 붙인 구조가 아니라, 브라우저 자체를 에이전트가 쓰도록 다시 만든 쪽에 가깝다.

구조는 세 덩어리다. 로그인된 사이트를 돌아다니는 브라우저 에이전트, 기기 안에 마크다운으로 쌓이는 메모리, 그리고 에이전트 전용 비밀번호 관리자. 셋 다 로컬에서 돈다. 브라우징 기록이 로컬 메모리가 되어서 어떤 사이트와 맥락이 중요한지 파악한다는 게 공식 설명이다.

벤치마크 얘기도 있다. Mind2Web, Odyssey, bu-bench-v1 세 곳에서 1위라고 공식 프로필에 적어뒀다. 다만 이건 자사 발표 수치이고, 내가 재현한 건 아니다. 이 글에서 다루는 건 벤치마크 점수가 아니라 실제 일 하나를 맡겼을 때의 결과다.

해낸 것 1. 스물네 번의 대조를 순서대로

가장 먼저 눈에 띈 건 지겨운 일을 지겨워하지 않는다는 점이었다. 브라우저에 로그인돼 있던 계정 다섯 개를 A부터 E로 두고, 계정마다 같은 네 항목을 같은 순서로 확인하게 했다. Gmail의 영수증, 결제센터 거래내역, 활성 구독 목록, 등록된 결제수단의 카드 끝 네 자리.

결과는 전부 탈락이었다. 문제의 카드는 다섯 계정 중 몇 곳에 등록돼 있었는데, 그 계정들 어디에도 해당 금액의 결제 내역이 없었다. 다섯 개를 다 털고 남은 결론은 “이 다섯은 아니다” 하나뿐이었다.

허탕처럼 보이지만 이게 중요하다. 다섯 개를 확실히 제거했기 때문에 여섯 번째를 의심할 수 있었다. 사람이 했으면 세 번째쯤에서 “카드가 여기 등록돼 있네” 하고 멈췄을 가능성이 높다. 실제로 내 첫 가설이 그거였다. 카드가 등록된 계정이 결제한 계정일 거다. 그 가설은 틀렸고, 끝까지 훑었기 때문에 틀렸다는 걸 알 수 있었다. 결제수단은 계정에 매달린 속성이지 결제의 증거가 아니다.

해낸 것 2. 거절당한 뒤에 경로를 바꿨다

계정을 찾은 다음이 더 인상적이었다. 여섯 번째 계정의 Gmail 영수증에서 결제 시각, 금액, 카드 끝 네 자리가 카드 승인 문자와 셋 다 일치했고, 원인이 무료 체험 종료 후 자동 유료 전환이라는 것까지 영수증에 있었다. 여기까지가 1단계다.

2단계는 해지, 3단계는 환불이었다. Google Play 주문내역에서 환불을 요청했고, 자동 심사에서 거절당했다. Google One 정책 문서를 보면 이유가 명확하다. 대부분의 국가에서 구입한 Google 스토리지 요금제는 환불되지 않는다는 게 기본 원칙이다.

보통 자동화는 여기서 끝난다. “요청함, 거절됨” 찍고 종료하는 게 스크립트의 정상 동작이다. 그런데 이 작업은 종료되지 않고 경로를 갈아탔다. Google One 고객지원 이메일로 넘어가서 예외 환불 재심을 요청했고, 지원팀이 회신으로 요구한 두 가지 동의 조건을 요약해 나에게 확인받은 다음 같은 스레드에 답장했다. 막힌 문 앞에서 다른 문을 찾는 동작이 스스로 나왔다는 게 이 실험에서 제일 값진 관찰이다.

해낸 것 3. 해지와 환불을 섞지 않았다

세 번째는 절차 분리다. 많은 사람이 착각하는 게 해지하면 방금 나간 돈도 돌아올 거라는 생각인데, 아니다. Google Play 고객센터는 정기 결제를 취소해도 이미 요금을 지불한 기간 동안은 계속 사용할 수 있다고 명시한다. 취소는 미래의 청구를 막는 조작이지 과거 결제를 되돌리는 조작이 아니다.

Aside는 이 둘을 별개 작업으로 두고 순서까지 맞췄다. 해지를 먼저 걸어 다음 달 청구를 막고, 그다음 환불을 따로 요청했다. 환불 심사가 며칠 걸리는 동안 다음 결제일이 오면 두 번째 청구가 붙기 때문에 이 순서가 맞다. 조사 중에 발견한 다른 계정의 무료 체험 하나도 같은 김에 정리했다.

며칠 걸리는 심사에 후속 확인 일정을 걸어둔 것도 같은 맥락이다. 사람은 “해지했으니 끝” 하고 손을 놓기 쉬운데, 큐에 남아 있으면 안 빠진다.

비밀번호를 안 보고 로그인한다는 구조

이 작업을 맡길 수 있었던 이유가 하나 더 있다. 메일함과 결제 정보를 동시에 여는 일이라 권한 부담이 작지 않은데, Aside의 비밀번호 관리자 구조가 그 부담을 낮춰준다.

공식 도움말 기준으로 에이전트는 login 동작을 쓸 수는 있지만 원본 비밀번호를 받지는 않는다. 자격증명은 에이전트에게 전달되는 대신 웹사이트에 직접 자동 입력된다. 접근 정책도 Settings의 Passwords 항목에서 항상 허용, 잠금 해제된 동안만, 사용 안 함 세 단계로 고를 수 있다.

에이전트에게 계정을 열어준다와 에이전트에게 비밀번호를 준다는 다른 얘기다. 이 구분이 있어서 계정 여섯 개를 열어주는 결정이 덜 부담스러웠다. 다만 로그인이 된다는 건 그 계정 안에서 할 수 있는 일이 열린다는 뜻이기도 하다. 비밀번호를 안 보는 것과 계정 안에서 아무것도 안 하는 것은 다르다.

멈춘 지점 세 개

과장하지 않으려면 여기도 같이 적어야 한다. 첫째, 내가 모르는 계정은 못 찾았다. 다섯 개가 전부 탈락한 뒤 여섯 번째 계정을 떠올린 건 나였다. 에이전트는 내가 로그인해준 범위 안에서만 움직였고, 존재를 모르는 계정은 조사 대상에 들어오지도 않았다.

둘째, 본인 인증은 전부 사람이 눌렀다. 계정 전환과 인증 단계는 넘어가지 않았다. 이건 제품 결함이라기보다 설계다. 결제, 게시, 메시지 같은 민감한 동작은 사용자 승인을 거치도록 되어 있다고 공식 프로필에도 적혀 있다. 승인 버튼이 사라지길 기대하면 안 된다.

셋째, 결과는 구글이 정한다. 재심 요청까지는 자동화가 밀어줬지만 승인 여부는 자동화 밖의 일이다. 이 글을 쓰는 시점에도 결과는 나오지 않았다. 브라우저 에이전트가 협상을 대신해주는 것도, 정책을 바꿔주는 것도 아니다.

8월의 판단이 어떻게 바뀌었나

8월 초안에서 내가 미뤄둔 질문은 “이게 Playwright를 대체하나”였다. 실사용 한 건을 거치고 나니 질문 자체가 틀렸다는 쪽으로 정리됐다.

Playwright는 같은 입력에서 같은 결과를 내고, 코드로 리뷰되고, CI에서 수백 번 반복되는 게 존재 이유다. 이번 작업은 정반대였다. 무엇을 찾을지는 알았지만 어디서 찾을지는 몰랐고, 다섯 번 실패한 다음 여섯 번째로 넘어가는 탐색이었으며, 중간에 경로를 바꿔야 했다. 재현성이 목적이 아니라 탐색이 목적인 일이다.

그래서 지금 내 판단은 이렇다. 대체 관계가 아니라 용도가 다르다. 반복해서 같은 답을 확인해야 하면 Playwright, 한 번인데 어디를 봐야 할지 모르면 브라우저 에이전트. 8월엔 공식 문서만 보고 이 선을 못 그었는데, 실패가 다섯 번 쌓인 작업 하나를 통과시키고 나니 선이 그어졌다.

맡겨도 되는 일과 아직 아닌 일

이번 한 건을 기준으로 정리하면 이렇다.

맡겨도 괜찮았던 일

  1. API가 없어서 사람이 화면을 봐야만 하는 조사
  2. 같은 항목을 여러 계정에 반복 대조하는 지겨운 작업
  3. 절차가 두 개 이상으로 갈리는데 둘 다 끝내야 하는 일
  4. 며칠 뒤에 다시 확인해야 해서 사람이 까먹기 쉬운 일

아직 사람이 쥐고 있어야 하는 일

  1. 어떤 계정이 존재하는지 정하는 판단
  2. 본인 인증과 최종 전송 버튼
  3. 결과가 외부 심사에 달린 일의 기대치 관리
  4. 권한을 어디까지 열지 정하는 결정

경계가 생각보다 명확했다. 에이전트가 줄여준 건 반복과 누락이고, 안 줄여준 건 판단과 책임이다.

FAQ

Aside는 기존 AI 챗봇과 뭐가 다른가요?

챗봇을 브라우저에 붙인 구조가 아니라, 로그인된 사이트에서 직접 동작하는 브라우저 에이전트와 로컬 메모리, 에이전트용 비밀번호 관리자를 묶은 브라우저입니다. 통합 API 없이 실제 계정을 써서 일한다는 점이 공식 설명의 핵심입니다.

에이전트에게 내 비밀번호가 노출되나요?

공식 도움말 기준으로 에이전트는 login 동작을 쓸 수 있지만 원본 비밀번호를 받지 않습니다. 자격증명은 웹사이트에 직접 자동 입력되고, 접근 정책은 항상 허용 / 잠금 해제된 동안만 / 사용 안 함 중에서 고를 수 있습니다.

Playwright로 짠 자동화를 Aside로 옮겨도 되나요?

목적이 다릅니다. 같은 입력에서 같은 결과를 재현하고 CI에서 반복해야 하는 테스트는 Playwright가 맞습니다. 어디를 봐야 할지 모르는 상태에서 로그인된 사이트를 탐색하며 증거를 모으는 일에는 브라우저 에이전트가 맞습니다.

결제나 민감한 작업까지 자동으로 진행되나요?

공식 소개 기준으로 결제, 게시, 메시지 전송 같은 민감한 작업은 사용자 승인을 거치도록 되어 있습니다. 이번 실사용에서도 본인 인증과 최종 회신은 전부 사람이 눌렀습니다.

공식 출처

관련 글