반복 일정 수정 UX: 한 회차·이후 일정·전체와 예외 구분하기

반복 일정을 수정할 때는 두 가지 답이 필요합니다. 무엇을 바꾸는지, 그 변경을 어느 회차에 적용하는지입니다. 저장하기 전에 둘 다 보여 주세요. 이후 회차에 이미 개별 변경이 있다면 그 예외도 미리보기에 포함해야 합니다. 짧은 적용 범위 라벨만으로 모든 영향을 설명할 수는 없습니다.

런던 시간으로 매주 목요일 09:00에 열리는 디자인 리뷰를 생각해 보겠습니다. 11월의 한 회의는 이미 11:00로 옮겨 두었습니다. 이제 주최자는 남은 정기 회의의 시작을 한 시간 늦추고 싶습니다. 새 시간을 모든 회차에 똑같이 적용하면, 여전히 필요한 기존 약속까지 덮어쓰게 됩니다.

날짜 선택 UI 디자인 가이드는 날짜·기간 입력, 제한 조건과 시간대를 다룹니다. 입력값이 유효해진 다음에는 반복 일정 수정 UX가 그 값을 올바른 회차에 연결해야 합니다. 이 글은 네 날짜로 구성한 프로토타입 예제를 통해 그 결정을 설계합니다.

반복 일정의 구성을 읽기 쉽게 보여 주기

첫 설계에서는 끝이 정해진 반복 일정을 사용합니다. 2026년 10월 22일, 10월 29일, 11월 5일, 11월 12일에 각각 45분 동안 열리는 리뷰 네 번입니다. 기본 시작 시간은 09:00이며, 11월 12일 회차만 개별적으로 11:00로 옮긴 상태입니다. 예제의 주최자는 10월 29일 회의가 시작되기 전에 해당 일정을 열고, 그날부터 기본 시간을 10:00로 바꿉니다.

일정 제목, 선택한 날짜, 진행 시간, 기준 시간대, 반복 요약을 함께 표시하세요. ‘매주 목요일 · 총 4회 · 런던 시간’이면 주최자가 알아볼 수 있는 형태입니다. 11월 12일 상세 화면에는 ‘11:00로 개별 변경됨’이라고 표시합니다. 반복 규칙 문자열을 해석하게 하지 말고, 눈에 보이는 차이를 설명하세요.

회차를 옮겨도 원래 반복 일정과의 관계는 남아 있어야 합니다. Google Calendar의 반복 일정 문서는 회차의 현재 시작 시각과, 반복 일정 안에서 그 회차를 식별하는 원래 시작 시각을 구분합니다. 화면에서는 목요일 회의를 금요일로 옮겼더라도 원래 목요일 리뷰였음을 알아볼 수 있어야 한다는 뜻입니다. 관련 없는 추가 회의처럼 보여서는 안 됩니다.

적용 범위마다 무엇이 바뀌는지 구체화하기

적용 범위를 고르는 동안 선택한 회차를 계속 보여 주세요. 이 예제에서는 시간을 수정한 뒤 변경 요약 옆에서 범위를 선택합니다. 범위를 고르면 미리보기만 갱신되고, 아직 저장되지는 않습니다.

이는 이 예제에서 명시적으로 정한 제품 규칙입니다. 실제 서비스는 지난 회차나 예외를 다르게 처리할 수 있습니다. 라벨을 정하기 전에 제품·개발팀과 동작을 합의하세요. 남은 일정만 바꾸는 명령에 ‘전체 반복 일정’이라는 이름을 붙이면 정확하지 않습니다. 선택한 회차 자체가 예외라면, 개별 변경값을 수정하는지 원래 반복 규칙의 기본 시간을 수정하는지도 밝혀야 합니다.

이 선택지는 서로 배타적이므로 하나를 고르는 컨트롤을 사용하세요. 설명에는 첫 적용 날짜와 예외 수를 포함할 수 있습니다. 이전 작업의 넓은 적용 범위를 눈에 띄지 않게 이어받지 마세요. 한 회의의 장소를 바꾸는 작업이 앞서 전체 일정을 옮겼던 결정을 자동으로 물려받아서는 안 됩니다.

