TL;DR

• Microsoft 365 Copilot, ChatGPT Business/Enterprise, Google Workspace 버전 Gemini는 조직의 계약(DPA: 데이터 처리 계약)에 따라 학습 이용이 기본적으로 OFF 설정되어 있다. 하지만 이 보호는 "회사가 계약했는지 여부"가 아니라 "현재 세션이 조직 계정인지"라는 테넌트 경계 (Tenant Boundary) 내부에 있을 때만 적용된다. 회사가 계약했더라도 개별 사용자에게 라이선스가 할당되어 있지 않다면, 해당 사용자가 여는 Copilot/Gemini는 개인용 버전의 동작으로 폴백(Fallback)된다.
• 계약 유무와 라이선스 할당은 별개의 상태 전이이며, 이를 혼동하면 "회사가 도입했으니 안전하다"라는 잘못된 전제하에 기밀 정보를 입력하게 된다. 브라우저의 OAuth 세션은 동일한 브라우저 내에 조직 계정과 개인 계정을 동시에 유지할 수 있으므로, UI상의 탭 전환 실수만으로도 데이터 흐름(Data Flow)의 보호 수준이 달라진다. 이는 앱 측의 결함이 아니라, 인간 측의 전환 비용이 제로(0)로 보장되지 않는다는 구조적인 문제이다.

배경

지난번에는 ChatGPT, Claude, Gemini의 옵트아웃(Opt-out) 설정을 개인 계정 내에서 비교했지만, 이번에는 레이어를 한 단계 높여서 애초에 "지금 열려 있는 세션은 회사의 계정인가, 개인의 계정인가"라는 구분을 다룬다. Microsoft 365 Copilot, ChatGPT Business/Enterprise, Google Workspace 버전 Gemini는 모두 계약 수준에서는 학습 이용이 기본적으로 OFF 되어 있음을 WebSearch를 통해 확인할 수 있었다. 하지만 실제로 화면을 확인해 보면, 이 보호는 "도구를 사용하고 있는지 여부"가 아니라 "어떤 계정·어떤 테넌트(Tenant)로 로그인했는지"라는 한 단계 더 세밀한 조건에 따라 전환되도록 설계되어 있다.

원리 1: 보호는 테넌트 경계(조직 계정 여부)에 의해 결정된다

Microsoft 365 Copilot은 Microsoft Graph를 통해 테넌트 내의 데이터에 액세스하지만, 이 학습 비이용 보호는 조직의 계약(Entra ID로 관리되는 테넌트)에 묶여 있다. 개인 Microsoft 계정(@outlook.com 등)으로 Copilot을 연 경우에는 이 계약의 적용 범위 외가 된다. ChatGPT도 마찬가지로, Business/Enterprise 워크스페이스에 로그인되어 있는 세션에서는 기본적으로 학습에 사용되지 않지만, 동일한 브라우저·동일한 인물이라 하더라도 개인용 Free/Plus 워크스페이스로 전환되어 있다면 적용 대상에서 제외된다. Google Workspace 버전 Gemini에서는 이 경계 내부에 있는 것이 UI상의 방패 마크(보호 아이콘)로 표시되는 구조로 되어 있다.

즉, 세 가지 도구 모두 보호의 단위는 "사용자"도 "계약 중인 회사"도 아닌, 지금 활성화된 세션이 어느 테넌트에 속해 있는가이다. 동일한 인물이 같은 날 동일한 도구를 열더라도, 로그인한 계정이 바뀌면 데이터 흐름의 취급이 달라진다.

원리 2: 계약과 라이선스 할당은 별개의 레이어 상태

회사가 Microsoft 365 Copilot이나 Google Workspace with Gemini 계약을 체결했더라도, 그것은 조직 단위의 계약이라는 하나의 상태에 불과하다. 개별 사용자가 해당 기능을 실제로 사용할 수 있는지 여부는 관리자가 해당 사용자에게 라이선스를 할당했는지라는 또 다른 별개의 상태에 의존한다. 이 두 가지 상태 전이(계약 체결 / 개별 라이선스 할당)는 독립적이며, 전자가 완료되었더라도 후자가 미완료 상태라면 해당 사용자가 여는 화면은 결과적으로 개인용 버전과 동일한 동작을 하게 된다(기능을 사용할 수 없거나, 개인 계정 이용으로 폴백됨). "회사가 도입했다"라는 정보만으로는 자신의 세션이 보호 대상인지 판단하기 위한 재료로서 불충분하다는 의미가 된다.

원리 3: OAuth의 다중 세션이 전환 실수의 온상이 된다

현대의 브라우저는 동일한 브라우저 내에서 여러 개의 OAuth 세션(조직 계정 및 개인 계정)을 동시에 유지할 수 있다. 이는 편의성을 위한 올바른 설계이지만, 부작용으로서 "현재 탭이 어느 계정으로 열려 있는가"를 사용자 스스로가 매번 육안으로 확인하지 않는 한, 의도치 않게 개인 계정의 세션으로 작업하게 되는 상태가 발생할 수 있다. 기술적으로는 앱과 브라우저 모두 사양대로 동작하고 있으므로 이는 버그가 아니다. 하지만 인간 측이 "전환을 의식하는 비용"을 항상 제로로 유지할 수 있다고는 장담할 수 없으며, 구조적으로 간과(Oversight)가 발생할 수 있는 지점으로서 설계자와 이용자 모두가 인식해 둘 필요가 있다.

효과가 없었던 것

"회사가 AI 도구를 계약했으므로, 열려 있는 화면은 기본적으로 안전하다"라는 전제는, 원리 2에서 살펴본 라이선스 할당(License Allocation)의 결여와 원리 3에서 살펴본 세션의 혼동 모두에 의해 무너진다. 도구 이름이나 계약 여부만을 확인하는 운영으로는 불충분하며, 실제로 열려 있는 세션이 조직 테넌트(Tenant)에 속해 있는지를 보호 표시, 워크스페이스(Workspace) 명칭, 방패 마크와 같은 UI상의 신호로 매번 확인하는 운영이 아니라면, 의도치 않게 개인용 버전의 동작 방식 그대로 기밀 정보를 다루게 된다.

요약

세 가지 도구에 공통적인 것은, 학습 이용 보호 여부가 "회사가 계약했는가"라는 단일 단계의 판정이 아니라, "현재 세션이 테넌트 경계(Tenant Boundary) 내부에 있는가"라는 세션 단위의 판정으로 결정된다는 점이다. 계약과 라이선스 할당이라는 두 가지 독립된 상태, 그리고 OAuth의 다중 세션이라는 구조를 이해한 상태에서, UI상의 신호를 매번 확인하는 습관을 갖는 것이 실무상 가장 실수를 줄일 수 있는 운영 방식이 된다.

Discussion