브라우저로 로그인하고 requests로 긁기: 쿠키·토큰 전달법과 한계

by

브라우저로 로그인하고 requests로

로그인이 필요한 사이트를 requests로 긁어오려다가 로그인 폼부터 막혀서 검색하셨다면, 답은 이렇습니다. 브라우저에서 수동으로 로그인한 다음 그 세션의 쿠키나 토큰을 꺼내 requests.Session()에 그대로 넘겨주면 로그인 페이지를 자동화할 필요 없이 로그인된 상태로 요청을 보낼 수 있습니다. 다만 httpOnly 쿠키, TLS 핑거프린팅, 자동 갱신되는 토큰 때문에 이 방법이 안 통하는 사이트도 적지 않아서, 어디까지 되고 어디서부터 막히는지를 같이 짚어보겠습니다.

브라우저에서 로그인한 다음 requests로 그대로 긁을 수 있나요?

가능합니다. 다만 “쿠키만 복사하면 끝”은 아닙니다. 브라우저로 로그인하고 requests로 요청을 보내려면, 로그인 후 서버가 발급한 세션 쿠키(또는 인증 토큰)를 requests의 Session 객체에 심어주는 과정이 필요합니다.

이게 통하는 이유는 간단합니다. 대부분의 웹 서비스는 로그인 여부를 아이디·비밀번호가 아니라 매 요청에 실려 오는 쿠키(세션 ID)나 헤더의 토큰으로 판단하기 때문입니다. 그 값만 똑같이 들고 가면 서버 입장에서는 브라우저가 보낸 요청인지 requests가 보낸 요청인지 구분하지 못하는 경우가 많습니다.

문제는 “많은 경우”일 뿐 “모든 경우”가 아니라는 점입니다. 쿠키·토큰 외에 User-Agent, Referer, TLS 핸드셰이크 패턴까지 같이 확인하는 사이트에서는 쿠키만 넘겨서는 요청이 바로 거부됩니다. 이 부분은 아래에서 따로 다루겠습니다.

쿠키를 꺼내는 세 가지 방법과 그 차이

쿠키를 requests로 가져오는 방법은 크게 세 가지로 나뉩니다. 매번 수동으로 복사할지, 라이브러리로 자동 추출할지, 자동화 도구로 아예 저장해둘지에 따라 작업 흐름이 달라집니다.

방법 작업 방식 장점 단점
개발자도구 수동 복사 F12 → Application → Cookies 값을 직접 복사 추가 설치 없이 바로 가능 쿠키 만료되면 매번 재복사, 자동화 불가
browser_cookie3 설치된 브라우저의 쿠키 DB를 파이썬에서 직접 읽음 코드 한 줄로 자동화 가능 브라우저가 실행 중이면 DB 잠김으로 실패할 수 있음
Selenium/Playwright 쿠키 export 자동화 브라우저로 로그인 후 cookies()로 저장 로그인 과정 자체도 자동화 가능 설치·실행 비용이 크고 느림

브라우저 개발자도구에서 쿠키를 확인하는 파이썬 웹 스크래핑 화면

browser_cookie3(PyPI 0.19.x 기준)를 쓰면 이렇게 짧게 끝납니다.

import browser_cookie3
import requests

# 크롬에 로그인돼 있는 세션의 쿠키를 해당 도메인만 가져옵니다
cj = browser_cookie3.chrome(domain_name="example.com")

session = requests.Session()
session.cookies.update(cj)

headers = {
    "User-Agent": (
        "Mozilla/5.0 (Windows NT 10.0; Win64; x64) "
        "AppleWebKit/537.36 (KHTML, like Gecko) "
        "Chrome/129.0.0.0 Safari/537.36"
    )
}

res = session.get("https://example.com/mypage", headers=headers)
print(res.status_code, len(res.text))
# 예시 출력: 200 48213  (로그인된 페이지 HTML 길이)

여기서 session.cookies.update(cj)는 http.cookiejar.CookieJar 객체를 그대로 받아들이는 requests의 공식 API입니다. 쿠키를 딕셔너리로 직접 넘겨도 되지만, 만료 시각이나 도메인 범위까지 유지하려면 CookieJar를 통째로 넘기는 쪽이 안전합니다. requests의 Session 쿠키 처리 방식은 공식 문서인 Requests: HTTP for Humans에 정리돼 있습니다.

토큰 인증은 쿠키와 다루는 방식이 다릅니다

요즘은 세션 쿠키 대신 Bearer 토큰이나 JWT를 쓰는 사이트도 많습니다. 이 경우는 쿠키 저장소가 아니라 요청 헤더에 토큰을 실어야 합니다.

브라우저 개발자도구의 Network 탭에서 로그인 후 호출되는 API 요청 하나를 골라 Authorization: Bearer ... 헤더 값을 확인하고, 그대로 requests 헤더에 넣으면 됩니다.

import requests

token = "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."  # 개발자도구에서 복사한 값

headers = {
    "Authorization": f"Bearer {token}",
    "Accept": "application/json",
}

res = requests.get("https://example.com/api/me", headers=headers)
print(res.json())

