신청이 막혔으면, 고칠 위치까지 데려다줘

“오류 문구 좀 바꿔주세요”에서 어디까지 볼 건데

이 요청을 받으면 문구 목록부터 뽑지 않을 거야. 신청이 막힌 화면, 그 전에 입력한 값, 버튼을 누른 순서부터 확인해. 사람이 항목을 못 찾는 건지, 규칙이 설명과 다른 건지, 서버가 응답하지 않은 건지에 따라 고칠 곳이 달라져. 요청은 “친절한 오류 안내” 대신 “입력한 내용을 잃지 않고 현재 필요한 항목을 고쳐 접수하기”로 다시 적어.

이번 신청서는 이름·이메일·참석 방식이 필수야. 현장 참석이면 회차도 고르고, 온라인 참석이면 회차가 없어. 로그인·결제·첨부파일은 이번 범위에서 빼. 예를 들어 이름에 “가상 참가자”, 이메일에 “sample@”, 참석 방식에 현장을 넣고 회차를 비워 제출하는 순서를 고정해. 이때 기대하는 건 이메일과 회차를 함께 고칠 수 있는 안내야. 실제 고객의 신청 내용을 조사 자료로 가져올 필요는 없어.

오류가 뜨기 전 입력과, 고친 뒤 전송값을 같이 봐

화면에 별표가 붙었다고 서버도 같은 조건으로 검사한다고 보면 안 돼. 기획이 가진 항목 정의, 화면에서 실행되는 검사, 서버의 거절 사유를 개발과 맞춰봐. 이메일은 어디까지 형식을 검사하는지, 이름 앞뒤 공백은 어떻게 처리하는지, 허용 길이가 화면에 적혀 있는지 확인해. 모르는 규칙을 일반적인 정규식 하나로 채우지 말고 확인할 항목으로 남겨.

특히 현장 참석을 온라인으로 바꾼 뒤를 봐야 해. 화면에서 회차를 숨겼는데 값이나 오류가 남아 있으면 보이지 않는 항목이 제출을 막을 수 있어. 조사표에는 화면뿐 아니라 실제로 보낸 항목도 넣어. 현장→온라인→현장 순서로 바꿨을 때 예전 회차가 조용히 다시 선택되는지도 확인할 거야.

문구만 고치려던 안에 위치와 입력 보존을 더해

처음 안은 오류 토스트 문구를 구체적으로 바꾸는 거야. 하지만 긴 신청서 아래에서 잠깐 뜨는 안내만 바꾸면 사람이 다시 위로 올라가 항목을 찾아야 해. 이번에는 전체 오류를 모아 보여주고 각 항목으로 이동시키는 안을 선택할 거야. 작은 한 항목 폼에도 무조건 같은 구성을 강제한다는 뜻은 아니고, 여러 오류와 조건부 항목이 있는 이 안건의 선택이야.

GOV.UK의 오류 요약은 오류 항목으로 연결하는 방식을 설명하고, 오류 메시지 지침은 잘못 입력한 값도 유지하도록 안내해. 이 두 가지를 보고 문구 교체안에 이동 대상과 보존 대상을 추가했어. W3C도 자동 발견한 오류를 항목과 텍스트로 알리도록 설명해. 흑백 화면이라도 선 색만 바꾸는 것으로 끝내지 않는 이유야. 이 근거가 접수 완료율이 올랐다는 실적은 아니야.

항목마다 문구, 위치, 다시 검사할 때를 정해

첫 화면부터 빈칸을 전부 오류로 표시하지 않아. 제출을 눌렀을 때 현재 필요한 항목을 한 번에 검사하고 화면 순서대로 보여줄 거야. 오류 요약에는 “다음 항목을 확인해 주세요”라고 쓰고, 이름 누락이면 “이름을 입력해 주세요”처럼 항목을 알아볼 수 있게 적어. 첫 오류에서 검사를 멈추면 고칠 때마다 다른 오류가 뒤늦게 나오는 문제가 남아.

요약의 링크를 누르면 제목 근처로 스크롤만 하지 말고 실제 입력에 키보드 초점도 보내. 선택 그룹은 첫 조작 가능한 선택지로 연결해. 개발 설계에는 입력과 오류 설명의 연결, 제출 실패 뒤 요약으로 초점 이동, 고정 헤더에 가려지지 않는 위치를 써. 문구와 스크롤 캡처만 넘기면 키보드 사용자는 같은 결과를 얻지 못할 수 있어.

