존재하지 않는 AI 옵트아웃: SaaS 플랫폼 17곳을 점검한 결과

귀사가 연결해 놓은 모든 SaaS 플랫폼은 바로 지금, 귀사의 콘텐츠가 다른 누군가의 AI 모델을 학습시킬지 여부를 조용히 결정하고 있습니다. 저희는 8200.dev의 커넥터 라이브러리에 포함된 17개 플랫폼 전체를 점검하여 각 플랫폼이 실제로 이를 어떻게 처리하는지 확인했습니다 — 관리자 토글이 있을 것으로 예상했지만, 대부분 그렇지 않았습니다.

발견한 내용은 다음과 같습니다. Slack은 기본적으로 모든 워크스페이스를 비생성형 모델 학습에 포함시킵니다 — 관리자 콘솔 어디에도 토글이 없으며, 옵트아웃하려면 워크스페이스 소유자가 특정 제목으로 [email protected]에 이메일을 보내야 하는데, 이는 이후 검증할 수 있는 어떤 기록으로도 남지 않습니다. Salesforce에는 실제 설정이 존재하지만, Setup 안쪽 깊숙이 묻혀 있는 Einstein GPT 토글이라서 대부분의 관리자는 어디를 찾아봐야 할지조차 모릅니다 — 게다가 에디션에 따라 접근하려면 지원 케이스가 필요할 수도 있습니다. Zendesk의 방식은 그냥 지원 티켓 접수, 그것으로 끝입니다. Intercom의 Fin AI에는 워크스페이스 단위 옵트아웃이 있지만, 이는 API가 아니라 UI에 존재합니다 — 관리자 콘솔 밖에서는 아무도 이것이 실제로 설정되어 있는지 검증할 수 없습니다.

Dropbox는 가장 흥미로운 사례입니다. 미국 계정은 기본적으로 타사 AI 기능에 옵트인되어 있고, EU, 영국, 캐나다 계정은 기본적으로 옵트아웃되어 있습니다. 동일한 제품, 동일한 회사임에도 계정이 등록된 위치에 따라 기본값이 정반대이며, 대부분의 팀은 자신에게 어느 쪽이 적용되는지 확인해 본 적조차 없습니다. WhatsApp Business도 지역별로 다릅니다. EU, 영국, 브라질에는 이의 제기 양식이 존재하지만, 그 외 지역에는 당길 만한 레버 자체가 없습니다.

반대편에는 콘텐츠를 학습에 전혀 사용하지 않는다는 것이 진짜 계약상 약속이지 설정값이 아닌 플랫폼도 있습니다. Google Workspace, Microsoft 365, Box, Notion, GCP가 모두 여기에 해당합니다. 안심되는 일이기는 하지만, 이 역시 자사 관리자 콘솔을 클릭해 보는 것만으로 검증할 수 있는 사항은 아닙니다 — 대부분의 사람이 첫 페이지 이후로는 읽지 않는 데이터 처리 계약서 속에 묻혀 있는 약속을, 벤더의 말을 그대로 믿는 것일 뿐입니다.

이 모든 것을 관통하는 패턴은 다음과 같습니다. Jira와 그 인접한 몇 가지 AI 기능 토글(GitHub Copilot의 공개 코드 매칭, GCP Vertex 조직 정책)을 제외하면, API를 가리켜 명확한 답을 얻을 수 있는 곳은 거의 없습니다. 바로 이 때문에 이 작업은 플랫폼별로 한 번은 직접 수작업으로 점검해야 하며 — 그다음부터는 팀 내 누군가가 이미 약관을 다 읽었을 것이라고 믿는 대신, 새 플랫폼을 연결할 때마다 자동으로 플래그가 표시되어야 합니다.

"누군가 확인하겠지"가 조용히 실패하는 이유

이 문제가 곪아 터지는 이유는 태만 때문이 아닙니다. 통상적인 통제 방법 — 담당자를 지정하고 확인하라고 지시하는 방식 — 이 가리킬 곳 자체가 없기 때문입니다.

위 목록을 다시 살펴보면 모든 항목의 공통점을 발견할 수 있습니다: 그 태도(posture)는 대시보드가 볼 수 없는 곳에 존재합니다. 계약 조항 속에, 가입 시 설정된 지역별 기본값 속에, 지난번 조달 담당자가 갱신했을 때 바뀐 요금제 등급 속에, 직접 써서 보내야 하는 이메일 주소 속에 있습니다. 이들 플랫폼 중 어느 곳에도, 보안팀이 실제로 답을 알아야 하는 단 하나의 질문 — *지금 우리 조직이 학습 데이터를 제공하고 있는가, 그리고 그것을 우리가 의도적으로 결정한 것인가?* — 에 답해주는 단일 화면은 존재하지 않습니다.

