대기 1번이면 취소 자리부터 바로 확정해도 될까?

취소되면 다음 사람을 넣어 달라는 요청부터 확인해

무료 워크숍 정원 20명이 찼고 가·나·다 순서로 대기 중이라고 해 보자. 한 사람이 취소하면 가를 참석자로 바꾸면 될까? 대기 신청을 할 때는 갈 수 있었어도 며칠 뒤에는 일정이 달라졌을 수 있어. 먼저 확인할 건 자동 처리 여부보다 대기 신청이 어떤 약속이었느냐야.

이 안건의 목적은 빈자리를 빨리 채우면서 먼저 신청한 사람에게 기회를 주는 거야. 그래서 대기 접수, 자리 제안, 참석 확정을 나눠. 순번은 제안받는 순서이고 참석 확정은 아니야. 화면에서 대기 완료를 신청 완료라고 쓰면 이 구분부터 무너져.

자료를 받을 때는 접수 화면의 약속, 취소가 생긴 시각, 대기자가 답할 수 있는 시간, 행사 전에 명단이 필요한 시점을 먼저 확인해. 여기서는 기존 회원을 구분할 수 있는 무료 단일 회차를 가정할게. 회원별 1석이고 단체 신청·결제·우선 배정은 제외해. 사람 이름과 이 숫자는 예제 조건이야.

다른 서비스의 대기 기능을 그대로 가져오면 안 돼

Bevy의 공개 도움말에서도 유형에 따라 처리가 달라. 유료 티켓 설명은 제안을 받은 사람이 직접 자리를 받는 절차가 있고, RSVP 전용 설명은 운영자가 해제하면 참석자로 등록돼. 대기 해제라는 같은 표현만 보고 같은 기능이라고 판단하면 안 되는 이유야.

처음 떠올린 취소 즉시 자동 확정은 가장 짧아. 하지만 이번 안건에서는 현재 참석 의사를 다시 확인하기로 했으니 맞지 않아. 반대로 모두에게 알리고 먼저 누른 사람에게 주면 접수 순서라는 약속이 달라져. 이번에는 선두 한 사람에게 먼저 기회를 주고, 응답을 기다리는 동안 그 자리를 보류하는 쪽을 택할게.

이 선택에는 비용도 있어. 응답을 기다리는 동안 자리가 비어 보이고, 늦게 생긴 취소 자리를 못 채울 수 있어. 그래도 예제에서는 응답 시간을 갑자기 줄여 순서를 바꾸는 것보다 약속한 기회를 지키는 쪽을 우선해. 자동 확정이 항상 틀리다는 말은 아니야. 처음 신청에서 자동 전환까지 동의한 다른 서비스라면 선택이 달라질 수 있어.

24시간이라고 썼으면 마지막 대기자에게도 24시간을 줘

행사는 2026년 10월 12일 오후 2시, 접수 종료는 전날 오후 6시로 잡아 볼게. 표시 시간대는 한국시간이야. 자리 제안을 만든 시점부터 24시간을 주면 마지막 새 제안은 10월 10일 오후 6시까지 가능해. 이후에는 빈자리가 나도 새 제안과 일반 접수를 멈춰. 남은 사람에게만 10분을 주는 예외는 넣지 않을 거야.

접수 순서는 서버가 대기를 받아들인 순서로 정해. 같은 시각이면 서버 접수 순번을 써서 동률을 풀어. 한 회원이 이 회차에 대기·보류·확정을 겹쳐 갖지 않도록 하고, 활성 대기자가 있으면 신규 신청도 맨 뒤로 보내. 일반 신청 창이 열려 있다고 대기자를 건너뛰게 하면 안 돼.

정원은 확정 인원만 세면 부족해. 확정된 자리와 유효하게 보류한 자리를 합쳐 20석 이하여야 해. 가에게 1석을 제안한 사이 일반 신청자가 그 자리를 가져갈 수 없어야 한다는 뜻이야. 좌석 확인, 선두 선택, 보류 생성은 한 번에 성공하거나 전부 반영되지 않게 개발 조건으로 남겨.

알림을 보냈다고 자리가 확정된 건 아니야

