앱 개발
헬스케어 앱은 기능보다 데이터 다루는 방식을 먼저 정해야 하는 앱입니다. 건강에 관한 정보는 개인정보 보호법에서 민감정보로 분류되어 다른 개인정보와 따로 동의를 받아야 하고, 저장과 접근 관리도 더 엄격하게 해야 합니다. 여기에 의료기기에 해당하는지, 애플과 구글의 건강 데이터 정책에 맞는지까지 개발 초반에 확인해 두면 출시 직전에 화면과 서버 구조를 뜯어고치는 일을 줄일 수 있습니다.
건강정보는 민감정보, 동의를 따로 받습니다
개인정보 보호법 제23조는 건강 등에 관한 정보를 민감정보로 정하고 원칙적으로 처리하지 못하게 합니다. 예외는 두 가지입니다. 정보주체에게 수집 목적과 항목, 보유 기간 등을 알리고 "다른 개인정보의 처리에 대한 동의와 별도로" 동의를 받은 경우, 그리고 법령에서 처리를 요구하거나 허용하는 경우입니다.
앱으로 옮기면 회원가입 동의 화면에 건강정보 수집 동의를 따로 떼어 두어야 한다는 뜻입니다. 이용약관, 개인정보 수집 동의, 건강정보 수집 동의를 한 번에 "전체 동의"로 묶어 두더라도 각 항목은 개별로 보여 주고 선택할 수 있어야 합니다. 걸음 수, 수면 시간, 혈압, 혈당, 복약 기록처럼 어떤 데이터가 건강정보에 해당하는지는 서비스마다 판단이 갈리는 부분이 있어서, 기획 단계에서 수집 항목 목록을 만들고 항목별로 분류해 두는 걸 권합니다.
이 글은 개발하면서 저희가 챙기는 실무 기준을 정리한 것이고, 서비스별 구체적인 적용은 법률 전문가와 한 번 확인하시는 게 좋습니다.
덜 모으는 것이 가장 확실한 보안입니다
헬스케어 앱 기획서를 받아 보면 "나중에 분석에 쓸 수 있으니 일단 저장"하는 항목이 꽤 많습니다. 생년월일 전체, 정확한 위치, 원본 측정값을 초 단위로 전부 보관하는 식입니다. 모은 데이터는 전부 보호해야 할 대상이고, 유출됐을 때 책임도 함께 늘어납니다.
저희는 화면 하나하나에 대해 이 값이 실제로 어떤 기능에 쓰이는지 묻는 방식으로 정리합니다. 나이대만 필요하면 출생연도만 받고, 기기에서 계산해 결과만 보내도 되는 값은 원본을 서버로 올리지 않습니다. 기기 연동 앱이라면 측정 원본을 앱 안에서 일정 기간만 두고 요약값만 서버에 저장하는 구조도 검토합니다. 보관 기간을 정하고 지나면 지우는 배치 작업까지 처음부터 만들어 두면 나중에 따로 손댈 일이 없습니다.
암호화와 접근 관리, 접속기록
개인정보보호위원회 고시인 "개인정보의 안전성 확보조치 기준"은 접근 권한 관리, 접근 통제, 암호화, 접속기록 보관과 점검 같은 조치를 요구합니다. 세부 기준은 고시 개정에 따라 바뀌므로 개발 시점의 원문을 확인해야 합니다. 앱 개발에서 실제로 손이 가는 부분은 대략 이렇습니다.
| 구간 | 저희가 적용하는 방식 |
|---|---|
| 통신 | 모든 API를 HTTPS로만 받고, 앱에서 일반 HTTP 접속을 막음 |
| 기기 저장 | 토큰과 민감한 값은 iOS 키체인, 안드로이드 Keystore 기반 저장소에 보관 |
| 서버 저장 | 데이터베이스와 백업 암호화, 민감 항목은 필드 단위 암호화 검토 |
| 관리자 화면 | 담당자별 계정, 역할별 권한, 개인정보 조회와 다운로드 기록 저장 |
| 로그 | 애플리케이션 로그와 크래시 리포트에 건강정보가 찍히지 않도록 마스킹 |
의외로 자주 새는 곳이 마지막 줄입니다. 개발 중에 디버깅하려고 요청 본문을 통째로 로그에 남겨 두면, 측정값과 사용자 식별자가 로그 수집 서비스로 그대로 넘어갑니다. 크래시 수집 도구나 분석 도구도 외부 서비스라는 점을 잊기 쉽습니다.
관리자 페이지도 꼭 같이 설계해야 합니다. 앱 쪽 보안은 잘 챙겼는데 운영자 화면에서 전체 회원 목록을 엑셀로 내려받을 수 있게 열어 두는 경우가 있습니다. 누가 언제 어떤 회원 정보를 봤는지 남기는 기능은 나중에 붙이기 번거로우니 처음부터 넣는 편이 낫습니다.
서버 위치와 국외이전
클라우드 리전을 해외로 잡거나, 해외 기업의 분석 도구, 고객 상담 도구, AI API로 데이터를 보내면 개인정보 국외이전 문제가 생길 수 있습니다. 개인정보 보호법 제28조의8은 국외로 제공, 처리위탁, 보관하는 것을 원칙적으로 막고, 별도 동의를 받거나 계약 이행에 필요한 위탁·보관으로서 처리방침 공개 등 요건을 갖춘 경우 같은 예외를 두고 있습니다. 별도 동의를 받을 때는 이전되는 항목, 국가, 시기와 방법, 받는 자, 이용 목적과 보유 기간, 거부 방법 등을 미리 알려야 합니다.
실무에서는 서버와 데이터베이스를 국내 리전에 두고, 외부 서비스로 나가는 데이터를 목록으로 정리해 두는 방식으로 시작합니다. 특히 AI 기능을 붙일 때 사용자 입력이나 기록을 해외 모델 API로 보내는지, 보낸다면 어떤 항목인지가 개인정보 처리방침과 맞아야 합니다.
분석에 쓰고 싶다면 가명정보
서비스를 운영하다 보면 사용자 데이터를 모아 통계를 내거나 연구에 쓰고 싶어집니다. 개인정보 보호법 제28조의2는 통계작성, 과학적 연구, 공익적 기록보존 등을 위해 정보주체의 동의 없이 가명정보를 처리할 수 있게 하고 있습니다. 가명정보는 이름이나 연락처 같은 값을 지우거나 바꿔서, 추가 정보 없이는 특정 개인을 알아볼 수 없게 만든 정보입니다.
다만 가명처리를 했다고 끝나는 건 아닙니다. 다시 알아볼 수 있게 하는 추가 정보를 분리해 보관해야 하고, 관련 기록을 남기는 등 지켜야 할 의무가 따로 있습니다. 앱 설계 단계에서 할 일은 분석용 데이터를 운영 데이터베이스와 분리할 수 있게 구조를 잡아 두는 것입니다. 운영 테이블에 사용자 ID와 측정값이 뒤섞여 있으면 나중에 가명처리 파이프라인을 만들 때 손이 훨씬 많이 갑니다.
이 앱이 의료기기에 해당하지는 않을까
헬스케어 앱에서 가장 늦게 확인했다가 곤란해지는 부분입니다. 식약처의 의료기기와 개인용 건강관리(웰니스)제품 판단기준은 사용 목적과 위해도에 따라 구분하는데, 질병의 진단이나 치료 등을 목적으로 하면 의료기기로, 일상적인 건강관리를 목적으로 하면 의료기기가 아닌 것으로 봅니다. 2025년 1월 24일부터는 디지털의료제품법이 시행되어 소프트웨어 형태의 의료기기를 디지털의료기기소프트웨어로 따로 다루고 있습니다.
- 일상적인 건강관리 목적
- 혈압 기록, 그래프 표시
- 의료기기 아닌 것으로 봄
- 질병 진단, 치료 목적
- 측정값으로 위험 판정
- 허가와 품질 관리 필요
같은 혈압 기록 앱이라도 "혈압을 기록하고 그래프로 보여 준다"와 "측정값을 분석해 고혈압 위험을 판정한다"는 성격이 달라질 수 있습니다. 앱 소개 문구나 화면 안내 문장 하나로 사용 목적이 다르게 읽히기도 합니다. 진단이나 치료에 가까운 기능이 기획에 들어 있다면 개발 시작 전에 식약처 자료와 전문가 확인을 거쳐 범위를 정해 두는 게 좋습니다. 의료기기로 가면 허가 절차와 품질 관리 요구가 붙어 일정과 개발 방식 자체가 달라지기 때문입니다.
애플도 App Store 심사 지침 1.4.1에서 진단이나 치료에 쓰일 수 있는 의료 앱은 더 엄격하게 심사할 수 있고, 측정 정확도를 주장하려면 데이터와 방법을 공개해야 한다고 안내합니다. 기기 센서만으로 혈압이나 혈당을 잰다고 하는 앱은 허용하지 않는다는 예시도 들어 있습니다.
HealthKit과 헬스 커넥트를 쓸 때
iOS의 HealthKit이나 안드로이드의 헬스 커넥트(Health Connect)에서 걸음 수, 심박수, 수면 같은 데이터를 가져오는 경우 스토어 정책이 하나 더 붙습니다.
애플 심사 지침 5.1.3은 HealthKit 등을 통해 얻은 건강 데이터를 광고, 마케팅 등의 목적으로 쓰거나 제3자에게 넘기지 못하게 하고, 건강 관리 개선이나 건강 연구 목적이라도 사용자 허락을 받은 경우로 제한합니다. 개인 건강정보를 iCloud에 저장하지 말라는 내용과, 앱이 수집하는 건강 데이터를 구체적으로 밝혀야 한다는 내용도 있습니다.
구글 플레이는 헬스 커넥트로 읽는 데이터를 개인적이고 민감한 사용자 데이터로 보고 사용자 데이터 정책을 적용합니다. Play Console의 앱 콘텐츠 페이지에서 건강 앱 신고 양식을 작성해 어떤 데이터 유형을 왜 쓰는지 밝혀야 하고, 핵심 기능에 필요 없는 권한은 요청하지 말아야 합니다. 나중에 데이터 유형을 추가하거나 빼면 양식을 다시 작성해야 한다는 점도 일정에 넣어 두세요.
스토어 개인정보 항목은 실제 동작과 맞아야 합니다
애플 App Store Connect의 앱 개인정보 보호 항목과 구글 플레이의 데이터 보안 섹션에는 앱이 수집하는 데이터를 신고해야 합니다. 두 곳 모두 건강 정보를 별도 데이터 유형으로 두고 있고, 앱에 넣은 외부 SDK가 수집하는 데이터까지 포함해야 한다고 안내합니다. 구글은 신고 내용의 정확성은 개발자 책임이며, 실제와 다르면 업데이트 제한이나 앱 삭제 같은 조치가 있을 수 있다고 밝히고 있습니다.
- SDK 목록과 각 SDK가 보내는 데이터
- 개인정보 처리방침 내용
- App Store 앱 개인정보 보호 항목
- 구글 플레이 데이터 보안 섹션
- 앱 안 동의 화면 문구
- SDK 추가 때 신고 항목 갱신
그래서 저희는 출시 전에 SDK 목록과 각 SDK가 보내는 데이터를 표로 정리하고, 개인정보 처리방침, 스토어 신고 항목, 앱 안의 동의 화면이 같은 내용을 말하는지 한 번에 대조합니다. 셋 중 하나만 바뀌어도 나머지를 같이 고쳐야 하는데, 업데이트하면서 분석 SDK 하나를 추가하고 신고 항목은 그대로 두는 경우가 흔합니다.
자주 묻는 질문
걸음 수나 수면 시간도 건강정보로 봐야 하나요?
서비스 성격과 다른 정보와의 결합 여부에 따라 판단이 달라질 수 있습니다. 애매하다면 민감정보에 준해 별도 동의를 받고 보호 조치를 적용하는 쪽이 안전합니다. 구체적인 판단은 법률 전문가와 확인하시길 권합니다.
해외 클라우드를 쓰면 안 되나요?
쓸 수는 있지만 국외이전 요건을 갖춰야 합니다. 같은 클라우드 업체라도 국내 리전을 고르면 이 문제를 단순하게 만들 수 있어서, 헬스케어 앱은 대부분 국내 리전으로 시작합니다.
처음엔 웰니스 앱으로 출시하고 나중에 기능을 넓혀도 되나요?
가능하지만 기능이 진단이나 치료 쪽으로 넓어지는 시점에 의료기기 해당 여부를 다시 확인해야 합니다. 데이터 구조와 기록 관리 방식을 처음부터 여유 있게 잡아 두면 그때 다시 만드는 범위가 줄어듭니다.
개인정보 처리방침은 언제 준비해야 하나요?
수집 항목이 확정되는 기획 단계에서 초안을 만드는 걸 권합니다. 스토어 심사에 처리방침 링크가 필요하고, 동의 화면 문구와 스토어 신고 항목도 이 내용을 기준으로 맞춰야 하기 때문입니다.
헬스케어 앱의 데이터 구조와 보안 설계를 함께 검토하고 싶으시면 상담으로 문의해 주세요. 저희가 해 온 헬스케어 앱 개발은 헬스케어 앱 개발 페이지에서 보실 수 있습니다.
기획부터 출시까지, 모바일파트너스가 함께합니다
2026년 8월 31일부터 구글 플레이 신규 앱과 업데이트는 Android 16(API 36)을 타깃으로 해야 합니다. 엣지 투 엣지, 뒤로 가기, 큰 화면 회전 규칙 등 실제로 손봐야 할 부분과 점검 순서를 정리했습니다.
바이브 코딩은 팀 상황에 따라 쓰는 범위가 달라집니다. 새 서비스, 기존 서비스, 기획자 프로토타입별로 어디에 쓰면 좋고 무엇을 막아야 하는지 실무 기준으로 정리했습니다.
기존 앱에 LLM 기반 AI 챗봇을 붙일 때 효과가 있는 곳과 없는 곳, 서버 구조, 회사 문서 연결(RAG), 틀린 답변 대응, 개인정보, AI 기본법 고지 의무, 스토어 정책까지 실무 순서로 정리했습니다.