AI로 구축된 앱이라고 해서 개인정보 보호를 소홀히 할 수는 없다

AI로 구축된 앱의 시대에는 데모를 위한 에너지보다 허가(permission)에 대한 규율이 더 필요합니다.

제품 출시(Shipping) 비용이 이상할 정도로 저렴해졌습니다. 소규모 팀이나 고집 있는 개발자 한 명이 몇 년 전보다 훨씬 빠르게 실제 앱처럼 보이는 결과물을 내놓을 수 있게 되었습니다. 인터페이스는 다듬어질 수 있고, README는 깔끔할 수 있으며, 빌드(build)도 정상적으로 작동할 수 있습니다. 전체적인 완성도가 실제 수준보다 훨씬 높게 느껴질 수도 있습니다.

하지만 그 어떤 것도 개인정보 보호(privacy) 비용을 줄여주지는 않습니다.

만약 당신의 앱이 기기 신호(device signals)를 읽거나, 사용자의 파일에 접근하거나, 로컬 상태(local state)를 검사하거나, 네트워크 요청(network requests)을 보내거나, 로그를 남기거나, 데이터를 내보내거나, 사용자의 자산(assets)을 처리할 수 있다면, "대부분 AI로 구축됨"이라는 문구는 면책 조항이 아닙니다. 그것은 사소한 정보일 뿐입니다. 사용자는 여전히 똑같은 질문을 던집니다:

이 앱은 무엇을 볼 수 있는가?

그 질문은 당신이 의도하든 의도하지 않든 UI(사용자 인터페이스)의 일부입니다.

Loupe는 유용한 경고의 신호탄입니다

Mysk Research에서 만든 Loupe는 iOS 및 iPadOS 앱으로, 네이티브 앱이 공개 API(public APIs)를 통해 무엇을 읽을 수 있는지 보여줍니다. Loupe의 README는 신호를 수동적(passive), 권한 기반(permission-gated), 고급(advanced)과 같은 카테리아로 분류합니다. 또한 사용자가 데이터를 내보내지 않는 한 앱이 값을 기기에 보관한다고 명시하고 있습니다.

이것만으로도 이미 흥미롭습니다. 대부분의 사용자는 앱이 요청 없이 무엇을 볼 수 있는지, 무엇이 프롬프트(prompt)를 필요로 하는지, 그리고 무엇이 더 고급 검사를 통해서만 가시화되는지에 대해 명확한 정신적 모델(mental model)을 가지고 있지 않습니다.

적어도 개발자들에게 더 흥미로운 세부 사항은, 이 프로젝트가 Loupe가 거의 전적으로 AI 코딩 도구로 작성되었다고 밝힌 점입니다.

그렇다고 해서 Loupe가 나쁘다는 뜻은 아닙니다. 오히려 논점을 더 날카롭게 만듭니다.

AI는 앱을 제작하는 데 도움을 줄 수 있습니다. 하지만 앱의 기능적 경계(capability boundary)에 대한 책임까지 흡수할 수는 없습니다. 도구가 앱이 무엇을 읽을 수 있는지 설명하기 시작하는 순간, 그 도구는 무엇을 읽는지, 무엇이 로컬에 남는지, 무엇이 내보내질 수 있는지, 그리고 사용자가 무엇을 신뢰해야 하는지에 대해 명확히 해야 합니다.

그러한 의무는 구현 방식이 시니어 엔지니어의 작업인지, 주말 프로토타입인지, 아니면 모델 지원 스프린트(model-assisted sprint)인지 여부를 따지지 않습니다.

"AI로 구축됨"은 개인정보 보호 모델이 아닙니다

생성된 코드를 그 자체로 하나의 카테고리로 취급하는 게으른 방식의 AI 제품 사고방식이 존재합니다. 앱이 실험적이기 때문에 거친 부분이 예상된다는 식입니다. 빌더가 빠르게 움직였기 때문에 책임은 가볍다는 식입니다. README에 AI의 도움을 받았다고 적혀 있으니 독자가 관대하게 평가해야 한다는 식입니다.

아니요.

사용자는 당신의 앱을 프롬프트 기록(prompt transcript)으로 경험하지 않습니다. 사용자는 자신의 컴퓨터, 휴대폰, 브라우저 또는 계정에서 실행되는 소프트웨어로서 앱을 경험합니다. 앱은 권한을 명확하게 요청하거나, 그렇지 않거나 둘 중 하나입니다. 데이터를 어딘가로 전송하거나, 전송하지 않거나 둘 중 하나입니다. 내보내기 경로를 설명하거나, 사람들이 추측하게 만들거나 둘 중 하나입니다.

