사용자의 위험을 완화하는 좋은 방법은 개인 정보 보호에 영향을 주지 않으면서 필요하지 않은 민감한 정보는 보관하지 않는 것입니다. 비즈니스 목표를 달성하면서 이 목표를 달성할 수 있는 방법은 매우 다양하므로 각 방법을 고려해 볼 가치가 있습니다. 다음과 같은 작업을 할 수 있습니다.
- 데이터가 필요한 목적을 설명합니다.
- 더 세부적인 수준으로 데이터를 수집합니다.
- 사용 후에는 데이터를 삭제합니다.
- 처음부터 수집하지 마세요.
이러한 각 접근 방식은 사용자가 무엇을 왜 하고 있는지에 대해 더 편안하게 느끼는 데 도움이 될 수 있으며, 개발자와의 관계에 크게 기여합니다. 투명성은 신뢰를 구축하며 무엇보다도 신뢰가 차별화된 장점이 될 수 있습니다. 많은 사람이 사용자와 고객이 기본적으로 이를 신뢰한다고 가정하지만, 소비자는 제품과 서비스를 끊임없이 평가하므로 그렇지 않을 수 있습니다. 데이터 및 상호작용을 존중하는 방식으로 사용자와 관계를 구축하면 프로젝트 또는 비즈니스 측면에서 경쟁 우위를 확보할 수 있습니다. 이는 경쟁 우위를 점할 수 없는 요소, 즉 진정한 차별화 요소입니다.
위의 접근 방식을 가장 효과적이지만 비즈니스에 가장 큰 영향을 미치는 것부터 가장 효과적이지만 중단이 적은 것 순으로 살펴보겠습니다.
처음에 데이터를 수집하지 않음
사용자 데이터가 피해를 입지 않도록 하는 가장 확실한 방법은 데이터를 수집하지 않는 것입니다. 서비스를 제공하기 위해 일부 데이터 수집이 필요하지만 생각보다 데이터 수집을 피할 수 있는 곳이 더 많이 있습니다. 비회원 결제를 예로 들 수 있습니다. 사용자가 웹 앱을 사용하여 무언가를 구매하려고 할 때 계정 가입을 요구할 수 있습니다. 나중에 처리하기 위해 개인 세부정보를 캡처했기 때문입니다. 메일링 리스트에 추가할 수 있고, 이미 관심 있는 고객으로서 사전 검증을 마쳤습니다. 하지만 고객은 이를 알고 있고 싫어합니다. 2021년 한 연구에 따르면 이탈한 판매 4건 중 1건은 사이트에서 사용자에게 계정 생성을 요구했기 때문입니다. 계정이 필요하지 않으면 고객을 유지할 가능성이 큽니다. 가입하지 않고 구매를 완료할 수 있게 되면 사용자에게 더 나은 옵션을 제공할 수 있으며, 동시에 사용자의 데이터를 충분히 보호하지 못하게 됩니다.
데이터 '퍼징'
물론, 데이터를 전혀 수집하지 않는 것은 선택사항이 아닐 수 있습니다. 서비스를 제공하고 합리적인 비즈니스 결정을 내리기 위해 데이터를 수집하는 것이 중요합니다. 신뢰 관계의 맥락에서 마케팅 커뮤니케이션을 구축하는 것도 도움이 될 수 있습니다. 하지만 집계된 데이터 (즉, 한 번에 많은 사용자에게 영향을 미치는) 결정은 집계된 데이터 (즉, 데이터의 집합적 속성)에 대한 결정이라는 점을 인식하는 것도 중요합니다.
예를 들어 잠재고객의 인구통계(잠재고객이 속하는 연령대, 위치 등)를 파악하는 것이 유용할 수 있습니다. 이로 인해 메시지나 접근방식이 달라질 수 있습니다. 그렇다고 해서 모든 서비스 사용자의 정확한 연령을 수집해야 하는 것은 아닙니다. 주로 트렌드와 전반적인 속성도 찾아 볼 수 있습니다. 대부분의 잠재고객이 '18~34세의 주요 인구통계'에 속하는지 여부에 따라 도달하려는 결정이 영향을 받는 경우, 실제로 물어봐야 할 질문은 사용자가 해당 인구통계에 속하는지 여부뿐입니다. 이렇게 하면 해당 그룹이 아닌 두 개의 '버킷'에 수집됩니다. 이보다 더 상세한 데이터가 필요한 상황이 있을 수 있지만 결정을 내리는 데 사용하는 인구통계 목록을 가져와 사용자에게 이 목록으로 분류하도록 요청하는 것이 매우 합리적입니다.
예
따라서 사용자층이 '18~34세', '35~49세', '49~64세', '65세 이상'으로 연령대를 어떻게 나누는지 알아두면 유용합니다. 매우 상세한 개인별 맞춤 데이터를 요청한 다음 사용자를 직접 분류하고 싶을 수 있습니다. 예를 들어 정확한 연령과 생년월일을 물어본 후 '35-49' 카테고리에 속하는 사용자 수에 관한 자체 목록을 만드는 경우와 같이 나중에 동일한 질문을 다시 할 필요가 없기 때문입니다. 하지만 어떻게 보일지 아는 것이 중요합니다. 이미 이 과정에서 다뤘고 다시 다룰 예정이므로 세부적인 수준의 데이터를 요청하면 사람들이 불편하게 느껴질 수 있고 조직에 대한 사용자의 신뢰가 떨어질 수 있으며 위험은 증가합니다.
데이터 요구사항을 고려하는 것도 중요합니다. 때로는 보다 세부적인 데이터가 '필요'하여 '만일의 경우'로 추측하는 경우도 있습니다. 지금은 사용자를 4개의 연령대로만 분류해야 할 수도 있지만, 향후에는 그 범위를 좁힐 수도 있습니다. 따라서 나중에 이 옵션을 열어 두기 위해 지금 매우 상세한 데이터를 수집해야 합니다. 과거에 더 세분화된 데이터가 의사 결정을 안내하기 위해 실제로 얼마나 자주 사용되었는지 생각해 보는 것이 좋습니다. 제공되는 서비스에 비해 공격적인 것으로 여겨지는 데이터를 요청하면 사용자가 조직을 신뢰하는 정도가 낮아질 수 있습니다. '만일의 경우'로 데이터를 수집하는 경우 더 나은 비즈니스 의사 결정을 위해 사용자의 신뢰를 희생하는 것뿐만 아니라 존재하지 않을 수도 있는 이론적 미래 의사 결정의 가능성과 관련 정보에 대한 보안 요구사항을 감수하는 데 그치지 않을 수 있습니다.
수집된 데이터의 세분화 정도를 줄이는 보다 상세한 알고리즘 방법도 있습니다. 무작위 응답 방법은 데이터가 조정 가능한 수준의 부정확성으로 수집되며, 응답자의 비밀유지를 유지하면서 잠재적으로 침습적이거나 민감한 정보를 수집할 때 사회 과학에서 수십 년간 사용되어 왔습니다. 위의 데이터 수집 방법은 사용자의 답변을 확대하는 것입니다. 즉, '나이가 몇 살인가요?'가 '다음 연령대 중 어느 연령대에 속하나요?'가 됩니다. 이때 무작위 응답은 특정 비율의 사용자가 답변에 대해 거짓말을 하도록 합니다. 잘못 응답한 사용자의 비율을 알면 수집된 데이터에서 유의미한 결론을 도출할 수 있지만 수집된 데이터가 부정확할 수 있다고 해서 개별 사용자의 개인 정보가 손상되지는 않습니다. 이 경우 독자 중 80% 가 여전히 18~34세 인구통계에 속한다고 말하는 경우, 응답자의 10% 가 의도적으로 오답을 제공하더라도 이 수치는 여전히 가장 큰 비중을 차지한다고 비교적 확신할 수 있습니다. 부정확한 정도는 정답이 항상 요청되지만 소프트웨어가 전송하기 전에 일정 비율의 답변을 변경하는 프로그래매틱 방식으로 변경될 수도 있습니다. 데이터가 수집될 때 이러한 프로세스와 그에 따른 결과를 사용자에게 설명할 수 있습니다. 즉, 개별 데이터는 신뢰할 수 없기 때문에 수집된 데이터를 악용하지 않겠다고 사용자가 신뢰할 필요가 없습니다.
비슷하지만 더 기술적으로 관련된 프로세스는 개인 정보 차등 보호입니다. 이는 수학적 기법을 사용하여 데이터의 집계 속성이 계속 표시되도록 데이터 스토리지를 변경하지만, 특정 개인이 데이터를 제공했는지 또는 어떤 데이터를 제공했는지도 알 수 없습니다. 이는 무작위 응답과 마찬가지로 개발자로부터도 사용자의 데이터를 보호하고, 개발자의 분명한 의도를 보여줍니다. 즉, 사용자 데이터가 없으면 사용자의 데이터를 사용할 수 없습니다.
수집된 데이터는 사용자 개인 정보 보호 침해를 줄이고 데이터가 유출될 경우 침해 수준도 낮추기 때문에 이러한 접근 방식을 통해 정보 유출 및 유출에 대한 보안을 강화할 수도 있습니다. 그러나 서버에서 개인 정보 차등 보호 기법을 적용하여 사용자가 집계되지 않은 데이터를 전송한 다음 개발자가 데이터를 집계하는 기법을 사용하는 경우에도 원시 사용자 데이터를 보호한 다음 처리 후 삭제해야 하며, 집계 전에 데이터를 사용하지 않는지(또는 데이터의 사용 목적을 명확히 함) 확인할 수 있는 명확한 정책을 마련하고 준수해야 합니다.
보관: 데이터를 수집한 다음 사용 후 삭제
수집된 데이터에는 수명 주기가 있습니다. 수집된 데이터는 비즈니스 결정을 내리는 데 도움이 되며, 언젠가 삭제되어야 한다는 점을 기억하면 유용합니다. 이는 다시 말해 사용자에게 질문을 하거나 사용자가 방문한 다른 웹사이트에 관한 정보를 저장하거나 사용자가 어떤 항목 및 기간을 추적하여 선호도에 대한 예측을 하는 경우, 개발자가 필요에 따라 사용할 수 있는 개방형 지원금이 아닌 특정한 목적으로 부여되는 데이터입니다. 이러한 목적으로 더 이상 데이터가 필요하지 않으면(때로는 1분 후, 몇 년이 지난 후) 삭제해야 합니다.
사용자에 대한 정보를 수집할 때마다 해당 데이터의 용도 (아래 참고)를 알고 있어야 하며 데이터 보존을 중지할 시기와 이유도 알아야 합니다. 이는 사용자가 동영상을 삭제하기로 선택한 경우, 특정 기간 후 또는 특정 이벤트가 발생한 후 로그아웃할 때일 수 있습니다. 관계에 대한 신뢰를 구축하는 좋은 방법은 가능한 경우 일방적 수신 거부를 포함하여 관련 데이터를 제어하는 방법을 사용자에게 명확히 알리는 것입니다. 데이터는 어떻게 삭제하나요? 계정을 삭제하려면 어떻게 해야 하나요? 이러한 관계를 구축하는 데 도움이 되는 것 외에도 데이터를 처리해야 하는 기간 동안에만 데이터를 저장하고, 사용자가 자신 또는 사용자를 대신하여 수집한 데이터를 확인하고 삭제할 방법이 있어야 합니다. 사업을 영위하는 지역에 이 사항에 대한 법률이 있을 수도 있습니다.
여기에서 명확한 기술 목표를 정의할 수 있어 셀프서비스로 사용자에게 도움이 됩니다. 사용자가 권한을 요청하지 않고 데이터 웨어하우스를 선택 해제할 수 있으면 선택하는 데 훨씬 더 편안함을 느낄 수 있으며 이를 위한 지원 리소스도 필요하지 않습니다.
다음과 같이 간단한 기본 수신 거부의 중요성을 인식하는 것이 중요합니다. "신뢰와 인식을 구축하기 위해 기업은 모든 터치 포인트에서 잠재고객을 존중하고, 요구를 경청하며, 그에 따라 대응하기 위해 노력하는 사회적 계약에 동의하는 것으로 시작할 수 있습니다." IAPP Nielsen Norman Group에 따르면 사용자가 '확장 프로세스를 거치지 않고 원치 않는 작업을 떠나려면 '긴급 상황 종료'가 명확히 표시되어야 합니다. 구독 취소보다 구독이 쉽다는 것은 누구나 알고 있습니다. 그러나 Nielsen Norman은 사용자가 고리를 넘기지 않고도 걸어 나갈 수 있는 기능을 제공함으로써 '자유와 자신감'을 얻게 된다고 말합니다. 학술 연구는 이를 뒷받침하고 '취소 가능성 원칙'이라는 이름을 붙였으며, "인터페이스는 취소가 가능한 경우 사용자가 부여한 권한을 사용자가 쉽게 취소할 수 있어야 합니다. 사용자는 이러한 동의를 취소할 수 있어야 하므로 가능한 경우 리소스에 액세스하는 권한을 줄일 수 있어야 합니다." 예를 보려면 Yee와 Iacono를 참고하세요.
데이터 보관 기간 및 보관은 조직과 프로젝트 간에 상당한 차이가 있지만, 고려해야 할 몇 가지 공통적인 가이드라인이 있습니다.
의견을 제시하지
여기에서는 사용자가 계정(및 가능한 경우 관련 데이터)을 삭제하고 로그아웃 시 Clear-Site-Data 헤더를 사용하여 로그아웃 시 임시 및 로컬에 저장된 데이터를 정기적으로 삭제할 수 있도록 하는 데 유용합니다.
클라이언트 측(쿠키, localStorage 또는 IndexedDB 또는 브라우저 캐시)에 저장된 사용자 데이터의 일부 또는 전부를 삭제하는 Clear-Site-Data 헤더를 제공합니다(해당하는 경우). Clear-Site-Data의 명백한 사용 사례는 사용자가 로그아웃하는 경우이지만, 보안 사고가 발생한 후에 이를 사용하여 도용 가능성이 있는 계정에서 클라이언트에 저장된 손상된 데이터의 흔적이 남아 있지 않도록 할 수도 있습니다.
Clear-Site-Data 지원을 추가하려면 사용자가 로그아웃할 때 (또는 클라이언트 측 저장소를 지우고자 할 때) 로그아웃 상태 (https://your-site/logout 또는 이와 유사한 상태)를 확인하는 페이지에서 HTTP 헤더 Clear-Site-Data를 전송해야 합니다. 이 헤더에는 다음 값의 일부 또는 전부가 포함될 수 있으며, 전체 값이 "*"일 수도 있습니다.
Clear-Site-Data: "cache", "cookies", "storage"
이러한 값은 각각 캐시된 페이지 (및 기타 HTTP 캐시 리소스), 저장된 쿠키, localStorage 및 IndexedDB 등을 지웁니다.
다른 옵션인 executionContexts에 대한 참조가 표시될 수 있지만 이 옵션은 많은 브라우저에서 지원되지 않습니다.
Clear-Site-Data 헤더를 사용하면 생성된 모든 리소스를 직접 삭제하는 것보다 더 쉬울 수 있습니다. 클라이언트에서 JavaScript 코드를 실행할 필요가 없고 브라우저 캐시를 지우는 유일한 공식 방법이기도 하지만 모든 브라우저에서 지원되지는 않기 때문입니다.
사용법 참고사항: Clear-Site-Data: cache를 전송하여 캐시를 지우면 Clear-Site-Data 헤더가 실제 로그아웃 페이지가 아니라 페이지가 로드되는 다른 일부 리소스에 전송되어야 합니다. 이는 캐시가 크고 속도가 느린 컴퓨터에서는 캐시를 지우는 동안 페이지가 차단되어 탐색을 할 수 없기 때문입니다. 이 작업은 몇 분 정도 걸리기 때문에 사용자가 실망할 수 있습니다. 발생할 가능성은 낮지만 테스트하기가 어려우므로 이 점을 염두에 두는 것이 좋습니다.
데이터가 필요한 목적 설명
사용자와 서비스 간의 관계에 대한 신뢰의 중요성은 사용자의 수명을 증가시키기 때문에 반복적으로 언급되었습니다. 또한 경쟁 우위도 제공합니다. 이러한 신뢰 수준을 높이는 한 가지 방법은 프로세스를 투명하게 공개하는 것이며, 데이터를 투명하게 공개하는 좋은 방법은 데이터의 목적을 설명하는 것입니다. 수집한 각 항목에 대해 언제 해당 항목이 삭제되는지 알아야 한다고 배웠습니다. 그러려면 이 데이터가 왜 필요한지, 답을 찾기 위해 어떤 특정 질문에서 데이터가 필요한지, 이 데이터를 수집하여 어떤 결정을 내리게 될지 알아야 합니다. 사용자에게 포기하도록 요청한 이 데이터가 필요한 이유를 알게 되면 이러한 데이터를 사용자에게 설명하여 신뢰를 구축하는 데 도움이 될 수 있습니다. 개인정보처리방침에서 또는 계정 생성에 관한 질문을 할 때 이 특정 질문에 대한 답을 얻어야 하는 이유, 해당 데이터로 수행할 작업, 데이터를 삭제할 수 있는 경우 및 방법을 설명하세요.
이러한 설명은 인라인으로 제시할 때 훨씬 더 잘 보입니다. 웹사이트의 다른 곳에서 밀접한 정책 문서에 설명을 숨기는 것은 설명을 숨기려는 시도처럼 보일 수 있습니다. 가입, 결제 또는 요청 양식을 통해 데이터 수집 자체와 함께 데이터를 수집하는 이유를 표시할 수 있습니다. 양식 필드에는 필수 입력란을 나타내는 별표 (*)가 표시되는 경우가 많습니다. 복잡한 양식에는 필드의 의미를 설명하는 정보 링크(i)가 포함되는 경우가 많습니다. 이러한 설명에 데이터가 수집되는 이유에 대한 설명을 추가하는 것이 좋습니다. 자주 사용되는 문구는 양식 입력란 옆에 있는 'Why do we need this?'입니다. 양식을 클릭하면 팝업 설명이 표시됩니다.
몇 가지 HTML 예는 다음과 같을 수 있습니다. 그러면 CSS와 JavaScript에서 <aside>를 숨기고 링크를 클릭할 때 팝업으로 표시합니다. 사이트에 사용하기 위해 만든 양식의 접근성을 확인해야 합니다.
이를 배치하는 정확한 방법은 스타일과 접근 방식에 따라 다르지만 여기서 요점은 데이터 수집을 해당 데이터가 수집되는 이유에 대한 설명과 직접 연결하는 것입니다. 모든 필드에 이를 지정해야 하는 것은 아닙니다. 가입 시 비밀번호를 선택해야 하는 이유를 아무도 설명하지 않아도 됩니다. 그러나 개인 및 연락처 정보에 대한 각 요청을 사용 및 보관 방법에 맞게 장식하면 데이터 보호에 투자하고 있음을 사용자에게 명확히 알리는 데 도움이 될 수 있습니다.
<div>
<label for="email">Email address*</label>
<input id="email" type="email" name="email" required aria-describedby="whyemail">
<a href="#whyemail">Why do we need this?</a>
<aside id="whyemail">We need this information as a unique identifier for you, and if you forget your password we can send you a reminder. We will use your email address to send you regular updates on the service if you choose, and will delete your email address from any mailing lists if you delete your account.</aside>
</div>
사용자에 관해 수집한 모든 정보를 이 절차를 거치면 내부 절차와 토론에도 도움이 될 수 있습니다. 앞서 '만일에 대비해' 데이터를 수집하고 싶다는 유혹이 들 수 있다고도 살펴보았습니다. 수집 이유를 투명하게 밝히면 이런 일이 발생함을 명확히 알 수 있습니다. 사용자 데이터 수집에 대해 사용자의 반응이 마음에 들지 않아서 공개적인 데이터 사용을 꺼리는 경우 데이터 수집을 재고해 볼 가치가 있다는 신호일 수 있습니다. 불쾌한 설명이 지나치게 불쾌한 경우 ('시간별로 방문 장소를 추적하기 위해 사용'), 너무 광범위한 경우 ('아직 사용할 내용을 모르지만 무언가 생각해 볼 때를 위해 사용하겠습니다') 또는 지나치게 회피적('내부적으로 공개되지 않는 목적으로 사용)'과 같은 경우가 여기에 해당합니다. 이는 단순히 도덕의 문제가 아닙니다. 이미 설명한 것처럼 사람들은 이러한 사실을 충분히 인식하고 있으며 무언가를 실험하는 것이 장기적인 노력의 시작이 아니라고 기대하는 사용자도 있습니다. 사용자가 초기에는 서비스에 많이 투자하지 않기 때문에 사용자가 자연스럽고 쉽게 가입할 수 있도록 사용자 환경을 설계하는 것이 일반적입니다. 따라서 사용자가 할 의향이 거의 없을 때 더 쉽게 투자할 수 있도록 하는 것이 중요합니다. 다시 포기하기가 쉬우며 장기적인 실험을 할 의지가 없다면, 서비스 실험은 억지로 실험을 시작하지 않을 것입니다. 이전과 마찬가지로 역설적이긴 하지만, 신뢰를 구축하는 가장 좋은 방법은 원치 않는 경우 사용자가 개발자를 신뢰하도록 요구하지 않는 것입니다.
데이터를 공유하지 않거나 최소한의 데이터만 공유하는 데는 합당한 이유가 있습니다. 상대방과 관계가 시작될 때 여러분을 신뢰할 이유가 없을 수도 있고 신뢰해서는 안 됩니다. 왜 그럴 수 있는지 보여주는 것이 목표입니다.
의견을 제시하지
- 수집하려는 모든 데이터와 수집하려는 이유와 보관 기간을 결정합니다.
- 해당 데이터를 요청할 때는 사용자에게 데이터를 수집하는 이유를 설명하세요.
- 사용한 후에는 서버 데이터베이스에서 삭제하세요.
- 사용자가
Clear-Site-Data헤더를 사용하여 직접 만든 계정을 삭제하고 스토리지에서 저장된 데이터를 지우도록 허용합니다.
이유
사용자와의 관계 구축은 신뢰가 핵심이고 신뢰는 개방성입니다. 사용자에 대한 데이터를 최대한 많이 수집하고 데이터 용도를 숨기는 데 그치지 않고, 신뢰를 쌓는 데 도움이 되고, 이는 비선정적인 경쟁사들보다 유리한 경쟁 우위를 점할 수 있습니다.