8. 로그인, 세션, CAPTCHA, 프록시, 스텔스 다루기

2026-04-18Views 43약 9분

로그인, 세션, CAPTCHA, 프록시, 스텔스 다루기

데모는 쉬운데 운영은 왜 어려울까

브라우저 에이전트 데모가 유난히 그럴듯해 보이는 이유는 간단합니다. 보통은 내 노트북, 방금 로그인한 계정, 익숙한 브라우저, 깨끗한 네트워크에서 실행하기 때문입니다. 그런데 운영으로 넘어가는 순간 조건이 바뀝니다. 새 브라우저가 뜨고, IP가 바뀌고, 세션이 비어 있고, 로그인 흐름에 2단계 인증이 끼어들고, 어떤 날은 CAPTCHA가 등장합니다. 그러면 어제까지 영리해 보이던 에이전트가 오늘은 로그인 페이지 앞에서 멍하니 서 있게 됩니다.

실전의 분기점은 모델의 추론 능력보다 브라우저 상태를 얼마나 안정적으로 이어 가느냐에 더 가깝습니다. 세션을 유지하고, 같은 사용자처럼 보이며, 필요한 경우에만 사람의 개입을 섞고, 네트워크와 브라우저 정체성을 일관되게 맞추는 팀이 오래 갑니다. 이 장이 중요한 이유가 바로 여기에 있습니다.

로그인은 한 번의 클릭이 아니라 상태의 축적이다

많은 초보 구현은 로그인을 화면 이벤트로만 이해합니다. 아이디 입력, 비밀번호 입력, 로그인 버튼 클릭. 하지만 웹사이트 입장에서는 로그인은 버튼이 아니라 상태입니다. 그 상태는 쿠키뿐 아니라 localStorage, sessionStorage, 토큰, 브라우저 설정, 때로는 IndexedDB 같은 저장소에도 흩어져 남습니다.¹²

그래서 쿠키만 덜렁 저장해 두고 다음 실행에서 다시 넣는 방식은 생각보다 자주 무너집니다. 어떤 사이트는 서버 세션 쿠키만으로 충분하지만, 현대적인 SPA 애플리케이션은 프런트엔드 저장소에 토큰이나 사용자 컨텍스트를 함께 보관합니다. 눈에 보이는 화면은 같아도, 내부 상태가 하나라도 비면 "로그인된 척하는 로그아웃 상태"가 됩니다.¹

이때 기억할 만한 실전 원칙은 단순합니다. 가능하면 개별 조각보다 브라우저 문맥 전체를 보존하라. 세션을 직접 주머니에 넣고 다니려 하지 말고, 브라우저가 기억한 상태를 통째로 다시 쓰는 쪽이 더 안정적입니다. Browserbase의 Contexts나 여러 클라우드 브라우저 제품이 쿠키, 토큰, 저장 상태 전체를 재사용하는 이유도 여기에 있습니다.²

쿠키 저장보다 브라우저 프로필 재사용이 강한 이유

실무에서 가장 현실적인 해법은 종종 "로그인 스크립트를 더 정교하게 짜기"가 아니라 브라우저 프로필을 재사용하는 것입니다. 크롬의 사용자 프로필을 떠올리면 이해가 쉽습니다. 회사용 프로필은 회사 사이트에 계속 로그인되어 있고, 개인용 프로필은 개인 서비스에 로그인되어 있죠. 에이전트도 똑같습니다.³⁴

프로필에는 쿠키만 들어 있지 않습니다. 로컬 스토리지, 각종 설정, 확장 기능, 때로는 사이트가 신뢰를 판단하는 데 쓰는 축적된 흔적까지 함께 남습니다. 그래서 프로필을 재사용하면 매번 처음 방문한 수상한 손님이 아니라, 어제도 왔던 익숙한 사용자처럼 보일 가능성이 높아집니다.⁴

운영 관점에서는 다음 규칙이 특히 중요합니다.

계정마다 프로필을 분리합니다.
고객 테넌트마다 프로필을 분리합니다.
병렬 실행 시 같은 프로필을 동시에 함부로 공유하지 않습니다.
읽기 전용 재사용과 쓰기 가능한 재사용을 구분합니다.⁴

여기서 마지막 항목이 중요합니다. 어떤 작업은 "현재 로그인 상태만 읽으면 되는" 조회 작업입니다. 이런 경우에는 프로필을 읽기 전용처럼 다루는 편이 안전합니다. 반대로 장바구니 갱신, 설정 변경, 긴 워크플로처럼 상태가 업데이트되어야 하는 작업은 실행 후 다시 저장해야 합니다. Steel은 이런 차이를 persist 여부로 다루고, AWS AgentCore도 브라우저 세션을 프로필로 저장한 뒤 다음 세션에서 복원하는 흐름을 제공합니다.³⁴

