비밀번호 정책 생성기

서비스 성격에 맞는 비밀번호 정책 문구와 조건을 생성합니다.

비밀번호 정책 생성기는 최소 길이, 문자 종류 요구사항, 최대 사용기간, 계정 잠금 임계값, MFA 필수 여부 등을 선택하면 사람이 읽을 수 있는 비밀번호 정책 문구와 그에 맞는 클라이언트 검증용 정규식을 즉시 만들어 줍니다. 사내 보안 정책서, 회원가입 폼 안내, 개발 명세에 그대로 붙여 넣을 수 있는 형태로 한국어와 영어 문구를 제공합니다.

모든 계산과 정규식 생성은 브라우저 안에서만 일어나며 어떤 입력값도 외부로 전송되지 않습니다. 길이를 우선시하는 최신 NIST 권고에 맞춰 강제 주기 변경 같은 구식 규칙을 피하면서도, 조직에 필요한 최소 요건을 명확한 문구로 정리하고 싶을 때 사용하세요.

최소 길이 (자)권장 12자 이상. 길이가 가장 강력한 강도 요소입니다.최대 사용기간 (일)0 = 강제 주기 변경 없음 (NIST 권고).계정 잠금 시도 횟수0 = 잠금 없음. 권장 5~10회.

필수 문자 종류

