예약 시간 오후 3시, 어느 나라 오후 3시야?

시간 선택창을 붙이기 전에, 누구 시간을 약속하는지 정해

해외 참가자도 신청하는 60분 온라인 워크숍을 가정해 보자. 요청은 “예약 화면에서 날짜와 시간을 고르게 해주세요”야. 날짜 선택창 하나면 끝날 것 같지만, 주최자가 입력한 오후 3시를 참가자 컴퓨터의 오후 3시로 읽으면 서로 다른 행사에 예약한 셈이 돼. 먼저 주최자가 정한 한 시점에 모두 접속하는 행사인지부터 확인해.

이번 안건은 주최자가 행사 기준 시간대를 고르고, 참가자는 같은 시점을 자기 시간대로 확인하는 방식으로 잡을게. 반복 수업이나 매장 방문 예약은 범위에서 빼. 그런 서비스는 “매주 현지 시각 3시”나 장소의 영업시간이 기준일 수 있어서 이번 결정을 그대로 옮기면 안 돼.

기획서에는 요청 문장 다음에 시간의 주인과 확정 뒤의 약속을 적어. 시간대 규칙이 바뀌어도 이 온라인 행사의 확정된 시점은 유지하고, 주최자가 시간을 바꾸려면 별도 변경 절차를 거치게 할 거야. 이 결정을 먼저 해야 개발자가 화면마다 서로 다른 기준을 구현하지 않아.

날짜와 시각만 저장하자는 안을 여기서 바꿔

처음에는 입력값을 저장하고 조회할 때 지역에 맞게 바꾸면 되겠다고 생각할 수 있어. 그런데 MDN의 날짜·시간 입력 설명을 보면 입력창 자체에는 시간대가 없어. 화면 언어가 한국어라는 이유로 한국 시간을 붙여도 안 돼. 한국어를 쓰는 참가자가 미국에 있을 수도 있잖아.

시간대는 해당 지역의 시간 규칙을 가리키는 이름이야. 예를 들어 Asia/Seoul은 서울 기준 규칙이고, UTC+09:00은 특정 시각에 UTC보다 9시간 빠르다는 차이값이야. 이름과 차이값은 역할이 달라. 미래 날짜를 다룰 때 오늘의 차이값만 저장하면 계절이나 규칙 변경을 반영하지 못할 수 있어.

그래서 입력 명세를 날짜·시각·행사 시간대 세 항목으로 바꿔. 지원하는 시간대 목록에서 고르게 하고, 브라우저가 알려준 지역은 추천값으로만 써. 사용자가 선택을 확인하기 전에는 확정하지 않아. 설계서에는 언어 선택이 시간대 선택을 바꾸지 않는다는 조건도 함께 적어.

입력한 시간이 실제로 한 번 존재하는지 확인해

날짜 형식이 맞는다고 바로 확정할 수는 없어. 일부 지역은 계절에 따라 시계를 조정해서 아예 없는 시각이나 두 번 나오는 시각이 생겨. 서버에서 해당 날짜와 시간대의 규칙으로 실제 시점 후보를 계산해야 해. 브라우저 입력 검사만 통과했다고 예약을 받지 않는 이유야.

후보가 없으면 “선택한 지역에서는 이 시간이 존재하지 않습니다. 다른 시간을 선택해 주세요.”라고 알려줘. 가장 가까운 시각으로 몰래 바꾸지 않아. 후보가 두 개면 처음 나오는 1시 30분인지, 시계가 돌아간 뒤 다시 나오는 1시 30분인지 구분해 선택받아. 각각의 UTC 차이와 참가자 표시도 같이 보여줘.

하나로 정해지면 최종 확인 화면으로 보내. 서버가 확인 화면의 입력·규칙 버전과 최종 요청을 다시 대조하고 결과가 같을 때만 저장해. 그 사이 규칙이나 주최자의 입력이 바뀌었다면 새 시간을 보여주고 다시 확인받아. 한 번 본 미리보기를 승인 근거로 계속 재사용하지 않는 거야.

