LLM에서 개인정보를 어떻게 필터링할까 — 입력부터 RAG·출력·로그까지 4단계 설계

대규모 언어 모델(LLM)을 업무에 연결하면 개인정보가 들어오는 경로도 함께 늘어납니다. 사용자가 프롬프트에 직접 입력할 수 있고, 학습 데이터나 RAG 문서에 이미 포함되어 있을 수도 있습니다. 모델이 검색 결과를 조합하는 과정에서 원래 질문과 무관한 개인정보를 답변에 섞거나, 운영 로그가 새로운 개인정보 저장소가 되는 문제도 생깁니다.

 

이 문제는 모델 앞에 정규식 필터 하나를 붙인다고 해결되지 않습니다. 개인정보는 데이터 수집부터 입력, 검색 컨텍스트, 출력, 로그까지 이동하기 때문입니다. 반대로 모든 문장을 무조건 차단하면 서비스가 쓸 수 없을 정도로 오탐이 늘어납니다.

 

현실적인 목표는 ‘완벽한 탐지’를 약속하는 것이 아니라, 고위험 정보는 놓치지 않도록 여러 탐지 방식을 겹치고, 업무 목적과 권한에 따라 차단·마스킹·가명화·허용을 일관되게 결정하는 것입니다.

먼저 개인정보의 흐름부터 그려야 한다

LLM 서비스에서 개인정보가 이동하는 대표 경로는 다음과 같습니다.

원본 문서·업무 데이터
        ↓
수집·전처리 → RAG 인덱스
        ↓           ↓
사용자 입력 → 검색·컨텍스트 구성 → LLM
                                  ↓
                              모델 출력
                                  ↓
                           사용자·외부 도구

각 구간의 요청·결과·정책 판단 → 감사 로그

여기서 중요한 점은 모델 자체가 개인정보 접근 권한을 판단하게 해서는 안 된다는 것입니다. “개인정보를 말하지 마라”라는 시스템 프롬프트는 보조 지시일 뿐 보안 경계가 아닙니다. OWASP도 민감정보가 학습 데이터나 사용자 상호작용을 통해 노출될 수 있으며, 시스템 프롬프트만으로는 우회를 막기 어렵다고 설명합니다.

 

따라서 개인정보 통제는 모델 바깥에서 강제해야 합니다.

4단계 구조를 한눈에 보면

단계	보호 대상	핵심 통제	대표 결과
1. 수집·전처리	학습 데이터, 문서, RAG 원본	정규식·체크섬, NER, 문맥 탐지, 표본 검수	제거, 마스킹, 가명화, 격리
2. 사용자 입력	프롬프트, 첨부 파일, 대화 이력	정규화, 실시간 PII 탐지, 목적별 정책	차단, 마스킹, 토큰화, 경고
3. RAG·도구·컨텍스트	검색 문서, 비밀정보, 외부 도구	검색 전 권한 검사, 최소 컨텍스트, 비밀 중개	허가된 정보만 모델에 전달
4. 출력·감사	모델 응답, 실행 인자, 운영 로그	출력 재검사, 구조 검증, 안전한 로깅	유출 차단, 추적·경보

각 단계는 서로를 대체하지 않습니다. 전처리에서 개인정보를 놓쳤더라도 입력 또는 출력 단계에서 다시 잡을 수 있어야 하고, 필터가 실패하더라도 RAG 권한 통제가 다른 사용자의 문서를 검색하지 못하게 해야 합니다.

1단계: 데이터 수집과 전처리에서 줄인다

학습 데이터나 RAG 지식베이스를 만들 때부터 개인정보의 양을 줄이는 것이 가장 비용 효율적입니다. 이미 벡터화된 뒤에는 원문뿐 아니라 청크, 임베딩, 메타데이터, 캐시와 백업까지 함께 정리해야 하기 때문입니다.

첫 번째 탐지: 규칙과 체크섬

주민등록번호, 전화번호, 이메일, 카드번호처럼 형식이 비교적 분명한 값은 정규표현식으로 빠르게 후보를 찾을 수 있습니다. 다만 숫자 모양만 맞는다고 실제 식별번호인 것은 아니므로 가능한 경우 체크섬, 날짜 유효성, 접두 구간과 같은 검증을 함께 적용해야 오탐을 줄일 수 있습니다.

 

