[DB] UTC로 구성 한다는 것

Contents

과거에 timezone이 필요한 날짜 데이터 빠르게 select 하기라는 글을 작성한 적이 있다.

시간이 지난 지금, 왜 굳이 이렇게 했을까 라는 생각이 든다.

https://nebulayoon.tistory.com/20

[TimescaleDB] timezone이 필요한 날짜 데이터 빠르게 select 하기

 

 

위 글의 내용은 다음과 같다.

 

TimeScaleDB의 hyper table의 기준이 되는 timestamptz column에 사용자의 로컬 날짜(date)를 조건으로 데이터를 가져올 때에는, UTC 날짜와 차이가 나기 때문에, 로컬 날짜 앞뒤로 1일의 데이터를 UTC를 기준으로 조회한 다음, 사용자의 로컬 날짜 기준으로 데이터를 다시 걸러내면 TimescaleDB의 chunk table을 최소한으로 탈 수 있기 때문에, 조회 속도가 향상된다.

 

위 3줄요약이 무슨 소리인지 모르겠다면, 해당 글을 보면 된다.

 

위와 같이 쿼리를 구성한 이유 중, 가장 큰 이유는, "쿼리를 실행할 때, 사용자 관점에서 날짜를 기준으로 입력하겠다"이다.

이렇게 구성하면, 쿼리 자체에 사용자 기준의 날짜가 들어감으로, 명시적으로 해당 쿼리가 어떤 "날짜"를 조회했는지 추적하기가 용이하고, 개발자로 하여금 타겟 데이터를 읽기 쉽게 해 준다.라고 생각했다.

쿼리, 날짜 이 두개의 키워드에 초점을 맞춘 것이 패착이다.

 

아직도, 그렇게 생각하기는 한다. "날짜"를 기준으로는 말이다.

 

위와 같이 할 필요가 없다는 것을 깨달았다.

 

"날짜"에 맞춰서 조회해야 한다는 생각에 "날짜"에 초점을 맞춰서, ::date로 type casting을 하고... 이럴 필요 없다.

python을 기준으로 설명하면,

1. 사용자가 보낸 사용자 기준 로컬 날짜에 timezone을 부여한다.

2. %Y-%m-%d %H:%M:%S 포맷으로 만든다.(datetime 객체)

3. 이제 내부적인 연산에서는 UTC로 변환하여 연산한다.

4. 해당 날짜 데이터가 필요한 경우, [start_utc, end_utc) 조건으로 조회한다.

 

 

한 마디로 로컬라이즈만 해주면 되고, 내부적으로는 모든 연산을 UTC로만 동작하게 하면 된다.

def to_utc_range_from_local_date(date_str: str):
    """
    사용자가 보낸 'YYYY-MM-DD' 날짜를 Asia/Seoul 날짜로 해석하고,
    DB 조회용 UTC datetime 범위를 반환한다.

    ex) '2025-10-25' 입력 시
        2025-10-25 00:00:00 KST → UTC
        2025-10-26 00:00:00 KST → UTC 로 변환
    """
    # 날짜 문자열 파싱
    local_date = datetime.strptime(date_str, "%Y-%m-%d")

    # localize
    start_local = local_date.replace(tzinfo=ZoneInfo("Asia/Seoul"))
    end_local = (local_date.replace(tzinfo=ZoneInfo("Asia/Seoul"))
                 .replace(hour=0, minute=0, second=0, microsecond=0)
                 + timedelta(days=1))

    # UTC 변환
    start_utc = start_local.astimezone(ZoneInfo("UTC"))
    end_utc = end_local.astimezone(ZoneInfo("UTC"))

    return start_utc, end_utc

 

 

만약 Front-end level에서 UTC로 변환하여, 서버한테 전송한다면, 서버는 UTC로만 동작하는 시스템으로 구성이 되며, DB 하고도 UTC로만 데이터를 조회하게 될 것이다.

 

혹은, Front-end에서 서버한테는 '2025-10-25'와 같이 날짜 문자열로 보내게 된다면, 서버는 위와 같은 함수 구성으로 로컬라이즈를 진행 후, 이후로는 동일하게 UTC로만 동작할 수 있다.

 

코드레벨에서 해결하면, 생각하기가 쉬워지는데, 쿼리 레벨에서 이것도 만족시키고 싶고, 저것도 만족시키고 싶고 하는 욕망이 들어가기 시작하면, 참 복잡해지는 것 같다.