비밀번호 정책은 계정의 공격 난이도를 높이면서도 안전한 행동을 불필요하게 어렵지 않게 만들어야 합니다.\n가장 효과적인 정책은 명확하고 실용적이며, 사람들이 실제로 일하는 방식에 맞추어져 있습니다. 정책은 길고 고유한 비밀번호를 장려하고, 비밀번호 관리자의 사용을 지원하며, 적재적소에 다중 인증(MFA)을 요구하고, 예측 가능한 사용자 행동을 유발하는 구시대적 규칙을 제거해야 합니다.
\n이 글에서는 현대적인 비밀번호 정책의 실천사항과 피해야 할 사항, 따라야 할 모범 사례, 그리고 바로 복사해 사용할 수 있는 정책 템플릿을 설명합니다.
\n비밀번호 정책은 비밀번호의 생성, 저장, 사용, 공유, 변경, 보호 방식에 관한 일련의 규칙입니다.\n이 정책은 직원, 계약직, 관리자, 서비스 계정, 때로는 고객까지 적용되며, 관리 대상 시스템에 따라 범위가 달라집니다.
\n좋은 비밀번호 정책은 실용적인 질문에 답해야 합니다:
\n가장 복잡한 규칙을 만드는 게 목표가 아닙니다. 진짜 위험을 줄이는 것이 목표입니다.
\n비밀번호 길이는 추측 및 무차별 대입 공격에 대한 가장 강력한 방어 수단 중 하나입니다. 조직 전체에 동일한 최소 길이 기준을 두면 여러 유형의 계정(일반, 관리자 등)에 별도 규칙을 두는 것보다 사람들이 이해하기 쉽고 IT팀도 일관되게 적용할 수 있습니다. 현실적인 기본값은 모든 사용 계정에 16자 이상을 요구하는 것입니다. 비밀번호 관리자를 사용하거나 무작위 단어 조합 패스프레이즈를 쓴다면 더 긴 것도 좋습니다.
\n사용자가 최소 길이보다 훨씬 긴 비밀번호를 만들 수 있도록 해야 합니다. 16자, 20자와 같은 낮은 최대 길이 제한은 피하세요. 최소 64자 이상의 최대 길이를 허용하는 것이 합리적이며, 많은 시스템은 그 이상도 무리 없이 지원합니다.
\n패스프레이즈 역시 허용해야 하며, 다만 널리 알려진 명언, 노래 가사, 회사 이름, 예측 가능한 문구 등은 피해야 합니다. 여러 개의 무작위 단어로 구성된 패스프레이즈는 의미 없는 짧은 비밀번호보다 보통 훨씬 강력합니다.
\n모든 계정은 고유한 비밀번호를 가져야 합니다. 비밀번호 재사용은 한 서비스에서 침해 사고가 발생했을 때 다른 서비스 계정 탈취로 이어지는 주원인 중 하나입니다. 비밀번호 관리자를 이용하면 각 계정마다 고유한 비밀번호를 실제로 사용하는 것이 실질적으로 가능합니다.
\n조직의 정책에서 지정된 비밀번호 관리자의 사용을 명확히 허용 및 권장해야 합니다. 사용자는 로그인 시 비밀번호 붙여넣기, 자동완성, 무작위 비밀번호 생성 기능을 자유롭게 활용할 수 있어야 합니다. 붙여넣기(copy-paste)를 차단하면 보호 효과가 있는 것 같지만, 오히려 강력한 비밀번호 관리자 사용을 어렵게 만듭니다.
\n비밀번호를 생성할 때, 알려진 유출 비밀번호 목록·자주 사용되는 비밀번호 목록·조직 전용 금지 목록에 포함된 경우 비밀번호를 거부하세요. 이는 대문자, 숫자, 기호를 반드시 포함시키는 등의 복잡성 강제보다 훨씬 효과적입니다.
\n다중 인증(MFA)은 기술적으로 가능한 한 모든 곳(특히 관리자, 원격접속, 클라우드, 이메일, 비밀번호 관리자, 금융 시스템 등 고위험 시스템)에 반드시 활성화해야 합니다. MFA가 강력한 비밀번호를 대체하지는 않지만, 비밀번호 탈취 시 피해를 크게 줄여줍니다.
\n피싱 대응능력이 강한 MFA(패스키, 하드웨어 보안키, 플랫폼 인증기 등)를 우선 사용하세요. 앱 기반 인증기가 SMS 인증보다 일반적으로 안전합니다. SMS 기반 MFA는 가능한 다른 방법이 있다면 절대 사용하면 안 됩니다. 전화번호는 탈취, SIM 스와핑, 번호 이동, 계정 복구 악용 등 다양한 위협에 노출될 수 있기 때문입니다.
\n이것은 단순한 이론이 아닙니다. 2018년, Reddit은 SMS 기반 2FA가 공격자에 의해 가로채져 내부 시스템이 침해되었음을 공개했습니다: https://www.reddit.com/r/announcements/comments/93qnm5/wehadasecurityincidenthereswhatyouneed_to/. 2021년, Coinbase는 신원 도용과 SMS 복구 절차의 취약점을 악용한 공격으로 적어도 6,000명의 고객 암호화폐가 탈취되었음을 보고했습니다: https://www.reuters.com/technology/coinbase-says-hackers-stole-cryptocurrency-least-6000-customers-2021-10-01/.
\n피싱, 사용자 기기 내 악성코드, 정보유출, 의심스러운 로그인, 비밀정보의 우발적 공개 등 침해가 의심되거나 확인되면 그 즉시 비밀번호를 변경해야 합니다.
\n가능한 한 공유 비밀번호 사용을 지양하고, 개별 계정 생성을 우선하세요. 어쩔 수 없이 공유해야 한다면 승인을 받은 비밀번호 관리자에 저장·공유하고, 접근은 권한 있는 사용자로 제한하며, 공유 이력 또한 가능하다면 기록하세요.
\n비밀번호 재설정은 계정 보안에서 가장 취약한 지점일 수 있습니다. 재설정 작업 시 신원 확인, 재설정 링크의 빠른 만료, 1회용 토큰 사용, 비밀번호 변경/재설정 시 사용자에게 알림을 꼭 포함하세요.
\n30일, 60일, 90일마다 비밀번호를 의무적으로 변경하게 하는 것은 오히려 더 약한 비밀번호를 유도할 수 있습니다. 사용자는 숫자 추가, 계절 변경 등 예측하기 쉬운 방식만 바꿉니다. NIST(미국 국립표준기술연구소)의 Digital Identity Guidelines도 불필요한 정기 교체를 폐기하고, 침해가 의심될 때에만 변경을 요구합니다. 참고: 3.1.1.2 항 https://pages.nist.gov/800-63-4/sp800-63b.html#passwordver 의심되는 침해, 역할 변경, 계정 복구, 정책 미준수 등에만 변경 조치를 적용하세요.
\n\"대문자, 소문자, 숫자, 특수문자 포함\"과 같은 규칙만으로는 보안이 확보되지 않습니다. Password1!은 이런 복잡성 규칙을 충족하지만 여전히 약한 비밀번호입니다. 길이, 고유성, 무작위성, 유출 비밀번호 차단을 우선하세요.
붙여넣기 차단은 비밀번호 관리자 사용을 어렵게 만듭니다. 결국 더 짧고 타이핑하기 쉬운 약한 비밀번호 사용을 유도할 수 있습니다. 특정하고 문서화된 보안 사유가 없는 한 붙여넣기 및 자동완성을 허용하세요.
\n비밀번호 힌트는 너무 많은 정보를 노출할 수 있습니다. 사용자가 힌트로 비밀번호를 기억할 수 있다면, 공격자도 충분히 추측할 수 있습니다. 비밀번호 재설정 시에는 안전한 신원 확인 절차를 사용하세요.
\n시스템 상에서 평문 또는 복호화 가능한 방식(가역 암호 등)으로 비밀번호를 저장해선 안 됩니다. 비밀번호는 Argon2id, bcrypt, scrypt, PBKDF2와 같은 최신의 느리고 소금값(salt)이 추가된 해시 함수로 변환해 저장해야 하며, 시스템 환경과 준수 기준에 따라 적절한 알고리즘을 선택해야 합니다.
\nMD5, SHA-1, SHA-256, SHA-512와 같은 빠른 범용 해시 알고리즘은 단독으로 비밀번호 해싱에 사용해서는 안 됩니다. 이들은 빠른 연산을 목적으로 설계되어 데이터베이스 유출 이후 오프라인 대입 공격이 쉬워질 수 있습니다. 자세한 배경은 비밀번호 해싱의 진화 글을 참고하세요.
\n비밀번호는 이메일, 채팅, 티켓, 문서, 스크린샷 등을 통해 공유해선 안 됩니다. 반드시 승인된 비밀번호 관리자의 보안 공유 및 접근 제어 기능을 이용하세요.
\n비밀번호에 이름, 생일, 회사명, 키보드 패턴, 반복 문자, '@'을 a로, '0'을 o로 대체하는 흔한 방식 등 예측 가능한 정보를 포함하지 마세요. 공격자들은 이런 패턴을 가장 먼저 시도합니다.
\n누구나 이해할 수 있는 요구사항을 적용하세요:
\n관리자, 서비스 계정, 운영 환경 접근 등 특권 계정에는 더욱 강력한 비밀번호, MFA, 접근 제한, 모니터링, 권한 변경 시 즉시 비밀번호 교체 등 특별 통제를 적용하세요.
\n강한 비밀번호만으로 과도한 권한을 보완할 수 없습니다. 각 사용자는 자신의 역할에 꼭 필요한 시스템·비밀 정보만 접근하도록 하세요.
\n비정상적 로그인 패턴, 물리적으로 불가능한 이동, 반복된 로그인 실패, 새로운 국가에서의 접속, 평소와 다른 시간대 접속 등을 탐지합니다. 비밀번호 정책은 모니터링과 사고대응이 반드시 같이 뒷받침되어야 합니다.
\n사용자 교육은 비밀번호 재사용, 피싱, 가짜 로그인, MFA 피로 공격, 안전한 공유, 의심스러운 행동 신고 절차 등 실제 위협에 집중하세요. 사용자 비난이 아니라, 안전한 행동이 쉽도록 지원하세요.
\n정책은 이해할 수 있도록 명확해야 합니다. 너무 길고, 애매하고, 비현실적으로 엄격하면 결국 사람들이 꼼수를 부리게 됩니다. 실제로 적용·준수할 수 있어야 가장 좋은 정책입니다.
\n아래 템플릿을 출발점으로 활용하세요. 대괄호 부분을 귀사 사정, 시스템, 위험 수준, 법·규정에 맞게 수정하면 됩니다.
\n비밀번호 정책\n\n버전: [1.0]\n책임 부서: [정보보호/IT부서]\n시행일: [YYYY-MM-DD]\n검토 주기: [매 12개월]\n\n1. 목적\n\n이 정책은 [조직명]에서 비밀번호를 생성, 사용, 저장, 공유, 변경하는 요건을 정의합니다. 목적은 무단 접근, 자격 증명 탈취, 계정 탈취, 데이터 손실의 위험을 줄이는 데 있습니다.\n\n2. 적용 범위\n\n이 정책은 [조직명]의 시스템, 애플리케이션, 네트워크, 클라우드, 데이터에 접근하는 모든 직원, 계약직, 임시 직원, 서비스 제공자 및 기타 사용자에게 적용됩니다.\n\n정규 계정, 특권 계정, 서비스 계정, 공유 계정과 인증에 비밀번호가 사용되는 모든 시스템이 포함됩니다.\n\n3. 비밀번호 생성 요건\n\n모든 비밀번호는 아래 요구사항을 따라야 합니다:\n\n- 인간 사용자 계정은 16자 이상을 사용해야 합니다.\n- 비밀번호는 반드시 고유해야 하며, 업무/개인 계정 간 재사용이 금지됩니다.\n- 이름, 사용자명, 회사명, 생일, 키보드 패턴, 반복 문자, 쉽게 추측 가능한 정보는 포함할 수 없습니다.\n- 흔한 문구, 명언, 가사, 예측 가능한 대체문자 사용 등도 금지합니다.\n- 알려진 유출 비밀번호나 흔히 쓰이는 비밀번호는 사용할 수 없습니다.\n- 공백, 기호, 숫자, 대소문자 등 사용 가능\n- 패스프레이즈는 길며 고유하고, 예측 가능하거나 공공의 문구가 아닐 때 허용됩니다.\n\n4. 비밀번호 관리자\n\n[조직명]은 승인된 비밀번호 관리자를 통한 비밀번호 생성, 저장, 공유 사용을 권장(필요 시 의무화)합니다.\n\n사용자는 승인된 비밀번호 관리자의 비밀번호 생성기, 자동완성, 복사/붙여넣기 기능을 사용할 수 있습니다. 비밀번호는 브라우저, 엑셀, 문서, 노트앱, 이메일, 채팅, 스크린샷, 승인되지 않은 도구에 저장하지 말아야 합니다.\n\n5. 다중 인증(MFA)\n\n아래를 포함하되 이에 국한되지 않는 모든 가능한 곳에서 다중 인증(MFA)이 활성화되어야 합니다:\n\n- 이메일 계정\n- 원격 접속 시스템\n- 비밀번호 관리자\n- 클라우드 서비스\n- 관리자 계정\n- 재무·인사 등 고위험 시스템\n- [기밀/중요 시스템]으로 분류된 기타 시스템\n\n가능한 경우, 패스키, 하드웨어 보안키, 플랫폼 인증기 등 피싱 내성이 강한 방식으로 MFA를 사용해야 합니다. 인증기 앱을 SMS 방식보다 우선 사용합니다. SMS 기반 MFA는 다른 방식이 기술적으로 불가능할 때만 허용됩니다.\n\n6. 비밀번호 변경\n\n다음의 경우 비밀번호를 즉시 변경해야 합니다:\n\n- 비밀번호가 유출·침해된 것으로 확인 또는 의심되는 경우\n- 사용자가 피싱 사이트에 비밀번호를 입력한 경우\n- 비밀번호가 무단 타인과 공유된 경우\n- 사용자 기기에서 악성코드나 비인가 접근이 탐지된 경우\n- 비밀번호가 유출된 데이터에서 확인된 경우\n- 특권 계정 사용자의 역할/고용 상태 변경 등\n- IT/보안부서의 비밀번호 변경 요청 시\n\n법률, 규정, 계약, 시스템 제한에 따라 요구되지 않는 한 주기적 비밀번호 만료는 필요하지 않습니다. 이전 비밀번호를 예측 가능하게 소폭 변경하는 것은 허용되지 않습니다.\n\n7. 비밀번호 공유\n\n비밀번호는 이메일, 채팅, 티켓, 문서, 스크린샷, 전화, 말 등으로 공유해서는 안 됩니다.\n\n공유가 불가피하거나 [정보보호/IT]의 명시적 승인을 받은 경우에만, 승인된 비밀번호 관리자로 관리하며 접근 권한은 승인된 사용자로 한정, 공유 이력을 기록합니다.\n\n8. 특권 계정\n\n특권 계정은 절대 일반 계정과 중복되는 비밀번호를 쓸 수 없습니다. 가능한 한 모든 특권 계정은 MFA를 적용하고, 정기적으로 검토해야 합니다.\n\n관리자가 퇴사, 역할 변경, 권한 상실, 침해 의심 시 특권 비밀번호 즉시 교체해야 합니다.\n\n9. 서비스 계정 및 애플리케이션 비밀정보\n\n서비스 계정의 비밀번호, API키, 토큰, 애플리케이션 비밀은 반드시 승인된 비밀관리 시스템 또는 비밀번호 관리자에 저장해야 합니다.\n\n서비스 계정 자격증명은 승인된 비밀관리 절차로 보호되지 않는 한, 소스코드, 설정 파일, 이미지, 문서, 스크립트 등에 직접 포함시켜선 안 됩니다.\n\n10. 비밀번호 재설정 및 계정 복구\n\n비밀번호 재설정 시 신원을 반드시 확인해야 하며, 재설정 링크/임시 비밀번호는 1회만 사용, 짧은 기한 내 만료, 승인된 채널로만 전달해야 합니다.\n\n비밀번호 변경/재설정 시 사용자가 통지를 받아야 하며, 임시 비밀번호는 첫 로그인 시 반드시 변경해야 합니다.\n\n11. 기술적 통제\n\n비밀번호 저장/처리 시스템은 다음을 준수해야 합니다:\n\n- 비밀번호를 결코 평문으로 저장하지 않습니다.\n- PBKDF2, scrypt, bcrypt, Argon2 등 승인된 최신 algorithm(소금값 적용)으로 해싱합니다.\n- MD5, SHA-1, SHA-256, SHA-512 등 빠른 해시 알고리즘만으로 해싱하면 안 됩니다.\n- 인증 엔드포인트에 속도 제한 등 방어 기능 적용\n- 약하고 흔히 쓰이거나 유출된 비밀번호 거부\n- 비밀번호 관리자의 붙여넣기 허용\n- 최소 64자 이상(기술적으로 가능한 경우) 입력 허용\n- 인증 관련 보안 이벤트 로그 기록\n\n12. 침해 의심시 신고\n\n비밀번호 침해(의심 포함), 피싱, 비정상 로그인/인증 요구, MFA 인증 요청(본인이 시작하지 않은 경우), 우발적 비밀번호 노출 등은 즉시 [정보보호/IT 연락처]에 신고합니다.\n\n13. 예외\n\n이 정책의 예외는 반드시 문서화, 위험평가, 기한한정, [정보보호/IT책임자]의 승인을 받아야 하며, 가능하다면 보완통제를 적용해야 합니다.\n\n14. 정책 위반 시 조치\n\n이 정책 위반 시 [조직명]의 기준 및 관련법에 따라 접근 권한 제거, 보안 교육, 징계 등 조치가 취해질 수 있습니다.\n\n15. 정책 검토\n\n이 정책은 최소 1년에 1번 또는 시스템·위협·법률·업무 사항 변화 시마다 재검토해야 합니다.\n강력한 비밀번호 정책은 사용자를 괴롭게 만드는 것이 아니라, 약한 관습을 없애고, 비밀번호 관리자와 MFA를 적극 활용하며, 자격 증명 유출 시 신속히 대응하는 데 있습니다. 현실적인 공격(피싱, 자격 증명 수집, 재사용, 계정 침해 등)에 집중해 실질적이고, 적용 가능하며, 집행 가능한 정책을 만드세요.
","frontmatter":{"date":"May 07, 2026","slug":"password-policy-dos-donts-best-practices","title":"비밀번호 정책: 실천사항, 비권장사항, 모범 사례, 그리고 바로 복사해 사용할 수 있는 템플릿","description":"현대적인 비밀번호 정책이 요구해야 할 사항, 지양해야 할 구식 규칙, 실용적인 조직용 템플릿까지 한눈에 알아보세요.","author":"Sascha Pfeiffer","featuredImage":null}}},"pageContext":{"slug":"password-policy-dos-donts-best-practices","lang":"ko","langPathPrefix":"/ko"}},"staticQueryHashes":["2149092236","3128451518","3192060438"]}