프롬프트를 저장하지 않는 AI 보안

AI 보안 도구를 도입하는 조직이 흔히 놓치는 질문이 하나 있습니다. "우리 데이터를 지켜준다는 그 보안 도구는, 그 데이터를 어디에 어떻게 보관하고 있는가?" 프롬프트 유출을 막겠다며 도입한 도구가 그 프롬프트 원문을 자기 서버에 통째로 쌓아두고 있다면, 유출 지점을 하나 없앤 대신 새로운 유출 지점을 하나 만든 셈입니다.

이 백서는 타이거쉴드가 왜 프롬프트·파일 원문을 서버에 저장하지 않는 방식으로 설계됐는지, 그리고 원문 없이도 통제·감사가 실제로 성립하는 이유를 기술적으로 설명합니다.

01 · 왜 원문 수집형 보안이 새로운 위험이 되는가

생성형 AI 보안 도구 대부분은 프롬프트를 검사하기 위해 서버로 전송받는 구조를 택합니다. 검사 자체는 필요하지만, 여기서 두 가지 문제가 따라옵니다.

• 보안 도구가 곧 데이터 저장소가 된다 — 직원이 실수로 입력한 개인정보·API 키·소스코드가, 이번엔 보안 벤더의 서버에 원문 그대로 쌓입니다. 막으려던 유출의 형태가 바뀔 뿐입니다.
• 도입 저항의 근본 원인이 된다 — "회사가 내 프롬프트를 전부 들여다보고 저장한다"는 인식은 구성원의 신뢰를 깎고, 실제로는 우회 사용(개인 기기·개인 계정 전환)을 부추깁니다. 통제하려던 행위가 오히려 안 보이는 곳으로 숨습니다.

이 두 문제는 벤더의 선의로 해결되지 않습니다. 원문을 애초에 서버로 보내지 않는 아키텍처만이 구조적으로 해결합니다.

02 · 로컬 검사 아키텍처 — 원문은 기기를 떠나지 않는다

타이거쉴드의 탐지는 브라우저 확장과 데스크톱 에이전트 내부에서 이뤄집니다. 프롬프트 텍스트, 업로드 파일, MCP 설정 파일의 내용은 검사가 끝나는 즉시 그 자리에서 폐기되며, 네트워크로 전송되지 않습니다.

구체적으로 로컬에서 일어나는 일:

1. 정규식·엔트로피·키워드 탐지기가 입력 내용을 스캔합니다(주민등록번호 checksum, API key 패턴, 소스코드 시그니처 등).
2. 문맥 분류기가 탐지 결과의 오탐 가능성을 낮춥니다.
3. 정책 엔진이 조치를 결정합니다 — 경고, 마스킹, 차단, 또는 승인 요청.
4. 조치가 실행된 이후, 원문이 아니라 이 조치에 대한 메타데이터만 서버로 전송됩니다.

검사는 로컬에서 끝난다. 서버로 넘어가는 것은 "무엇을 했는가"의 기록뿐, "무엇을 봤는가"의 원본이 아니다.

이 원칙은 MCP 스캐너에도 동일하게 적용됩니다. Claude Desktop·Cursor·Claude Code의 로컬 설정 파일(예: claude_desktop_config.json)은 기기 안에서 파싱·위험 점수화되고, 서버로는 "어떤 서버가 어떤 위험도로 판정됐는가"만 전달됩니다. 설정 파일의 실제 경로·시크릿 값 원문은 전송되지 않습니다.

03 · 서버에 남기는 것: 이벤트 메타데이터의 구조

"원문을 저장하지 않는다"는 "아무것도 기록하지 않는다"는 뜻이 아닙니다. 감사·리포트·통계를 위해 구조화된 이벤트 메타데이터는 남깁니다. 타이거쉴드의 이벤트 스키마는 다음 필드만 허용하도록 설계 원칙(ADR)으로 못박혀 있습니다.

event {
  rule_id:    string   // 어떤 탐지 규칙이 걸렸는가 (예: KR_RRN, API_KEY_AWS)
  service:    string   // 어떤 AI 서비스에서 발생했는가 (ChatGPT, Claude, MCP 등)
  user_team:  string   // 누구/어느 팀에서 발생했는가
  action:     enum     // warn | mask | block | approve
  severity:   enum     // low | medium | high | critical
  count:      integer  // 동일 규칙 매칭 개수 (원문 아님)
  timestamp:  datetime
  content_hash: string?  // 선택적 — 04장 참고
}

여기에 원문성 필드(원문 텍스트, 스니펫, 매칭된 문자열 자체)는 스키마 설계 단계에서부터 배제되어 있습니다. 이는 사후 정책이 아니라, 새로운 기능을 추가할 때마다 검토하는 아키텍처 규칙입니다 — 즉 "실수로 원문이 저장되는" 경로 자체가 스키마 수준에서 차단됩니다.