정규식만으로는 다음과 같은 표현을 놓치기 쉽습니다.

공일공-일이삼사-오육칠팔
홍 길 동의 메일은 hong (at) example (dot) com
매주 화요일 ○○병원 희귀질환 센터에 방문하는 팀장

따라서 공백·유니코드·구분자·알려진 인코딩을 먼저 정규화하고, 정규식 결과를 최종 판정이 아니라 탐지 신호 중 하나로 취급해야 합니다.

두 번째 탐지: NER와 문맥

인명, 위치, 조직, 의료 정보처럼 문맥에 따라 의미가 달라지는 정보는 개체명 인식(NER)과 주변 단어를 함께 분석합니다. Microsoft Presidio의 Analyzer도 정규식, 목록, 체크섬, 규칙, NER와 문맥을 조합하며, spaCy·Transformers·Stanza 등의 NLP 엔진이나 사용자 정의 인식기를 연결할 수 있습니다.

 

한국어 환경에서는 기본 영문 모델을 그대로 도입하기보다 한국어 NER 모델과 업무별 사전을 검증해야 합니다. 사번, 고객번호, 프로젝트 코드, 지점명처럼 조직 내부에서만 식별력이 있는 값은 범용 도구가 알 수 없으므로 사용자 정의 인식기가 필요합니다.

세 번째 탐지: 의미 기반 모델은 보조 수단으로

“매주 같은 병원에서 특정 치료를 받는 유일한 임원”처럼 여러 단서를 조합해야 식별 위험이 드러나는 문장은 의미 기반 분류기나 LLM을 보조 탐지기로 사용할 수 있습니다. 하지만 LLM-as-a-Judge 하나에 차단 결정을 맡기면 출력이 비결정적이고 프롬프트 우회에 영향을 받을 수 있습니다.

 

또한 외부 LLM에 원문을 보내 개인정보를 탐지하는 순간, 탐지 전에 개인정보를 외부로 전송하는 모순이 생길 수 있습니다. 의미 기반 탐지가 필요하다면 내부 모델이나 승인된 처리 환경을 사용하고, 결과는 PERSON, MEDICAL_CONTEXT, HIGH_RISK 같은 구조화된 레이블로 제한하는 편이 안전합니다.

네 번째 검증: 사람이 표본을 본다

자동 필터의 정확도는 문서 유형과 언어에 따라 달라집니다. 배포 전에는 개인정보가 있는 표본과 없는 표본을 함께 만들어 재현율과 정밀도를 측정하고, 운영 중에도 권한을 가진 검수자가 최소한의 표본을 확인해야 합니다. 검수 화면 역시 원문 전체를 무조건 노출하지 않고 필요한 주변 문맥만 보여주는 것이 좋습니다.

탐지보다 중요한 것은 ‘어떻게 처리할지’다

개인정보를 발견한 뒤의 조치는 사용 목적에 따라 달라집니다.

처리 방식	예시	적합한 상황	주의점
차단·제거	요청 자체를 거부	비밀번호, API 키, 주민등록번호 등 고위험 값	사용자에게 안전한 재입력 방법 안내
마스킹	010-****-5678	화면 표시나 상담 맥락에 일부 정보가 필요할 때	남은 조각의 재식별 가능성 점검
범주화	정확한 나이 → 40대	통계·분석에 정밀값이 불필요할 때	너무 세밀한 범주는 식별력을 유지
가명화·토큰화	이름 → PERSON_7F2A	같은 대화·업무 내 연결성이 필요할 때	대응표는 모델 밖의 별도 금고에 보관
허용	권한 있는 상담원의 고객 조회	법적 근거와 업무 목적이 명확할 때	최소 범위, 만료 시간, 감사 기록 적용

Microsoft Presidio Anonymizer는 replace, redact, hash, mask, encrypt 같은 연산자를 제공합니다. 하지만 도구가 제공하는 기능과 조직이 선택해야 하는 정책은 별개입니다. 예를 들어 단방향 해시는 후보 값의 범위가 좁으면 재식별될 수 있고, 가명화는 대응표가 남아 있으므로 익명화와 같지 않습니다.

전화번호 뒷자리만 남기면 안전할까?

010-****-5678처럼 일부만 가렸다고 해서 자동으로 익명 정보가 되는 것은 아닙니다. 같은 대화에 소속, 직책, 지역, 방문 일시나 사건 정황이 함께 있으면 남은 네 자리와 결합해 특정인을 추정할 수 있습니다.

