해외 일정 시간대 설정: 서머타임과 반복 일정을 확인하는 법

해외 교육 안내에 오전 9시라고 적혀 있으면 계산기를 켜기 전에 확인할 것이 있습니다. 어느 날짜의, 어느 도시 오전 9시인지입니다. 한 번짜리 회의라면 그 순간만 정확히 맞추면 되지만, 매주 열리는 수업이라면 문제가 조금 달라집니다. 첫날 한국 오후 5시에 참석했다고 해서 마지막 수업도 오후 5시라는 보장은 없습니다. 시간대 설정에서는 첫 일정이 맞는 것과 반복 규칙이 맞는 것이 별개의 검사 항목입니다.

달력에 저장할 답도 단순히 ‘한국 시간으로 몇 시’에서 끝나지 않는 편이 좋습니다. 누가 정한 어느 지역의 시각을 기준으로 삼았는지 남겨야, 나중에 시간이 달라졌을 때 정상적인 변환인지 실제 일정 변경인지 가릴 수 있습니다. 숫자만 맞춰 놓으면 그 숫자를 왜 골랐는지는 사라집니다.

시차보다 먼저, 무엇을 고정할지 정합니다

해외 일정을 입력할 때 첫 질문은 ‘상대방이 어디에 있나’보다 ‘이 약속의 시각은 어느 지역을 기준으로 정했나’에 가깝습니다. 런던 소재 기관이 주최해도 안내문에서 한국 참가자를 위해 서울 시각을 따로 정했을 수 있습니다. 주최자의 주소만 보고 런던 시간으로 바꾸면 오히려 잘못 입력하게 됩니다.

가상의 온라인 교육 안내가 ‘2026년 10월 19일 월요일 오전 9시, 런던 현지 시각’이라면 날짜는 10월 19일, 시각은 09:00, 기준 지역은 런던입니다. 반면 ‘한국 참가자는 10월 19일 오후 5시 접속’이라는 별도 확정 안내가 있다면 두 표현이 같은 순간인지 먼저 대조합니다. 서로 다르다면 편한 쪽을 골라 저장할 일이 아니라 기관에 어느 안내가 유효한지 확인할 일입니다.

국가명만 적힌 안내도 한 번 더 살펴봅니다. 도시나 행사장 주소가 있는지, 온라인 행사는 주최자가 특정 시간대를 지정했는지 찾습니다. ‘현지 시간’이라는 말에서 현지가 행사장인지 접속자의 위치인지 불분명하면 계산을 시작해도 정답을 고를 수 없습니다. 이때는 ‘한국에서 접속할 때 몇 시인가요?’만 묻기보다 ‘행사 날짜와 기준 도시, 현지 시작 시각을 함께 확인해 주세요’라고 요청하는 편이 재확인에도 유용합니다.

고정 UTC 오프셋과 도시 기반 시간대는 다릅니다

UTC+01:00은 UTC보다 한 시간 빠르다는 차이를 나타냅니다. 이 숫자 자체에는 특정 지역이 어느 날짜에 시계를 바꾸는지에 관한 규칙이 들어 있지 않습니다. Europe/London 같은 지역 식별자는 날짜에 맞는 시간대 규칙을 적용할 때 사용합니다. IANA 시간대 데이터베이스 안내는 지역별 UTC 차이와 서머타임 규칙의 변경을 데이터에 반영한다고 설명합니다.

따라서 ‘런던에서 매주 오전 9시’와 ‘매주 UTC 09:00’은 같은 예약 조건이 아닙니다. 앞의 조건은 런던의 생활 시각을 따르고, 뒤의 조건은 UTC 시각을 고정합니다. 안내문이 UTC를 명시했다면 그것을 그대로 존중해야 합니다. 도시 기반 설정이 편리하다는 이유로 주최자가 지정한 UTC를 임의로 현지 시각으로 바꾸지는 않습니다.

런던을 항상 GMT라고 부르는 것도 피합니다. 영국 공식 안내는 서머타임 기간을 BST, 시계를 되돌린 뒤를 GMT로 구분합니다. 지역 이름과 특정 기간의 시간 표기를 같은 것으로 취급하면, 런던은 제대로 골랐는데 시차는 틀리는 일이 생깁니다. 영국 정부의 시계 변경 안내에서 연도별 전환일을 확인할 수 있습니다.

런던 월요일 오전 9시는 한국에서 두 시각이 됩니다

2026년 영국의 가을 시계 변경일은 10월 25일입니다. 이 날짜를 사이에 둔 두 월요일을 비교하면, 왜 오늘의 시차만 외워 두어서는 부족한지 드러납니다. 아래는 실제 회의나 수강 경험이 아니라, 매주 런던 09:00에 시작하는 가상 일정을 날짜별로 계산한 결과입니다.

