dbt + Trino에서 현재 시각 표기 방식

dbt 쿼리 모델 중 현재 시각을 사용한 처리가 로직에 포함될 수 있습니다. 쿼리에서 사용되는 Jinja 문법과 SQL 내장 함수의 시간 표기 기준이 다르게 동작하는 상황이 있습니다. 이번 글에서는 현재 시각을 표기하는 방식 차이와 타임존을 반영에 대한 dbt 커뮤니티 현황을 공유합니다.

1. current_date vs run_started_at 비교

expression	query	timezone	description
current_timestamp	select current_timestamp	세션 기준	Trino가 사용하는 세션의 타임존 기준 시각
run_started_at	select {{ run_started_at }}	UTC 고정	UTC 기준 쿼리 실행 시작 시각

Trino 세션이 Asia/Seoul로 설정되어 있을 경우, current_date는 KST 기준의 날짜가 반환되지만, run_started_at은 UTC 기준의 타임스탬프 문자열이 반환됩니다. 타임존이 반영된 run_started_at을 사용하기 위해서는 astimezone 설정으로 명시해야합니다.

 select '{{ run_started_at.astimezone(modules.pytz.timezone("Asia/Seoul")) }}'

⚠️ 삽질 포인트
dbt jinja function(run_started_at)과 trino function(current_time)을 혼동했습니다.
run_started_at이 Trino의 current_timestamp나 current_time 같이 current_timezone을 반영한다고 생각했습니다. 하지만 run_started_at은 dbt 전용 Jinja 함수이며, 쿼리 실행 시점의 UTC 시간을 문자열로 삽입해주는 역할만 합니다.
즉, Trino가 처리하는 함수가 아니기 때문에 시간대 설정이나 SQL 연산에 직접적으로 활용할 수 없습니다.

2. run_started_at이 UTC로 고정되는 이유

run_started_at은 Jinja context 내에서 사용할 수 있는 내장 변수로, 쿼리 실행 시작 시점을 UTC 기준 문자열로 반환합니다.
고정된 이유에 대한 dbt 문서 내 직접적인 설명은 없지만 일반적으로 로그나 배치 처리에서 UTC를 사용해 시간대에 따른 혼동을 방지하고 일관성을 유지하여 데이터 정확성과 신뢰성을 확보하기 위한 설정으로 보입니다. (ex. AWS 이벤트 로그 가이드)

3. run_started_at의 시스템 타임존 지원 논의 현황

1에서 언급한 삽질 포인트를 나만 만난건가 싶었습니다. 하지만 dbt 오픈소스 레포 히스토리를 찾다보면 비슷한 착오를 겪고 세션 타임존을 반영하고자 하는 흐름을 볼 수 있었습니다.
dbt 커뮤니티에서는 run_started_at이 항상 UTC로 반환되는 것에 대한 피드백과 개선 요청이 지속적으로 제기되어 왔습니다.

• Allow the configuration of the timezone for timestamps in event logging
• feature run_started_at an aware Python datetime

run_started_at의 시스템 타임 지원은 고려되고 있는 기능이지만 아직 도입되지 않았으며, 현재는 사용자가 수동으로 파싱하거나 타임존 보정을 적용해야합니다.

마무리

current_date와 run_started_at은 모두 유용한 시간 관련 값이지만, 서로 다른 기준(세션 타임존 vs UTC)을 따르기 때문에 혼용 시 주의가 필요합니다. run_started_at의 시간대 유연성을 지원하게 된다면 더욱 직관적인 모델 작성이 가능할 것으로 기대되지만 이벤트 로그에서 사용되는 함수로 dbt측에서 신중하게 접근하는 것으로 보입니다.