크롬 드라이버 버전 오류와의 전쟁, 웹드라이버 매니저로 마침표를 찍다

크롬 드라이버 버전 오류와의 전쟁, 웹드라이버 매니저로 마침표를 찍다

크롬 브라우저가 자동 업데이트되면서 셀레늄 자동화 봇이 갑자기 먹통이 된 경험을 기록한다. SessionNotCreatedException 에러가 반복되는 이유를 찾는 데만 이틀이 걸렸고, 해결책은 단 한 줄의 라이브러리 교체였다.

위 화면은 크롬 브라우저 자동 업데이트 이후 셀레늄 스크립트를 실행한 순간의 터미널 로그다. SessionNotCreatedException과 함께 "This version of ChromeDriver only supports Chrome version..."이라는 메시지가 붉게 도배된 화면은, 지금껏 정상 작동하던 자동화 봇이 하루아침에 멈췄다는 것을 의미한다. 하드코딩된 드라이버 파일과 업데이트된 브라우저 사이의 버전 불일치가 원인이었다.

반복 업무를 없애기 위해 시작한 작은 프로젝트

사업을 운영하다 보면 시장의 흐름이나 경쟁사 동향을 파악하기 위해 매일 수집해야 하는 데이터가 있습니다. 초기에는 팀원들이 직접 웹사이트에 접속해 엑셀로 데이터를 옮겨 적었습니다. 하지만 이런 단순 반복 작업은 팀의 소중한 시간을 갉아먹었고, 피로가 누적될수록 휴먼 에러도 잦아졌습니다.

이 고질적인 문제를 해결하기 위해 파이썬(Python)과 셀레니움(Selenium)을 활용한 '데이터 크롤링 봇'을 개발했습니다. 처음 코드를 완성하고 테스트를 실행하던 날, 모니터 속 마우스 커서가 스스로 움직이며 데이터를 척척 수집하는 모습을 보며 묘한 짜릿함을 느꼈습니다. '이제 이 스크립트가 우리 팀의 든든한 막내 역할을 해주겠구나'하는 자부심을 안고 서버에 코드를 배포했습니다.

한 번의 세팅이 영원할 것이라는 순진한 기대

스케줄러 등록을 마친 후, 제 기대는 확고했습니다. '이제 매일 아침 9시가 되면, 내가 신경 쓰지 않아도 정해진 데이터가 엑셀로 예쁘게 정리되어 슬랙(Slack)으로 날아오겠지.'

마치 공장에 튼튼한 자동화 기계를 들여놓은 기분이었습니다. 전원만 켜두면 쉬지 않고 돌아가는 컨베이어 벨트처럼, 소프트웨어 역시 한 번 작성해 두면 외부에서 건드리지 않는 이상 영구적으로 작동할 것이라 믿었습니다. 며칠 동안 스크립트가 오차 없이 데이터를 물어오는 것을 보며, 저는 자동화가 주는 달콤한 환상에 성공적으로 빠져 있었습니다.

빨간 줄로 도배된 에러 로그의 습격

평화롭던 자동화의 꿈은 불과 2주 만에 산산조각 났습니다. 출근 후 확인한 슬랙 채널에는 매일 도착해야 할 데이터 파일이 없었습니다. 서둘러 서버에 접속해 로그를 열어보니, 터미널 창은 온통 붉은색 에러 메시지로 도배되어 있었습니다.

가장 눈에 띄는 문구는 SessionNotCreatedException이었습니다. 스크립트가 실행되자마자 웹 브라우저를 띄워보지도 못한 채 그대로 뻗어버린 것입니다. 어제까지 수천 건의 데이터를 거뜬히 수집하던 코드가 갑자기 심정지 상태가 되니 당황스러울 수밖에 없었습니다. 자동화 시스템이 멈춘 그날, 데이터 수집은 다시 팀원들의 수작업으로 돌아갔고 저는 원인 규명에 매달려야 했습니다.

헛다리를 짚었던 디버깅의 시간

처음에는 제가 짠 코드 어딘가에 숨어있던 버그가 터진 줄 알았습니다. 혹은 타겟 웹사이트의 UI 구조가 바뀌어 크롤러가 요소를 찾지 못했다고 생각했습니다. 웹사이트를 분석하고 네트워크 상태를 점검해 보았지만 특이점은 없었습니다.

다음으로는 서버 메모리 부족을 의심했습니다. 클라우드 서버 사양이 낮아 백그라운드 프로세스가 메모리를 점유한 탓에 크롬 브라우저가 실행되지 않은 것이라 짐작하고 서버를 재부팅했습니다. 하지만 서버를 껐다 켜고 코드를 이리저리 수정해 봐도, 스크립트는 시작과 동시에 차가운 에러 메시지만 토해냈습니다.

이틀간의 디버깅 끝에 에러 메시지를 정독하는 과정을 보여주는 화면이다.

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

