캡차(Captcha)와 보안 시스템에 가로막힌 셀레늄 우회 작전

[에러발생] 캡차(Captcha)와 보안 시스템에 가로막힌 셀레늄 우회 작전

사내 데이터 수집 자동화 프로젝트에서 셀레늄(Selenium)이 보안 시스템에 차단당한 실제 경험을 공유한다. 로컬 환경에서는 정상 작동하던 스크립트가 서버 배포 후 캡챠(CAPTCHA)와 Access Denied 벽에 부딪힌 과정, 그리고 기술적 우회 대신 '정공법'을 선택한 판단 기록이다.

위 화면은 클라우드 서버에 배포된 셀레늄 스크립트가 실행되던 중 차단된 순간의 브라우저 캡처다. 웹사이트는 봇 접근을 감지하고 캡챠 화면을 띄웠으며, 스크립트는 이를 뚫지 못하고 빈 결괏값만 반환했다. 이 화면 하나가 며칠간의 디버깅을 시작하게 만든 단서였다.

왜 시작했나: 수작업의 늪에서 벗어나기 위한 결단

사내 데이터 수집 프로젝트를 진행하던 중 심각한 병목 현상을 발견했다. 시장 동향 파악을 위해 담당 직원이 매일 아침 타사 웹포털에 접속해 데이터를 엑셀로 옮겨 적는 단순 수작업을 반복하고 있었던 것이다. 귀중한 인력과 리소스가 단순 복붙 작업에 낭비되는 것을 방치할 수 없었다.

팀원들이 데이터 '수집'이라는 막일에서 벗어나 더 가치 있는 '데이터 분석'에 집중할 수 있는 환경을 만들어주고 싶었다. 이를 해결하기 위해 가장 직관적이고 널리 쓰이는 브라우저 제어 도구인 셀레늄(Selenium)을 도입하여 사내 스크래핑 자동화 시스템을 구축하기로 결단했다.

기대한 점: 셀레늄이 가져다줄 자동화의 마법

처음 셀레늄을 선택한 이유는 명확했다. 사람이 실제 브라우저를 띄우고 클릭하며 스크롤을 내리는 모든 동작을 코드 몇 줄로 안전하게 모사할 수 있기 때문이다. 복잡한 자바스크립트 렌더링이 얽혀 있는 최신 동적 웹사이트라도 무리 없이 데이터를 추출할 수 있을 거라 믿었다.

코드를 작성해 서버에 올려두면 퇴근 후에도 밤새워 작동하며, 다음 날 아침 정갈하게 정리된 데이터 리포트를 대령할 것이라는 이른바 '자동화의 마법'을 기대했다. 단기간에 시스템을 완성해 팀의 생산성을 극적으로 끌어올릴 수 있다는 확신에 차 즐겁게 개발에 착수했다.

문제 분석 단계에서 초기에는 단순한 타이밍 문제로 오판하고 Wait 시간만 늘려보는 실수를 반복했다. 아래는 실제 원인을 분석한 과정을 보여주는 장면이다.

상황을 분석하는 파이선생 캐릭터

위 장면처럼 단순한 타이밍 문제가 아님을 인지하는 데 며칠이 걸렸다. 에러 로그를 정독하고 나서야 진짜 원인이 navigator.webdriver 속성 노출을 통한 봇 탐지임을 파악했다. 표면적인 증상(빈 결괏값)만 쫓으면 진짜 원인을 놓치게 된다는 교훈이 이 분석 과정에 담겨 있다.

실제 문제: 갑작스러운 멈춤, 그리고 보안 차단

로컬 환경에서의 초기 개발과 테스트는 아주 순조로웠다. 원하는 데이터를 정확하게 찾아내 수집했다. 하지만 완성된 스크립트를 클라우드 서버에 올리고 스케줄러를 연동하자마자 예상치 못한 문제가 터졌다.

며칠간 잘 작동하던 시스템이 돌연 데이터를 가져오지 못하고 빈 결괏값만 뱉어내기 시작했다. 원인을 파악하기 위해 에러 로그를 뒤지고 브라우저 구동 화면을 캡처해 보았다. 그곳에는 웹사이트 측에서 우리의 접근을 차단했다는 로그와 함께, "당신은 로봇입니까?"를 묻는 캡챠(CAPTCHA) 화면과 'Access Denied'라는 서늘한 보안 경고 창이 스크립트의 앞길을 가로막고 있었다.

처음 생각한 원인: 단순한 네트워크 지연 혹은 타이밍 이슈

처음 차단 에러를 마주했을 때는 단순히 서버의 네트워크 지연이거나 일시적인 트래픽 폭주로 인한 장애일 것이라 가볍게 넘겼다. 혹은 웹페이지 로딩이 미처 완료되기도 전에 스크립트가 다음 돔(DOM) 요소를 찾으려다 발생한 타이밍 문제라고 생각했다.

