비밀번호가 유출됐다고요? 큰일 날 수 있습니다. 동일한 비밀번호를 사용하는 모든 서비스도 털릴 수 있습니다.

비밀번호 재사용과 크리덴셜 스터핑(Credential Stuffing) 방어법

비밀번호 하나가 유출되면, 그 하나로 끝나지 않습니다.

크리덴셜 스터핑(Credential Stuffing)이란 한 사이트에서 유출된 아이디·비밀번호 조합을, 공격자가 다른 사이트들에 자동으로 대량 대입해 로그인을 시도하는 공격입니다. 비밀번호를 "푸는" 것이 아니라, 이미 새어 나온 정답을 다른 자물쇠에 차례로 끼워 보는 방식입니다.

저는 CTO로 일하며 로그인 인증 시스템을 직접 설계하고, 실제 자동화 로그인 공격 트래픽이 서버에 쏟아지는 것을 모니터링한 경험이 있습니다. 그 관점에서 분명히 말씀드릴 수 있는 건, 이 공격이 무서운 이유는 기술이 정교해서가 아니라 우리가 비밀번호를 재사용하기 때문이라는 점입니다.

이 글에서는 크리덴셜 스터핑의 정확한 정의, 작동 원리, 왜 한 번의 유출이 도미노가 되는지, 그리고 오늘 바로 적용할 수 있는 방어법까지 정리하겠습니다.

이 글이 속한 주제: 계정·비밀번호 보안

크리덴셜 스터핑이란 정확히 무엇인가?

크리덴셜 스터핑이란 이미 유출된 계정 정보(크리덴셜)를 다른 서비스에 자동 대입(stuffing)해 로그인되는 계정을 찾아내는 공격입니다. 국제 보안 표준 기구 OWASP는 이를 "다른 곳에서 탈취한 인증 정보 목록을, 사용자가 같은 자격 증명을 재사용했는지 확인하기 위해 애플리케이션에 테스트하는 행위"로 정의합니다.

핵심은 두 단어입니다.

크리덴셜(Credential): 아이디와 비밀번호 같은 인증 정보
스터핑(Stuffing): "쑤셔 넣다" — 수십만 개의 조합을 봇으로 자동 입력한다는 의미

무차별 대입(브루트 포스)과는 다릅니다

많은 분이 크리덴셜 스터핑을 비밀번호를 하나씩 추측하는 무차별 대입 공격과 혼동합니다. 둘은 다릅니다.

구분	크리덴셜 스터핑	무차별 대입(브루트 포스)
입력값	이미 유출된 실제 ID·비밀번호 조합	무작위로 생성한 비밀번호
전제 조건	다른 사이트의 유출 데이터	없음
성공의 열쇠	사용자의 비밀번호 재사용	약한 비밀번호
차단 난이도	높음(정상 비밀번호이므로)	상대적으로 낮음

브루트 포스가 "무작위로 열릴때까지 열어보는" 것이라면, 크리덴셜 스터핑은 "옆집에서 주운 진짜 열쇠를 우리 집 문에 꽂아 보는" 것에 가깝습니다. 그래서 더 위험합니다. 입력되는 비밀번호 자체가 누군가의 진짜 비밀번호이기 때문에, 서버 입장에서는 정상 로그인과 구분하기 어렵습니다.

크리덴셜 스터핑은 어떻게 작동하는가?

공격은 대체로 다음 흐름을 따릅니다.

유출 데이터 확보 — 공격자는 다크웹이나 해킹 포럼에서 유출된 계정 목록을 구합니다. 2025년 기준 단일 데이터셋에 160억 건의 자격 증명이 모여 있던 사례가 보고되기도 했습니다.
자동화 봇 준비 — 수백~수천 개의 IP(프록시)와 봇을 동원해, 사람처럼 보이게 분산 로그인을 시도합니다.
대량 대입 — 확보한 ID·비밀번호 조합을 여러 사이트의 로그인 창에 자동으로 밀어 넣습니다.
성공 계정 선별 — 로그인에 성공한 계정만 추려냅니다.
수익화 — 탈취한 계정으로 포인트·마일리지 도용, 결제, 추가 개인정보 수집, 혹은 계정 자체를 재판매합니다.

성공률은 낮지만, 규모가 모든 것을 바꿉니다

크리덴셜 스터핑의 1회 성공률은 약 0.1~2%에 불과합니다. 클라우드플레어에 따르면 1,000번 시도해 한 번 성공하는 수준입니다.

문제는 시도량입니다. 보안 업계 분석에 따르면 매월 약 260억 건의 크리덴셜 스터핑 시도가 발생하며, 이는 18개월 만에 약 50% 증가한 수치입니다. 성공률 0.1%라도 260억 건이면 매월 수천만 개 계정이 뚫린다는 계산이 나옵니다.

왜 한 번 털린 비밀번호가 위험한가? — 진짜 이유

여기서부터가 이 글의 핵심입니다. 비밀번호 하나의 유출이 왜 당신의 모든 계정을 위협하는지, 그 진짜 이유는 비밀번호 재사용에 있습니다.

데이터가 이를 분명히 보여줍니다.

