로또 당첨 조회 API 전환과 파이프라인 재시도 안정성 강화

외부 API가 바뀌었다. 그것도 조용히.

배경: 공식 API가 슬쩍 바뀐 날

dhlottery 쪽에서 로또 당첨 정보를 조회하는 엔드포인트가 변경됐다. 기존에 쓰던 API가 어느 순간부터 응답이 이상하거나 아예 데이터를 못 가져오는 상황이 발생했고, 원인을 파고들어 보니 신 API(selectPstLt645InfoNew)로 전환된 것이었다.

외부 API를 쓰는 봇이나 파이프라인의 고질적인 문제가 이거다. 제공자 입장에서는 API 버저닝을 별도로 공지하거나 deprecated 기간을 충분히 주는 경우도 있지만, 그렇지 않은 경우도 꽤 많다. 운영 중인 시스템이 조용히 깨지고, 깨진 걸 뒤늦게 발견하는 패턴. 이번이 딱 그 케이스였다.

작업 내용

변경된 파일은 bot/generate.py와 publish.sh 두 개다.

핵심은 두 가지였다.

첫 번째, API 엔드포인트 전환. generate.py 내부에서 호출하던 구 API를 selectPstLt645InfoNew로 교체했다. 단순히 URL 문자열 하나 바꾸는 거처럼 보이지만, 응답 스펙도 같이 확인해야 한다. 필드명이 바뀌거나, 구조가 조금 달라지거나, 없던 필드가 생기거나 하는 경우가 많기 때문에 응답 파싱 부분도 같이 점검했다.

두 번째, 회차 글 보장과 재시도 로직. 이게 이번 작업에서 더 중요한 부분이었다. API 전환 자체보다도, "정상적으로 특정 회차의 데이터가 생성됐는지"를 보장하는 흐름이 없었던 게 문제였다. 데이터를 못 가져오면 그냥 빈 글이 올라가거나, 아예 게시가 안 된 상태로 넘어가 버리는 경우가 있었다. 이번에 그 구멍을 메꿨다.

재시도 패턴은 이런 외부 의존성이 있는 파이프라인에서 거의 필수다. 단순하게라도 구현해두면 일시적인 네트워크 오류나 API 응답 지연으로 인한 실패를 상당 부분 흡수할 수 있다.

# 재시도 패턴 예시 (일반적인 구조)
import time

def fetch_with_retry(fetch_fn, max_retries=3, delay=5):
    for attempt in range(max_retries):
        try:
            result = fetch_fn()
            if result:
                return result
        except Exception as e:
            print(f"[attempt {attempt+1}] failed: {e}")
        time.sleep(delay)
    raise RuntimeError("최대 재시도 횟수 초과")

publish.sh 쪽에서도 단순히 generate를 호출하고 끝내는 게 아니라, 정상적으로 회차 글이 만들어졌는지 확인하고 실패 시 재시도하는 흐름을 추가했다. 쉘 스크립트 레벨에서의 재시도는 Python 레벨보다 좀 더 거칠 수 있지만, 파이프라인 전체 레벨에서 안전망이 하나 더 생기는 셈이다.

회고

이런 작업을 하고 나면 매번 드는 생각이 있다. "외부 API 의존성은 항상 깨진다고 가정하고 설계해야 한다"는 것. 당장은 잘 동작하더라도, 제공자가 언제 응답 스펙을 바꾸거나 엔드포인트를 변경할지 알 수 없다.

이번에 두 가지를 챙겼는데:

• API 응답값 자체에 대한 validation을 더 명시적으로 두기 (예상한 필드가 없으면 조기 실패)
• 파이프라인 실패 시 어떤 회차에서 어떤 이유로 실패했는지 로그가 충분히 남도록

특히 로그가 충분하지 않으면, 문제가 발생했을 때 "왜 이 회차가 빠졌는지"를 역추적하는 데 시간이 배로 걸린다. 이번 케이스처럼 외부 API 변경이 원인인 경우는 그나마 찾기 쉬운 편이고, 데이터 자체가 애매하게 잘못 들어오는 케이스는 로그 없이는 추적이 거의 불가능하다.

bot/generate.py + publish.sh 두 파일만 건드렸지만, 이번 수정은 단순 버그픽스가 아니라 파이프라인의 안정성 레이어를 한 단계 올린 작업으로 봐야 한다. API 전환 대응 + 보장 로직 + 재시도가 한 커밋에 묶인 이유도 그거다. 따로 나누기보다 하나의 "안정성 강화" 단위로 처리하는 게 맞다고 판단했다.

다음은 API 응답 스펙이 또 바뀌었을 때 알람이라도 받을 수 있도록 모니터링 훅을 붙이는 것 정도가 자연스러운 다음 단계일 것 같다.

🛒 이 글과 어울리는 추천 상품

• 노트북 쿠팡에서 보기 →
• 외장SSD 쿠팡에서 보기 →
• 모니터 쿠팡에서 보기 →

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.