BigQuery DATE DATETIME TIMESTAMP에 대해 실무에서 자주 겪는 문제와 해결 방법을 정리했습니다. BigQuery에서 날짜 관련 오류가 반복되는 이유는

함수가 부족해서가 아니라

타입을 정확히 이해하지 못해서다.

 

DATE, DATETIME, TIMESTAMP는 이름이 비슷하지만

내부 구조와 저장 방식이 완전히 다르다.

 

이 차이를 이해하지 못하면:

 

  • WHERE 조건이 어긋나고
  • 리포트 날짜가 하루 밀리고
  • Looker Studio에서 값이 이상하게 보인다.

 

이 글에서는 단순 비교가 아니라

내부 저장 구조 → 실제 차이 → 실무에서 언제 써야 하는지까지 정리한다.


<날짜 유형>

자주 묻는 질문

Q. BigQuery DATE DATETIME TIMESTAMP에서 가장 흔한 실수는?

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

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

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

BigQuery 날짜 타입의 내부 구조

① DATE

  • 형식: YYYY-MM-DD
  • 시간 정보 없음
  • 타임존 없음

예:

DATE '2025-01-01'

 

DATE는 “달력 날짜”만 표현한다.


② DATETIME

  • 형식: YYYY-MM-DD HH:MM:SS
  • 시간 정보 있음
  • 타임존 없음

예:

DATETIME '2025-01-01 09:30:00'

 

DATETIME은 “시간까지 포함된 값”이지만

어느 국가 시간인지 정보는 없다.


③ TIMESTAMP

  • 형식: YYYY-MM-DD HH:MM:SS UTC
  • 시간 정보 있음
  • 타임존 기반 (UTC 저장)

예:

TIMESTAMP '2025-01-01 00:00:00 UTC'

 

TIMESTAMP는

항상 UTC 기준으로 저장된다.

 

이 차이가 실무에서 가장 중요한 부분이다.


가장 많이 발생하는 오류 – 하루 밀림 현상

예를 들어:

하루 밀림 현상은 BigQuery 날짜 타입 사용 시 타임존 차이로 인해 발생하는 오류이다.

SELECT DATE(event_timestamp)
FROM table

 

한국 시간 기준으로 1월 1일 새벽 1시 이벤트가

UTC 기준으로는 12월 31일일 수 있다.

 

그래서 리포트 날짜가 하루 밀린다.


🔎 왜 이런 일이 발생하는가?

 

날짜 왜곡은 TIMESTAMP가 UTC로 저장되고 DATE 변환 시 타임존 고려가 없어 발생하는 현상이다.

TIMESTAMP는 UTC 저장

DATE() 변환 시 타임존 고려 없이 변환

 

즉, 시간대가 다른 국가에서는 날짜 왜곡 발생.


✅ 안전한 변환 방식

 

안전한 변환 방식은 날짜 및 시간 타입 변환 시 명확하게 타임존을 명시하는 것이다.

DATE(event_timestamp, 'Asia/Seoul')

 

또는

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

 

타임존을 명시하는 것이 가장 안전하다.


핵심 정리: ① BigQuery 날짜 타입(DATE, DATETIME, TIMESTAMP)은 내부 구조와 저장 방식이 다르다. ② TIMESTAMP는 항상 UTC 기준으로 저장되며, 타임존 미고려 시 날짜 오류가 발생한다. ③ 날짜 타입 변환 및 조건 설정 시 타임존을 명확히 명시하고 안전한 패턴을 사용해야 한다.

DATE vs DATETIME vs TIMESTAMP 비교 표

항목 DATA DATETIME TIMESTAMP
시간 포함
타임존 포함 ⭕ (UTC 저장)
저장 기준 날짜 날짜+시간 UTC
주 사용 목적 일자 집계 로컬 이벤트 글로벌 로그

실무 시나리오 1 – 일별 매출 집계

목표:

