캘린더 연동 AI 비서의 요일 착각 문제 — LLM이 날짜 계산을 틀리는 이유와 대응법

발단: AI 비서가 2월 14일을 금요일이라고 답했다

캘린더와 연동된 개인 AI 비서 '이든'에게 이번 주와 다음 주 일정을 물었습니다. 이든은 API를 통해 일정 데이터를 정상적으로 가져왔고, 일정 목록을 깔끔하게 정리해 보여주었습니다.

📅 이번 주 (2월 10일 ~ 16일)
- 2/11 (화) 16:00 - 내용
- 2/14 (금) 15:00 - 내용

문제는 2월 14일이 금요일이 아니라 토요일이라는 점이었습니다. "2월 14일이 금요일이야?"라고 되물었더니, 이든은 즉시 날짜를 다시 확인하고 토요일로 정정했습니다.

사소해 보이는 이 에피소드에는 LLM 기반 AI 비서를 실무에 적용할 때 반드시 알아야 할 구조적 한계가 담겨 있습니다.

원인: LLM은 날짜-요일 매핑을 "계산"하지 않는다

LLM이 날짜와 요일을 틀리는 근본 원인은 명확합니다. LLM은 계산기가 아니라 패턴 매칭 엔진이기 때문입니다.

1. 훈련 데이터 기반의 확률적 추론

LLM은 "2월 14일은 발렌타인데이이고, 발렌타인데이는 금요일에 자주 언급된다"와 같은 훈련 데이터의 통계적 패턴에 의존합니다. 2026년의 달력을 참조하는 것이 아니라, 과거 텍스트에서 가장 그럴듯한 요일을 생성하는 것입니다.

2. 윤년, 연도별 차이를 내재적으로 처리할 수 없음

같은 2월 14일이라도 해마다 요일이 다릅니다. 이 매핑은 단순 패턴이 아니라 모듈러 연산을 필요로 합니다.

2024년 2월 14일 → 수요일
2025년 2월 14일 → 금요일
2026년 2월 14일 → 토요일

LLM은 이 계산을 수행하는 것이 아니라, 가장 높은 확률의 토큰을 선택합니다. 2025년 훈련 데이터에서 "2월 14일 금요일"이 빈번했다면, 2026년에도 금요일을 출력할 가능성이 높습니다.

3. 캘린더 API는 날짜만 반환하고 요일은 반환하지 않는다

제 캘린더 API의 응답을 살펴보면, 일정의 날짜는 ISO 8601 형식으로만 제공됩니다.

{
  "properties": {
    "Date": {
      "date": {
        "start": "2026-02-14T15:00:00+09:00",
        "end": null
      }
    }
  }
}

여기에는 saturday나 토요일 같은 요일 정보가 없습니다. LLM이 이 날짜를 사용자에게 보여줄 때 요일을 자체적으로 추론해야 하는데, 바로 이 지점에서 오류가 발생합니다.

대응법 1: 시스템 프롬프트에 현재 날짜와 요일을 명시한다

가장 기본적인 방어선은 시스템 프롬프트에 오늘 날짜와 요일을 주입하는 것입니다.

# 시스템 정보
- 현재 날짜: 2026-02-11 (수요일)
- 이번 주: 월(2/9) ~ 일(2/15)

이렇게 하면 LLM이 "오늘이 수요일이고 2월 11일"이라는 앵커 포인트를 가지게 되어, 2월 14일까지 3일 뒤 = 토요일이라는 상대적 추론이 가능해집니다. 하지만 이것만으로는 충분하지 않습니다. 2주 뒤, 한 달 뒤의 날짜에 대해서는 여전히 틀릴 수 있습니다.

대응법 2: 도구 호출로 요일 계산을 위임한다

LLM이 날짜 계산을 직접 하지 않도록, 외부 도구에 위임하는 것이 가장 확실한 해결책입니다.

from datetime import datetime

def get_day_of_week(date_str: str) -> str:
    """ISO 날짜 문자열에서 요일을 반환"""
    dt = datetime.fromisoformat(date_str)
    days = ["월요일", "화요일", "수요일", "목요일",
            "금요일", "토요일", "일요일"]
    return days[dt.weekday()]

MCP(Model Context Protocol) 서버나 function calling 도구로 이 함수를 등록해두면, LLM이 날짜를 표시할 때 자동으로 이 도구를 호출하게 할 수 있습니다.

{
  "name": "get_day_of_week",
  "description": "주어진 날짜의 요일을 정확히 반환합니다. 날짜를 사용자에게 보여줄 때 반드시 이 도구를 사용하세요.",
  "input_schema": {
    "type": "object",
    "properties": {
      "date": {
        "type": "string",
        "description": "ISO 8601 형식의 날짜 (예: 2026-02-14)"
      }
    },
    "required": ["date"]
  }
}

핵심은 도구 설명에 **"날짜를 보여줄 때 반드시 사용하라"**는 지시를 포함하는 것입니다. 그렇지 않으면 LLM은 도구를 호출하지 않고 자체 추론으로 요일을 생성할 수 있습니다.

대응법 3: 데이터 전처리 단계에서 요일을 포함시킨다

API 응답을 LLM에 전달하기 전에, 전처리 레이어에서 요일 정보를 미리 추가하는 방법입니다.

from datetime import datetime

def enrich_notion_events(events: list) -> list:
    days = ["월", "화", "수", "목", "금", "토", "일"]
    for event in events:
        date_str = event["date"]["start"]
        dt = datetime.fromisoformat(date_str)
        event["day_of_week"] = days[dt.weekday()]
        event["formatted"] = f"{dt.month}/{dt.day} ({event['day_of_week']})"
    return events

이렇게 하면 LLM에 전달되는 데이터가 처음부터 요일을 포함하게 됩니다.

전처리 전: {"start": "2026-02-14T15:00:00+09:00", "title": "내용"}
전처리 후: {"start": "2026-02-14T15:00:00+09:00", "title": "내용",
           "day_of_week": "토", "formatted": "2/14 (토)"}

LLM이 추론할 필요 자체를 없애는 것이 가장 안전합니다.

세 가지 대응법 비교

실무에서는 세 가지를 조합하는 것을 권장합니다. 시스템 프롬프트로 기본 컨텍스트를 제공하고, API 데이터는 전처리로 보강하며, 사용자가 임의의 날짜를 물어볼 경우를 대비해 도구 호출을 등록해두는 것입니다.

핵심 정리

LLM 기반 AI 비서를 캘린더나 일정 관리에 활용할 때 기억해야 할 체크리스트입니다.

1. LLM은 날짜-요일 매핑을 확률적으로 추론한다 — 계산이 아니라 패턴 매칭이므로 틀릴 수 있습니다
2. 시스템 프롬프트에 현재 날짜/요일을 반드시 주입하세요 — 앵커 포인트 없이는 연도조차 틀릴 수 있습니다
3. 날짜 관련 외부 도구를 등록하고, 사용을 강제하세요 — 도구 설명에 "반드시 사용" 지시를 포함해야 합니다
4. 가능하다면 데이터 전처리 단계에서 요일을 추가하세요 — LLM의 추론 부담을 줄이는 것이 가장 확실한 방어입니다
5. 숫자 계산이 필요한 모든 영역에 같은 원칙을 적용하세요 — 날짜뿐 아니라 금액 계산, 단위 변환 등도 동일한 패턴입니다

LLM의 강점은 자연어 이해와 맥락 파악입니다. 정확한 계산은 코드에 맡기고, LLM에게는 그 결과를 사람에게 자연스럽게 전달하는 역할을 맡기는 것이 올바른 역할 분담입니다.