데이터 챕터 리드를 맡고 있는 정승호님이 “글로벌 대응을 위한 타임존 전환”을 주제로 발표를 진행했는데요. 국내 시장을 넘어 글로벌 무대로 비즈니스를 확장하기 위해, 데이터 저장 구조와 파이프라인을 근본적으로 바꾼 과정을 공유했습니다.

글로벌 비즈니스의 시작

데이터라이즈의 기존 데이터는 모두 KST(Asia/Seoul) 기준으로 저장돼 있었습니다. 한국 사용자에게는 문제가 없었지만, 글로벌 고객에게는 큰 제약이었습니다.

• 현지 기준 시간 제공 필요: 단순히 KST 데이터를 변환하는 방식으로는 서머타임(DST) 같은 변수를 감당할 수 없음
• 24개 타임존 동시성: 글로벌 고객이 늘어나면 24시간 내내 잡이 돌아가는 구조가 필요
• 비용·효율성: Hive 기반 구조는 동시성 지원을 할 수 없어 확장성이 부족

따라서 데이터팀은 두 가지를 동시에 추진했습니다.

1. 데이터 저장 방식을 KST → UTC로 전환
2. Hive에서 Iceberg로 포맷 전환 (ACID, Time Travel, Schema Evolution 지원)

서머타임이라는 복병

시간 문제는 생각보다 단순하지 않았습니다.

예를 들어, 서울 오전 10시 27분은 로스앤젤레스에서는 오후 6시 27분입니다. 그런데 이 시차가 항상 16시간인 게 아니라, 서머타임이 적용되는 시기에는 17시간 차이로 바뀝니다.

사람은 이를 알고 조정할 수 있지만, 서비스는 시스템 차원에서 자동으로 계산해야 합니다. 전 세계에 500개가 넘는 타임존이 존재한다는 점을 고려하면, UTC를 기준으로 모든 시간을 변환하는 것이 유일한 방법이었습니다.

데이터 파이프라인의 변화

기존에는 KST 기준으로만 파이프라인이 동작했습니다.

• Daily Job: 매일 0시, 전날 지표와 캠페인 대상자 추출
• Hourly Job: KST 오전 8시 ~ 오후 11시, 매시간 캠페인 대상자 추출 및 메시지 발송

글로벌 대응을 위해서는 이 구조가 완전히 달라져야 했습니다.

• Daily Job: 각 사이트의 현지 0시에 맞춰 수행
• Hourly Job: 24시간 내내 전 세계 타임존별로 수행

즉, “KST 기준 하루 한 번/몇 시간”이 아니라, 각 현지 시간을 인식해 Job을 동작시키는 구조로 바뀐 것입니다.

세 가지 공통 모듈의 등장

이 변화를 가능하게 하기 위해 데이터팀은 세 가지 공통 모듈을 개발했습니다.

1. Site Finder
   • 특정 시점이 현지 0시인지 판별하고, 해당 고객사 리스트를 반환
   • Spark SQL 조건에 붙여 모든 잡이 올바른 고객사에서만 수행되도록 지원
2. Marker
   • Airflow 센서는 Job 실행 여부만 알 수 있지만, 실제 데이터가 DB에 쌓였는지는 알 수 없습니다.
   • Marker는 timezone + date + site id 단위로 생성·갱신·삭제 여부를 기록해, “작업은 성공했지만 데이터가 없는” 상황을 개선하였습니다.
3. SparkPipe
   • 타임존별로 처리된 데이터를 MySQL에 반영
   • 고객사별 데이터 삭제·갱신을 트랜잭션 단위로 처리해 원자성을 보장
   • 기존에는 전체 데이터를 덮어쓰던 방식을 개선해, 필요한 부분만 교체하도록 최적화

Hive에서 Iceberg로: 달리는 기차의 바퀴 교체

