당신의 데이터가 AI로 어떻게 전달되는지에 대한 요약표
요약
SaaS와 AI 서비스 연동 시 데이터가 어떻게 전달되고 노출될 수 있는지 시각화하여 설명합니다. Google Workspace, ChatGPT, Claude, AWS 등 주요 서비스의 데이터 접근 구조를 통해 보안 인식을 높이는 것을 목적으로 합니다.
핵심 포인트
- SaaS 내 데이터는 AI 모델이 읽을 수 있는 상태임을 인지해야 함
- AI 에이전트에게 권한 부여 시 민감한 클라우드 자원 접근 가능성 존재
- 로컬 AI 에이전트는 시스템 인증 정보 및 iCloud 데이터에 접근 가능
- 데이터 보호 정책 재검토를 위한 구조적 이해의 중요성
서론
다양한 서비스들이 AI를 도입하고 있습니다.
예를 들어 Google Workspace는 Gemini에게 물어보는 것만으로 파일의 저장 위치를 의식하지 않고 정보를 끌어내는 것이 가능합니다.
편리한 반면, 가능하다면 AI에게 보여주고 싶지 않은 데이터를 어디에 둘 것인가를 고민해야 하는 시대가 되었습니다.
- 기밀 정보
- 제3자 제공 허가를 받지 않은 정보
이번에는 어떤 서비스에 데이터를 저장했을 때, 어떤 AI에게 그 내용이 전달되는지를 시각화합니다.
기사의 목적
이 기사를 읽으시는 여러분께는 이후의 내용이 새로운 발견이 적을지도 모릅니다.
이 기사의 목적은, 읽는 분이 비엔지니어 등 데이터 관리에 익숙하지 않은 분들을 위한 설명 자료로 활용할 수 있도록 하는 것입니다.
엔지니어, 비엔지니어를 불문하고 가볍게 SaaS에 데이터를 맡기고 있지만, 그것들은 SaaS와 그 AI도 볼 가능성이 있는 것이라는 점을 시각화하는 것이 목표입니다.
반대로, SaaS를 사용해서는 안 된다고 주장하는 기사는 아닙니다.
필자 자신도 SaaS 없이는 사생활도 업무도 거의 불가능합니다.
소개하는 SaaS의 이용을 자제하도록 권고할 의도는 없으며, 오히려 구조를 올바르게 이해한 상태에서 안심하고 활용하시기를 바라고 있습니다.
SaaS에 데이터를 맡긴 시점에서 기밀 수준은 다소 떨어지므로, 데이터 보호 정책을 재검토하는 계기나 도움이 된다면 좋겠습니다.
요약표
SaaS를 모두 열거하는 것은 불가능하므로, 주요한 것들을 예시로 소개합니다.
AI 내장 제품
| 서비스 | 대상 데이터 | AI에 의한 데이터 읽기에 인간의 액션이 필요한가 | 거래처를 통한 이용 가능성 |
|---|---|---|---|
| Google Workspace | 거의 전부 (Drive / Gmail / Calendar / Meet / etc.) | 불필요 | 수신 측이 Gmail로 수신하고 있는 경우 / 거래처의 Google Meet에 참가한 경우 |
| ... |
MCP나 API 등으로 AI가 조작할 수 있는 것
ChatGPT도 Claude도 비즈니스 도구와의 연동을 강화하고 있습니다.
SaaS 자체에 AI가 탑재되어 있지 않거나, 탑재되어 있더라도 명시적인 호출이 필요하더라도, AI 서비스 경유로 의도치 않게 읽힐 가능성은 있습니다.
ChatGPT
수가 많은 데다 계속 늘어나고 있으므로, 공식 페이지를 참조해 주세요.
Claude
ChatGPT와 마찬가지로 공식 페이지를 참조해 주세요.
또한, Cowork를 이용하고 있는 경우, PC에서 열람 가능한 데이터는 모두 Claude가 액세스할 수 있게 됩니다.
AWS
Agent Toolkit for AWS를 통해, 권한이 허용되는 한 모든 데이터를 보는 것이 가능합니다.
평소 여러분이 사용하고 있는 권한을 AI 에이전트에게 넘기면, S3나 RDS나 CloudWatch 등 민감한 정보가 포함될 가능성이 있는 서비스에 액세스할 수 있게 됩니다.
OpenClaw 등의 로컬 AI 에이전트
Mac 상에서 동작시키고 있는 경우, iCloud 상의 모든 데이터에 더해, 홈 디렉토리에 저장된 액세스 키(Access Key)나 브라우저의 인증 정보를 경유하여 각 서비스에 액세스할 수 있는 상태가 됩니다.
해설
몇 가지 서비스에 대해 표에 기재한 이유를 심층적으로 살펴봅니다.
모두 AI 학습에는 데이터를 이용하지 않는다고 되어 있지만, 데이터를 읽을 수 있다는 점은 변함이 없다는 점에 주의가 필요합니다.
Google Workspace
Google Workspace 내의 거의 모든 데이터는 Gemini가 액세스할 수 있습니다.
- Google Drive
- Gmail
- Google Calendar
- Google Meet에서의 대화 내용
Gemini에게 물어보는 것만으로, 파일이 어디에 있었는지 검색하지 않아도 정보를 얻을 수 있는 매우 강력한 통합입니다.
편리하고 유용하지만, 데이터 내용에 따라서는 맡기기를 주저하게 되는 서비스가 되었습니다.
또한, Gmail이 있는 것도 까다로운 부분입니다.
수신한 메일에 민감한 정보가 포함되어 있어도, Gemini는 그 내용에 액세스할 수 있는 상태에 있습니다.
현대 사회에서 메일에 담은 정보는 Gemini가 읽을 수 있다는 전제로 생각하는 것이 좋을 것입니다.
Notion
Notion 내의 거의 모든 데이터에 액세스 가능한 Notion AI가 존재합니다.
지식 베이스(Knowledge Base)로도 활용되는 Notion으로부터 정보를 횡단적으로 취득할 수 있는 편리한 AI입니다.
Notion은 애초에 일본 국내에 데이터를 보관하고 있지 않았습니다.
2026년 5월부터는 일본 국내로의 데이터 보관을 선택할 수 있게 될 예정입니다.
Notion AI에 의해 데이터 취급 방식이 크게 변한 것은 아니며, 원래 유스케이스(Use Case)에 따라 Notion에 데이터를 두어서는 안 되었다는 점에 주의하시기 바랍니다.
GitHub
GitHub Copilot은 사용자가 접근 가능할 경우 프라이빗 리포지토리(Private Repository)를 볼 수 있습니다.
또한, Claude 등 다양한 AI 서비스가 GitHub에 접속 가능하다는 점에도 주의가 필요합니다.
접속에는 GitHub App이 필요하며, 접속 시 대상 리포지토리를 선택할 수 있지만, Organization의 경우에는 모든 리포지토리에 대한 액세스 권한을 부여하는 경우가 많을 것입니다.
이 경우, 허가된 AI 서비스 측은 Organization 내의 모든 리포지토리를 읽을 수 있습니다.
GitHub의 경우, AI가 읽어도 문제가 없는 데이터만을 저장해야 할 것입니다.
2026년 5월에는 CISA조차 GitHub 리포지토리에 액세스 키(Access Key)를 보관하고 있었다는 사실이 밝혀졌습니다.
간과하기 쉬운 점으로, GitHub Actions를 통한 Secrets 유출에도 주의가 필요합니다.
Secrets를 직접 참조할 수는 없지만, GitHub Actions 실행 중에는 평문(Plaintext)으로 취급됩니다.
GitHub Actions의 수정 권한이나 실행 권한, 로그 열람 권한을 AI에게 부여한 경우, AI의 실수로 인해 Secrets가 유출될 위험이 있습니다.
어느 권한이든 GitHub Actions 개발을 AI에게 맡길 때 필요하게 되므로, Secrets를 사용하지 않고 단명 토큰(Short-lived Token, OIDC 등)으로 전환하는 것을 검토해 보시기 바랍니다.
AI가 데이터를 읽기 어려운 보관처
불안을 조장하는 것만으로는 건설적이지 않기에, AI에게 읽히고 싶지 않은 데이터의 보관처 후보도 제시합니다.
단, 이는 어디까지나 기본 설정 상태에서는 읽히지 않을 것이라는 의미이며, 명시적으로 설정하면 모두 AI가 액세스할 수 있습니다.
로컬 디스크 (Local Disk)
AI로부터 읽히지 않는다는 관점에서 보면, 가장 안전한 것은 PC나 서버의 디스크입니다.
궁극적으로는 네트워크 자체를 차단함으로써 외부 유출 걱정조차 경감할 수 있습니다.
Windows의 경우에만 Copilot이나 Recall을 통해 파일을 읽힐 가능성이 있으므로 주의하시기 바랍니다.
AWS 등의 클라우드 서비스 각종 스토리지
AWS나 Google Cloud 등 클라우드 서비스의 스토리지는 클라우드 프로바이더(Cloud Provider)가 사용자의 스토리지 내에 액세스하지 않는다고 생각해도 무방합니다.
클라이언트 사이드 암호화(Client-side Encryption)를 사용하면, 클라우드 프로바이더 측에서조차 데이터 액세스를 거의 불가능하게 하는 설정도 가능합니다.
엄격하게 따지기 시작하면 기술적으로 클라우드 프로바이더가 액세스를 수행하는 것 자체는 가능하겠지만, 그 정도 수준의 데이터 관리는 이 글에서 다루지 않습니다.
서비스에 맡기기 전에 암호화하기
Google Drive 등에 데이터를 업로드하기 전에 파일을 암호화해 두는 방법을 취할 수 있습니다.
비밀번호가 걸린 zip 파일로 만드는 것만으로도 서비스 측에서의 해독은 어려워지며, 일반적인 서비스는 비밀번호가 걸린 파일을 해독하지 않을 것입니다.
보안 측면에서 비판받곤 하는 이른바 PPAP과 유사하지만, 그 방식의 문제점은 이메일로 zip 파일과 비밀번호를 모두 보내는 데 있습니다.
암호화된 파일과 비밀번호를 동일한 서비스에 보관하지 않는다면 안전한 수단입니다.
E2E 암호화 (End-to-End Encryption)를 표방하는 서비스
Proton Drive나 Tresorit 등 E2E 암호화를 수행하는 서비스라면, 서비스 측에서 파일 내부를 확인하는 것이 어렵습니다.
이번에 소개한 것 중에서는 로컬 디스크보다 소실 리스크가 낮으면서도, AI에게 데이터를 읽힐 걱정도 적은 균형 잡힌 선택지입니다.
AWS 등과 마찬가지로 엄격하게 생각하면 파일을 엿볼 수 있는 리스크 자체는 존재합니다.
그 리스크조차 허용할 수 없는 경우에는 다른 수단을 검토하시기 바랍니다.
마치며
개인적인 프로젝트에서 가급적 AI에게 보여주고 싶지 않은 파일이 있어, AI가 데이터를 읽기 어려운 환경을 찾던 중의 조사 결과를 기사로 작성했습니다.
단순히 나 자신이 주의하면 되는 것을 넘어, 거래처에 이메일이나 메시지를 보내는 것만으로도 어떤 형태로든 AI가 관여하게 되는 시대입니다.
우리가 가진 데이터의 대부분은 어떤 형태로든 AI가 읽고 있다는 전제하에 생각해야 합니다.
Discussion
AI 자동 생성 콘텐츠
본 콘텐츠는 Zenn AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기