bcrypt cost 10·12·14의 속도 차이와 운영값을 고르는 기준
bcrypt cost가 1 증가하면 핵심 연산량은 대략 두 배가 되므로 10에서 12는 약 네 배, 12에서 14는 다시 약 네 배의 계산 부담이 생깁니다. 실제 값은 서버 CPU와 구현에 따라 달라지므로 운영과 비슷한 환경에서 로그인 지연과 동시 요청을 측정해 정해야 합니다.
높은 cost가 항상 더 좋은 설정은 아닙니다. 공격 비용을 높이는 동시에 정상 로그인도 느려지므로 보안 기준, 서버 용량, 장애 시 CPU 고갈 가능성을 함께 봐야 합니다.
먼저 보는 핵심 요약
- cost는 해시 문자열 안에 저장되어 기존 계정과 신규 계정이 서로 다른 값을 사용할 수 있습니다.
- 단일 해시 시간뿐 아니라 동시 로그인과 비밀번호 재설정 트래픽을 함께 부하 시험합니다.
- 기준을 올릴 때는 사용자가 다음 로그인에 성공한 시점에 새 cost로 재해시하는 방식이 실용적입니다.
cost 숫자가 실제로 의미하는 것
bcrypt의 work factor는 반복 비용을 지수적으로 늘립니다. cost 12는 단순히 cost 10보다 20% 느린 값이 아닙니다. 구현과 하드웨어가 같다면 단계가 하나 오를 때 계산량이 크게 늘어 로그인 처리량과 공격자의 대입 속도를 동시에 낮춥니다.
개발 노트북 측정값을 운영에 그대로 쓰면 안 되는 이유
노트북의 CPU 세대, 전원 모드, 브라우저 WebAssembly와 서버 네이티브 라이브러리는 성능이 다릅니다. 운영 컨테이너의 CPU 제한과 오토스케일 조건, 피크 시간 동시 요청을 포함해 측정해야 실제 지연과 비용을 예측할 수 있습니다.
로그인 지연과 DoS 위험을 함께 보는 기준
검증 한 건이 지나치게 오래 걸리면 정상 사용자 경험뿐 아니라 공격자가 많은 로그인 요청으로 CPU를 소진시키기 쉬워집니다. 인증 API의 rate limit, 큐 길이, 타임아웃과 함께 cost를 설계해야 합니다.
기존 해시의 cost를 안전하게 올리는 방법
bcrypt 문자열에는 사용한 cost가 포함됩니다. 로그인 성공 후 현재 정책보다 낮은 cost인지 확인해 새 해시로 교체하면 비밀번호를 평문으로 저장하지 않고 점진적으로 올릴 수 있습니다. 장기간 로그인하지 않는 계정은 별도 재설정 정책이 필요합니다.
단계별로 확인하는 방법
- 후보 cost 정하기
현재 정책과 보안 가이드를 바탕으로 10, 11, 12처럼 현실적인 후보 범위를 고릅니다.
- 운영 유사 환경에서 측정하기
서버와 같은 런타임·CPU 제한으로 생성과 검증 시간을 여러 번 측정합니다.
- 동시 요청 부하 확인하기
피크 로그인 수와 비밀번호 재설정 요청을 함께 보내 CPU와 응답시간을 기록합니다.
- 재해시 정책 배포하기
로그인 성공 시 기존 해시의 cost를 읽고 정책보다 낮으면 새 값으로 교체합니다.
판단 기준을 한눈에 비교하기
| 확인 항목 | 판단 기준 |
|---|---|
| cost 10 | 레거시 bcrypt에서 자주 보는 최소선이지만 실제 보안성은 운영 환경과 위협 모델로 판단합니다. |
| cost 12 | cost 10보다 핵심 계산량이 대략 네 배로 늘어날 수 있어 서버 실측이 필요합니다. |
| cost 14 | cost 12보다 다시 큰 부담이 생기므로 동시 로그인과 CPU 고갈 위험을 반드시 시험합니다. |
| Argon2id | 신규 시스템에서는 bcrypt만 고집하지 말고 메모리 경도 알고리즘 지원 여부도 검토합니다. |
실행 전 체크리스트
- 운영과 같은 런타임에서 시간을 측정했나요?
- 동시 로그인 부하와 CPU 사용률을 확인했나요?
- 인증 API에 rate limit과 타임아웃이 있나요?
- 낮은 cost 해시를 점진적으로 재해시할 계획이 있나요?
주의할 점
브라우저 도구의 속도는 사용자의 기기와 WebAssembly 환경을 반영할 뿐 서버의 정답이 아닙니다. 실제 비밀번호나 운영 해시를 입력하지 말고 샘플로 비교한 뒤 서버에서 다시 측정하세요.
함께 보면 좋은 글
자주 묻는 질문
cost 12가 모든 서비스의 정답인가요?
아닙니다. 서버 성능, 동시 로그인 수, 위협 모델이 다르므로 운영 유사 환경의 측정 결과로 정해야 합니다.
cost를 올리면 기존 비밀번호 로그인이 깨지나요?
해시 문자열에 기존 cost가 포함되어 있어 검증할 수 있습니다. 로그인 성공 후 새 정책으로 재해시하면 점진적으로 전환할 수 있습니다.
bcrypt와 SHA-256 중 무엇이 비밀번호 저장에 맞나요?
빠른 범용 해시인 SHA-256을 단독으로 쓰는 것은 적합하지 않습니다. 비밀번호 저장용으로 설계된 느린 알고리즘과 고유 salt를 사용해야 합니다.
한글 비밀번호도 72자까지 가능한가요?
bcrypt 구현 다수는 72바이트 제한을 가집니다. UTF-8 한글은 한 글자가 여러 바이트이므로 글자 수와 바이트 수를 구분해야 합니다.
근거와 출처
- OWASP Password Storage Cheat Sheet — 보조 출처, 조회일 2026-08-30
- bcrypt 원논문 — 1차 출처, 조회일 2026-08-30
도구에서 직접 확인하기
설명한 기준을 실제 값에 적용하려면 bcrypt 해시 생성·검증에서 작은 샘플부터 확인하세요. 원본과 결과를 나란히 비교한 뒤 실제 사용 환경에 적용하는 순서가 가장 안전합니다.
이 글은 알파카랩스 Utils의 개발 도구 도구와 함께 보는 정보성 가이드입니다. 규격과 외부 서비스 정책은 바뀔 수 있으므로 중요한 결정 전에는 연결된 공식 출처의 최신 내용을 다시 확인하세요.