"비밀번호는 복잡하게, 90일마다 바꾸세요." 이 익숙한 조언의 절반은 처음부터 틀렸고, 나머지 절반은 시대에 뒤떨어졌습니다. 현대 보안에서 정답은 비밀번호를 완벽하게 다듬는 일이 아니라, 비밀번호 하나가 뚫려도 무너지지 않는 구조를 짜는 일입니다.
비밀번호만큼 모두가 한마디씩 거들면서, 동시에 잘못 알고 있는 주제도 드뭅니다. "특수문자를 섞어라", "주기적으로 갈아라", "남에게 알려주지 마라" 같은 규칙은 너무 오래 들어서, 우리는 그것이 정말 공격을 막아 주는지 따져 보지 않습니다. 이 글은 그 익숙한 규칙들을 하나씩 분해해, 무엇이 미신이고 무엇이 실제로 효과가 있는지를 가려냅니다. 그리고 더 중요한 결론 — 비밀번호 논의의 진짜 무게중심은 비밀번호 바깥에 있다는 것 — 으로 넘어갑니다. 여기서 다루는 점검과 도구는 모두 본인 소유의 계정과 시스템에만 적용하십시오.
미리 핵심을 한 줄로 요약하면 이렇습니다. 비밀번호는 언젠가 새어 나간다고 가정하고(침해 가정의 원칙), 그래도 계정이 멀쩡한 구조를 만드는 편이, 새지 않는 완벽한 비밀번호를 만드는 것보다 현실적이고 강력합니다.
미신 1: "자주 바꿀수록 안전하다"
가장 널리 퍼졌고, 동시에 가장 해로운 미신부터 봅시다. 3개월 또는 90일마다 비밀번호를 강제로 교체하게 하는 정책입니다. 직관적으로는 자주 갈아 끼울수록 안전할 것 같지만, 실제 결과는 오히려 그 반대인 경우가 많습니다.
강제 교체가 보안을 갉아먹는 이유
문제의 뿌리는 기술이 아니라 사람의 행동에 있습니다. 두 달마다 새 비밀번호를 외워야 하는 사람은, 매번 강력하고 전혀 새로운 문자열을 떠올리지 못합니다. 그래서 가장 게으른 방식으로 규칙을 통과시킵니다.
| 강제 교체가 유도하는 실제 행동 | 결과 |
|---|---|
Spring2026! → Summer2026! 처럼 끝부분만 바꾸기 |
다음 값이 뻔히 예측됨 |
숫자 한 자리만 +1 (pass1 → pass2) |
한 개가 뚫리면 나머지도 노출 |
| 외우기 쉬운 단순한 패턴으로 회귀 | 비밀번호 품질 자체가 하락 |
| 포스트잇·메모장에 적어 두기 | 물리적 유출 경로 생성 |
여기에 더해, 비밀번호를 더 자주 입력하고 더 자주 새로 만들수록 노출 기회도 같이 늘어납니다. 교체하는 순간, 메모하는 순간, 반복해서 타이핑하는 순간마다 새는 틈이 생깁니다. 즉 "자주 바꿔라"는 요구가 더 약하고 더 예측 가능한 비밀번호를 대량으로 찍어 내는 셈입니다.
그럼 언제 바꿔야 하나
교체의 기준은 달력이 아니라 사건이어야 합니다.
- 유출됐거나 유출이 의심될 때
- 사용하던 서비스에서 침해 정황이 보고됐을 때
- 그 비밀번호가 약했다는 사실을 뒤늦게 깨달았을 때
이건 한 사람의 의견이 아니라 사실상의 국제 표준입니다. 미국 NIST(국립표준기술연구소)의 디지털 인증 지침 SP 800-63B는 "유출 정황이 있을 때를 제외하고 비밀번호를 주기적으로 강제 변경하도록 요구하지 말 것"을 명시합니다. 다시 말해, 사내 규정에 아직 "90일마다 변경"이 남아 있다면 그것은 보안을 위한 장치가 아니라 표준에 역행하는 관행입니다. 실제 보안 컨설팅 현장에서 고객사 정책을 손볼 때 가장 먼저 들어내는 항목도 바로 이 주기적 강제 변경이며, 이 조항을 없애는 것만으로 사용자들의 비밀번호 품질이 눈에 띄게 좋아집니다.
미신 2: "복잡할수록 안전하다" — 절반만 맞는 말
다음은 "대소문자·숫자·특수문자를 섞어 복잡하게 만들라"는 조언입니다. 이건 완전한 미신은 아니고, 절반만 맞는 말입니다. 의미는 있지만, 그 이유를 정확히 짚지 못하면 엉뚱한 곳에 힘을 쏟게 됩니다.
복잡함이 실제로 막아 주는 것
복잡함의 목적을 흔히 "사람이 머리로 추측하기 어렵게" 만드는 것이라 오해합니다. 그러나 더 결정적인 목적은 따로 있습니다. 공격자가 미리 모아 둔 비밀번호 목록(사전)에 내 비밀번호가 들어 있지 않게 하는 것입니다.
공격자는 비밀번호를 하나하나 상상해서 입력하지 않습니다. 그들은 과거 수많은 유출 사고에서 수집한 실제 비밀번호와 흔한 단어 조합을 거대한 데이터베이스로 만들어 두고, 그것을 자동화 도구로 초당 수만~수백만 건씩 던집니다(무차별 대입, 그리고 유출 쌍을 그대로 재입력하는 자격 증명 스터핑). 만약 내 비밀번호가 — 누군가 이미 쓴 적이 있어 유출 데이터에 포함됐거나, 흔한 조합이라서 — 그 목록 안에 있다면, 아무리 복잡해 보여도 사실상 즉시 뚫립니다.
그래서 "복잡하게"의 진짜 뜻은 남들이 안 쓰는, 그래서 그 목록에 없는 비밀번호를 쓰라는 것입니다. 특수문자가 도움이 되는 이유도 그 자체가 마법이라서가 아니라, 흔한 사전에서 벗어나게 해 주기 때문입니다.
복잡함보다 중요한 두 가지: 길이와 고유성
현대의 이해는 복잡함보다 길이와 고유성을 앞에 둡니다.
길이가 중요한 까닭은, 충분히 긴 비밀번호는 무차별 대입으로 깨는 데 비현실적으로 긴 시간이 걸리기 때문입니다. 짧고 복잡한 것보다, 길면서 외울 수 있는 편이 대체로 낫습니다. 무관한 단어 여러 개를 이어 붙인 패스프레이즈(passphrase)가 좋은 예입니다. 예를 들어 correct-horse-battery-staple 같은 구절은 기억하기는 쉬우면서도 충분히 길어 무차별 대입에 강합니다.
이 방향 역시 NIST SP 800-63B와 일치합니다. 이 표준은 "반드시 대문자·숫자·특수문자를 섞어라" 같은 복잡도 강제 규칙(composition rule)을 요구하지 말 것을 권하고, 대신 충분한 길이(최소 8자, 가능하면 훨씬 길게 허용)와 유출 목록 대조를 강조합니다. 표준이 가리키는 나침반 역시 "복잡함"이 아니라 "길이와 고유성"인 셈입니다.
고유성이 중요한 까닭은 바로 다음에 다룰 재사용 문제 때문입니다. 아무리 강한 비밀번호라도 여러 곳에 돌려쓰는 순간, 한 곳의 유출이 모든 곳의 침해로 번집니다.
정리하면, "복잡하게"라는 조언은 틀린 게 아니라 부정확합니다. 정확한 문장은 이렇습니다. 흔하지 않고, 충분히 길고, 어디에도 재사용하지 않은 비밀번호를 쓰십시오.
진짜 위협: 재사용
복잡함이나 교체 주기는 곁가지입니다. 비밀번호와 관련해 가장 실질적이고 현실적인 위협은 재사용입니다. 이건 미신이 아니라 매일 실제로 계정을 털고 있는 진짜 위협입니다.
재사용 한 번이 모든 계정을 무너뜨리는 구조
사람의 기억에는 한계가 있어서, 많은 이들이 여러 서비스에 같거나 비슷한 비밀번호를 돌려씁니다. 그리고 이것이 오늘날 계정 침해의 가장 흔한 원인 중 하나입니다. 자격 증명 스터핑이라 부르는 공격의 흐름은 이렇습니다.
- 어떤 서비스가 침해되어 비밀번호가 유출됩니다. 당신 잘못이 아니어도, 당신이 쓰던 서비스가 뚫리면 당신의 비밀번호가 유출 데이터에 섞여 들어갑니다.
- 공격자는 그 유출된 아이디·비밀번호 쌍을 들고, 당신이 같은 값을 썼을 법한 다른 서비스 — 이메일, 금융, 업무 시스템 — 에 차례로 그대로 입력합니다.
- 한 곳이라도 같은 비밀번호를 재사용했다면, 한 서비스의 유출이 당신의 전 계정으로 번집니다.
이것이 고유성을 강조한 이유입니다. 아무리 강한 비밀번호라도 재사용하는 순간 그 강도는 무의미해집니다. 가장 허술한 서비스의 보안 수준이, 그 비밀번호를 쓰는 모든 곳의 보안 수준으로 끌어내려지기 때문입니다.
지금 1분 점검. 내 이메일이나 비밀번호가 과거 유출에 포함됐는지는 Have I Been Pwned(HIBP)에서 즉시 확인할 수 있습니다. 보안 연구자 Troy Hunt가 운영하는 무료 서비스로, 공개된 수십억 건의 유출 계정을 모아 둔 데이터베이스입니다. 이메일을 넣어 하나라도 걸린다면, 그 비밀번호를 재사용한 모든 곳을 지금 바꿔야 한다는 신호입니다(앞서 말한 "사건이 생겼을 때"의 바로 그 사건입니다). 비밀번호 칸이 아니라 이메일을 넣는 게 핵심이고, 비밀번호 자체를 확인하려면 같은 사이트의 'Pwned Passwords'를 쓰면 됩니다 — 비밀번호 원문이 서버로 전송되지 않도록 설계돼 있어 안전합니다.
해법: 비밀번호 관리 도구
모든 서비스마다 서로 다른 강한 비밀번호를 쓰는 일은, 사람의 기억력으로는 불가능합니다. 그래서 현실적인 해법은 단 하나, 비밀번호 관리 도구(password manager)입니다.
관리 도구는 서비스마다 서로 다른 강한 비밀번호를 자동 생성하고, 암호화해 보관하고, 로그인할 때 채워 줍니다. 사용자는 강력한 마스터 비밀번호 하나(그리고 뒤에서 다룰 다단계 인증)만 기억하면 되고, 나머지는 도구가 떠맡습니다. 덕분에 재사용 없이 모든 서비스에 고유하고 강한 비밀번호를 쓸 수 있게 됩니다. 기억의 한계라는 근본 문제를 도구가 대신 풀어 주는 것입니다.
널리 쓰이는 선택지로는 오픈소스이며 무료 요금제만으로도 개인용에 충분한 Bitwarden, 그리고 1Password 등이 있습니다. 어느 것이든 좋으니 하나를 골라 오늘 시작하는 것이 핵심입니다. 처음엔 그동안 돌려쓰던 비밀번호 몇 개를 도구가 만든 고유한 값으로 바꾸는 데서 출발해, 자주 쓰는 계정부터 차차 옮기면 됩니다. 수백 개의 서비스 자격 증명을 다루는 실무자도 머릿속에 외우는 비밀번호는 관리 도구의 마스터 비밀번호 단 하나뿐이고, 나머지는 전부 본인조차 외우지 못하는 무작위 문자열입니다.
다만 이 도구가 곧 모든 비밀번호의 금고 열쇠이므로, 마스터 비밀번호는 매우 강해야 하고 반드시 다단계 인증으로 한 겹 더 잠가야 합니다. 이메일 계정이 다른 모든 계정의 열쇠이듯, 비밀번호 관리 도구도 같은 무게로 지켜야 합니다.
현대의 정답: 다단계 인증(MFA)
이제 이 글의 핵심에 도달했습니다. 비밀번호에 관한 모든 논의의 결론은 한 문장으로 압축됩니다. 현대의 비밀번호는 반드시 다단계 인증과 함께 가야 합니다. 비밀번호 하나에만 의존하던 시대는 끝났습니다.
왜 MFA가 결론인가
지금까지 본 것들 — 강제 교체의 허상, 복잡함의 한계, 재사용의 위험 — 이 하나같이 가리키는 진실이 있습니다. 비밀번호는 본질적으로 깨지기 쉬우며, 언젠가는 새어 나갈 수 있다는 것입니다. 아무리 강하고 고유하게 만들어도 피싱으로 넘어갈 수 있고, 서비스 유출에 섞일 수 있고, 온갖 경로로 빠져나갈 수 있습니다.
그러니 옳은 접근은 비밀번호를 완벽하게 다듬는 데 매달리는 것이 아니라, 비밀번호가 유출되어도 계정이 안전한 구조를 만드는 것입니다. 그 구조의 이름이 다단계 인증, 즉 MFA(Multi-Factor Authentication, 흔히 2단계 인증·2FA로도 부릅니다)입니다.
MFA는 로그인할 때 비밀번호(아는 것)에 더해 두 번째 인증 요소 — 예컨대 당신이 가진 것(특정 기기, 하드웨어 키) — 를 함께 요구합니다. 그러면 공격자가 비밀번호를 손에 넣어도 두 번째 요소가 없으면 들어올 수 없습니다. 비밀번호 유출이 곧장 계정 침해로 이어지지 않게 끊어 주는 것이 MFA의 핵심 가치입니다.
적용 우선순위: 열쇠가 되는 계정부터
MFA는 이제 선택이 아니라 모든 중요한 계정의 기본 사양입니다. 특히 다음 계정에는 예외 없이 적용하십시오.
- 이메일 — 다른 거의 모든 계정의 비밀번호 재설정 열쇠
- 비밀번호 관리 도구 — 모든 비밀번호의 금고 열쇠
- 금융 계정 — 은행, 증권, 결제 서비스
- 업무 시스템 — 서버 콘솔, 클라우드 관리자, 사내 핵심 시스템
모든 MFA가 똑같이 안전한 것은 아니다
다만 분명히 짚을 점이 있습니다. MFA는 방식에 따라 안전성이 크게 다릅니다. 어떤 방식은 피싱에 취약합니다 — 공격자가 가짜 로그인 페이지로 유도해 비밀번호와 함께 두 번째 요소(예: 일회용 코드)까지 실시간으로 가로채는 정교한 피싱이 존재하기 때문입니다.
가능하면 피싱에 강한 방식, 특히 하드웨어 보안 키를 우선하십시오. 하드웨어 키는 물리적 장치가 손에 있어야 하고, 인증이 접속 중인 도메인에 묶여 있어 가짜 페이지로는 가로채기 어렵습니다. 현재 쓸 수 있는 가장 강한 두 번째 요소입니다. 그렇더라도, 어떤 형태든 MFA가 있는 것이 아예 없는 것보다 비교할 수 없이 낫습니다.
| MFA 방식 | 피싱 저항성 | 비고 |
|---|---|---|
| 하드웨어 보안 키 (FIDO2/WebAuthn) | 매우 강함 | 도메인에 묶여 가짜 페이지에 안 넘어감, 최우선 권장 |
| 인증 앱(TOTP) 일회용 코드 | 중간 | SMS보다 낫지만 실시간 피싱엔 가로채일 수 있음 |
| SMS 문자 코드 | 약함 | 없는 것보단 낫지만 SIM 스와핑·가로채기에 취약 |
사람이 아닌 시스템 연결: IP 화이트리스트
지금까지는 사람이 입력하는 비밀번호를 다뤘습니다. 그런데 시스템과 시스템 사이의 연결 — 특히 API 서버나 백엔드 간 통신 — 에는 또 다른 차원의 방어가 필요합니다. 바로 IP 화이트리스트입니다.
시스템 간 연결의 결정적 특성
API 서버나 백엔드에 접속할 때도 자격 증명(API 키 등)을 씁니다. 그런데 시스템 간 연결은 사람의 로그인과 결정적으로 다른 특성이 하나 있습니다. 연결하는 주체가 미리 정해져 있다는 점입니다. 사람은 카페에서도, 집에서도, 출장지에서도 로그인할 수 있지만, 백엔드 연결은 보통 정해진 몇 대의 서버 사이에서만 일어납니다.
이 특성을 무기로 삼는 방어가 IP 화이트리스트입니다. 발상은 단순합니다. 허용된 출처(IP 주소)에서 오는 연결만 받고, 그 외의 모든 연결은 기본적으로 거부하는 것입니다. 이는 공격면 축소와 기본 거부(default deny) 원칙을 시스템 연결에 그대로 적용한 형태입니다.
IP 화이트리스트가 주는 보호
보호 효과는 강력합니다. 설령 API 키나 자격 증명이 유출되더라도, 공격자가 허용된 IP 대역에서 연결하지 않는 한 그 키는 무용지물이 됩니다. 자격 증명 유출이 곧 침해로 이어지지 않게 끊어 주는 것입니다 — 사람의 로그인에 대해 MFA가 한 일을, 시스템 간 연결에 대해 IP 화이트리스트가 합니다. 둘 다 "자격 증명 하나에 의존하지 않는다"는 동일한 원리 위에 서 있습니다.
원칙은 명확합니다. API 서버 등 백엔드 연결에는 반드시 IP 화이트리스트를 적용하십시오. 정해진 시스템들 사이의 연결이라면, 그 정해진 출처만 허용하고 나머지를 전부 막는 것은 적은 노력으로 큰 보호를 얻는 방어입니다. 웹 서버 레벨에서도 간단히 표현할 수 있습니다.
# Nginx: 내부 관리·API 엔드포인트를 특정 출처에서만 허용
location /api/internal/ {
allow 203.0.113.10; # 허용할 백엔드 서버 IP
allow 203.0.113.0/24; # 또는 허용 대역
deny all; # 그 외 전부 거부 (기본 거부)
proxy_pass http://backend;
}
# 방화벽(ufw)으로 DB 포트를 특정 출처에만 개방하는 예시
ufw default deny incoming
ufw allow from 203.0.113.10 to any port 5432 # 허용된 앱 서버만 DB 접근
화이트리스트는 혼자보다 함께일 때 강하다
IP 화이트리스트는 그 자체로도 강력하지만, 다른 방어와 겹쳐 쌓을 때(깊이 방어) 훨씬 안전해집니다. 출처를 화이트리스트로 제한하고, 그 위에 강한 자격 증명을 쓰고, 통신을 TLS로 암호화하고, 백엔드를 인터넷에서 직접 보이지 않게 숨기면, 여러 겹의 방어가 백엔드 연결을 감쌉니다. 한 겹이 뚫려도 다음 겹이 막아 줍니다.
한눈에 정리: 비밀번호 미신 vs 현대의 정답
| 흔한 통념 | 실제 | 현대의 정답 |
|---|---|---|
| 90일마다 강제로 바꿔라 | 더 약하고 예측 가능한 비밀번호를 유도 | 사건(유출·의심)이 있을 때만 교체 |
| 특수문자 섞어 복잡하게 | 절반만 맞음 — 핵심은 사전에 없는 값 | 길이와 고유성 우선, 패스프레이즈 |
| 강한 비밀번호 하나면 충분 | 재사용 시 가장 약한 곳까지 함께 뚫림 | 관리 도구로 서비스마다 고유하게 |
| 비밀번호만 잘 지키면 안전 | 비밀번호는 언젠가 새어 나감 | MFA, 특히 하드웨어 키로 한 겹 더 |
| API 키만 잘 숨기면 안전 | 키도 유출될 수 있음 | IP 화이트리스트로 출처 제한 |
오늘 바로 실행할 체크리스트
위 내용을 그대로 따라 할 수 있는 행동 목록으로 압축했습니다.
- 주기적 강제 변경을 폐기하라. 달력이 아니라 사건(유출·의심)이 교체의 트리거가 되게 한다.
- 길고 고유한 비밀번호를 쓰라. 복잡함보다 길이와 고유성. 흔한 사전에 없는 값으로.
- 재사용을 끊어라. 비밀번호 관리 도구로 서비스마다 서로 다른 값을 쓴다.
- HIBP로 점검하라. 이메일을 넣어 유출 이력을 확인하고, 걸린 곳의 비밀번호를 먼저 바꾼다.
- 중요한 계정에 MFA를 켜라. 이메일·비밀번호 관리 도구·금융·업무 시스템부터.
- 가능하면 하드웨어 키를 쓰라. 피싱에 강한 두 번째 요소를 우선한다.
- 백엔드·API에 IP 화이트리스트를 걸어라. 허용된 출처만 받고 나머지는 기본 거부.
- 하나에 의존하지 않는 구조를 만들라. 유출을 가정하고, 그래도 안전하게 설계한다.
자주 묻는 질문 (FAQ)
Q. NIST가 정말 비밀번호를 주기적으로 바꾸지 말라고 했나요? 네. NIST SP 800-63B는 "유출 정황이 있을 때를 제외하고 비밀번호를 주기적으로 강제 변경하도록 요구하지 말 것"을 명시합니다. 주기적 강제 교체는 사용자가 끝자리만 바꾸거나 단순한 패턴으로 회귀하게 만들어 오히려 비밀번호 품질을 떨어뜨리기 때문입니다. 따라서 "90일마다 변경" 같은 사내 규정은 보안을 강화하기는커녕 표준에 역행합니다. 교체는 정해진 주기가 아니라 유출·유출 의심 같은 사건이 있을 때 하는 것이 맞습니다.
Q. 그럼 특수문자를 섞는 건 이제 의미가 없나요?
의미가 아주 없는 건 아니지만, 우선순위가 길이와 고유성보다 낮습니다. 복잡함의 진짜 목적은 사람의 추측을 막는 것이 아니라, 공격자가 유출 데이터로 만들어 둔 비밀번호 사전에 내 값이 들어 있지 않게 하는 것입니다. 짧고 복잡한 비밀번호보다, 무관한 단어를 여러 개 이은 충분히 긴 패스프레이즈(예: correct-horse-battery-staple)가 외우기 쉽고 무차별 대입에도 더 강합니다. NIST SP 800-63B도 복잡도 강제 규칙을 요구하지 말고 충분한 길이와 유출 목록 대조를 쓰라고 권합니다.
Q. 비밀번호 관리 도구가 뚫리면 모든 비밀번호가 한꺼번에 털리는 것 아닌가요? 이론적으로는 그래서 마스터 비밀번호가 모든 것의 단일 열쇠가 됩니다. 그렇기에 마스터 비밀번호는 매우 강하게 만들고 반드시 MFA(가능하면 하드웨어 키)로 한 겹 더 잠가야 합니다. 그렇게 보호한다면, 사람의 기억력으로는 절대 불가능한 "모든 서비스마다 고유하고 강한 비밀번호"를 현실에서 달성하게 해 주는 이득이, 단일 지점이라는 위험보다 훨씬 큽니다. Bitwarden 같은 도구는 저장소를 암호화해 보관하므로, 마스터 비밀번호와 두 번째 요소를 잘 지키는 것이 핵심입니다.
Q. MFA만 켜면 피싱도 막아 주나요? 방식에 따라 다릅니다. 모든 MFA가 피싱을 막아 주는 것은 아닙니다. SMS 코드나 인증 앱의 일회용 코드(TOTP)는, 공격자가 가짜 로그인 페이지로 유도해 비밀번호와 코드를 실시간으로 가로채는 정교한 피싱에 넘어갈 수 있습니다. 반면 FIDO2/WebAuthn 기반의 하드웨어 보안 키는 인증이 접속 중인 도메인에 묶여 있어, 가짜 도메인에서는 애초에 동작하지 않습니다. 그래서 피싱 저항성이 중요한 계정일수록 하드웨어 키를 우선해야 합니다. 다만 어떤 MFA든 없는 것보다는 훨씬 낫습니다.
Q. IP 화이트리스트는 사람의 로그인에도 적용하면 안 되나요? 사람의 로그인에는 잘 맞지 않습니다. 사람은 카페, 집, 출장지 등 어디서든 접속하므로 허용 IP를 미리 고정하기 어렵기 때문입니다. 사람의 로그인에는 MFA가 정답이고, IP 화이트리스트는 출처가 정해진 시스템 간 연결 — API 서버, 백엔드, 데이터베이스 접속 — 에 적합합니다. 둘은 "자격 증명 하나에 의존하지 않는다"는 같은 원리를 각각의 상황에 맞게 적용한 것입니다. 백엔드 연결이라면 IP 화이트리스트에 강한 자격 증명, TLS 암호화, 인터넷 비노출을 겹쳐 쌓는 깊이 방어가 가장 안전합니다.
원문 출처 및 더 알아보기
이 글은 (주)뎁팀 웹 보안팀이 운영하는 보안 가이드 사이트 SGAEPS(시그앱스)의 가이드를 바탕으로 재구성했습니다. 더 깊은 원문은 SGAEPS 가이드 원문에서 확인하실 수 있습니다.