비밀 정보 유출 없이 AI 사용하기: AI 보조 개발을 위한 위협 모델 (Threat Model)

누군가 에러를 마주하고, 전체 스택 트레이스 (stack trace)를 채팅창에 복사한 뒤, 모델에게 "이것 좀 빨리 해결해 줘"라고 요청합니다. 그 트레이스의 세 줄 아래에는 실제 비밀번호가 포함된 DATABASE_URL이 묻혀 있습니다. 답변은 4초 만에 돌아옵니다. 이제 그 비밀 정보는 당신이 손을 쓸 수 없는 어딘가로 흘러갔습니다.

LLM 프롬프트에 비밀 정보를 붙여넣는 것은 새로운 형태의 Pastebin 사용법과 같습니다. 다만, 사후에 요청 로그(request log)나 학습 데이터 세트(training set)에서 이를 삭제할 수 없다는 점이 다릅니다. 이 글은 AI를 피하는 것에 관한 것이 아닙니다. 저 또한 코드를 배포하기 위해 매일 AI를 사용합니다. 이 글은 신뢰 경계 (trust boundary)를 넘나드는 모든 시스템을 사용하는 방식, 즉 '느낌'이 아닌 '위협 모델 (threat model)'을 가지고 사용하는 법에 관한 것입니다.

당신의 프롬프트가 실제로 가는 곳

대부분의 사람들은 프롬프트를 개인적인 대화로 생각합니다. 하지만 그렇지 않습니다. 프롬프트는 여러 곳으로 퍼져 나가는 아웃바운드 요청 (outbound request)이며, 그 목적지는 당신이 무엇에 비용을 지불하느냐에 따라 전적으로 달라집니다.

무료 및 소비자용 티어 (free and consumer tiers)에서는 입력 내용이 종종 보관되며 모델을 개선하는 데 사용될 수 있습니다. 유료인 Pro, Team, Enterprise 티어에서는 제공업체가 일반적으로 귀하의 데이터를 학습에 사용하지 않고, 더 짧거나 제로에 가까운 보관 기간 (retention windows)을 유지하기로 계약합니다. 이 차이는 실재하며 중요합니다. 유료 계정은 진정으로 더 안전합니다. 하지만 "학습에 사용되지 않는다"는 것이 "절대 저장되지 않는다"는 것과 같은 의미는 아닙니다. 요청 로그 (request logs), 남용 탐지 시스템 (abuse-detection systems), 인간 검토 예외 사항 (human-review exceptions), 그리고 하위 프로세서 (sub-processors)는 여전히 존재합니다.

데이터가 해당 경계를 넘어 유출되는 방식에는 세 가지가 있으며, 첫 번째 방식만이 명확합니다:

당신이 붙여넣는 것: 스택 트레이스 (stack trace), 설정 (config), 코드 스니펫 (snippet) 등.
도구가 자동으로 첨부하는 것: 열려 있는 파일, 주변 리포지토리 (repo), 터미널 출력 등을 포함합니다. 현대적인 코딩 어시스턴트 (coding assistants)는 당신이 명시적으로 전달하지 않은 컨텍스트 (context)를 가져옵니다.
모델이 내뱉는 것: 이전에 입력했던 비밀 정보가 커밋 (commit), PR 설명, 또는 로그 라인 (log line)에 다시 나타나는 경우 등.

위협 모델 (The threat model)

이 논의를 정직하게 유지하기 위한 프레임워크는 다음과 같습니다: 서비스 제공자(provider)는 _적대자 (adversary)_가 아닙니다. 그들은 _신뢰할 수 있지만 검증은 불가능한 제3자 (trusted-but-unverifiable third party)_입니다. 위험은 그들이 학습에 대해 거짓말을 하는 것이 아닙니다. 위험은 사용자가 그들의 내부 파이프라인(pipeline), 정책, 하위 프로세서(sub-processors), 그리고 침해 노출(breach exposure)을 감사(audit)할 수 없으며, 이 모든 것이 시간이 지남에 따라 변한다는 점에 있습니다.

