[브라우저 자동화] 비전 기반 자동화는 느렸다: 브라우저 자동화 도구 2개를 직접 비교해봤습니다

📝 한줄 요약

지난주에는 Claude Chrome 확장앱으로 채용 후보 검토 자동화를 성공시켰습니다. 이번에는 그 다음 단계로, 더 빠르고 더 신뢰도 높게 쓸 수 있는 방법이 있는지 gstack browse와 agent-browser를 실제로 붙여보며 비교했습니다.

🎯 이런 분들께 도움돼요

• 브라우저 자동화를 업무에 붙여보고 싶은 비개발자

• 반복적인 운영 업무를 AI로 줄이고 싶은 실무자

• 노코드 방식으로도 어디까지 자동화할 수 있는지 궁금한 사람

😫 문제 상황 (Before)

사실 이 시도는 완전히 처음은 아니었습니다. 지난주에 저는 Claude Chrome 확장앱을 활용해 채용 후보 검토 자동화를 한 번 성공시켰습니다. 그 경험은 이미 GPters에 정리해두었습니다.

• 지난 글: 채용 플랫폼에서 200명의 채용 후보 검토부터 제안 발송까지, Claude Code가 다 하게 만들기

문제는 그 다음이었습니다. 돌아가긴 했지만, 계속 쓰기에는 두 가지가 마음에 걸렸습니다.

첫째, 속도였습니다. Claude Chrome 확장앱은 결국 화면을 비전으로 읽으면서 판단하는 방식이라 토큰 소모가 크고, 반응도 느린 편이었습니다. “된다”는 건 확인했지만, 실무에서 계속 돌리기엔 답답한 순간이 있었습니다.

둘째, 신뢰성을 어떻게 봐야 할지가 막막했습니다. 한두 번 성공했다고 해서 곧바로 “이제 실전에 써도 된다”라고 말하기는 어려웠습니다. 어떤 상황에서 잘 되고, 어디서 꼬이고, 얼마나 제어 가능한지 기준이 필요했습니다.

게다가 채용 사이트는 민감합니다. 자동화가 너무 기계적으로 보이면 밴당할 가능성도 있습니다. 그래서 이번에는 단순히 자동화 성공 여부만 보는 게 아니라, 더 빠르고 더 프로그램적으로 제어할 수 있는 방식이 있는지, 그리고 사람처럼 동작하게 만들 방법까지 같이 확인해보기로 했습니다.

🛠️ 사용한 도구

• 도구명: gstack browse, agent-browser, Codex CLI

• 모델: GPT-5.4

• 특이사항: 지난 실험의 Claude Chrome 확장앱 사례를 기준점으로 삼고, 이번에는 스크립트 기반 브라우저 자동화를 직접 비교했습니다.

🔧 작업 과정

확장앱이 이미 되는데, 왜 굳이 다시 해봤을까

지난 실험에서 저는 Claude Chrome 확장앱으로 후보 검토 자동화를 성공했습니다.

그런데 실제 업무에 붙여보려면 질문이 달라집니다. 단순히 되느냐가 아니라, 얼마나 빠른지, 얼마나 안정적인지, 어디까지 내가 통제할 수 있는지가 더 중요해집니다. 이번에는 바로 그 기준으로 다른 도구를 보기 시작했습니다.

제가 처음 던진 요청은 꽤 단순했습니다.

browse CLI 설치

https://github.com/garrytan/gstack 의 스킬들을 AI Tool Kit에 설치해줘

여기서 AI Tool Kit은 지니파이 사내에서 쓰는 스킬 공유 도구입니다. 설치해두면 어떤 프로젝트에서든 가져와서 쓸 수 있거든요.

agent-browser 설치

https://github.com/vercel-labs/agent-browser 에 있는 agent-browser 설치하고 인스톨해줘