개발자 도구(developer tools)와 소규모 유틸리티의 경우, 기능을 먼저 출시하고 경계(boundary)는 나중에 설명하려는 유혹적인 지름길이 있습니다. 그렇게 하면 첫날부터 제품 동작(product behavior)으로 설계되었어야 할 동작에 대해 모호한 개인정보 보호 문구(privacy copy)를 남기게 됩니다.

"우리는 개인정보 보호를 가치 있게 여깁니다"는 경계가 아닙니다.

"이미지는 브라우저에서 로컬로 처리되며 크기 조절을 위해 업로드되지 않습니다"는 경계입니다.

"네트워크 액세스는 이 엔드포인트(endpoint)에서 메타데이터를 가져오는 데에만 사용됩니다"는 경계입니다.

"내보내기는 이 버튼을 클릭할 때만 발생합니다"는 경계입니다.

이러한 문장들은 법적인 마법이 아닙니다. 이것들은 제품이 반드시 지켜야 하는 엔지니어링 약속(engineering commitments)입니다.

검사 가능성(Inspectability)이 느낌(vibes)보다 낫다

앱 개인정보 보호 도구에 대한 커뮤니티의 반응은 계속해서 동일한 실질적인 요구로 수렴됩니다. 사람들은 자신이 검사할 수 있는 동작을 원한다는 것입니다.

Apple의 앱 개인정보 보호 보고서(App Privacy Report)는 데이터 및 센서 액세스, 네트워크 활동, 접속된 도메인 등을 보여줌으로써 이러한 아이디어를 사용자 인터페이스(UI)로 밀어붙였습니다. 이러한 방식의 개인정보 보호 보고에 관한 연구는 다음 문제 또한 지적합니다. 사용자가 보고 있는 것 뒤에 숨겨진 목적을 이해할 수 없다면, 단순한 가시성(visibility)만으로는 충분하지 않다는 점입니다.

그것이 바로 개발자들이 가져가야 할 부분입니다.

가장 강력한 개인정보 보호 태세는 지루할 정도입니다. 즉, 눈에 보이는 동작이 설명과 일치하는 것입니다.

만약 앱이 로컬에서 작동한다고 말한다면, 네트워크 로그가 의심스럽게 보여서는 안 됩니다.

만약 앱이 내보내기(export)가 사용자 제어 방식이라고 말한다면, 명확한 내보내기 동작이 있어야 합니다.

만약 앱에 권한(permissions)이 필요하다면, 운영체제(OS)의 프롬프트가 모든 것을 갑작스럽게 느끼게 만들기 전에 제품 측에서 왜 필요한지 설명해야 합니다.

만약 도구가 민감한 자산(sensitive assets)을 처리한다면, 그 처리 경로(processing path)는 회의적인 사용자라도 이해할 수 있을 만큼 충분히 단순하고 명확해야 합니다.

개인정보 보호 문구(Privacy copy)는 증빙(receipt)이 되어야지, 실질적인 조치의 대체재가 되어서는 안 됩니다.

로컬 우선(Local-first) 방식은 경계가 확실할 때만 도움이 됩니다

로컬 처리(Local processing)는 그것이 실제로 구현되어 있을 때 이해하기 가장 쉬운 경계 중 하나입니다.

좁은 범위의 브라우저 유틸리티가 좋은 예시입니다. 만약 누군가가 이미지를 업로드하고, 크기를 조정하고, 결과물을 미리 본 뒤, 이미지 픽셀을 서버로 전송하지 않고 결과물을 다운로드한다면, 개인정보 보호 스토리는 복잡하지 않습니다. 그저 제한적일 뿐입니다.

이것이 바로 Resize Image For와 같은 도구들이 이 대화에서 유용한 예시가 되는 이유입니다. 핵심은 모든 앱이 이미지 크기 조정기여야 한다는 것이 아닙니다. 핵심은 워크플로우(workflow)가 작고 설명 가능한 경계를 가지고 있다는 점입니다: 브라우저에서 업로드, 로컬에서 처리, 결과 미리보기, 파일 다운로드.

그러한 종류의 디자인은 극적인 개인정보 보호 언어를 필요로 하지 않습니다. 구현 사항이 자신이 설명한 상자(box) 안에 머물러 있기만 하면 됩니다.

이와 동일한 아이디어가 AI로 구축된 앱에도 적용됩니다.

앱이 권한을 피할 수 있다면, 피하십시오.

로컬에서 처리할 수 있다면, 로컬에서 처리하십시오.

네트워크가 필요하다면, 네트워크 동작을 읽기 쉽게 만드십시오.

데이터를 내보낸다면, 내보내기를 명시적으로 만드십시오.

텔레메트리(telemetry)가 필수적이지 않다면, 모든 제품 분석(product analytics) 템플릿이 그것을 가정한다고 해서 굳이 추가하지 마십시오.

단순하고 명확한 경계가 곧 기능입니다.

출시 전 내가 사용할 체크리스트