글로벌 환경에서는 여러 타임존 잡이 동시에 실행되므로, Hive의 한계는 분명했습니다. Iceberg는 동시 쓰기, 트랜잭션, Time Travel, Schema Evolution 등 필요한 기능을 모두 지원했습니다.

마이그레이션은 서비스 중단 없이 진행돼야 했습니다. 그래서 Gold Level(서비스와 가까운 데이터)부터 시작해 Bronze Level로 내려가는 역순으로 교체했습니다. 100대 규모의 EMR 클러스터를 띄워 스크립트 기반으로 일괄 마이그레이션을 수행했습니다.

파티션 전략, 세 번의 시행착오

Iceberg 전환에서 가장 큰 고민은 파티션 구조였습니다. 아래 세번의 고민 끝에 최종적인 형태를 결정할 수 있었습니다.

• Try 1: site id + date id

  고객사별 동시 쓰기는 가능했지만, 600개 고객사 × 1년치 데이터 = 22만 개 이상의 파티션이 생성.

  Small file이 폭증해 하루치 데이터도 조회 불가 → 비효율로 판정.

• Try 2: timezone + date id

  파티션 수를 줄여 쿼리 속도는 향상. 그러나 site id 조건으로 조회하면 성능 저하가 여전.

• Try 3: timezone + date id + site id ordered

최종 선택. site id를 정렬해 저장하면서 성능 문제를 해결했고, I/O 효율까지 개선되어 월 5천 달러 비용 절감 효과를 얻었습니다. 다만, 고객사 단위 동시성 확보에는 한계가 있었고, compaction 작업은 수동 관리가 필요했습니다.

아테나 제약과 우회

추가로 Athena의 Presto 엔진은 100개 이상 파티션을 동시에 열 수 없다는 제약이 있었습니다. 모든 쿼리를 Spark로 옮기기는 부분은 타임존의 원래의 목표와 동떨어져있기에

→ Athena에서 데이터를 UNLOAD → Parquet 파일로 저장 → Spark로 읽어 Iceberg에 기록하는 방식으로 우회했습니다.

협업과 QA

이번 전환은 데이터 엔지니어(DE)뿐 아니라 데이터 애널리스트(DA), 데이터 애널리틱스 엔지니어(DAE)까지 모두 참여한 협업 프로젝트였습니다.

• DAE/DA: 비즈니스 요구사항 도출, 전환 후 지표 정확성 검증
• DE: 기술적 제약 검토, 모듈 개발, 마이그레이션 설계
• 팀 전체: 파티션 설계와 전환 로직을 브레인스토밍으로 결정

최종 QA는 2주간 진행되었으며, 실제 타임존별 잡이 안정적으로 수행되는지 반복 검증했습니다.

기대 효과

이번 타임존 전환 프로젝트는 단순히 데이터 저장 구조를 바꾸는 작업이 아니었습니다.

• 정확성·신뢰성 향상: UTC 기반 일원화로 언제 어디서나 동일한 시간 정보 제공
• 효율성·동시성 증가: 타임존 단위로 24시간 처리 가능, 재처리/재적재 효율 강화
• 확장성 확보: 신규 타임존과 고객사가 늘어나도 추가 작업 불필요
• 비용 절감: 파티션 최적화로 월 수천 달러 수준 절감

발표를 마치며 “놀이터 준비는 끝났습니다. 이제 데이터로 돈만 벌면 됩니다.”

마치며

데이터 챕터의 타임존 전환기는 글로벌 서비스를 위한 새로운 데이터 기반을 마련한 프로젝트였습니다. UTC 표준화, Iceberg 전환, 공통 모듈 개발을 통해 데이터 파이프라인은 24시간 언제든 안정적으로 동작할 수 있는 구조로 재탄생했습니다. 앞으로 데이터라이즈는 글로벌 고객이 어디서든 동일하게 신뢰할 수 있는 서비스를 제공하기 위해, 이러한 기술적 도전을 계속 이어갈 것입니다.