패스워드는 복잡할수록 안전하다 — 라는 오래된 오해

신규 시스템의 사용자 인증을 설계하다가, 손이 한 번 멎었다.

“패스워드는 영문 대소문자·숫자·특수문자 중 3종 이상을 포함하여 8자리 이상으로 설정해야 합니다.” — 이 문장은 워낙 익숙해서 한 번도 의심해본 적이 없었다. 거의 모든 사이트가 이 형태의 규칙을 두고 있고, 나도 그 형태를 그대로 옮겨 적으려 했다. 그런데 어딘가에서 본 한 줄이 떠올랐다. “패스워드 복잡도 규칙을 만든 사람이 그걸 후회한다고 했다.” 정말 그런 말이 있었는지 다시 확인해보았고, 확인한 김에 현 시점의 권고가 어디까지 와 있는지도 같이 정리했다. 결론부터 적으면, 우리가 당연하게 쓰고 있는 그 규칙은 더 이상 권장되지 않는다.

시작점에 있던 사람의 회고

복잡도 규칙의 출발점은 2003년 미국 NIST 가 발행한 SP 800-63 부록 A 였다. 그 부록을 작성한 사람이 Bill Burr 다. 영문 대소문자, 숫자, 특수문자를 섞고, 주기적으로 바꾸라는 — 우리가 지금 익숙하게 쓰고 있는 — 그 골격이 바로 이 문서에서 나왔다.

2017년 Wall Street Journal 인터뷰에서 Burr 는 이렇게 말했다.

“Much of what I did I now regret.”

자신이 한 일의 많은 부분을 후회한다는 말이다. 당시 실제 사용자 데이터를 거의 가지고 있지 못해 1980년대의 한 백서에 크게 의존해 가이드를 작성할 수밖에 없었고, 결과적으로 ‘잘못된 나무에 대고 짖었다(barking up the wrong tree)’ 는 표현까지 썼다.

복잡도 규칙이 잘못된 이유는 단순하다. 사람은 규칙을 만족시키되 기억하기는 쉬운 쪽으로 변형을 만든다. password 가 막히면 Password1! 로 간다. a 를 @ 로 바꾸고, 끝에 123 을 붙이며, 회사명에 2024 를 덧붙인다. 공격자도 사람의 그런 습관을 이미 알고 있다. 결국 복잡도 규칙은 사용자에게 창의력을 강요하지만, 사람의 창의력은 예측 가능한 방향으로 흐른다.

NIST 의 현재 입장 — 길이 우선, 복잡도 금지

NIST 는 2025년 7월에 SP 800-63 Revision 4 를 발행하면서 입장을 분명히 정리했다. 패스워드를 다루는 부분(SP 800-63B) 의 규범 문구는 다음과 같다.

“Verifiers and CSPs SHALL require passwords that are used as a single-factor authentication mechanism to be a minimum of 15 characters in length.”

단일 요소(single-factor) 로 패스워드를 쓸 때는 최소 15자 이상이어야 한다. 다요소 인증(MFA) 의 한 요소로 쓰일 때만 최소 8자까지 허용한다.

“Verifiers and CSPs SHOULD permit a maximum password length of at least 64 characters.”

최대 길이는 64자 이상을 허용해야 한다. 긴 passphrase 를 쓸 자리를 시스템이 막아서는 안 된다는 뜻이다.

그리고 이 문구가 핵심이다.

“Verifiers and CSPs SHALL NOT impose other composition rules (e.g., requiring mixtures of different character types) for passwords.”

문자 종류 혼합 같은 복잡도 요구사항을 부과해서는 안 된다(SHALL NOT). SHALL NOT 은 NIST 규범에서 가장 강한 금지 표현이다. 권고가 아니라 금지다.

주기적 변경도 마찬가지로 금지로 정리됐다.

“Verifiers and CSPs SHALL NOT require subscribers to change passwords periodically.”

다만 침해 정황이 확인되면 강제 변경한다는 단서가 붙는다.

요약하면, NIST 의 새 권고는 다음 다섯 줄이다.

• 단일 요소 인증의 최소 길이는 15자.
• 최대 길이는 64자 이상 허용.
• 문자 종류 조합 강제는 금지.
• 주기적 변경 강제는 금지.
• 차단목록(commonly used, expected, or compromised passwords) 대조는 의무.

차단목록 검사는 결국 “사용자가 아무리 길게 만들어도 password12345678 같은 흔한 문자열은 막아야 한다” 는 의미다. 길이 + 차단목록의 조합이 복잡도를 대체한다.

복잡도 규칙은 왜 무너졌는가

복잡도가 무너진 이유는 한 가지가 아니다. 세 갈래의 사실이 동시에 작동한다.