일별 매출 집계는 특정 날짜 기준으로 총 매출을 계산하는 분석 작업이다.

  • 날짜별 매출 합계

추천 타입:

  • DATE
SELECT
  DATE(order_timestamp, 'Asia/Seoul') AS order_date,
  SUM(amount)
FROM table
GROUP BY order_date

실무 시나리오 2 – 로그인 이벤트 분석

 

로그인 이벤트 분석은 사용자의 로그인 기록을 기반으로 시간별 트렌드를 파악하는 작업이다.

목표:

  • 시간 단위 분석

추천 타입:

  • TIMESTAMP

이벤트 로그는 보통 UTC 기준으로 저장된다.

SELECT
  EXTRACT(HOUR FROM event_timestamp AT TIME ZONE 'Asia/Seoul') AS hour,
  COUNT(*)
FROM table
GROUP BY hour

실무 시나리오 3 – 내부 시스템 예약 데이터

 

내부 시스템 예약 데이터는 특정 타임존에 고정된 예약 시간을 저장하는 데이터이다.

예약 시간이 한국 기준 고정이라면

DATETIME이 적합하다.

DATETIME '2025-01-01 09:00:00'

 

타임존 변환이 필요 없다면

DATETIME이 단순하다.

 


타입 변환 시 주의해야 할 것

TIMESTAMP → DATE

 

TIMESTAMP를 DATE로 변환하는 것은 시간 정보를 제거하고 순수 날짜만 추출하는 작업이다.

DATE(timestamp_col)

 

⚠ 타임존 고려 필요


DATETIME → TIMESTAMP

 

DATETIME을 TIMESTAMP로 변환하는 것은 로컬 시간 정보를 UTC 기준 시간 정보로 변경하는 작업이다.

TIMESTAMP(datetime_col, 'Asia/Seoul')

 

타임존 명시 안 하면 오류 발생 가능.


STRING → DATE

 

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

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

 

포맷 정확히 맞아야 한다.


실무에서 가장 안전한 패턴

 

안전한 패턴은 BigQuery 날짜 타입 사용 시 오류를 최소화하기 위한 권장사항들의 집합이다.

✔ 이벤트 로그 = TIMESTAMP

✔ 집계용 컬럼 = DATE 별도 생성

✔ 타임존 명시

✔ BETWEEN 대신 >= / < 사용

 

예:

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

Looker Studio와 연결 시 주의점

  • TIMESTAMP를 그대로 연결하면
  • 날짜가 하루 밀릴 수 있다.
  • 리포트용 DATE 컬럼 별도 생성 권장

가장 많이 하는 실수

 

가장 많이 하는 실수는 BigQuery 날짜 타입의 내부 동작 원리를 오해하여 발생하는 오류이다.

❌ DATE와 TIMESTAMP 직접 비교

❌ 타임존 없이 DATE 변환

❌ 문자열 날짜 직접 비교


📌 최종 체크리스트

 

최종 체크리스트는 BigQuery 날짜 관련 문제를 해결하고 예방하기 위한 점검 항목이다.

✔ 이벤트 로그는 UTC 저장인지 확인

✔ DATE 변환 시 타임존 명시

✔ 집계용 DATE 컬럼 생성

✔ BETWEEN 대신 범위 비교 사용

✔ Looker 연결 전 타입 통일


마무리

 

BigQuery 날짜 오류의 대부분은

함수 문제가 아니라

타입과 타임존 이해 부족에서 발생한다.

 

DATE, DATETIME, TIMESTAMP의 차이를 이해하면

분석 오류의 절반 이상을 예방할 수 있다.

 

실무에서는

“어떤 타입을 쓰느냐”가

“어떤 함수를 쓰느냐”보다 더 중요하다.

 

이 블로그에서는

구글시트·BigQuery·Looker Studio를 사용하며

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

💬 이 글이 도움이 되셨다면

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

+ Recent posts