그래서 확인 작업은 미뤄지고, 잊히고, 다음 담당자에게 그대로 넘겨집니다. 방치됨으로써 기본값이 승리합니다. 그리고 그 기본값은 귀사의 데이터 처리 의무가 아니라 벤더의 AI 로드맵에 최적화되어 벤더가 작성한 것입니다. 이는 8월 17일 Atlassian Jira에서 바뀌는 것에서 하나의 플랫폼을 두고 다뤘던 것과 같은 구조입니다 — 다만 이번에는 플랫폼이 하나가 아닙니다. 연결된 모든 도구가 저마다의 방식으로, 저마다의 시점에, 저마다 숨겨진 곳에서 각자 버전의 결정을 내리고 있는 것입니다.

이는 호기심의 문제가 아니라 컴플라이언스의 문제입니다

귀사의 조직이 SOC 2 보고서를 보유하고 있거나, ISO 27001을 준비 중이거나, GDPR 하에서 개인정보를 처리하고 있다면, 데이터 학습 제공 문제는 귀사가 이미 지고 있는 의무 한가운데로 곧바로 이어집니다.

데이터 처리 계약서(DPA)는 귀사의 데이터가 사용될 수 있는 목적을 기술합니다. 타사 AI 모델을 학습시키는 것도 하나의 목적입니다. 만약 고객사의 DPA에 자사 데이터는 서비스 제공을 위해 사용된다고 명시되어 있는데, 귀사가 연결한 플랫폼 중 하나가 조용히 그 동일한 데이터를 모델 학습에 투입하고 있다면, 하류(downstream)에서 약속한 것과 상류(upstream)에서 허용한 것 사이의 간극을 메워야 하는 것은 벤더가 아니라 귀사입니다. 감사인들은 이미 이 문제를 직접적으로 묻기 시작했으며, 보통 "귀사의 하위 처리자(subprocessor) 중 귀사의 데이터로 AI를 학습시키는 곳이 있습니까, 그리고 그것을 어떻게 알고 계십니까?"와 같은 형태로 묻습니다. 방어 가능한 답변은 두 가지 요소로 구성됩니다: 태도(어떤 플랫폼이 데이터를 제공하고, 어떤 플랫폼이 계약상 제외되는지)와 결정 기록(누가, 언제 검토했으며, 무엇을 선택했는지)입니다. "확인해 본 적이 없습니다"만이 유일하게 완전히 실패하는 답변입니다. 심사자가 현재 기대하는 바는 2026년 AI 거버넌스에 대해 감사인이 실제로 요구하는 것에서 다루었으며, 데이터 학습 제공 문제는 바로 그 검토 항목에서 표준 점검 항목이 되어 가고 있습니다.

지금 실행해 볼 만한 일회성 감사

다행히도 이 문제는 해결 비용이 진짜로 저렴한, 몇 안 되는 거버넌스 항목 중 하나입니다. 재설계할 필요는 전혀 없습니다. 설정을 찾아내고, 의도적으로 결정하고, 그 결정을 기록으로 남기기만 하면 됩니다. 구체적으로는:

1. 표면을 목록화하십시오. 귀사 조직의 콘텐츠나 메타데이터가 실제로 존재하는 모든 SaaS 플랫폼을 나열하십시오. 고객 데이터, 규제 대상 데이터, 또는 NDA 대상 정보가 저장되어 있다면 대상 범위에 포함됩니다 — 이번 주에 메일을 보낸 그 도구만이 아닙니다.
2. 각 플랫폼의 태도를 확인하십시오. 때로는 설정 페이지, 때로는 지원 티켓, 때로는 이메일 옵트아웃, 때로는 아무런 통제 수단도 없는 계약 조항일 수 있습니다. 그것이 어디에 있는지 기록하십시오.
3. 요금제 등급을 확인하십시오. 여러 플랫폼에서 태도는 요금제 등급에 따라 달라집니다 — GitHub는 Business와 Enterprise 데이터를 학습에서 제외하지만 하위 등급은 더 넓은 약관의 적용을 받으며, 마이그레이션이 조용히 태도를 뒤바꿀 수 있습니다.
4. 신중하게 결정하십시오. 옵트인이 정당한 선택일 수도 있습니다. 더 나은 AI 기능은 실질적인 혜택입니다. 실패 양식은 데이터 제공 자체가 아니라 아무도 결정하지 않은 채 이루어지는 데이터 제공입니다. 민감한 것은 제외하고, 그것이 귀사의 판단이라면 나머지는 그대로 두어도 됩니다.
5. 기록으로 남기고, 일정에 따라 재점검하십시오. 날짜가 기록된 메모는 조용한 기본값을 거버넌스 증거로 바꾸어 놓습니다. 그리고 벤더는 기본값을 자주 바꾸기 때문에, 한 번 검토한 태도는 관리되고 있는 태도가 아닙니다.