위험에 처한 자산 (Assets at risk): API 키 및 토큰, 데이터베이스 연결 문자열 (connection strings), 개인 키 및 인증서, 테스트 픽스처 (test fixtures)에 포함된 고객 개인정보 (PII), 그리고 독점적인 비즈니스 로직.
실패 모드 (Failure modes): 사용자가 가정한 범위를 넘어선 제공자의 데이터 보유, 지나치게 넓은 도구 컨텍스트 윈도우 (context window), 침해된 에디터 확장 프로그램 (editor extension), 또는 미래의 사용자 본인이 모델의 출력물을 공개적인 어딘가에 붙여넣는 경우.

프롬프트 채널을 운영 환경(production)에서 발생하는 모든 외부 네트워크 호출과 동일하게 취급하십시오: 즉, 신뢰할 수 없는 이그레스 (untrusted egress)로 간주해야 합니다. 단순히 제공자의 문서에서 주의를 기울이겠다고 약속했다는 이유만으로 평문(plaintext) 형태의 고객 데이터를 제3자 엔드포인트 (endpoint)로 전송하지는 않을 것입니다. 프롬프트 입력창이 바로 그 엔드포인트입니다.

프롬프트에 절대 넣어서는 안 되는 것

짧은 '전송 금지' 목록만으로도 대부분의 문제를 해결할 수 있습니다:

활성 자격 증명 (credentials), 토큰, 또는 API 키
.env, .env.local, .env.production 파일의 내용
개인 키, 인증서, 또는 키 자료 (key material)
이름, 이메일, 결제 데이터와 같은 실제 고객 개인정보 (PII)
오픈 소스로 공개하지 않을 독점 소스 코드의 전체 덤프 (full dumps)

중요한 뉘앙스는 이것이 '금욕'이 아니라 '마스킹 (masking)'에 관한 것이라는 점입니다. 플레이스홀더 (placeholders)를 사용하는 것은 완전히 괜찮으며, 모델은 이에 대해서도 충분히 잘 추론합니다: [API_KEY], [DB_PASSWORD], postgres://user:****@host/db와 같은 방식입니다. 실제 답변을 얻기 위해 실제 값이 필요한 경우는 거의 없습니다. 만약 이미 비밀 정보 확산 문제 (secrets-sprawl problem)를 겪고 있다면, AI 보조는 그 위에 데이터 유출 경로를 하나 더 추가할 뿐입니다.

컨텍스트 위생 (Context hygiene): 유출을 구조적으로 불가능하게 만들기

"조심해야지"라고 의존하는 방식은 피곤해지는 순간 실패합니다. 대신, 데이터가 기기를 떠나기 전에 실행되는 루프로서 워크플로우(workflow) 자체에 규율을 구축하십시오.

세 가지 구체적인 습관이 이를 뒷받침합니다:

AI 도구를 위한 ignore 파일: 이는 AI 시대의 .gitignore입니다. 어시스턴트(assistant)가 자동으로 첨부하는 컨텍스트(context)에서 .env, 비밀 정보(secrets) 디렉토리, 키 자료(key material)를 제외하십시오.
전송 전 스캔: 비밀 정보 탐지(secret detection)를 pre-commit 단계뿐만 아니라 프롬프트 입력 전(pre-prompt)의 습관으로 실행하십시오. 수정 비용이 가장 저렴한 유출은 에디터(editor)를 떠나지 않은 유출입니다.
평문(plaintext)이 아예 존재하지 않도록 유지: 이것이 더 깊은 원칙이 적용되는 지점입니다. 비밀 정보가 암호문(ciphertext)으로 저장되고 런타임(runtime) 시에만 메모리로 복호화된다면, 애초에 유출할 수 있는 붙여넣기 가능한 평문 자체가 존재하지 않습니다. 이것이 바로 봉투 암호화 (envelope encryption)와 KMS 기반 비밀 정보 위협 모델 (KMS-backed secrets threat model)이 제공하는 가치이며, 제가 암호화된 env 파일을 코드베이스에서 완전히 제외하는 이유입니다.

클라우드 vs 유료 티어 vs 로컬: 데이터에 적합한 환경 선택하기

정직한 답변은 가치의 대부분을 버리게 되는 "모든 것을 셀프 호스팅(self-host)하라"가 아닙니다.
전송하려는 데이터의 민감도에 맞춰 티어(tier)를 매칭하는 것입니다.

티어	학습 미사용 보장 (No-training guarantee)	검증 가능 여부?	용도
무료 / 소비자용 채팅	대개 보장되지 않음, 학습할 수 있음	아니요	일회성 코드 조각, 공개 문서
...