재확인 조건을 더 정확하게 정할게. 최종 확인 요청에서 원래 입력, 선택한 겹침 시각, 시간대 규칙 버전 중 하나라도 미리보기와 다르면 기존 확인을 만료시켜. 규칙 버전만 바뀌고 계산된 UTC 시점이 같더라도 새 미리보기를 보여주고 다시 확인받아.

숫자로 대조하면 놓친 조건이 보여

일반적인 한국 시간 예제 하나만 보면 이 설계가 멀쩡해 보여. 그래서 정상 시각, 존재하지 않는 시각, 두 번 나오는 시각을 따로 확인했어. 아래 값은 Python의 zoneinfo로 현지 시각을 UTC로 바꾼 다음 다시 원래 지역으로 돌려 대조했어. 두 후보가 같은 UTC 시점이면 중복을 제거했어.

뉴욕의 2026년 11월 1일 01:30은 UTC 05:30과 06:30 두 후보가 나와. 반대로 3월 8일 02:30은 원래 현지 시각으로 돌아오는 후보가 없어. 구현 검수에서는 사용한 시간대 규칙 버전도 남겨. 라이브러리가 알아서 보정한 값을 정답으로 삼으면 없는 시간까지 정상 예약으로 들어갈 수 있어.

이 글의 상황 선택은 정해 둔 설계 예제를 보여주는 거야. 실제 예약을 저장하거나 알림을 보내지는 않아. 개발에 전달할 때는 이 값을 서버 응답과 대조하는 테스트 자료로 쓰고, 지원할 지역을 추가하면 그 지역의 경계 날짜도 함께 보충해.

확정 기록과 화면에 보여줄 값을 나눠

UTC로 저장하자는 말만 남기면 나중에 왜 그 시간을 골랐는지 확인하기 어려워. 주최자가 입력한 현지 날짜·시각, 행사 시간대, 겹친 시간 중 선택한 차이값, 확정한 공통 시점과 당시 규칙 버전을 함께 남겨. 원래 입력과 현재 표시값을 덮어쓰지 않도록 저장 명세를 나눠줘.

참가자 화면에서는 행사 기준과 내 기준을 같은 자리에서 읽을 수 있게 해. “10월 15일 15:00 · 서울 / 내 시간: 10월 14일 23:00 · 로스앤젤레스”처럼 날짜를 생략하지 않아. 내 시간대를 직접 바꾸는 기능도 둬. 기기 설정이 잘못됐을 때 사용자가 시간을 확인할 수 있어야 하니까.

60분 소요는 경과 시간으로 정할게. 확정된 시작 시점에 60분을 더해 종료 시점을 만들고 각 지역으로 변환해. 시계가 돌아가는 날에 현지 시계 숫자만 빼서 소요 시간을 계산하지 않아. 시작과 끝의 날짜가 다르면 둘 다 보여줘.

AI에는 변환 결과보다 빠진 조건을 먼저 물어봐

AI에 “시간대 예약 기획서를 써줘”라고만 시키면 저장은 UTC로 한다는 설명에서 끝날 수 있어. 이번에는 한 번만 열리는 온라인 행사라는 범위, 확정 뒤에는 시점을 유지한다는 결정, 화면에서 보여줄 두 날짜를 먼저 줘. 아래는 실제 실행한 대화가 아니라 업무에 가져다 쓸 질문 예시야.

답에 “미국 시간으로 변환”이라고만 적혀 있으면 지역이 빠진 거야. 뉴욕과 로스앤젤레스를 구분해 고치고, 겹친 시각을 어떻게 선택할지도 다시 요청해. 수정 질문은 “두 개의 01:30을 구분하는 선택 문구와, 선택하지 않았을 때 서버가 거절하는 조건을 적어줘” 정도로 구체화할 수 있어.

채택 기준은 문장이 매끈한지가 아니야. 위의 정상·공백·겹침 예제에서 같은 시점이 나오고, 없는 시각을 확정하지 않으며, 확정 뒤 기준을 바꾸지 않아야 해. AI가 만든 숫자는 시간대 라이브러리 결과와 대조한 뒤 문서에 넣어. 검증되지 않은 답은 기획의 근거로 올리지 않아.