이 목록을 솔직하게 설명하면 *반복적이고, 여러 플랫폼에 걸쳐 있으며, 지루하다*는 것입니다 — 사람이 기억하는 것에 의존할 때 썩어버리는 바로 그런 종류의 통제입니다.

저희가 자체적으로 이 점검을 수행했을 때

2026년 7월 31일, 저희는 자사의 Atlassian 조직 관리자 콘솔을 열고 위의 5단계를 그대로 밟아 보았습니다. 그 결과를 정확하게 보고하는 것이 중요한데, 이는 양쪽 모두에 적용되기 때문입니다.

조직 수준의 통제는 이미 꺼져 있었습니다. Atlassian Administration → Security → Data contribution에는 제품별이 아니라 조직 전체에 대한 단일 On/Off 선택지가 있으며, 저희 설정은 Off로 되어 있었고 포함 목록도 비어 있어 선택적으로 다시 옵트인된 항목이 없었습니다. 고칠 것이 없었습니다. 이것이 좋은 기본값, 혹은 이전에 내려진 좋은 결정의 모습입니다.

그런데 그 통제 바로 아래에 인쇄된 문장이 있었습니다: *"메타데이터는 항상 제공됩니다."* 저희가 설정해 둔 스위치는 앱 내 콘텐츠 — 사람들이 티켓과 페이지에 작성하는 내용 — 만을 통제합니다. 메타데이터는 그 범위 밖에 있으며, 저희 요금제에서는 그에 대한 통제 수단이 아예 제공되지 않습니다. 저희의 Jira 구독은 Premium이며, 완전한 메타데이터 옵트아웃은 Cloud Enterprise 등급의 기능입니다. 모든 관리자 화면에 걸쳐 있는 배너에는 변경 사항이 적용되는 날짜가 표시되어 있습니다: 2026년 8월 17일.

즉, 유료 등급에서 이미 의도적인 결정을 내린 조직조차도 완전히 옵트아웃할 수는 없었으며, 그 사실을 알 수 있는 유일한 방법은 다시 살펴볼 특별한 이유도 없는 설정 페이지의 한 줄짜리 본문을 읽는 것뿐이었습니다. 한편 Bitbucket과 Trello는 별도로 청구되며 그 페이지 자체 밖에 완전히 위치합니다. 이들의 태도가 무엇이든, 그것은 다른 화면에서 이루어지는 다른 점검입니다.

이는 Atlassian을 비판하려는 것이 전혀 아닙니다. Atlassian은 최소한 그 통제 수단을 노출하고, 한계를 명확하게 명시하며, 날짜를 공개하고 있습니다. 이것이 바로 이 글이 주장하는 바를 저희 스스로에게 적용해 보여준 사례입니다: 결정과 그 한계는 어떤 대시보드도 보여주지 않는 곳에 존재하며, "우리는 그것을 껐습니다"는 "우리는 데이터를 제공하지 않고 있습니다"와 같은 말이 아니라는 것입니다.

8200.dev가 이를 자동으로 드러내는 방법

8200.dev는 이제 귀사가 연결하는 모든 플랫폼에 대해 AI 학습 태도(posture) 발견 사항을 제기합니다. Slack, Dropbox, Salesforce, GitHub, 또는 그 밖에 지원되는 어떤 플랫폼이든 연결하면, 스캔은 공유 및 권한 발견 사항 바로 옆에서 다음을 알려드립니다: 해당 벤더가 기본적으로 귀사의 데이터를 AI 학습에 사용하는지, 옵트아웃이나 계약상 보장이 어디에 있는지, 그리고 그 태도가 마지막으로 검증된 시점은 언제인지. 기본 옵트인 플랫폼은 결정을 요구하는 발견 사항으로 표시되며, 계약상 안전한 플랫폼은 감사인에게 제출할 수 있는 확인서(attestation)로 표시됩니다.

플랫폼이 인접한 축에서 API로 읽을 수 있는 정책을 실제로 노출하는 경우, 저희는 이를 실시간으로 점검합니다. GitHub 커넥터는 귀사 조직의 Copilot 공개 코드 매칭 설정을 읽어 들이며, GCP 커넥터는 Vertex AI가 조직 정책의 제약 없이 실행되고 있을 때 이를 플래그로 표시합니다. 모든 발견 사항에는 단계별 해결 플레이북이 함께 제공되며, 전체 점검 카탈로그는 기능 페이지에서 확인하실 수 있습니다.

핵심은 AI 기능이 위험하다는 것이 아닙니다 — 많은 기능은 켤 만한 가치가 있습니다. 핵심은 귀사 조직이 이미 사용 중인 모든 플랫폼에서, 데이터 학습 제공이 기본값이 아니라 결정이 되어야 한다는 것입니다. 이를 수동으로 기억하는 대신 자동으로 드러나게 하고 싶으시다면, 요금제 및 가격 안내를 확인하시고 단 몇 분 만에 첫 번째 플랫폼을 연결해 보십시오.