[설계 6] 고객 희망 내원 날짜는 예약 확정이 아니다

고객의 희망 내원 날짜를 병원 제안, 자원 점유, 동의와 예약 확정으로 연결하는 작은 로봇 작업자들 — 고객이 날짜를 골랐다는 사실과 병원이 해당 예약일시를 보장했다는 것은 다릅니다. 그 사이에는 계획 검증, 자원 점유, 병원 승인과 고객 동의가 있습니다.

2026-08-13 · 병원 예약 서비스 개발기 · 희망 일정과 예약 확정

환자 A가 패키지 상품의 첫 방문을 예약하려고 합니다. 고객 채널에서 8월 20일 오전을 골랐고 신청도 완료했습니다. 화면만 보면 예약이 끝난 듯하지만, 병원에는 아직 확인할 것이 남아 있습니다.

구매한 상품의 현재 AppointmentPlan 버전으로 진행할 수 있는가?
그 시간에 필요한 의료진, 장비, 공간과 수용량이 남아 있는가?
병원 정책이 고객 요청을 바로 선점하도록 허용하는가?
병원이 다른 조건을 제안한다면 환자 A가 그 변경에 동의했는가?

따라서 예약 서비스는 고객이 고른 값만으로 예약을 확정하지 않습니다.

고객 희망 내원 날짜는 일정 의도이고, 예약 확정은 구체적인 제안·자원 점유·병원 승인·해당 제안에 대한 고객 동의가 결합된 결과입니다.

이 구분이 없으면 고객 화면의 “신청 완료”, 상담원의 “확인 중”, 병원 달력의 “자원 점유”가 모두 같은 예약 완료로 뭉개집니다. 그러면 변경을 거절한 고객의 기존 예약이 사라지거나, 장비를 확보하지 못한 일정이 확정으로 보이는 문제가 생깁니다.

환자 A의 신청은 먼저 일정 제안이 된다

환자 A가 제출하는 것은 임의의 예약 행 전체가 아닙니다. 구매 시점의 상품 BOM으로 만든 AppointmentPlan과 희망 방문 구간, 외부 동의 서비스가 발행한 증빙 참조입니다. 환자 식별자, 병원 범위, 정책과 실제 자원은 인증 경계와 서버 저장소에서 다시 읽습니다.

예약 서비스는 요청을 받으면 다음 조건을 검증합니다.

검증 대상	묻는 질문	실패했을 때
계획 버전	아직 유효하고 이 환자·병원에 속한 계획인가?	다른 예약 계획으로 임의 연결하지 않고 요청을 거부함
상품 정의 해시	구매 당시 고정한 상품 정의와 같은가?	최신 상품으로 조용히 다시 해석하지 않음
요청당 처리 한도	항목 수·의존 관계 수·탐색 기간이 허용 범위 안인가?	부분 처리 없이 요청 전체를 거부하고, 초과한 한도를 오류 코드로 알림
적용 정책 기록	이 제안을 만들 때 적용한 병원 정책은 무엇인가?	검증 시점의 정책을 제안에 함께 기록해 이후 정책 변경과 구분함
동의 증빙	해당 환자·예약 계획·일정·약관에 결합된 증빙인가?	원문 개인정보를 저장하지 않고 증빙 불일치를 거부함

검증을 통과해도 결과는 정책에 따라 PROPOSED 또는 HELD입니다. 아직 예약이 확정된 것은 아닙니다.

`PROPOSED`, `HELD`, `CONFIRMED`는 무엇이 보장됐는지를 말한다

세 상태는 화면 단계를 예쁘게 나눈 이름이 아닙니다. 각각 다른 업무 보장을 나타냅니다.

상태	이미 보장된 것	아직 남은 조건
`PROPOSED`	구체적인 일정·항목·정책을 담은 제안 버전	자원 점유, 필요한 승인과 예약 확정
`HELD`	제한된 시간 동안의 자원 선점과 제안	만료 전 승인·동의·예약 확정
`CONFIRMED`	구체적인 제안·해당 제안의 동의 증빙·자원 점유가 결합된 예약 확정	실제 내원과 진료 완료