직접 관리형 프로필이 필요한 경우에는 사용자 데이터 디렉터리(user data dir)를 별도로 만들고, 한 번 사람이 로그인해 둔 뒤 그 디렉터리를 반복 사용하면 됩니다. Crawl4AI는 이 방식을 정식으로 설명하며, 로그인과 설정을 마친 프로필 경로를 이후 크롤링에 재사용하도록 안내합니다.⁵

2FA, SSO, CAPTCHA: 완전 자동화보다 좋은 자동화

이 지점에서 많은 팀이 욕심을 냅니다. "로그인도 매번 자동, 2FA도 자동, CAPTCHA도 자동, 모든 사이트에서 자동." 하지만 실전에서는 항상 자동보다 필요한 순간만 사람이 개입하는 구조가 더 강합니다.

특히 SSO, 2단계 인증, 조직용 포털, 금융·헬스케어 계열 서비스는 첫 로그인 자체가 신원 확인 절차입니다. 이런 흐름은 굳이 매번 깨부술 대상이 아니라, 한 번 통과하고 이후 상태를 재사용할 대상으로 보는 편이 낫습니다.³⁴⁵

가장 안정적인 패턴은 이렇습니다. 처음 한 번은 headed 모드, 즉 사람이 볼 수 있는 브라우저로 엽니다. 여기서 사용자가 직접 SSO를 완료하고, OTP를 입력하고, 필요한 CAPTCHA를 처리합니다. 그 뒤 브라우저 프로필이나 세션 상태를 저장합니다. 이후 반복 작업은 저장된 프로필로 headless 또는 클라우드 브라우저에서 이어 갑니다.⁴⁵⁶

이 방식이 좋은 이유는 두 가지입니다. 첫째, 로그인 자체를 매번 다시 시도하지 않으니 실패 지점이 줄어듭니다. 둘째, 사이트 입장에서도 "정상 사용자가 이미 인증한 세션의 후속 활동"으로 보이기 쉬워집니다. CAPTCHA도 비슷합니다. CAPTCHA는 대개 본질이 아니라 증상입니다. 브라우저가 비정상적으로 보이거나, IP 평판이 나쁘거나, 너무 자주 새 세션이 나타나거나, 행동 패턴이 기계적으로 보여서 발생하는 경우가 많습니다.⁶⁷

따라서 CAPTCHA 전략의 순서는 보통 다음이 맞습니다. 먼저 덜 수상하게 보이기, 그다음 세션 재사용으로 재등장을 줄이기, 마지막으로 허용된 환경에서 해결 수단을 붙이기입니다. Browserless나 Intuned 같은 플랫폼이 CAPTCHA 해결 기능을 별도 옵션으로 두면서도, 동시에 stealth·headful·프록시를 함께 권장하는 이유도 이 때문입니다.⁶⁷

프록시는 우회 도구가 아니라 네트워크 정체성 관리 도구다

프록시를 이야기하면 종종 "막히면 IP 바꾸기"만 떠올립니다. 하지만 에이전트 운영에서 프록시는 더 넓은 개념입니다. 어느 네트워크에서 들어오는 사용자로 보일 것인가를 설계하는 일입니다.

특히 인증된 워크플로에서는 IP가 세션의 일부처럼 취급될 수 있습니다. 어떤 포털은 세션이 시작된 IP 대역과 이후 요청의 출처가 크게 달라지면 재인증을 요구합니다. AWS AgentCore가 안정적인 egress IP와 사내 프록시 연동을 중요한 기능으로 강조하는 이유가 바로 이것입니다.³

실무에서는 작업 종류에 따라 프록시 전략을 나눠야 합니다.

긴 로그인 흐름, 장바구니, 신청서 작성처럼 한 사이트에서 여러 단계를 밟는 작업은 sticky 또는 static 성격의 IP가 유리합니다.
여러 사이트를 짧게 훑는 리서치 작업은 회전형(rotating) 전략이 더 적합할 수 있습니다.
지역별 가격, 국가별 검색 결과, 사내망 접속처럼 위치가 중요한 작업은 geo-targeting이나 사내 프록시 라우팅이 필요합니다.³⁹

여기서 초보자가 많이 놓치는 것이 있습니다. 프로필과 IP는 짝을 맞춰야 한다는 점입니다. 같은 프로필을 미국 시간대처럼 꾸며 놓고, 매 실행마다 다른 나라 IP로 접속하면 정체성이 흔들립니다. 반대로 한국어 브라우저, 서울 시간대, 한국 IP, 한국 서비스 흐름이 잘 맞으면 훨씬 자연스럽습니다. 프록시는 빠른 탈출 버튼이 아니라 브라우저 정체성의 일부입니다.

스텔스는 변장이 아니라 일관성이다

"스텔스"라는 말은 멋있지만, 실제로는 마법 망토가 아닙니다. 사이트는 생각보다 많은 단서를 봅니다. User-Agent, Accept-Language, 시간대, 화면 크기, 폰트, WebGL 정보, canvas 출력, 하드웨어 코어 수, 터치 지원 여부 같은 브라우저 특성뿐 아니라, 더 아래 레벨에서는 TLS 핸드셰이크나 연결 방식, 그리고 행동 패턴까지 함께 볼 수 있습니다.⁸¹⁰