이 단계에서 먼저 한 일은 도구를 실제로 깔고, 로컬 환경에서 바로 실행되는지 확인하는 것이었습니다. “좋아 보이는 툴”과 “실제로 지금 내 업무 환경에서 돌아가는 툴”은 완전히 다르기 때문입니다.

여기서 바로 느낀 차이가 있었습니다. Claude Chrome 확장앱은 화면을 보고 판단하는 느낌이 강했다면, 이번에 본 도구들은 훨씬 더 스크립트처럼 동작했습니다. 같은 브라우저 자동화라도 체감 속도부터 달랐습니다.

로그인은 AI가 다 못 해도 된다

이번 실험에서 가장 인상적이었던 지점은 로그인 처리 방식이었습니다.

gstack browse는 기본적으로 헤드리스 브라우저 중심이라 로그인 구간이 꽤 까다로웠습니다. 이미 다른 브라우저에 살아 있는 로그인 쿠키를 가져와 재사용하는 식으로 풀어야 했고, 이 과정은 생각보다 손이 많이 갔습니다.

반면 agent-browser는 화면이 보이는 브라우저를 띄울 수 있었습니다. 그래서 완전 자동화를 고집할 필요가 없었습니다. 로그인만 제가 직접 하고, 그 다음 반복 작업은 다시 도구에게 넘기면 됐습니다.

그 흐름은 실제로 이렇게 진행했습니다.

이 agent-browser를 사용해서 career.rememberapp.co.kr 에 접속해서 인재 검색 탭에 처음 나오는 20개 프로필을 profiels-agent-browser.md 파일로 저장해줘.

이렇게 명령하니, Agent-browser는 시도를 하다가 로그인이 필요한 것 깨닫고, 브라우저를 띄워줄테니 (그전까지는 headless라서 브라우저 안보였음), 로그인을 해 달라고 하더라구요.

그래서 로그인을 완료해주었습니다.

이 순간 “아, 실무에서는 이 방식이 훨씬 현실적이겠다”는 생각이 들었습니다. 모든 걸 완전 자동으로 만들지 않아도 됩니다. 사람이 인증만 맡고, 그 다음부터는 AI가 반복 작업을 이어받는 구조면 이미 충분히 강력합니다.

클릭이 불안정하면, 방식 자체를 바꾸면 된다

이번 작업이 처음부터 매끈했던 건 아닙니다. 첫 결과는 제가 기대한 것과 달랐습니다. 프로필을 모으긴 했는데, 상세 페이지가 아니라 목록에 보이는 요약 정보만 저장된 상태였습니다.

제가 다시 요청한 내용도 아주 직접적이었습니다.

아까 agent-browser로 profiels-agent-browser.md 에 데이터를 모았는데, 각 인재를 클릭한 상세 페이지의 데이터를 가져왔어야했는데 그냥 목록의 데이터만 가져왔어! 인재 클릭 후 보여지는 세부 데이터를 가져와서 다시 써줘.

여기서 좋았던 점은, “실패했으니 끝”이 아니라 자동화 방식을 바꿀 수 있었다는 점입니다. 카드 클릭이 불안정하면, 카드에서 상세 링크를 추출한 뒤 상세 페이지를 순서대로 여는 방식으로 바꾸면 됩니다.

결국 이번 실험은 단순한 클릭 자동화가 아니라, 상세 페이지 기준으로 자기소개, 직무, 전문 분야·스킬, 경력사항, 학력사항, 자격증, 선호하는 제안 조건까지 다시 구조화하는 쪽으로 발전했습니다. 이 지점에서 “AI가 브라우저를 만질 수 있다”를 넘어, “실제 업무 데이터를 다시 쓸 수 있는 문서 형태로 정리할 수 있다”는 쪽으로 넘어갔습니다.

속도만 볼 게 아니라, 밴 리스크까지 같이 봐야 했다

이번에 제가 일부러 같이 본 건 “사람처럼 보이게 만들 수 있나”였습니다.

