프로젝트를 시작할 때 이 설계 결정을 미룰 수 없는 이유
AI 에이전트를 도입하거나 직접 개발하는 프로젝트에서, 프라이버시 설계는 보통 법무팀 검토 단계에서 처음 등장한다. 기능 요구사항이 확정되고 아키텍처가 굳어진 뒤에야 "동의 화면을 어디에 넣을까"를 논의하게 된다. 이 순서가 문제다.
메타의 AI 개인 비서 Muse는 지금 이 설계 문제를 실제 스케일에서 드러내고 있다. Muse는 사용자가 주고받은 이메일, 채팅, SNS 활동을 읽고 매 시간 내부 프로필을 갱신한다. 이 프로필에는 사용자의 사회적 관계망, 상대와의 갈등이나 동맹 관계, 어떤 시간대에 어떤 방식의 메시지가 행동을 유도하는 데 효과적인지까지 담긴다. Muse를 직접 쓰지 않는 사람도, 그 사람을 아는 누군가가 Muse를 쓴다면 프로필에 포함될 수 있다.
공개적으로 접근 가능한 내부 파일을 통해 이 구조가 알려졌다는 점, 그리고 메타가 이를 부인하지 않았다는 점은, 이 설계가 의도된 것임을 확인해준다. 문제는 의도의 유무가 아니라 사용자가 이것을 얼마나 이해하고 동의했는가다.
여기서 핵심 질문은 Muse의 잘잘못이 아니다. 당신 회사가 비슷한 구조의 AI 에이전트를 만들고 있거나 도입을 검토 중이라면, 어느 시점에 어떤 결정을 내려야 나중에 같은 문제를 피할 수 있는가다.
수집 범위와 추론 범위는 다르다: 요구사항에서 이 둘을 분리해야 한다
AI 에이전트가 행동 데이터를 활용하는 방식은 크게 두 층위로 나뉜다.
첫 번째는 수집 범위다. 어떤 데이터 소스에 접근하는가, 얼마나 자주 읽는가, 원본 데이터를 얼마나 보관하는가. Muse의 경우 이메일, 소셜 피드, 메시지가 연결된다.
두 번째는 추론 범위다. 수집한 데이터로 무엇을 파악하는가. "사용자가 좋아하는 식당"을 기억하는 것과 "어떤 메시지 유형이 이 사용자의 행동을 가장 효과적으로 유도하는가"를 계산하는 것은 다르다. 사용자가 명시적으로 말하지 않은 목표나 욕구를 추론하는 것도 마찬가지다.
요구사항 단계에서 이 두 층위를 별도 항목으로 명시하지 않으면, 추론 범위는 기술 구현 과정에서 자연스럽게 확장된다. 수집 범위에 대한 동의가 추론 범위까지 커버한다고 가정하게 되는 것이다. 이 가정이 나중에 규제 기관이나 사용자 앞에서 가장 먼저 무너진다.
요구사항 단계 산출물 1: 수집 데이터 항목 목록과 각 항목에서 시스템이 도출하는 추론 항목을 별도로 명세화한다. "연락처 정보를 읽는다"와 "이 연락처와의 관계 강도 및 갈등 여부를 추론한다"는 서로 다른 줄에 적혀야 한다.
사용자 개입 지점: 있다는 것과 작동한다는 것은 다르다
Muse는 사용자가 특정 정보를 "잊으라고" 지시할 수 있다고 명시한다. 통제권을 준다는 뜻이다. 그런데 알려진 내부 지침에 따르면, "잊기" 요청을 처리할 때 원본 메시지가 여전히 채팅 기록에 남아있어도 그 사실을 사용자에게 알리지 말도록 설계되어 있다.
통제권이 존재하지만 그 한계가 사용자에게 보이지 않는 구조다.
이것은 UX 문제이기 전에 요구사항 문제다. 설계 초기에 "사용자가 삭제를 요청할 때 실제로 무엇이 삭제되는가, 그리고 그 범위를 사용자가 확인할 수 있는가"를 명세에 포함시키지 않으면, 개발팀은 합리적인 방향, 즉 대화 문맥을 유지하면서 프로필 항목만 제거하는 방향으로 구현한다. 그 결과가 위와 같은 구조다.
AI 에이전트의 사용자 개입 지점을 설계할 때는 세 가지를 각각 명세해야 한다.
- 접근 제어: 어떤 데이터 소스를 언제 연결하고 끊을 수 있는가
- 삭제와 망각의 실제 범위: 삭제 요청이 원본 데이터, 추론된 프로필, 학습에 반영된 패턴 중 어디까지 영향을 주는가
- 범위 고지: 삭제가 일부 범위에만 적용될 때 사용자에게 어떻게 알리는가
요구사항 단계 산출물 2: 사용자 개입 시나리오별 실제 작동 범위 명세. "삭제 요청 시 삭제되지 않는 것"을 포함한다.
제3자 데이터와 집계 학습: 동의를 받지 않은 대상이 있다
Muse 구조에서 가장 다루기 어려운 부분은 두 가지다.
하나는 제3자 프로파일링이다. Muse를 쓰지 않는 사람도, 다른 Muse 사용자와의 대화를 통해 프로필 데이터의 일부가 된다. 이들은 데이터 수집에 동의한 적이 없다.
다른 하나는 집계 학습이다. Muse는 개별 사용자의 데이터를 다른 에이전트와 직접 공유하지 않지만, 행동 패턴에서 뽑은 인사이트, 예를 들어 "야간 메시지가 특정 사용자 유형에게 더 효과적이다"는 식의 정보를 비식별 처리 후 제품 개선에 쓴다. 비식별화의 견고함은 데이터 유형과 결합 가능성에 따라 달라진다.
이 두 가지는 보통 개인정보 처리방침의 하단에 묻히는 내용이다. 하지만 규제 관점에서는 처음부터 명시해야 하는 설계 결정이다. GDPR이 적용되는 경우 제3자 데이터 처리에는 별도 법적 근거가 필요하고, 국내 개인정보보호법에서도 제3자 제공과 목적 외 이용은 별개로 다뤄진다.
요구사항 단계 산출물 3: 데이터 주체 유형 분류. 직접 사용자, 사용자가 언급한 제3자, 집계 인사이트로 기여하는 간접 주체를 구분하고, 각각에 대한 처리 근거와 범위를 별도로 정의한다.
내부 감시 체계를 설계에 포함해야 하는 실질적 이유
규제 준수를 위해 감사 로그를 남긴다는 개념은 익숙하다. 여기서 말하는 내부 감시는 조금 다른 층위다.
AI 에이전트가 추론과 프로파일링을 자율적으로 수행할 때, 개발팀도 시스템이 어떤 추론을 하고 있는지 사후에야 알게 되는 구조가 만들어지기 쉽다. Muse의 내부 파일이 사용자에게 공개된 것은 투명성을 의도한 것이라고 메타는 설명했지만, 역으로 말하면 시스템이 무엇을 기록하고 있는지 내부에서 먼저 파악하지 못하면 외부 검토가 들어왔을 때 대응이 어렵다.
요구사항 단계에서 정해야 하는 내부 감시 항목은 다음과 같다.
- 프로필 내용 열람 권한: 시스템이 생성한 사용자 추론 결과를 누가, 어떤 목적으로 볼 수 있는가
- 이상 추론 감지: 추론 결과가 특정 임계치를 넘거나 예상 범위를 벗어날 때 검토 절차가 있는가
- 집계 학습 결과 검토: 비식별화된 인사이트가 실제로 재식별 불가능한지 주기적으로 점검하는 프로세스가 있는가
이 항목들이 처음부터 요구사항에 없으면, 출시 후 규제 기관이나 외부 연구자가 먼저 문제를 발견하는 상황이 반복된다.
요구사항 단계 산출물 4: 내부 감시 체계 명세. 시스템이 생성하는 추론 결과의 접근 제어, 검토 주기, 이상 탐지 기준을 포함한다.
구현 단계로 넘어가기 전에 확인해야 할 판단 기준
요구사항 단계의 산출물 네 가지를 작성했다면, 구현 전에 다음 질문에 답할 수 있는지 확인한다.
수집과 추론 분리 측면에서: 사용자에게 동의를 받는 항목 목록이 수집 데이터와 추론 항목을 모두 포함하는가, 아니면 데이터 소스 목록만 있는가.
사용자 개입 측면에서: "삭제" 또는 "잊기" 기능의 요구사항에 삭제되지 않는 범위와 그에 대한 고지 방식이 명시되어 있는가.
제3자 데이터 측면에서: 시스템이 처리하는 데이터 주체 중 동의 없이 포함되는 대상이 있는가. 있다면 그 처리 근거가 요구사항 문서에 적혀 있는가.
내부 감시 측면에서: 시스템이 생성한 추론 결과를 개발팀 스스로 정기적으로 검토하는 절차가 일정과 담당자를 포함해 계획되어 있는가.
이 중 하나라도 "구현 이후에 정하면 된다"는 답이 나온다면, 그 항목이 나중에 가장 먼저 문제가 될 가능성이 높다. 설계 변경 비용은 요구사항 단계에서 가장 낮고, 출시 이후 규제 대응 국면에서 가장 높다.
첫 번째 스프린트를 시작하기 전에, 위 네 가지 산출물을 법무와 함께 검토하는 자리를 한 번 잡는 것이 이 글의 권고다.
