한눈에 요약
뉴욕의 매주 금요일 오전 9시를 유지한다면 서울에서는 2026년 10월 30일 밤 10시, 11월 6일 밤 11시입니다. 미국 서머타임 종료를 반영한 차이이므로, 표시가 달라졌다는 이유만으로 반복 일정 전체를 한 시간 당기지 마세요.
내 캘린더에서만 회의가 한 시간 늦어졌다면
뉴욕 팀과 매주 금요일 아침에 만나기로 했습니다. 한국에서는 퇴근 뒤 밤 10시에 접속했는데, 다음 달 일정을 넘겨 보니 밤 11시로 표시됩니다. 회의가 밀린 것인지, 캘린더를 잘못 만든 것인지 먼저 헷갈립니다.
이때 확인할 것은 “회의를 어느 도시의 시계에 맞추기로 했는가”입니다. 미국 NIST는 2026년 서머타임 종료를 11월 1일 현지 시각 오전 2시로 안내합니다. 뉴욕은 이후 표준시로 돌아가므로 서울과의 시차가 한 시간 더 벌어집니다.
구글은 참석자가 같은 일정을 자신의 현지 시간대로 보도록 설명합니다. 따라서 서울 화면에 밤 11시가 나온다는 사실과, 주최자가 회의를 한 시간 늦췄다는 판단은 구분해야 합니다. 이 글은 컴퓨터 웹의 Google Calendar와 뉴욕·서울 조합을 다룹니다.
두 도시의 시간을 동시에 고정할 수는 없습니다
BBS는 서머타임 경계 앞뒤의 금요일을 골라 시간대 데이터로 변환했습니다. 다음 표의 날짜는 양쪽 도시에서 모두 같은 날입니다. 첫 회의만 확인하면 두 선택이 똑같아 보이지만, 11월 회차에서는 차이가 드러납니다.
| 고정할 기준 | 10월 30일 금요일 | 11월 6일 금요일 |
|---|---|---|
| 뉴욕 오전 9시 | 뉴욕 09:00 / 서울 22:00 | 뉴욕 09:00 / 서울 23:00 |
| 서울 밤 10시 | 서울 22:00 / 뉴욕 09:00 | 서울 22:00 / 뉴욕 08:00 |
새 반복 일정은 숫자보다 시간대부터 맞춥니다
팀이 뉴욕 오전 9시를 기준으로 합의했다면, 새 일정의 시간대를 뉴욕으로 지정하고 09:00를 넣습니다. 서울 시간으로 22:00를 입력한 뒤 계속 반복시키는 선택과는 다릅니다. 구글의 개발자 문서도 반복 회차를 펼칠 때 일정에 지정된 시간대를 사용한다고 설명합니다.
컴퓨터 웹에서 만들기 → 일정 → 옵션 더보기로 들어갑니다. 일정 시각 옆의 시간대에서 뉴욕을 검색해 선택하고, 시작을 2026년 10월 30일 09:00로 정합니다. “반복 안 함” 메뉴에서 매주 금요일에 반복하도록 설정하고 종료 조건도 정합니다. 표시 언어에 따라 메뉴 이름은 다를 수 있습니다.
처음에는 참석자를 넣지 않은 확인용 일정으로 저장해 보세요. 서울을 표시 시간대로 둔 캘린더에서 10월 30일과 11월 6일 회차를 각각 열어 위 표와 비교합니다. 두 날짜가 맞는 것을 확인한 뒤 참석자를 추가하고, 초대 설명에 “뉴욕 현지 오전 9시 기준”이라고 적어 두면 변경 이유를 설명하기 쉽습니다.
캘린더 전체의 표시 시간대와 개별 일정의 기준 시간대는 역할이 다릅니다. 화면에 뉴욕 시각을 추가로 표시하는 것만으로 기존 반복 일정의 기준이 뉴욕으로 바뀌지는 않습니다.
이미 초대를 받았다면 주최자에게 한 문장만 확인하세요
“이 회의는 뉴욕 오전 9시 고정인가요, 서울 밤 10시 고정인가요?”라는 질문이면 됩니다. 뉴욕 기준이 맞고 두 회차가 표와 일치한다면, 한국 쪽 참석 시간을 밤 11시로 받아들이는 것이 합의에 맞습니다. 한국 쪽 밤 10시를 유지하려면 뉴욕 팀의 오전 8시 참석에 대한 새 합의가 필요합니다.
개발자 Jeff McKay도 2024년 Stack Overflow에서 API로 만든 반복 일정이 서머타임 구간에서 예상과 달라지는 경험을 남겼습니다. 해결 답변이 없는 사례여서 지금의 웹 캘린더 오류를 입증하지는 않습니다. 다만 첫 회차가 맞는 것만으로 이후 회차까지 맞다고 판단하기 어렵다는 점을 보여 줍니다.
초대된 개별 회차가 표와 다르다면 그 날짜가 예외로 수정됐는지, 실제 일정의 기준 시간대가 무엇인지부터 확인하세요. 주최자가 반복 일정을 수정할 때는 어느 회차에 적용할지도 선택합니다. 원인을 확인하기 전에 전체 일정을 일괄 이동하면 이미 별도로 조정한 회차까지 영향을 받을 수 있습니다.
확인할 때는 “지금 시각” 대신 회의 날짜를 넣습니다
오늘의 뉴욕 시각을 보여 주는 시계만으로 11월 회의를 검산하면 서머타임 경계를 놓칠 수 있습니다. 확인 대상은 도시 두 곳, 회의 날짜, 고정할 현지 시각입니다. 이 세 가지를 초대 설명과 대조해 두면 다음 시간 변경 때도 같은 방식으로 판단할 수 있습니다.
2026년 10월 27일 공식 도움말과 NIST 자료를 확인하고, Python 시간대 변환으로 표의 네 경우를 검산했습니다. 실제 Google 계정에서 초대 발송·외부 캘린더 동기화까지 재현한 것은 아닙니다. 이미 수정된 예외 회차나 다른 나라의 시간대 규칙에는 이 표를 그대로 적용하지 마세요.
확인한 자료
본문의 근거와 관련 내용을 원문에서 살펴보세요.