1. 길이가 이미 수학적으로 더 강하다

해킹 프로그램의 무차별 대입(brute force) 관점에서 안전성은 곧 가능한 조합의 수(엔트로피) 다. 그 수학에서도 복잡도는 길이를 이기지 못한다.

길이를 한 자 늘리는 효과가 문자 종류 하나를 추가하는 효과보다 크다. 길이는 지수 자리에 붙고, 문자 종류는 밑(base) 에 붙기 때문이다. 즉 ‘복잡도를 빼면 약해진다’ 는 직관 자체가 틀렸다. 길이만으로도 더 강해질 수 있다.

2. 실제 공격은 무차별 대입이 아니다 — 사람의 패턴을 노린다

여기가 진짜 핵심이다. 현실의 패스워드 크래킹은 95⁸ 전체 공간을 뒤지지 않는다. 사람이 만들 법한 패턴만 시도한다. 사전 + 규칙 기반 공격(rule-based dictionary attack) 이라고 부르며, hashcat 같은 도구가 가장 잘 하는 일이다.

문제는 사용자가 ‘영문·숫자·특수문자 3 종 8 자’ 규칙을 만족시키는 방식이 놀랍도록 예측 가능하다는 점이다.

• 첫 글자만 대문자: Password1!, Welcome24@
• 글자 → 기호 치환(leet speak): P@ssw0rd, S3cr3t!
• 단어 + 연도: Company2024!
• 시즌 + 연도: Spring2024!, Summer25!

이런 패턴은 hashcat 의 룰셋(best64.rule, dive.rule 등) 에 이미 정리되어 있다. 결과적으로 복잡도 규칙을 충족한 8 자 패스워드의 상당수가 오프라인 공격에서 수 분 ~ 수 시간 내에 깨진다.

복잡도 규칙이 약속한 95⁸ 의 이론적 공간은 사실 95⁸ 가 아니다. 사용자가 실제로 머무는 좁은 패턴 집합으로 줄어든다. 공격자는 그 좁아진 부분만 정확히 노린다. 복잡도 규칙은 보안을 늘려준다고 약속했지만, 결과적으로 사용자의 선택 공간을 좁혀 공격자에게 사냥터를 만들어준 셈이다.

3. 부담은 결국 다른 약점이 되어 돌아온다

복잡도 규칙은 사람의 인지 부담을 크게 늘린다. 사람은 그 부담을 견디지 못해 다음과 같이 적응한다.

• 종이·메모장·휴대폰 메모에 적어둔다.
• 한 패스워드를 모든 사이트에서 재사용한다.
• 패스워드 매니저를 쓰지 않고 외울 만한 한두 패턴만 돌려 쓴다.

특히 동일 패스워드 재사용은 치명적이다. 한 사이트가 유출되면 같은 패스워드로 다른 사이트가 즉시 시도되는 credential stuffing 공격이 가능해진다. 보안의 출발점이 패스워드 한 줄이 아니라 사용자 전체 디지털 흔적의 약한 고리들 합집합이 되어버린다.

NIST 가 paste 허용을 명시한 이유도 같은 맥락이다. paste 를 막으면 패스워드 매니저 사용을 사실상 막는 셈이고, 그러면 사용자는 결국 동일 패스워드 재사용으로 흘러간다.

그래서 길이가 정직하다

길이는 정직하다. 복잡도는 그렇지 않다. 복잡도 규칙이 만든 95⁸ 공간은 사용자의 예측 가능한 패턴 안으로 좁아지지만, 길이가 만든 26¹² 공간은 사용자가 외울 수 있는 자연어 passphrase 까지 자연스럽게 포괄한다. correct-horse-battery-staple 형태의 passphrase 가 P@ssw0rd! 보다 안전하고 동시에 기억하기 쉬운 이유다.

복잡도 규칙은 좋은 의도였다. 다만 인간이 그 규칙을 어떻게 만족시키는지에 대한 데이터를 가지고 있지 않은 상태에서 만들어졌다. 이제 데이터가 쌓였고, 데이터는 이 규칙이 의도와 정반대로 작동했다는 것을 보여준다.

한국 규정 — 여전히 복잡도 + 길이 조합

그러면 한국의 권고는 어디까지 왔는가. 결론은 “아직 따라가지 않았다” 이다.

강제력을 가진 행정규칙 라인은 다음과 같다.

• 「개인정보 보호법」 제29조(안전조치의무)
• 「개인정보 보호법 시행령」 제30조(개인정보의 안전성 확보조치)
• 「개인정보의 안전성 확보조치 기준」(개인정보보호위원회 고시) 제4조(접근 권한의 관리) 제5항

제4조 제5항의 문구는 다음과 같다.

