프라이버시 샌드박스에 대해 말하지 않는 것

배달의 민족 같은 서비스가 등장하면서 중국집과 배달원의 관계는 크게 변했습니다. 이게 SDK Runtime이라는, 앞으로 2~3년 내에 도입이 가능할 것으로 보이는 구조적 변화와 유사합니다.

예전엔 중국 음식점은 배달원을 직접 고용했었습니다. 그래서 음식점은 배달원에게 자원(오토바이, 휴계공간 등)을 제공했고 배달원의 숫자와 역량이 음식점의 퍼포먼스에도 적지 않은 영향을 주었습니다. 요즘 중국 음식점은 배달의 대부분을 대행 서비스를 통해 외부에 맡깁니다. 음식점의 자원을 아끼면서 자신은 핵심 업무에 집중합니다.

마찬가지로 안드로이드 앱은 SDK Runtime이라는 환경을 잘 활용하면 앞으로는 자투리 기능을 외부에 맡기고, 앱 자신은 핵심 기능에 집중할 수 있게 됩니다. 안드로이드 OS는 앱과 SDK 간의 통신을 관리하는 중간 레이어를 제공하여, 프라이버시 샌드박스 API와 광고 서빙의 문제를 해결합니다.

결국엔 도입될 것으로 판단하는 이유

OS 레벨의 변화는 혼란을 초래하지만, 이익이 크기 때문에 앱 개발자들의 선호로 SDK Runtime 도입 압력이 생길 것입니다.

개발자들은 맛있는 음식을 만드는데 집중하는 경향이 있습니다. 안드로이드 앱 개발자는 뛰어난 앱을 만드는데 필요한 테크 스택(예를들면 Java, Android Studio, Git 등)을 학습하는 것 외에는 리소스를 쓰고 싶어하지 않을 것입니다. 이런 점에서 SDK Runtime은 앱 개발자에게 반가운 소식입니다.
OS 레벨에서 앱과 SDK가 서로 다른 프로세스이므로, SDK의 이상동작에 의해 앱이 죽는다거나 앱 성능이 떨어지는 상황이 상당히 많이 없어집니다. 앱 개발자는 이런 치닥거리에서 해방됩니다.
SDK 업데이트 때문에 앱을 재배포해야 하는 일도 매우 많이 감소할 것입니다. 개발자뿐만 아니라 제품조직, 마케팅조직, 그리고 SDK를 제공하는 서드 파티에게도 희소식이죠.
앱 개발자는 자기가 구현한 기능이 아닌 서드 파티의 기능에 의해 사용되고 수집되는 데이터에 대해서 쉽게 확인할 수 있고 쉽게 컨트롤 할 수 있습니다. 이런 통제권이 있다는 것을 마다할 이유가 없습니다.

SDK Runtime 문서의 설계제안과 여러가지 내용에 따르면 위와 같은 장점을 기대할 수 있습니다. 물론 여전히 설계제안 단계일뿐이고 정말 갈 길이 멉니다.

변경사항에 대한 몇 가지 해설

구글의 공식 문서에 변경사항이 다음과 같이 정리되어 있습니다.

액세스: 권한, 메모리, 저장소
실행: 언어, 런타임 변경사항, 수명 주기, 미디어 렌더링
커뮤니케이션: 앱과 SDK 간 및 SDK 간
개발: 이 모델에서 빌드, 디버그, 테스트하는 방법
배포: Android, 앱, SDK의 여러 버전에서 배포, 업데이트, 롤백하는 방법

이 중 설명을 덧붙이고 싶은 내용들이 있습니다.

액세스 - 광고 SDK에게는 기본값으로 인터넷, 네트워크, 프라이버시 샌드박스 API, 광고 식별자, 플레이 스토어 인스톨 레퍼러 권한만을 주고 싶다는 바램이 담겨있습니다. 이 외의 권한은 SDK가 선언하여 유저에게 동의를 받아야 하겠지요. 단말기 정보, 식별자 정보를 얻지 못하면 인터넷 권한으로 얻은 IP 주소 정도를 활용할 수 있을 것입니다. 어트리뷰션 관점에서는 지금의 iOS 환경과 다를 것이 없어보이네요.
실행 - 광고 식별자는 없어질테지만 다른 종류의 식별자들은 여전히 남아있습니다. SDK Runtime에서는 원천적으로 이런 식별자를 수집할 수 없도록 하고 싶다는 의지가 보입니다. (For the SDK Runtime we propose further limiting access to identifiers which could be used for cross-app tracking.) 예를 들면 그 가능성이 낮고 가능한 경우도 적을 것이지만, IMEI 또는 전화번호 자체가 cross-app tracking에 활용될 수 있는 기술적 잠재력이 있습니다.
커뮤니케이션 - 서로 다른 프로세스(앱과 SDK든 SDK와 SDK든)는 안드로이드의 IBinder 인터페이스를 통해서 통신을 하도록 제안하고 있습니다. 이것의 결과로 앱은 SDK가 가지고 있는 API를 호출할 수 있고, 그 호출의 결과를 콜백 받을 수 있습니다. 결과적으로는 앱이 SDK의 기능을 쓰는데 문제가 없을 것이다 라고 말할 수 있습니다. SDK와 SDK 간에도 SDK Runtime 환경의 도움을 받든 IBinder를 사용하든 통신이 가능합니다. 다만 앱과 여러개의 SDK가 서로 데이터를 주고받아야 하는 상황을 어떻게 처리할지 굉장히 궁금해집니다. 예를 들어 앱이 3개의 mar tech 솔루션을 사용하고 이 3개 솔루션이 서로 유저 아이덴티티를 SDK 레벨에서 공유하는 것이 지금의 프랙티스라면, 각자 프로세스가 분리되어있고 비동기적으로 데이터를 주고받는 SDK Runtime 환경에선 어떤 방식으로 이것을 유지할 수 있을지에 대한 이야기입니다. 예를 들면 마케팅 오토메이션 벤더의 SDK와 어트리뷰션 벤더의 SDK, 또는 SRN SDK와 어트리뷰션 벤더의 SDK 사이의 관계일 수 있습니다. 이와 별개로 미디에이션과 SSP 간의 절차는 잘 처리할 수 있게 초기 설계에 반영하겠다는 언급이 있는 것은 다행이었습니다.

결론

SDK Runtime은 매우 구조적인 변화입니다. 단순히 기술적인 개선에 그치지 않고 어떤 것들은 꽤 크게 영향을 받겠지만, 엔드 유저의 데이터 보호나 앱의 성능 면에서 여러 가지 이점을 기대할 수 있습니다.

초기 도입 단계에서는 혼란과 불편함이 있을 수 있지만 장기적으로 볼 때 이점이 더 클 것으로 예상합니다. 개발자는 핵심 기능에 집중하고, 보안과 프라이버시는 시스템 레벨에서 강화되며, 유저에게 전달되는 경험은 향상될 것입니다. 이러한 이유로 SDK Runtime이 안드로이드에 결국엔 자리잡을 가능성이 높다고 생각합니다.

이 예상처럼 더 안전하고 효율적인 안드로이드 환경이 현실이 될지 지켜보려고 합니다.