이에 따라 셀레늄 코드 곳곳에 Implicit / Explicit Wait 대기 시간을 넉넉하게 늘려보고, 창 크기를 조절하거나 클릭 사이에 무작위로 휴식 시간을 부여하는 등 UI 상호작용 측면의 튜닝만 반복했다. 하지만 코드를 아무리 다듬어도 한 번 차단된 환경에서는 계속해서 보안 화면만 나타날 뿐, 원래 목표했던 데이터 페이지로는 결코 접근할 수 없었다.

실제 문제 원인: 정교해진 봇 탐지 솔루션과 WAF

며칠간의 삽질 끝에 파악한 진짜 원인은 대상 웹사이트에 구축된 강력한 웹 방화벽(WAF)과 봇 탐지(Anti-Bot) 솔루션에 있었다.

최신 보안 시스템들은 단순히 짧은 시간 내의 접속 빈도만 체크하지 않는다. 브라우저의 고유 지문(Fingerprint), 마우스 움직임의 궤적, HTTP 헤더의 미세한 차이(예: navigator.webdriver 속성 노출 여부) 등을 종합적으로 분석해 일반 사용자와 자동화 스크립트를 귀신같이 골라낸다. 우리의 셀레늄 스크립트는 너무나 정직하게 자신이 "자동화 도구"임을 헤더와 동작 패턴으로 광고하고 있었고, 보안 시스템은 이를 명백한 비정상 트래픽으로 간주해 즉각적인 차단 조치를 내린 것이었다.

해결 및 정리 과정: 꼼수 우회가 아닌 정공법을 택하다

진짜 원인을 파악한 직후, 특수하게 개조된 웹드라이버를 사용해 봇 탐지를 회피하거나 프록시 IP 풀을 구성해 우회 접속하는 등 다양한 보안 시스템 '우회(Bypass)' 기법들을 찾아보았다. 처음에는 이런 기술적 꼼수를 적용해 차단을 뚫어볼까 진지하게 고민했다.

하지만 기술 책임자이자 비즈니스를 이끄는 입장에서 장기적으로 생각해보니 이는 결코 올바른 방향이 아니었다. 보안 시스템을 강제로 우회하는 것은 창과 방패의 끝없는 소모전이며, 결국 서비스 코드를 끊임없이 수정해야 하는 거대한 기술 부채로 돌아온다. 게다가 타사의 보안 조치를 무력화하는 것은 서비스 이용 약관을 정면으로 위반하는 리스크를 안고 있었다. 그래서 우리는 '우회'를 과감히 포기하고 '정공법'을 택하기로 결단했다.

우선 대상 웹사이트에서 데이터를 합법적으로 제공하는 공식 오픈 API가 있는지 샅샅이 조사했다. 예상치 못하게도 우리가 힘겹게 스크래핑하려던 데이터의 상당수는 이미 공식 API를 통해 제공되고 있었다. 비록 약간의 과금이 필요한 엔터프라이즈 요금제였지만, 시스템의 안정성과 개발자들의 유지보수 비용을 종합적으로 고려하면 훨씬 이득이었다. API로 제공되지 않는 특수 데이터의 경우, 해당 기업의 B2B 제휴 담당자에게 직접 연락하여 합법적인 데이터 연동 계약을 맺었다. 결론적으로 기존의 불안정한 셀레늄 크롤링 로직을 모두 걷어내고, 안전하고 규격을 갖춘 API 연동 방식으로 아키텍처를 전면 개편했다.

배운 점: 기술적 가능성이 항상 비즈니스의 정답은 아니다

이번 경험을 통해 "기술적으로 무언가를 구현할 수 있다는 사실이 곧 비즈니스 환경에서의 정답은 아니다"라는 것을 뼈저리게 배웠다.

브라우저를 자동화하여 데이터를 긁어오는 것은 당장 눈앞의 문제를 비용 없이 쉽게 해결해 주는 것처럼 보이지만, 장기적으로는 시스템의 불안정성을 키우는 시한폭탄과 같다. 보안 장치를 우회하려는 아슬아슬한 줄타기에 에너지를 쏟기보다는, 정당한 비용을 지불하거나 공식적인 파트너십을 맺어 안정적인 파이프라인을 구축하는 것이 진정한 의미의 엔지니어링이다. 자동화는 우리의 업무를 돕는 도구일 뿐, 타인의 시스템을 억지로 여는 만능열쇠가 되어서는 안 된다.

다음 계획: 견고하고 합법적인 데이터 인프라 고도화

현재 새롭게 개편된 API 기반의 데이터 수집 시스템은 단 한 번의 차단 이슈나 지연 없이 매우 견고하게 돌아가고 있다.

다음 단계로는 사내 다른 부서에서 알음알음 사용하고 있는 산재된 레거시 스크래퍼들에 대한 전수 조사를 진행할 계획이다. 약관을 위반하거나 타사 서버에 무리를 주는 방식의 무분별한 수집 로직이 발견된다면, 이를 모두 공식 API 연동 방식으로 전환할 것이다. 나아가 수집된 데이터를 내부 데이터 웨어하우스(DW)에 체계적으로 적재하고, 팀원들이 실시간 대시보드를 통해 비즈니스 인사이트를 직관적으로 얻을 수 있도록 사내 데이터 인프라를 한 단계 고도화하는 작업에 매진할 것이다.