한 번 오류가 드러난 항목은 고친 뒤 그 항목을 벗어날 때 다시 확인하는 걸 이번 규칙으로 정할게. 해결됐다면 요약과 항목 옆 오류를 같이 지워. 마지막 오류가 사라지면 빈 요약도 없애고 남은 개수를 갱신해. 입력할 때마다 요약으로 초점을 돌리지는 않아. 새 오류와 서버에서만 확인되는 조건은 재제출 때 다시 검사해. 이메일 형식 통과는 주소가 실제 존재하거나 본인 것이라는 확인과 달라.

안 보이는 항목을 필수로 남겨두면 안 돼

온라인 참석으로 바꾸면 회차 선택과 그 오류를 제거하고 전송에서도 빼. 서버도 온라인 요청의 회차를 접수에 쓰지 않는 조건을 적용해야 해. 화면에서만 필수를 해제하는 것으로 끝내지 않아. 변경 전 안내에 “온라인으로 바꾸면 고른 회차가 초기화돼요”를 넣고, 바뀐 뒤에는 회차를 선택하지 않아도 된다는 짧은 상태 안내를 제공해.

다시 현장으로 돌아오면 회차를 새로 고르게 할 거야. 예전 선택을 복원하는 안도 있지만 그 사이 회차가 마감될 수 있고 사용자가 이전 선택을 놓치기 쉬워. 그래서 이 예제는 재선택을 택해. 이름과 이메일의 잘못된 값까지 지우는 것은 이 규칙이 아니야. 선택 조건을 바꿔 필요 없어졌다고 알린 회차만 제거하는 거야. 회차의 최신 가용 여부는 최종 접수 시 서버에서 다시 확인해.

입력 문제와 서비스 문제를 같은 칸에 넣지 마

이 예제에서 회차 마감은 서버가 정원이 찼다고 확인한 상태를 뜻해. 신청 기간 종료나 행사 취소는 이번 예외와 구분해서 별도로 설계해야 해. 이메일 형식이 틀린 것과 고른 회차가 마감된 것은 다음 행동이 달라. 서버가 회차 마감을 확인했다면 다른 입력은 남기고 해당 회차를 마감으로 표시해. “선택한 회차가 마감됐어요. 다른 회차를 선택해 주세요”라고 안내하고 새 선택을 받아. 임의로 다른 회차에 넣으면 신청 조건 자체가 바뀌어. 자리가 남았다는 화면 표시도 접수 시점의 확보를 보장하지 않으니 개발에는 정원 확인과 접수 확정 처리를 함께 검수해달라고 넘겨.

서버 응답을 못 받았다고 이름이나 이메일 옆에 오류를 붙이지 않아. “접수 결과를 확인하지 못했어요”처럼 현재 아는 사실을 쓰고 결과 확인 동선으로 연결해. 미반영이 확인되기 전 자동으로 다시 제출시키는 것은 별도 중복 접수 문제를 만들 수 있어. 결과를 확인할 방법이 아직 없다면 개발 확인 사항으로 남기고, 있다고 가정한 안내를 먼저 배포하지 않을 거야.

AI에는 예쁜 문구보다 조건이 바뀌는 순서를 줘

AI에게 오류 문구를 친절하게 써달라고만 하면 조건부 항목이 언제 사라지는지 검토할 근거가 없어. 확정한 항목과 검사 시점, 참석 방식을 바꾸는 순서를 같이 줄 거야. 아래는 그때 쓸 질문 예시야. 실제 받은 답변이나 수정 이력으로 제시하는 건 아니야.

가령 “오류가 해결되면 요약을 닫고 첫 입력으로 이동”이라는 제안이 나오면 초점을 불필요하게 옮기는지부터 봐. “이메일을 고치는 도중 회차 오류가 남아 있다. 현재 초점은 유지하고 남은 오류만 갱신하도록 다시 써줘”라고 고칠 수 있어. “온라인 전환 시 회차를 숨겨라”는 답에는 값·오류·전송값도 빠졌는지 물어볼 거야. 채택할 문장은 규칙표에, 재현 순서는 QA표에 옮겨 두 문서가 같은 조건인지 대조해.

