문제 정의: AI가 짜준 코드에 키가 그대로 박혀 있다
AI 코딩 도구는 편하다. 그런데 대부분의 예제 코드는 API 키를 소스에 직접 문자열로 박아 넣는 방식으로 되어 있다. AI도 그 관례를 그대로 따라 api_key = "sk-..." 형태의 코드를 뱉는다. 문제는 그다음이다. 그 커밋이 공개 저장소든 사내 저장소든 저장소로 올라가는 순간, 인증정보가 세상에 노출된다.
"우리는 비공개 레포라 괜찮다"는 생각부터 깨야 한다. 조사에 따르면 사내(internal) 저장소가 공개 저장소보다 하드코딩 시크릿을 품고 있을 확률이 약 6배 높다. 비공개라는 안심이 오히려 검사를 느슨하게 만들기 때문이다.
왜 중요한가: 규모와 속도가 동시에 커졌다
2025년 한 해 공개 GitHub 커밋에 신규로 노출된 하드코딩 시크릿은 약 2,865만 개. 전년 대비 34% 늘어난 역대 최대 단일연도 증가폭이다. 특히 AI 보조 커밋의 시크릿 노출률은 3.2%로, 전체 평균 1.5%의 약 2배다. AI 보조 커밋은 한 번에 더 많은 코드를 쏟아내는 경향이 있어 키가 섞여 나갈 표면이 그만큼 넓다. LLM·클라우드 API 키 같은 AI 서비스 크리덴셜 노출은 1년 새 81% 급증했다.
한 번 새면 삭제로 끝나지 않는다
가장 위험한 오해는 "파일 지우면 된다"는 생각이다. git은 이력을 남긴다. 다음 커밋에서 키를 빼도, 과거 커밋 이력에는 키가 그대로 남아 누구나 되살릴 수 있다. 실제로 유효성이 확인된 시크릿의 64%가 최초 유출 4년 뒤에도 여전히 악용 가능한 상태였다. 유일한 정답은 키 폐기·재발급이다. 소스 정리는 그다음이다.
해결 방법: 3단계
- 코드에서 시크릿 분리 — 키·토큰·비밀번호는
.env파일과 환경변수로 빼고, 배포 환경에서는 시크릿 매니저를 쓴다. - .gitignore로 원천 차단 —
.env를.gitignore에 등록해 커밋 자체가 안 되게 막는다. - 커밋·푸시 전 시크릿 스캐닝 — 현재 파일뿐 아니라 과거 히스토리까지 스캔한다.
이미 올라간 키가 있다면 순서가 중요하다. 먼저 재발급, 그다음 소스 정리. 반대로 하면 정리하는 사이에 유출된 키가 악용된다.
자가점검 체크리스트
- ☐ 코드·설정 파일에 하드코딩된 키·토큰·비밀번호가 있는가
- ☐
.env가.gitignore에 등록돼 있는가 - ☐ 과거 커밋 히스토리에 키가 남아 있지 않은가
- ☐ 노출이 의심되는 키를 전부 재발급했는가
- ☐ 배포 환경변수와 소스가 분리돼 있는가
- ☐ 외부에 공개된 웹앱·JS 번들에 키가 새어나가지 않는가
코드는 스캐너로, 배포된 결과물은 CodeScan으로
앞의 5개 항목은 소스 저장소 안에서 점검할 수 있다. 문제는 6번이다. 프론트엔드 JS 번들이나 배포된 API 응답으로 키가 새는 경우는 소스만 봐서는 잡히지 않는다. 실제로 인터넷에 떠 있는 우리 서비스를 외부 관점에서 봐야 한다.
보안 전문 기업 SENTRIX의 CodeScan 무료 웹 스캔은 실제 배포된 서비스를 30초 만에 점검해 노출된 시크릿, 취약한 보안 헤더, 설정 오류를 찾아낸다. 소스 코드는 시크릿 스캐닝 도구로, 배포된 결과물은 CodeScan으로 이중 점검하는 흐름이 가장 안전하다.
지금 할 일
codescan.kr에서 30초 무료 스캔으로 노출된 키·설정부터 확인하세요. 새는 키가 발견되면 그 즉시 재발급하고, 저장소 히스토리와 인프라 전반이 걱정된다면 SENTRIX 정밀 진단으로 넘어가면 된다. 노출은 시간이 지날수록 커진다. 오늘 30초가 가장 싸다.