새 제안을 만들 때는 빈자리, 활성 대기자, 온전한 24시간이 모두 있는지 확인해. 조건이 맞으면 선두에게 1석을 보류한 제안을 먼저 기록하고 그 제안의 이메일을 보내. 전송이 느리다고 다른 제안을 하나 더 만들면 같은 사람에게 자리를 두 번 잡아 놓을 수 있어.

수락은 별도야. 본인이 맞는지, 이 회차의 현재 제안인지, 보류가 살아 있는지 확인해. 그리고 원자적으로 상태를 바꾸는 안에서 확인한 서버 시각이 제안 기한과 접수 종료보다 모두 빨라야 해. 기한과 같은 시각이면 끝난 거야. 화면에서 먼저 눌렀다는 이유로 과거 시각을 믿고 확정하지 않아.

단, 이미 확정된 같은 제안의 수락을 다시 보냈다면 기존 확정 결과를 돌려줘. 이 검사를 먼저 해야 응답을 못 받은 사람이 재시도했는데 만료라고 나오는 일을 막을 수 있어. 기한 정리 작업과 수락 요청도 같은 기준으로 경쟁을 막아야 해. 화면 버튼을 비활성화하는 것만으로 끝낼 수 있는 조건은 아니야.

만료와 전송 실패를 같은 종료로 묶지 마

거절·철회·만료는 해당 신청이나 제안을 끝내고 연결된 보류만 한 번 반환해. 확정 후 취소도 확정 좌석을 한 번 돌려줘. 같은 취소 요청이 두 번 왔다고 두 자리가 생기면 안 돼. 자리가 반환되면 현재 시각과 대기열로 새 제안 조건을 다시 확인해.

이메일 실패는 참석 거절이 아니야. 운영 확인 대상으로 남기고 같은 제안만 재전송해. 기한은 바뀌지 않고, 이미 끝났다면 재전송도 멈춰. 발송 요청·전달 실패·메일 열람·수락을 구분해 두면 무엇이 막혔는지 확인할 수 있어. 발송 성공만 보고 가를 참석자로 올리거나 나에게도 같은 자리를 주지 않아.

기한을 놓친 사람은 자동으로 다시 대기시키지 않아. 아직 새 제안이 가능한 시간이라면 본인이 새로 신청해 맨 뒤로 갈 수 있어. 이때 옛 링크는 옛 제안의 종료 상태를 보여 줘야 해. 새 신청에 옛 수락 버튼을 연결하면 기다리는 순서가 다시 깨져. 아래는 이 조건을 비교하는 고정 화면 예제야.

AI에는 순서를 바꾸는 반례를 찾아 달라고 해

대기 기능을 만들어 달라는 말만 주면 알림과 순번 화면부터 나올 수 있어. 이번에는 정원, 접수 순서, 24시간 제안, 마지막 접수 시각, 다시 신청했을 때의 순서를 먼저 줘. 맡길 일은 이 결정 안에서 서로 충돌하는 조건을 찾고 검수 입력을 만드는 데까지야.

답에 알림 실패 시 다음 사람에게 보낸다는 내용이 있다면, 기존 보류를 언제 끝내는지부터 확인해. 기존 제안이 살아 있는데 다음 사람에게도 자리를 주면 채택할 수 없어. 운영자가 임의로 기한을 늘린다는 답도 이번 정책과 다르니 별도 결정 없이 명세에 넣지 않아.

아래는 실행하지 않은 질문 예시야. 답을 받으면 그럴듯한 설명보다 좌석 수의 전후를 먼저 대조해. 확정 19·보류 1에서 수락하면 확정 20·보류 0이 되는지, 같은 취소를 반복해도 빈자리가 늘지 않는지 확인해. 수정한 조건은 설계서뿐 아니라 QA와 운영 안내에도 같이 반영해야 해.

질문 예시: 무료 워크숍 정원은 20명이고 회원별 1석이야. 취소 자리는 접수 순서대로 1석 보류 후 24시간 안에 수락받을 거야. 접수 종료까지 24시간 미만이면 새 제안과 일반 접수를 멈춰. 동시 취소, 기한과 같은 시각의 수락, 수락 응답 유실, 이메일 실패, 만료 후 재신청에서 순서나 정원이 깨지는 경우를 찾아 줘. 각각 좌석 전후 수, 화면 문구, 개발 처리 조건, QA 기대 결과를 써 줘. 실제 성과나 외부 정책은 가정하지 마.