HELD는 CONFIRMED의 약한 별칭이 아닙니다. 자원이 잠시 잡혔더라도 동의나 승인 조건을 충족하지 못하면 만료될 수 있습니다. 반대로 PROPOSED는 단순 메모가 아닙니다. 이후 동의가 무엇을 승인했는지 확인할 수 있도록 시간, 항목, 자원 후보, 적용 정책과 제안 해시를 고정한 제안 버전입니다.

또한 예약 확정 상태는 방문의 접수·진행·완료 상태와 다른 축입니다. CONFIRMED는 환자와 병원이 일정에 합의했다는 뜻이지, 진료를 마쳤다는 뜻이 아닙니다. 실제 시작·완료·부분 완료는 임상 서비스가 소유하는 별도 정보입니다.

환자 A가 희망 내원 날짜를 제출하면 예약 서비스가 계획과 정책을 검증하고 자원을 선점한 뒤 병원 승인과 해당 제안에 대한 고객 동의를 결합해 예약을 확정하는 시퀀스 — 같은 조건을 승인할 때와 병원이 다른 조건을 제안할 때의 동의 경계가 다릅니다.

같은 조건을 승인할 때와 조건을 바꿀 때는 다르다

환자 A가 요청한 시간, 방문 항목과 중요한 조건을 병원이 그대로 승인한다면 최초 요청에 결합된 동의 증빙을 사용할 수 있습니다. 정책이 허용하고 자원 점유도 성공하면 같은 제안의 상태를 CONFIRMED로 전환합니다.

하지만 병원이 오후 시간, 다른 담당자 조합, 다른 방문 항목처럼 중요한 조건을 바꾼다면 원 요청의 동의를 재사용할 수 없습니다. 예약 서비스는 기존 제안을 수정하지 않고 새 버전을 추가합니다. 고객에게 보여 준 조건과 동의 증빙은 proposalId, 제안 버전, 제안 해시에 정확히 결합됩니다.

고객 희망 내원 날짜 제출
  → PROPOSED 또는 HELD
  → 병원 검토
      ├─ 같은 조건 승인 → 해당 제안의 동의 검증 → CONFIRMED
      └─ 조건 변경 → 새 제안 버전 → 고객 동의 → CONFIRMED

이 모델에서는 “고객이 예약에 동의했다”는 모호한 문장만 남지 않습니다. 고객이 어느 시간, 어느 항목, 어느 정책 조건에 동의했는지 다시 확인할 수 있습니다.

변경 제안은 기존 예약을 먼저 취소하지 않는다

환자 A가 이미 다음 주 화요일 오전으로 예약을 확정한 뒤 금요일 오후로 바꾸고 싶다고 하겠습니다. 새 시간을 알아보기 위해 기존 예약을 먼저 취소하면, 금요일 자원 충돌이나 고객의 최종 거절이 발생했을 때 유효한 화요일 예약까지 잃습니다.

기존 예약을 보호하는 변경은 다음 순서를 지킵니다.

기존 confirmedProposalId와 자원 점유를 유지합니다.
새 시간으로 제안 버전을 추가합니다.
새 제안에 대한 고객 동의 증빙을 검증합니다.
새 자원을 확보합니다.
한 트랜잭션에서 확정 제안을 교체하고 기존 자원을 해제합니다.

새 자원 점유가 실패하거나 고객이 거절하거나 제안이 만료되면 기존 예약의 확정 상태와 예약일시는 그대로 남습니다. 이것이 날짜 필드만 수정하는 것과 확정 예약을 변경하는 것의 가장 큰 차이입니다.

각 서비스는 무엇을 책임지는가

희망 일정과 예약 확정을 분리하려면 서비스 경계도 함께 분명해야 합니다.