즉, 스텔스의 핵심은 무언가를 하나 가리는 것이 아니라 여러 층의 정보가 서로 모순되지 않게 만드는 것입니다. Windows 크롬처럼 말하는데 폰트와 렌더링 특성은 전혀 다르거나, 서울 IP로 접속했는데 시간대는 뉴욕이고, 모바일이라고 주장하는데 화면과 입력 장치는 데스크톱처럼 보이면 금방 어색해집니다.⁸¹⁰

그래서 좋은 스텔스 전략은 대체로 화려하지 않습니다. 브라우저 버전과 헤더를 맞추고, 프록시 위치와 로케일을 맞추고, headless 탐지 신호를 줄이고, 너무 기계적인 클릭 간격을 피하고, 필요한 경우 headful 모드로 전환합니다. Browserless는 이를 IP 평판과 브라우저 지문을 함께 다루는 문제로 설명하고, Intuned는 headful, stealth, proxies, CAPTCHA solving을 서로 다른 차원의 방어층으로 제시합니다.⁶⁷

한마디로 정리하면 이렇습니다. 스텔스는 숨는 기술이 아니라 그럴듯하게 이어지는 기술입니다.

운영 패턴: 안정적인 팀은 어떻게 설계하는가

실전에서 성숙한 팀은 대개 아래와 같은 구조를 택합니다.

첫째, 초기 인증과 반복 실행을 분리합니다. 최초 로그인, 2FA, 복잡한 약관 동의는 사람이 보고 처리합니다. 그 후에는 저장된 프로필을 기반으로 자동화를 실행합니다.⁴⁵

둘째, 프로필을 자산처럼 관리합니다. 계정별로 나누고, 만료 시점을 추적하고, 병렬 접근 충돌을 막고, 필요하면 읽기 전용 복제본을 씁니다.³⁴

셋째, 세션 건강 검진을 먼저 하고 본작업에 들어갑니다. 예를 들어 시작 직후에 프로필 페이지나 사용자 메뉴 존재 여부를 확인해 "아직 로그인 상태인가?"를 검사합니다. 이 단계에서 실패하면 본작업 대신 재로그인 플로로 보냅니다. 이렇게 하면 중간에 긴 작업이 모두 끝난 뒤 로그아웃을 발견하는 비극을 줄일 수 있습니다.

넷째, 관측 가능성을 남깁니다. 어떤 프로필로, 어떤 IP로, 어떤 헤더/브라우저 버전으로, 어느 시점에 CAPTCHA가 떴는지 기록해야 합니다. 브라우저 자동화의 장애는 재현이 어렵기 때문에, 로그와 스크린샷과 네트워크 단서가 없으면 원인을 찾기 힘듭니다.

흔한 실패 패턴

이 장에서 가장 자주 보게 되는 실패는 놀라울 만큼 비슷합니다.

첫 번째는 매 실행마다 새 브라우저, 새 IP, 새 로그인으로 시작하는 것입니다. 개발 단계에서는 단순해 보여도, 운영에서는 매번 의심받는 첫 방문자가 됩니다.

두 번째는 쿠키만 저장하고 끝냈다고 믿는 것입니다. 저장소가 여러 층으로 나뉜 현대 웹앱에서는 절반만 챙긴 셈일 수 있습니다.¹²

세 번째는 같은 프로필을 여러 작업자가 동시에 덮어쓰는 것입니다. 한 작업은 로그아웃하고, 다른 작업은 장바구니를 비우고, 세 번째 작업은 설정을 바꾸면 프로필이 전쟁터가 됩니다.

네 번째는 프록시와 지문을 따로 놀게 하는 것입니다. IP는 일본인데 언어는 독일어, 시간대는 미국, 브라우저는 모바일, 행동은 초당 정밀 클릭. 너무 많은 설정은 오히려 "꾸민 티"를 냅니다.

다섯 번째는 CAPTCHA를 원인으로 오해하는 것입니다. CAPTCHA는 종종 마지막 경보등일 뿐입니다. 그 앞단의 세션 관리, IP 평판, 브라우저 일관성, 요청 속도, 행동 패턴이 진짜 원인인 경우가 많습니다.⁶⁷¹⁰

이 장의 핵심 정리

브라우저 에이전트가 실전에 들어가면, 문제는 클릭 능력이 아니라 정체성 유지 능력으로 바뀝니다. 로그인 상태를 이어 가고, 브라우저 프로필을 재사용하고, 복잡한 인증은 한 번만 사람과 함께 넘기고, 프록시와 지문을 같은 인물의 일부처럼 맞춰야 합니다. 이 네 가지가 맞물리면 에이전트는 "매번 처음 온 봇"이 아니라 "계속 돌아오는 사용자"에 가까워집니다.

그리고 바로 그 지점에서, 데모용 자동화와 운영 가능한 자동화가 갈라집니다.