04 · hash·fingerprint로 중복·재현을 다루는 법

메타데이터만으로 부족한 경우가 하나 있습니다. "이 이벤트가 나중에 다시 발생한 그 이벤트와 같은 것인가"를 확인해야 할 때입니다. 이를 위해 선택적으로 원문의 단방향 해시(SHA-256 등)를 저장할 수 있습니다.

• 해시는 원문을 복원할 수 없는 값입니다 — 원문 → 해시는 계산 가능하지만 해시 → 원문은 불가능합니다.
• 동일 원문은 항상 동일 해시를 만들기 때문에, "같은 유출이 반복되는가"·"이전에 조치한 그 사건이 맞는가"를 원문 없이 대조할 수 있습니다.
• 해시 저장 여부는 조직의 정책으로 켜고 끌 수 있습니다 — 기본값은 저장하지 않음이며, 감사 요건상 필요한 조직만 옵트인합니다.

즉 hash는 "원문의 축소 저장"이 아니라 "원문 없이 동일성만 확인하는 지문"입니다. 이 구분이 백서 전체에서 가장 중요한 기술적 포인트입니다.

05 · 원문 없이 성립하는 감사 증적의 논리

"감사·심사 대응을 위해서는 원문을 보관해야 하지 않나?"라는 질문에 대한 답은 명확합니다 — 아닙니다. 심사가 실제로 확인하는 것은 아래 네 가지이며, 그 어느 것도 원문을 요구하지 않습니다.

1. 정책의 존재 — 어떤 데이터 유형을 어떤 AI 서비스에 입력하면 안 되는지 문서화되어 있는가.
2. 정책의 작동 — 실제로 위반 시도가 있었을 때 경고·마스킹·차단이 발동했는가. (rule_id + action + timestamp로 증명)
3. 조치의 이력 — 위반 발생 시 무엇을 했는가. (action + severity 추이로 증명)
4. 운영의 지속성 — 통제가 일회성이 아니라 상시 작동하는가. (기간별 count 집계로 증명)

이 네 가지는 "이벤트 유형·조치·시간"의 조합만으로 완전히 증명됩니다. 원문을 요구하는 것은 오히려 심사의 본질(통제가 작동하는가)을 벗어나, 불필요하게 새로운 개인정보 저장소를 만드는 결과를 낳습니다.

06 · ISMS-P 관련 통제 항목과의 매핑

ISMS-P 인증 기준의 정보보호·개인정보 관리체계 관점에서, 생성형 AI 이용 통제는 크게 접근통제·데이터 보호·사고 대응·최소 수집의 기존 원칙 안에서 다뤄집니다. 타이거쉴드의 메타데이터 기반 설계는 이 원칙들과 다음과 같이 정렬됩니다.

• 통제 정책 문서화 ↔ AI 사용 정책(허용/금지 서비스, 금지 데이터 유형)을 관리자 대시보드에서 관리·이력화.
• 접근·이용 기록 ↔ 이벤트 메타데이터(누가·언제·무엇을·어떤 조치)가 곧 접근 기록에 해당.
• 최소 수집 원칙 ↔ 원문 미저장 설계 자체가 최소 수집을 아키텍처로 강제.
• 사고 대응·복구 ↔ 위반 탐지 시 조치 이력과 재발 방지 기록.

다만 명확히 해둘 것이 있습니다 — 이 매핑은 통제 설계의 정렬 관계를 설명한 것이며, 타이거쉴드 자체의 ISMS-P 인증 취득을 의미하지 않습니다. 자체 인증(SOC2·ISMS-P)은 로드맵 항목이며, 인증 여부와 무관하게 고객사가 자사 심사에서 이 설계를 증적 논리로 활용할 수 있다는 뜻입니다.

07 · 개인정보보호법 관점의 데이터 최소 수집

개인정보보호위원회의 생성형 AI 개인정보 처리 안내서(2025-08)는 생성형 AI를 활용·이용하는 기업에도 개인정보 처리 원칙(목적 제한, 최소 수집, 안전조치)이 그대로 적용된다는 점을 분명히 합니다. 보안 도구가 이 원칙에서 예외일 수는 없습니다.

• 목적 제한: 수집하는 메타데이터는 오직 "탐지·정책 집행·감사"라는 목적에 필요한 필드로 한정됩니다.
• 최소 수집: 원문성 필드를 스키마에서 배제함으로써, 애초에 과다 수집이 불가능한 구조를 택합니다.
• 안전조치: 선택적 hash는 단방향 함수로 원문 복원이 불가능해 그 자체로 개인정보가 아닙니다.

결과적으로 타이거쉴드를 도입하는 조직은, 도구 자체가 새로운 개인정보 처리 리스크를 만들지 않는다는 것을 설계 수준에서 설명할 수 있습니다.