최종 버튼은 ‘리뷰 2회 변경 사항 저장’처럼 표현할 수 있습니다. 바로 위에 정확한 날짜를 보여 주세요. 끝이 없는 반복 일정이라면 유한한 전체 횟수를 만들어 내지 말고, ‘10월 29일부터 매주 목요일’처럼 시작 경계와 일부 회차 미리보기를 사용합니다.

일반 회차와 예외를 함께 미리 보기

‘이 일정 및 이후 일정’에는 네 날짜의 결과를 모두 보여 주세요. 이 예제에서는 바뀌지 않는 행까지 보이는 것이 중요합니다. 변경된 행만 나열하면 주최자가 알아야 할 맥락이 사라집니다.

표에는 ‘모든 시각은 런던 시간 기준입니다’라고 표시합니다. 확인 문장은 ‘10월 29일부터 리뷰 2회를 10:00로 옮깁니다. 11월 12일은 11:00로 유지합니다’처럼 쓸 수 있습니다. 색으로 변경 행을 강조하더라도 변경 전후의 시각과 이유만으로 결과를 이해할 수 있어야 합니다.

개별 변경을 보존하는 것은 이 예제에서 선택한 정책이지, 모든 캘린더가 보장하는 동작은 아닙니다. 실제 작업이 개별 변경을 덮어쓴다면 저장 전에 영향을 받는 예외와 최종 값을 나열하세요. 긴 반복 일정에는 개수와 펼쳐 볼 수 있는 목록을 제공합니다. 시간은 그대로이고 장소만 바뀐 예외도 검토해야 합니다. 모든 필드를 초기화하면 주최자가 요청한 변경과 관계없는 정보까지 지워질 수 있습니다.

더 복잡한 수정은 예외가 속했던 원래 회차 자체를 없앨 수도 있습니다. 목요일을 화요일로 바꾸는 일은 시작을 한 시간 늦추는 것과 다릅니다. 앞서 목요일에서 금요일로 옮긴 리뷰는 어떻게 될까요? 서비스가 계산한 실제 결과 회차를 받아 미리보기에 사용하세요. 저장된 예외가 전부 유지되거나, 함께 이동하거나, 사라진다고 시각 디자인에서 임의로 가정해서는 안 됩니다.

시계가 바뀌어도 무엇을 고정할지 밝히기

‘매주 목요일 09:00’에도 시간 기준이 필요합니다. 특정 시간대의 오전 9시를 유지하는 팀 회의는 UTC 시각이 달라질 수 있습니다. UTC 08:00에 고정한 일정은 런던의 시계에서 다른 결과를 만듭니다.

영국은 2026년 10월 25일에 시계를 한 시간 뒤로 돌립니다. 아직 수정하지 않은 원래 리뷰 시간을 기준으로 전후 날짜를 비교하면 차이가 드러납니다.

작업에 맞는 기준을 정하고 반복 요약 가까이에 명시하세요. 이 리뷰에서는 ‘런던 시간 09:00’가 팀의 현지 회의 시간을 일정하게 유지합니다. 원격 참석자에게 ‘내 시간’을 함께 보여 주는 것은 도움이 될 수 있지만, 일정의 기준 시간대를 조용히 대체해서는 안 됩니다. 주최자가 기준 시간대를 바꿀 때는 현지 시계의 시각을 유지하는지, 이미 정해진 실제 순간을 유지하는지 미리 보여 주세요.

RFC 5545는 UTC, 시간대를 지정한 현지 시각, 시간대 지정이 없는 부동 현지 시각을 구분합니다. 특정 시간대와 연결되지 않은 부동 시각은 국제 회의를 간단히 표현하는 안전한 대안이 아닙니다. 같은 명세는 반복 규칙으로 만들어진 유효하지 않은 날짜와 존재하지 않는 현지 시각을 반복 집합에서 제외하도록 규정합니다. 따라서 매월 ‘31일’이나 봄철 시계 변경 구간의 시간에는 목업에서 추측한 날짜가 아닌 실제 발생 회차 미리보기가 필요합니다.

이런 사례를 지원하는 제품이라면 반복 계산 엔진의 결과를 디자인 검토에 가져오세요. 서비스의 실제 정책에 따라 생략되거나 조정된 날짜를 어떻게 설명할지 정합니다. 설명은 영향을 받는 날짜 가까이에 두세요. 여러 화면 떨어진 곳의 일반적인 시간대 각주로는 약속 하나가 사라진 이유를 알 수 없습니다.