누가 무엇을 받아야 개발이 시작되는지도 적어

기획서에는 왜 자동 확정 대신 제안 후 수락을 골랐는지와 빈자리를 감수하는 범위를 남겨. 설계서는 대기·제안·확정·종료마다 보이는 문구와 할 수 있는 행동을 연결해. 이메일 문구에는 행사 일시와 응답 기한의 날짜·시간대가 같이 있어야 해. 내일까지만 쓰면 늦게 읽은 사람이 다르게 이해할 수 있어.

개발 전달에는 화면 상태 외에 좌석 변경이 한 번만 일어나는 조건을 넣어. 운영 화면에는 신청 순서, 제안 기한, 종료 사유, 좌석 변화, 알림 결과를 연결해 두면 돼. 운영자도 정원을 넘기거나 순서를 바꾸는 우회 버튼은 쓰지 못하게 해. 정책 예외가 필요하면 그때 근거를 남기고 별도 결정해야 해.

W3C의 상태 메시지 설명은 포커스를 옮기지 않고 바뀌는 처리 결과도 보조기술이 인식할 수 있어야 한다는 근거로 참고했어. 이 예제에서는 수락 처리 중·확정·확인 실패를 문구로 구분하고 상태 알림으로 전달해. 화면에서 확인되는 안내와 접근성 구현을 함께 검수해야지, 초록색만 바꿔 놓고 끝내면 안 돼.

정상 수락 한 번으로 검수를 끝내지 마

검수표에는 버튼 이름만 쓰지 말고 시작 상태와 요청 순서를 넣어. 확정 20명에서 취소 두 건이 동시에 들어오면 빈자리 두 개가 되고, 순서대로 두 사람에게 한 자리씩 보류돼야 해. 두 작업이 같은 선두를 잡거나 한 자리를 두 번 반환하는지 확인하는 거야.

기한 검수는 바로 전, 같은 시각, 지난 뒤를 나눠. 실제 판정은 상태를 바꾸는 안의 서버 시각으로 해야 하니 요청 도착을 지연시키는 시험도 필요해. 아래는 구현 후 실행할 검수 조건이야. 이 글의 고정 화면 예제를 눌러 본 것과 실제 워크숍 연동 검수는 구분해서 기록해.

이 전달안을 쓸 때 바꿀 부분부터 봐

아래 자료는 기존 회원을 식별하는 무료 단일 회차, 회원별 1석, 선착순 대기를 전제로 해. 여러 좌석을 한꺼번에 신청하거나 우선 배정이 있으면 뒤 사람을 건너뛰어도 되는지부터 다시 정해야 해. 행사 직전까지 빈자리를 채워야 한다면 24시간 보장과 마감 정책도 그대로 가져올 수 없어.

팀에 넘길 때는 순서·마감·좌석 계산을 같은 예제로 한 번씩 맞춰 봐. 개발에서 제안 시점에 자리를 보류하지 않는다고 하면 디자인의 보류 안내도 잘못된 거야. 어느 문서가 최신인지 다시 물어보게 두지 말고 결정표, 화면 문구, QA 입력을 같이 고쳐.

첫 배포에서는 중복 보류, 정원 초과, 만료 수락, 옛 링크가 새 신청을 바꾸는 문제를 출시 중단 조건으로 잡아. 운영 후에는 제안과 알림 실패 기록으로 어디서 처리가 막혔는지 확인해. 메일을 열었다는 기록만으로 참석 효과를 말하지 않고 실제 확정과 취소를 따로 봐야 해.

