LLM이 만든 비밀번호가 위험한 이유: 100비트처럼 보이지만 실제론 27비트
안녕하세요, Tom입니다.
"비밀번호 좀 만들어줘"라고 Claude에게 부탁해본 적 있으신가요? 그럼 아마 이런 비밀번호가 나왔을 겁니다:
G7$kL9#mQ2&xP4!w
KeePass 같은 비밀번호 관리 도구에 넣으면 **"약 100비트 엔트로피, 매우 강력"**이라고 나옵니다. 슈퍼컴퓨터로도 수십억 년 걸릴 것 같죠?
실제로는 27비트밖에 안 됩니다. 일반 컴퓨터로 몇 초 만에 뚫릴 수 있는 약한 비밀번호예요.
실험: LLM에게 비밀번호 50번 생성시켜보니
보안 회사 Irregular가 재밌는 실험을 했습니다.
실험 방법:
- Claude Opus 4.6, ChatGPT, Gemini에게 각각
- "비밀번호를 생성해줘" 요청을 50번 반복
- 온도(temperature)를 0.0~1.0으로 바꿔가며 테스트
결과:
| 모델 | 동일 비밀번호 반복 | 고유 비밀번호 수 | 선호 패턴 |
|---|---|---|---|
| Claude Opus | 18번/50번 (36%) | 30개 | 'G'로 시작 + 두 번째 '7' |
| ChatGPT | - | - | 'v'로 시작 |
| Gemini | - | - | 'k' 또는 'K'로 시작 |
가장 충격적인 사실:
- 온도를 0.0으로 설정하면 → 50번 전부 똑같은 비밀번호
- 온도를 1.0으로 올려도 → 패턴은 여전히 존재
엔트로피 착시 현상
KeePass 평가: "100비트 엔트로피, 매우 강력"
실제 Shannon 엔트로피: 27비트
왜 이런 차이가 날까요?
진짜 강력한 비밀번호의 조건
CSPRNG (암호학적으로 안전한 난수 생성기):
import secrets
password = secrets.token_urlsafe(16)
# 결과: 'Dg3K_8xNm2pQ7vL9'
# 모든 문자가 균등한 확률로 선택됨LLM:
# "비밀번호 생성해줘"
# 결과: 'G7$kL9#mQ2&xP4!w'
# 15번째 자리가 숫자 '2'일 확률 99.7% (거의 고정)LLM은 **"가장 그럴듯한 다음 토큰"**을 예측하도록 훈련되었습니다. 즉, 예측 가능성을 극대화하는 게 목표예요.
이건 비밀번호 생성과 정반대입니다.
더 위험한 문제: AI 코딩 에이전트
여기서 끝이 아닙니다. 더 큰 문제는 AI 코딩 도구가 코드에 취약한 비밀번호를 하드코딩한다는 점입니다.
실제 사례:
# Claude Code가 생성한 코드
DATABASE_PASSWORD = "K7#mP9vL2$xQ4!w"// Codex가 생성한 코드
const API_KEY = "k9#vLmP7$Q2&xW4!";문제점:
-
"비밀번호 생성해줘" →
openssl rand같은 안전한 방법 제안
✅ 올바른 접근 -
"비밀번호 추천해줘" → LLM이 만든 패턴 비밀번호 바로 삽입
❌ 위험한 접근
실제로 GitHub에서 K7#mP9, k9#vL 같은 패턴을 검색하면 이미 수많은 저장소에서 발견됩니다.
왜 LLM은 비밀번호 생성에 부적합한가?
근본적인 구조 문제:
| 특성 | CSPRNG | LLM |
|---|---|---|
| 목표 | 예측 불가능성 극대화 | 그럴듯함 극대화 |
| 무작위성 | 완전 균등 분포 | 편향된 분포 |
| 엔트로피 | 실제 100비트 | 겉보기 100비트, 실제 27비트 |
| 보안성 | 암호학적으로 안전 | 구조적으로 취약 |
Irregular의 결론:
"프롬프트를 잘 짜거나 온도를 조절해도 근본적으로 해결 불가능합니다."
개발자가 해야 할 일
❌ 하지 말아야 할 것
# AI에게 "비밀번호 추천해줘" 요청
password = "G7$kL9#mQ2&xP4!w" # 위험!✅ 해야 할 것
# Python
import secrets
password = secrets.token_urlsafe(32)
# Node.js
const crypto = require('crypto');
const password = crypto.randomBytes(32).toString('base64');
# CLI
openssl rand -base64 32AI 코딩 도구 사용 시 주의사항
- 코드 리뷰 필수 — AI가 생성한 비밀번호/API 키는 반드시 검증
- 환경 변수 사용 — 하드코딩된 비밀번호 절대 금지
- 비밀 관리 도구 활용 — 1Password, Vault, AWS Secrets Manager 등
마무리하며
LLM은 정말 많은 것을 잘합니다. 하지만 비밀번호 생성은 그중 하나가 아닙니다.
문제는 겉보기엔 강력해 보인다는 점입니다. KeePass도 속고, 사람도 속고, 심지어 개발자도 속습니다.
핵심은 이것입니다:
- 진짜 보안은 외형이 아니라 실제 엔트로피에 달려 있습니다
- LLM의 예측 중심 설계는 비밀번호 생성과 근본적으로 맞지 않습니다
- AI 코딩 도구가 코드에 심은 취약한 비밀번호는 은밀하게 퍼질 수 있습니다
혹시 여러분 프로젝트에 AI가 생성한 비밀번호가 하드코딩되어 있진 않나요? 한 번 확인해보시는 걸 추천합니다.
이 글은 Geeknews에서 발견한 내용을 정리한 것입니다. 원본은 여기에서 확인할 수 있습니다.