BigQuery에서 날짜 관련 오류가 반복되는 이유는

함수가 부족해서가 아니라

타입을 정확히 변환하지 않았기 때문이다.

 

특히 다음 상황에서 문제가 자주 발생한다.

 

  • WHERE 조건에서 타입 불일치
  • TIMESTAMP → DATE 변환 후 하루 밀림
  • STRING 날짜 파싱 실패
  • Looker Studio 연결 시 날짜 왜곡

 

이 글에서는 단순 함수 정리가 아니라

언제 어떤 변환을 해야 안전한지 실무 기준으로 정리한다.

 


자주 묻는 질문

Q. BigQuery 날짜 변환에서 가장 흔한 실수는?

BigQuery 날짜 변환 사용 시 가장 흔한 실수는 기본 설정을 확인하지 않는 것입니다. 공식 문서의 기본 예제부터 따라하는 것을 권장합니다.

Q. 이 방법이 최신 버전에서도 동작하나요?

네, 이 글의 내용은 2026년 기준으로 검증되었습니다. 버전 업데이트에 따라 UI가 다를 수 있으니 참고하세요.

BigQuery 날짜 타입 다시 정리

타입 시간포함 타임존 저장기준
DATE 달력 날짜
DATETIME 로컬 시간
TIMESTAMP UTC 저장

핵심:

BigQuery 날짜 타입은 데이터를 저장하는 방식과 시간, 타임존 포함 여부에 따라 구분되는 데이터 유형이다.

 

TIMESTAMP는 항상 UTC로 저장된다.

 

이 차이가 모든 변환의 출발점이다.

 


가장 많이 쓰는 변환 패턴 ①

TIMESTAMP → DATE

DATE(event_timestamp)

⚠ 이 방식은 타임존을 고려하지 않는다.

TIMESTAMP를 DATE로 변환하는 것은 UTC 기준으로 저장된 타임스탬프에서 날짜 정보만 특정 타임존에 맞춰 추출하는 과정이다.

한국 기준 분석이라면 안전한 방법:

DATE(event_timestamp, 'Asia/Seoul')

이 패턴이 실무에서 가장 많이 사용된다.

 


변환 패턴 ②

TIMESTAMP → DATETIME

DATETIME(event_timestamp)

 

TIMESTAMP를 DATETIME으로 변환하는 것은 타임존 정보를 제거하고 UTC 기준 시간을 유지한 채 날짜와 시간을 표현하는 것이다.

이 변환은:

 

  • 타임존 정보 제거
  • UTC 기준 시간 유지

 

즉, 시간은 남지만 “어느 나라 시간인지” 정보는 사라진다.


변환 패턴 ③

DATE → TIMESTAMP

TIMESTAMP(DATE '2025-01-01')

이 경우 UTC 기준 00:00으로 변환된다.

DATE를 TIMESTAMP로 변환하는 것은 특정 날짜에 타임존 정보를 부여하여 UTC 기준의 시간으로 만드는 과정이다.

 

한국 기준으로 보면:

 

  • 2025-01-01 00:00 KST
  • → 2024-12-31 15:00 UTC

 

따라서 타임존 명시가 필요하다.

TIMESTAMP('2025-01-01', 'Asia/Seoul')

변환 패턴 ④

DATETIME → TIMESTAMP

TIMESTAMP(datetime_col, 'Asia/Seoul')

타임존을 명시하지 않으면

DATETIME을 TIMESTAMP로 변환하는 것은 특정 타임존을 부여하여 지역 시간을 UTC 기준의 시간으로 조정하는 것이다.

의도하지 않은 시간 변환이 발생한다.


변환 패턴 ⑤

STRING → DATE

PARSE_DATE('%Y-%m-%d', string_col)

⚠ 포맷이 정확히 일치해야 한다.

STRING을 DATE로 변환하는 것은 특정 문자열 형식의 날짜를 BigQuery의 DATE 타입으로 파싱하는 것이다.

 

예:

PARSE_DATE('%Y%m%d', '20250101')

변환 패턴 ⑥

STRING → TIMESTAMP

PARSE_TIMESTAMP('%Y-%m-%d %H:%M:%S', string_col, 'Asia/Seoul')

타임존을 명시하지 않으면 UTC 기준으로 해석된다.

STRING을 TIMESTAMP로 변환하는 것은 특정 문자열 형식의 날짜와 시간을 타임존 정보와 함께 BigQuery의 TIMESTAMP 타입으로 파싱하는 것이다.

 


암시적 변환 vs 명시적 변환

 

BigQuery는 일부 상황에서 자동 변환을 시도하지만

BigQuery에서 암시적 변환은 시스템이 자동으로 데이터 타입을 변경하는 것이며, 명시적 변환은 사용자가 함수를 사용하여 타입을 직접 지정하는 것이다.

