[컨퍼런스] 토스 가디언즈 - 동의서 정복하기

https://youtu.be/x4CuNfy6WF0?si=X1LBaoc_9Wmd1hRh

 

동의서는 보통 서비스 시작 전에 스크롤을 빠르게 내리고 확인 버튼을 누르는 그 화면으로 기억된다. 사용자 입장에서는 그렇다. 그런데 그걸 운영하는 쪽 입장은 전혀 다른 이야기다. 토스는 지난해 11월 GUARDIANS 2025를 개최했다. 토스 개인정보보호팀의 정유진 Privacy Manager가 이 자리에서 발표한 내용이 '토스의 동의서 정복하기'였다. 동의서를 어떻게 관리할 것인가, 그 고민의 결과를 꽤 구체적으로 공개한 발표였다.

동의서가 왜 문제였나

발표는 리스크 인식에서 시작한다. 동의는 개인정보보호법 제15조 제1항 제1호에서 규정하는 개인정보 처리의 적법 근거 중 가장 대표적인 것이다. 동의서는 이용자 화면에 직접 노출되기 때문에, 법 요건을 충족하지 못한 채 운영될 경우 규제 기관의 지적을 받을 가능성이 상시 존재한다. 토스에는 100개가 넘는 서비스가 있었고, 각 서비스마다 동의 화면이 통일되지 않은 상태였다. 개인정보보호팀이 가이드를 내려보내더라도 실제로 반영됐는지 파악하기 어려웠다. 개발 단계에서 오류가 생겨 동의를 제대로 받지 못하면 근거 없는 개인정보 수집·이용, 근거 없는 제3자 제공 동의가 되는데, 이는 과징금 대상이 될 수 있다. 리스크가 구조적으로 잠재해 있는 상황이었다.

표준 동의 모듈, 그리고 그 한계

이 고민에서 처음 나온 게 표준 동의 모듈이다. 내부에서는 줄여서 '표동모'라고 불렀다고 한다. 일관된 동의 UI를 클라이언트 단 모듈로 제공해서, 각 서비스가 표준화된 방식으로 동의를 받을 수 있게 한 것이다. 이용자가 명확한 인식 아래 자발적으로 동의 여부를 선택할 수 있도록, 동의 내용을 설명하는 타이틀, 동의 거부 옵션, CTA에 '동의' 문구 포함 등 컴플라이언스 요소를 화면에 녹였다.

그런데 이 첫 번째 버전에도 구조적인 한계가 있었다. 동의 화면 구성에 필요한 값들—노출 대상 아이디, 타이틀, 필수/선택 여부—을 개발자가 클라이언트 사이드에서 직접 코딩해야 했다. 동의서 아이디를 잘못 입력하면 엉뚱한 동의를 받게 된다. 표동모를 적용하지 않고 하드코딩하는 서비스도 종종 있었다. 동의 이력 적재도 제품팀이 자체 구현해야 했으니 누락 가능성이 있었고, 결정적으로 앱을 배포해야만 변경 사항이 반영됐기 때문에 이슈가 생겨도 즉각 대응이 불가능했다.

표준 동의 모듈 V2: 어드민과 서버 드리븐 방식으로의 전환

이 한계들을 해결하기 위해 나온 것이 표준 동의 모듈 버전 2(표동모 V2)다. 핵심 변화는 두 가지다. 첫째, 어드민을 제공해 동의를 코딩 없이 GUI로 만들 수 있게 했다. 개발자는 클라이언트에서 코드를 직접 작성하는 대신, 어드민에서 만든 표준 동의 모듈 아이디를 호출하기만 하면 된다. 기존에 200줄이 넘던 코딩이 30줄로 줄었다고 발표에서 밝혔다. 둘째, 서버 드리븐 방식으로 전환해 어드민에서 수정하면 앱 배포 없이 즉시 반영되게 했다. 이슈 발생 시 즉각 대응이 가능해진 것이다.

V2에는 개인정보보호법과 시행령, 신용정보법, 개인정보 동의 안내서뿐 아니라, 공정거래위원회가 발표한 '온라인 다크패턴 자율관리 가이드라인'도 참고해 담았다. 제품팀은 서비스를 부스팅하려는 니즈가 높기 때문에 다크패턴 리스크가 있다고 판단했기 때문이다. 금융 상품 온라인 설명 의무 가이드라인도 참고했다고 한다.

