Claude Code의 "다음부터 확인하지 않기"로 비밀번호 유출?
機械翻訳 / Machine-translated
A
AI Friends
2時間前・8分で読める
機械翻訳 / Machine-translated
@aifriends
AI Friends（https://aifriends.jp）のクロスポスト公式アカウント。AIツールの紹介・使い方・できることを、中学生でもわかるやさしい日本語で届けます。
Claude Code에서 "Yes, and don't ask again"을 눌러본 적 있으신가요? 사실 확인 절차를 생략하는 이 선택이 비밀번호를 GitHub에 공개해버리는 원인이 되고 있었습니다. 이 글에서는 무슨 일이 일어났는지와, 오늘부터 실천할 수 있는 대책을 정리합니다.
보안 기업 Apiiro가 2026년 11월 5일에 조사 결과를 공개했습니다. GIGAZINE의 보도에 따르면, GitHub 상에서 발견된 민감 정보(비밀번호나 API 키 등, 타인에게 노출되어서는 안 되는 정보)는 총 2,539건입니다.
조사 대상은 Claude Code가 생성하는 설정 파일인 .claude/settings.local.json입니다. 공개되어 있던 동명의 파일은 10만 4,185건이었습니다.
그중 1,122건의 파일에 민감 정보가 포함되어 있었습니다. 관련된 조직은 63개에 달합니다.
의료 기록 데이터베이스의 관리자 비밀번호와 결제 서비스의 운영용 인증 정보도 발견되었다고 보고되고 있습니다.
Claude Code는 명령어를 실행하기 전에 "실행해도 괜찮습니까?"라고 묻습니다. 여기서 "Yes, and don't ask again(허용하고 다음부터 확인하지 않기)"을 선택하면, 해당 명령어가 설정 파일에 기록됩니다.
문제는 명령어 문자열이 그대로 저장된다는 점입니다. 예를 들어 데이터베이스에 접속하는 명령어에 비밀번호를 직접 입력했다면, 비밀번호도 함께 남게 됩니다.
이 설정 파일은 원래 자신의 PC 안에만 보관하는 것입니다. 그런데 실수로 Git(소스코드의 변경 이력을 관리하는 도구)에 등록하면, GitHub에 공개되어버립니다.
Git의 제외 설정(.gitignore)은 개별 PC에 저장됩니다. 다른 PC에서는 적용되지 않습니다. 게다가 한 번 Git 관리에 포함된 파일은 제외 설정을 추가해도 보호할 수 없습니다.
발견된 민감 정보의 내역은 다음과 같습니다.
파일이 클수록 위험했습니다. 8KB 이상의 설정 파일에서는 9.9%에 민감 정보가 포함되어 있었습니다. 오래 사용할수록 "다음부터 확인하지 않기"의 기록이 늘어나기 때문입니다.
또 하나 주목할 점은 탐지 도구의 한계입니다. 일반적인 2가지 도구로 조사한 결과, 민감 정보를 포함한 1,122건 중 215건은 어느 도구에서도 발견되지 않았습니다.
비밀번호는 "단순한 명령어의 일부"로 기록됩니다. 정해진 형식의 키를 찾는 도구는 이를 놓치기 쉽습니다.
사실 비슷한 문제는 봄에도 지적된 바 있었습니다. 보안 기업 Lakera의 조사를 TechTalks가 2026년 4월에 보도했습니다.
npm(JavaScript 패키지 배포 서비스)의 패키지 약 4만 6,500건을 조사한 결과, 428건에 동일한 설정 파일이 포함되어 있었습니다. 그중 30개 패키지의 33개 파일에는 실제로 사용 가능한 상태의 인증 정보가 있었습니다.
이번 조사는 GitHub가 무대로, 규모가 훨씬 커졌습니다. 공개 장소가 달라도 원인은 같은 "명령어 통째 저장"입니다.
Claude Code의 개발 책임자 보리스 체르니(Boris Cherny) 씨는 2026년 11월 7일 Hacker News에 댓글을 달았습니다.
그에 따르면, Claude Code는 이 파일을 생성할 때 Git의 제외 대상으로 설정하는 기능을 갖추고 있습니다. 따라서 유출된 파일은 수동으로 생성되어 Git에 등록된 것일 것이라는 견해입니다.
한편, Claude Code가 민감 정보를 삭제하는 처리를 지금까지 수행하지 않았다는 점도 인정했습니다. 인증 정보를 감지하는 기능 추가와, 자동 모드에서 민감 정보 저장을 방지하는 방법을 검토 중이라고 합니다.
논의 중에는 반대 의견도 있었습니다. "허용 목록은 결과가 정해져 있지만, AI에게 자신의 행동을 심사하게 하는 것은 불확실하다"는 목소리입니다. 이 점은 아직 결론이 나지 않은 상태입니다.
보호 방법은 몇 가지가 있습니다. 각각의 특징을 정리합니다.
이미 유출된 경우에는 파일을 삭제하는 것만으로는 부족합니다. 공개 이력에 남은 인증 정보를 무효화하고 새로 발급받는 것이 필요합니다.
또한 체르니 씨는 GitHub 등에서 시크릿 스캔(민감 정보 자동 탐지 기능)을 활성화할 것을 권장하고 있습니다.
한국에서도 Claude Code를 사용하는 개발자가 늘고 있어, 남의 일이 아닙니다.
예를 들어, 외주 개발 회사를 생각해봅시다. 팀원 5명이 각자 "다음부터 확인하지 않기"를 누르며 고객의 데이터베이스에 접속하는 명령어를 실행합니다. 한 명이 설정 파일을 실수로 커밋하면, 고객의 운영 환경 비밀번호가 공개 리포지토리에 올라가버립니다.
개인 개발자의 경우도 마찬가지입니다. 취미로 만든 앱을 GitHub에 올렸을 때 결제 서비스의 키가 섞여 있다면, 부정 사용으로 이어질 우려가 있습니다.
회사 차원에서는 CI(자동으로 테스트와 검사를 수행하는 도구)에 ".claude/가 공개 대상에 포함되어 있으면 실패하도록" 하는 규칙을 추가하는 방법이 있습니다. TechTalks도 동일한 대책을 제시하고 있습니다.
Q. 내 리포지토리는 괜찮을까?
A. .claude/settings.local.json이 Git에 등록되어 있지 않은지 확인하세요. 내용에 비밀번호나 토큰이 없는지도 확인해두면 안심할 수 있습니다.
Q. "다음부터 확인하지 않기"는 더 이상 사용하지 않는 게 좋을까?
A. 사용하는 것 자체가 나쁜 것은 아닙니다. 비밀번호가 포함된 명령어에서는 사용을 피하고, 환경 변수로 대체하세요.
Q. 이미 공개해버렸다면 어떻게 해야 하나?
A. 파일을 삭제하는 것만으로는 부족합니다. 이력에 남은 인증 정보를 무효화하고 재발급받으세요.
Q. 시크릿 스캔이 있으면 충분한가?
A. 충분하다고 할 수 없습니다. 이번 조사에서는 215건이 일반적인 2가지 도구 어느 쪽에서도 탐지되지 않았습니다.
우선 자신의 리포지토리에서 .claude/settings.local.json이 Git에 포함되어 있지 않은지 확인해보세요.
이 글은 AI Friends에서 크로스포스트되었습니다.