질문 예시: 해외 참가자가 있는 60분 일회성 온라인 행사를 설계하고 있어. 주최자가 행사 시간대를 확인하고, 확정 뒤에는 같은 UTC 시점을 유지할 거야. 입력부터 최종 확인까지 빠진 조건을 찾아줘. 현지 시각이 없거나 두 번 나오는 경우, 기기 시간대 변경, 미리보기 후 규칙 변경을 나눠서 화면 안내와 서버 거절 조건을 적어줘. 반복 일정은 제외해.

일정을 바꾸는 일과 알림을 보내는 일을 구분해

확정한 뒤 주최자가 시간을 수정하는 경우는 단순한 화면 재표시가 아니야. 변경안을 먼저 보여주고 명시적으로 확정받은 다음 일정 버전을 올려. 운영 담당자가 이전·새 시간을 대조할 수 있게 남기고, 영향을 받는 참가자에게 새 일정으로 연결되는 알림을 보내.

알림 전송이 실패했다고 이미 바뀐 일정을 예전으로 돌리지는 않아. 예약 내역은 새 버전을 보여주고 실패한 발송만 재처리해. 중복 발송을 줄이도록 참가자·일정 버전별 발송 결과를 남겨. 알림을 보냈다는 것과 참가자가 읽거나 동의했다는 것도 구분해야 해.

시간대 규칙 업데이트는 운영 점검 대상이야. 이번 정책에서는 확정 시점을 고정하므로 달라지는 건 지역별 표시일 수 있어. 영향을 받은 일정과 참가자를 확인해 안내하고, 주최자가 현지 시계를 유지하려고 한다면 별도 일정 변경으로 처리해. 자동 업데이트가 주최자 승인처럼 동작하게 만들지 마.

QA에는 시간 선택이 된다는 말 대신 이 값을 줘

QA가 화면에서 날짜를 고르고 저장만 해 보면 이 문제를 찾기 어려워. 입력, 선택한 시간대, 기대하는 UTC 시점, 표시 날짜를 한 줄로 이어서 넘겨. 오류일 때는 저장되지 않았는지까지 확인해야 해. 프론트 화면이 막혀 있어도 직접 보낸 요청을 서버가 받아 버리면 같은 문제가 남아.

아래 검수표는 구현 후 확인할 조건이야. 이번에 계산으로 확인한 건 정상·공백·겹침 변환값이고, 예약 저장이나 알림 실패 처리는 실제 서비스에서 별도로 검증해야 해. 기획 검토 결과와 서비스 통합 검수를 같은 완료 표시로 합치지 않아.

내 서비스에 옮길 때는 시간 약속부터 바꿔 적어

가져갈 자료는 아래 전달안이야. 시간대만 바꿔 넣기 전에 네 서비스가 무엇을 약속하는지 먼저 바꿔 적어. 온라인 행사라서 공통 시점을 고정한 건지, 매장 방문처럼 현지 시계와 장소가 더 중요한지 확인해야 해. 후자라면 규칙 변경 때 예약을 유지하는 방법부터 다시 결정해야 해.

기획 담당은 이 범위와 변경 정책을 확정하고, 개발 담당은 지원 시간대와 규칙 업데이트 방식, 서버 판정 결과를 붙여. 디자인은 두 날짜를 읽는 화면과 겹친 시각 선택 화면을 연결하고, QA는 검수표를 실제 응답과 대조해. 운영에는 규칙 업데이트와 발송 실패를 누가 확인할지까지 넘겨.

첫 적용에서는 경계값이 어긋나면 새로운 예약 확정을 막고 원인을 고쳐. 기존 확정 예약의 시점을 일괄 덮어써서 맞추지 않아. 수정한 규칙으로 새 입력을 다시 확인하고, 이미 확정된 일정에 영향이 있는지는 별도 목록으로 검토하는 게 다음 단계야.

