개인정보 법적 쟁점 검토

구조부터 보겠습니다. 수집 항목을 코드 한 곳에 정의하고 화면·방침이 같은 목록을 보게 한 점, 통증 정보를 민감정보로 분리해 선택 동의로 뺀 점, 동의가 없으면 서버 쓰기가 firestore.rules에서 막히게 한 점은 좋습니다. 실무에서 이 세 가지가 안 돼 있는 경우가 훨씬 많습니다.

다만 서비스를 열기 전에 반드시 막아야 할 것이 네 건 있습니다. 순서대로 짚겠습니다.

Firebase를 쓰신다고 했는데, 그러면 개인정보가 Google의 해외 서버에 저장됩니다. 이건 위탁과 별개로 국외 이전에 해당하고, 별도의 고지와 동의 근거가 필요합니다.

그런데 지금 동의 항목을 보면 국외 이전에 관한 항목이 없습니다. "계정 정보 · 프로필 · 훈련 기록 · 신체 정보"만 있습니다. 이 상태로 서버에 올리면 동의받은 범위를 벗어난 처리가 됩니다.

저장 위치를 서울 리전으로 두면 저장에 관한 부담은 줄어듭니다. 다만 그것만으로 끝나지 않습니다.

• 운영·장애 대응 과정에서 해외 인력이 접근할 수 있는지
• 인증(Firebase Auth), 앱 무결성(App Check) 같은 부가 서비스의 처리 위치가 저장소와 다른지
• 생성형 AI 처리 위치 — 이게 다음 지적 사항입니다

구글과 체결하는 데이터 처리 약관에서 실제 처리 지역을 확인하고, 그 결과를 방침에 그대로 적으셔야 합니다. "확인 후 기재"로 표시해 둔 자리가 그 부분입니다.

이게 제일 걸립니다. AI 코치가 아이의 종목·나이·신체 정보·통증 부위를 함께 넣어 답변을 만든다고 하셨죠. 통증 정보는 건강에 관한 정보, 즉 민감정보입니다.

지금 구조에서는 아이가 "어깨가 아파요"라고 입력하면 그 문장이 그대로 외부 AI 서비스로 전송됩니다. 정리하면 미성년자의 민감정보를 국외로 이전하는 것입니다. 동의 항목 어디에도 이 내용이 없습니다.

맞습니다. 그리고 이건 화면 문구가 아니라 코드에서 막아야 합니다. 지금 동의 저장소에 isAgreed('health')가 이미 있으니, AI 프롬프트를 만드는 지점에서 이 값을 보고 통증 관련 항목을 통째로 빼는 분기를 넣으시면 됩니다.

덧붙여 아이가 자유 입력으로 "어깨 아파요"라고 쓰는 건 막을 수 없습니다. 그건 이용자 본인이 스스로 제공한 것이라 성격이 다르지만, 그렇더라도 AI 대화 내용이 어디로 가는지는 고지해야 합니다.

만 14세 미만이면 법정대리인 동의를 받도록 만드신 건 맞습니다. 그런데 확인 방법이 보호자 성함을 아이가 입력하는 것뿐입니다.

아이가 부모 이름 세 글자를 적고 체크박스를 누르면 통과합니다. 이건 "동의를 받았다"고 주장하기 어렵습니다. 분쟁이 생기면 회사가 확인 노력을 다했는지를 다투게 되는데, 성함 입력만으로는 방어가 안 됩니다.

그게 깔끔합니다. 다만 순서가 중요합니다. 지금은 아이가 먼저 가입하고 나중에 부모를 연동하는 흐름인데, 만 14세 미만이면 부모 승인이 있기 전까지는 서버에 올리면 안 됩니다.

다행히 지금 코드가 그 상태를 표현할 수 있게 돼 있습니다. canStoreOnServer가 법정대리인 동의 시각이 비어 있으면 false를 돌려주니, 승인 전까지는 기기에만 저장하고 승인 후 업로드하는 구조로 가면 됩니다.

