캘린더 초대에 잘못된 시간이 표시되는 이유

캘린더의 시간대 문제는 비슷한 모습으로 나타납니다. 내 화면에는 회의가 09:00에 시작한다고 나오는데, 초대한 사람에게는 15:00로 표시됩니다. 단순히 현지 시간이 다른 것일 수도 있지만, 실제 시작 시점이 서로 다르게 전달된 것일 수도 있습니다. 몇 주 동안 맞던 일정이 시계를 바꾼 뒤 한 시간 밀리거나, 자는 동안 알림이 오는 경우도 있습니다.

원인은 화면 표시가 아닐 때가 많습니다. 일정에 ‘9시’만 저장하고 어느 시간대의 9시인지를 기록하지 않으면, 이후 처리 과정에서 빠진 정보를 각자 추정합니다. 가정이 다르면 결과도 달라집니다.

캘린더가 시간대를 표현하는 방식, 오류가 몇 주 뒤에 드러나는 이유, 일정의 시간과 시간대를 함께 저장하면 달라지는 점을 살펴보겠습니다.

시간대 없는 시각의 문제

캘린더가 시작 시간을 2026-09-14 09:00로만 저장한다고 가정해 보겠습니다. 여러 사람이 참석하는 회의에는 이 정보만으로 부족합니다. 시스템 구성 요소마다 다르게 해석할 수 있기 때문입니다.

브라우저 입력 양식은 사용자가 입력한 시각을 보냅니다. CalDAV 클라이언트는 시간대 식별자도 보내지만, 서버가 이를 무시하면 현지 시계의 값만 남습니다. 내보내기 형식이 명확한 시간 표현을 요구한다는 이유로 이 값에 잘못된 UTC 표시를 붙일 수도 있습니다. 한편 알림 서비스는 저장된 값을 현재 UTC 시각과 비교합니다.

같은 값에 대해 네 구성 요소가 네 가지 해석을 하는 셈입니다. 모두 UTC를 사용하면 문제를 발견하지 못할 수 있습니다. 베를린의 참석자가 추가되는 순간 일부 일정이 다르게 처리될 수 있지만, 오류 메시지는 나오지 않습니다.

한 시간대에서만 테스트하면 이런 오류를 놓치기 쉽습니다. 여러 지역의 사용자를 가정한 테스트는 문제를 미리 찾는 데 도움이 됩니다. 그렇지 않으면 여행, 시계 변경, 다른 시간대의 사람에게 보낸 첫 초대를 계기로 문제가 드러납니다.

캘린더 시각을 표현하는 세 가지 방식

시간대 없는 시각, 즉 ‘floating time’은 그런 동작을 의도했다면 유효합니다. 하지만 예를 들어 14일인 생일은 보통 시간대 없는 시각이 아니라 날짜로 표현합니다. 공동 회의에서는 같은 현지 시각이 서로 다른 실제 시점을 가리킬 수 있습니다.

종일 일정은 날짜로 저장하며 시간대 간 변환을 하지 않습니다. 공휴일을 UTC 시점으로 바꾼 다음 현지 시간으로 되돌리면 그리니치 서쪽에서는 전날 저녁으로 표시될 수 있습니다. 날짜를 회의 시작 시점처럼 처리해서는 안 됩니다.

시계 변경이 오류를 드러내는 이유

UTC와의 차이가 늘 일정하다면 시간대 처리는 더 간단할 것입니다. 하지만 많은 지역에서는 그 차이가 바뀌며, 전환을 계기로 숨어 있던 오류가 드러납니다.

베를린은 겨울에 UTC+1, 여름에 UTC+2를 사용합니다. 반복 회의를 고정 UTC 시각으로 계산하면 전환 뒤 현지 시계에서 한 시간 이동합니다. 실제 시점은 명확하지만 더 이상 오전 9시 회의는 아닙니다. Europe/Berlin 일정이 오전 9시를 유지하려면 반복 규칙도 해당 시간대에서 계산해야 합니다. 시간대 이름을 저장하는 것만으로는 충분하지 않습니다.

참석자가 여러 나라에 있으면 더 복잡해집니다. 유럽과 북미는 서로 다른 날짜에 시계를 바꿉니다. 두 전환 사이에는 런던과 뉴욕의 평소 시차가 한 시간 달라집니다. 이 기간은 계절과 연도에 따라 길이가 달라지므로 항상 같다고 가정하면 안 됩니다. 캘린더가 정상이어도 한쪽 참석자의 현지 회의 시간이 일시적으로 달라질 수 있습니다.

기본 시간대를 바꾸는 것으로는 이 차이를 없앨 수 없습니다. ‘같은 실제 시점’과 ‘같은 현지 시각’은 다른 요구사항입니다. 반복 일정이 어떤 동작을 해야 하는지 정하고, 반복 계산과 클라이언트 간 교환에서도 그 동작이 유지되는지 확인해야 합니다.

UTC와 시간대를 함께 저장하기

