“다음 주 화요일에 봐요” 같은 말을 일정으로 바꾸려면 기준 날짜가 필요합니다. 그런데 저는 이 기준을 무엇으로 둘지에서 한 번 막혔습니다. 처리하는 시점과 말한 시점이 다르기 때문입니다. 이 글은 그 차이가 왜 문제가 되는지, 그리고 제가 어떤 기준으로 정했는지에 대한 기록입니다.
기준이 두 개였다
녹음된 대화를 글로 바꾸고 그 안에서 일정을 찾는 기능이었습니다. 여기서 시점이 두 개 생깁니다.
- 말한 시점 — 실제로 그 문장이 발화된 때
- 처리한 시점 — 나중에 글로 바꾸고 분석한 때
둘이 같은 날이면 문제가 없습니다. 그런데 며칠 뒤에 처리하면 “다음 주 화요일”이 가리키는 날이 통째로 밀립니다. 처리 시점을 기준으로 삼으면 실제로 약속한 날과 다른 날이 등록됩니다.
말한 시점을 기준으로 고정했다
그래서 기준을 ‘처리한 때’가 아니라 ‘원래 기록이 만들어진 때’로 못 박았습니다. 나중에 언제 처리하든 결과가 같아지도록 한 것입니다.
이 기준을 지키려면 한 가지가 더 필요했습니다. 글로 바꾼 결과에 그 기준 시각을 같이 저장하는 일입니다. 저장해 두지 않으면 나중에 다시 분석할 때 또 처리 시점을 쓰게 됩니다. 그래서 저장 형식에 기준 시각 자리를 따로 만들었습니다.
그래도 자동 등록은 하지 않았다
기준을 고정했다고 해서 해석이 항상 맞는 것은 아닙니다. “담주 초”, “그때쯤” 같은 표현은 사람도 애매하게 씁니다.
그래서 찾아낸 일정은 후보로만 보여주고 등록은 사람이 확인한 뒤에 하도록 했습니다. 화면에서 날짜를 보고 맞으면 넘기고, 틀리면 고치는 방식입니다. 자동으로 넣으면 편하지만, 틀린 일정이 조용히 쌓이는 쪽이 더 나쁘다고 봤습니다.
같은 문제를 만날 때
이건 특정 기능만의 문제가 아닙니다. 나중에 처리하는 모든 기록에 같은 함정이 있습니다. 메모, 녹취, 메시지 백업 어디서든 “어제”, “다음 달” 같은 말이 나오면 기준이 필요합니다.
정리하면 세 가지입니다. 기준 시각을 원본이 만들어진 때로 잡고, 그 시각을 결과에 같이 저장하고, 해석 결과는 사람이 확인하게 한다는 것입니다. 아직 실제 기기에서 다양한 표현을 얼마나 정확히 해석하는지는 측정하지 못했고, 그 부분은 미검증으로 남겨 두었습니다.
공식 문서가 말하는 날짜 표현의 기준
상대 날짜 문제는 직접 구현할 때만 생기는 것이 아닙니다. 흔히 쓰는 날짜 도구와 캘린더 API가 기준 날짜와 시간대를 어떻게 다루는지 공식 문서로 보면 이 글의 결정이 왜 필요한지 분명해집니다.
MDN의 Intl.RelativeTimeFormat 문서에 따르면 이 객체는 “1일 전”, “3분기 후” 같은 상대 시간 문구를 언어에 맞게 만들어 줍니다. 생성할 때 언어 코드와 옵션을 받고, 옵션에는 numeric(always 또는 auto), style(long, short, narrow) 등이 있습니다. format(값, 단위)을 호출하면 값과 단위로 문구를 돌려줍니다. 예를 들어 numeric을 auto로 두면 영어에서 -1일이 “yesterday”로 나옵니다. 이 문서에는 기준 날짜나 시간대를 정하는 설명이 없습니다. 즉 이 도구는 이미 계산된 숫자를 문구로 바꾸는 일만 하고, “어느 날을 기준으로 삼을지”는 쓰는 쪽이 정해야 한다는 뜻으로 읽을 수 있습니다(이 부분은 문서의 설명이 아니라 이 글의 해석입니다).
Google Calendar API 문서는 일정의 시간을 두 가지로 나눕니다. 특정 시점은 start.dateTime과 end.dateTime으로, 종일 일정은 start.date와 end.date로 적습니다. 시작과 종료는 둘 다 시각이거나 둘 다 종일이어야 하며, 한쪽은 날짜이고 다른 쪽은 시각인 조합은 유효하지 않다고 명시합니다. 시간대는 IANA 식별자로 지정하고, 요청에서 따로 시간대를 지정하지 않으면 캘린더의 기본 시간대가 조회 결과를 정합니다. 반복 일정은 하나의 시간대를 반드시 지정해야 각 회차를 계산할 수 있다고 합니다.
| 공식 문서의 내용 | 이 글의 결정과 연결되는 점(해석) |
|---|---|
| 상대 시간 문구 도구는 값과 단위만 받는다(MDN) | “다음 주 화요일”을 날짜로 바꾸는 기준은 앱이 따로 들고 있어야 함 |
| 일정은 시각(dateTime)과 종일(date)을 구분한다(Google Calendar API) | “화요일에 봐요”처럼 시각이 없는 말은 종일 후보로 둘지 정해야 함 |
| 시간대는 IANA 식별자로 명시한다(Google Calendar API) | 기준 시각을 저장할 때 시간대까지 함께 저장해야 같은 결과가 나옴 |
| 반복 일정은 단일 시간대가 필요하다(Google Calendar API) | “매주 화요일” 같은 표현은 시간대가 정해진 뒤에야 계산 가능 |
정리하면 말한 시점의 기준 시각을 시간대와 함께 저장해 두는 것은 특별한 사치가 아니라, 일정 데이터가 요구하는 최소한의 정보와 맞닿아 있습니다. 후보로 먼저 보여주고 사람이 확인한 뒤 등록한다는 방식도 같은 맥락입니다. 캘린더에 들어가는 순간 날짜와 시간대는 문서의 규칙대로 확정되기 때문입니다.
확인 자료
기준일: 2026-10-18. 문서 내용은 바뀔 수 있습니다.