앱 MVP 민감정보 저장: 기기 보안 저장소·잠금·복구를 나누는 5가지 기준
앱 MVP 민감정보 저장: 기기 보안 저장소·잠금·복구를 나누는 5가지 기준
앱 MVP에서 로그인 토큰이나 암호화 키를 저장한다는 말은 간단하지만, 실제로는 “어떤 데이터를 남길지”, “잠긴 기기에서도 필요한지”, “기기 변경 때 무엇을 되살릴지”를 한꺼번에 결정하는 일입니다. 이 판단을 하나로 뭉치면 편의 기능을 위해 민감한 값을 오래 남기거나, 반대로 정상적인 재로그인도 오류처럼 보이게 만들 수 있습니다.
먼저 답하면, 앱 MVP의 보안 저장소는 짧은 비밀값과 암호화 키를 플랫폼의 보안 저장소에 두되, 데이터 종류·접근 조건·키 수명·백업 경계·복구 경로를 따로 정하는 방식이 좋습니다. Android는 Keystore 키 재료를 앱 프로세스나 기기 밖으로 추출하기 어렵게 하고 용도·사용자 인증 같은 사용 제한을 지정할 수 있다고 설명합니다. Apple은 Keychain을 작은 비밀 데이터를 암호화된 데이터베이스에 저장하는 API로 설명하며, 항목별 접근 가능 시점을 정할 수 있게 합니다.
이 글은 앱 안의 민감 정보 저장 경계에 한정합니다. 로그인 방식 자체는 로그인 수단 선택 기준, 세션 종료 시점은 로그인 유지와 세션 만료 기준, 개인정보가 로그에 남지 않게 하는 범위는 오류 로그 마스킹 기준에서 별도로 점검하세요. 아래 기준이 침해 방지, 심사 통과, 데이터 복구를 보장하지는 않습니다.
기준 1: 보안 저장소에 넣을 값을 먼저 좁힙니다
기기 보안 저장소는 모든 앱 데이터를 넣는 일반 데이터베이스가 아닙니다. Apple은 Keychain을 비밀번호·암호화 키·인증서처럼 작고 민감한 데이터를 저장하는 용도로 설명합니다. Android Keystore도 키 재료를 보호하고 암호화·서명 같은 연산에 쓰기 위한 시스템입니다.
따라서 MVP 문서에서 데이터는 세 칸으로 나눠 보세요. 첫째, 재인증 토큰·키처럼 짧고 비밀인 값입니다. 둘째, 사용자가 다시 내려받아도 되는 화면 캐시·목록·이미지입니다. 셋째, 계약·주문·권한처럼 서버가 최종 상태를 갖고 있어야 하는 업무 기록입니다. 첫째만 보안 저장소 후보로 두고, 둘째와 셋째는 보안 저장소에 통째로 복제하지 않는 기준을 먼저 세우면 저장량과 복구 책임이 섞이지 않습니다.
“암호화했으니 민감 정보 전체를 기기에 보관해도 된다”는 결론도 피하세요. 저장 여부는 데이터 최소화, 오프라인 필요성, 탈취 시 영향, 서버 재검증 가능성을 함께 따져야 합니다. 특히 서비스의 최종 권한·거래 상태는 앱의 로컬 값만 보고 확정하지 말고 서버 상태를 다시 확인하는 흐름을 남기세요.
기준 2: 잠금 상태와 사용자 인증을 기능별로 정합니다
기기 잠금과 앱의 로그인 상태는 같은 말이 아닙니다. Apple은 Keychain 항목마다 기기 상태와 사용자 입력을 조합해 접근 가능 조건을 정할 수 있다고 안내합니다. 예를 들어 기기가 잠긴 동안에는 접근할 수 없는 기본 동작, 암호가 설정된 기기에서만 접근하도록 더 제한하는 선택, 백그라운드 작업을 위해 잠긴 상태에서도 접근해야 하는 선택은 서로 다른 제품 결정입니다.
Android Keystore도 키 생성·가져오기 때 인증된 사용자가 최근에 인증했는지, 특정 암호 연산마다 인증할지 같은 제한을 설정할 수 있다고 설명합니다. 이 기능은 모든 화면에 생체인증을 붙이라는 뜻이 아닙니다. 결제 승인, 민감 문서 열기, 기기 내 복구 키 사용처럼 다시 확인할 이유가 있는 행동만 후보로 두고, 알림 수신이나 정상적인 동기화처럼 잠긴 상태에서도 해야 하는 작업과 분리하세요.
기획서에는 “보안 강화” 대신 다음처럼 적는 편이 검수에 도움이 됩니다. “화면 잠금 해제 뒤에만 재인증 토큰을 읽는다”, “백그라운드 동기화는 비밀값 원문을 읽지 않고 서버가 발급한 제한된 작업 권한만 쓴다”, “인증이 없으면 상세 화면 대신 재로그인 안내를 보인다.” 실제 지원 여부와 인증 방식은 대상 OS·기기·앱의 위협 모델에 맞춰 확인해야 합니다.
기준 3: 키의 용도와 무효화 뒤 행동을 한 묶음으로 설계합니다
Android Keystore는 키를 만들거나 가져온 뒤 허용한 암호 알고리즘·연산 목적·블록 모드·다이제스트, 시간 범위, 사용자 인증 같은 사용 권한을 강제할 수 있다고 설명합니다. 그리고 이런 권한은 만든 뒤 바꿀 수 없습니다. 그러므로 “키 하나를 저장했다”에서 끝내지 말고, 어떤 데이터 암호화용인지, 서명용인지, 다른 용도로 재사용하지 않는지와 별칭·생성 시점·교체 조건을 함께 기록하세요.
생체인증에만 의존하는 키는 등록 정보가 바뀌었을 때 기본적으로 무효화될 수 있습니다. Android 문서는 새 생체인증 등록 뒤 유효 상태를 별도로 구성할 수 있다고 안내합니다. 이때 중요한 것은 어떤 설정값을 고를지가 아니라, 무효화가 일어났을 때 앱이 무엇을 할지입니다. “키를 다시 만들고 서버에서 권한을 재확인한다”, “사용자에게 다시 로그인하도록 안내한다”, “기존 로컬 암호문을 복구 대상으로 보지 않는다” 중 해당 서비스의 실제 경로를 정하세요.
더 높은 하드웨어 격리를 제공할 수 있는 Android StrongBox도 모든 기기·알고리즘에서 같은 방식으로 쓸 수 있는 전제가 아닙니다. Android는 StrongBox가 더 느리고 지원 범위가 제한될 수 있어 대부분의 앱에 필수는 아니라고 설명합니다. 따라서 ‘지원 기기에서만 선호하고, 불가하면 별도 키를 생성하거나 기능을 제한한다’처럼 실패 경로를 QA 항목에 넣는 편이 안전합니다.
기준 4: 백업·기기 변경과 ‘이 기기만’의 경계를 분리합니다
기기 변경 뒤 로그인이 유지되는 경험과, 비밀값을 다른 기기로 옮기지 않는 선택은 서로 다른 목표입니다. Apple Platform Security 문서는 Keychain 보호 클래스 중 일부에 ‘이 기기만’에 해당하는 대응 항목이 있으며, 백업에서 다른 기기로 복원될 때 기기 고유 키로 인해 쓸 수 없게 된다고 설명합니다. 즉, 어떤 값이 새 기기에서도 필요하다고 해서 로컬 비밀값 자체를 백업에 포함해야 한다는 뜻은 아닙니다.
MVP에서는 값마다 세 가지를 써 보세요. ‘같은 기기 재설치 뒤에도 필요한가’, ‘새 기기에서도 이어져야 하는가’, ‘서버에서 다시 발급하거나 검증할 수 있는가’입니다. 재인증이나 서버 재발급으로 충분한 값은 기기 한정으로 두고, 새 기기에서 이어져야 하는 업무 상태는 서버 계정 상태로 복구하는 편이 이해하기 쉽습니다. 개발 편의를 위해 키·토큰을 설정 파일, 앱 번들, 분석 이벤트, 고객지원 캡처에 복사하는 흐름은 이 글의 범위에서 제외하세요.
기준 5: ‘읽지 못함’을 오류가 아닌 복구 상태로 다룹니다
보안 저장소 접근 실패는 네트워크 오류와 다르게 다뤄야 합니다. 기기가 잠겨 있을 수 있고, 사용자가 인증하지 않았을 수 있으며, 생체인증 변경으로 키가 무효화됐을 수 있고, 재설치·기기 변경으로 로컬 항목이 없을 수 있습니다. 네 경우를 모두 “알 수 없는 오류”로 보이면 고객은 반복 시도만 하게 됩니다.
출시 전에는 정상 읽기 외에 잠긴 기기, 인증 취소, 생체정보 변경, 지원되지 않는 하드웨어 보안 기능, 앱 재설치, 백업 복원, 새 기기 로그인 장면을 확인하세요. 각 장면에서 보여 줄 안내, 다시 인증할 계정, 서버 확인 뒤 재발급할 값, 제거할 오래된 암호문을 한 표로 남기면 개발·고객지원·QA가 같은 복구 흐름을 볼 수 있습니다.
판단 칸 | 먼저 정할 질문 | 확인할 증거 |
|---|---|---|
데이터 | 정말 짧은 비밀값·키만 남기는가? | 저장 대상 분류와 서버 최종 상태 |
접근 | 잠김·백그라운드·재인증 때 각각 읽어도 되는가? | 기기 잠금·인증 상태별 실제 결과 |
키 수명 | 용도·별칭·교체·무효화 뒤 행동이 있는가? | 키 정책과 재발급·재로그인 결과 |
이전 | 새 기기로 가져갈 값과 서버에서 복구할 값을 구분했는가? | 재설치·백업·기기 변경 시나리오 |
복구 | 접근 불가를 어떤 안내와 안전한 다음 행동으로 바꾸는가? | 실패 화면과 서버 재검증 기록 |
출시 전 5분 점검표
기기 보안 저장소에 넣는 값이 비밀값·키처럼 작고 필요한 값으로 한정됐는가?
잠긴 기기·백그라운드 작업·재인증이 필요한 행동을 기능별로 나눴는가?
각 키의 사용 목적, 교체 조건, 생체정보 변경 등 무효화 뒤 행동을 정했는가?
백업·재설치·새 기기에서 로컬 비밀값과 서버 계정 상태의 복구 경계를 구분했는가?
접근 실패 때 재시도만 시키지 않고 재로그인·서버 확인·안전한 초기화의 다음 행동을 안내하는가?
민감 정보를 다루는 MVP의 핵심은 더 많은 값을 기기에 남기는 것이 아니라, 무엇을 남기지 않을지와 읽지 못했을 때 어디서 다시 확인할지를 정하는 데 있습니다. 유인어스는 민간 사업 지원 서비스이며, 이 글은 특정 저장 방식의 보안성, 침해 방지, 앱 심사 통과를 보장하지 않습니다. 실제 구현 전에는 최신 플랫폼 문서와 서비스의 데이터 분류·위협 모델·서버 권한 정책을 함께 검토하세요.
자주 묻는 질문
Keychain이나 Android Keystore에 앱 데이터 전체를 넣어도 되나요?
권하지 않습니다. Apple은 Keychain을 비밀번호·키 같은 작은 민감 데이터 저장소로, Android는 Keystore를 키 재료와 암호 연산 보호 체계로 설명합니다. 일반 캐시·대용량 데이터·서버가 최종 상태여야 하는 업무 기록은 별도 저장·서버 검증 정책으로 나누세요.
잠긴 기기에서도 토큰을 읽게 하면 안 되나요?
필요한 기능에 따라 다릅니다. Apple은 항목별 접근 가능 시점을 조절할 수 있다고 설명하고, Android도 키 사용에 사용자 인증 조건을 둘 수 있다고 안내합니다. 잠긴 상태에서 꼭 필요한 백그라운드 작업인지, 비밀값 원문 접근이 필요한지, 재인증을 요구해도 되는지부터 정하세요.
생체인증을 새로 등록하면 왜 다시 로그인할 수 있나요?
Android Keystore에서 생체인증에만 의존하는 키는 새 생체정보 등록 때 기본적으로 무효화될 수 있습니다. 앱은 그 상태를 감지했을 때 서버 재확인·새 키 생성·재로그인 중 실제 복구 경로를 제공해야 합니다.
기기 변경 뒤에도 로그인을 유지하려면 토큰을 백업해야 하나요?
반드시 그렇지는 않습니다. Apple은 일부 Keychain 보호 클래스의 ‘이 기기만’ 대응 항목이 다른 기기로 복원될 때 쓸 수 없도록 설계된다고 설명합니다. 새 기기에서 필요한 경험은 서버 계정 확인·재발급으로 복구할지, 로컬 값 이전이 필요한지 데이터별로 따로 결정하세요.
확인한 공식 출처
- Android Developers · Android Keystore system — 2026-09-19 확인
- Android Developers · Cryptography — 2026-09-19 확인
- Apple Developer · Keychain services — 2026-09-19 확인
- Apple Developer · Restricting keychain item accessibility — 2026-09-19 확인
- Apple Platform Security · Keychain data protection — 2026-09-19 확인