이 분석 과정에서 에러 로그의 핵심 문장 "This version of ChromeDriver only supports Chrome version..." 이 범인을 정확히 지목하고 있었음을 알아냈다. 코드 버그가 아닌 외부 의존성(브라우저 버전)의 변화가 원인이었다. 코드를 아무리 뒤져도 버그를 찾을 수 없었던 이유가 바로 여기에 있었다.

범인은 '말없이 업데이트된' 크롬 브라우저

마음을 가라앉히고 에러 메시지를 첫 줄부터 끝까지 정독했습니다. 그제야 길고 복잡한 영어 문장 속에서 진짜 범인을 지목하는 문장이 눈에 들어왔습니다. "This version of ChromeDriver only supports Chrome version..."

원인은 바로 '버전 불일치'였습니다. 셀레니움이 크롬 브라우저를 제어하려면 '크롬 드라이버(ChromeDriver)'라는 중간 다리 역할의 실행 파일이 필요합니다. 처음 세팅할 때 저는 제 PC 환경에 맞는 드라이버 파일을 직접 다운로드하여 프로젝트 폴더에 넣어두었습니다.

문제는 구글 크롬 브라우저가 보안과 성능 향상을 위해 사용자가 모르는 사이 백그라운드에서 자동 업데이트를 진행한다는 점이었습니다. 브라우저는 최신 버전으로 올라갔는데, 폴더 안의 드라이버 파일은 과거 버전에 멈춰 있으니 둘 사이에 통신이 끊긴 것입니다. 결국 브라우저가 업데이트될 때마다 제가 직접 사이트에 들어가 새 드라이버를 다운받아 덮어씌워야 하는 '수동 작업'이 여전히 남아있다는 사실을 뼈저리게 깨달았습니다.

웹드라이버 매니저(webdriver-manager), 자동화의 빈틈을 메우다

이 치명적인 번거로움을 해결하기 위해 문서를 뒤지던 중, 구세주 같은 파이썬 라이브러리를 발견했습니다. 바로 webdriver-manager입니다.

이 라이브러리는 코드가 실행되는 순간, 현재 시스템에 설치된 크롬 브라우저의 버전을 스스로 감지하고 그에 정확히 맞는 크롬 드라이버를 알아서 다운로드하여 연결해 줍니다. 저는 기존에 드라이버의 결코 경로를 하드코딩해 두었던 부분을 지우고, 단 한 줄의 코드를 추가했습니다.

ChromeDriverManager().install()

코드를 수정하고 다시 실행하자, 터미널 창에 드라이버 버전을 체크하고 캐시에 저장한다는 로그가 짧게 스쳐 간 뒤 크롬 브라우저가 정상적으로 팝업되었습니다. 이제 크롬 브라우저가 백 번을 업데이트하더라도, 제 코드는 실행될 때마다 스스로 버전을 맞추어 새 드라이버를 장착합니다. 수동으로 파일을 교체해야 하는 굴레에서 성공적으로 해방된 순간이었습니다.

성공적인 자동화 시스템을 위해 배운 것들

이번 경험을 통해 '작동하는 코드'와 '유지보수가 가능한 시스템'은 완전히 다르다는 것을 배웠습니다. 겉으로 보이는 기능 구현에만 급급했던 저는, 시스템을 지탱하는 기반 환경(브라우저 버전 등)이 언제든 변할 수 있다는 사실을 간과했습니다.

아무리 코드를 정교하게 짜더라도 외부 의존성을 정적으로 고정해 두면, 그것은 언젠가 터질 시한폭탄과 같습니다. 진정한 업무 자동화란 단순히 사람의 손길을 줄이는 것을 넘어, 시스템 스스로 환경 변화에 적응하도록 설계하여 '유지보수 개입 포인트'까지 최소화하는 것임을 깨달았습니다.

더 단단한 파이프라인을 향한 다음 스텝

웹드라이버 매니저를 도입한 이후, 저희 팀의 크롤링 봇은 브라우저 업데이트 이슈로 멈추는 일 없이 매일 묵묵히 제 몫을 다하고 있습니다. 가장 큰 골칫거리를 해결하고 나니, 이제 시스템을 한 단계 더 고도화하고 싶은 욕심이 생깁니다.

다음 목표는 브라우저 창을 시각적으로 띄우지 않고 백그라운드에서 훨씬 빠르고 가볍게 동작하는 '헤드리스(Headless) 모드'를 전면 도입하는 것입니다. 더불어 타겟 웹사이트의 일시적인 응답 지연이나 네트워크 오류가 발생했을 때 프로그램이 바로 죽지 않고 일정 시간 대기 후 다시 시도하는 '재시도 로직(Retry logic)'도 추가할 계획입니다. 어떠한 변수 앞에서도 쉽게 멈추지 않는, 더욱 단단하고 견고한 자동화 파이프라인을 만들어 나가겠습니다.