생성형 AI (Generative AI)나 AI 에이전트가 코드를 작성하는 시대가 되었습니다. 코드를 작성하는 속도는 비약적으로 향상되었지만, 그 이면에는 새로운 문제도 발생하고 있습니다.

그것은 바로 시크릿(Secret)의 오커밋(誤commit)입니다.

API 키, 액세스 토큰, 데이터베이스 연결 문자열, 비밀키 등 본래 Git에 커밋해서는 안 되는 정보가 AI가 생성한 코드에 섞여 들어갈 가능성이 있습니다. 이 과제를 해결하기 위해, Git에 커밋하기 전에 시크릿을 감지하는 pre-commit hook인 KeyGate를 공개했습니다.

그리고 공개 후 약 2개월 만에, PyPI의 누적 다운로드 수가 10,000건을 넘어섰습니다. 이 수치에는 CI 환경에서의 다운로드도 포함되어 있습니다.

이 기사에서는 10,000 다운로드라는 숫자 그 자체보다는, 개발·공개·운영을 통해 얻은 지견을 공유하고자 합니다.

계기는 AI 에이전트였습니다.

인간은 "이것은 API 키이므로 커밋해서는 안 된다"라는 지식을 가지고 있습니다. 하지만 AI는 입력값이나 주변 코드에 비밀 정보가 포함되어 있다면, 그것을 그대로 생성 결과에 포함하는 경우가 있습니다. 물론 최종적인 책임은 인간에게 있습니다. 하지만 AI가 코드를 작성하는 양이 늘어날수록, 인간이 계속해서 리뷰하는 것은 현실적으로 불가능합니다.

따라서 필요해지는 것이 "Git에 들어가기 전에 막아주는 가드레일(Guardrail)"입니다.

시크릿 감지 도구는 수없이 많이 존재합니다.

하지만 대부분은

• GitHub로 Push한 후
• CI가 동작한 후
• 리포지토리를 스캔한 후

에 감지합니다.

저는 Git 이력에 남기 전에 막는 것이 중요하다고 생각했습니다.

한번 Git 이력에 남은 비밀 정보는

• Force Push
• History Rewrite

등의 사후 처리 비용이 매우 커집니다.

사고는 발생한 뒤에 대처하는 것보다 발생하지 않도록 하는 것이 압도적으로 저렴합니다.

시크릿 감지에는

• Recall (재현율)
• Precision (정밀도)

이라는 두 가지 지표가 있습니다.

저는 Recall을 최우선으로 했습니다. 이유는 단순합니다. 오탐(False Positive)은 번거로움을 주지만, 미탐(False Negative)은 정보 유출로 이어지기 때문입니다.

검증에서는,

라는 결과가 나왔습니다.

즉, 검증 코퍼스(Corpus)에서는 미탐 제로를 달성했습니다.

Recall만을 추구하면 오탐이 늘어납니다. 그렇다면 Precision을 100%에 가깝게 만들면 될까요? 그렇지 않습니다. Precision을 높인다는 것은 "수상한 것도 통과시킨다"는 방향이 됩니다.

그 결과, 정말 위험한 시크릿을 놓칠 가능성이 높아집니다. 보안 도구로서 저는 이 트레이드오프(Trade-off)를 받아들일 수 없었습니다.

그렇다면 오탐을 어떻게 다룰 것인가. 이 부분이 설계에서 가장 고민했던 지점입니다. 만약 모든 것을 BLOCK(차단)한다면, 개발자는 번거로움 때문에 도구를 무효화할 것입니다. 그렇게 되면 의미가 없습니다.

그래서 KeyGate에서는

• 명확한 시크릿 → BLOCK
• 의심스러운 것 → WARN

이라는 2단계 방식을 채택했습니다.

즉, 보안과 개발 경험(Developer Experience)의 균형을 설계로 해결하고자 했습니다.

이번에 KeyGate가 PyPI에서 10,000 다운로드를 넘어서며 새삼 느낀 점이 있습니다. 그것은 "OSS는 좋은 코드를 쓴다고 해서 자연스럽게 사용되는 것이 아니다"라는 점입니다. README를 작성하고, Qiita에서 설계 사상을 설명하고, X에서 지속적으로 발신하여 겨우 조금씩 사용될 수 있게 되었습니다.