방침에는 "탈퇴 시 지체 없이 파기"라고 적혀 있는데, 앱에 탈퇴 기능이 없습니다. 삭제를 요구할 방법이 없는 상태로 방침에만 적어 두면, 그 자체가 지적 대상입니다.

열람·정정·삭제·처리정지 요구권은 방침에 문장으로 적는 것으로 끝나지 않고 실제로 행사할 수 있어야 합니다. 법정대리인도 아이를 대신해 행사할 수 있어야 하고요.

만 14세 미만을 대상으로 하면 아동이 이해할 수 있는 쉬운 표현으로 별도 고지해야 합니다. 지금 동의 화면은 성인 기준 문장입니다. "개인정보 수집·이용에 동의합니다"는 초등학생에게 통하지 않습니다.

아동용 요약본을 따로 두시길 권합니다. 문장을 짧게, 그림이나 아이콘을 곁들여서요.

개인정보 보호책임자를 지정하고 성명·직책·연락처를 방침에 공개해야 합니다. 1인 사업자면 대표자가 겸할 수 있습니다. 초안에 자리를 비워 뒀는데, 비운 채로 공개하면 안 됩니다.

그리고 그 연락처가 실제로 응답해야 합니다. 문의가 오면 지체 없이 처리해야 하고, 처리 기록도 남기셔야 합니다.

카메라·사진·알림 권한은 요청하기 전에 무엇에 쓰는지 고지하고, 필수와 선택을 구분해야 합니다. 지금은 OS 권한 팝업이 바로 뜨는 구조로 보입니다. 온보딩에 접근권한 안내 화면을 한 장 넣으세요.

보유 기간이 전부 "탈퇴 시까지"인 것도 다시 보셔야 합니다. 이용 기록처럼 목적이 끝나면 지워도 되는 항목은 별도 기간을 정하는 게 맞습니다. 장기 미접속 계정 처리 방침도 정하시고요.

미리 넣어 두는 방식은 권하지 않습니다. 이유가 세 가지입니다.

• 제3자 제공은 별도 동의 사항입니다. 처리방침에 적어 두는 것과 동의를 받는 것은 다릅니다. 방침에 문장이 있어도 동의를 안 받았으면 제공할 수 없습니다.
• 미성년자 데이터입니다. 아동의 개인정보를 상업적 목적으로 제3자에게 제공하는 건 규제기관이 가장 민감하게 보는 영역입니다.
• 지금 학부모 안내서에는 "기록이 기기 밖으로 나가지 않는다"고 적혀 있습니다. 여기에 데이터 판매 문구가 같이 있으면 앞뒤가 맞지 않아 오히려 신뢰를 잃습니다.

대안은 가명처리입니다. 특정 개인을 알아볼 수 없게 처리한 정보는 통계 작성이나 연구 목적으로 동의 없이 활용할 여지가 있습니다. 다만 가명처리의 적정성, 재식별 위험, 결합 제한 등 따져야 할 게 많아 이 단계에서 결론 낼 사안은 아닙니다.

지적만 드렸으니 유지하셔야 할 것도 말씀드립니다.

• 수집 항목을 코드 한 곳에 정의하고 화면·방침이 같은 목록을 보게 한 구조. 항목이 바뀌면 버전이 올라가고 재동의를 받는 장치까지 있습니다.
• 통증 정보를 민감정보로 분리해 선택 동의로 둔 점. 전부 필수로 묶는 사례가 훨씬 많습니다.
• 보안 규칙이 기본 거부이고, 동의 문서를 읽어 서버에서 한 번 더 막는 점. 클라이언트만 믿지 않는 설계입니다.
• 자세 분석 영상을 기기 밖으로 내보내지 않는 점.

정리하면, 중대 4건을 처리하기 전에는 서버 저장을 켜지 마시고, 그 뒤에 변호사 검토를 한 번 받으시면 됩니다. 지금 상태로 자문을 받으셔도 같은 지적이 나올 겁니다.