“개인정보처리자는 개인정보취급자 또는 정보주체가 안전한 비밀번호를 설정하여 이행할 수 있도록 비밀번호 작성규칙을 수립하여 적용하여야 한다.”

조문 자체는 ‘작성규칙을 수립해 적용하라’ 는 일반적 의무다. 구체적인 권고 내용은 개인정보보호위원회의 해설서(2024년 10월 발간, 2025-9호로 개정되어 2025년 10월 31일 시행) 에 ‘예시’ 로 들어 있다. 그 예시가 다음과 같다.

• 최소 10자리 이상: 영대문자·영소문자·숫자·특수문자 중 2종류 이상 조합·구성
• 최소 8자리 이상: 영대문자·영소문자·숫자·특수문자 중 3종류 이상 조합·구성
• 일련번호(12345678), 전화번호, 잘 알려진 단어(love, happy), 키보드상에서 나란히 있는 문자열(qwer) 등 사용 지양
• 최소 6개월마다 변경

별도로 KISA 가 발행한 「패스워드 선택 및 이용 안내서」(2008년 제정, 2019년 6월 개정) 도 같은 골격을 따른다.

즉 한국의 권고는 아직 복잡도 기반에 머물러 있다. 다만 두 가지를 함께 짚어둘 만하다.

첫째, 해설서 본문 안에 “기술 발달에 따라 비밀번호의 최소 길이는 늘어날 수 있음” 이라는 단서가 명시되어 있다. 즉 위 예시 자체가 영구한 기준이 아니라 시점 권고임을 발행자도 인정하고 있다.

둘째, 고시 본문이 요구하는 것은 ‘작성규칙의 수립·적용’ 이지 ‘해설서의 예시 자체’ 가 아니다. 해설서는 ‘예시’ 로 명시되어 있다. 처리자가 합리적 근거를 가지고 다른 안전 정책(예: 더 긴 길이 하한 + 차단목록 + 침해 기반 강제 변경) 을 적용하는 것은 법적 의무 위반이 아니다. 다만 감독기관 점검 시 ‘왜 그 정책이 안전한가’ 를 설명할 수 있어야 한다.

그러면 우리 시스템은 어떻게 설계하는가

내가 지금 설계하고 있는 시스템에서는 다음과 같이 정한다.

• 단일 요소 인증의 패스워드 최소 길이를 12자 로 둔다. NIST 의 15자가 가장 보수적인 기준이지만, 한국 사용자의 평균 입력 습관을 고려해 12자에서 출발한다. 시스템이 안정화되면 14~15자로 상향한다.
• 다요소 인증의 한 요소로 쓰일 때는 최소 8자로 한다.
• 최대 길이는 64자 이상 허용한다. 긴 passphrase 를 막지 않는다.
• 문자 종류 조합은 강제하지 않는다. 입력창에서 ‘대소문자·숫자·특수문자를 섞으세요’ 라는 카피를 빼고, 대신 ‘12자 이상으로 입력해주세요’ 만 남긴다.
• 주기적 변경은 강제하지 않는다. 침해 정황이 확인된 계정에 한해 강제 변경을 트리거한다.
• 차단목록 검사를 의무화한다. Have I Been Pwned 의 Pwned Passwords 데이터셋, 서비스명 변형, 사내 빈출 패스워드를 포함한다.
• 패스워드 입력 필드의 paste 를 허용한다. 패스워드 매니저 사용을 막지 않는다.

「개인정보의 안전성 확보조치 기준」에 대한 준수 입장은 다음과 같이 정리한다. 고시 제4조 제5항이 요구하는 ‘비밀번호 작성규칙의 수립·적용’ 은 충족한다. 해설서의 8자+3종 / 10자+2종 예시 대신, NIST SP 800-63B Rev. 4 를 근거로 한 12자 이상 + 차단목록 검사 + 침해 기반 강제 변경 정책을 채택했다. 길이 하한과 차단목록 검사의 조합이 복잡도 강제보다 동등 이상의 안전성을 제공한다는 점을 정책 문서에 명시해둔다.

마무리

패스워드 복잡도 규칙은 좋은 의도에서 출발했지만, 그 사이 데이터가 쌓이며 효용을 잃었다. 이제 길이는 정직하고 복잡도는 그렇지 않다는 점이 분명해졌다.

신규 시스템을 설계하는 입장에서 보면, 익숙한 규칙을 그대로 옮기지 않고 출처를 한 번 다시 확인해보는 일은 의외로 보상이 크다. 사용자가 종이에 패스워드를 적어두게 만드는 정책을, 같은 비용으로 그렇지 않은 정책으로 바꿀 수 있다면 — 그건 작지 않은 변경이다.