그리고 결정 과정은 다음과 같은 흐름을 따릅니다:

대부분의 실제 엔지니어링 작업에서는 학습을 하지 않는다는 계약(no-training agreement)이 포함된 유료 티어(paid tier)를 사용하는 것이 실용적인 기본값입니다. 사실을 있는 그대로 말하겠습니다. 로컬 모델이나 셀프 호스팅(self-hosted) 모델로 내려가는 경우는 데이터가 규제 대상이며, 단순히 약속을 받는 것을 넘어 데이터가 제3자를 거치지 않았음을 _증명_해야 할 때뿐입니다. PCI 규정 하의 결제 데이터나 HIPAA 규정 하의 의료 데이터는 결코 소비자용 채팅 티어를 거쳐서는 안 됩니다. 이것은 절대적인 원칙입니다.

AI에 적용된 제로 트러스트 (Zero-trust)

이 부분이 모든 것을 하나로 묶어줍니다. 우리는 유료 티어를 사용합니다. 우리는 실제 업무를 수행할 수 있을 만큼 '학습을 하지 않겠다'는 약속을 충분히 신뢰합니다. 그럼에도 불구하고 우리는 여전히 핵심 기밀(crown jewels)을 붙여넣지 않습니다. 제공업체가 거짓말을 한다고 생각해서가 아니라, 보호해야 할 가장 저렴한 비밀은 기계 밖으로 한 번도 나가지 않은 것이기 때문입니다.

학습 미사용 보장은 기술적 (technical) 통제가 아닌 계약적 (contractual) 통제입니다. 이는 위험을 낮춰줄 뿐, 제거해주지는 않습니다. 따라서 우리는 이를 하나의 계층으로 취급하며, 프롬프트 채널(prompt channel)이 어쨌든 적대적일 수 있다고 가정합니다. 이는 여러분이 모든 경계에 적용하는 것과 동일한 제로 트러스트 태세 (zero-trust posture)와 같습니다: 검증하고, 범위를 정하고, 최소화하십시오. 단순히 최소 권한(least-privilege)뿐만 아니라 최소 컨텍스트(least-context)를 유지해야 합니다. 이것은 불신이 아닙니다. 클라우드 제공업체가 이미 디스크가 안전하다고 약속했음에도 불구하고 저장 데이터(data at rest)를 암호화하는 것과 같은 이유입니다. 규칙을 준수하고, 안전하게 행동하며, 심층 방어(defense in depth)를 실천하십시오.

체크리스트

AI가 여러분의 코드에 닿기 전에:

AI 도구 무시 파일(ignore file)을 추가하십시오. .env, 비밀 정보(secrets) 디렉토리, 키 자료(key material)가 자동 첨부되는 컨텍스트(context)에서 제외하십시오.
붙여넣기 직전의 모든 항목에 대해 비밀 정보 스캔(secret scan)을 실행하십시오.
자격 증명(credentials)과 개인정보(PII)는 실제 값이 아닌 플레이스홀더(placeholder)로 마스킹(masking)하십시오.
독점적인 작업(proprietary work)에는 학습 미사용 계약(no-training agreement)이 포함된 유료 티어를 사용하십시오. 규제 대상 데이터(regulated data)의 경우, 데이터가 절대 외부로 유출되지 않았음을 증명해야 하므로 로컬(local) 또는 셀프 호스팅(self-hosted) 방식을 사용하십시오.
실제 비밀 정보는 KMS 또는 키스토어(keystore)에 보관하여, 붙여넣기 위한 평문(plaintext)이 존재하지 않도록 하십시오.
AI의 출력(output)이 로그(logs), PR(Pull Request), 또는 커밋(commits)에 반영되기 전에 검토하십시오. 모델은 사용자가 입력한 내용을 그대로 되돌려줍니다.
프롬프트 채널(prompt channel)을 신뢰할 수 없는 송출(egress) 경로로 취급하십시오. 해당 경로를 통과하는 데이터는 기록(log)하고 최소화하십시오.

이러한 과정들은 습관이 되면 작업 속도를 늦추지 않습니다. 4초 만에 얻는 답변은 여전히 4초 만에 얻을 수 있습니다. 다만, 다시는 되돌릴 수 없는 비밀 정보를 대가로 지불하지 않게 될 뿐입니다.