돌이켜보면, OSS에는 다음 세 가지가 필요하다고 느낍니다.

"무엇을 만드는가"보다 "어떤 과제를 해결하는가"가 더 중요합니다. 저는 AI 에이전트가 코드를 작성하는 시대에 "시크릿의 오커밋 사고는 향후 더욱 늘어날 것이다"라는 과제에 주목했습니다.

만약 단순히 "시크릿 감지 도구를 만들었습니다"라고만 했다면, 수많은 기존 도구들 사이에 묻혔을 것입니다. "AI 시대의 Git 가드레일"이라는 문제 설정이 있었기에 관심을 끌 수 있었습니다.

OSS는 소스 코드만으로는 전달되지 않습니다. 왜 그런 설계를 했는지를 설명하는 것도 중요합니다.

KeyGate에서는

• Recall을 우선하는 이유
• BLOCK/WARN의 2단계 설계
• 오탐과의 트레이드오프

를 처음부터 의식하여 설계했습니다.

단순히 기능을 나열하는 것보다 "왜 그런 설계인가"를 설명하는 것이 이용자로 하여금 안심하고 도입하게 만듭니다.

마지막으로 필요한 것은 발신입니다. 아무리 좋은 OSS라도 존재를 알리지 못하면 사용되지 않습니다.

저는

• README 개선
• Qiita에서의 기사 공개
• X에서의 발신

를 계속했습니다.

공개하는 것으로 끝나는 것이 아니라, "왜 만들었는지", "무엇을 해결하는지"를 계속해서 전달하는 것 또한 OSS 개발의 일부라고 느끼고 있습니다.

물론 코드의 품질은 중요합니다. 하지만 그것만으로는 충분하지 않습니다.

이용자는 소스 코드를 읽기 전에,

• 무엇을 해결하는 도구인가
• 왜 필요한가
• 다른 것과 무엇이 다른가

를 판단합니다. 즉, 처음에 평가받는 것은 코드가 아니라 문제 설정과 설계 사상, 그리고 발신(공유)입니다. 10,000 다운로드를 통해 제가 가장 강하게 실감한 점은 바로 이 부분이었습니다.

PyPI의 다운로드 수는 이용자 수가 아닙니다. CI 환경으로부터의 자동 다운로드도 포함되어 있습니다.

따라서 "10,000명이 사용하고 있다"라고는 말할 수 없습니다. 한편으로, 약 2개월 만에 10,000 다운로드를 넘었다는 것은 적어도 일정 수의 개발 환경에서 테스트되었고, 지속적으로 가져가고 있다는 것을 나타내는 숫자라고 받아들이고 있습니다.

숫자 이상으로 기뻤던 것은 "이런 도구가 필요했다"라는 피드백이었습니다.

AI는 앞으로 점점 더 코드를 작성하게 될 것입니다. 하지만 AI가 생성한 코드를 그대로 운영 환경(Production)으로 흘려보내는 시대는 오지 않을 것이라고 생각합니다.

필요한 것은 AI를 신뢰하는 것이 아니라, AI를 안전하게 사용하기 위한 메커니즘입니다. 저는 이것을 "AI Security Gate"라고 부르고 있습니다.

• Git에 들어가기 전
• CI로 흘려보내기 전
• 운영 환경에 배포(Deploy)하기 전

각 단계에 가드레일(Guardrail)을 설치함으로써, AI를 더욱 안심하고 활용할 수 있게 될 것입니다.

KeyGate는 아직 완성된 형태가 아닙니다.

앞으로는,

• 더 많은 시크릿(Secret) 포맷에 대한 대응
• AI 생성 코드를 전제로 한 탐지 로직의 개선
• 개발자 경험(Developer Experience)을 해치지 않는 운영 기능 추가

에 집중할 예정입니다. AI가 코드를 작성하는 시대이기에 더욱, "안전하게 개발하기 위한 가드레일"의 중요성은 앞으로 더욱 높아질 것이라고 생각합니다.