“경기 남부 지점의 유일한 보안팀장”
+ “지난 화요일 ○○병원 방문”
+ “전화번호 끝 네 자리 5678”
= 결합했을 때 높아지는 재식별 가능성

따라서 마스킹 범위는 고정된 모양이 아니라 사용 화면과 업무 목적, 함께 노출되는 정보, 접근자의 범위에 따라 정해야 합니다.

• 단순 통계나 LLM 분석에는 [연락처]로 전체 치환하거나 삭제합니다.
• 같은 대화에서 대상을 연결해야 한다면 PHONE_8F92 같은 무작위 토큰을 사용합니다.
• 상담원이 본인 확인 뒤 연락처를 확인해야 한다면 화면에는 필요한 범위만 표시하고, 전체 번호 조회는 별도 승인 절차로 분리합니다.
• 로그와 분석 데이터에는 끝 네 자리도 가능하면 남기지 않습니다.

가장 안전한 개인정보는 필터가 잘 가린 정보가 아니라 애초에 수집하거나 모델에 전달하지 않은 정보입니다. 사후 마스킹을 준비하더라도 입력 화면에서 주민등록번호, 인증정보처럼 불필요한 값의 입력을 먼저 막아야 합니다.

2단계: 사용자 입력은 모델 호출 전에 통제한다

운영 환경에서는 모든 프롬프트와 첨부 파일이 비신뢰 입력입니다. 처리 순서는 다음처럼 구성할 수 있습니다.

요청 인증
→ 텍스트·인코딩 정규화
→ 규칙·체크섬 탐지
→ NER·문맥 탐지
→ 테넌트·업무 목적별 정책 결정
→ 차단 또는 가명화
→ 승인된 모델 호출

OpenAI Guardrails의 Contains PII 체크는 Microsoft Presidio를 이용해 입력 개인정보를 마스킹하거나 차단할 수 있고, 출력 단계에서는 차단 정책을 적용할 수 있습니다. AWS Bedrock Guardrails도 입력과 모델 응답의 PII를 탐지해 차단하거나 마스킹하는 기능을 제공합니다. 이런 관리형 기능은 유용하지만 조직의 한국어 데이터와 식별자에 맞춘 검증 없이 ‘설정했으니 끝’이라고 판단해서는 안 됩니다.

 

입력 길이 제한, 파일 크기 제한, 요청 빈도 제한도 필요합니다. 이는 비용 폭증과 자원 고갈, 대량 추출 시도를 줄이는 통제이지 개인정보 탐지나 프롬프트 인젝션을 해결하는 필터는 아닙니다.

 

사용자 경험도 중요합니다. 무조건 오류를 내기보다 다음처럼 구체적인 안전 행동을 알려주는 것이 좋습니다.

주민등록번호로 보이는 값이 포함되어 요청을 전송하지 않았습니다.
해당 값을 삭제하거나 고객 참조번호로 바꾼 뒤 다시 시도해 주세요.

3단계: RAG는 검색하기 전에 권한을 검사한다

RAG에서 흔한 실수는 전체 문서를 검색한 다음 모델에게 “권한 없는 내용은 답하지 마라”고 지시하는 것입니다. 이미 검색된 청크가 컨텍스트에 들어간 뒤에는 프롬프트 인젝션이나 모델 오류로 노출될 가능성이 생깁니다.

 

권한 검사는 검색 전에 이루어져야 합니다.

사용자 인증 정보
→ 테넌트·역할·문서 ACL 확인
→ 허용 범위로 검색 후보 제한
→ 관련 청크 검색
→ 필요한 최소 청크만 컨텍스트에 포함

일반 업무에서는 문서·행 단위 ACL, 테넌트 키, 보안 등급 메타데이터와 검색 필터를 이용한 ‘security trimming’을 적용할 수 있습니다. 규제 경계가 강하거나 서로 다른 고객의 데이터가 절대 섞여서는 안 되는 환경이라면 인덱스, 데이터베이스, 계정 또는 VPC를 물리적으로 분리하는 방식을 추가합니다. 모든 사용자 그룹마다 벡터 DB를 복제하는 것이 유일한 정답은 아닙니다.

 