고객 채널, 예약 서비스, 병원 운영, 자원 원장과 임상 서비스가 희망 내원 날짜, 제안, 승인, 자원 점유, 동의와 완료 사실을 나누어 소유하는 책임 경계 — 예약 서비스는 제안과 예약 확정 상태를 소유하지만, 고객 채널의 동의 원문이나 임상 완료 판단까지 소유하지 않습니다.

서비스	소유하는 정보	예약 서비스와의 경계
고객 채널·동의 서비스	고객 희망 내원 날짜, 고객에게 제시한 조건, 동의 원문과 증빙 발행	예약 서비스에는 원문 내용을 저장하지 않고도 검증할 수 있는 증빙 참조만 전달함
예약 서비스	제안 버전, 예약 확정 상태, 적용 정책 기록, 자원 점유 연결, 변경 이력	구체적인 제안과 해당 제안의 동의를 결합하고 상태 전이를 한 트랜잭션으로 기록함
병원 운영	승인 권한, 가능한 대안, 운영 정책의 적용 판단	고객 요청을 승인하거나 새 조건을 제안함
자원 원장	의료진·장비·공간·수용량의 실제 점유 가능성	`HELD`와 `CONFIRMED`에 필요한 점유 결과를 제공함
임상·시술 서비스	실제 시작·완료·부분 완료	방문 결과를 발행하며 일정 합의 상태를 대신 판단하지 않음

고객 상담·CRM의 노쇼 이력이나 VIP 정책은 이 흐름의 입력이 될 수 있습니다. 다만 예약 서비스가 스스로 고객 등급을 만들거나 벌점을 부과하는 것은 아닙니다. 정책 소유 서비스가 근거와 적용 범위를 결정하고, 예약 서비스는 상품과 병원의 운영 규칙, 기존에 확정한 예약의 일시와 자원 점유를 지키는 범위에서 제안 우선순위나 승인 조건에 반영합니다. 다음 글에서는 노쇼 이력과 VIP 우선 신호를 신규 예약과 대기 목록 제안에 적용할 때의 책임 경계를 다룹니다.

현재 구현과 운영 활성화는 같은 말이 아니다

이 글의 상태 모델과 명령 경계는 현재 코드에 구현되어 있습니다. 고객 요청, 병원 승인, 변경 제안, 고객 수락·거절, 직접 확정, 만료와 취소 경로가 있고, 동의 증빙과 적용 정책 기록, 자원 점유를 함께 검증합니다.

하지만 구현이 병합됐다는 사실이 모든 병원에서 운영 환경의 쓰기 경로를 열었다는 뜻은 아닙니다.

사실성 표지	이번 글에서 의미하는 범위
현재 구현	`AppointmentCommitment`, `AppointmentProposal`, 요청·승인·수락·거절·변경 명령, 동의 검증, H2·PostgreSQL·MySQL용 V10 마이그레이션과 테스트
승인된 설계	기존 예약 보호, 확정된 제안 버전을 수정하지 않는 원칙, 적용 정책·동의 증빙 보존 원칙
운영 대기	외부 동의·커머스·임상 연동 어댑터, 운영 환경의 `WRITE` 활성화, 일부 병원 대상 검증·복구 훈련
로드맵	재확인, 대기 목록, 노쇼·VIP 우선순위와 같은 운영 정책

따라서 CONFIRMED 모델이 존재한다는 사실만으로 특정 병원에 운영 적용까지 끝났다고 볼 수는 없습니다. 상태 전이 로직이 준비되어 있어도, 외부 책임 서비스 연동과 운영 검증이 끝나기 전에는 쓰기 경로를 제한할 수 있습니다.

다음 글에서 다룰 것

이번 글은 하나의 방문 예약일시가 확정되는 경계를 살펴봤습니다. 다음 글에서는 노쇼 이력, VIP 우선 신호, 대기 목록 제안이 만날 때 예약 우선순위를 누가 소유하는지 구체적으로 다룹니다.

시각 자료로 다시 보기

근거 링크

시리즈 링크

GitHub 계정으로 의견을 남기거나 reaction을 남길 수 있습니다.