보안, 프라이버시, 컴플라이언스

도입은 성능이 아니라 데이터 흐름에서 시작한다

기업과 공공 조직이 Claude를 도입할 때 가장 먼저 묻는 질문은 "얼마나 똑똑한가"가 아니다. "어떤 데이터가 어디로 가고, 어디에 남으며, 누가 볼 수 있는가"다. 이 질문에 답하지 못하면 파일럿은 빨리 시작할 수 있어도 운영 승인은 받기 어렵다.

Claude를 웹에서 쓰든, API로 제품에 붙이든, Claude Code로 개발 업무에 쓰든 기본 원칙은 같다. 입력 데이터, 첨부 파일, 도구 호출 결과, 로그, 평가 데이터, 감사 기록을 분리해서 봐야 한다. "Claude에 보냈다"는 한 문장으로는 부족하다. 어떤 기능을 통해 보냈는지, 어떤 계약 조건이 적용되는지, 조직 내부 로그에는 무엇이 남는지, 외부 도구에는 무엇이 전달되는지까지 확인해야 한다.

보안 검토의 목표는 모든 사용을 막는 것이 아니다. 사용 가능한 데이터와 금지해야 할 데이터를 나누고, 민감한 업무에는 더 강한 통제를 붙이는 것이다. 법무·보안·개인정보 담당자와 같은 언어로 말하려면 모델 이름보다 데이터 플로우 지도가 먼저 필요하다.

AI 생성 이미지

데이터 플로우 지도를 그리는 법

데이터 플로우 지도는 Claude 기능을 둘러싼 정보 이동 경로를 한 장에 표시한 문서다. 복잡한 시스템 도면이 아니어도 된다. 다음 여섯 가지를 빠뜨리지 않으면 된다.

실무에서는 데이터 흐름을 다음처럼 적는다.

사용자 질문
  → 애플리케이션 서버
  → 개인정보 마스킹/정책 검사
  → Claude API 요청
  → 도구 호출 필요 시 사내 검색 API 실행
  → 검색 결과를 Claude에 재전달
  → 최종 답변 생성
  → 응답 로그에는 request_id, 모델, 토큰, 오류만 저장
  → 원문 입력은 저장하지 않음 또는 별도 암호화 저장

이 지도에서 중요한 것은 "어디까지가 Anthropic 또는 클라우드 제공자의 처리 영역이고, 어디부터가 우리 조직의 책임인가"를 나누는 일이다. 예를 들어 API 요청 자체의 보존 정책은 벤더 조건을 확인해야 하지만, 애플리케이션 서버 로그, RAG 인덱스, 상담원 화면 캡처, 평가셋 저장소는 대부분 조직 내부 책임이다. 많은 사고는 모델이 아니라 주변 시스템에서 난다.

데이터 등급을 먼저 정한다

Claude에 넣을 수 있는 데이터 기준은 조직마다 다르다. 하지만 최소한 다음 등급은 구분해야 한다.

특히 비밀값은 예외 없이 금지해야 한다. Claude가 안전하게 처리한다고 해도, 비밀값이 프롬프트, 로그, 채팅 기록, 평가셋, 화면 공유 자료에 남는 순간 사고 범위가 넓어진다. 개발자는 "디버깅을 위해 잠깐"이라고 생각하기 쉽지만, API 키와 토큰은 모델 입력이 아니라 보안 저장소에서 관리해야 한다.

개인정보는 더 세밀하게 본다. 단순 이름과 이메일도 개인정보일 수 있다. 상담 내역처럼 여러 정보가 결합되면 개인을 식별할 가능성이 커진다. 법률, 의료, 금융, 공공 민원처럼 민감한 맥락이 붙으면 같은 데이터라도 위험도가 올라간다.

보존 정책과 ZDR을 기능별로 본다

보존 정책 검토에서 흔한 실수는 "Claude는 학습에 쓰지 않는다더라"에서 멈추는 것이다. 학습 사용 여부와 보존 여부는 다른 문제다. 모델 학습에 쓰지 않더라도, 남용 방지, 서비스 운영, 장애 분석, 법적 의무, 제품 기능을 위해 일정 기간 저장될 수 있다.

ZDR, 즉 Zero Data Retention은 요청·응답 콘텐츠를 지속적으로 저장하지 않는 구성을 뜻한다. 하지만 ZDR은 기본값이 아니라 계약과 계정 설정에 따라 적용되는 통제다. Anthropic의 개인정보 안내도 ZDR이 기본 보존 방식과 구분되는 별도 약정이며, 적용 범위가 적격 API와 상업용 조직 API 키를 사용하는 제품으로 제한될 수 있음을 설명한다.¹