구체적인 시간이 있는 일정에는 정확한 UTC 시점과 현지 시간을 입력할 때 사용한 시간대를 함께 저장하는 것이 좋습니다. 반복 일정에서는 반복 규칙을 계산하는 방식도 중요합니다.

UTC는 시점 비교, 일정 정렬, 겹치는 일정 확인을 명확하게 만듭니다. 시간대는 원래 현지 시간이 무엇을 뜻했는지 알려 줍니다. 다만 이 필드를 저장해도 모든 내보내기 방식이 반복 일정의 정보를 온전히 보존하는 것은 아닙니다. 출력 형식과 클라이언트의 처리 방식을 따로 확인해야 합니다.

실제 사용에서는 다음과 같이 동작합니다.

• 웹메일에서 일정을 만들면 입력한 시간과 함께 브라우저 시간대를 보냅니다. 서버는 시간을 UTC로 변환하고 시간대를 저장합니다. 브라우저가 베를린으로 설정되어 있다면 베를린이 기록됩니다.
• 다른 곳에서 일정을 보면 UTC가 브라우저의 현지 시간으로 변환됩니다. 예시 날짜에는 베를린에서 09:00, 샌프란시스코에서 00:00로 표시됩니다. 같은 실제 시점이지만 다른 시기에는 시차가 달라질 수 있습니다.
• 알림은 비교에 사용할 명확한 시점을 얻습니다. 시간대 때문에 생기는 이 모호함은 사라지지만, 전달 여부는 작업 스케줄러와 알림 경로의 작동 상태에도 달려 있습니다.
• 수정할 때는 현재 브라우저 시간대의 시간이 표시됩니다. 일정의 원래 시간대와 같다는 보장은 없습니다. 특히 여행 후에는 저장 전에 시간과 기기 설정을 확인하세요.

기존 일정의 처리 방식

오래된 일정에는 시간대가 저장되어 있지 않을 수 있습니다. 시스템은 이를 자동으로 다시 해석하지 않고 웹 화면의 기존 표시 방식을 유지합니다. 이미 있는 약속이 갑자기 이동하는 것을 막기 위해서입니다.

이는 의도적인 선택입니다. 나중에 시간대를 지정하려면 추정이 필요하고, 틀린 추정은 동의 없이 일정을 바꿉니다. 두 해 동안 14:00로 표시된 일정을 자동 수정으로 다른 시간으로 바꾸면 안 됩니다. 수동으로 검토할 때는 그 14:00가 원래 무엇을 뜻했는지 먼저 확인하세요.

기존 일정을 수정하면서 시간대를 추가할 수 있습니다. 웹메일은 시간이 있는 일정을 저장할 때 브라우저 시간대를 보내므로 현지 시간과 기기 설정부터 확인해야 합니다. API로 설명만 수정하면서 시간대 매개변수를 보내지 않으면 누락된 정보가 추가되지 않습니다. 수정하지 않은 일정은 기존 동작을 유지합니다.

오래된 반복 회의가 해외 참석자에게 잘못 표시된다면 원래 시간과 시간대를 확인하고 수정 사항을 저장하세요. 그런 다음 시계 변경 전후의 반복 일정도 확인해야 합니다. 다시 저장하는 것만으로 전체 반복 계산이 올바르게 바뀌는 것은 아닙니다.

CalDAV, ICS와 다른 캘린더

캘린더는 웹 화면 밖에서도 사용할 수 있어야 합니다. Apple Calendar, Thunderbird, 호환되는 모바일 앱은 CalDAV로 연결할 수 있습니다. 하지만 기기에 Google 캘린더가 있다고 해서 임의의 CalDAV 서버에 연결할 수 있는 것은 아닙니다. 연동 방식과 호환성을 별도로 확인해야 합니다.

CalDAV로 일정을 받으면 서버는 시간대 식별자를 이용해 해당 UTC 시점을 저장합니다. 받은 원본 캘린더 문서를 그대로 돌려줄 수도 있고, 웹메일에서 만든 일정은 UTC 값으로 생성합니다. 따라서 모든 응답이 같은 형식을 사용하는 것은 아닙니다. 종일 일정은 날짜로 교환합니다. 반복 일정에서는 교환 후에도 현지 반복 시간이 유지되는지 확인하세요.

호환되는 클라이언트는 같은 실제 시점을 보여 줄 수 있습니다. 예를 들어 베를린의 iPhone에서 만든 일정을 리스본의 노트북에서 웹메일로 수정하고 뉴욕의 Thunderbird에서 열어도 같은 시점을 나타낼 수 있습니다. 각 지역의 현지 시간은 다릅니다. 클라이언트와 기기가 올바르게 설정되어 있어야 하며, 시간대 이름은 IANA 시간대 데이터베이스를 따릅니다.

클라이언트별 설정 안내를 참고하세요. macOS의 Apple Calendar, iPhone과 iPad, DAVx⁵를 사용하는 Android, Thunderbird 안내가 있습니다. Outlook은 보통 CalDAV용 타사 추가 기능이 필요하며, 버전별 제약은 Outlook 연결 안내에서 확인할 수 있습니다.