항상 안전하지는 않다.

 

❌ 암시적 변환:

WHERE event_timestamp >= '2025-01-01'

 

⭕ 명시적 변환:

WHERE event_timestamp >= TIMESTAMP('2025-01-01','Asia/Seoul')

 

실무에서는 항상 명시적 변환을 권장한다.

 


실무 시나리오 1 – 월간 집계

 

월간 집계는 특정 월의 데이터를 집계하기 위해 날짜/시간 컬럼을 월 단위로 필터링하는 실무 시나리오이다.

안전한 패턴:

WHERE event_timestamp >= TIMESTAMP('2025-01-01','Asia/Seoul')
AND event_timestamp <  TIMESTAMP('2025-02-01','Asia/Seoul')

 

BETWEEN 대신 범위 비교 사용.


실무 시나리오 2 – 일별 리포트 컬럼 생성

SELECT
  DATE(event_timestamp,'Asia/Seoul') AS report_date,
  COUNT(*)
FROM table
GROUP BY report_date

Looker Studio 연결 시 안정적.

일별 리포트 컬럼 생성은 BigQuery에서 날짜/시간 데이터를 일별 분석에 용이한 형태로 변환하여 새로운 컬럼을 만드는 실무 시나리오이다.


11. 실무 시나리오 3 – 로그 데이터 보정

 

UTC 기준 저장된 이벤트를

로그 데이터 보정은 UTC 기준으로 저장된 로그 데이터를 특정 지역의 시간 기준으로 조정하여 분석의 정확성을 높이는 실무 시나리오이다.

한국 시간 기준으로 변환:

DATETIME(event_timestamp,'Asia/Seoul')

12. 가장 자주 발생하는 오류 3가지

1. DATE와 TIMESTAMP 직접 비교

❌ 오류 발생

가장 자주 발생하는 오류 3가지는 BigQuery 날짜 변환 시 흔히 겪는 타입 불일치, 타임존 누락, 문자열 비교 문제를 지칭한다.

 

2. 타임존 미지정 변환

→ 하루 밀림 현상

 

3. 문자열 날짜 직접 비교

WHERE string_col >= '2025-01-01'

→ 문자열 비교 발생


13. 안전한 날짜 필터 템플릿

일자 기준 분석

WHERE DATE(event_timestamp,'Asia/Seoul')
BETWEEN DATE '2025-01-01' AND DATE '2025-01-31'

 

안전한 날짜 필터 템플릿은 BigQuery에서 날짜 데이터를 조회할 때 정확하고 오류 없이 기간을 지정하는 표준화된 방법을 제공한다.

기간 분석 (권장)

WHERE event_timestamp >= TIMESTAMP('2025-01-01','Asia/Seoul')
AND event_timestamp <  TIMESTAMP('2025-02-01','Asia/Seoul')

14. Looker Studio 연결 시 권장 패턴

 

Looker Studio 연결 시 권장 패턴은 BigQuery의 날짜 데이터를 Looker Studio에서 왜곡 없이 정확하게 시각화하기 위한 최적의 데이터 처리 방식이다.

✔ TIMESTAMP 유지

✔ 리포트용 DATE 컬럼 별도 생성

✔ 타임존 명시


📌 최종 체크리스트

 

최종 체크리스트는 BigQuery 날짜 변환 작업을 완료한 후 잠재적인 오류를 방지하고 정확성을 확보하기 위한 점검 항목 목록이다.

✔ 변환 시 타임존 명시했는가

✔ DATE와 TIMESTAMP 직접 비교하지 않았는가

✔ 문자열 날짜는 PARSE 함수 사용했는가

✔ BETWEEN 대신 범위 비교 사용했는가

✔ 리포트용 DATE 컬럼 별도 생성했는가


마무리

 

마무리 섹션은 본문의 핵심 내용을 요약하고 독자에게 최종적인 메시지를 전달하는 부분이다.

BigQuery 날짜 변환 문제는

함수 암기 문제가 아니라

타입과 타임존 이해 문제다.

 

DATE · DATETIME · TIMESTAMP를

상황에 맞게 정확히 변환하면

실무 오류의 상당 부분을 예방할 수 있다.

 

이 블로그에서는

구글시트, BigQuery, Looker Studio를 활용하며

실무에서 실제로 막혔던 문제를 구조적으로 정리하고 있다.

💬 이 글이 도움이 되셨다면

BigQuery 날짜 변환 관련 궁금한 점이나 더 알고 싶은 내용이 있다면 댓글로 남겨주세요! 실무에서 겪은 경험을 공유해 주셔도 좋습니다.

+ Recent posts