따라서 기능별로 다음 표를 만든다.

이 표는 계약 검토 문서와 함께 관리해야 한다. 제품 문서는 바뀔 수 있고, 베타 기능은 일반 기능과 보존 조건이 다를 수 있다. 민감 데이터가 들어가는 업무는 "현재 문서 기준", "계정 설정 기준", "계약 기준", "내부 로그 기준"을 함께 확인한다.

Data residency는 만능 보장이 아니다

Data residency는 데이터를 특정 지역에 저장하거나 처리하도록 제한하는 통제다. 하지만 "AWS를 통해 쓴다" 또는 "특정 리전을 골랐다"는 말만으로 충분하지 않다.

Claude Platform on AWS의 설명은 이 점을 분명히 보여 준다. 이 통합은 AWS가 인증, IAM 접근 제어, 과금 연동을 제공하지만, 추론 스택은 Anthropic이 운영하는 구조다. 문서에는 데이터가 AWS 안에 머물지 않을 수 있고, 추론이 Anthropic의 기본 클라우드로 라우팅될 수 있으며, 요청별 inference_geo 파라미터로 특정 지리권에 추론을 고정할 수 있다고 설명되어 있다.²

이 말은 세 가지 검토를 요구한다.

첫째, 리전 선택과 추론 위치를 구분해야 한다. 과금이 AWS에서 이루어져도 실제 추론과 하위 서비스가 어디에서 처리되는지는 별도 확인이 필요하다.

둘째, 계약 주체와 처리자 역할을 확인해야 한다. Claude Platform on AWS에서는 AWS와 Anthropic이 독립적인 데이터 처리자로 설명된다.² 따라서 감사 문서에는 "AWS 사용"만 적지 말고, Anthropic 약관, DPA, 사용 정책, AWS 서비스 약관을 함께 적어야 한다.

셋째, 지역 고정이 필요한 업무는 설정 증적을 남겨야 한다. inference_geo 같은 파라미터를 사용한다면 코드 설정, 배포 버전, 테스트 요청, 운영 로그에 그 사실이 남아야 한다. 감사에서 중요한 것은 "할 수 있다"가 아니라 "그렇게 설정했고 계속 유지하고 있다"는 증거다.

Admin API와 Compliance API로 운영을 증명한다

컴플라이언스는 정책 문서만으로 되지 않는다. 누가 접근했고, 어떤 키를 썼고, 어느 워크스페이스에서 비용이 발생했으며, 어떤 설정이 바뀌었는지 확인할 수 있어야 한다.

Claude 운영에서 관리 API는 네 가지 목적으로 쓴다.

1. 사용자와 권한 관리: 조직 구성원, 역할, 워크스페이스 접근권을 주기적으로 점검한다. Claude Console은 User, Claude Code User, Limited Developer, Developer, Billing, Admin 같은 역할 기반 접근 체계를 제공한다.³

2. API 키 수명주기 관리: 키 생성자, 사용 제품, 마지막 사용 시점, 회전 주기, 폐기 기록을 관리한다.

3. 사용량·비용 관리: 모델, 워크스페이스, API 키, 시간대별 토큰 사용량과 비용을 확인해 예산 초과와 비정상 사용을 탐지한다. Anthropic의 Usage and Cost API는 조직 단위 사용량 리포트를 조회하는 흐름을 제공한다.⁴

4. 감사 추적: 관리자 변경, 프로젝트 설정, 파일 업로드, 사용자 활동 같은 이벤트를 보안 정보 이벤트 관리 시스템, 즉 SIEM으로 보낸다.

실무 구조는 다음과 같다.

Claude Console / Admin API / Compliance API
  → 일일 사용자·역할 스냅샷
  → API 키 인벤토리
  → 사용량·비용 리포트
  → 감사 이벤트 수집
  → SIEM·GRC 시스템 저장
  → 월간 접근권 검토와 분기별 위험 보고

권한은 최소 권한 원칙으로 설계한다. Admin 역할은 소수에게만 준다. Billing 권한과 개발 권한을 분리한다. 프로덕션 API 키는 개인 노트북이 아니라 비밀 관리 시스템에서 주입한다. 퇴사자와 부서 이동자는 IdP, Claude 조직, 워크스페이스, 코드 저장소 권한에서 동시에 제거되어야 한다.

국내 개인정보 규제와 연결하기

국내 조직은 Claude 도입을 개인정보 보호법의 언어로 번역해야 한다. 핵심은 다음 질문이다.

