“이 문서를 ChatGPT나 Claude에 넣어도 될까요?” 회사에서 AI를 쓰기 시작하면 거의 반드시 나오는 질문입니다. 그런데 이 질문에 “안전하다” 또는 “절대 안 된다”라고 한 단어로 답하면 오히려 위험합니다.
같은 서비스라도 개인 계정인지 업무용 계정인지, 웹 채팅인지 API인지, 어떤 보존 정책과 관리 기능이 적용되는지에 따라 판단이 달라지기 때문입니다. 더구나 문서를 AI에 넣는 순간 문제는 모델 성능만이 아니라 계정 권한, 외부 연동, 로그, 내부 규정으로 확장됩니다.
실무에서 쓸 만한 질문은 따로 있습니다. 민감한 데이터를 넣기 전에 “이 AI가 안전한가?”보다 “이 데이터가 어떤 계정과 경로를 거쳐 어디까지 이동하고, 누가 지울 수 있는가?”를 확인해야 합니다.
- 분류문서가 공개·내부·기밀·제한 중 어디에 속하는지 정합니다.
- 계정개인용인지 업무용인지와 관리자 통제를 확인합니다.
- 경로웹·API·외부 연동을 거치는 데이터 흐름을 그립니다.
- 승인조직 정책에 따라 입력과 보존 조건을 승인받습니다.
학습 제외 설정과 대화 삭제는 같은 조치가 아닙니다. 입력 전에 이 차이가 헷갈린다면 AI 대화 저장·메모리·학습의 구분부터 확인하고, 실제 계정의 설정과 보관 조건을 대조해 보세요.
먼저 확인할 사실: 서비스 이름보다 계정과 플랜이 중요하다
OpenAI의 ChatGPT 데이터 사용 안내는 개인용 서비스에서 데이터 제어 설정으로 모델 학습 사용을 끌 수 있다고 설명합니다. OpenAI 비즈니스 데이터 안내는 Business·Enterprise·Edu·API의 입력과 출력을 기본적으로 모델 학습에 사용하지 않는다고 밝힙니다. 실제 적용 범위와 보존 기간은 제품과 계약 조건을 다시 확인해야 합니다.
Anthropic의 소비자 데이터 안내도 Claude Free·Pro·Max와 Claude for Work·API의 데이터 처리 조건을 구분합니다. 따라서 회사에서 개인 계정으로 유료 플랜을 결제했다고 해서 곧바로 기업용 보안 통제가 생기는 것은 아닙니다. “유료”와 “조직 관리 가능”은 같은 말이 아닙니다.
정책과 제품 설정은 바뀔 수 있으므로 실제 도입 전에는 회사가 선택한 플랜의 약관·개인정보 처리방침·관리자 문서를 다시 확인해야 합니다.
회사 자료를 네 단계로 나누면 판단이 쉬워진다
| 구분 | 역할 | 설명 | 예시 |
|---|---|---|---|
| 공개 | 이미 공개된 자료 | 보도자료와 공개 문서처럼 일반 AI 사용을 검토할 수 있는 자료입니다. | 출처와 저작권은 별도 확인 |
| 내부 | 공개 전 초안과 업무 메모 | 외부 공개 전 자료이므로 승인된 계정과 도구에서만 사용합니다. | 조직 승인과 접근 통제 |
| 기밀 | 계약서와 소스코드 | 조직 정책, 플랜, 보존, 접근 통제를 확인한 뒤 제한적으로 사용합니다. | 입력 범위와 보존 기간 |
| 제한 | 식별자와 인증 정보 | 주민등록번호, 결제정보, 인증키, 의료·인사 정보는 원칙적으로 입력하지 않습니다. | 필요 시 별도 승인과 비식별화 |
여기서 “기밀”과 “제한”의 구체적인 기준은 회사의 보안 정책을 따라야 합니다. 표의 목적은 모든 자료를 AI에 넣을지 말지를 대신 결정하는 것이 아니라, 문서마다 다른 절차를 만들자는 데 있습니다.
데이터가 이동하는 경로를 그려 보자
문서 보안은 입력창에서 끝나지 않습니다. ChatGPT Work 클라우드 보안 문서도 연결 계정, 브라우저·네트워크 통제, 데이터 보존, 감사 가시성을 별도 점검 대상으로 다룹니다. 다음 경로를 하나씩 확인해 보세요.
사용자 계정 → AI 서비스 → 모델 처리·보존 → 대화 기록·관리자 로그
↘ 파일 업로드·커넥터·MCP → 외부 저장소·업무 시스템
특히 커넥터와 MCP를 연결하면 AI가 읽는 데이터의 범위가 넓어질 수 있습니다. GitHub, Google Drive, Slack 같은 시스템에 연결된 경우 질문 한 번이 어떤 파일과 메시지를 검색하는지, 쓰기 권한까지 있는지 확인해야 합니다. 이 주제는 MCP 연결과 보안 가이드에서 따로 다룹니다.
확인할 질문은 다음과 같습니다.
- 회사가 승인한 계정인가, 개인 계정인가
- 입력과 출력이 모델 학습에 사용되는가
- 대화와 업로드 파일의 보존 기간은 얼마인가
- 관리자가 사용자를 추가·삭제하고 로그를 확인할 수 있는가
- 외부 연동이 읽기 전용인가, 쓰기·삭제까지 가능한가
- 계정 탈퇴나 프로젝트 종료 후 데이터를 어떻게 삭제하는가
- API 키와 OAuth 토큰은 어디에 저장되고 누가 회수할 수 있는가
공식 문서에 답이 없거나 계약에 따라 달라지는 항목은 “안전하다”라고 추정하지 않는 것이 좋습니다. 모르는 상태 자체가 도입 보류 사유가 될 수 있습니다.
문서 전체보다 필요한 조각만 보낸다
승인된 업무용 계정이라도 작업에 필요하지 않은 정보까지 입력할 이유는 없습니다. 회의록을 요약한다면 참석자 연락처와 다른 안건을 덜어 내고, 계약 문구를 다듬는다면 당사자 식별 정보와 금액을 제외한 조항만 떼어 내는 식으로 입력 범위를 줄일 수 있습니다.
- 목적요약·분류·문장 수정처럼 필요한 결과를 한 문장으로 정합니다.
- 추출결과에 꼭 필요한 문단과 필드만 별도 사본으로 만듭니다.
- 제거식별자·인증정보·다른 고객과 안건의 내용을 덜어 냅니다.
- 검토출력에 원문 민감정보가 다시 섞이지 않았는지 확인합니다.
비식별화는 이름 하나를 지우는 작업이 아닐 수 있습니다. 여러 정보의 조합으로 대상을 다시 알아볼 수 있다면 회사의 개인정보·보안 기준에 따라 더 강한 처리나 별도 승인이 필요합니다.
허용 여부를 결정하는 문서 처리 예시
고객 장애 보고서를 요약한다고 가정해 보겠습니다. 다음 값은 흐름을 설명하기 위한 가상 데이터입니다.
| 구분 | 역할 | 설명 | 예시 |
|---|---|---|---|
| 원문에 있던 필드 | 업무 처리에는 필요하지만 외부 입력에는 과한 값 | customer_name=새봄상사, phone=010-0000-0000, contract_id=CT-2048, authorization=Bearer [비밀값], occurred_at, error_code, 재현 단계 | 원문 보관소에서만 다룸 |
| 마스킹 뒤 입력 | 요약에 필요한 최소 문맥 | occurred_at=14:20 KST, error_code=PAY-401, 재현 단계=결제 승인 뒤 세션 만료. 고객명·전화번호·계약 ID·인증값은 제거합니다. | 개인·계약·인증 식별자 제거 |
핵심은 문서 전체를 넣고 나중에 삭제하는 것이 아니라, 목적에 필요 없는 필드를 입력 전에 없애는 것입니다. 오류 코드 자체가 고객을 역추적할 수 있거나 재현 단계에 내부 URL이 남아 있다면 그것도 일반화하거나 조직이 승인한 사내 경로에서만 처리해야 합니다.
소스코드를 AI에 넣을 때 추가로 봐야 할 것
소스코드는 문서보다 민감할 때가 많습니다. 코드 자체뿐 아니라 다음 정보가 함께 노출될 수 있기 때문입니다.
- 데이터베이스 구조와 내부 주소
- 인증 방식과 권한 모델
- 아직 공개되지 않은 기능의 계획
- 취약점과 우회 경로
- 제3자 라이브러리와 라이선스 정보
Claude Code 공식 보안 문서는 프로젝트 파일과 터미널 명령에 접근하는 코딩 에이전트의 권한 구조, 승인, 샌드박스, 네트워크 접근을 설명합니다. 핵심은 도구가 로컬에서 실행된다는 사실만으로 모든 위험이 사라지지 않는다는 점입니다. 파일을 읽는 권한과 외부 네트워크로 전송할 수 있는 경로를 함께 봐야 합니다.
실무에서는 저장소 전체를 처음부터 넘기기보다 다음 순서가 낫습니다.
- 공개 또는 비민감한 샘플 저장소로 작업 방식을 확인합니다.
- 비밀키, 고객 데이터, 운영 설정을 제외하고 필요한 파일만 엽니다.
- 읽기·분석부터 시작하고 수정과 명령 실행은 승인으로 둡니다.
- 결과를 확인한 뒤에만 범위를 넓힙니다.
- 사용이 끝난 토큰과 연결을 회수하고 기록을 남깁니다.
전면 금지보다 데이터 분류가 먼저다
AI를 전면 금지하면 직원이 개인 계정으로 우회해 사용하는 그림자가 생길 수 있습니다. 반대로 아무 도구나 허용하면 회사가 통제할 수 없는 데이터 경로가 늘어납니다. 그래서 현실적인 정책은 “승인된 도구, 승인된 데이터, 승인된 목적”을 정하는 쪽에 가깝습니다.
앞으로 AI 도구가 업무 시스템과 더 많이 연결될 가능성은 있습니다. 그렇다면 지금 준비할 것은 특정 제품의 보안 문구를 외우는 일이 아니라 다음과 같은 운영 기반입니다.
- 회사 자료의 공개·내부·기밀·제한 등급을 정합니다.
- 승인된 AI 계정과 개인 계정의 사용 목적을 분리합니다.
- 모델 학습·보존·삭제·관리자 접근 조건을 문서로 남깁니다.
- 커넥터와 MCP는 읽기 전용부터 허용하고 권한 목록을 관리합니다.
- 직원이 실수로 민감한 자료를 입력했을 때 신고·회수·변경 절차를 마련합니다.
이렇게 해 두면 새로운 AI가 등장해도 제품마다 처음부터 판단하지 않아도 됩니다. 이름이 바뀌어도 확인해야 할 질문은 남기 때문입니다.
실수로 민감한 자료를 입력했다면
삭제부터 누르기 전에 노출 종류를 나눕니다. 삭제는 대응의 한 단계일 뿐, 이미 처리·전송·로그·백업된 모든 사본이 회수됐다는 보장은 아닙니다.
API 키·토큰이 노출된 경우
해당 키를 즉시 폐기하거나 회전하고, 연결된 서비스의 권한과 접근 로그를 확인합니다. 담당자에게는 비밀값 자체가 아니라 키 식별자, 서비스·계정, 노출 시각과 채팅 또는 작업 ID, 부여됐던 권한, 폐기 시각, 의심 호출 범위를 전달합니다. 회수 대상은 키 하나가 아니라 그 키로 만든 세션·파생 토큰·비정상 작업입니다.
문서·고객 정보가 노출된 경우
공유·연결 앱·자동 동기화를 먼저 멈추고 가능한 삭제 절차를 시작합니다. 계정·워크스페이스, 파일·채팅 ID, 입력 시각, 포함된 정보 범주, 수신 서비스와 연결 앱, 공유받은 사람, 이미 만든 요약·다운로드·색인을 기록해 보안·개인정보 담당자에게 전달합니다. 회수 대상은 원문 파일뿐 아니라 채팅 사본, 프로젝트 파일, 연결 앱 색인, 내려받은 결과물입니다.
두 경우 모두 화면에서 사라졌다는 사실만으로 사고가 끝났다고 판단하지 않습니다. 서비스의 보존·법적 예외와 조직의 사고 대응 절차를 확인하고, 영향 범위와 복구 조치를 기록으로 닫습니다.
입력 전 10초 체크리스트
- [ ] 이 자료의 보안 등급을 알고 있는가
- [ ] 회사가 승인한 계정과 서비스인가
- [ ] 학습 사용·보존 기간·삭제 조건을 확인했는가
- [ ] 주민번호·인증키·고객 식별정보를 제거했는가
- [ ] 연결된 저장소와 외부 도구의 권한을 확인했는가
- [ ] 결과를 다른 사람에게 공유할 때 민감정보가 다시 포함되지 않는가
- [ ] 문제가 생겼을 때 토큰 회수와 보고 경로를 알고 있는가
자주 묻는 질문
회사 유료 플랜이면 회사 문서를 넣어도 되나요?
유료 여부만으로 판단할 수 없습니다. 업무용 플랜인지, 조직 관리와 데이터 처리 조건이 무엇인지, 회사 정책이 허용하는지 확인해야 합니다.
문서에서 이름만 지우면 안전한가요?
항상 그렇지는 않습니다. 날짜, 사건, 계약 금액, 내부 ID를 조합하면 개인이나 회사를 다시 추정할 수 있습니다. 비식별화가 필요한 데이터는 보안·법무 기준을 따르세요.
API를 쓰면 무조건 안전한가요?
API는 별도 데이터 정책과 기술 통제를 적용할 수 있지만, 호출 로그·프록시·애플리케이션 저장소에 데이터가 남을 수 있습니다. API 자체와 주변 시스템을 함께 확인해야 합니다.
VIEW—
