요약 (TL;DR)

• AI 에디터들이 API 키와 비밀 정보(secrets)를 소스 파일에 직접 하드코딩(hardcoding)하는 패턴을 반복하고 있습니다.
• 이 단일 패턴은 SOC 2, PCI-DSS, 그리고 HIPAA 심사에서 자동으로 탈락 사유가 됩니다.
• 1인 창업자와 소규모 팀들은 보안 담당자를 채용하기도 전에 기업용 보안 설문지(security questionnaires)를 받게 되며, 심사관들이 가장 먼저 검색(grep)해 보는 항목이 바로 이것입니다.

제가 자문을 해주고 있는 한 1인 창업자가 그의 첫 SOC 2 준비 심사(readiness review)를 2주 앞두고 저에게 연락을 해왔습니다. 그는 4개월 동안 Cursor를 사용하여 제품 전체를 구축했고, 빠르게 출시하고 고객들과 반복(iteration)하며, 그 단계에서 마땅히 해야 할 일들을 정확히 수행해 왔습니다. 그는 감사인이 확인하기 전에 코드베이스(codebase)를 점검해 달라고 요청했습니다.

확인한 지 10분 만에, 저는 첫 달부터 리포지토리(repo)에 커밋되어 있던 설정 파일 내의 Stripe 비밀 키(secret key)를 발견했습니다. .env 파일에 있는 것도 아니었고, 비밀 관리자(secrets manager)에 있는 것도 아니었습니다. 그저 평문(plaintext) 상태로 세 개의 서로 다른 서비스에서 직접 참조되며 그곳에 놓여 있었습니다.

이것은 부주의한 작업이 아니었습니다. 그는 유능한 엔지니어입니다. 단지 혼자서 제품을 출시하는 1인 개발자일 때는 빠르게 움직이기 위해 AI 에디터에 의존하게 되는데, AI 에디터는 당신의 리포지토리가 곧 심사를 받을 예정이라는 사실을 알지 못할 뿐입니다.

패턴 (The Pattern)

Cursor, Claude Code, 또는 Copilot에게 새로운 API 연동(integration)을 구성해 달라고 요청하면, 다음과 같은 결과를 자주 접하게 됩니다:

const STRIPE_SECRET = 'sk_live_51H8xK2eZvKYlo2C...'; // ❌
const client = new Stripe(STRIPE_SECRET);

대신 다음과 같이 되어야 합니다:

const STRIPE_SECRET = process.env.STRIPE_SECRET_KEY; // ✅
const client = new Stripe(STRIPE_SECRET);

CWE-798, 하드코딩된 자격 증명 사용(Use of Hard-coded Credentials). 이것은 가장 오래되고 문서화가 잘 된 취약점 클래스 중 하나이며, AI 에디터들은 이를 끊임없이 재현하고 있습니다.

이것이 계속 발생하는 이유

여러분이 읽어본 모든 "5분 만에 Stripe에 연결하는 방법"과 같은 튜토리얼들은 키(key)를 코드 내에 직접 하드코딩(hardcode)합니다. 왜냐하면 dotenv를 불러오고 환경 변수(environment variables)를 설명하는 과정이 블로그 포스트의 흐름을 끊기 때문입니다. 그것이 바로 학습 데이터(training data)입니다. 모델은 보안보다 가독성을 최적화한 수천 개의 문서로부터 "작동하는 예제"를 학습했으며, 사용자가 명시적으로 지시하지 않는 한 기본적으로 그 패턴을 재현합니다.

규모가 작은 팀에게 중요한 부분은 다음과 같습니다. 컴플라이언스 프레임워크(compliance frameworks)는 의도를 고려하지 않습니다. SOC 2의 CC6.1 통제 항목은 액세스 자격 증명(access credentials) 보호에 대해 명시적입니다. PCI-DSS 8.2.1은 암호화 자료(cryptographic material)를 절대 평문(plaintext)으로 저장하지 않을 것을 요구합니다. HIPAA의 164.312 기술적 보호 조치(technical safeguards) 또한 개인 건강 정보(PHI)를 다루는 모든 것에 대해 동일한 사항을 요구합니다. Git 히스토리에 포함된 단 하나의 하드코딩된 키만으로도 감사인(auditor)은 해당 통제 항목 전체를 실패로 분류하기에 충분하며, 유출된 비밀 정보를 제거하기 위해 Git 히스토리를 다시 쓰는 것은 그 자체로 몇 시간씩 걸리는 골칫거리입니다.

이제 엔터프라이즈 고객들은 이러한 요구 사항을 규모와 상관없이 모든 벤더(vendor)에게 요구하고 있습니다. 만약 여러분이 실제 보안 팀을 보유한 기업과 계약을 체결하려는 2인 규모의 스타트업이라면, 벤더 보안 설문지(vendor security questionnaire)를 받게 될 것이며, "자격 증명을 평문으로 저장합니까?"가 첫 번째 질문이 될 것입니다.

해결 방법

첫날부터 모든 비밀 정보(secret)를 환경 변수(environment variables)와 Git에서 제외된 .env 파일로 옮기세요:

echo ".env" >> .gitignore

// .env (절대 커밋하지 마세요)
STRIPE_SECRET_KEY=sk_live_...
JWT_SECRET=...
...

만약 비밀 정보가 이미 Git 히스토리에 포함되었다면, 즉시 키를 교체(rotate)한 다음 git filter-repo 또는 BFG Repo-Cleaner를 사용하여 히스토리를 삭제(scrub)하세요. 히스토리를 정리하는 것보다 키를 교체하는 것이 더 중요합니다. 키가 이미 활성화된 상태라면 히스토리 정리만으로는 노출 문제를 되돌릴 수 없습니다.

단일 개발자 단계를 넘어선다면, 적절한 비밀 관리자(secrets manager, 예: AWS Secrets Manager, Doppler, Infisical)를 사용하는 것이 장기적으로 .env 파일보다 낫습니다. 하지만 .env와 .gitignore를 사용하는 것은 최소한의 기본 요건(floor)이지, 최종 목표(ceiling)가 아닙니다.

저는 특히 이 문제를 해결하기 위해 SafeWeave를 운영해 왔습니다. 이 도구는 SOC 2, PCI-DSS, HIPAA 준수 프로필을 기본적으로 제공하기 때문인데, 이는 전담 컴플라이언스(Compliance) 담당자를 채용하지 않고도 기업 보안 심사를 통과하려는 1인 창업자나 5인 규모의 팀에게 매우 중요합니다. 이 도구는 MCP 서버로서 Cursor 및 Claude Code와 연동되어, 제가 다음 파일로 넘어가기 전에 하드코딩된 비밀 정보(Hardcoded Secrets)를 찾아내어 표시해 줍니다. 물론, gitleaks를 사용한 기본적인 프리 커밋 훅(Pre-commit hook)만으로도 이 포스트에서 다루는 내용의 대부분을 잡아낼 수 있습니다. 중요한 것은 어떤 도구를 사용하든, 코드가 배포(Ship)되기 전에 이를 잡아내는 것입니다.