가상 무료 워크숍 신청서의 오류 복구 설계를 검토해줘.
항목: 이름, 이메일, 참석 방식(현장/온라인), 현장 참석 회차. 로그인·결제·첨부파일은 없어.
확정: 이름·이메일·참석 방식 필수. 회차는 현장일 때만 필수. 온라인 전환 시 회차 선택·오류·전송값 제거, 다시 현장으로 바꾸면 새로 선택.
첫 제출 전에는 입력 중 오류를 띄우지 않음. 제출 후 발견된 오류 항목은 그 항목을 벗어날 때 재검사. 재제출 때는 현재 적용되는 전체 항목 검사.
요약과 입력 옆에는 같은 문구. 제출 오류 시 요약에 초점, 링크는 해당 입력에 초점. 재검사 때문에 입력 중 초점을 빼앗지 않음. 이름·이메일의 틀린 입력도 유지.
검토할 순서: 현장 회차 누락 → 제출 → 온라인으로 변경 → 제출. 이메일 형식 오류를 고친 뒤에는 요약·필드·낭독 상태가 같이 갱신되는지도 봐줘.
입력 오류, 서버가 확인한 회차 마감, 서비스 장애, 접수 결과 미확인을 나눠줘. 이메일 형식만 맞는 것을 주소 소유 확인으로 쓰지 마.
출력: 빠진 조건 / 충돌하는 문구나 동작 / 재현 순서 / 기대 결과 / 개발에게 확인할 근거. 실제 API·고객 데이터·미확인 정책은 만들지 마.

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

QA에는 “오류 표시 확인” 대신 시작값과 조작 순서를 넘겨. 특히 한 화면에서 오류를 고치고 참석 방식을 바꾸는 연속 동작을 봐야 해. 보이지 않는 회차 오류는 첫 제출만 확인하면 놓치기 쉬워. 화면 기대값 옆에는 전송값과 서버 판단도 붙여. 클라이언트에서만 정상이라면 접수까지 해결했다고 볼 수 없어.

키보드로 제출→요약→오류 링크→입력 순서를 따라가고, 320픽셀 너비와 확대에서도 안내와 고칠 위치가 보이는지 확인해. 보조 기술은 오류 항목과 설명을 읽는지, 수정할 때 같은 문장을 과도하게 반복하지 않는지 지원 환경에서 확인해야 해. 아래는 실행 전 기대값이야. 실제 결과·담당자·환경·증거 위치는 검수한 뒤 따로 적어.

개발과 운영에 넘길 때 남겨야 할 것

기획서에는 신청이 어디서 막히는지, 이번 범위와 선택 이유를 적어. 설계서에는 항목별 적용 조건·문구·값 보존·초점·재검사·서버 거절을 붙여. 개발이 확인한 형식 규칙이나 회차 정책이 바뀌면 문구만 수정하지 말고 규칙표와 QA 기대값도 같이 바꿔. 운영에는 입력을 고쳐야 하는 문의와 접수 결과를 확인해야 하는 문의를 나눠 전달해.

배포 후에는 오류가 적게 찍혔다는 것만 보고 좋아졌다고 하지 않을 거야. 검사가 빠져도 오류 수는 줄 수 있어. 같은 오류가 반복되는지, 수정 후 다시 제출한 결과가 어떤지, 접수 미확인 문의가 남는지를 나눠 보자. 측정에는 오류 종류와 항목·결과만 남기고 이름이나 이메일 내용은 넣지 않아. 아래 전달안에 실제 규칙·담당자·검수 증거를 채우면 다음 사람이 다시 설명을 듣지 않아도 이어갈 수 있어.

