AI에게 해외 일정이나 작업 기록을 한국 시간으로 정리해 달라고 했는데, 날짜가 하루 밀리거나 시간이 9시간 어긋날 수 있습니다. 원문이 UTC인지, 이미 한국 시간인지, 시각 없이 날짜만 적힌 것인지 먼저 나누면 같은 오류를 반복해서 고치기 쉽습니다. 아래는 특정 앱의 예약 기능 설명이 아니라, AI가 만든 일정표를 검수하는 방법입니다.
자료 확인일: 2026년 11월 7일. 예시는 계산을 위한 가상 일정이며 실제 예약이나 초대가 아닙니다.
시간을 바꾸기 전에 원문을 네 가지로 나누세요
인터넷 시각 표준인 RFC 3339는 날짜·시각과 UTC 오프셋을 함께 표현합니다. 오프셋은 현지 시각에서 UTC를 뺀 값입니다. 따라서 +09:00이 붙은 시각을 UTC로 옮길 때는 9시간을 빼며, UTC를 한국 시간으로 옮길 때는 9시간을 더합니다. 다만 한국어로 적힌 문장이라는 이유만으로 한국 시간이라고 판단하면 안 됩니다.
| 원문 예시 | 분류 | 처리 원칙 |
|---|---|---|
| 2026-11-08T00:30:00Z | UTC 시각 | 한국 시간으로 변환 |
| 2026-11-08T09:30:00+09:00 | 오프셋이 있는 시각 | 한국 시간과 일치하는지 확인 |
| 2026-11-08 09:30 | 시간대가 없는 시각 | 출처의 시간대를 확인할 때까지 보류 |
| 2026-11-08 | 날짜만 있는 값 | 시각과 시간대를 임의로 만들지 않음 |
세 번째 값은 실제로 한국 시간일 수도 있고 다른 지역의 현지 시각일 수도 있습니다. 네 번째 값은 기념일, 마감일, 종일 일정 등 여러 뜻이 가능하므로 곧바로 ‘UTC 자정’으로 바꾸면 안 됩니다. Google Calendar 공식 이벤트 문서도 종일 일정에 쓰는 date와 시각을 담는 dateTime을 구분합니다. 날짜만 있다는 사실만으로 종일 일정까지 확정하지 말고 원문의 뜻을 확인하세요.
자정을 넘는 예제 두 개로 방향을 확인하기
첫째, 2026년 11월 7일 21:30 UTC에 9시간을 더하면 11월 8일 06:30 한국 시간입니다. ‘21+9=30’만 계산한 뒤 날짜를 그대로 두면 틀립니다. 24시간을 넘은 6시간 30분이므로 날짜도 하루 넘어갑니다.
둘째, 2026년 11월 8일 02:00 한국 시간에서 9시간을 빼면 11월 7일 17:00 UTC입니다. 반대로 이미 +09:00이 붙은 11월 8일 09:30에 다시 9시간을 더해 18:30으로 만드는 것은 이중 변환입니다. 변환 전후를 나란히 두면 이런 실수를 바로 찾을 수 있습니다.
AI에는 최종 시각뿐 아니라 확인 근거도 요청하세요
Google의 프롬프트 안내는 명확한 지시, 출력 형식, 입력과 출력의 예시를 제시하는 방법을 설명합니다. 이를 일정 정리에 적용한 다음 문구는 직접 수정해 쓸 수 있습니다.
요청 예시: “아래 자료를 한국 시간 기준으로 정리해 주세요. 열은 원문 ID, 원문 날짜·시각, 원문 시간대 근거, 한국 날짜·시각, 확인 상태로 만드세요. 원문은 수정하지 마세요. Z 또는 명시된 UTC 오프셋이 있을 때만 변환하고, 시간대가 없으면 ‘확인 필요’로 남기세요. 날짜만 있는 값에는 00:00을 붙이지 마세요. 결과가 자정을 넘으면 날짜도 바꾸세요. 2026-11-07T21:30:00Z의 결과는 2026-11-08 06:30 한국 시간입니다.”
이 요청만으로 정확성이 보장되지는 않습니다. 입력 행에 A001, A002처럼 고유 ID를 붙이고, 출력에서 같은 ID가 한 번씩 있는지 확인하세요. 시간이 틀린 문제와 행이 빠지거나 두 번 들어간 문제를 따로 찾을 수 있습니다. 이메일 서명이나 무관한 개인정보는 빼고 날짜 판단에 필요한 문맥만 전달하는 편이 좋습니다.
전체 재요청과 오류 행 재검토를 비교하기
가령 80행 중 6행의 시간대가 불명확하다면, 80행을 매번 새로 정리하기보다 원문을 보존한 채 그 6행의 근거부터 확인하세요. 이미 맞는 결과를 새 답변으로 덮어쓸 위험도 줄일 수 있습니다. 모든 행을 처음 한 번 대조한 뒤, 두 번째 검토에 행당 30초가 걸린다고 가정하면 전체 재검토는 40분, 6행만 재검토하면 3분입니다. 이는 작업량을 설명하는 계산이며 실제 측정한 속도나 AI 요금 절감률이 아닙니다.
API를 쓴다면 입력·출력 토큰, 재시도 횟수와 사용 모델을 따로 기록해야 비용을 비교할 수 있습니다. 행 수가 92.5% 줄었다고 청구액도 같은 비율로 줄지는 않습니다. 긴 공통 지시문과 출력 길이도 비용에 영향을 줍니다.
캘린더에 옮기기 전 마지막 점검
- 원문과 결과의 ID·행 수가 맞고, 원문 시간대의 근거가 남아 있나요?
- UTC에서 한국 시간으로 더했는지, 한국 시간에서 UTC로 뺐는지 확인했나요?
- 자정 전후의 날짜와 날짜만 있는 값의 의미를 따로 확인했나요?
- 해외 현지 시각의 반복 일정은 도시·날짜별 서머타임 규칙을 확인했나요?
- 저장한 일정의 실제 표시 시간대와 날짜를 원문에 다시 대조했나요?
UTC 오프셋 하나는 특정 시점의 차이를 알려줍니다. 해외 도시의 몇 달 뒤 반복 일정까지 같은 차이로 계산해도 된다는 뜻은 아닙니다. AI의 표는 검토용 중간 결과로 쓰고, 중요한 회의나 마감은 원문과 최종 저장 화면을 함께 확인하세요.