AI 코딩 도우미를 쓰다 보면 “이 명령을 실행할까요?”라는 질문을 수십 번 받게 돼요. 그러다 보면 자연스럽게 손이 가는 버튼이 있죠. “Yes, and don’t ask again(네, 다시 묻지 마세요)”. 그런데 이 버튼 하나 때문에 개발자들의 데이터베이스 비밀번호와 클라우드 열쇠가 공개 깃허브에 그대로 올라가 있었다는 조사 결과가 나왔어요.
보안 기업 에이피로(Apiiro)는 11월 6일, 앤트로픽의 AI 코딩 도우미 클로드 코드(Claude Code)가 승인한 명령을 저장하는 파일 .claude/settings.local.json을 공개 깃허브에서 찾아봤더니 1,122개 파일에 비밀번호·토큰·키 같은 비밀이 최소 하나씩 들어 있었다고 밝혔어요. 미국 보안 매체 더해커뉴스가 7일 자세히 보도했고, 9일(현지 시간) 미국 SANS 인터넷 스톰 센터의 아침 방송에서도 다뤄졌어요. 오늘은 이게 어떻게 생기는 일인지, 개발자가 아니어도 왜 알아 둘 만한지, 그리고 지금 할 일을 순서대로 쉽게 풀어볼게요.
한눈에 보기
| 항목 | 내용 |
|---|---|
| 무엇이 | 클로드 코드가 “다시 묻지 않기”로 승인한 명령을 글자 그대로 저장하는 파일 .claude/settings.local.json |
| 문제 | 명령 안에 비밀번호·토큰을 직접 적었다면 그것까지 평문(암호화 안 된 글자)으로 저장됨 |
| 어디서 발견 | 누구나 볼 수 있는 공개 깃허브 저장소 |
| 규모 | 파일 104,185개 중 1,122개(약 1.1%)에 비밀, 서로 다른 비밀 1,379개 |
| 실제 악용 | 누가 썼는지는 확인 안 됨. 다만 통보받은 한 회사는 “키가 실제로 살아 있었다”고 확인 |
| 핵심 조언 | 파일을 지우기보다 비밀부터 바꾸기(교체)가 먼저 |
“다시 묻지 않기”는 원래 어떤 기능일까요?
클로드 코드는 기본적으로 대부분의 셸 명령(컴퓨터에 직접 내리는 명령)을 실행하기 전에 사용자에게 물어봐요. 이때 “다시 묻지 않기”를 누르면, 그 명령을 허용하는 규칙을 프로젝트 폴더 안의 .claude/settings.local.json에 적어 두고 다음부터는 묻지 않고 바로 실행해요. 회사 출입문에 비유하면 “이 사람은 다음부터 그냥 통과”라고 경비실 장부에 적어 두는 셈이에요.
문제는 장부에 무엇을 적느냐예요. 어떤 때는 npm test *처럼 “이런 모양의 명령은 다 통과”라는 패턴이 적히고, 어떤 때는 그 명령 한 줄이 통째로 적혀요. 통째로 적히는 경우, 명령 안에 들어 있던 비밀번호도 함께 장부에 남아요.
| 승인한 명령 예시 | 파일에 남는 것 | 위험도 |
|---|---|---|
npm test (테스트 실행) |
npm test * 같은 패턴 |
낮음 — 비밀이 없음 |
mysql -p비밀번호 ... (DB 접속) |
비밀번호가 들어간 명령 전체 | 높음 — DB 열쇠가 그대로 |
PGPASSWORD=... psql ... |
비밀번호가 들어간 명령 전체 | 높음 |
psql $DB_URL (변수 사용) |
변수 이름 $DB_URL만 |
낮음 — 진짜 값은 안 남음 |
위 표의 비밀번호 칸은 설명을 위한 예시예요. 연구진은 최신 모델(Opus 5.5, Fable 5.1)로도 같은 동작을 재현했다고 밝혔어요.
내 컴퓨터 메모가 어떻게 깃허브까지 갔을까요?
클로드 코드도 이 파일을 깃(코드 버전 관리 도구)에서 빼려고 나름 장치를 해 뒀어요. 깃 저장소에서 처음 이 파일을 만들 때 사용자의 전역 git 제외 목록에 추가해서, 그 컴퓨터에서는 모든 저장소가 이 파일을 무시하게 하는 방식이에요.
하지만 이 보호막은 그 사람의 그 컴퓨터 한 대에만 있어요. 프로젝트 자체의 .gitignore(이 저장소에서 무시할 파일 목록)에는 추가하지 않기 때문에, 다른 컴퓨터에서 작업하거나 이미 한 번 커밋된 파일이라면 보호가 따라가지 않아요. 연구진이 추적한 1,105개 저장소 중 539개에서는 클로드가 공동 작성자로 표시된 커밋이 이 파일을 바꿨대요. AI가 스스로 이 파일을 커밋에 담는 일이 흔하다는 뜻으로 해석했어요.
| 보호 장치 | 어디에 저장되나 | 다른 PC·팀원에게도 적용? |
|---|---|---|
| 전역 git 제외 목록 (클로드 코드가 자동 추가) | 내 컴퓨터의 git 설정 | 아니요 |
프로젝트 .gitignore (사람이 직접 추가해야 함) |
저장소 안 | 예 — 저장소와 함께 이동 |
| 이미 커밋된 파일 | 저장소 기록(히스토리) | 위 두 가지 모두 소용없음 |
숫자로 보는 규모
| 구분 | 숫자 | 쉽게 말하면 |
|---|---|---|
| 찾은 settings.local.json | 104,185개 (103,617개 저장소) | 이 파일 자체는 아주 흔함 |
| 비밀이 든 파일 | 1,122개 (약 1.1%) | 100개 중 1개꼴 |
| 서로 다른 비밀 | 1,379개 | 한 파일에 여러 개 든 경우도 |
| 옛 버전에만 남은 비밀 | 734개 (509개 저장소) | 파일을 지웠어도 기록에 남음 |
| 같은 비밀을 품은 포크(복제본) | 74개 저장소의 포크 211개 | 원본을 고쳐도 복제본엔 그대로 |
| 전체 합계 (공유 설정·대화 기록 포함) | 비밀 2,539개, 저장소 1,994개 | 다른 클로드 파일까지 넓히면 더 많음 |
어떤 비밀이었는지도 중요해요. 3분의 1 이상이 데이터베이스를 바로 여는 열쇠였어요.
| 비밀 종류 | 개수 | 새면 생길 수 있는 일 |
|---|---|---|
| 데이터베이스 비밀번호 | 379개 | 고객 정보·주문 기록 같은 데이터 열람·삭제 |
| 공개 서버 SSH 로그인 | 43개 | 서버에 원격으로 들어가 마음대로 조작 |
| 깃허브·깃랩·npm 토큰 | 42개 | 코드 변조, 악성 패키지 배포(공급망 공격) |
| AWS 키 | 23개 | 클라우드 자원 무단 사용, 요금 폭탄 |
파일 주인 중에는 63개 기관이 있었고 대부분 크고 작은 소프트웨어 회사였어요. 연구진은 가장 심각한 사례로 한 데이터베이스 업체의 관리자급 클라우드 키, 의료 기록 데이터베이스의 소유자 비밀번호를 꼽았어요. 월요일(현지 시간) 기준으로 비밀이 든 파일은 모두 아직 기본 브랜치에 있었고, 그중 절반은 최소 217일 동안 그대로였대요.
보안 검사 도구는 왜 못 잡았을까요?
회사들은 보통 gitleaks, TruffleHog 같은 비밀 검사 도구로 코드에 키가 섞였는지 확인해요. 그런데 연구진이 두 도구로 1,122개 파일을 검사해 보니 gitleaks는 564개, TruffleHog는 643개만 찾았고 둘 다 놓친 파일이 215개였어요.
이유는 간단해요. 이런 도구는 ghp_로 시작하는 깃허브 토큰처럼 모양이 정해진 키를 잘 찾아요. 하지만 sshpass -p나 mysql -p 뒤에 붙은 비밀번호는 그냥 평범한 단어처럼 보여서 지나치기 쉬워요. 우편함 검사관이 “카드 모양 봉투”는 잘 잡는데, 편지 본문에 적힌 비밀번호는 못 알아보는 것과 비슷해요.
| 검사 도구 | 1,122개 중 찾은 수 | 잘 찾는 것 / 놓치기 쉬운 것 |
|---|---|---|
| gitleaks | 564개 | 정해진 형식의 키 / 명령 속에 섞인 일반 비밀번호 |
| TruffleHog | 643개 | |
| 둘 다 놓침 | 215개 | 대부분 명령 안에 직접 적은 비밀번호 |
개발자가 아니어도 알아 둘 이유
“나는 코딩 안 하는데?” 싶으실 수 있어요. 하지만 내가 가입한 쇼핑몰, 병원 예약 앱, 동네 학원 프로그램도 누군가가 AI 도우미로 만들고 있을 수 있어요. 그 개발자의 DB 비밀번호가 새면, 그 안의 내 이름·연락처·주문 내역이 위험해져요. 실제로 이번 사례 중에는 의료 기록 데이터베이스의 비밀번호도 있었어요.
또 하나의 교훈은 “편의 버튼은 무언가를 기억한다”는 점이에요. 브라우저의 “비밀번호 저장”, 앱의 “자동 로그인”, AI 도우미의 “다시 묻지 않기”는 모두 어딘가에 그 정보를 적어 두는 기능이에요. 그 메모가 어디에 있고 누가 볼 수 있는지 한 번쯤 생각해 보는 습관이 도움이 돼요.
오늘 할 5가지 (순서가 중요해요)
| 순서 | 할 일 | 예시 |
|---|---|---|
| 1 | 비밀부터 교체 — 파일에 한 번이라도 들어갔던 비밀번호·토큰·키는 전부 새로 발급 | DB 비밀번호 변경, 깃허브 토큰 폐기 후 재발급 |
| 2 | 저장소와 옛 기록에서 .claude/settings.local.json, .claude/settings.json 찾기 |
지금은 없어도 과거 커밋에 남았는지 확인 |
| 3 | 추적 끊고 프로젝트 .gitignore에 추가 |
git rm --cached .claude/settings.local.json |
| 4 | 커밋한 적 없어도 내 PC의 파일을 열어 비밀이 든 규칙 삭제 | npm 패키지·도커 이미지·압축 파일·동기화 폴더로 퍼질 수 있음 |
| 5 | 비밀은 명령에 직접 쓰지 말고 변수 이름으로, 승인은 패턴으로 | $DB_URL, Bash(npm run:*) |
왜 1번이 먼저일까요? 파일을 지워도 깃 기록과 포크에는 남아 있어서, 이미 누가 복사해 갔다면 소용이 없어요. 현관 열쇠를 잃어버렸을 때 “열쇠를 찾는 것”보다 “자물쇠를 바꾸는 것”이 먼저인 것과 같아요.
회사 보안 담당자라면
| 권고 | 이유 |
|---|---|
.claude/, .cursor/, .gemini/, .specstory/ 같은 에이전트 폴더를 .env처럼 취급 |
노트북과 저장소 모두에 비밀이 들어 있을 수 있음 |
| 커밋 전·CI 비밀 검사에 포함하고 git 기록까지 검사 | 명령 속 비밀번호도 잡도록 규칙 보강 필요 |
조직의 .gitignore 템플릿에 .claude/settings.local.json 추가 |
개인 PC 설정에 기대지 않기 |
| 공개 서버 주소와 짝지어진 비밀부터 확인 | 실제로 접속에 쓰일 수 있는 것부터 막기 |
참고로 연구진이 문서를 비교한 코딩 에이전트 16종 가운데, 승인한 명령 전체를 기본으로 프로젝트 파일에 저장한다고 확인된 건 클로드 코드뿐이었어요. 다만 다른 도구도 비슷한 메모를 남길 수 있으니 에이전트 폴더 전체를 살피는 게 안전해요.
아직 남은 질문
이 동작은 처음 알려진 게 아니에요. 2025년 8월 11일에도 “API 키와 토큰이 settings.local.json에 그대로 저장된다”는 버그 보고가 올라왔지만, 60일 동안 활동이 없다는 이유로 자동 봇이 “계획 없음”으로 닫았어요. 연구진이 인용한 관련 보고 네 건이 모두 같은 봇에 의해 닫혔고, 앤트로픽의 답변은 없었다고 해요. 앤트로픽이 저장 방식을 바꿀지는 아직 알려지지 않았어요.
정리
| 기억할 것 | 한 줄 설명 |
|---|---|
| 원인 | “다시 묻지 않기”가 비밀번호 든 명령을 글자 그대로 저장 |
| 퍼진 길 | 프로젝트 .gitignore에 없어서 커밋·공개 저장소·포크로 확산 |
| 놓친 이유 | 명령 속 비밀번호는 흔한 검사 도구가 잘 못 알아봄 |
| 첫 행동 | 파일 삭제보다 비밀 교체가 먼저 |
| 습관 | 비밀은 변수로, 승인은 패턴으로 |
AI 도우미가 일을 빠르게 해 주는 만큼, “무엇을 기억해 두는지”도 함께 챙겨야 하는 시대예요. 편의 버튼을 누르기 전 1초만 “이 명령에 비밀번호가 들어 있나?”를 떠올려 보세요. 그 1초가 회사 데이터베이스 전체를 지켜 줄 수 있어요.