일회성 온라인 워크숍 예약 — 개발·QA 전달안
적용 범위: 해외 참가자가 있는 60분 온라인 행사. 반복 일정·종일 일정·오프라인 장소 예약은 제외.
결정: 확정 전에는 주최자가 고른 현지 날짜·시간과 시간대로 의미를 정한다. 확정 후에는 저장한 UTC 시각을 약속으로 유지한다.
기준 예제: 2026-10-15 15:00, Asia/Seoul, UTC+09:00 → 2026-10-15T06:00:00Z. 종료는 07:00Z. 뉴욕 시작은 10월15일02:00, 로스앤젤레스는 10월14일23:00.
입력: 날짜, 시각, 행사 기준 시간대를 각각 표시한다. 브라우저 시간대는 추천만 하고 주최자가 확인한다. 언어 선택은 시간을 바꾸지 않는다.
확정 전: 서버가 지원 시간대인지 검사하고 실제 시각 후보를 계산한다. 0개면 존재하지 않는 시간 안내, 2개면 각각의 UTC 차이와 구분 설명을 제시하고 선택받는다. 임의 보정·자동 첫 번째 선택 금지.
최종 확인: 행사 기준 날짜·시각·지역·UTC 차이, 내 시간대의 날짜·시각, 60분 소요를 함께 보여준다. 서버가 입력과 규칙을 재검증하고 미리보기 버전을 비교한다. 바뀌면 새 결과를 보여주고 다시 확인받는다.
보관: 입력 원본 현지 날짜·시각, 행사 시간대, 선택한 UTC 차이, 확정 UTC 시작·종료, 확정 시각, 사용한 시간대 규칙 버전, 일정 버전과 변경 사유. 표시용 시간과 원본을 구분한다.
확정 후: 기기 시간대 변경은 표시만 변경한다. 시간대 규칙 업데이트로 표시가 달라져도 UTC 시각을 자동 이동하지 않는다. 변경 안내와 현재 일정을 함께 보여준다.
일정 변경: 주최자가 변경안을 확인하고 확정하면 일정 버전을 올린다. 이전 값과 변경 사유를 남긴다. 알림은 새 버전으로 연결하며 전송 실패는 재전송 대상으로 남긴다. 이미 확정된 일정을 되돌리지 않는다.
책임: 기획은 시간 약속과 변경 범위 결정, 개발은 서버 판정·버전 충돌·변환 검증, 디자인은 두 날짜와 오류 안내, 운영은 변경 대상·전송 실패 확인, QA는 아래 경계값 대조.
검수: 한국/뉴욕/LA 표시, 잘못된 시간대, 미선택 시간대, DST 공백 0개, 겹침 2개, 겹침 선택 후 재검증, 기기 변경, 언어 변경, 오래된 미리보기, 규칙 변경, 알림 실패를 확인한다.
운영 인계: 최초 적용 전 지원 시간대 목록·규칙 업데이트 담당·알림 재처리 책임자를 정한다. 경계값 검증 실패 시 새 예약 확정을 막고 원인을 고친다. 기존 확정 예약의 저장 시각은 보존한다.
확인 범위: 글의 숫자는 Python zoneinfo로 왕복 변환해 확인했다. 실제 예약 서비스나 알림 연동을 구현·시험한 결과는 아니다.
재확인 조건을 더 정확하게 정할게. 최종 확인 요청에서 원래 입력, 선택한 겹침 시각, 시간대 규칙 버전 중 하나라도 미리보기와 다르면 기존 확인을 만료시켜. 규칙 버전만 바뀌고 계산된 UTC 시점이 같더라도 새 미리보기를 보여주고 다시 확인받아.

출처와 예제 조건

가상 60분 온라인 워크숍 안건이야. 아래 공개 자료의 시간 표현 원칙을 참고했고, 예약·변경 정책은 이 예제를 위해 정했어. 숫자는 Python zoneinfo 왕복 변환으로 확인했으며 실제 예약 서비스의 연동 결과는 아니야. AI 질문은 실행하지 않은 예시야. 영어·중국어판은 같은 한국어 안건의 현지화야.

MDN — datetime-local input

W3C Group Draft Note — Working with Time Zones

RFC 3339 — Date and Time on the Internet