이번에 회사에서 콘텐츠 데이터를 크롤링해서 BigQuery에 적재하는 파이프라인을 Cloud Run으로 배포했다.
단순해 보이지만, Cloud Run + Selenium + 환경 변수 조합에는 생각보다 많은 시행착오가 따랐기에 그 중 가장 크게 막혔던 이슈 3가지와 해결 과정을 정리해보려한다.
1. os.environ.get()이 None을 반환하는 문제 ❌
🧩 현상
Cloud Run 배포 후 실행했더니, os.environ.get("CAFE24_MALL_ID") 값이 None.
하지만 --set-env-vars로 분명 등록했음.
🔍 원인
로컬에서는 .env를 통해 환경변수를 관리하다 보니, load_dotenv()를 습관처럼 호출했는데,
Cloud Run에서는 .env가 없기 때문에 load_dotenv() 호출 시 None으로 덮어써버림.
✅ 해결
load_dotenv()호출 완전 제거- 환경 변수는
.env대신 Cloud Run 환경 변수로 관리 - Cloud Run 배포 시 다음처럼 명시:
gcloud run deploy export-cafe24-contents \
--set-env-vars="중요한 키값"💡 참고 - 환경 변수 관리
.env 파일을 동적으로 수정해야 하는 경우(예: refresh token 자동 갱신)에는
GCS에 .env를 저장하고, Cloud Functions에서 주기적으로 다운로드 및 업데이트 하는 방식이 적합하다.
반면, 값이 바뀌지 않는 고정 환경 변수라면 .env를 쓰는 것보다
Cloud Run의 --set-env-vars를 사용하는 게 훨씬 간단하고 안전하며 유지보수도 쉬움.
2. 코드 수정했는데 반영이 안 되는 문제 🤯
🧩 현상
Cloud Run에 배포했는데, 수정한 코드가 반영되지 않음.
로그에 찍히는 메시지가 이전 버전의 코드.
🔍 원인
Cloud Build가 이전 Docker 이미지 캐시를 참조해서
변경사항 없는 이미지를 계속 빌드 및 배포하고 있었음.
✅ 해결
- 아래 옵션으로 캐시 사용 방지:
gcloud config set builds/use_kaniko true
gcloud builds submit --no-cache --tag "gcr.io/$PROJECT_ID/$IMAGE_NAME"- 이후
Cloud Run으로 배포:
gcloud run deploy "$SERVICE_NAME" \
--image "gcr.io/$PROJECT_ID/$IMAGE_NAME" \
--region "$REGION" \
...→ 캐시를 완전히 무시하고 새로 빌드되므로, 코드 변경이 즉시 반영됨.
3. logger.info()가 로그에 안 찍힘 😶
🧩 현상
에러 로그(logger.error())는 잘 찍히는데,
logger.info()는 Cloud Logging에 전혀 보이지 않음.
🔍 원인
루트 로거가 WARNING 이상만 출력하도록 설정되어 있었음.
따라서 INFO 로그는 출력되지만 Cloud Run에서는 무시됨.
✅ 해결
main.py등 진입점에서 명시적으로 logging 레벨 설정:
import logging
logging.basicConfig(level=logging.INFO, format="%(asctime)s %(levelname)s: %(message)s")
logger = logging.getLogger(__name__)💡 참고: 모듈별 logger = logging.getLogger(__name__) 만으로는 부족함.
basicConfig로 전역 설정을 명확히 해줘야 Cloud Logging에서 INFO 로그도 보임.