• 개인정보를 처리하는가?

• 처리 목적은 무엇인가?

• 어떤 항목을 수집·이용하는가?

• 보존 기간은 얼마인가?

• 외부 업체에 처리 업무를 맡기는가?

• 제3자 제공 또는 국외 이전이 발생하는가?

• 정보주체 권리 행사와 삭제 요청에 대응할 수 있는가?

• 안전성 확보 조치를 갖추었는가?

개인정보 보호법은 개인정보 처리 전반을 규율하며, 처리 목적, 보유 기간, 제3자 제공, 위탁, 파기, 안전성 확보 같은 요소를 조직이 설명할 수 있어야 한다.⁵ Claude 같은 생성형 AI 서비스를 쓰는 경우에는 여기에 "모델 입력으로 어떤 정보가 들어가는가", "출력에 개인정보가 새로 생성되거나 노출되는가", "프롬프트와 결과가 평가셋으로 재사용되는가"라는 질문이 추가된다.

생성형 AI 관련 개인정보보호위원회 안내의 취지도 실무적으로는 명확하다. AI 개발·이용 과정에서 데이터 단계, 모델 단계, 시스템 단계의 위험을 나누어 보고, 접근 통제, 입력·출력 필터링, 문서화, 책임자 관여, 지속 모니터링을 요구하는 방향으로 해석할 수 있다.⁶

위탁, 제3자 제공, 국외 이전 체크리스트

Claude 도입 검토 회의에서는 다음 표를 그대로 사용해도 좋다.

위탁과 제3자 제공은 반드시 구분해야 한다. 단순히 외부 업체가 데이터를 본다고 모두 제3자 제공은 아니다. 조직의 목적을 위해 처리 업무를 맡기는 구조라면 위탁 검토가 중심이 된다. 반대로 외부 사업자가 독립된 목적을 위해 데이터를 이용한다면 제3자 제공 문제가 생길 수 있다. 국외 이전은 저장 위치뿐 아니라 접근 가능성, 지원 인력, 하위처리자까지 포함해 봐야 한다.

운영 문서 패키지를 만든다

승인을 받는 조직은 "안전하게 쓰겠습니다"라고 말하지 않는다. 문서로 보여 준다. Claude 도입을 위한 기본 문서 패키지는 다음 여섯 가지다.

1. 데이터 플로우 지도: 입력, 저장, 처리, 도구, 로그, 평가 흐름.

2. 데이터 등급표: 입력 가능·제한·금지 데이터 기준.

3. 기능별 보존·ZDR 매트릭스: API, 파일, 캐시, 배치, 검색, 코드 실행별 조건.

4. 권한·키 관리표: 사용자 역할, 워크스페이스, API 키, 회전 주기.

5. 개인정보 검토 체크리스트: 목적, 항목, 위탁, 국외 이전, 파기, 권리 대응.

6. 사고 대응 플레이북: 잘못된 개인정보 입력, 프롬프트 인젝션, 데이터 유출 의심, 비용 급증 대응.

마지막으로 1쪽짜리 보안 검토 메모를 만들면 회의가 빨라진다.

Claude 도입 보안 검토 메모

1. 사용 목적:
2. 사용자 그룹:
3. 입력 데이터 등급:
4. 개인정보 포함 여부:
5. 사용 기능: API / 파일 / 검색 / 코드 실행 / 캐시 / 배치
6. 보존 정책 및 ZDR 적용 여부:
7. data residency 요구사항:
8. 외부 도구·하위처리자:
9. 로그 저장 항목:
10. 사람 검토가 필요한 고위험 출력:
11. 운영 책임자:
12. 승인 조건과 재검토 주기:

이 문서는 완벽한 법률 의견서가 아니다. 하지만 제품팀, 보안팀, 법무팀, 개인정보보호책임자가 같은 표를 보게 만든다. Claude 도입의 성패는 결국 여기에 달려 있다. 모델을 믿는 것이 아니라, 데이터 흐름을 알고, 보존을 통제하고, 권한을 제한하고, 감사를 남기는 조직만이 Claude를 오래 쓸 수 있다.

참고

¹Zero Data Retention 적용 범위에 대한 Anthropic Privacy Center 설명

²What is Claude Platform on AWS?

³Claude Console roles and permissions

⁴Usage and Cost API - Claude API Docs

⁵PERSONAL INFORMATION PROTECTION ACT - Korean Law Information Center

⁶South Korea Sets AI Standard: PIPC's Guidelines for Generative AI Present Obligations & Opportunity