API 키, 데이터베이스 비밀번호, OAuth 토큰은 프롬프트나 RAG 문서에 넣지 않습니다. 비밀 값은 Secrets Manager나 Vault 같은 비밀 저장소가 보관하고, 도구 브로커가 실행 시점에만 참조해야 합니다. KMS 또는 HSM은 주로 이 데이터와 저장소를 암호화하는 키를 관리합니다.

 

모델에는 비밀 자체 대신 권한이 제한된 도구 인터페이스를 제공합니다.

나쁜 예: 프롬프트에 운영 DB 비밀번호 삽입

좋은 예: LLM이 `lookup_customer(reference_id)` 요청
       → 도구 브로커가 사용자 권한과 인자를 검사
       → 비밀 저장소에서 자격증명을 일시 참조
       → 필요한 필드만 반환

나중에 원문을 다시 보여줘야 한다면

단순 마스킹은 표시 형식을 가리는 작업이며, 원본을 복원하는 기능은 아닙니다. 나중에 권한 있는 사용자에게 원문을 다시 보여줘야 한다면 가역적 토큰화 또는 암호화된 별도 원본 저장소를 설계해야 합니다. 이때 복원 로직을 LLM이나 프롬프트에 맡기면 안 됩니다.

 

안전한 흐름은 다음과 같습니다.

1. 원본 전화번호 수집
2. 무작위 토큰 발급: PHONE_8F92
3. LLM·대화 DB에는 토큰만 저장
4. 원본↔토큰 매핑은 별도 보안 저장소에 암호화
5. 사용자가 원문 조회 요청
6. 애플리케이션이 세션·소유권·권한·재인증 확인
7. 미들웨어가 필요한 순간에만 복원
8. LLM을 거치지 않고 승인된 UI에 직접 렌더링
9. 조회 사실을 원문 없이 감사 로그에 기록

구성 요소별 책임도 분명해야 합니다.

구성 요소	맡아야 할 역할	가져서는 안 되는 권한
LLM	“연락처 확인 요청”이라는 의도 파악	원본 매핑 DB·복호화 키 접근
애플리케이션	세션, 소유권, 업무 목적, 정책 검사	무제한 원본 대량 조회
토큰 금고	토큰과 원본의 안전한 매핑	사용자와 직접 상호작용
KMS·HSM	저장소 암호화 키의 생성·사용 통제	개인정보를 프롬프트에 전달
승인된 UI	확인된 사용자에게 최소 시간 표시	응답 캐시·분석 로그에 원문 저장
감사 시스템	조회자·시각·사유·정책 결과 기록	복원된 개인정보 원문 기록

재식별 요청은 일반 조회보다 강한 통제를 적용합니다. 로그인 세션만 믿지 말고 위험도에 따라 MFA나 최근 재인증을 요구하고, RBAC뿐 아니라 데이터 소유권과 업무 목적도 확인합니다. 복원 API에는 짧은 만료 시간, 1회성 권한, 호출 빈도 제한과 대량 조회 차단을 적용합니다.

 

저장소는 승인된 암호 알고리즘으로 암호화하고 키는 KMS 또는 HSM에서 통제합니다. “AES-256을 사용했다”는 사실만으로 안전한 것은 아닙니다. 애플리케이션 역할이 모든 키와 데이터를 자유롭게 복호화할 수 있다면 분리 효과가 사라지므로, 키 사용 정책과 서비스 역할을 함께 제한해야 합니다.

 

감사 로그에는 사용자 ID, 세션 또는 요청 ID, 조회 시각, 가명화된 대상 식별자, 조회 사유, 허용·거부 결과와 정책 버전을 기록합니다. 복원된 전화번호 자체나 복호화 키는 기록하지 않습니다. 이 이벤트를 SIEM으로 보내 평소와 다른 시간대의 조회, 짧은 시간의 반복 조회, 다수 고객 조회를 경보로 연결할 수 있습니다.

4단계: 출력과 로그를 마지막 방어선으로 둔다

모델의 원시 출력은 사용자나 외부 시스템에 전달하기 전에 다시 검사해야 합니다. 입력에서 발견되지 않은 정보가 RAG 문서나 모델 기억에서 생성될 수 있기 때문입니다.

 

출력 단계에서는 개인정보 유형, 요청자의 권한, 응답 목적을 함께 판단해 다음 중 하나를 선택합니다.