런던의 일정 날짜	런던 현지 시각과 표기	같은 순간의 UTC	한국 시각
2026-10-19 월요일	09:00 BST, UTC+01:00	2026-10-19 08:00	2026-10-19 월요일 17:00
2026-10-26 월요일	09:00 GMT, UTC+00:00	2026-10-26 09:00	2026-10-26 월요일 18:00

계산에는 Python의 zoneinfo와 Europe/London, Asia/Seoul을 사용했습니다. 런던 시각을 서울로 변환한 결과뿐 아니라 UTC로 바꾼 뒤 서울의 해당 날짜 오프셋인 9시간을 더한 결과, 다시 런던으로 되돌린 결과까지 대조했습니다. Python zoneinfo 문서는 이러한 지역별 시간 변환에 사용하는 모듈을 설명합니다.

10월 19일에는 런던 09:00에서 한 시간을 빼면 UTC 08:00이고, 여기에 9시간을 더해 한국 17:00가 됩니다. 10월 26일에는 런던 09:00가 UTC 09:00이므로 한국 18:00입니다. 계산식이 어려워진 것이 아니라, 계산에 넣어야 할 런던의 오프셋이 바뀐 것입니다. 이전 회차의 한국 시각을 그대로 복사하는 방식으로는 이 차이를 잡을 수 없습니다.

상대 지역 고정과 한국 시각 고정 중 하나를 선택합니다

교육기관이 런던 09:00 수업을 유지한다면 반복 기준은 Europe/London의 월요일 09:00입니다. 한국 참가자는 10월 19일 17:00, 26일 18:00에 참석하게 됩니다. 26일의 달력이 한 시간 밀려 보인다는 이유만으로 17:00로 끌어다 놓으면, 맞게 변환된 일정을 틀리게 고치는 셈입니다.

반대로 양측이 매주 한국 17:00를 지키기로 합의했다면 Asia/Seoul의 월요일 17:00를 기준으로 정합니다. 같은 두 날짜를 역변환하면 런던에서는 10월 19일 09:00, 26일 08:00입니다. 두 도시의 생활 시각을 전후 모두 똑같이 유지할 수는 없습니다. 어느 쪽의 한 시간을 움직일지 합의하는 것이 반복 설정의 핵심입니다.

반복 종료일이나 횟수도 원래 안내에 맞춥니다. 교육이 정해진 회차로 끝나는데 무기한 반복으로 저장하면 수업이 끝난 뒤에도 참석 알림이 남을 수 있습니다. 휴강일, 특별 강연, 장소 변경처럼 이미 확정된 예외가 있다면 기본 규칙과 따로 기록합니다. 아직 정해지지 않은 예외까지 예상해 달력에 만들 필요는 없습니다.

달력의 표시와 개별 일정의 기준을 구별합니다

시간이 이상하게 보이면 먼저 무엇을 보고 있는지 나눠야 합니다. 화면의 시간 눈금, 개별 일정에 지정한 지역, 실제로 사람들이 동시에 접속해야 하는 순간은 같은 말이 아닙니다. 구별할 때는 다음처럼 질문을 바꿔 보면 됩니다.

구분	확인할 질문	런던 10월 26일 09:00 일정의 예
달력 표시 시간대	내 화면은 어느 지역의 시계로 읽고 있나요?	서울 기준 화면에서는 18:00로 읽습니다.
개별 일정 시간대	입력한 날짜와 시각은 어느 지역의 규칙을 따르나요?	Europe/London의 10월 26일 09:00입니다.
실제 절대시각	다른 도시에서도 같은 순간을 가리키나요?	UTC 09:00와 서울 18:00는 같은 순간입니다.

Google은 일정을 생성할 때 UTC로 변환하고 사용자에게는 현지 시각으로 보여 준다고 설명합니다. 따라서 초대한 사람과 초대받은 사람의 화면에 다른 숫자가 보여도 같은 순간일 수 있습니다. Google Calendar의 시간대 도움말은 표시 설정과 일정별 설정을 구분해 안내합니다.

컴퓨터에서는 표시 기준을 먼저 확인합니다

컴퓨터용 Google Calendar의 설정 → 일반 → 시간대에서 주시간대(Primary time zone)를 확인합니다. 한국 기준으로 일정을 살펴볼 목적이면 서울을 선택하고, 비교할 도시를 추가 시간대로 표시할 수 있습니다. 서울과 런던을 나란히 보면 오프셋 숫자만 보는 것보다 어느 지역의 시각인지 구분하기 쉽습니다.