채용 사이트는 일반 서비스보다 자동화에 민감할 수 있습니다. 너무 기계적으로 움직이면 밴당할 가능성을 무시하기 어렵습니다. 그래서 이번 실험에서는 단순 수집 성공 여부뿐 아니라, 사람처럼 자연스러운 딜레이를 넣는 기능이 있는지도 따로 확인했습니다.

제가 던진 질문은 이랬습니다.

agent-browser, browse CLI 툴을 써서 브라우징을 할 때 (헤드리스/헤드 모두), 이간이 하듯이 자연스러운 딜레이를 넣는 기능이 따로 있는지 확인해볼래?

결론은 의외로 단순했습니다. 두 도구 모두 “사람처럼 자연스럽게 보이게 해주는 전용 옵션”이 아주 잘 갖춰져 있지는 않았습니다. 대신 wait를 수동으로 넣거나, 입력을 문자 단위로 처리하는 식의 우회는 가능했습니다.

이 과정에서 더 분명해진 건, 자동화 도구를 볼 때 “되냐 안 되냐”만 보면 안 된다는 점입니다. 속도, 신뢰성, 제어 가능성, 그리고 밴 리스크까지 같이 봐야 실제 업무에 쓸 수 있습니다.

✅ 결과 (After)

Before vs After

결과물

• gstack browse 기반 수집 결과: profiles.md

• agent-browser 기반 상세 수집 결과: profiels-agent-browser.md

• 재사용용 수집 스크립트: collect_remember_profiles.mjs

이번 실험의 가장 큰 결과는, Claude Chrome 확장앱보다 더 프로그램적으로 제어되고 더 신뢰도 높게 다룰 수 있는 방식을 찾기 시작했다는 점입니다. 아직 완성은 아니지만, “실전에 쓸 자동화”로 가기 위한 기준이 훨씬 선명해졌습니다.

💬 이 과정에서 배운 AI 활용 팁

효과적이었던 것

1. 자동화 도구는 “성공 여부”만 보지 말고 속도, 신뢰성, 제어 가능성, 밴 리스크까지 같이 비교해야 합니다.

2. 로그인처럼 막히는 구간은 사람이 맡고, 그 이후 반복 작업만 자동화하는 식으로 역할을 나누면 실무 적용이 훨씬 쉬워집니다.

이렇게 하면 안 돼요

1. 한 번 성공했다고 바로 실전에 투입하면 안 됩니다. 특히 채용 사이트처럼 민감한 서비스는 검증 기준이 더 필요합니다.

2. 목록 화면만 보고 “수집됐다”고 판단하면 안 됩니다. 실제로 필요한 정보가 상세 페이지에 있는지 꼭 다시 확인해야 합니다.

🌍 다른 업무에 적용한다면?

이 경험은 채용 업무에만 국한되지 않습니다. 로그인 후 웹서비스 안에서 사람이 반복적으로 열고, 확인하고, 정리하고, 문서화하는 업무라면 비슷한 구조로 바꿔볼 수 있습니다.

예를 들어 영업 리드 검토, 고객 문의 분류, 파트너 리스트 점검, 운영 대시보드 확인 같은 작업도 같은 패턴입니다. 특히 “사람이 초반 인증만 하고, 그 다음은 자동화가 이어받는 구조”는 꽤 많은 업무에 적용 가능합니다.

🚀 앞으로의 계획

지난 글에서는 서브에이전트를 써서 200명을 동시에 검토하는 흐름까지 갔지만, 이번에 새로 비교한 도구들로는 아직 그 수준까지 확장해보지는 못했습니다.

다음 목표는 여기까지입니다. 이번에 검증한 더 프로그램적인 방식으로도, 예전처럼 200명 단위 병렬 검토까지 다시 연결해보는 것입니다. 그 단계까지 가면 단순 실험이 아니라, 실제 채용 운영에 바로 쓸 수 있는 자동화 방안이 완성된다고 보고 있습니다.