🔍 전화번호 정규식 생성기 (30+ 국가)
30+ 국가의 전화번호 검증용 정규식을 즉시 생성. E.164 / 국제 / 유연 / 모바일 전용 4 가지 변형, 다국가 OR 결합, 실시간 테스터, JavaScript / PHP / Python / Ruby / Go 의 복사 가능한 스니펫 포함. 폼 입력 검증, 로그 추출, 데이터 정제에 활용.
🔒 개인정보 보호
- ・모든 처리는 브라우저 JavaScript 로 완결
- ・입력한 전화번호는 서버로 전송되지 않습니다
📝 생성된 정규식
/^.+$/g
🧪 라이브 테스터
💻 언어별 코드 스니펫
📖 자주 걸리는 지점
30 개국 이상에 대해 전화번호 검증용 정규식을 생성합니다. E.164 / 국제 / 유연 / 모바일 전용 4 가지 변형, 여러 나라의 OR 결합, 그 자리에서 시험할 수 있는 테스터, JavaScript / PHP / Python / Ruby / Go 의 스니펫이 딸려 있습니다. 처리는 브라우저 안에서 끝납니다. 다만 정규식이 할 수 있는 것은 「형태가 번호다운가」의 판정뿐입니다 — 그 번호가 실재하는지, 지금도 쓰이는지, SMS 가 도달하는지는 알 수 없습니다. 그리고 번호 계획은 바뀝니다: 새로운 앞자리가 할당되면 어제까지 옳았던 정규식이 오늘부터 실재하는 번호를 거부하기 시작합니다.
| 사례 | 무슨 일이 일어나는가 | 어떻게 하면 되는가 |
|---|---|---|
| 너무 엄격한 정규식이 실재하는 번호를 튕겨 낸다 | 전화번호 체계는 각국의 규제 당국이 관리하며 몇 년마다 바뀝니다 — 휴대전화의 새로운 앞 세 자리가 추가되고, 유선전화의 지역번호가 분할되고, 새 서비스용 번호대가 만들어집니다. 앞자리를 세세히 열거한 정규식은 그 순간에는 정확해도 시간이 지나면서 실재하는 번호를 거부하게 됩니다. 게다가 번호 이동성 때문에 「이 앞자리는 휴대전화니까 SMS 가 간다」는 추론은 이제 성립하지 않습니다 — 번호대와 통신사의 대응은 고정이 아니기 때문입니다. 그리고 거부당한 사용자는 이유를 모른 채 이탈합니다 — 「당신의 번호는 무효입니다」라고 표시된 올바른 번호의 소유자에게는 손쓸 방법이 없습니다. | 정규식은 「명백히 이상한 입력을 튕겨 내기」 위해서만 쓰세요. 구체적으로는 자릿수의 하한과 상한, 쓸 수 있는 문자 종류, 국가번호의 타당성 정도로 그칩니다 — 앞 세 자리의 열거는 계속 갱신할 각오가 없다면 쓰지 않는 편이 안전합니다. 정확성이 필요한 장면 (SMS 인증·본인 확인·과금) 에서는 유지되고 있는 라이브러리를 쓰세요 — libphonenumber 는 각국의 번호 계획을 지속적으로 갱신하고 있으며 그 작업을 스스로 떠맡을 이유가 없습니다. 정말로 도달하는지를 확인하는 유일한 방법은 실제로 보내는 것입니다 — SMS 로 확인 코드를 보낸다면 정규식의 정밀도는 최종적인 검증에 중요하지 않게 됩니다. |
| 검증 전에 정규화하지 않았다 | 사람은 같은 번호를 여러 가지로 씁니다 — 하이픈 있음·없음, 공백 구분, 괄호 붙임, 국가번호 있음·없음, 앞의 0 있음·없음, 그리고 전각 숫자. 스마트폰의 연락처에서 복사하면 보이지 않는 제어 문자나 특수한 공백이 섞이기도 합니다. 날 문자열을 그대로 정규식에 통과시키면 이것들은 전부 「무효」가 됩니다 — 게다가 입력한 본인에게는 무엇이 다른지 보이지 않습니다 (전각과 반각 숫자는 폰트에 따라 폭만 다릅니다). 또 하나 까다로운 것이 국내 표기와 국제 표기의 앞자리 0 입니다 — 많은 나라에서 국내에서는 앞에 0 을 붙이고 국가번호를 붙일 때는 그 0 을 뗍니다. 양쪽을 받아들이고 싶다면 어느 한쪽으로 모은 뒤에 비교할 수밖에 없습니다. |
순서를 「정규화 → 검증 → 저장」으로 고정하세요. 정규화에서는 전각을 반각으로 고치고 (전각 반각 변환) 숫자와 앞의 + 이외를 모두 제거합니다 — 이것만으로 위에 든 표기 흔들림의 대부분이 흡수됩니다. 검증은 그 정규화된 문자열에 대해 하고 저장은 E.164 형식 (+ 와 국가번호부터 시작하는 숫자만의 형태) 으로 통일하세요 — 이 형태라면 비교도 중복 판정도 국제 발송도 그대로 통합니다. 표시할 때 그 나라의 관습에 맞춰 정형하면 됩니다. 입력란에서는 하이픈이나 공백을 허용하세요 — 「숫자만 입력하세요」라는 제약은 사용자에게 정규화 작업을 떠넘기는 것일 뿐입니다. |
| 정규식 엔진마다 동작이 다르다 | 여기의 테스터는 JavaScript 엔진에서 돌기 때문에 거기서 통한 패턴이 붙여 넣은 곳에서도 똑같이 동작한다는 보장은 없습니다. 대표적인 차이가 셋 있습니다. Go 의 regexp 는 RE2 이므로 전방 탐색 ((?=...)) 과 후방 참조를 쓸 수 없습니다 — 그것들을 포함한 패턴은 컴파일 시에 오류가 됩니다. PHP 의 preg_match 는 구분자가 필요해서 /.../ 로 감싸지 않으면 경고가 나고 아무것도 일치하지 않습니다. 앵커의 의미도 흔들립니다 — $ 는 많은 엔진에서 끝의 줄바꿈 바로 앞에도 일치하므로 번호 뒤에 줄바꿈과 다른 텍스트가 붙은 입력이 통과해 버릴 수 있습니다 (JavaScript 나 Python 에서는 \z 나 \Z, 혹은 줄바꿈을 먼저 제거하는 대응이 필요합니다). |
생성한 패턴은 반드시 실제로 쓸 언어에서 한 번 시험하세요. 특히 Go 는 「동작하지 않는다」가 아니라 「기동할 때 죽는다」이므로 테스트가 없으면 프로덕션에서 알게 됩니다. 테스트 케이스는 세 종류 준비하세요: 통과해야 할 정상 번호, 튕겨 내야 할 명백한 오류, 그리고 경계 (최단·최장·국가번호 유무). 「튕겨 내야 할 입력」을 반드시 넣는 것이 요점입니다 — 정상계만 시험하면 무엇이든 통과시키는 망가진 패턴이라도 테스트가 초록이 됩니다. 그리고 정규식을 코드에 직접 쓰지 말고 이름을 붙여 한 곳에 모으세요 — 번호 계획이 바뀌었을 때 고칠 곳이 하나로 끝납니다. |
어디까지 엄격하게 할지는 그 번호를 무엇에 쓰는가로 정해집니다. 문의 폼의 임의 항목이라면 엄격한 검증은 문의를 줄일 뿐입니다 — 연락이 닿지 않으면 곤란한 것은 입력한 본인이지 당신이 대신 판정할 필요는 없습니다. 반대로 SMS 인증이나 배송 연락처라면 보낼 수 없다는 것이 즉시 업무의 실패가 되므로 형식의 검증이 아니라 실제 도달 확인 (확인 코드의 발송) 을 공정에 넣으세요. 이 둘을 같은 엄격함으로 다루는 것이 가장 흔한 설계 실수입니다. 또 하나, 전화번호는 개인정보입니다 — 로그에 출력하지 않고, 오류 메시지에 포함하지 않고, 분석 도구에 URL 파라미터로 넘기지 않습니다. 입력 도중의 값을 실시간으로 검증 API 에 보내는 설계는 특히 주의가 필요합니다. 그리고 「무효입니다」라고만 표시하는 것은 피하세요 — 몇 자리가 필요한지, 국가번호가 필요한지, 기대하는 형식을 예시하면 대부분의 입력 실수는 그 자리에서 해결됩니다.
📖 사용법
-
1
대상 국가 선택한 국가 또는 여러 국가를 OR 결합 (국제 폼) 가능. 30+ 국가 지원.
-
2
변형 선택E.164/국제/유연/모바일 전용 4 종 중 선택.
-
3
복사 또는 테스트한 번에 복사 가능. 라이브 테스터로 즉시 검증.
-
4
원하는 언어에 붙여넣기JS/PHP/Python/Ruby/Go/Java 즉시 실행 스니펫 자동 생성.
❓ 자주 묻는 질문
libphonenumber 미사용 이유?
국제 형식과 E.164 차이?
여러 국가를 하나의 정규식으로?
생성된 정규식이 완벽한가요?
🐛 이 도구에서 문제가 발생했나요?
무료 · 가입 불필요. 재현 절차만이라도 도움이 됩니다. 보고는 운영자에게 직접 전달되어 개선에 사용됩니다.
보고 감사합니다!
운영자에게 전달되었습니다. 개선에 사용됩니다.