주시간대를 바꾸는 것과 회의 시간을 바꾸는 것은 다릅니다. 런던 시각으로 화면을 읽고 싶다는 이유만으로 일정 편집창의 시작 시각까지 고칠 필요는 없습니다. 표시를 바꾼 뒤 숫자가 달라졌다면, 우선 앞의 표처럼 같은 순간으로 변환되는지 확인합니다. 화면 변화와 약속 변경을 한꺼번에 처리하지 않아야 원인을 찾기 쉽습니다.

새 일정을 만들거나 편집할 때는 시간 옆의 Time zone에서 기준 도시를 지정합니다. 기준 도시와 시각을 한 쌍으로 맞추고 저장한 뒤, 일정 상세를 다시 열어 날짜와 시작·종료 시각을 확인합니다. 한국 시각으로 이미 변환한 숫자를 입력해 놓고 시간대만 런던으로 선택하면 변환을 두 번 적용한 결과가 됩니다.

예를 들어 앞의 가상 수업을 런던 기준으로 입력한다면 09:00와 런던을 함께 넣습니다. 서울 기준으로 한 번짜리 참석 메모를 만든다면 변환된 시각과 서울을 함께 넣습니다. 다만 공식 반복 초대가 따로 있다면 개인 메모를 또 다른 공식 일정처럼 공유하지 않습니다. 같은 제목의 두 일정이 남아 있을 때 어느 쪽을 따라야 하는지 혼란이 생기기 때문입니다.

초대장은 숫자를 다시 입력하기 전에 읽습니다

초대받은 일정이 있다면 주최자, 행사 날짜, 시작과 종료, 표시된 시간대, 설명란의 원래 안내를 먼저 살펴봅니다. 메일 본문의 설명과 달력의 일정 시각이 따로 적혀 있으면 둘을 구분해서 읽습니다. ‘런던 09:00’라는 안내와 ‘서울 18:00’라는 달력 표시는 위의 10월 26일 사례에서는 서로 맞는 표현입니다.

반대로 같은 10월 26일 초대에 한국 17:00와 런던 09:00가 함께 적혀 있다면 불일치입니다. 메일 문구가 오래된 것인지, 일정 생성 시 시간대를 잘못 골랐는지, 실제 시작 시각을 변경했는지는 숫자만으로 확정할 수 없습니다. ‘초대에는 한국 17:00로 보이는데 안내문의 런던 09:00를 기준으로 하면 한국 18:00입니다’처럼 충돌하는 두 값을 구체적으로 제시해 확인합니다.

초대장을 이미 받았는데 한국 시각을 알아보기 위해 같은 일정을 새로 만드는 것은 피하는 편이 좋습니다. 원래 초대가 변경될 때 개인 복사본까지 함께 고쳐지는지 확인하지 않았다면, 새 메모는 참고용으로만 취급해야 합니다. 제목 옆에 개인 확인용이라고 구분하거나 공식 일정에 연결되는 메모로 남기는 방식이 낫습니다. 이 경우에도 실제 참석 기준은 주최자가 관리하는 최신 안내입니다.

접속 시작과 본행사 시작도 나눠 봅니다. 대기실 입장, 출석 확인, 교육 시작이 각각 안내되어 있다면 하나의 시각으로 합치지 않습니다. 본행사에 맞춰 달력을 저장하고 준비를 위한 별도 알림을 앞당기는 방법이 있습니다. 어느 숫자가 안내문에 있는 사실이고 어느 숫자가 자신의 준비 여유인지 구분해 두면, 기관이 시작 시각을 바꿨을 때 무엇을 다시 계산해야 하는지 분명해집니다.

자정을 넘으면 날짜부터 다시 읽습니다

시간 변환 결과에서 시와 분만 복사하지 않습니다. 런던 2026년 10월 26일 18:00를 가상의 행사 시작으로 잡으면 서울에서는 10월 27일 03:00입니다. 이 변환도 동일한 지역 식별자로 계산했습니다. 런던의 월요일 행사지만 한국 참가자의 알림은 화요일 새벽에 필요합니다.

이때 ‘월요일 저녁 행사’라는 제목을 보고 한국 달력의 월요일에 넣으면 날짜부터 틀립니다. 본문의 안내는 주최 지역 날짜를 유지하되, 참석용 일정은 자신의 달력에서 변환된 날짜에 놓이는지 확인합니다. 상대방에게 시간을 설명할 때도 ‘새벽 3시’만 쓰지 말고 ‘한국 10월 27일 화요일 03:00’라고 적습니다.

종일 일정으로 해결할 문제인지 확인합니다

