LLM이 만든 비밀번호가 위험한 이유: 100비트처럼 보이지만 실제론 27비트
"비밀번호 좀 만들어줘"라고 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'
# 모든 문자가 균등한 확률로 선택됨# "비밀번호 생성해줘"
# 결과: '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비트 |
| 보안성 | 암호학적으로 안전 | 구조적으로 취약 |
"프롬프트를 잘 짜거나 온도를 조절해도 근본적으로 해결 불가능합니다."
광고
개발자가 해야 할 일
하지 말아야 할 것
# 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에서 발견한 내용을 정리한 것입니다. 원본은 여기에서 확인할 수 있습니다.
광고
Claude Code, OpenCode 같은 AI 코딩 도구를 직접 쓰면서 AI 업계의 변화를 개발자 관점에서 기록합니다. 단순 번역이 아니라 써본 경험과 해석을 함께 남기려고 해요.
관련 글
7천 대 DJI 로봇청소기를 우연히 해킹하게 된 개발자 이야기
게임 컨트롤러로 로봇청소기를 조종하려다 24개국 7천 대 기기의 카메라, 마이크, 지도 데이터에 접근하게 된 엔지니어. AI 코딩 도구가 드러낸 스마트홈 보안의 허점.
Claude Opus 4.8 출시: 4.7 대비 코드 결함 4배 감소, Fast 모드는 3배 저렴해졌다
Anthropic이 Opus 4.8을 내놨어요. 가격은 그대로지만 코드 신뢰성이 4배 좋아졌고, Fast 모드 비용이 3배 내려갔어요. 매일 Claude Code를 쓰는 입장에서 체감 포인트를 정리했어요.
Trusted Access for Cyber 신청 방법과 대상 — GPT-5.5-Cyber와 GPT-5.5 차이
OpenAI Trusted Access for Cyber(TAC) 신청 방법은 개인은 chatgpt.com/cyber에서 신원 확인, 기업은 OpenAI 담당자를 통한 팀 단위 요청이에요. GPT-5.5-Cyber는 검증된 보안 방어자에게만 제한 공개된 OpenAI의 사이버보안 모델이에요. Trusted Access for Cyber(TAC) 프로그램은 누가 신청할 수 있는지, 접근 단계는 어떻게 나뉘는지, GPT-5.5와 무엇이 다른지 OpenAI 원문 기준으로 정리했어요.