파이썬 티스토리 자동 로그인 실패기: 카카오 봇 탐지와 Fail-Fast 방어막 구축

파이썬 티스토리 자동 로그인 실패기: 카카오 봇 탐지와 Fail-Fast 방어막 구축

안녕하세요, 1인 개발자이자 자동화 시스템을 구축하고 있는 파이선생입니다. 오늘은 제가 최근에 겪었던 파이썬(Python) 기반의 티스토리(Tistory) 블로그 자동화 시스템에서 발생한 '카카오 로그인 차단' 사태와 이를 해결하기 위해 어떤 방어막(Fail-Fast)을 구축했는지에 대한 생생한 경험담을 공유하고자 합니다.

많은 분들이 블로그를 운영하면서 귀찮은 반복 작업을 줄이기 위해 자동화 스크립트를 작성하십니다. 저 역시 Selenium을 활용하여 마크다운(Markdown)으로 작성한 글을 티스토리 에디터에 자동으로 붙여넣고 임시저장하는 시스템을 수개월간 잘 사용해 왔습니다. 그런데 영원할 것 같았던 이 자동화 시스템에 갑자기 제동이 걸렸습니다. 바로 카카오의 보안 정책이 강화되면서 자동 로그인이 막혀버린 것입니다.

1. 영원한 자동화는 없다: 카카오 계정 자동 로그인 차단 사태

블로그 자동화의 핵심은 '사람의 개입을 최소화'하는 데 있습니다. 제가 구축했던 auto_post_master.py 스크립트는 크롬 브라우저의 프로필(Profile) 기능을 활용하여 로그인 세션을 유지하고, 필요할 경우 카카오 로그인 페이지로 리다이렉트하여 환경변수(.env)에 저장된 아이디와 비밀번호를 자동으로 입력하는 구조였습니다.

수개월 동안 이 방식은 아무런 문제 없이 작동했습니다. Keys.RETURN 명령어를 통해 폼을 제출하면 자연스럽게 티스토리 관리자 화면으로 넘어갔죠. 하지만 어느 날, 파이썬 스크립트를 실행하고 콘솔 창을 지켜보던 저는 이상한 점을 발견했습니다. 평소라면 5초 내에 에디터 화면인 manage/newpost로 진입해야 할 스크립트가 계속해서 카카오 로그인 화면(auth/login)에서 맴돌고 있었던 것입니다.

원인을 파악하기 위해 Selenium이 구동 중인 크롬 창을 띄워 확인해 보았습니다. 아이디와 비밀번호는 완벽하게 입력되어 제출버튼까지 눌러졌지만, 화면은 다음 페이지로 넘어가지 않았습니다. 브라우저 콘솔 네트워크 탭을 살펴보니, 폼 제출에 대한 응답으로 추가 보안 인증(Captcha)이나 기기 인증을 요구하는 내부 로직이 돌고 있었습니다.

즉, 비밀번호가 틀린 것이 아니었습니다. 카카오 서버 측에서 평소와 다른 브라우저 지문(Fingerprint)이나 자동화 플래그(enable-automation 등)를 감지하고, 해당 로그인 시도를 '사람이 아닌 봇(Bot)'으로 규정하여 멈춰 세운 것입니다. 영원할 줄 알았던 UI 기반 자동화의 치명적인 약점이 드러나는 순간이었습니다.

안내 : 콘솔 에러 로그 화면 (파일명: evidence_01.png)

2. Selenium 우회 시도의 한계와 봇 탐지(Bot Detection)

이 문제를 해결하기 위해 처음에는 다양한 우회 기법을 시도해 보았습니다. 많은 개발자들이 봇 탐지를 회피하기 위해 사용하는 보편적인 기술들입니다.

첫 번째로 시도한 것은 ChromeDriverManager의 옵션을 수정하여 자동화 플래그를 숨기는 것이었습니다. excludeSwitches 옵션에 enable-automation을 추가하고, useAutomationExtension을 False로 설정하여 웹사이트가 Selenium의 존재를 눈치채지 못하도록 위장했습니다.

두 번째로는 사람처럼 행동하게 만드는 것이었습니다. 파이썬의 time.sleep() 대신 난수를 발생시켜 대기 시간을 불규칙하게 만드는 human_delay() 함수를 도입했습니다. 타이핑 속도도 조절해 보고, 마우스 커서의 움직임까지 흉내 내는 라이브러리를 찾아보기도 했습니다.

하지만 카카오와 같은 대형 플랫폼의 봇 탐지 시스템은 생각보다 훨씬 견고했습니다. IP 주소의 평판, 브라우저의 User-Agent, WebGL 및 Canvas 렌더링 방식의 차이 등 수십 가지 지표를 종합하여 봇 여부를 판별하기 때문입니다. 일시적으로 로그인이 성공하더라도 며칠 뒤면 다시 차단되는 숨바꼭질이 반복되었습니다. 결국 저는 UI 조작을 통한 로그인 자동화가 '유지보수 비용이 너무 높은, 깨지기 쉬운 유리잔'이라는 사실을 인정해야만 했습니다.

3. 대안 1: Fail-Fast 로직을 통한 안전장치(Login Guard) 구축