시간대 오류를 예방하는 방법

국제 회의 제목에 시간대를 적으세요. ‘주간 회의 (09:00 CET)’는 메일 클라이언트가 초대를 잘못 표시할 때 참고가 됩니다. 하지만 CET는 겨울의 표준시이며, 베를린은 여름에 CEST를 사용합니다. 일 년 내내 CET를 쓰지 말고 날짜에 맞는 약어나 참석자가 알아볼 수 있는 도시 이름을 쓰세요.

반복 일정을 기준이 되는 시간대에 맞추세요. 베를린 사무실의 시계에 맞춰야 하는 회의라면 그 시간대를 사용하고 반복 계산도 해당 시간대를 따르는지 확인하세요. 해외 참석자의 현지 시간은 전환 기간에 바뀔 수 있습니다. 회의가 변경된 것이 아니라 지역 간 시차가 변한 것일 수 있습니다.

시계를 바꾸는 시기에는 중요한 회의를 다시 확인하세요. 유럽과 북미는 전환 날짜가 다르므로 평소 시차가 일시적으로 달라집니다. 구체적인 날짜를 확인하고 양쪽의 현지 시간을 글로 남겨 서로 확인하세요.

날짜만 중요하다면 종일 일정을 사용하세요. 컨퍼런스가 열리는 날을 표시하기에 적합합니다. 정해진 시간에 참석해야 한다면 날짜만 적지 말고 시간과 시간대가 있는 일정을 만드세요. 시간이 필요 없는 일정에 임의의 시작 시간을 붙이지 마세요.

자주 묻는 질문

다른 시간대의 참석자에게 회의 시간이 다르게 보이는 이유는 무엇인가요?

현지 시간이 달라도 같은 실제 시점을 나타내는 것은 정상입니다. 실제 시작 시점이 서로 다르게 전달되었을 때가 문제입니다. 일정 시간대와 클라이언트 설정을 확인하세요. 시간대가 누락되어 있었다면 원래 시간을 확인한 뒤 올바른 시간대를 저장하고 참석자와 결과를 확인하세요.

반복 회의가 한 시간 이동한 이유는 무엇인가요?

서머타임과 표준시 사이의 전환 때문일 수 있습니다. 고정 UTC 시각의 반복 일정은 그 시각을 유지하지만 현지 시계에서는 달라집니다. 현지 시간대에서 계산하는 일정은 현지 시각을 유지하고 다른 지역에서는 이동할 수 있습니다. 원하는 동작은 약속에 따라 다르므로 반복 계산과 내보내기 방식을 확인하세요.

웹메일에서 일정을 만들면 어느 시간대를 사용하나요?

웹메일은 브라우저 시간대를 읽고 시간이 있는 일정과 함께 보냅니다. 서버는 UTC 시점과 시간대를 저장합니다. 현재 위치와 다른 시간대에 맞춰야 하는 회의라면 특히 생성 전에 기기 설정을 확인하세요.

종일 일정도 시간대 변환을 하나요?

아니요. 시점이 아니라 날짜로 저장합니다. 날짜를 UTC를 통해 변환하면 다른 시간대의 사람에게 전날이나 다음 날로 보일 수 있습니다.

시간대를 저장하기 전에 만든 일정은 어떻게 되나요?

자동으로 시간대를 지정하지 않고 기존 동작을 유지합니다. 웹메일은 시간이 있는 일정을 저장할 때 브라우저 시간대를 추가하므로 먼저 시간과 기기 설정을 확인하세요. API 업데이트에서 시간대를 명시하지 않으면 오래된 기록에는 추가되지 않습니다.

Apple Calendar와 Google 캘린더에서도 시간대가 올바르게 처리되나요?

호환되는 CalDAV 클라이언트를 올바르게 설정하면 일정 시간을 변환할 수 있습니다. Apple Calendar에는 연결 안내가 있습니다. Google 캘린더는 사용할 수 있는 연동 방식을 확인해야 하며, 임의의 외부 CalDAV 서버와 연결된다고 보장할 수 없습니다. 반복 일정과 서머타임 전환도 확인하세요.

API에서 시간대를 명시할 수 있나요?

네. 일정 생성과 업데이트용 REST API는 시간대 매개변수를 받습니다. MCP에서는 도구 스키마를 확인하고 지원하는 경우 해당 필드를 보내세요. 매개변수를 생략해도 시스템이 원하는 시간대를 항상 추정할 수 있는 것은 아닙니다.

오래된 일정의 알림이 잘못된 시간에 오는 이유는 무엇인가요?

시간대 없이 저장한 시각을 현재 실제 시점과 비교하면 결과가 잘못될 수 있습니다. 원래 시간을 확인하고 맞는 시간대를 저장한 뒤 알림을 테스트하세요. 문제가 계속되면 알림 설정과 작업 스케줄러의 작동 상태도 확인해야 합니다.