해외 회의 시간, 왜 자꾸 틀릴까? 시차가 상수가 아닌 이유 (서머타임·UTC 함정)

서울과 뉴욕은 14시간 차이라고 외워두셨을 겁니다. 그런데 여름에 계산해보면 13시간입니다. 한 시간이 어디로 사라진 걸까요.

틀린 게 아닙니다. 시차는 고정된 숫자가 아니기 때문입니다. 이 글은 시차가 언제, 왜 바뀌는지와 그걸 모르고 일정을 잡으면 어디서 사고가 나는지를 정리합니다.

1. 시차는 상수가 아니다

시차는 두 지역의 UTC 기준 오프셋 차이입니다. 문제는 그 오프셋이 1년 내내 같지 않다는 점입니다.

구간	뉴욕	서울과의 차이
겨울 (표준시, EST)	UTC−5	14시간
여름 (서머타임, EDT)	UTC−4	13시간

여름에는 뉴욕이 시계를 한 시간 앞으로 돌립니다. 서울은 그대로 있으니 격차가 한 시간 줄어듭니다. 로스앤젤레스도 같은 방식으로 17시간 ↔ 16시간을 오갑니다.

한국은 서머타임을 쓰지 않습니다. 마지막으로 시행한 게 1987~1988년이었고 그 뒤로는 계속 UTC+9 고정입니다.

그래서 한국에서만 지내면 "시계를 돌린다"는 감각 자체가 없습니다. 시차를 한 번 외워두면 평생 쓸 수 있는 상수처럼 느껴지죠. 상대편 나라가 1년에 두 번 시계를 움직이고 있다는 사실이 계산에서 통째로 빠집니다.

같은 UTC+9인 도쿄와는 시차가 0시간이고 이건 정말로 변하지 않습니다. 일본도 서머타임이 없으니까요. 두바이(UTC+4)도 마찬가지입니다. 이 조합만 다루다 보면 더더욱 방심하게 됩니다.

여기서 진짜 함정이 나옵니다. 서머타임을 쓰는 나라들도 같은 날 바꾸지 않습니다.

2026년으로 옮기면 이렇게 됩니다.

	미국	유럽
시작	3월 8일	3월 29일
종료	11월 1일	10월 25일

즉 3월 8일 ~ 3월 29일(약 3주), 10월 25일 ~ 11월 1일(약 1주) 동안은 미국과 유럽 중 한쪽만 서머타임 상태입니다. 이 구간에는 뉴욕–런던 시차가 평소 5시간이 아니라 4시간이 됩니다.

한국에서 미국·유럽 참석자가 같이 들어오는 회의를 잡는다면, 이 3주와 1주가 매년 반복되는 사고 구간입니다.

호주 시드니를 넣으면 계산이 한 번 더 꼬입니다. 남반구라 계절이 반대이고, 따라서 서머타임 기간도 반대입니다.

서울과의 차이는 1시간 ↔ 2시간을 오갑니다. 그런데 시드니가 시계를 앞으로 돌리는 10월은 유럽이 시계를 뒤로 돌리는 달입니다. 같은 주에 한쪽은 앞으로, 한쪽은 뒤로 갑니다.

사람이 헷갈리는 건 그렇다 쳐도, 자동화에 시차를 하드코딩하면 더 조용히 틀립니다.

서버 스케줄러(크론)는 보통 UTC 기준으로 식을 해석합니다. 한국 시각 오전 7시 30분에 무언가를 돌리고 싶다면 UTC로는 이렇게 됩니다.

KST 07:30 = UTC 22:30, 그런데 하루 전날

시간만 30 22로 바꿔놓고 요일 필드를 그대로 두면, 평일에 돌리려던 작업이 일요일 밤에 돌아갑니다. UTC 22:30은 한국 시각으로 다음 날 아침이니 요일도 하루 당겨 적어야 하는데, 시간만 환산하고 요일을 잊는 게 흔한 실수입니다.

에러가 나지 않는다는 게 이 버그의 가장 나쁜 점입니다. 그냥 엉뚱한 요일에 조용히 실행될 뿐이라 한참 뒤에야 발견됩니다.

고정 오프셋(UTC+9, GMT-5)을 저장하지 마세요. Asia/Seoul, America/New_York 같은 지역 이름(IANA 타임존) 으로 다루면 서머타임이 자동으로 반영됩니다. 이 사이트 세계 시계도 같은 방식이라 오프셋이 그날 기준으로 다시 계산됩니다.
초대장에는 "현지 시각"을 함께 적으세요. "한국시간 오후 4시 (뉴욕 오전 3시)"처럼 양쪽을 다 쓰면 상대가 검산할 수 있습니다.
3월과 10~11월 회의는 한 번 더 확인하세요. 위 전환 구간에 걸리면 지난달에 쓰던 시차가 그대로 통하지 않습니다.
반복 회의는 전환일에 자동으로 밀립니다. 캘린더가 타임존 기준으로 잡아주긴 하지만, 상대 쪽 시각이 한 시간 움직인다는 뜻이라 사전 공지가 필요합니다.

시차를 지금 바로 맞춰보고 싶다면 세계 시계에서 서울·뉴욕·런던·시드니를 나란히 놓고 확인해보세요. 날짜 간격이 궁금하다면 디데이 계산기도 같은 계열입니다.