두 번 눌러도 한 번만
이번 391편은 사용자가 실수로 버튼을 두 번 이상 누르는 상황을 고려하여 구현하라는 규칙입니다.

KRDS CP-271 — 사용자가 실수로 버튼을 두 번 이상 누르는 상황을 고려하여 구현하고 있다.
0. 들어가며 — 신청 버튼을 두 번 누르면
이번 391편은 사용자가 실수로 버튼을 두 번 이상 누르는 상황을 고려하여 구현하라는 규칙입니다.
사용자는 — 응답이 느리면 ‘안 눌렸나?’ 하고 버튼을 또 누르거나, 실수로 빠르게 두 번 클릭(더블클릭)하기도 하죠. 그런데 ‘신청’, ‘결제’, ‘제출’ 같은 버튼이 — 두 번 눌려 두 번 처리되면, 중복 신청·이중 결제 같은 심각한 문제가 생깁니다. CP-271은 중복 클릭을 방지하라고 규정합니다. 이번 편을 풀어냅니다.
1. 규칙 원문 — 중복 클릭 상황 고려
CP-271 (컴포넌트 > 버튼) “사용자가 실수로 버튼을 두 번 이상 누르는 상황을 고려하여 구현하고 있다.”
사용자가 버튼을 실수로 두 번 이상 누르더라도 동작이 중복 실행되지 않게, 그 상황을 고려해 방지 처리를 구현하라는 뜻입니다.
정리: 버튼을 두 번 눌러도 동작이 한 번만 실행되게 하라. 이게 CP-271입니다.
2. 왜 중복 클릭을 방지해야 하나
사용자가 버튼을 두 번 이상 누르는 일은 — 실수가 아니라 흔한 상황입니다:
응답 지연 — 버튼을 눌렀는데 처리(서버 통신 등)에 시간이 걸려 화면 변화가 없으면 — 사용자는 ‘안 눌렸나?’ 싶어 다시 누릅니다. 느린 네트워크에서 특히 잦죠.
더블클릭 습관 — 데스크톱 사용자는 — 아이콘을 더블클릭하는 습관으로 버튼도 빠르게 두 번 누르기도 합니다.
손 떨림 — 운동 장애 사용자는 의도치 않게 버튼을 여러 번 누를 수 있죠.
이때 — 버튼이 두 번 눌린 만큼 두 번 처리되면 심각한 문제가 생깁니다:
중복 신청·접수 — ’신청하기’가 두 번 처리되면 — 같은 신청이 두 건 접수되죠. 사용자·기관 모두 혼란스럽고, 중복 처리·취소 업무가 발생합니다.
이중 결제·송금 — ’결제하기’가 두 번이면 — 돈이 두 번 빠져나가는 치명적 문제죠.
중복 데이터·게시 — ‘등록’, ’제출’이 두 번이면 같은 데이터가 두 개 생깁니다.
특히 공공 서비스의 민원 신청·접수·결제에서 중복 처리는 — 사용자 피해와 행정 부담으로 직결되죠.
그래서 CP-271은 — 중복 클릭을 방지하라고 합니다. 핵심 기법:
버튼 비활성화(disable) — 버튼을 누르는 즉시 그 버튼을 비활성화해, 처리가 끝날 때까지 다시 못 누르게 합 니다. 가장 흔하고 확실하죠. 처리 완료 후(또는 화면 전환 후) 해제.
로딩 상태 표시 — 버튼을 누르면 — 로딩 스피너·“처리 중…” 표시로 ’지금 처리하고 있다’를 알려, 사용자가 다시 안 누르게(응답 지연 인지). 비활성화와 함께 쓰면 좋죠.
서버 측 멱등성(idempotency) — 더 근본적으로 — 서버에서 같은 요청이 중복 와도 한 번만 처리되게 보장 (멱등 키, 중복 요청 거부). 클라이언트 비활성화가 우회되거나 실패해도(빠른 더블클릭, 네트워크 재전송) 서버가 중복을 막죠. 결제·신청 같은 중요 처리는 서버 멱등성이 필수입니다.
디바운스(debounce) — 짧은 시간 내 반복 클릭을 무시.
클라이언트 + 서버 이중 방어. 가장 안전한 건 — 클라이언트(버튼 비활성화·로딩)와 서버(멱등성) 양쪽에서 막는 것입니다. 클라이언트 방어는 사용성(즉각 피드백)을, 서버 방어는 확실성(우회·재전송 대비)을 담당하죠. 특히 결제·신청은 서버 멱등성이 안전망입니다.
접근성 고려. 버튼 비활성화 시 — 그 상태가 스크린 리더에도 전달돼야 하죠(aria-disabled 또는 disabled + “처리 중” 안내). 그래야 비시각 사용자도 ’지금 처리 중이라 다시 누를 수 없다’를 압니다. 로딩 상태도 aria-live 등으로 알리면 좋고요.
이 규칙은 버튼의 ’안전한 동작 실행’을 담당합니다 — 버튼이 동작을 실행하는데(CP-270), 그 실행이 의도치 않게 중복되지 않게(271) 하죠. 구조화 목록 예측 가능 작동(CP-150), 모달 명확성(CP-179)과 함께 안전한 상호작용을 이룹니다.
정리하면 — 사용자가 응답 지연·더블클릭·손 떨림으로 버튼을 여러 번 누르는 일은 흔하므로, 버튼 비활성화·로딩 표시·서버 멱등성으로 중복 실행을 방지해 중복 신청·이중 결제 같은 문제를 막아야 합니다.
3. 점검 / 개선
무엇을 점검하나
중복 방지 — 버튼을 두 번 빠르게 눌러도 동작이 한 번만 실행되는가.
비활성·로딩 — 누른 즉시 버튼이 비활성화되고 처리 중 표시가 되는가.
서버 멱등성 — 결제·신청 등 중요 처리에 서버 중복 방지가 있는가.
개선 방향
클릭 즉시 버튼 비활성화 + 로딩 표시. 처리 완료 후 해제.
결제·신청은 서버 멱등성(멱등 키) 병행. 비활성 상태 스크린 리더 전달.
4. 누가 담당하나 / 우리 사이트에 해당될까?
| 역할 | 책임 |
|---|---|
| 개발(프론트) | 버튼 비활성화·로딩·디바운스 |
| 개발(백엔드) | 서버 멱등성·중복 요청 방지 |
| 기관 유형 | CP-271 적용 |
|---|---|
| 중앙행정기관(대표·운영) / 공공기관 / 지자체 | ✅ 필수 (제출·신청·결제 버튼) |
신청·접수·결제 등 중요 동작 버튼을 쓰는 모든 사이트가 해당됩니다.
5. 30초 자가진단 + FAQ
✅ 30초 자가진단
□ 버튼을 두 번 빠르게 눌러도 동작이 한 번만 실행되나요?
□ 누른 즉시 버튼이 비활성화되고 처리 중 표시가 되나요?
□ 결제·신청 등 중요 처리에 서버 중복 방지가 있나요?
❓ FAQ
Q1. 왜 사용자가 두 번 누르나요? 응답이 느려 ‘안 눌렸나?’ 싶어 다시 누르거나, 더블클릭 습관·손 떨림 때문 입니다. 흔한 상황이죠. Q2. 버튼 비활성화만으론 부족한가요? 빠른 더블클릭·네트워크 재전송으로 우회될 수 있습니다. 결제·신청은 서버 멱등성도 필요하죠. Q3. 비활성 상태를 스크린 리더에 알려야 하나요? 네. aria-disabled·로딩 안내로 ’처리 중’을 전달해야 합니다.
6. 마무리
CP-271의 메시지:
두 번 눌러도 한 번만 — 실수로 버튼을 여러 번 누르는 상황을 방지하라.
응답 지연·더블클릭·손 떨림으로 버튼을 여러 번 누르는 일은 흔합니다. 버튼 비활성화·로딩 표시(클라이언트)와 서버 멱등성(서버)으로 중복 실행을 막아 중복 신청·이중 결제를 방지하죠. 공공 서비스에서 특히 중요합니다. 다음 편은 모든 버튼의 텍스트 설명입니다.
다음 편 예고 ▶ 「392. (CP-272) 모든 버튼에는 기능, 목적을 이해할 수 있는 설명을 텍스트로 제공하고 있다.」
ViewCheck는 버튼의 중복 클릭이 방지되는지를 진단합니다.
📚 참고 출처
KRDS 컴포넌트 — 버튼(Button) 가이드 — https://www.krds.go.kr/html/site/component/component_25.html
KRDS #ViewCheck #공공웹사이트 #전자정부 #디지털정부 #웹접근성 #디자인시스템 #UIUX #UI컴포넌트 #웹표준
KRDS,ViewCheck,공공웹사이트,전자정부,디지털정부,웹접근성,디자인시스템,UIUX,UI컴포넌트,웹표준

관련 글
다음 호는 언제?
이번 846편은 간행물 자료의 발행 주기 정보를 본문의 부제목이나 별도 안내 영역에 제공하라는 규칙입니다. 그리고 이 편이 — 846 규칙 완전 분해 시리즈의 마지막 한 편입니다.
방대한 자료를 효율적으로
이번 845편은 목록에 필터링, 정렬 방식, 상세 검색(기간, 자료 유형 등) 기능을 제공하여 정보를 효과적으로 조회하라는 규칙입니다. [정책 자료 탐색] 서브섹션의 시작이죠.
적힌 대로 가야 한다
이번 844편은 모든 링크는 실행하였을 때, 링크 레이블에 명시된 적절한 화면으로 이동하라는 규칙입니다.