안전함        → 전달
일부 노출 가능 → 마스킹 후 전달
고위험 정보    → 전체 차단 및 안전한 대체 문구
판단 불확실    → 사람의 승인 대기

코드, SQL, HTML, 도구 호출 인자는 개인정보 필터와 별개로 스키마 검증, 허용 목록, 이스케이프와 샌드박스가 필요합니다. 개인정보를 지웠다고 해서 명령 실행도 안전해지는 것은 아닙니다.

 

감사 로그에는 원문 대신 다음 정보를 남기는 편이 좋습니다.

{
  "request_id": "req_7f2a",
  "actor_id": "pseudonymous-user-42",
  "detected_types": ["PHONE_NUMBER", "PERSON"],
  "detected_count": 2,
  "action": "MASK",
  "policy_version": "pii-policy-2026-07",
  "model_route": "internal-model",
  "timestamp": "2026-07-30T10:15:00+09:00"
}

여기에는 탐지된 전화번호나 이름의 원문을 기록하지 않습니다. 사고 조사 때문에 제한적인 원문 보관이 반드시 필요하다면 별도의 암호화 저장소, 엄격한 접근 통제, 짧은 보존 기간과 열람 감사를 적용해야 합니다.

 

관리형 가드레일을 사용할 때도 로그 설정을 별도로 확인해야 합니다. AWS 문서는 Guardrails의 마스킹이 모델 호출 로그에 자동 적용되지 않아 원본 요청이 CloudWatch Logs나 S3에 저장될 수 있고, 추적 정보에도 탐지된 원문이 포함될 수 있다고 경고합니다. 즉, 화면에서 마스킹된 것과 로그에서 제거된 것은 같은 일이 아닙니다.

실무 정책은 데이터 유형별로 달라야 한다

데이터 유형	기본 정책	예외 조건
비밀번호·API 키·세션 토큰	즉시 차단, 보안 경보	없음
주민등록번호·여권번호·계좌·카드	외부 모델 전송 차단, 내부에서도 최소화	명시적 법적 근거와 승인된 전용 업무
전화번호·이메일·주소	마스킹 또는 토큰화	본인 확인이 끝난 상담 등 목적이 명확한 경우
이름·직책·기관	문맥과 결합 위험 평가	공개된 업무 정보이고 목적에 필요한 경우
의료·생체·위치·행동 정보	고위험으로 분류, 내부 처리 우선	강화된 동의·권한·감사 체계
사번·고객번호·프로젝트 코드	조직별 인식기와 정책 적용	승인된 내부 업무

같은 이름이라도 공개된 보도자료의 대표자 이름과 비공개 상담 기록의 환자 이름은 위험이 다릅니다. 단순히 ‘PII인가 아닌가’만 판정하지 말고 데이터 민감도, 사용 목적, 요청자 권한, 전송 대상과 보존 기간을 함께 정책 엔진에 넣어야 합니다.

운영 전 반드시 측정할 지표

개인정보 필터는 설치 여부가 아니라 성능과 실패 방식으로 평가해야 합니다.

• 고위험 재현율: 실제 주민등록번호·계정 비밀 등을 얼마나 놓치지 않는가
• 정밀도: 정상 업무 문장을 얼마나 잘못 차단하지 않는가
• 언어·표현별 성능: 한국어, 영문, 띄어쓰기 변형, 유니코드, 이미지 OCR에서 성능이 유지되는가
• 우회 내성: 분할 입력, 인코딩, 역할극, 간접 프롬프트 인젝션에도 정책이 유지되는가
• 처리 지연: 입력과 출력 검사가 서비스 지연에 미치는 영향
• 정책 결과: 차단·마스킹·허용 비율과 사용자 재시도율
• 잔여 유출률: 레드팀 데이터셋에서 최종 응답이나 로그로 남은 개인정보 비율

운영 중 탐지 규칙이나 모델을 바꾸면 동일한 회귀 테스트 세트로 다시 측정해야 합니다. 탐지 모델의 버전과 정책 버전을 감사 로그에 남기는 이유도 여기에 있습니다.

도입 순서는 작게 시작하는 편이 안전하다