대문자 (A–Z)소문자 (a–z)숫자 (0–9)특수문자 (!@#$ 등)

다단계 인증(MFA) 필수

요약

최소 길이	12
필수 문자 종류	대문자, 소문자, 숫자
최대 사용기간	주기 변경 없음
계정 잠금	5회 실패 시
MFA	필수

비밀번호 정책 문구

- 비밀번호는 최소 12자 이상이어야 합니다.
- 하나 이상의 대문자(A–Z)를 포함해야 합니다.
- 하나 이상의 소문자(a–z)를 포함해야 합니다.
- 하나 이상의 숫자(0–9)를 포함해야 합니다.
- 유출 등 명확한 사유가 없는 한 주기적 강제 변경을 요구하지 않습니다.
- 로그인 실패가 5회 누적되면 계정을 일시적으로 잠급니다.
- 모든 계정에 다단계 인증(MFA)을 필수로 적용합니다.

검증용 정규식

^(?=.*[A-Z])(?=.*[a-z])(?=.*\d).{12,}$

정책에 들어가는 항목

이 도구는 다섯 가지 축으로 정책을 구성합니다. 각 항목은 정책 문구의 불릿으로 변환되고, 문자 종류 요구사항은 가입 폼 등에서 쓸 수 있는 정규식으로도 함께 출력됩니다.

최소 길이: 비밀번호의 최소 글자 수. 길이가 가장 강력한 강도 요소입니다.
문자 종류: 대문자·소문자·숫자·특수문자 중 무엇을 강제할지 선택합니다.
최대 사용기간: 며칠마다 변경을 요구할지(0이면 주기 변경 없음).
계정 잠금: 실패가 몇 번 누적되면 계정을 잠글지.
MFA: 다단계 인증을 필수로 할지 여부.

NIST 권고: 길이 우선, 강제 주기 변경 지양

미국 NIST의 디지털 신원 가이드라인(SP 800-63B)은 복잡도 규칙을 잔뜩 쌓기보다 충분한 길이를 확보하는 편이 훨씬 효과적이라고 봅니다. 핵심 권고는 다음과 같습니다.

최소 8자 이상을 허용하고, 가능하면 64자까지 긴 패스프레이즈를 허용하세요.
특정 문자 종류를 억지로 섞게 강제하는 규칙은 오히려 예측 가능한 패턴(Password1! 등)을 낳습니다.
유출 사고 등 명백한 사유가 없는 한 주기적 강제 변경을 요구하지 마세요. 잦은 변경은 더 약한 비밀번호로 이어집니다.
유출된 비밀번호 목록과 대조(차단)하고, MFA를 함께 적용하는 편이 복잡도 규칙보다 효과적입니다.

이 생성기는 위 권고를 거스르지 않도록 최대 사용기간을 0(주기 변경 없음)으로 둘 수 있게 설계되어 있습니다. 정책 문구와 함께 출력되는 검증용 정규식을 가입 폼에 적용하면, 정책 수립과 클라이언트 검증을 한 번에 처리할 수 있습니다.

출력 정규식을 쓰는 법

출력되는 정규식은 선택한 문자 종류 요구사항과 최소 길이를 검증하는 클라이언트용 패턴입니다. 각 종류 요건은 전방탐색(lookahead)으로 표현되며, 예를 들어 대문자 1개 이상은 (?=.*[A-Z]) 형태입니다. 이 정규식은 입력 폼의 즉각적인 피드백 용도이며, 실제 인증은 반드시 서버에서 길이·유출 여부 등을 다시 검증해야 합니다.

길이·문자종류별 경우의 수 (정책 강도 비교)

어떤 조합을 강제할지 고민될 때 참고할 수 있는, 문자 집합 크기와 길이에 따른 가능한 비밀번호 경우의 수입니다. 오프라인 해시 공격 기준에서 길이를 한 자 늘리는 것이 문자 종류를 하나 더 강제하는 것보다 거의 항상 강력하다는 점을 수치로 확인할 수 있습니다.

문자 집합	집합 크기	8자 경우의 수	12자 경우의 수
숫자만 `0-9`	10	10⁸	10¹²
소문자만 `a-z`	26	약 2.1×10¹¹	약 9.5×10¹⁶
대소문자+숫자 `A-Za-z0-9`	62	약 2.2×10¹⁴	약 3.2×10²¹
대소문자+숫자+기호	약 95	약 6.6×10¹⁵	약 5.4×10²³

소문자 12자(약 9.5×10¹⁶)가 4가지 종류를 모두 강제한 8자(약 6.6×10¹⁵)보다 경우의 수가 많다는 점에 주목하세요. 그래서 이 생성기는 종류를 늘리기보다 최소 길이를 12자 이상으로 잡을 것을 권합니다.

워크스루: 12자 + 대문자·숫자 요구

최소 길이 12, 대문자와 숫자를 필수로 켜고 소문자·기호는 끈 정책을 만들면 출력 정규식은 다음과 같은 형태가 됩니다.

^(?=.*[A-Z])(?=.*\d).{12,}$

(?=.*[A-Z]) — 문자열 어딘가에 대문자가 최소 1개 있는지 확인(전방탐색, 위치를 소비하지 않음).
(?=.*\d) — 숫자가 최소 1개 있는지 확인.
.{12,} — 전체 길이가 12자 이상인지 확인.

Spring2026Login은 통과하고(대문자 S, 숫자 2026, 15자), spring2026은 대문자가 없고 10자라 두 군데에서 실패합니다. 기호를 켜지 않았으므로 기호가 없어도 통과한다는 점에 유의하세요.

흔한 실수 / 함정

정규식의 .은 기본적으로 줄바꿈을 제외한 모든 문자입니다. 사용자가 비밀번호에 의도치 않게 앞뒤 공백을 넣어도 .는 공백을 길이로 세므로, 서버에서는 공백을 trim하지 말고 그대로 해시하되 붙여넣기 시 공백 혼입 여부를 별도로 안내하는 것이 안전합니다.
전방탐색 (?=.*[A-Z])은 “포함 여부”만 보고 위치를 소비하지 않습니다. 여러 종류 요건을 [A-Z].*\d처럼 한 줄로 이어 쓰면 “대문자 다음에 숫자”라는 잘못된 순서 제약이 걸립니다. 반드시 독립된 전방탐색을 나열하세요.

자주 묻는 질문

생성된 정책이나 정규식이 서버로 전송되나요?

아니요. 모든 처리는 브라우저 안에서만 이뤄지며 입력값이나 결과는 어디로도 전송되지 않습니다.

출력 정규식만으로 비밀번호 검증이 충분한가요?

아니요. 정규식은 폼에서의 즉각 피드백용입니다. 길이·문자 종류는 검증하지만 유출된 비밀번호 차단이나 사전 단어 검사는 하지 않으므로, 실제 인증은 서버에서 다시 검증해야 합니다.

왜 최대 사용기간 기본값이 강제 변경 없음인가요?

최신 NIST 권고는 유출 등 명확한 사유가 없으면 주기적 강제 변경을 권하지 않습니다. 잦은 변경은 더 약하고 예측 가능한 비밀번호로 이어지는 경향이 있기 때문입니다.

정규식이 특수문자를 어떻게 처리하나요?

특수문자 요건을 켜면 영문·숫자·공백을 제외한 문자가 하나 이상 있는지 검사하는 전방탐색을 추가합니다. 특정 기호 집합으로 제한하고 싶다면 출력된 패턴의 문자 클래스를 직접 수정하세요.

최소 길이는 얼마로 잡는 게 좋나요?

NIST는 최소 8자를 허용하되 더 긴 패스프레이즈를 권장합니다. 일반 서비스라면 12자 이상을 기본으로 두고, 관리자 계정 등 민감한 곳은 더 길게 설정하는 것을 권합니다.