날짜만 기억하면 되는 행사일이나 휴일 메모는 종일 일정으로 다룰 수 있습니다. 그러나 참가 마감, 항공편 출발, 실시간 교육 시작처럼 특정 순간을 지켜야 한다면 시간이 있는 일정으로 남겨야 합니다. Google의 일정 유형 설명은 종일 일정의 날짜 값과 시간 있는 일정의 시작·종료 시각을 구분합니다.

‘해외 교육이 열리는 날’과 ‘그 교육에 접속해야 하는 순간’은 서로 다른 용도로 기록할 수 있습니다. 날짜를 기억할 종일 메모가 필요하더라도 실제 접속 일정까지 대신하게 하지는 않습니다. 특히 마감일만 적힌 공지에서 임의로 현지 23:59를 만들어 넣지 않습니다. 마감 시각이 없다면 기관에 확인할 항목으로 남겨야지, 종일 표시가 그 빈칸을 채워 주지는 않습니다.

반대로 종일 메모를 시간 있는 일정으로 옮기면서 한국 자정부터 다음 날 자정까지라고 임의로 정의하는 것도 주의합니다. 그 메모가 나타내려는 것이 현지의 날짜인지, 실제 운영 시간인지 먼저 결정합니다. 박람회 날짜를 기억할 메모와 개장 시각에 맞춘 방문 일정은 같은 행사에 관한 기록이어도 필요한 정밀도가 다릅니다.

이동 일정은 출발과 도착을 각각 현지 기준으로 입력합니다

항공편처럼 시작과 끝의 지역이 다르면 한 지역의 시계만으로 적지 않습니다. 예약 확인서에 표시된 각 지점의 날짜·현지 시각을 대조해 출발에는 출발지, 도착에는 도착지 시간대를 연결합니다. Google Calendar에서는 Time zone의 Use separate start and end time zones로 시작과 종료의 시간대를 나눌 수 있습니다.

다음은 입력 방식을 설명하기 위한 가상 이동이며, 실제 항공편이나 운항 시간표가 아닙니다.

입력 대상	예약 안내에 있다고 가정한 현지 날짜·시각	지정할 지역	서울 기준으로 검산한 시각
출발	2026-10-19 23:00, 서울	Asia/Seoul	2026-10-19 23:00
도착	2026-10-20 06:00, 런던	Europe/London	2026-10-20 14:00

이 가정에서 경과시간은 15시간입니다. 현지 시계의 23:00와 06:00만 빼서 7시간이라고 계산하면 서로 다른 기준을 섞게 됩니다. 도착을 런던 기준으로 넣었는지, 다음 날 날짜를 보존했는지, 같은 시간대로 바꿨을 때 종료가 시작보다 뒤에 오는지 확인합니다.

왕복편은 각각 독립적으로 검산합니다. 갈 때 계산한 시차를 귀국편에도 자동 적용하지 말고 귀국 날짜의 출발지와 도착지를 다시 선택합니다. 환승이 있으면 각 구간의 도착 공항과 다음 출발 공항, 날짜를 구별합니다. 시간 변환이 맞는 것과 실제로 환승 가능한 예약인 것은 별개의 문제이므로, 운항 변경과 탑승 절차는 항공사의 최신 예약 안내를 기준으로 확인합니다.

재확인은 일정의 조건이 바뀌는 지점에서 합니다

한 번 저장한 뒤 매일 모든 시간대를 다시 계산할 필요는 없습니다. 재확인이 필요한 지점은 정해 둘 수 있습니다. 예약 직후에는 잘못 입력한 값을 잡고, 서머타임 전환 뒤 첫 회차 전에는 반복 기준을 확인하며, 주최 기관의 변경 안내가 오면 약속 자체가 달라졌는지 살펴봅니다. 해외로 이동해 달력의 표시 기준을 바꿨을 때에는 화면만 달라진 것인지 확인합니다.

여러 나라가 참석하는 일정은 각 지역의 전환일을 같은 날로 가정하지 않습니다. 필요한 참석 도시를 정한 뒤 그 도시의 전환을 걸치는 회차를 각각 점검합니다. 전환이 있는지 모를 때는 현재 시각을 보여 주는 세계시계보다 행사 날짜를 지정할 수 있는 변환 결과와 주최자의 안내를 대조합니다. 현재 시계를 보는 용도와 미래 약속을 검산하는 용도는 다릅니다.

