브라우저 자동화를 붙이고 나니 에이전트 봇이 할 수 있는 일이 꽤 많아졌다. 브라우저를 열고, 페이지를 읽고, 다음에 뭘 해야 할지 추론해서 버튼을 누른다. 네이버 메일을 읽거나, 쿠폰을 등록하는 식의 귀찮은 일들을 맡길 수 있게 됐다.
리서치 쪽에서도 꽤 쓸만했다. 개인적으로는 코덱스보다 GPT Pro 쪽 결과물이 더 마음에 드는 경우가 많다. 브라우저 자동화를 이용하면 에이전트 봇이 GPT Pro를 브라우저에서 직접 열고, 결과물을 가져와 다시 가공하는 식의 흐름도 가능하다. 결국 브라우저를 다룰 수 있다는 건, 다른 웹 기반 AI 서비스까지 내 에이전트의 도구처럼 엮을 수 있다는 뜻이었다.
그런데 실제로 계속 써보니 속도 문제가 눈에 밟혔다. AI가 현재 페이지를 보고 매번 다음 액션을 추론하는 구조라 유연하긴 한데, 그만큼 느리다. 일반적인 리서치나 정리 작업은 괜찮다. 어차피 내가 직접 해도 귀찮은 일이고, 몇 분 늦어져도 큰 문제는 없다. 하지만 예약처럼 몇 초 차이로 결과가 달라지는 작업에서는 이 느림이 꽤 치명적이었다.
그래서 이번에는 브라우저 자동화 위에 브라우저 매크로 기능을 붙였다. 에이전트가 모든 순간을 새로 생각하게 두는 대신, 내가 직접 성공한 경로를 한 번 녹화해두고 필요할 때 그대로 재생하게 만드는 기능이다. 처음부터 대단한 기능을 붙인다기보다는, 이미 만들었던 브라우저 자동화의 빈틈을 메우는 작업에 가까웠다.
직접 지나간 경로를 저장해두고 다시 재생하는 방식
브라우저 자동화는 편하지만 느림
브라우저 자동화의 기본 흐름은 단순하다. 현재 페이지를 읽고, 목표와 비교한 뒤, 다음 액션을 결정한다. 그리고 클릭하거나 입력한 뒤 다시 페이지를 읽는다. 목표를 달성할 때까지 이 과정을 반복한다.
말로 적으면 간단한데 실제로는 꽤 많은 추론이 들어간다. 예를 들어 네이버 메일 제목을 읽는 작업만 해도, 네이버에 접속하고, 메일 서비스로 이동할 버튼을 찾고, 로그인이 필요하면 로그인 세션을 요청하고, 다시 메일 페이지로 들어간 뒤 리스트에서 제목을 추출해야 한다. 사람이 하면 몇 번 클릭하고 끝날 일이지만, 에이전트에게는 각 단계가 전부 판단 지점이다.
이 방식의 장점은 분명하다. 정해진 좌표를 누르는 매크로가 아니라 현재 화면을 보고 판단하므로, 사이트 구조가 조금 바뀌어도 대응할 여지가 있다. 예상하지 못한 페이지가 나와도 어느 정도는 스스로 다시 길을 찾을 수 있다. 문제는 그 유연함의 비용이 속도로 돌아온다는 점이다. 에이전트가 똑똑하게 행동하려면 매번 생각해야 하고, 그 생각에는 시간이 든다.
경로 캐싱으로 한 번 줄이긴 했다
이전 브라우저 자동화 작업에서 이 문제를 줄이기 위해 네비게이션 경로 캐싱을 붙였다. 에이전트가 어떤 페이지까지 가는 데 성공하면 그 경로를 저장해두고, 다음에 비슷한 요청이 들어왔을 때 먼저 그 경로를 재사용하는 방식이다.
효과는 꽤 좋았다. 처음에는 30분 가까이 걸리던 작업이 같은 요청을 다시 했을 때 3분 정도로 줄어들기도 했다. 매번 처음부터 페이지를 읽고 길을 찾지 않아도 되니 토큰도 덜 쓰고, 체감 속도도 확실히 나아졌다. 이때까지만 해도 브라우저 자동화가 제법 실사용 가능한 수준으로 올라왔다고 생각했다.
하지만 경로 캐싱은 어디까지나 에이전트 자동화를 보조하는 장치였다. 저장된 경로를 쓸지 말지도 판단해야 하고, 실행 전후로 상태도 확인해야 한다. 전처리와 후처리도 남아 있다. 캐싱된 경로가 실패하면 다시 추론 모드로 들어가야 하므로, 빨라지긴 했지만 여전히 모델 추론 기반 자동화의 안쪽에 있었다.
일반적인 작업에는 이 정도면 충분했다. 그런데 예약처럼 정해진 시간에 빠르게 눌러야 하는 작업에서는 여전히 애매했다. 이 경우에는 유연함보다 속도가 더 중요했다.
처음 길을 찾는 것과 이미 찾은 길을 다시 가는 것은 다른 문제다
예약 작업에는 매크로가 더 맞았다
브라우저 자동화를 붙이면서 제일 기대했던 것 중 하나가 예약 작업이었다. 내가 정해진 시간에 기다리고 있다가 버튼을 누르는 게 아니라, 홈서버가 알아서 브라우저를 열고 예약을 잡아주면 좋겠다고 생각했다. 이건 개인 AI 에이전트를 만드는 입장에서 꽤 매력적인 사용 사례였다.
그런데 실제로 만들어보니 AI 자동화는 이런 작업과 잘 맞지 않았다. 예약 버튼이 열리는 순간에는 똑똑하게 판단하는 것보다 빨리 누르는 게 중요하다. 이미 어디를 눌러야 하는지 알고 있다면 굳이 다시 생각할 필요가 없다. 오히려 그 생각이 방해가 된다.
이 지점에서 브라우저 매크로가 필요해졌다. AI 브라우저 자동화는 낯선 페이지에서 목표까지 가는 길을 찾는 데 강하고, 브라우저 매크로는 이미 아는 경로를 빠르게 반복하는 데 강하다. 경로 캐싱은 그 중간쯤에 있다. 처음에는 브라우저 자동화만 잘 만들면 다 해결될 줄 알았는데, 만들수록 모든 것을 AI 추론으로 처리하는 게 정답은 아니라는 생각이 들었다.
결국 예약 작업은 매크로 쪽이 더 잘 맞았다. 에이전트가 처음 길을 찾는 건 좋다. 하지만 한 번 찾은 길을 다시 갈 때는 매번 생각하지 말고, 그냥 빠르게 재생하는 편이 낫다.
브라우저 매크로 기능 추가
구현 방식 자체는 어렵지 않았다. 이미 브라우저 자동화 쪽에 이동 경로를 저장하고 재사용하는 구조가 있었기 때문이다. 여기에 내가 직접 브라우저를 조작한 기록을 저장하고, 나중에 그대로 재생할 수 있게 만들면 된다.
사용 흐름도 자연스럽게 잡혔다. 에이전트 봇에게 매크로 녹화해줘라고 요청하면 noVNC 원격 브라우저 링크를 보내준다. 나는 그 브라우저에서 직접 클릭하고 입력하면서 원하는 경로를 수행한다. 그러면 그 액션들이 매크로로 저장되고, 나중에 매크로 재생해줘라고 하면 저장된 내용을 다시 실행한다.
코덱스에게 현재 구조를 설명하고 구현해달라고 하니 기능 자체는 금방 붙었다. 바이브 코딩의 장점이 이런 곳에서 나온다. 이미 만들어둔 구조가 있고, 원하는 동작이 명확하면 생각보다 빠르게 기능이 들어간다. 테스트해보니 기본 동작도 잘 됐다. 직접 녹화한 경로가 그대로 재생되는 걸 보니 꽤 뿌듯했다.
무엇보다 마음에 든 부분은, 이제 에이전트가 매번 "이 버튼인가?" 하고 고민하지 않아도 된다는 점이었다. 내가 맞는 버튼을 한 번 눌러서 길을 만들어두면 된다. 그 뒤로는 에이전트가 길을 찾는 게 아니라, 만들어둔 길을 따라간다.
하이브리드로도 속도 문제는 남음
브라우저 매크로를 붙였다고 해서 AI 자동화가 필요 없어지는 건 아니다. 오히려 둘을 같이 써야 쓸만해진다. 매크로는 빠르지만 약하다. 페이지 구조가 바뀌거나, 팝업이 뜨거나, 버튼 위치가 달라지면 쉽게 깨질 수 있다. 반대로 AI 자동화는 느리지만 상황을 보고 다시 판단할 수 있다.
그래서 목표 달성만 놓고 보면 둘을 섞는 방식이 제일 현실적이다. 먼저 저장된 매크로를 빠르게 재생하고, 중간에 막히거나 예상과 다른 화면이 나오면 AI 자동화로 넘긴다. AI가 새 경로를 찾아 성공하면 그걸 다시 저장할 수도 있다. 이렇게 하면 단순히 실패로 끝나는 경우는 줄일 수 있다.
다만 이건 어디까지나 안정성을 높이는 방향이지, 속도 문제를 완전히 해결하는 방식은 아니다. 예약처럼 정해진 순간에 빠르게 눌러야 하는 작업에서 매크로가 실패하고 AI 자동화로 넘어가는 순간, 이미 속도 싸움에서는 늦을 수 있다. 그러니까 하이브리드는 보험에 가깝다. 목표 달성 가능성은 올려주지만, 속도가 중요한 구간의 본질적인 해결책은 아니다.
예약처럼 시간이 중요한 작업은 매크로 재생 쪽이 더 어울린다
아직 아쉬운 부분
기능은 붙었지만 아직 사용성이 완전히 마음에 들진 않는다. 가장 큰 문제는 녹화 기반이라는 점이다. 내가 직접 한 번 해볼 수 있는 작업은 매크로로 만들 수 있지만, 아직 열리지 않은 예약 페이지처럼 미리 시뮬레이션하기 어려운 경우에는 녹화 자체가 어렵다. 미리 연습할 수 있는 서비스라면 괜찮지만, 그렇지 않은 곳에서는 한계가 있다.
자연어 요청의 전처리 시간도 조금 거슬린다. 매크로 재생해줘라고 말하면 에이전트는 어떤 기능을 써야 하는지, 어떤 매크로를 골라야 하는지 다시 판단한다. 기능이 많아질수록 이 앞단의 추론 시간이 조금씩 늘어난다. 명령어로 바로 실행하게 만들 수는 있지만, 그러면 사용감이 별로다. 자연어로 딸깍하려고 만든 봇인데 명령어를 외우고 싶진 않다.
그래서 다음에는 별도 웹 화면이 필요할 것 같다. 저장된 매크로 목록을 보고, 바로 재생 버튼을 누르거나, 특정 시간에 실행되도록 예약을 걸 수 있는 화면이다. 텔레그램은 자연어 요청용으로 두고, 빠른 실행과 관리는 웹 UI에서 하는 식이 더 좋아 보인다. 특히 예약 기능과 엮으려면 결국 이쪽이 더 편할 것 같다.