바이브 코딩으로 나만의 오픈 클로 만들기 – 자연어 리마인더와 옵시디언 데일리 노트 연동을 붙이고 나니 텔레그램 AI 에이전트 봇이 제법 쓸 만해졌다. 여기서 브라우저 자동화까지 올라가면 할 수 있는 일이 단번에 넓어진다. 잘만 붙이면 스케줄링과 연결해서 지금 바로 하기 어려운 예약 작업도 미리 걸어둘 수 있고, 홈서버가 정해진 시간에 알아서 처리하게 만들 수도 있다.
이번 글에서는 그 브라우저 자동화를 붙이면서 맞닥뜨린 문제들을 정리해보려 한다. 핵심은 세 가지였다. 로그인 보안을 어떻게 처리할 것인지, 에이전트 추론 중심 자동화를 어떻게 굴릴 것인지, 그리고 그 과정에서 폭발하는 토큰 사용량을 어떻게 감당할 것인지다.
에이전트의 브라우저 자동화, 무엇을 만들고 싶었나
내가 만들고 싶었던 것은 단순한 매크로가 아니었다. 미리 정해둔 클릭 순서를 반복하는 스크립트가 아니라, 에이전트가 현재 웹 페이지를 직접 읽고 지금 무엇을 해야 하는지 판단한 뒤 다음 행동을 선택하는 자동화였다. 그래야 사이트 구조가 조금 바뀌거나 예상하지 못한 화면이 튀어나와도 어느 정도는 스스로 대응할 수 있다.
처음 구현은 이 이상과는 거리가 멀었다. 웹 페이지를 보고 어떤 행동을 해야 하는지 분류하는 로직 대부분이 하드코딩된 기계적 규칙에 기대고 있었기 때문이다. 이런 방식은 당장은 빨리 돌아가도 예외가 늘어날수록 사람이 계속 규칙을 추가하고 디버깅해야 한다. 자동화라고 부르기엔 너무 손이 많이 간다.
그런데 에이전트에게 로그를 읽게 하며 디버깅하던 중 흥미로운 점을 확인했다. 이미 에이전트는 페이지 상태를 보고 다음 행동을 어느 정도 추론할 수 있었다. 그렇다면 규칙을 더 덧대는 대신, 에이전트의 추론 능력 자체를 자동화의 중심에 놓는 편이 낫지 않을까. 방향은 그쪽으로 바뀌었다.
그리고 그렇게 방향을 정하자마자, 가장 먼저 해결해야 할 현실적인 문제가 눈앞에 나타났다. 로그인이다.
기계적 규칙이 아닌 추론으로 자동화
브라우저 자동화의 첫 번째 벽, 로그인 보안
브라우저 자동화를 구현하면서 가장 먼저 부딪힌 문제는 로그인이었다. 로그인을 자동화하려면 결국 아이디와 비밀번호를 다뤄야 한다. 그런데 그 정보를 텔레그램이나 에이전트 입력 경로로 흘려보내는 순간, 아무리 편해 보여도 보안 관점에서는 바로 탈락이다. 비밀번호는 무엇보다 흔적이 남지 않는 쪽으로 다뤄야 한다.
오픈 클로는 미리 로그인된 브라우저 프로필을 재사용하는 방식을 쓴다고 한다. 비밀번호를 직접 전달하지 않아도 되니 확실히 한 단계 나아간 방식이다. 다만 이 접근도 완전히 마음에 들지는 않았다. 자동화 전에 원격으로 접속해 브라우저 프로필을 준비해야 하는 번거로움이 있고, 로그인된 프로필 자체가 남아 있으면 그 안의 세션 정보가 또 다른 공격 지점이 될 수 있기 때문이다.
암호화된 아이디·비밀번호 파일은 왜 버렸나
처음 떠올린 아이디어는 서버에 암호화된 자격 증명 파일을 두고, 필요할 때만 내가 가진 키로 복호화해서 쓰는 방식이었다. 겉보기에는 그럴듯하다. 비밀번호를 평문으로 남기지 않고, 필요할 때만 잠깐 꺼내 쓰는 셈이니까.
하지만 보안 관점에서 따져보면 여전히 찜찜한 구석이 많았다. 결국 비밀번호가 서버 어딘가에 저장된다는 사실은 변하지 않고, 복호화 키와 함께 탈취되면 한 번에 무너진다. 게다가 브라우저 자동화가 실행되는 동안에는 복호화된 정보가 메모리에 남게 된다. 위험을 줄이는 수준이지, 근본적인 해결은 아니었다.
noVNC 원격 브라우저로 로그인 세션만 남기기
결국 비밀번호를 어떤 형태로든 서버에 저장하는 방식은 포기했다. 여기에 2FA, 캡챠, 소셜 로그인처럼 사이트마다 다른 인증 절차까지 생각하면, 로그인 자체를 코드로 자동화하는 건 유지보수 면에서도 답이 보이지 않았다.
그래서 접근을 완전히 바꿨다. 봇이 로그인하는 게 아니라, 서버의 브라우저를 내가 원격으로 직접 조작해서 로그인하고 그 세션만 저장하는 구조다. noVNC와 WebSockify를 이용해 서버의 Firefox 화면을 스마트폰 브라우저로 띄우고, 내가 직접 로그인한다. 로그인이 끝나면 세션 쿠키와 스토리지 상태만 남기고 브라우저는 닫는다.
이 방식의 장점은 명확하다. 비밀번호는 서버에 저장되지 않는다. 저장되는 것은 어디까지나 로그인 이후의 제한된 세션 정보뿐이다. 텔레그램 봇 토큰 같은 민감 정보도 브라우저 자식 프로세스의 환경 변수에서 제거해, 코덱스 에이전트가 실수로라도 접근하지 못하게 했다.
결과적으로 이 구조는 보안과 편의성 사이에서 가장 현실적인 타협점이 됐다. 비밀번호는 남기지 않으면서도, 오픈 클로처럼 로그인된 브라우저 프로필을 미리 수동으로 준비해둘 필요도 없어졌다.
바이브 코딩의 한계, 테스트와 회귀의 반복
로그인 문제를 정리하고 나서 본격적으로 자동화를 붙이기 시작했는데, 여기서 바이브 코딩의 한계가 꽤 선명하게 드러났다. 하나의 이슈를 해결하면 다른 곳에서 회귀가 터지고, 여러 구간에 걸친 문제를 부분적으로만 고쳐놓고는 해결됐다고 착각하는 경우도 자주 나왔다. 코드베이스가 커질수록 전체 맥락을 놓친 수정이 늘어난 것이다.
이 시점부터는 단순히 “이슈 있어, 고쳐줘”만 반복해서는 진도가 잘 나가지 않았다. 각 기능이 어떤 모듈에 책임을 가져야 하는지, 상태를 어디에서 들고 어디에서 버릴지, 요구 사항과 구조가 충돌하는 지점이 어디인지까지 사람이 직접 짚어줘야 했다. 세부 구현은 AI가 도와줄 수 있어도, 구조를 정리하고 방향을 잡는 역할은 결국 사람이 맡아야 한다는 걸 실감했다.
구조를 조금씩 바로잡자 기능은 점차 안정되기 시작했다. 그런데 이번에는 전혀 다른 비용이 눈에 띄기 시작했다. 바로 토큰 사용량이다.
하나 수정하면 하나가 무너진다
AI 에이전트 추론의 대가, 막대한 토큰 소모
테스트와 디버깅을 이어가면서 가장 크게 체감한 문제는 토큰 소모량이었다. 조금만 복잡한 사이트를 만나거나, 에이전트가 목표 페이지를 바로 찾지 못하면 추론이 계속 반복됐다. 현재 화면을 읽고, 다음 행동을 고르고, 실패하면 다시 판단하는 과정을 거치는 동안 토큰이 무섭게 녹아내렸다.
문제는 한 번의 실패가 다음 시도에 깔끔하게 반영되지 않는다는 점이었다. 연속성이 약한 세션에서는 이전에 했던 잘못된 행동을 다시 반복하는 경우가 있었고, 그 상태로 제한 횟수까지 재시도하면 토큰만 잔뜩 태우고 끝나기 일쑤였다.
자동화 테스트 한 번에 주간 사용량의 3%가 날아간 적도 있었다. 이쯤 되니 기술적으로 되느냐보다, 이걸 계속 굴릴 수 있느냐가 더 큰 문제가 됐다. 관련해서는 [[바닥나버린 코덱스 주간 사용량]]에도 따로 적어두었다.
녹아내리는 코덱스 사용량
네비게이션 경로 캐싱으로 토큰 절약하기
토큰이 이렇게 빠져나가는 원인을 따져보니 답은 분명했다. 에이전트가 매번 처음부터 페이지를 읽고 추론하니, 이미 성공한 적 있는 작업도 늘 새로 길을 찾고 있었던 것이다.
그래서 붙인 게 네비게이션 경로 캐싱이다. 특정 사이트에서 원하는 페이지까지 도달하는 클릭 경로가 한 번 성공하면, 그 경로를 저장해둔다. 다음에 비슷한 요청이 들어오면 처음부터 추론을 시작하는 대신, 캐싱된 경로를 먼저 시도한다. 그리고 그 경로가 실패했을 때만 다시 추론 모드로 돌아간다.
효과는 꽤 확실했다. 같은 작업을 반복할수록 추론 횟수가 크게 줄었고, 그만큼 토큰 소모도 눈에 띄게 내려갔다. 물론 사이트가 UI를 바꾸면 저장된 경로는 금방 깨질 수 있다. 그래도 이 방식은 괜찮다. 실패하면 다시 추론해서 새 경로를 캐싱하면 되기 때문이다. 늘 처음부터 헤매는 구조보다 훨씬 실용적이다.
마치며
코덱스의 주간 사용량을 거의 그대로 쏟아붓다시피 하며 일주일 내내 테스트, 디버깅, 개선을 반복한 끝에 이제는 그럭저럭 실사용 가능한 브라우저 자동화를 만들 수 있었다. 지금은 네이버를 통해 자주 가는 미용실 예약을 잡거나, 복권을 구매하거나, 브라우저에서 GPT Pro로 내용을 분석하는 일까지 제법 자연스럽게 해낸다. 이런 모습을 보고 있으면 텔레그램 봇 기반 AI 에이전트가 단순한 챗봇을 넘어, 조금 더 내 생활에 밀착된 개인 비서에 가까워지고 있다는 느낌이 든다.
물론 이런 종류의 AI 에이전트 브라우저 자동화는 다른 AI 서비스나 오픈 클로 계열 프로젝트에서도 얼마든지 구현할 수 있는 영역일지 모른다. 그래도 이번 작업이 특히 즐거운 이유는, 내가 원하는 방식으로 직접 구조를 잡고 손보며 만들었다는 데 있다. 그중에서도 로그인 문제를 noVNC 기반 원격 로그인 세션으로 해결한 부분은 이 프로젝트만의 꽤 분명한 특징처럼 느껴진다. 브라우저 자동화에서 늘 까다로운 보안 문제를, 적어도 내 사용 범위 안에서는 꽤 만족스럽게 정리했기 때문이다.
이제 다음 단계는 리마인더에서 스케줄링 기능을 분리해, 스케줄링과 브라우저 자동화를 자연스럽게 결합하는 것이다. 예약된 시간에 홈서버가 자동으로 브라우저를 열고 필요한 작업을 수행하게 만들면, 나만의 오픈 클로는 한층 더 실용적인 자동화 비서에 가까워질 것이다. 이렇게 하나씩 내 취향에 맞는 기술을 붙여가며 AI 에이전트를 키워가는 과정 자체가 꽤 재미있다.