Django 기반 사이트처럼 CSRF 토큰을 별도로 요구하는 경우도 있습니다. 보통 csrftoken 쿠키 값을 그대로 X-CSRFToken 헤더에 복사해서 같이 보내야 POST 요청이 통과됩니다. 쿠키 하나만 들고 가면 되는 세션 인증과 달리, 토큰 인증은 “어디서 값을 읽어와서 어디에 넣는지”가 사이트마다 조금씩 다르다는 점을 염두에 둬야 합니다.

세션을 넘기기 전에 이 세 가지를 확인해 보세요

쿠키나 토큰을 복사해 왔는데도 요청이 자꾸 막힌다면, 아래 항목부터 점검해 보세요.

HTTP 인증 토큰을 활용한 웹 요청 코드 예시 화면

  • User-Agent 일치 여부: 쿠키를 발급받은 브라우저의 User-Agent와 requests가 보내는 User-Agent가 다르면 일부 서비스가 의심스러운 접근으로 판단합니다. 개발자도구 Network 탭에서 실제 요청 헤더를 그대로 복사해 쓰는 쪽이 안전합니다.
  • 쿠키 만료 시간: HTTP 쿠키에는 Expires나 Max-Age 속성이 있어서, 세션 쿠키는 보통 브라우저를 닫거나 일정 시간이 지나면 서버 쪽에서도 무효화됩니다. 복사해둔 쿠키가 오래됐다면 재로그인부터 다시 해야 합니다.
  • Referer·Origin 헤더: 일부 API는 어느 페이지에서 호출됐는지를 같이 검사합니다. 이 헤더가 비어 있으면 정상 요청인데도 거부되는 경우가 있습니다.

쿠키와 토큰을 다 넘겼는데 403·419가 뜨는 이유는 뭔가요?

이 방법의 한계는 생각보다 자주 부딫힙니다. 아래 상황에서는 쿠키·토큰을 제대로 넘겨도 requests만으로 뚫기가 어렵습니다.

  • httpOnly 쿠키: 자바스크립트로 읽을 수 없게 설정된 쿠키는 브라우저 개발자도구의 Application 탭에서는 보이지만, 페이지 안의 스크립트로는 꺼낼 수 없습니다. browser_cookie3처럼 브라우저 DB 파일을 직접 읽는 방식만 이 쿠키를 가져올 수 있고, 수동 복사로는 막힐 수 있습니다.
  • TLS 핑거프린팅: requests가 쓰는 urllib3의 TLS 핸드셰이크 방식은 실제 크롬 브라우저와 패턴이 달라서, Cloudflare 같은 서비스는 이 차이만으로도 요청을 봇으로 분류해 차단합니다. 쿠키가 맞아도 TLS 단계에서 걸러지는 셈입니다. 이런 핸드셰이크까지 흉내 내려면 curl_cffi처럼 브라우저 TLS 지문을 모사하는 별도 라이브러리가 필요합니다.
  • 자동 갱신 토큰: 로그인 직후 받은 토큰이 몇 분 뒤 자동으로 교체되는 사이트도 있습니다. 브라우저는 백그라운드 스크립트가 알아서 갱신하지만, requests는 그 과정을 모르니 복사해둔 토큰이 금방 만료됩니다.
  • 동시 세션 제한: 같은 계정으로 브라우저와 requests가 동시에 쿠키를 쓰면, 서버가 둘 중 하나를 강제 로그아웃시키는 서비스도 있습니다.
  • JS 렌더링 콘텐츠: requests는 HTML만 받아올 뿐 자바스크립트를 실행하지 않습니다. 로그인 이후 데이터가 API 호출이 아니라 프런트엔드 스크립트로 그려지는 페이지라면, 쿠키를 제대로 넘겨도 빈 틀만 받게 됩니다.

여기에 더해 사이트 이용약관이나 robots.txt에서 자동 수집을 명시적으로 금지하는 경우도 있으니, 쿠키를 넘기는 기술적 가능성과 별개로 약관 위반 소지는 따로 확인해 보시는 게 좋습니다.

requests로 충분한 경우와 Playwright로 넘어가야 하는 경우

지금까지 다룬 내용을 기준으로 선택 기준을 정리해보면 이렇습니다.

상황 적합한 도구
쿠키·토큰만으로 인증되고, 데이터가 JSON API로 내려옴 requests + Session
httpOnly 쿠키가 필요하지만 로그인은 한 번만 하면 됨 browser_cookie3 + requests
TLS 핑거프린팅으로 막히거나 토큰이 수시로 갱신됨 Playwright/Selenium으로 로그인부터 끝까지 자동화
로그인 후 데이터가 자바스크립트로 그려짐 Playwright/Selenium (requests로는 접근 불가)

브라우저로 로그인하고 requests로 긁는 방식은 분명 빠르고 가볍습니다. 다만 위 표에서 오른쪽 칸에 해당하는 사이트라면, requests에 시간을 더 쓰기보다 처음부터 Playwright 같은 자동화 브라우저로 로그인 과정 자체를 재현하는 쪽이 결과적으로 더 빨리 끝납니다. 쿠키 추출 코드를 짜기 전에 이 표로 먼저 어느 쪽에 해당하는지 가늠해 보시길 권합니다.

무한 스크롤 페이지를 끝까지 긁기, 스크롤 반복이 항목을 빠뜨리는 이유

Leave a Comment