메일 반복 일정 취소 검수, 한 회차만 정확히 취소하려면

iTIP 문서를 2026년 11월 9일 확인했습니다. 검증된 취소는 RECURRENCE-ID가 없으면 UID의 시리즈 전체, 있으면 원래 시작값으로 범위를 확인합니다.

매주 화요일 10시 회의 중 이번 주만 12시로 옮겼다고 해 보겠습니다. 그 회차가 취소되면 12시 회의만 사라지고 다음 주 화요일 일정은 남아야 합니다. 취소 알림에 들어 있는 회차 식별값은 원래의 10시입니다. 검수에서 화면의 12시와 원래의 10시를 따로 적어 두면, 연동이 어느 쪽을 기준으로 삼는지 바로 알 수 있습니다.

전체 취소와 한 회차 취소를 어떻게 구분하나요?#

메일에 담긴 유효한 iTIP 일정 취소 알림은 METHOD:CANCEL을 사용합니다. UID는 기존 일정의 시리즈를 찾는 값입니다. 일정을 취소하는 알림에서 RECURRENCE-ID가 없으면 시리즈 전체, 값이 있고 RANGE가 없으면 해당 회차가 대상입니다. RANGE=THISANDFUTURE는 지정한 회차부터 회차 식별값 순서로 이후 범위를 가리킵니다. RFC 5545에 따라 별도 컴포넌트로 정의된 후속 회차는 범위와 별도로 확인합니다. 여러 회차를 각각 지정할 때는 한 CANCEL 안에 같은 UID와 각 회차의 RECURRENCE-ID를 가진 VEVENT를 여러 개 넣을 수 있습니다. RFC 5546 일정 취소 · RFC 5545 회차 식별값

먼저 받은 메시지가 일정 자체를 취소하는지 확인하세요. 참가자 몇 명만 초대에서 제외하는 경우에도 METHOD:CANCEL을 씁니다. RFC 5546은 일정 전체 취소에 STATUS:CANCELLED를 요구하고, 특정 참가자만 제외할 때는 그 상태를 넣지 않도록 규정합니다. 파서가 원문의 RECURRENCE-ID를 누락한 경우에도 전체 취소로 넘어가지 않도록, 필드 부재와 파싱 실패를 구분합니다.

이동한 회차를 포함해 무엇을 검수하나요?#

아래는 가상 주간 회의입니다. 11월 10일 회차를 10시에서 12시로 옮겼고 다음 주 회차는 그대로입니다. 두 값은 한국시간이며 표와 코드는 UTC로 적었습니다. 검수 담당자는 UID와 원래 회차 시작값을 저장된 일정에 대조한 다음, 반영 후보 또는 확인 대기를 기록합니다.

이 함수는 한 개의 VEVENT만 받는 흐름의 예시입니다. verifiedEventCancellation은 필드 추출 완료, 주최자 권한, 메시지 순서, 일정 취소 의도를 앞 단계에서 확인한 결과입니다. recurrenceId와 range는 원문에 각각 없을 때만 undefined로 넘깁니다. 규격이 허용하는 RANGE는 THISANDFUTURE입니다. 예시 함수는 추출은 됐지만 허용되지 않는 RANGE도 보류합니다. originalStarts에는 원래 회차의 비교 키를 넣습니다. 예시 값은 모두 같은 UTC 형식을 사용합니다.

export function cancellationScope(series, notice) {
  if (!notice.verifiedEventCancellation || notice.uid !== series.uid) {
    return "hold-unverified";
  }
  if (notice.range !== undefined) return "hold-range";
  if (notice.recurrenceId === undefined) return "series-candidate";
  if (!series.originalStarts.includes(notice.recurrenceId)) {
    return "hold-unmatched";
  }
  return "occurrence-candidate";
}

실제 인수표에는 원본의 회차 값, 저장된 원래 회차 키, 후보 또는 보류 사유, 변경 전후 일정 상태를 나란히 적습니다. 위 표의 두 번째 행은 이동한 회차가 후보에 포함되는지와 다음 주 일정이 유지되는지 함께 확인합니다. 날짜만 있는 종일 일정과 시각이 있는 일정을 구분하고, 시간대가 있는 값은 파서의 비교 규칙을 별도로 검수합니다. 파서나 캘린더 API를 교체하거나 시간대 처리 규칙을 바꾸면 같은 표본을 다시 돌립니다.

사람이 확인하는 편이 나은 경우는 언제인가요?#

팀이 이미 캘린더에서 취소를 처리하고 메일 자동화는 후속 업무에 알림만 남긴다면, 회차 범위를 자동으로 반영할 이유가 적습니다. 캘린더 쓰기가 필요한 흐름이라면 먼저 자동 반영 범위를 합의하세요. 예를 들어 회차 하나만 자동 후보로 두고 전체 취소와 이후 취소는 승인 대기로 보낼 수 있습니다. 여러 VEVENT가 온 경우도 한 개의 VEVENT만 받는 이 흐름에서는 보류합니다.

메일 본문에 “이번 주 회의 취소”만 있고 구조화된 알림을 확인할 수 없다면 담당자가 캘린더 원본에서 회차를 확인하도록 보냅니다. 쓰기 단계에서는 이미 반영한 취소를 다시 받았을 때 중복 변경이 없는지 별도로 확인합니다. 문장에서 날짜를 읽는 문제는 메일 기한 추출 검수에서 다룹니다.

어떤 문서에서 기준을 확인했나요?#

• RFC 5546 §3.2.5 일정 취소는 전체·개별·이후 회차의 취소 표현과 참가자 제외를 구분합니다. 2009년 12월 공개.
• RFC 5545 §3.8.4.4 회차 식별값은 회차 식별값으로 원래 시작값을 사용하도록 정의합니다. 2009년 9월 공개.
• Google Calendar API 반복 일정 가이드는 이동한 뒤에도 같은 시리즈 내 회차를 식별하는 originalStartTime을 설명합니다. 2026년 9월 17일 갱신.
• 알파카랩스 업무 자동화·API 연동은 실패·중복·재처리와 운영 인수 조건을 협의하는 범위를 공개합니다.

문서와 공개 서비스는 2026년 11월 9일 확인했습니다. 표와 코드는 위 표준을 바탕으로 만든 설계 예시입니다.

자주 묻는 질문#

취소 검수 범위를 정할 때#

첫 범위 협의에서 비식별 알림과 기대 결과로 반복 일정 취소의 적용 범위를 정리합니다. 소요 시간은 표본과 쓰기 범위를 확인한 뒤 협의합니다.