브라우저 에이전트가 내 API 예산을 다 갉아먹었는데, 왜 그런지 이제야 알겠네

몇 주 동안 실제 웹 작업(채용 지원서 작성, 예약 흐름, 대시보드 스크래핑 등 단순 데모가 아닌 실제 작업)에 AI 에이전트를 돌려봤는데, 토큰 비용이 계속 불어나는 걸 보면서도 도대체 어디서 다 나가는 건지 정말 알 수가 없었어.

알고 보니 브라우저 루프가 완전 돈 먹는 하마인데, 아무도 이 얘기를 안 하더라고.

모든 동작 하나하나(클릭, 대기, 관찰, '오 모달창 떴네', 다시 관찰, 탭이 이상한 짓을 하네, 또 관찰)가 전부 왕복 통신이야. 각각 전부 다. 난 순진하게 모델 자체가 비싼 줄 알았는데, 아니었어. 에이전트가 페이지 어디에 있는지 계속 파악하려고 하는 그 과정이 문제였던 거야. 계속, 반복해서 말이지.

이 문제에 대해 깊게 파고들어 봤는데(잠을 잤어야 했는데, 뭐 어쨌든), 나한테 딱 와닿았던 건 스냅샷 품질이 사실상 모든 후속 과정을 결정한다는 거야. 나쁜 스냅샷 → 잘못된 클릭 → 재시도 → 더 많은 컨텍스트 → 더 많은 비용. 이게 눈에 보이지 않는 복합적인 실패의 소용돌이인데, 청구서 대시보드를 보면서 "잠깐, 이게 뭐야?" 할 때까지는 알 수가 없지.

그리고 이건 좀 뼈아픈 사실인데, 더 빠른 에이전트는 단순히 사용자 경험(UX) 문제가 아니야. 말 그대로 더 저렴해. 재시도도 적고, 관찰 루프도 적고, 복구에 낭비되는 컨텍스트도 적으니까. 직접 측정해 보기 전까지는 이걸 제대로 이해하지 못했어.

격리된 브라우저 환경이라는 것도 이제 이해가 가. 공유 세션은 완전 혼돈 그 자체거든. 탭이 이리저리 움직이고, 세션끼리 충돌하고, 에이전트는 초점을 잃고, 다시 방향 잡느라 토큰을 더 쓰고... 왜 진작 이걸 생각 못 했을까.

뭐, 이 분야를 오래 한 사람들에겐 당연한 걸지도 모르지. 하지만 이제 막 실제 웹사이트에서 에이전트를 테스트하기 시작했는데 비용이 이상하게 느껴진다면, 프롬프트를 최적화하기 전에 브라우저 런타임부터 살펴봐. 낭비가 거기 숨어 있으니까.

혹시 다른 사람들도 이런 경험 해본 적 있어?