iOS 27은 Apple에게, 그리고 계속 늘어나는 지역 법률에게, 데이터를 수집하기 전에 사용자의 연령을 앱에 알려주는 공식적인 방법을 제공합니다. 앱이 미성년자로부터 무언가를 수집하고 있다면 — 대부분의 소비자 앱이 그렇게 인식하지 못한 채 실제로는 그렇게 하고 있습니다 — 동의를 요청하고 수집 내역을 문서화하는 방식이 바뀌어야 합니다. 언젠가가 아니라, 점점 늘어나는 지역 목록에서는 지금 당장입니다.
컴플라이언스 주제이니 먼저 밝혀 둡니다. 이 글은 마케팅과 프로덕트 팀을 위한 실무 안내이며, 법률 자문이 아닙니다. 구체적인 의무는 사용자가 어느 지역에 있는지, 앱이 무엇을 하는지에 따라 달라지며, 세부 사항은 변호사의 확인을 거쳐야 합니다. 이 가이드는 iOS 27이 도입하는 내용, 그것이 현재 사용 중인 트래킹과 세그멘테이션에 어떤 의미를 갖는지, 그리고 App Store 심사 기준이 더 엄격해지기 전에 점검해야 할 체크리스트를 정리합니다. Pushwoosh는 고객 참여 플랫폼이며, 동의와 데이터 수집이 Pushwoosh 설정과 맞닿는 부분은 정확히 짚어 드립니다.
iOS 27이 실제로 도입하는 것
핵심은 두 가지 API이며, 이 둘은 함께 작동합니다.
Declared Age Range API는 사용자의 생년월일을 요청하거나 저장하지 않고도 연령대(예: 13+, 16+, 18+)를 앱이 요청할 수 있게 합니다. Apple이 연령대를 제공하고, 개발자는 신호만 받을 뿐 날짜는 받지 않습니다. 이 프레임워크는 iOS 26부터 존재했으며, iOS 27에서 관련 요건과 시행이 강화됩니다.
PermissionKit은 부모 동의 절차를 담당합니다. 앱이 미성년자의 사용 방식에 영향을 주는 중대한 변경을 적용할 때, PermissionKit은 사용자에게 안내하고 규제 지역에서는 미성년자가 계속 이용하기 전에 부모 또는 보호자의 승인을 요청하는 흐름입니다.
중요한 설계 지점은 시스템이 언제 이것이 적용되는지 알려준다는 점입니다. isEligibleForAgeFeatures와 requiredRegulatoryFeatures와 같은 신호를 통해, OS는 특정 사용자에게 연령 관련 의무가 적용되는지, 연령대나 부모 동의를 요청해야 하는지를 알려줍니다. 사용자별로 추측할 필요 없이 플랫폼이 적용 여부를 직접 전달합니다.
”9월부터 의무화”라는 헤드라인이 잘못 전달하는 것
여기서는 정확히 짚을 필요가 있습니다. 이 의무는 단일한 전역 스위치가 아니며, “9월부터 의무화”는 Apple이 실제로 쓰는 표현이 아닙니다. 서로 다른 두 가지 사안이 진행되고 있는데, 언론 보도는 이를 하나의 마감일로 뭉뚱그리는 경향이 있습니다.
첫 번째는 App Store 심사 기준입니다. Apple은 개인정보 문서와 연령 처리 방식이 보여줘야 할 내용을 꾸준히 강화하고 있으며, 소셜 기능이나 사용자 생성 콘텐츠 기능이 있는 앱은 Declared Age Range API를 기반으로 한 사용자 대면 연령 게이트를 구현할 것으로 기대됩니다. 이는 특정 날짜에 한 번에 전환되는 것이 아니라 iOS 27 사이클 전체에 걸쳐 점진적으로 강화됩니다 — 소셜 기능이 있는 앱이라면 다음 릴리스 이전에 마무리해야 할 작업으로 여기시기 바랍니다.
두 번째, 확정된 날짜가 있는 것은 지역 법률이며, 이미 여러 곳에서 시행 중입니다. Apple 스스로 Declared Age Range 의무를 특정 관할 지역과 연결합니다. 유타주에서는 2026년 5월 6일부터, 루이지애나주에서는 2026년 7월 1일부터 신규 Apple 계정에 연령대 공유가 적용되며, Apple은 호주·브라질·싱가포르에서 2026년 2월 24일부터 18세 이상 앱 다운로드 차단을 시작했습니다. 다른 법률은 각자의 일정을 따르며, 일부는 이미 시행 중이고 일부는 연기되었습니다. 시스템의 규제 신호가 존재하는 이유는 바로 “이 사용자에게 이걸 해야 하는가”라는 질문의 답이 해당 사용자의 지역과 그 지역 법률의 현재 상태에 달려 있기 때문입니다.
실무적으로 정리하면, 소셜 기능이나 UGC가 있거나 규제 지역에서 미성년자 데이터를 수집하고 있다면 이는 지금 처리해야 할 작업이지 미래 항목이 아닙니다. 둘 다 해당하지 않더라도 개인정보 문서를 최신 상태로 유지하는 것은 여전히 기대되며, 규제 대상 지역은 계속 확대되고 있으므로 지금 역량을 갖추는 편이 나중에 마감일 압박 속에서 뒤늦게 대응하는 것보다 비용이 적게 듭니다.
이것이 법무팀만이 아니라 마케팅팀 일이 되는 이유
연령 확인은 법무와 엔지니어링의 과제처럼 보이지만, 그 영향이 어디까지 닿는지 따라가 보면 결국 트래킹과 세그멘테이션에 정확히 도달합니다.
광고 식별자를 수집하거나, 자동 행동 이벤트를 발생시키거나, 인앱 활동을 기반으로 세그먼트를 구축한다면 연령 신호는 무엇을 수집할 수 있는지, 누구에 대해 수집할 수 있는지를 바꿉니다. 보호 대상 연령대에 속한 사용자는 성인과 동일한 행동 트래킹과 광고 ID 수집에 조용히 포함시킬 수 있는 대상이 아닙니다. OS가 규제 지역의 사용자가 미성년자임을 알려줄 수 있는 순간부터, “모든 사용자를 동일하게 트래킹한다”는 방식은 더 이상 방어 가능한 기본값이 아닙니다.
이는 많은 앱이 안고 있는 공백을 정리할 좋은 시점이기도 합니다. 바로 광고 식별자(iOS의 IDFA, Android의 GAID) 처리가 불명확하거나 문서화되지 않은 문제입니다. 데이터 문서에 어떤 광고 식별자를 왜 수집하는지 명확히 적혀 있지 않다면, 그 공백은 이미 리스크였습니다. iOS 27 사이클을 거치며 심사 기준이 강화될수록 이는 반려 리스크로 바뀝니다. 연령 수집 관련 사항과 광고 ID 문서화를 같은 작업 단위에서 함께 정리하는 것이 효율적인데, 둘 다 같은 개인정보 고지 안에 있기 때문입니다.
컴플라이언스 체크리스트
법무 및 엔지니어링 파트너와 함께 아래 항목을 점검하세요.
- 미성년 사용자가 어느 지역에 있는지 파악하세요. 이미 연령 확인 법률이 시행 중인 운영 지역이 어디인지, 그리고 지역과 무관하게 App Store 심사를 유발하는 소셜/UGC 기능이 앱에 있는지 확인하세요.
- 적용 신호를 채택하세요. 특정 사용자에게 연령 관련 의무가 적용되는지 자체적으로 추측하지 말고, OS가 제공하는 신호를 활용하세요. 연령대나 동의를 요청할 시점은 플랫폼이 알려주도록 하세요.
- 생년월일이 아니라 연령대를 요청하세요. 연령 신호가 필요한 곳에서는 Declared Age Range API를 사용해 연령대만 받고, 이후 보호해야 할 생년월일은 절대 수집하거나 저장하지 마세요.
- 중대한 변경에 대한 부모 동의를 연결하세요. 미성년자가 앱을 사용한다면, 이를 요구하는 지역에서 중대 변경 동의 흐름이 갖춰져 있는지 확인하세요.
- 연령대별로 트래킹을 세그먼트하세요. 보호 대상 연령대 사용자가 미성년자에게 허용되지 않는 광고 ID 수집 및 행동 트래킹에서 제외되도록 하세요. 이는 사용자별 수동 검토가 아니라 데이터 수집 및 동의 설정의 문제입니다.
- 개인정보 문서를 업데이트하세요. App Store 개인정보 고지를 최신 상태로 유지하고, 이 참에 광고 ID 문서화 공백도 함께 메워 IDFA와 GAID 처리 방식을 명확히 밝히세요. 이는 심사 기준이 가장 먼저 확인하는 항목입니다.
- 동의 문구를 검토하세요. 미성년자나 보호자가 보는 동의 문구가 실제 수집 항목과 일치하는지 확인하세요. GDPR 동의 실무와 같은 맥락에서 점검하시면 됩니다.
Pushwoosh로 연령 인지 데이터 수집을 깔끔하게 처리하기
Pushwoosh는 동의 관리와 데이터 수집 제어 기능을 제공해 연령대별로 트래킹을 세그먼트하고, 보호 대상 사용자를 해당되지 않는 수집에서 제외하며, 광고 ID 처리를 문서화되고 깔끔한 상태로 유지할 수 있게 합니다. Pushwoosh는 SOC 2 Type I과 ISO 27001:2022 인증을 받았으며, GDPR과 HIPAA를 준수하고, EU와 미국에 데이터센터를 운영합니다. 컴플라이언스 작업에 노력이 전혀 들지 않을 수는 없지만, 데이터 쪽이 가장 어려운 부분이 되어서는 안 됩니다.
