하이픈이 있든 없든 받아주기

KRDS BP-013 — [전화번호] 여러 가지 입력 형식에 유연한 입력 필드를 제공하고 있다.

0. 들어가며 — 010-1234-5678인지 01012345678인지

이번 579편은 전화번호의 여러 가지 입력 형식에 유연한 입력 필드를 제공하라는 규칙입니다.

전화번호를 — ’010-1234-5678’로 적든 ’01012345678’로 적든 ’010 1234 5678’로 적든, 시스템이 다 받아들여야 하죠. 한 형식만 고집하면 — 다른 형식으로 적은 사용자가 오류를 만납니다. BP-013은 형식 유연성을 규정합니다. 이번 편을 풀어냅니다.

1. 원문 — 여러 형식에 유연한 필드

BP-013 (기본 패턴 > 개인 식별 정보 입력 [전화번호]) “[전화번호] 여러 가지 입력 형식에 유연한 입력 필드를 제공하고 있다.”

전화번호를 다양한 형식(하이픈 유무, 공백 등)으로 입력해도 받아들이는 유연한 입력 필드를 제공하라는 뜻입니다.

정리: 전화번호를 여러 형식으로 입력해도 받아들여라. 이게 BP-013입니다.

2. 왜 형식 유연성인가

전화번호는 — 사람마다 적는 형식이 다릅니다:

010-1234-5678 (하이픈)

01012345678 (구분자 없이)

010 1234 5678 (공백)

(010) 1234-5678 (괄호)

이 모든 게 — 같은 번호죠. 그런데 — 시스템이 한 형식만 고집하면, 다른 형식으로 적은 사용자가 오류를 만납니다. BP-013은 형식 유연성을 요구합니다.

한 형식만 받을 때의 문제:

형식 강요 오류 시스템이 ‘010-1234-5678’(하이픈 필수)만 받으면, 사용자가 ‘01012345678’(구분자 없이) 적었을 때 ‘형식이 올바르지 않습니다’ 오류가 납니다. 사용자는 ‘번호는 맞는데 왜 오류지?’ 당황하죠. 자기 번호를 제대로 적었는데 거부당하니 짜증납니다.

하이픈 위치 강요 — 하이픈을 — 특정 위치에만 허용하면(010-1234-5678만, 01-01234-5678은 거부), 더 까다롭죠.

불필요한 시행착오 — 사용자가 — 형식을 바꿔가며 여러 번 시도하게 됩니다.

그래서 BP-013은 — 여러 형식을 유연하게 받으라고 합니다:

구분자 유연 처리 하이픈·공백·괄호가 있든 없든 다 받아들입니다. 시스템이 입력받은 번호에서 숫자만 추출해 처리하면, 어떤 형식으로 적어도 같은 번호로 인식하죠. ’010-1234-5678’도 ’01012345678’도 숫자 01012345678 로 정규화합니다.

자동 포맷팅(선택) 더 나아가 사용자가 숫자만 치면 시스템이 하이픈을 자동 삽입(010-1234-5678)해 보기 좋게 표시할 수도 있죠. 입력은 유연하게 받고, 표시는 정돈되게요.

관대한 검증 — 검증은 — 자릿수·유효성 정도만 확인하고, 구분자 형식은 강요하지 않습니다. 정당한 번호를 거부 하지 않게요.

유연성 vs 검증. 유연하게 받되 — 명백히 잘못된 번호(자릿수 부족, 문자 포함)는 검증합니다. 핵심은 — 구분자 형식 때문에 정당한 번호를 거부하지 않는 것이죠. 형식이 달라도 같은 번호면 받습니다.

왜 이게 사용자 친화적인가. 전화번호는 자주 입력하는 정보입니다. 사용자가 익숙한 자기 방식으로 적게 하면, 입력이 편하고 오류가 줄죠. 시스템이 형식을 사용자에게 맞추는 것입니다(사용자가 시스템 형식에 맞추는 게 아니라). 오류 예방(BP-008·CP-386 정신)이자 사용자 배려죠.

이 규칙은 개인 식별 정보 입력의 ’전화번호 입력 관대성’을 담당합니다 — 여러 형식을 유연하게 받아(013), 사용자가 익숙한 방식으로 적고 형식 오류를 안 만나게 하죠. 시스템이 사용자에게 맞추는 배려입니다.

정리하면 — 전화번호는 사람마다 적는 형식이 다른데 한 형식만 고집하면 정당한 번호가 거부되므로, 구분자 유무·위치에 관계없이 숫자를 정규화해 여러 형식을 유연하게 받아야 합니다.

3. 점검 / 개선

무엇을 점검하나

형식 유연 — 하이픈·공백·괄호 유무에 관계없이 전화번호를 받는가.

숫자 정규화 — 입력 형식이 달라도 같은 번호로 인식하는가.

관대한 검증 — 구분자 형식 때문에 정당한 번호를 거부하지 않는가.

개선 방향

입력에서 숫자만 추출해 정규화. 구분자 형식 강요 제거.

자동 포맷팅(표시)은 선택. 자릿수·유효성만 검증, 구분자는 관대.

4. 누가 담당하나 / 우리 사이트에 해당될까?

역할	책임
퍼블리셔/개발	형식 유연 처리·정규화 구현

기관 유형	BP-013 적용
중앙행정기관(대표·운영) / 공공기관 / 지자체	✅ 필수 (전화번호 입력 시)

전화번호를 입력받는 모든 사이트가 해당됩니다.

5. 30초 자가진단 + FAQ

✅ 30초 자가진단

□ 하이픈·공백·괄호 유무에 관계없이 전화번호를 받나요?

□ 입력 형식이 달라도 같은 번호로 인식하나요?

□ 구분자 형식 때문에 정당한 번호를 거부하지 않나요?

❓ FAQ

Q1. 한 형식만 받으면 데이터가 깔끔하지 않나요? 형식은 시스템이 정규화하면 됩니다. 사용자에게 한 형식을 강요 하면 정당한 번호가 거부돼 짜증나죠. Q2. 어떻게 유연하게 받나요? 입력에서 숫자만 추출해 정규화합니다. ’010-1234-5678’도 ’01012345678’도 같은 번호로 인식하죠. Q3. 자동 포맷팅을 하나요? 선택입니다. 숫자만 치면 하이픈을 자동 삽입해 보기 좋게 표시할 수 있죠. 입력은 유연, 표시는 정돈입니다.

6. 마무리

BP-013의 메시지:

하이픈이 있든 없든 받아주기 — 여러 입력 형식에 유연한 전화번호 필드를 제공하라.

전화번호는 사람마다 형식이 다른데 한 형식만 고집하면 정당한 번호가 거부됩니다. 숫자를 정규화해 여러 형식을 유연 하게 받는 게 핵심이죠. 다음 편은 국가 코드 입력입니다.

다음 편 예고 ▶ 「580. (BP-014) [전화번호] 국가 코드 입력에 국가명과 국가 코드가 명시된 목록을 콤보박스의 옵션으로 제공하고 있다.」

ViewCheck는 전화번호가 여러 형식으로 유연하게 입력되는지를 진단합니다.

📚 참고 출처

KRDS 기본 패턴 — 개인 식별 정보 입력 가이드 — https://www.krds.go.kr/html/site/pattern/pattern_01.html

KRDS #ViewCheck #공공웹사이트 #전자정부 #디지털정부 #웹접근성 #디자인시스템 #UIUX #UI컴포넌트 #웹표준

KRDS,ViewCheck,공공웹사이트,전자정부,디지털정부,웹접근성,디자인시스템,UIUX,UI컴포넌트,웹표준