브라우저-유즈 에이전트 비교 실험(Comet, Atlas, Browserbase)
얼마 전에도 썼듯 브라우저를 통제하는 AI 에이전트에 대한 관심이 부쩍 커졌습니다. 그래서 에이전트 몇 종을 간단한 실험으로 비교해봤어요. 기능성, 투명성, 유용성을 포함한 종합 평가를 해봤습니다.
그리고 이 작은 실험에서는 Comet의 압승이었습니다. 직접 하기 귀찮은 작은 작업에 대해, 작업의 성공 조건 및 목적을 충분히 잘 입력할 수 있다면 Comet의 에이전트를 유용하게 쓸 수 있겠습니다. 다만 다른 LLM을 통해 '되묻기' 및 '프롬프트 증강'을 한 다음 요청해야 실패가 적을 것 같아요.
요청 작업은 대략 이랬어요.
교보문고 주간 베스트셀러 목록 https://store.kyobobook.co.kr/bestseller/total/weekly 에서 첫 3개 책에 대해 각 책의 제목, 저자, 목차를 뽑아줘.
'대략'인 이유는 아주 엄밀한 실험은 아니어서 그렇습니다. 처음에는 전체 책(20개)을 요청했다가 너무 오래 걸려서 3개로 바꿨고, Atlas에서는 링크도 달라고 하는 등 조금씩 다르게 했어요. 노션 로그인이 가능했던 Comet과 Atlas는 Notion 페이지에 정리해달라고도 했었습니다.
에이전트별 상세 평가는 다음과 같습니다.
🥇 Comet: 4.5점
기능성: 5점
주어진 URL에 접근, 목록에서 상세 페이지로 이동, 제목/저자/목차 추출, 노션으로 이동, 노션 페이지 생성, 노션 페이지 작성 모두 성공했습니다. 생각보다 너무 잘 해서 더 할 말이 없네요.
투명성: 4점
작업 도중에 사고 과정이 모두 나오고(영어이긴 했지만), 브라우저 동작도 다 볼 수 있었습니다. 그러나 작업 완료된 후 과정을 다시 보려니 확인하기가 매우 불편하더군요. 동작 영상 녹화까지 기대하는 건 좀 무리겠지만, 중간중간 스크린샷이라도 남아있었으면 어땠을까 싶네요. 그리고 얼마나 오랫동안 동작했는지도 나오지 않았습니다.
(특히 브라우저-유즈 에이전트 초창기에) 더 유용하게 쓰려면 내 명령에 의해 에이전트가 어떻게, 얼마나 오랫동안 동작했는지를 이해하는 게 필수라고 생각합니다. 그래야 더 좋은 명령을 내릴 수 있으니까요. 그래서 이부분은 아쉬웠습니다.
그리고 이 에이전트를 사용하는 데 얼마나 비용이 들어갔는지(예: 소모된 크레딧, 내게 주어진 몇 번/몇 분의 호출 중 얼마나 썼는지 등)를 알기가 어렵다는 것도 아쉬운 부분이었어요. 사실 Comet의 AI 에이전트 자체 가격도 잘 못 찾겠더라고요.
유용성을 고려한 종합 평가: 4.5점
Comet은 Chrome 브라우저에서 내 쿠키와 온갖 정보를 다 가져감으로써, 제가 작업했던 서비스들에 대한 로그인이 이미 다 되어 있었습니다. 그래서 '에이전트'로서 일을 시키기에는 더 편하긴 했는데 한편으로는 섬뜩하기도 하더군요.
Comet이 노션 페이지에 정리해준 내용은, 제가 요구한대로 기입되긴 했으나 포맷이 아주 보기 좋진 않았습니다. 링크는 요청 안했지만 알아서 넣어줄 수 있었을까, 하는 아쉬움도 있었어요. 이 정보들을 정리하는 목적을 명시했으면 해줬을까? 하는 생각도 들었습니다.
아무튼 직접 하기 귀찮은 작은 작업에 대해, 작업의 성공 조건 및 목적을 충분히 잘 입력할 수 있다면 유용하게 쓸 수 있겠습니다. 다른 LLM을 통해 '되묻기' 및 '프롬프트 증강'을 한 다음 요청하는 게 좋아 보입니다.
참고로 첫 3개가 아닌, 20개 전부(베스트셀러 페이지의 기본 페이지네이션)에 대한 정리를 요청했을 때는 컨텍스트 길이의 제한 때문이었는지 모르겠지만 15개만 해줬습니다. 그래서 '에이전트가 안정적으로 일할 수 있는 길이'에 대한 감을 잡는 게 중요해보였어요.
한편, '20개를 전부 정리 후 한번에 노션 페이지 작성' 자체가 그리 좋지 않은 워크플로우였다는 생각도 들더군요. 이상적으로는, 이렇게 되면 어땠을까 싶어요.
- 브라우저-유즈 에이전트가 오케스트레이터로서 필요한 에이전트들을 설계한다.
- 서브에이전트 1: 목록에서 상세 페이지로 이동해서 내용을 추출한다
- 서브에이전트 2: 추출한 내용을 노션 페이지 1개에 넣는다
- 20개의 병렬 세션을 띄워서 서브에이전트 1 - 2 순서로 돌게 한다.
- 오케스트레이터 에이전트가 20개의 페이지를 한 페이지에 순차적으로 합치고, 임시로 만들었던 페이지들은 삭제한다.
- 전체 포맷팅을 보기 좋게 변경한다.
🥈ChatGPT Atlas: 3.5점
기능성: 3점
- 주어진 URL에 접근: 성공했으나, 교보문고 웹페이지 첫 접근시 나오는 팝업을 처리할 방법을 스스로 결정하지 못했습니다. (다른 에이전트들은 이 문제가 없었거나, 스스로 처리했습니다)
- 목록에서 상세 페이지로 이동: 성공했으나 의외로 상당히 헤맸습니다. (Comet보다 훨씬 느렸습니다) 게다가 주간 베스트 페이지에서 1/2/3위가 아닌 1/3/4위를 추출했습니다. 목록 페이지에서 스크롤을 과하게 내린 것 같더군요.
- 제목/저자/목차 추출: 결과적으로는 성공하긴 했는데, 위와 마찬가지로 상당히 헤맸고 자주 오류가 떴습니다. (Comet은 훨씬 쉽게/빠르게 해냈습니다) DOM을 파싱해서 찾아내는 능력이 상대적으로 떨어지는 느낌이었어요.
- 노션으로 이동, 노션 페이지 생성: 성공했습니다. (노션 로그인은 제가 미리 해줬습니다)
- 노션 페이지 작성: 실패했습니다. 정리 자체는 예쁘게 해줬는데, 재미있게도 노션 페이지 자체가 아니라, 하단의 '노션 AI용 Textarea' 안에다 정리한 내용을 넣어뒀더라고요.
투명성: 4.5점
작업 도중에는 Comet과 유사하게 사고 과정, 브라우저 동작 모두 볼 수 있었습니다. 그리고 작업 완료 후에도 어떤 동작을 했었는지 모두 쉽게 확인할 수 있었어요. 얼마나 오래 걸렸는지도 나왔는데, 각 스텝별로 얼마나 걸렸는지까지 나왔으면 더 좋았겠다 싶더군요.
Comet보다는 훨씬 좋은 인터페이스였지만, 역시나 스크린샷이 생기길 바라고 있습니다. 비용에 대한 정보는 Comet과 마찬가지로 알 수 없었습니다.
유용성을 고려한 종합 평가: 3.5점
직접 로그인을 해야 했다는 점, 팝업을 처리하지 못한 점, 결과적으로 최종 동작을 성공하지 못한 점들이 아쉬웠어요. 속도도 훨씬 느렸고요. 하지만 인터페이스 측면에서는 Comet보다 높은 점수를 주고 싶습니다. (노션에 들어가진 못했지만) 최종적으로 정리해준 내용도 더 보기 좋았고요.
앞으로가 더 기대됩니다만, 당분간은 Comet 위주로 쓸 것 같습니다. Atlas가 똑똑해지는 게 빠를지, Comet의 인터페이스가 좋아지는 게 빠를지 모르겠네요.
(탈락) Gemini Computer Use (Browserbase Demo)
컴퓨터-유즈는 그 이름에서 알 수 있듯 브라우저-유즈보다 좀 더 큰 개념입니다. AI 에이전트가 웹브라우저를 통제하는 걸 넘어, 컴퓨터의 모든 앱을 통제하겠다는 거죠. 물론 현재 Gemini가 공개한 모델은 웹에 국한된 것 같지만, 비전은 더 크게 보고 있는 것 같습니다.
The Gemini 2.5 Computer Use model is primarily optimized for web browsers, but also demonstrates strong promise for mobile UI control tasks. It is not yet optimized for desktop OS-level control.
Gemini가 위 블로그에서 공개한 무료 데모로도 유사한 테스트를 해봤습니다만 완전 실패했습니다. 이건 무료 모델의 한계일 수도 있고, Browserbase 가 잘못 구현한 것일 수도 있지만 아무튼 목차를 전혀 찾지 못하더군요. DOM을 가져오는 게 아니라 '스크롤을 내려서 화면 내에서 찾기'만 반복하다가 주어진 5분의 실행 시간을 넘겨버렸습니다. 투명성 측면에서는 아주 나쁘진 않았지만요.
(가능성) Opal
브라우저-유즈 에이전트들과는 좀 성격이 다르지만 Opal도 시험해봤습니다. 하단 텍스트 창에 유사한 요구사항을 넣었고, 노션 대신 Google Spreadsheet에 저장해달라고 했어요. 그랬더니 영어로 죄다 바꿔서 노드 몇 개를 알아서 만들어줬습니다.
그런데 구현된 동작이 제가 원하는 바와 완전 다르더군요. 상세 페이지로 들어가질 않고 주어진 목록 페이지 내에서만 찾는 동작이었습니다. 웹페이지의 내용을 가져오는 것도 브라우저를 통하는 게 아니라 fetch 같은 걸로 가져오는 느낌이었고요.
하지만 각 Tool Call 별로 얼마나 오래 걸렸는지, 어떤 모델을 사용할지, 어떤 입력을 받을지 등을 좀 더 '프로그래밍'할 수 있다는 면에서는 좋았습니다. Code Execution 툴을 통해 좀 더 복잡한 작업도 안정적으로 쓸 수 있겠다는 생각도 들었어요.
하지만 정작 (위 Comet에서 쓴 것처럼) 병렬로 여러 에이전트가 돌게 하는 식으로는, 제가 못하는 건지 잘 못 하겠더군요. 그리고 이렇게 할 바에는 그냥 바이브 코딩하는 게 훨씬 편하겠다는 생각도 했습니다. 뭔가 가능성은 보이는데 아직 멀었다...는 느낌? 그래도 재미는 있었습니다.
Member discussion