시계를 바꾸는 당일 새벽에 일정이 있다면 더 세밀한 확인이 필요합니다. 시각을 앞당기는 구간에는 건너뛰는 현지 시각이, 되돌리는 구간에는 두 번 나타나는 현지 시각이 생길 수 있습니다. Python의 시간대 전환 설명에서도 이런 중복 시각을 구분합니다. 일반적인 변환기에 숫자를 한 번 넣은 것만으로 안심하지 말고, 기관이 지정한 UTC나 오프셋까지 받아 어느 순간인지 확정합니다.

미래의 시간대 제도는 바뀔 수 있습니다. IANA는 규칙을 갱신하고, 사용자는 보통 운영체제나 소프트웨어 공급자의 업데이트를 통해 이를 받습니다. Google도 지역 규칙 변경을 알기 전에 생성한 일정은 잘못 표시될 수 있다고 경고합니다. 수개월 전 만든 중요한 예약이라면 기기와 앱을 업데이트하고 기관의 최신 안내와 다시 맞춰 보는 이유가 여기에 있습니다.

잘못 저장했다면 전체 반복을 고치기 전에 범위를 좁힙니다

표시 오류와 예약 오류를 먼저 가릅니다

초대의 원래 날짜·시각·도시, 현재 달력의 표시 시간대, 실제 보이는 날짜·시각을 나란히 적습니다. 같은 순간으로 변환된다면 표시 차이이고, 변환해도 맞지 않는다면 일정 값이나 안내가 어긋난 것입니다. 이 구분 전에 이벤트를 한 시간씩 움직이면 무엇이 원인이었는지 더 알기 어려워집니다.

휴대전화와 컴퓨터에서 다르게 보일 때도 곧바로 원본을 고치지 않습니다. 같은 계정의 같은 일정을 열었는지, 표시 시간대가 같은지, 최신 변경을 불러왔는지부터 확인합니다. 다른 달력에 만든 복사본을 보고 있었다면 시간대 설정을 만져도 원본과의 불일치는 해결되지 않습니다.

수정 권한과 적용 회차를 확인합니다

주최자가 보낸 초대라면 자신에게 일정 수정 권한이 있는지 확인합니다. 권한이 없다면 원본 변경을 요청하고, 개인 메모를 고친 것으로 참석자 전체의 일정이 수정됐다고 보지는 않습니다. 자신이 관리하는 일정이라도 수정 전에는 현재 값과 바꿀 값을 기록해 두는 편이 좋습니다.

오류가 한 회차에만 있는지, 특정 회차부터 계속되는지, 처음부터 반복 기준이 잘못된 것인지 구분합니다. 저장창에서는 이번 일정만 바꾸는 선택인지, 이후 일정인지, 전체 반복인지 읽습니다. 앱에 표시되는 선택지가 목적에 맞지 않으면 범위를 확인하지 않은 채 전체를 선택하지 않습니다.

한 번만 시작 시각을 바꾸기로 했다면 그 회차의 예외로 처리합니다. 반대로 앞으로의 모든 회차가 잘못된 기준을 따르고 있다면 매주 하나씩 고쳐 예외를 늘리는 대신 반복 기준을 수정할 방법을 확인합니다. Google의 반복 일정 기술 문서는 전체·이후 회차 변경과 개별 예외를 구분하며, 이후 회차 변경에서 기존 예외가 재설정될 수 있음을 안내합니다. 따라서 이미 따로 조정한 회차는 변경 전후를 반드시 대조합니다.

취소된 수업이나 특별 회차가 있었다면 그 목록도 함께 확인합니다. 전체 시간대를 바로잡는 목적이 휴강까지 되살리거나 별도 약속을 덮어쓰는 결과로 이어져서는 안 됩니다. 과거 회차를 유지해야 하는지, 앞으로의 회차만 바꾸는지에 따라 처리 범위를 나누고 저장 후 영향을 받은 첫 회차와 예외 회차를 각각 열어 봅니다.

수정 결과는 날짜와 도시를 붙여 알립니다

앞의 가상 교육을 바로잡는 상황이라면 ‘한 시간 늦춰졌습니다’보다 ‘2026년 10월 26일 월요일 런던 09:00, 한국 18:00이며, 런던 기준 시작 시각은 그대로입니다’라고 알리는 편이 분명합니다. 한 회차만 고쳤다면 그 범위를 덧붙이고, 이후 전체에 적용했다면 어느 날짜부터인지 적습니다.

마지막으로 수정한 일정을 다시 열어 기관 안내의 날짜·현지 시각·기준 도시와 대조합니다. 한국 표시를 확인하고, 반복이라면 전환을 사이에 둔 회차와 이미 지정된 예외를 확인합니다. 화면의 숫자가 보기 익숙해졌는지가 아니라, 원래 합의한 지역의 시각을 지키고 있는지가 수정 완료의 기준입니다.