취소와 저장 결과도 같은 수정 흐름 안에서 다루기

일정 취소에도 같은 수준의 범위 설명이 필요합니다. ‘11월 5일 리뷰 취소’와 ‘11월 5일 전에 반복 일정 종료’는 결과가 다릅니다. 전자는 이후 리뷰를 남기고, 후자는 서비스 규칙에 따라 남은 예정 회차를 제거합니다. 모호한 ‘일정 삭제’ 확인은 이 차이를 숨깁니다.

한 회차를 취소한 뒤에는 일정 이력이나 적절한 위치에서 결과를 다시 찾을 수 있어야 합니다. 프로토타입에도 다음 회차가 여전히 남아 있음을 보여 주세요. 제품이 지원할 때만 복원을 제공하고, 회차를 복원하면 기존 개별 변경까지 돌아오는지도 설명합니다.

저장 중에는 요청한 범위와 미리보기를 유지하고 실수로 중복 제출하지 않게 합니다. 요청이 실패하면 주최자가 수정한 내용을 남겨 두세요. 응답이 불확실하다면 다시 저장하게 하기 전에 현재 저장 상태부터 확인합니다. 클라이언트가 결과를 모르는 상황에서 ‘변경된 내용이 없습니다’라고 단정해서는 안 됩니다.

미리보기가 열린 동안 다른 사람이 11월 12일 리뷰를 옮겼을 수도 있습니다. 새로 바뀐 회차를 보여 주고, 적용하기 전에 갱신된 영향을 다시 검토하게 하세요. 주최자가 제안한 10:00 시작 시간은 유지해, 처음부터 다시 입력하지 않고 변경 내용을 조정할 수 있게 합니다.

서비스가 구분할 수 있다면 저장 상태와 알림 상태도 나누세요. ‘리뷰 2회가 변경되었습니다’는 일정의 상태이고, ‘초대장을 보냈습니다’는 별도 결과이므로 확인되었을 때만 표시합니다. 모든 참석자가 새 시간을 보거나 수락했다고 약속해서는 안 됩니다.

Pixso에서 적용 범위의 결과를 연결해 보기

Pixso에서 연결된 프레임 다섯 개를 만드세요. 선택한 10월 29일 리뷰, 수정한 시간과 범위 선택, 네 날짜 미리보기, 유지되는 11월 12일 예외의 상세 화면, 저장 후 캘린더입니다. 프레임마다 날짜, 진행 시간과 시간대 표기를 일치시킵니다. 리뷰 행 컴포넌트를 재사용하면 선택·처리 중 상태를 바꿀 때 데이터까지 실수로 바뀌는 일을 줄일 수 있습니다.

Pixso의 프로토타이핑 흐름에서는 인터페이스 요소를 목적지 프레임에 연결하고, 시작 프레임을 정해 상호작용을 미리 볼 수 있습니다. 취소 경로를 포함해 각 범위 선택을 해당 결과 미리보기에 연결하세요. 프레임은 합의한 일정 동작을 표현합니다. 프로토타입 자체가 반복 일정을 계산하거나 실제 캘린더를 갱신하는 것은 아닙니다.

참가자에게 10월 29일부터 일반 리뷰를 10:00로 옮기되, 별도로 약속한 11월 리뷰는 11:00로 유지하게 하세요. 저장 전에 어느 날짜가 바뀌는지 물어봅니다. 저장 후에는 예외를 찾아보고 11월 5일 리뷰만 취소하게 합니다. 예상한 결과와 화면의 결과가 달라지는 지점을 기록하세요.

두 번째 과제는 10월의 시계 변경 전후에도 리뷰를 런던 시간 09:00로 유지하는 것입니다. 올바른 범위를 고르더라도 시간 기준을 설명하지 못한다면 결정에 필요한 정보가 아직 부족합니다. 오해가 생긴 지점의 요약이나 미리보기를 수정하세요. 주최자가 바뀌는 날짜, 남아 있는 예외, 모두가 따라야 할 시간을 구체적으로 설명할 수 있어야 합니다.