1. 데이터 흐름과 저장 위치를 먼저 목록화합니다.
2. 비밀번호·토큰·고유식별번호처럼 고위험 항목부터 차단합니다.
3. 한국어 문서와 조직 고유 식별자로 평가 데이터셋을 만듭니다.
4. 수집, 입력, RAG, 출력, 로그에 같은 정책 ID를 연결합니다.
5. 차단이 업무에 미치는 영향을 측정하며 마스킹·가명화 예외를 설계합니다.
6. 레드팀과 회귀 테스트를 정기적으로 수행합니다.
7. 보존 기간이 끝난 원문, 캐시, 인덱스와 백업의 삭제 절차를 검증합니다.

국내 지침을 적용할 때 확인할 점

국내 공식 자료도 일관되게 생애주기 전체의 위험 관리와 데이터 최소화를 강조합니다. 개인정보보호위원회의 2025년 「생성형 인공지능(AI) 개발·활용을 위한 개인정보 처리 안내서」는 목적 설정부터 데이터 전처리, 접근권한 통제, 입출력 필터링, 배포 전 테스트와 지속적 관리까지 단계별 고려사항을 제시합니다. 2026년 이용자 가이드는 업무자료와 제3자 정보를 입력하기 전에 확인하고, 대화 저장·학습 활용과 외부 서비스 권한을 점검하도록 안내합니다.

 

개인정보위의 AI 프라이버시 리스크 관리 모델은 AI의 유형과 용례를 파악하고, 위험의 발생 가능성과 중대성을 측정한 뒤 위험에 비례하는 조치를 선택하는 접근을 설명합니다. 안내서의 모든 예시 조치가 모든 서비스에 똑같이 의무 적용된다는 뜻은 아닙니다. 실제 법적 의무와 보존 기간, 국외 이전, 가명정보 처리 여부는 조직의 처리 목적과 적용 법령을 기준으로 별도 검토해야 합니다.

 

기술 보안 측면에서는 KISA의 「인공지능(AI) 보안 안내서」와 「AI 보안 위협 대응 매뉴얼」, 국가정보원의 「국가·공공기관 AI보안 가이드북」을 함께 참고할 수 있습니다. 공공기관이나 기밀·민감 데이터를 다루는 환경은 일반 소비자 서비스보다 강한 승인, 망 분리와 데이터 등급 통제가 필요할 수 있습니다.

결론

LLM 개인정보 보호는 특정 제품 하나를 설치하는 작업이 아닙니다. 데이터 수집 단계에서 개인정보를 줄이고, 모델 호출 전에 입력을 통제하며, RAG가 권한 밖의 문서를 검색하지 못하게 하고, 최종 출력과 로그를 다시 검사하는 연속된 체계입니다.

 

정규식은 빠르지만 문맥을 놓치고, NER은 유연하지만 오탐과 미탐이 있으며, 의미 기반 모델은 복잡한 단서를 이해할 수 있지만 그 자체가 새로운 처리 위험이 될 수 있습니다. 그래서 여러 탐지 신호를 조합하되, 최종 행동은 모델이 아니라 외부 정책 엔진과 권한 시스템이 결정해야 합니다.

 

핵심 원칙은 간단합니다.

모델에 전달할 필요가 없는 개인정보는 먼저 제거하고, 필요한 정보도 최소한으로 가명화하며, 검색과 도구 실행은 사용자 권한으로 제한하고, 출력과 로그까지 다시 확인한다.

이 원칙을 4단계 전체에 일관되게 적용해야 개인정보 필터가 단순한 문자열 치환 기능이 아니라 실제 보안 통제로 작동합니다.

참고 자료

• OWASP GenAI Security Project — LLM02:2025 Sensitive Information Disclosure
• Microsoft Presidio — Text anonymization
• Microsoft Presidio — Anonymizer
• OpenAI Guardrails — Contains PII
• AWS Bedrock Guardrails — Sensitive information filters
• 개인정보보호위원회 — 생성형 AI 서비스 이용자를 위한 개인정보 보호 가이드
• 개인정보보호위원회 — 생성형 인공지능(AI) 개발·활용을 위한 개인정보 처리 안내서
• 개인정보보호위원회 — 안전한 인공지능(AI)·데이터 활용을 위한 AI 프라이버시 리스크 관리 모델
• KISA — 인공지능(AI) 보안 안내서
• KISA — AI 보안 위협 대응 매뉴얼
• 국가정보원 — 국가·공공기관 AI보안 가이드북