2024년 4월~2025년 4월 사이 유출된 비밀번호 190억 개를 분석한 결과, 94%가 여러 계정에서 재사용·중복된 것으로 나타났습니다.
지난해 유출에 노출된 사용자의 70%는 이미 유출된 적 있는 비밀번호를 다시 사용하고 있었습니다(SpyCloud).
사용자의 89%는 비밀번호 재사용이 위험하다는 것을 알면서도, 실제로 계정마다 고유한 비밀번호를 쓰는 사람은 12%에 불과했습니다.

즉, 어느 쇼핑몰에서 새어 나간 당신의 이메일 + 비밀번호 조합은, 같은 비밀번호를 쓴 이메일·은행·SNS·쇼핑·게임 계정의 마스터키가 됩니다. 공격자가 그 조합 하나만 손에 넣으면, 나머지는 봇이 알아서 전부 시도합니다.

실무에서 본 가장 흔한 시나리오는 이렇습니다. 보안이 허술한 소규모 사이트에서 비밀번호가 유출 → 같은 비밀번호를 쓴 사용자의 주요 서비스 계정이 줄줄이 탈취 → 정작 잘 만든 대형 서비스도 "정상 비밀번호 입력"이라 막기 어려움. 약점은 가장 허술한 사이트 하나가 만들고, 피해는 가장 중요한 계정에서 터집니다.

실제 피해 사례와 국내 현황

크리덴셜 스터핑은 먼 나라 이야기가 아닙니다.

개인정보보호위원회와 한국인터넷진흥원(KISA)이 발간한 자료에 따르면, 2023년 접수된 개인정보 유출 사고 307건 중 크리덴셜 스터핑이 활용된 사례가 보고됐고, 국내 유통 기업의 대규모 고객정보 유출 사고에서도 이 수법이 거론됐습니다. 글로벌 통계로는, 2025년 베리존 DBIR 보고서가 분석한 침해 사고의 22%에서 탈취된 자격 증명이 초기 침투 경로로 사용됐습니다.

YMYL 안내: 이 글은 일반적인 보안 정보 제공을 목적으로 하며, 개별 사고의 법적·금전적 책임이나 구체적 대응은 전문가 및 해당 기관(KISA 118 등) 상담을 권합니다.

지금 당장 할 수 있는 방어법

좋은 소식은, 막는 방법이 어렵지 않다는 것입니다.

사용자가 할 일

비밀번호 재사용을 멈추세요. 이것 하나만 지켜도 크리덴셜 스터핑의 전제 조건이 무너집니다.
비밀번호 관리자를 쓰세요. 사이트마다 다른 무작위 비밀번호를 외울 필요 없이 자동 생성·저장할 수 있습니다.
2단계 인증(MFA)을 켜세요. 가장 강력한 방어책입니다. 마이크로소프트 분석에 따르면 MFA는 계정 탈취의 99.9%를 막을 수 있습니다. 비밀번호가 털려도 두 번째 인증이 벽이 됩니다.
유출 여부를 확인하세요. 내 이메일이 유출됐는지 점검하고, 그렇다면 해당 비밀번호를 쓰는 모든 계정을 즉시 변경하세요.

서비스 운영자가 할 일

운영자라면 MFA 제공, 비정상 로그인 패턴 탐지, CAPTCHA·레이트 리밋, 유출된 비밀번호 차단(거부 목록), 디바이스 핑거프린팅 등 다층 방어(defense in depth)를 권합니다. OWASP는 단일 수단에 의존하지 말 것을 강조합니다.

FAQ

크리덴셜 스터핑과 무차별 대입 공격의 차이는 무엇인가요?

무차별 대입은 무작위로 비밀번호를 추측합니다. 크리덴셜 스터핑은 이미 유출된 진짜 ID·비밀번호 조합을 다른 사이트에 대입합니다. 후자는 정상 비밀번호를 쓰기 때문에 탐지가 더 어렵습니다.

내 비밀번호가 이미 털렸는지 조회할 수 있나요?

이메일 유출 조회 서비스(예: Have I Been Pwned)나 브라우저·비밀번호 관리자의 유출 점검 기능으로 확인할 수 있습니다. 유출이 확인되면 같은 비밀번호를 쓰는 모든 계정을 변경하세요.

비밀번호를 복잡하게 만들면 크리덴셜 스터핑을 막을 수 있나요?

부분적으로만 그렇습니다. 아무리 복잡해도 재사용하면 한 곳만 털려도 전부 위험합니다. 복잡성보다 고유성과 2단계 인증이 핵심입니다.

2단계 인증(MFA)만 켜면 안전한가요?

MFA는 가장 효과적인 방어책으로 대부분의 계정 탈취를 막지만, 100%는 아닙니다. 피싱으로 인증 코드까지 가로채는 공격도 있으므로, 고유한 비밀번호와 함께 사용하는 것이 가장 안전합니다.

결론

크리덴셜 스터핑이란 유출된 비밀번호를 다른 사이트에 자동 대입하는 공격이고, 그 위력의 근원은 우리의 비밀번호 재사용 습관입니다. 비밀번호 94%가 재사용되는 현실에서, 한 번의 유출은 곧 모든 계정의 위기가 됩니다.

오늘 단 하나만 한다면, 가장 중요한 계정의 2단계 인증을 켜는 것부터 시작하세요. 그것이 99.9%를 막는 가장 빠른 한 걸음입니다.

이 블로그 검색