자동 로그인이 언제든 막힐 수 있다는 사실을 인정한 후, 제 시스템의 설계 철학을 완전히 바꾸었습니다. "어떻게든 뚫고 들어간다"에서 "문제가 생기면 시스템이 망가지기 전에 가장 먼저 즉시 멈춘다"로 방향을 선회한 것입니다. 이를 소프트웨어 공학에서는 Fail-Fast(빠른 실패) 패턴이라고 부릅니다.

과거의 스크립트는 로그인이 안 된 상태에서도 어떻게든 다음 로직(에디터 진입, 본문 HTML 주입 등)을 강행하려다가 무수한 에러를 뱉어내며 프로그램이 뻗어버리곤 했습니다. 이는 매우 위험한 동작입니다. 엉뚱한 페이지의 DOM에 접근하려다 알 수 없는 클릭이 발생하거나, 예기치 않은 게시물이 발행될 위험도 존재합니다.

따라서 저는 safe_auto_post_master.py라는 새로운 스크립트를 작성하며 'Login Guard'라는 강력한 검증 로직을 제일 앞단에 배치했습니다.

# [Fail-Fast] URL 리다이렉트 최종 검증 로직
current_url = driver.current_url
if "auth/login" in current_url or str(post_id) not in current_url:
    msg = f"로그인 세션 만료 및 인증 실패로 인해 수정 화면에 접근 불가 (URL: {current_url})"
    logger.error(f"[edit 오류] {msg}")
    driver.save_screenshot("error_login_guard.png")
    return {"success": False, "blocked_reasons": [msg]}

이제 제 자동화 스크립트는 에디터에 진입하기 직전에 현재 브라우저의 URL이 정상적인 목적지인지 확인합니다. 만약 카카오 보안에 막혀 auth/login 화면으로 튕겨 나갔다면, 즉시 모든 작업을 중단하고 에러 스크린샷을 남긴 뒤 우아하게(gracefully) 프로그램을 종료합니다. 이 사소한 안전장치 하나 덕분에 저는 더 이상 스크립트가 폭주하여 엉뚱한 짓을 할까 봐 조마조마해하지 않게 되었습니다.

4. 대안 2: 티스토리 Open API 로의 피벗(Pivot) 검토

UI 자동화의 한계를 뼈저리게 느낀 후, 저는 보다 근본적이고 안정적인 해결책을 모색하기 시작했습니다. 바로 플랫폼에서 공식적으로 제공하는 Tistory Open API를 활용하는 방안입니다.

Selenium을 이용한 방식은 화면에 보이는 HTML DOM 요소(id, class)에 의존합니다. 티스토리 측에서 에디터의 디자인을 아주 조금만 바꾸거나, 버튼의 id 이름을 변경하면 스크립트는 여지없이 고장납니다. 반면 API 통신은 다릅니다. 서버 대 서버로 정해진 JSON 규격에 맞춰 데이터를 주고받기 때문에, 브라우저가 화면을 렌더링할 필요도 없고 카카오 로그인 화면의 캡차에 막힐 일도 없습니다.

티스토리 API 문서(https://www.tistory.com/apis/post/modify)를 분석해 본 결과, 파이썬의 requests 라이브러리를 통해 액세스 토큰(Access Token)과 글의 제목, HTML 본문만 POST 방식으로 전송하면 1초 만에 글 수정이 완료된다는 것을 확인했습니다. Selenium이 크롬을 띄우고, 페이지 로딩을 기다리고, TinyMCE 에디터를 찾아 iframe을 파싱하는 데 10초 이상 걸리던 작업이 단 1초 만에 끝나는 것입니다.

물론 API를 사용하려면 최초 1회 OAuth 2.0 인증 과정을 거쳐 토큰을 발급받아야 하는 번거로움이 있습니다. 하지만 비밀번호 원문을 로컬에 두는 것보다 토큰을 사용하는 것이 보안상 훨씬 안전하며, 언제든 토큰을 무효화할 수 있다는 장점이 있습니다. 조만간 저는 전체 자동화 시스템의 코어를 Selenium 기반에서 완전한 API 기반으로 피벗(Pivot)할 계획입니다.

5. 결론: 자동화 시스템은 실패를 다루는 방식이 핵심이다

이번 카카오 자동 로그인 차단 사태를 겪으며 제가 깨달은 가장 큰 교훈은 "좋은 자동화 시스템은 성공할 때보다 실패할 때 어떻게 동작하느냐로 결정된다"는 것입니다.

우리는 흔히 100% 완벽하게 동작하는 자동화를 꿈꿉니다. 하지만 외부 플랫폼에 의존하는 시스템은 언제든 예고 없이 변경될 수 있고, 막힐 수 있습니다. 그것은 통제 불가능한 변수입니다. 우리가 통제할 수 있는 유일한 것은 '실패가 발생했을 때 시스템이 얼마나 안전하게 멈추고, 관리자에게 명확한 원인을 알려주는가'입니다.

Login Guard와 같은 Fail-Fast 로직은 단순한 예외 처리 코드가 아닙니다. 내 시스템에 대한 신뢰를 높여주는 가장 든든한 보험입니다. 여러분도 파이썬으로 크롤러나 웹 자동화 스크립트를 개발하고 계신다면, '어떻게 우회할까'를 고민하기 전에 '어떻게 안전하게 실패할까'를 먼저 고민해 보시기를 강력히 권해드립니다. 이상, 실패를 통해 한 뼘 더 성장한 자동화 랩의 파이선생이었습니다.