최근 GCP Cloud Run에 Python Selenium 크롤러를 올려서 Cafe24 콘텐츠 데이터를 매일 크롤링하고 BigQuery에 저장하는 자동화 파이프라인을 만들었다. 그런데 예상치 못한 타임존 문제를 겪게 되었다.
✅ 결론부터 말하자면: GCP 환경에서는 무조건 UTC 기준으로 동작한다.
따라서, 한국에서 돌리는 API라면 Python 코드 내에서 반드시 KST 타임존을 명시적으로 지정해야 한다.
🧩 문제 상황
나는 Dockerfile에 타임존 설정을 다음과 같이 넣어뒀다.
RUN apt-get install -y tzdata && \
ln -snf /usr/share/zoneinfo/Asia/Seoul /etc/localtime && \
echo "Asia/Seoul" > /etc/timezone그리고 Python 코드에서는 단순하게 어제 날짜를 이렇게 가져오고 있었다:
from datetime import datetime, timedelta
target_date = (datetime.today() - timedelta(days=1)).strftime("%Y-%m-%d")그런데 실제로 배포 후 실행해보니, 대상 날짜가 하루 늦게 찍히는 문제가 발생했다.
예를 들어, 한국 시간으로 3월 26일 아침 7시에 실행됐는데,
[INFO] 대상 날짜: 2025-03-24이렇게 이틀 전 날짜가 타겟으로 지정되고 있었다.
🕵🏻♀️ 원인 분석
알고 보니 GCP Cloud Run에서는 기본적으로 서버가 UTC 타임존으로 동작한다. Docker 이미지 안에서 시스템 타임존을 Asia/Seoul로 바꿨더라도, Python의 datetime.today()는 서버 타임존에 영향을 받지 않고 여전히 UTC 기준으로 값을 반환한다.
즉, 아래 코드는 GCP에선 UTC 기준의 날짜를 반환하므로 우리가 원하는 한국 기준으로는 하루 차이가 날 수 있다:
datetime.today() # --> UTC 기준!🧯 해결 방법: Python 코드에서 타임존 명시하기
Python은 시스템 타임존을 자동으로 감지하지 않기 때문에, pytz나 zoneinfo를 이용해서 명시적으로 타임존을 지정해줘야 한다.
✅ pytz 사용 예시 (Python 3.8 이하 호환 가능)
import pytz
from datetime import datetime, timedelta
kst = pytz.timezone("Asia/Seoul")
target_date = (datetime.now(kst) - timedelta(days=1)).strftime("%Y-%m-%d")✅ zoneinfo 사용 예시 (Python 3.9 이상)
from datetime import datetime, timedelta
from zoneinfo import ZoneInfo
kst = ZoneInfo("Asia/Seoul")
target_date = (datetime.now(kst) - timedelta(days=1)).strftime("%Y-%m-%d")🧠 포인트 요약
| 항목 | 설명 |
|---|---|
tzdata로 Docker 타임존 설정 | 시스템 시간에는 유효하지만 Python 코드엔 직접 영향 없음 |
datetime.today() | 타임존 정보 없음 (naive), GCP에서는 UTC 기준 |
| 해결책 | pytz 또는 zoneinfo로 KST 타임존을 명시적으로 적용해야 정확한 날짜 계산 가능 |
✅ 적용 대상 예시
- 한국 API 연동 시: Cafe24, 네이버 스마트스토어, 쿠팡파트너스 등
- 정시 기준 스케줄링, 어제 날짜 데이터 처리 등
- Cloud Run, Cloud Functions, GCE 등 GCP 환경 전반
📝 마치며
GCP처럼 글로벌 환경에서 자동화를 구축할 때, 타임존 이슈는 사소하지만 중요한 디테일이다. 특히 한국 기준으로 데이터를 수집하거나 분석하는 파이프라인이라면 꼭 타임존을 명시적으로 처리하는 습관을 들이자.