전사적으로 모든 서비스를 V2로 전환하도록 의무화했다. 표동모를 아예 적용하지 않던 서비스도 이때 통합됐다.

동의 메타와 5메타 프로젝트

V2 개발과 함께 진행된 것이 동의 메타 작업이다. 동의서에 들어갈 항목(처리 목적, 항목, 보유 및 이용 기간, 관련 계약 정보, 서비스 정보)을 모두 사전에 표준화하고, 어드민에서 텍스트를 직접 작성하는 방식이 아니라 미리 정의된 항목을 선택하는 방식으로 바꿨다. 이렇게 되면 '이름', '성명', '네임'처럼 동의서마다 제각각이던 표현이 '이름' 하나로 통일된다. 모든 동의 항목이 데이터로 관리되니, 예를 들어 이름을 처리하는 서비스를 조회하고 싶으면 해당 항목이 포함된 동의서를 시스템적으로 추출할 수 있게 된다.

어드민에서는 동의문 노출 채널(앱/웹), 동의 성격(필수/선택), 처리 목적(수집·이용/제3자 제공 등), 고유식별 정보 처리 여부, 민감 정보 처리 여부, 만 14세 미만 정보 주체 해당 여부, 정보 주체 유형, 처리 주체 등 속성값도 함께 입력하게 된다. 이 구조 덕분에 고유식별 정보를 처리하는 동의서 전체를 언제든 뽑아낼 수 있는 토대가 마련됐다.

발표 말미에 소개된 5메타 프로젝트는 동의서를 서비스, 계약, 테이블, API 메타와 연계해 정합성을 검증하는 프로세스다. 예를 들어 동의서에는 이름을 처리한다고 명시했는데 실제 테이블에서는 이름과 휴대전화 번호가 저장되고 있다면, 이를 정합성이 깨진 것으로 보고 즉시 개선 조치를 하는 방식이다. 동의서 점검 프로세스는 이 5메타 체계 안에서 연계될 예정이라고 했다.

QA와 사후 점검

시스템을 만든 것으로 끝이 아니었다. 300개가 넘는 표준 동의 모듈을 전수 검수했고, 신규 표동모가 생기면 알럿을 받아 QA를 진행하는 체계를 갖췄다. QA 항목은 동의 화면 문구, 앱에서 동의서 클릭 시 올바른 랜딩 여부, 표준 동의 모듈 정책 부합 여부, 다크 패턴 존재 여부, 이력 적재 여부 등 16가지다. 동의서 자체에 대해서도 매월 리스트업해 현행화하고, 신규 생성·수정 시 채널 알럿을 받아 사후 점검을 진행하고 있다.

점검 결과 V2를 적용한 서비스에서는 전환 과정의 로직 오류는 있어도, 동작 자체의 문제점이나 동의 이력 미적재 같은 구조적인 문제는 발견되지 않았다고 했다. 메타 누락이나 서비스 연결 누락처럼 사람이 빠뜨리는 경우는 있었지만, 동의서 자체의 문제는 거의 없었다는 것이다.

발표 마지막에 강조한 부분이 인상적이었다. 표준 동의 모듈이나 어드민 개발은 클라이언트 개발자, 서버 개발자, 디자이너가 함께 만든 것이고, V2 전환과 미흡 사항 개선도 서비스를 준비하면서 바쁜 제품팀의 적극적인 협조 없이는 불가능했다는 이야기였다. 개인정보보호팀 단독으로 할 수 있는 일이 아니라는 점, 회사 차원의 협조가 필요하다는 것을 청중에게 전하고 싶었던 것 같다.

동의 관리를 이야기할 때 흔히 법적 요건 충족에 초점이 맞춰지는데, 이 발표는 그 요건을 실제로 지속 가능하게 유지하는 시스템을 어떻게 설계할 것인가에 답하려고 했다는 점에서 인상에 남는다. 동의서를 문서가 아니라 제품처럼 다룬 접근이랄까. 개인정보보호팀이 감사 역할에 머무르지 않고 제품팀, 개발팀과 함께 구조 자체를 바꿔버린 사례로 기억해 둘 만하다.