파이썬 크롤링: requests부터 통합 API까지 2026

2026년에 파이썬으로 소셜 데이터를 크롤링하는 길은 크게 둘이에요. requests와 BeautifulSoup으로 직접 크롤러를 만들거나, 통합 API를 파이썬에서 호출하거나. 직접 만들면 TLS 지문, 데이터센터 IP 차단, JS 하이드레이션, 몇 주마다 바뀌는 내부 파라미터와 계속 싸워야 하고, 통합 API는 httpx.get() 한 줄이에요. 이 글은 두 길의 진짜 장단점을 바로 돌려볼 수 있는 코드와 함께 풀어 줘요. 플랫폼별로 더 깊게 들어가고 싶다면 틱톡 크롤링과 인스타그램 크롤링 글도 같이 보세요.

파이썬 크롤링의 두 갈래

파이썬 크롤링이라고 하면 보통 requests로 페이지를 받아 BeautifulSoup으로 파싱하는 그림을 떠올려요. 블로그, 뉴스, 위키처럼 서버가 완성된 HTML을 그대로 내려 주는 곳에선 지금도 이게 정답이에요. 문제는 소셜 플랫폼이에요. 틱톡, 인스타그램, 유튜브 같은 곳은 HTML이 거의 비어 있고, 팔로워 수나 조회수 같은 진짜 데이터는 자바스크립트가 나중에 그려 내는 JSON 안에 숨어 있어요. 게다가 이들은 자동화된 요청을 아주 공격적으로 막아요.

그래서 선택은 결국 하나예요. 차단과 파싱을 직접 다 떠안을지, 아니면 그 부분을 벤더에게 맡기고 데이터만 받을지. 이 글은 두 길을 하나씩 열어 보고, 마지막에 상황별로 뭘 고르면 좋은지 정리해 줘요.

항목	직접 크롤러 (requests + BeautifulSoup)	통합 API (httpx.get)
준비 시간	몇 시간~며칠	약 5분
차단 대응	프록시·TLS 위장·CAPTCHA 직접 관리	벤더가 전부 처리
스키마	플랫폼마다 제각각, 어댑터 직접 작성	42개 플랫폼 하나로 통일
유지보수	3~6주마다 셀렉터 손봄, 계속 내가	벤더가 담당
비용	프록시(약 $10/GB) + 엔지니어 시간	요청당 1크레딧, 무료 티어

requests와 BeautifulSoup로 직접

가장 익숙한 출발점이에요. 정적인 HTML 페이지라면 열 줄 안에 끝나요.

import requests
from bs4 import BeautifulSoup

# 평범한 requests + BeautifulSoup. 완성된 HTML 페이지엔 잘 통해요.
res = requests.get("https://example.com/blog")
soup = BeautifulSoup(res.text, "html.parser")
titles = [h2.get_text(strip=True) for h2 in soup.select("h2")]
print(titles)

# 그런데 소셜 플랫폼에선 이 코드가 이렇게 막혀요:
# - requests 의 TLS 지문이 브라우저가 아니라서 403 을 맞고
# - 팔로워/조회수는 HTML 이 아니라 JS 가 그리는 JSON 안에 있고
# - 데이터센터 IP 는 몇 분 안에 밴당해요

블로그 하나 긁는 데는 이걸로 충분해요. 하지만 틱톡 프로필의 팔로워 수를 가져오려고 같은 코드를 겨누면, 응답은 빈 껍데기이거나 403이에요. requests 대신 httpx를 써도 결과는 같아요. 둘 다 브라우저처럼 보이지 않으니까요. 여기서부터가 소셜 크롤링의 진짜 난이도예요.

소셜 플랫폼이 막는 법

막는 층이 넷이에요. 하나만 뚫어선 안 돼요.

첫째, TLS 지문이에요. 소셜 플랫폼은 요청의 TLS 핸드셰이크만 보고도 진짜 크롬인지 파이썬 라이브러리인지 구분해요. requests와 httpx는 여기서 바로 걸려요. 그래서 크롬을 흉내 내는 curl_cffi로 지문을 위장해야 해요.

둘째, IP예요. 데이터센터 IP(AWS, GCP 등)는 첫 요청부터 막히는 경우가 많아요. 뚫으려면 GB당 약 $10짜리 주거용 프록시가 필요하고, 하루 1만 건 규모면 프록시 대역폭만 월 50~100달러가 현실적으로 들어요.

셋째, 하이드레이션이에요. 틱톡은 공개 페이지를 <script id="__UNIVERSAL_DATA_FOR_REHYDRATION__"> 태그 안의 JSON으로 그려 내요. BeautifulSoup으로 그 태그를 찾아 JSON을 꺼내고 webapp.user-detail 같은 키까지 타고 들어가면 데이터가 나오지만, 틱톡이 키 경로를 바꾸는 몇 주마다 그 길도 함께 깨져요.

