Wikipedia 크롤링 레이어를 데이터 파이프라인에 연결
목차
Wikipedia REST API를 붙이는 작업을 했다. 인증 없이 User-Agent만 박아서 요청하는 구조.
왜 이 타이밍에 Wikipedia fetcher였나
bot/data_source.py와 bot/generate.py 두 파일이 함께 변경됐다는 게 포인트다. data_source 쪽에서 fetcher를 구현하고, generate 쪽에서 그걸 받아서 실제 생성 흐름에 붙인 것이다. 즉 단순히 "API 호출 함수 하나 추가"가 아니라 데이터 파이프라인 레이어 전체를 연결한 작업이었음.
Wikipedia REST API는 OAuth 같은 별도 인증 없이 바로 쓸 수 있다. 대신 Wikimedia 정책상 User-Agent를 명시해야 한다. 이게 빠지면 처음엔 응답이 오다가 특정 트래픽 임계를 넘는 순간 막히거나 throttle이 걸린다. 운영 중에 갑자기 데이터가 안 들어오는 상황이 생기는 건데, 그때 원인 파악하는 게 생각보다 오래 걸린다. User-Agent를 "박음"이라고 표현한 게 맞다. 처음부터 정책 위반 소지 없이 고정해두는 게 맞는 선택이었다.
data_source.py / generate.py 분리 의도
# bot/data_source.py — 데이터 취득 레이어
def fetch_wikipedia_summary(title: str) -> dict:
headers = {"User-Agent": "MyBot/1.0 (https://example.org; [email protected])"}
url = f"https://en.wikipedia.org/api/rest_v1/page/summary/{title}"
resp = requests.get(url, headers=headers, timeout=10)
resp.raise_for_status()
return resp.json()
# bot/generate.py — 생성 레이어에서 data_source 를 주입받아 사용
from bot.data_source import fetch_wikipedia_summary
def generate_response(topic: str) -> str:
data = fetch_wikipedia_summary(topic)
extract = data.get("extract", "")
# ... 이후 LLM 혹은 템플릿 조합 로직
이렇게 레이어를 분리해두면 나중에 data_source를 교체하거나 mock으로 갈아끼울 때 generate 쪽을 건드릴 필요가 없다. 팀에서 이런 구조를 잡아두는 게 중요한 이유가 있는데, fetcher가 generate 로직 안에 인라인으로 박혀 있으면 테스트 작성이 불필요하게 복잡해진다. 외부 HTTP 요청을 mocking해야 하는 위치가 generate 안에 숨어버리기 때문이다.
Wikipedia REST API를 쓸 때 챙겨야 할 것들
| 항목 | 주의 포인트 |
|---|---|
| User-Agent | 서비스명 + 연락처 포맷 필수. 없으면 정책 위반 |
| 엔드포인트 | /api/rest_v1/page/summary/{title} — 간단한 요약에 적합 |
| 언어 | 도메인 prefix 변경으로 다국어 대응 가능 (ko.wikipedia.org 등) |
| Rate Limit | 명시적 키 없어도 IP 기반 throttle 존재. 배치성 요청 시 sleep 필요 |
| 오류 처리 | 404 (페이지 없음) / 301 (제목 redirect) 케이스 별도 처리 권장 |
특히 title이 URL encode 없이 들어가면 한글이나 특수문자에서 바로 터진다. 이 부분은 fetcher 내부에서 urllib.parse.quote로 한 번 감싸두는 게 안전하다.
회고
무인증 API라고 해서 "그냥 쓰면 되지"로 접근하면 나중에 꼭 한 번 터진다. User-Agent 정책이 대표적인 예고, 이런 규칙은 공식 문서 첫 페이지에 명시돼 있는데도 빠뜨리는 경우가 많다. commit 메시지에 "(무인증, User-Agent 박음)"이라고 명시한 건 잘한 선택이었다. 나중에 이 코드를 보는 사람이 "왜 headers에 이게 있지?" 하고 지우는 사고를 막을 수 있기 때문이다.
data_source / generate 분리 패턴은 이번처럼 외부 데이터 소스가 붙는 시점에 가장 명확하게 가치가 드러난다. 처음부터 잘 잡아두면 Wikipedia 다음에 다른 소스가 붙을 때도 generate를 손댈 이유가 없다.
끝.
🛒 이 글과 어울리는 추천 상품
*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.
댓글 0
첫 댓글 달아줘.