안건: 무료 워크숍 신청서 오류 복구
현상: 신청이 막혔다는 말만 있고 고칠 항목을 찾기 어렵다. 조건을 바꾼 뒤 사라진 회차 오류가 제출을 막을 수도 있다.
목적: 이미 입력한 내용을 살려 두고 현재 필요한 항목을 고친 뒤 접수를 이어가게 한다.
범위: 이름·이메일·참석 방식·현장 참석 회차. 로그인·결제·첨부파일 없음. 이 문서는 독립적인 가상 설계다.
규칙: 이름·이메일·참석 방식 필수, 현장일 때만 회차 필수. 공백 처리·길이·허용 형식은 개발과 하나의 규칙표로 확정하며 실제 서버에도 적용한다. 이메일 형식 확인은 도달·소유 확인이 아니다.
조건 변경: 온라인 선택 즉시 회차 값·오류·전송값 제거. 미리 회차 선택이 초기화된다는 안내를 두고 변경 직후 회차가 필요 없다는 상태 안내를 한다. 다시 현장을 선택하면 회차를 새로 고른다. 이름·이메일은 오류가 있어도 유지한다.
표시 시점: 첫 제출 전 조용히 입력. 제출 시 현재 적용 항목 전체 검사. 오류는 화면 순서대로 요약과 항목 옆에 같은 문구로 표시. 첫 항목에서 중단하지 않는다. 로컬 통과 뒤 서버에서 발견한 오류도 같은 구조로 반영한다.
초점: 제출 결과에 오류가 있으면 요약 제목으로 이동. 요약 링크는 실제 입력 또는 선택 그룹 첫 조작 가능 항목으로 이동. 고정 헤더가 가리지 않게 한다. 오류 문구를 입력과 연결하고 색에만 의존하지 않는다.
수정: 오류가 드러난 항목은 벗어날 때 재검사. 해결된 오류는 필드와 요약에서 함께 제거하고 남은 개수를 갱신한다. 새 오류는 다음 제출에서 전체 검사. 모든 오류가 사라지면 빈 요약 제거. 검사 때문에 초점을 다시 요약으로 보내지 않는다.
문구: 이름을 입력해 주세요 / 이메일 주소를 입력해 주세요 / 이메일 주소의 @ 앞뒤를 확인해 주세요(해당 조건일 때만) / 참석 방식을 선택해 주세요 / 현장 참석 회차를 선택해 주세요.
회차 마감: 서버가 선택 회차의 접수 불가를 확인하면 현재 입력 유지, 해당 회차는 마감으로 표시하고 재선택 요구. 다른 회차로 자동 변경하지 않는다. 재제출 때 가용 여부를 다시 확인한다. 회차 확정과 정원 반영의 동시 처리 보장은 개발 검수 항목이다.
서비스 문제: 입력이 잘못됐다는 표시로 바꾸지 않는다. 접수 결과를 못 받은 경우 성공·실패를 단정하지 않고 결과 확인 동선을 제공한다. 그 근거가 없는 상태에서 다시 제출하도록 자동 유도하지 않는다.
역할: 기획은 적용 조건·메시지·전환·초점 설계, 개발은 클라이언트/서버 규칙 일치·오류 응답·접수 확인 근거, QA는 아래 순서와 보조 기술 확인, 운영은 입력 교정 문의와 실제 장애를 구분.
QA: 빈 제출, 다중 오류, 잘못된 값 보존, 요약 링크 키보드, 필드 수정 후 오류 제거, 현장→온라인→현장, 전송값 검사, 서버 회차 마감, 시간초과, 320px·확대·고정 헤더 확인. 실제 결과·버전·환경·담당자·증거 위치는 실행 뒤 별도 기입.
측정: 오류 종류·적용 항목·수정 뒤 재제출 결과로 같은 오류 반복을 확인한다. 이메일·이름·입력값 자체는 계측에 넣지 않는다. 오류 건수 감소만으로 완료율 개선을 주장하지 않는다.
보완 검수: 회차 A 선택 → 온라인 전환 → 요청에 회차가 없는지 확인 → 현장 복귀 → A 미복원 확인 → 미선택 제출 시 회차 필수 오류. 이 예제의 회차 마감은 정원 소진만 뜻하며 신청 기간 종료·행사 취소는 별도 조건이다.

출처와 예제 조건

2026-09-28 확인한 GOV.UK와 W3C 공개 자료를 참고한 가상 무료 워크숍 신청서 설계야. 참석 방식·회차 초기화·검사 시점은 이 예제에서 정한 조건이야. 회사 자료나 진명의 실제 경험·성과를 옮긴 글이 아니며 위키렙AI가 작성했어. AI 질문과 수정은 예시이고 실제 대화 기록은 없어. 자료 화면 검수와 실제 신청 서버·보조 기술 통합 검수는 구분해. 영어·중국어는 같은 한국어 안건의 현지화야.

GOV.UK Design System — Error summary

GOV.UK Design System — Error message

W3C WAI — Understanding Error Identification