넷째, 로테이션이에요. 인스타그램의 내부 GraphQL은 요청마다 doc_id 파라미터를 요구하는데, 이 값이 2~4주마다 바뀌어요. 유튜브 자막을 뽑아 주는 youtube-transcript-api는 유튜브의 내부 timedtext 엔드포인트를 역설계한 거라 아무런 SLA가 없고, 유튜브가 조용히 손대면 그냥 멈춰요. 자막이 필요하다면 유튜브 자막 추출 도구로 먼저 결과부터 확인해 볼 수도 있어요.

정리하면, 코드는 쉬운 쪽이에요. 어려운 건 이 네 층을 계속 살아 있게 유지하는 일이고, 그게 몇 주마다 반복돼요.

통합 API를 파이썬에서 호출

이 네 층을 전부 벤더에게 넘기는 길이에요. HTTP 호출 하나, API 키 하나, 모든 플랫폼을 가로지르는 스키마 하나. 프록시도, TLS 지문도, CAPTCHA 솔버도, 틱톡이 하이드레이션 키를 바꾸는 새벽 3시의 호출기도 전부 벤더가 떠안아요. 파이썬에선 httpx.get() 한 줄이면 끝이에요.

import os, httpx

r = httpx.get(
    "https://www.socialcrawl.dev/v1/tiktok/profile",
    params={"handle": "tiktok"},
    headers={"x-api-key": os.environ["SOCIALCRAWL_API_KEY"]},
)
body = r.json()
profile = body["data"]
print(f"{profile['username']} - followers {profile['followers']:,}")
print(f"engagement rate: {profile['engagement_rate']}%")

응답은 언제나 { success, platform, data } 모양의 통합 봉투예요. data 안에 정규화된 필드가 들어 있고, 봇 탐지나 프록시는 신경 쓸 일이 없어요. 전체 엔드포인트와 크레딧 비용은 틱톡 데이터 API에서 볼 수 있어요.

통합 스키마의 값

요청 모양은 특별할 게 없어요. 핵심은 스키마예요. 원본 틱톡 JSON은 팔로워를 followerCount로, 인스타그램은 edge_followed_by.count로, 유튜브는 statistics.subscriberCount로 써요. 세 플랫폼에 걸쳐 만들다 보면 뭔가 하나 내놓기도 전에 플랫폼마다 어댑터를 짜고 있게 되죠. AI 에이전트라면 그게 도구 정의 하나가 아니라 셋이라는 뜻이고요.

통합 스키마는 이 이름을 전부 followers로 맞춰 줘요. 그래서 파서 하나가 모든 플랫폼에 통해요.

import os, httpx

KEY = os.environ["SOCIALCRAWL_API_KEY"]
BASE = "https://www.socialcrawl.dev/v1"

targets = [
    ("tiktok", {"handle": "nike"}),
    ("instagram", {"username": "nike"}),
    ("youtube", {"handle": "nike"}),
]

for platform, params in targets:
    r = httpx.get(f"{BASE}/{platform}/profile", params=params,
                  headers={"x-api-key": KEY})
    data = r.json()["data"]
    # 같은 파서. followers 는 플랫폼과 상관없이 followers 예요.
    print(f"{platform}: {data['followers']:,} followers, "
          f"engagement {data['engagement_rate']}%")

여기에 더해 engagement_rate, estimated_reach, content_category, language 같은 계산 필드가 응답에 함께 담겨 와요. 데이터를 그저 읽는 게 아니라 바로 추론할 수 있게 해 주는 거예요. 가격은 크레딧 기반이에요. 무료 100크레딧으로 시작해서, £15에 2,500(Starter), £49에 20,000(Growth), £299에 150,000(Pro)까지 있고, 크레딧은 만료되지 않아요. 하루 상한도, 승인 대기열도 없고요. 유튜브를 다룬다면 유튜브 API 글에서 자막과 트렌딩 데이터까지 이어서 볼 수 있어요.

합법성과 개인정보

짧게 답하면, 공개된 소셜 데이터를 크롤링하는 건 미국 연방법상 대체로 방어 가능해요. 다만 약관과 개인정보법은 별개예요.

미국 판결 두 개가 기준선을 잡았어요. hiQ Labs v. LinkedIn (제9순회법원, 2022)에서 법원은 컴퓨터 사기 및 남용 방지법(CFAA)이 공개적으로 접근 가능한 로그아웃 상태의 데이터 크롤링을 금지하지 않는다고 봤고, Meta v. Bright Data (N.D. Cal., 2024)에서 첸 판사가 그 논리를 이어받았어요. 다만 두 판결 모두 미국법만 다뤄요.