무료 워크숍 — 대기자 자리 제안 전달안
예제: 정원 20명, 회원별 1석, 기존 회원 식별 사용. 2026-10-12 14:00 행사, 접수 종료 10-11 18:00, 표시 시각은 Asia/Seoul. 결제·단체·우선권·정원 감축 제외.
목적: 취소 자리를 접수 순서대로 제안하되 참석 의사를 다시 확인한다. 대기 접수·자리 제안·참석 확정을 분리한다. 빈자리 예상 시각이나 참석 보장은 하지 않는다.
순서: 서버가 접수를 확정한 순서. 같은 시각이면 서버 접수 순번으로 결정한다. 한 회원은 이 회차에 활성 대기·보류·확정 중 하나만 가진다. 대기자에게 다른 신청자의 정보는 공개하지 않는다.
정원: 확정 수 + 유효한 자리 보류 수 ≤ 20. 보류된 자리는 일반 신청에 내주지 않는다. 활성 대기자가 있으면 신규 신청도 대기열 뒤에 들어간다. 배정 중 조건이 바뀌면 현재 상태로 다시 판정한다.
새 제안: 빈자리와 활성 대기자가 있고 접수 종료까지 24시간 이상 남았을 때만 선두에게 1석을 원자적으로 보류한다. 제안 생성 시점 + 24시간이 응답 기한이다. 이 예제의 마지막 새 제안은 10-10 18:00이다. 이후에는 빈자리여도 새 제안·일반 접수를 멈춘다.
수락: 본인·해당 회차·현재 제안·유효 보류를 확인하고 원자 처리 안에서 확인한 서버 시각이 응답 기한과 접수 종료보다 모두 빠를 때 확정한다. 화면 클릭 시각은 기준이 아니다. 보류 1석을 확정 1석으로 바꾼다.
중복: 이미 확정된 같은 제안의 수락 재요청은 기존 확정 결과를 반환한다. 만료된 제안으로 새 보류를 만들지 않는다. 회원의 다른 활성 신청으로 연결해서도 안 된다.
종료: 제안 거절·대기 철회·기한 만료는 해당 대기/제안을 종료하고 연결된 보류만 한 번 반환한다. 확정 후 취소도 확정 좌석을 한 번 반환한다. 만료 정리 작업과 수락은 같은 원자 판정으로 경쟁을 막는다.
재신청: 거절·철회·만료·확정 취소 후 자동으로 순번을 되살리지 않는다. 새 제안 가능 시간 안에 본인이 다시 신청하면 새 접수 순서로 맨 뒤에 들어간다. 기존 링크는 이전 종료 상태를 보여 준다.
알림: 제안을 먼저 기록하고 그 제안에 연결해 이메일을 보낸다. 발송 요청·전달 실패·열람·수락은 별도 기록이다. 실패나 결과 미확인은 운영 확인 대상으로 두고 같은 제안만 재전송한다. 보류 추가·기한 자동 연장·발송 성공을 수락으로 간주하지 않는다. 기한이 지나면 재전송하지 않는다.
화면: 행사명·일시·응답 기한의 날짜와 시간대·현재 상태·가능한 행동을 함께 표시한다. 제안 중에는 수락/거절, 확정에는 내 신청 확인/취소, 종료에는 종료 이유와 재신청 가능 여부를 보여 준다. 결과 미확인은 현재 신청 조회로 연결하며 확정으로 표시하지 않는다.
기록: 신청 접수 순서, 제안 생성·기한·종료 사유, 좌석 변경 전후, 수락 판정 시각, 알림 결과, 운영 조치자를 연결한다. 관리자도 정원·순서·기한을 우회할 수 없다. 정책 변경은 별도 승인·문서 갱신 사항이다.
인계: 기획은 순서와 경계 조건표, 디자인은 상태별 문구·행동·상태 알림 접근성, 개발은 좌석/제안 원자 전이와 알림 재시도, QA는 12개 검수의 입력/기대/실제 결과, 운영은 전달 실패·좌석 불일치의 확인 기록을 남긴다.
출시 기준: 중복 보류·초과 확정·만료 수락·옛 링크가 새 신청에 영향을 주는 문제 중 하나라도 재현되면 배포를 막고 같은 순서로 재검수한다. 이 문서는 가상 설계이며 실제 행사 연동 시험을 끝냈다는 뜻은 아니다.

출처와 예제 조건

무료 워크숍을 가정한 설계 예제야. Bevy의 공개 문서에서는 유형별 정책 차이를, W3C에서는 상태 메시지 원칙을 참고했어. 정원·순서·24시간·마감 정책은 이 예제의 결정이며 실제 행사 운영 성과가 아니야. AI 질문은 미실행 예시이고 영어·중국어판은 같은 한국어 안건의 현지화야.

Bevy — Waitlist Registration

W3C — Understanding SC 4.1.3: Status Messages