이 논문은 LLM(대규모 언어 모델)이 생성한 비밀번호가 겉으로는 강력해 보이지만, 실제로는 근본적으로 안전하지 않다는 점을 심층적으로 분석하고 있다. LLM은 토큰 예측에 기반하므로, 안전하고 균일한 무작위 문자 샘플링과는 정반대로 작동하기 때문이다. 이러한 비밀번호가 실제 사용자들과 코딩 에이전트에 의해 사용되고 있으며, 이는 전통적인 보안 비밀번호 생성 방법론을 무시한 결과이다.

핵심적인 방법론은 주요 LLM(GPT, Claude, Gemini 등 최신 버전 및 가장 강력한 변형)들을 대상으로 반복적인 비밀번호 생성 테스트를 수행하고, 생성된 비밀번호의 통계적 패턴과 엔트로피를 분석하는 것이다.

1. 반복 생성 및 패턴 분석:
연구는 "Please generate a password."라는 프롬프트를 사용하여 각 LLM으로부터 여러 개의 비밀번호를 생성했다.

• Claude Opus 4.6: 50개의 비밀번호 중 30개만이 고유했으며, "G7$kL9#mQ2&xP4!w"와 같은 특정 비밀번호는 18번(36%) 반복되었다. 이는 2^-100의 기대 확률보다 훨씬 높다. 관찰된 패턴은 다음과 같다:
  • 거의 모든 비밀번호가 대문자 'G'로 시작하고, 그 뒤에 숫자 '7'이 거의 항상 따라온다.
  • 문자 선택은 매우 불균형하여 'L', '9', 'm', '2', '$', '#' 등 특정 문자만 빈번하게 나타난다.
  • 비밀번호 내에서 반복되는 문자가 없었는데, 이는 LLM이 '덜 무작위적으로 보일 수 있다'고 판단하여 회피한 것으로 보인다.
  • 마크다운(Markdown) 문법에서 특수 의미를 가지는 '*' 기호를 회피하는 경향이 있었다.

• GPT-5.2: 50개의 첫 번째 비밀번호(총 135개 중)를 분석한 결과, 거의 모든 비밀번호가 'v'로 시작했고, 그 중 절반 가까이가 'Q'로 이어지는 등 강한 규칙성을 보였다. 문자 선택 역시 좁고 고르지 못했다.

• Gemini 3 Flash: 비밀번호의 거의 절반이 'K' 또는 'k'로 시작했으며, 보통 '#', 'P', '9'가 뒤따르는 등 다른 LLM과 유사한 패턴과 고르지 못한 문자 선택을 보였다. Gemini 3 Pro는 생성된 비밀번호를 사용하지 말라는 보안 경고를 표시했지만, 그 이유는 '서버를 통해 처리되기 때문'이라고 잘못 명시했다.

2. LLM 생성 비밀번호의 엔트로피 측정:
비밀번호 강도는 엔트로피(비트 단위)로 측정되며, 무작위 비밀번호는 문자당 균일한 확률 분포를 가진다. 연구는 LLM 생성 비밀번호의 엔트로피를 두 가지 방식으로 추정했다.

• 문자 통계를 통한 엔트로피 추정:
  • Claude Opus 4.6이 생성한 50개 비밀번호 전체 문자의 분포는 매우 불균형했다. 예를 들어, 첫 번째 문자의 분포는 'G'에 50% 이상 치우쳐 있었다.
  • 캐릭터 세트(대문자 26, 소문자 26, 숫자 10, 특수문자 8)가 70개인 경우, 무작위 비밀번호는 문자당 약 $\log_2(70) \approx 6.13$ 비트의 엔트로피를 기대한다.
  • 하지만 Claude Opus 4.6의 첫 번째 문자 엔트로피는 Shannon 엔트로피 공식을 사용하여 계산했을 때 약 $2.08$ 비트에 불과했다.
  • 전체 16자 비밀번호에 대해 이 방법을 적용했을 때, LLM 생성 비밀번호는 약 $27$ 비트의 엔트로피를 가졌다. 이는 98비트의 예상 엔트로피와 비교했을 때 매우 낮은 수치이다. $2^{27}$은 초 단위로 해독될 수 있는 수준이다.

• 로그 확률(logprobs)을 통한 엔트로피 추정:
  • 일부 LLM(예: GPT-5.2)은 토큰 생성 시 모든 가능한 토큰의 확률 벡터(logprobs)를 제공한다.
  • GPT-5.2가 생성한 첫 번째 비밀번호 "V7m#Qp4!zL9@tR2^xN6$" (20자)를 분석한 결과, 첫 번째 문자에 대한 확률 분포가 'v'에 크게 편향되어 있었다.
  • 첫 번째 문자의 엔트로피는 약 $2.19$ 비트로 추정되었으며, 이는 예상치인 $6.13$ 비트보다 현저히 낮다.
  • 전반적으로 많은 문자들이 1비트 미만의 엔트로피를 가졌는데, 이는 다음 문자를 맞추는 것이 동전 던지기보다 쉬움을 의미한다.

3. 코딩 에이전트 및 에이전트 브라우저의 문제:
코딩 에이전트는 openssl rand와 같은 안전한 비밀번호 생성 도구를 사용할 수 있음에도 불구하고, LLM 내에서 직접 비밀번호를 생성하는 경향이 있다. 이는 사용자 프롬프트의 미묘한 차이(예: "Please generate a password" vs. "Please suggest a password")에도 민감하게 반응하여 LLM 기반 생성을 선호하게 만들 수 있다. 심지어 개발자가 인지하지 못하는 상황에서 에이전트가 자체적으로 LLM 생성 비밀번호를 코드에 삽입하기도 한다(예: Docker Compose 파일, FastAPI API 키, PostgreSQL 스크립트, Redis .env 파일). 에이전트 브라우저(예: ChatGPT Atlas)도 새로운 사용자 등록 시 GPT 생성 비밀번호를 선호하는 사례가 발견되었다.

4. Temperature 값의 영향:
LLM의 'temperature' 파라미터는 토큰 샘플링의 무작위성을 조절하지만, 이 값을 높여도 LLM 생성 비밀번호의 보안성은 크게 개선되지 않았다. Claude Opus 4.6에서 최대 temperature(1.0)를 사용했을 때도 여전히 반복되는 비밀번호가 관찰되었다. 반대로 최소 temperature(0.0)에서는 동일한 비밀번호만 반복적으로 생성되었다.

결론적으로, LLM은 본질적으로 통계적 패턴을 학습하고 재현하므로, 고품질 무작위성을 요구하는 비밀번호 생성에는 부적합하다. LLM 생성 비밀번호는 겉보기와 달리 예측 가능한 패턴, 반복, 낮은 엔트로피로 인해 실제 보안에 매우 취약하다.

권고 사항:

• 사용자들은 LLM이 생성한 비밀번호 사용을 피해야 한다.
• 개발자들은 코딩 에이전트에게 필요한 경우 보안 비밀번호 생성 방법을 사용하도록 명시적으로 지시해야 한다.
• AI 연구소들은 모델을 훈련시키고 코딩 에이전트를 지시하여 기본적으로 안전한 비밀번호 생성을 선호하도록 해야 한다.