EU와 영국의 GDPR은 데이터가 공개돼 있어도 개인정보에는 적용되고, 한국의 개인정보 보호법(PIPA)도 마찬가지예요. 프로필 이름과 팔로워 수를 대규모로 긁으면 미국 법원이 뭐라고 하든 데이터 컨트롤러 의무가 생길 수 있어요. 실전 원칙은 이래요. 인증이 필요한 엔드포인트는 피하고, 비공개나 로그인 뒤의 콘텐츠는 절대 수집하지 말고, 레이트리밋을 지키세요. 이건 법률 자문이 아니고 관할마다 달라요. 더 자세한 건 스크래핑 합법성 가이드에서 확인하세요.

방법 선택

기준은 하나예요. 유지보수를 얼마나 감당할 수 있느냐.

한 번짜리 리서치이고 파이프라인의 모든 줄을 직접 소유하고 싶다면 curl_cffi와 프록시로 직접 크롤러를 만드세요. 그만한 값어치가 있어요. 반대로 프로덕션 파이프라인이나 AI 에이전트처럼 90일 뒤에도 아무도 안 보는 채로 돌아가야 한다면, 통합 API가 유지보수를 없애 주고 플랫폼 전반의 스키마를 표준화해 줘요. 정적인 블로그나 뉴스라면 requests + BeautifulSoup으로 충분하고요. 소셜 데이터가 끼는 순간부터 계산이 달라져요.

자주 묻는 질문

파이썬으로 소셜 미디어를 크롤링할 수 있나요?

네, 두 가지 길이 있어요. requests나 httpx에 BeautifulSoup을 더해 직접 크롤러를 만들거나, 통합 API를 httpx.get()으로 호출하는 거예요. 직접 만들 땐 소셜 플랫폼이 TLS 지문과 데이터센터 IP를 막으니 curl_cffi와 주거용 프록시가 사실상 필요하고, 팔로워 수 같은 데이터는 JS가 그리는 JSON 안에 있어 하이드레이션 파싱까지 해야 해요. 통합 API는 이 과정을 전부 벤더가 처리해 줘요.

requests와 BeautifulSoup로 인스타그램을 크롤링할 수 있나요?

정적인 HTML 페이지엔 통하지만 인스타그램엔 거의 안 통해요. 인스타그램은 데이터센터 IP를 막고, requests의 TLS 지문을 잡아내고, 팔로워 수를 JS로 그려 내며, 내부 GraphQL의 doc_id를 2~4주마다 바꿔요. 순수 BeautifulSoup 스크립트는 빈 응답이나 403을 맞기 쉬워요. curl_cffi와 프록시를 붙이거나, 통합 API를 쓰는 편이 안정적이에요.

파이썬 크롤링에서 requests와 httpx 중 뭘 쓰나요?

정적 페이지엔 둘 다 괜찮아요. httpx는 async 지원과 HTTP/2가 강점이에요. 다만 소셜 플랫폼 크롤링에선 둘 다 TLS 지문으로 차단당하니, 이때는 크롬을 흉내 내는 curl_cffi가 필요해요. 통합 API를 호출할 땐 어느 쪽이든 상관없고, 이 글의 예제는 httpx.get()을 써요.

파이썬 크롤링은 합법인가요?

미국에서는 공개된 로그아웃 상태의 데이터 크롤링이 대체로 CFAA 위반이 아니에요. hiQ v. LinkedIn(2022)과 Meta v. Bright Data(2024) 모두 공개 데이터 크롤링을 인정했어요. 다만 플랫폼 약관은 자동 수집을 금지하는 경우가 많고, EU·영국의 GDPR과 한국의 개인정보 보호법(PIPA)은 데이터가 공개돼 있어도 개인정보에 적용돼요. 인증이 필요한 엔드포인트와 비공개 데이터는 피하세요. 이건 법률 자문이 아니에요.

통합 스키마가 왜 필요한가요?

플랫폼마다 필드 이름이 다르기 때문이에요. 팔로워 수를 틱톡은 followerCount, 인스타그램은 edge_followed_by.count, 유튜브는 statistics.subscriberCount로 써요. 여러 플랫폼을 다루면 플랫폼마다 어댑터를 짜야 하죠. 통합 스키마는 이걸 전부 followers로 맞추고 engagement_rate 같은 계산 필드를 더해 줘서, 파서 하나로 모든 플랫폼을 다룰 수 있게 해 줘요.