만약 AI 코딩 도구가 당신의 앱 구축을 도왔다면, 개인정보 보호 검토는 덜 명확해지는 것이 아니라 더 명확해져야 합니다. 생성된 코드는 괜찮을 수 있습니다. 하지만 당신이 알아차리지 못한 기본 설정(defaults), 검사하지 않은 의존성(dependencies), 그리고 데이터가 어디로 가는지 누군가 묻기 전까지는 무해해 보이는 흐름(flows)을 포함할 수도 있습니다.

나는 아주 직설적인 체크리스트로 시작할 것입니다.

앱이 볼 수 있는 데이터를 나열하십시오. 당신이 "개인적인" 것이라고 생각하는 데이터만이 아닙니다. 그 전부를 말합니다. 디바이스 신호 (Device signals), 파일, 클립보드 접근 (Clipboard access), 위치 (Location), 카메라 (Camera), 연락처 (Contacts), 계정 식별자 (Account identifiers), 로그 (Logs), 생성된 출력물 (Generated outputs), 업로드된 자산 (Uploaded assets), 그리고 메타데이터 (Metadata)까지 포함됩니다.

수동적 가시성 (Passive visibility)과 권한 기반 접근 (Permission-gated access)을 분리하십시오. 만약 앱이 사용자 프롬프트 없이 무언가를 볼 수 있다면, 내부적으로라도 이를 명시하십시오. 그것이 바로 사용자들이 예상하지 못하는 바로 그 종류의 일입니다.

모든 네트워크 경로 (Network path)를 기록하십시오. 도메인 (Domains), 엔드포인트 (Endpoints), 분석 (Analytics), 오류 보고 (Error reporting), 업데이트 확인 (Update checks), 모델 호출 (Model calls), 저장소 (Storage), 결제 흐름 (Payment flows) 등 적용되는 모든 것을 포함합니다. 만약 특정 요청이 왜 존재하는지 설명할 수 없다면, 그것은 아마도 검토 과정에서 살아남지 못해야 할 것입니다.

내보내기 (Export)를 사용자의 행동으로 만드십시오. 데이터의 조용한 이동은 신뢰가 새어나가기 시작하는 지점입니다. 사용자가 보고서를 생성하거나, 파일을 저장하거나, 자산을 공유하거나, 다른 서비스로 무언가를 보낼 때, 그 순간을 명확하게 인지할 수 있도록 만드십시오.

좁은 범위의 권한 (Narrow permissions)을 선호하십시오. 필요한 것을, 필요한 시점에 요청하십시오. 광범위한 권한은 전체적인 리스크 프로필 (Risk profile)이 되기 직전까지는 편리하게 느껴질 뿐입니다.

개인정보 보호 스토리 (Privacy story)를 하나의 기능처럼 테스트하십시오. 네트워크 검사 (Network inspection)를 켠 상태로 앱을 실행하십시오. 주요 흐름 (Main flows)을 실행하십시오. 기기 밖으로 나가는 것이 무엇인지 확인하십시오. 새로고침이나 재시작 후에도 남아 있는 것이 무엇인지 확인하십시오. 권한이 거부되었을 때 어떤 일이 일어나는지 확인하십시오. README 파일은 앱이 실제로 수행하는 동작과 일치해야 합니다.

그런 다음, 앱이 수행하는 일을 평이한 언어로 말하게 하십시오.

정책 텍스트의 벽도 아니고, "군사급 개인정보 보호 (Military-grade privacy)" 같은 말도 아닙니다. 그저 운영상의 진실 (Operational truth)을 말하십시오.

신뢰의 경계는 여전히 당신의 몫입니다

AI 보조 개발 (AI-assisted development)은 소프트웨어를 구축하는 비용을 변화시킵니다. 하지만 책임 모델 (Accountability model)을 변화시키지는 않습니다.

이것이 많은 빌더(Builders)들이 다소 어색한 방식으로 배우게 될 부분이라고 생각합니다. 앱을 제작하는 비용은 저렴했을지 몰라도, 사용자의 신뢰는 저렴하지 않습니다. 권한은 여전히 중요합니다. 네트워크 호출도 여전히 중요합니다. 데이터 경로도 여전히 중요합니다. 불분명한 내보내기 흐름도 여전히 중요합니다.

최고의 AI 구축 도구는 자신이 AI로 구축되었다는 사실에 대해 사과하는 도구가 아닐 것입니다.

최고의 도구는 구현(implementation), 인터페이스(interface), 그리고 개인정보 보호 설명(privacy explanation)이 모두 동일한 방향을 가리키는 도구일 것입니다.

AI는 인터페이스를 출시(ship)하는 데 도움을 줄 수 있습니다.

하지만 신뢰 경계(trust boundary)는 여전히 당신의 책임입니다.

출처 노트