앱 MVP Android 스크린샷 감지: 신호·화면 범위·차단 정책을 나누는 5가지 기준
앱 MVP Android 스크린샷 감지: 신호·화면 범위·차단 정책을 나누는 5가지 기준
Android 앱 MVP에서 스크린샷을 감지하고 싶을 때 가장 먼저 정할 일은 “캡처를 막을 것인가, 알림 신호만 받을 것인가, 아무 동작도 하지 않을 것인가”입니다. Android 14의 스크린샷 감지 API는 보이는 Activity에서 사용자가 특정 하드웨어 버튼 조합으로 스크린샷을 찍은 사실을 알려 줄 수 있습니다. 그러나 캡처 이미지 자체를 앱에 전달하지 않으며, ADB 명령이나 instrumentation 테스트의 스크린샷까지 감지하는 API도 아닙니다(C001).
따라서 이 기능을 화면 유출의 완전한 증거, 사용자의 의도 판정, 모든 캡처 경로의 차단으로 읽으면 안 됩니다. 민감한 화면을 어떻게 보호할지, 사용자에게 어떤 안내를 할지, 수신한 신호를 어떤 범위에서 기록할지, 지원 OS 밖에서는 무엇을 할지를 각각 나누어야 합니다. 이 글은 스크린샷 감지가 전환이나 보안을 보장한다고 주장하지 않습니다. MVP의 기능 범위와 QA 근거를 구분하는 기준입니다.
먼저 구분할 것: 감지 신호, 캡처 이미지, 캡처 차단은 다른 기능입니다
Android 14(API 34)는 Activity별 스크린샷 감지 콜백을 제공합니다. 해당 Activity가 보이는 동안 사용자가 스크린샷을 찍으면 콜백이 호출되고 시스템은 사용자에게 알림을 보여 줍니다(C001). 이때 앱이 받는 것은 “그 화면에서 감지 신호가 발생했다”는 사실이지, 실제 이미지 파일이나 그 이미지의 전송 대상이 아닙니다.
반대로 `FLAG_SECURE`는 창의 내용을 스크린샷과 비보안 디스플레이에 보이지 않게 하도록 설정하는 별도 제어입니다(C001). 감지 콜백과 `FLAG_SECURE`를 동시에 넣었다고 해도, 어느 화면에서 어떤 OS·기기 조합을 실제로 검증했는지는 별도로 남겨야 합니다. API 참조는 `FLAG_SECURE`가 설정된 Activity에서는 `onScreenCaptured()`가 호출되지 않는다고 명시합니다(C002).
구분 | MVP에서 답할 질문 | 완료로 단정하면 안 되는 것 |
|---|---|---|
감지 | 어떤 Activity에서 하드웨어 스크린샷 신호를 받을 것인가 | 모든 화면 캡처를 관찰했다는 주장 |
화면 내용 | 신호 시점에 어떤 상태가 화면에 있었는가 | API가 이미지 원본을 전달한다는 가정 |
차단 | 정말 캡처를 제한해야 하는 민감 화면은 무엇인가 | 감지 콜백만으로 유출을 막았다는 결론 |
사용자 안내 | 시스템 알림과 앱 안내를 어떻게 맥락화할 것인가 | 사용자가 악의적으로 캡처했다는 해석 |
검수 | 어떤 기기·OS·조작에서 신호를 확인했는가 | ADB·자동화 캡처도 감지된다는 가정 |
기준 1: 먼저 화면을 분류하고, 감지 목적을 한 문장으로 남깁니다
모든 화면에 감지를 넣는다고 제품 판단이 선명해지지는 않습니다. 예를 들어 일회성 인증 코드, 상담 대화, 결제 확인처럼 별도의 보호 판단이 필요한 화면과 일반 콘텐츠 화면은 다른 기준을 가질 수 있습니다. Android는 감지 사용 시 사용자에게 시스템 알림이 표시되므로, 감지를 시작하는 화면에서 맥락을 미리 알리는 방안을 고려하라고 안내합니다(C001).
MVP 기록은 “스크린샷 감지 추가”보다 구체적이어야 합니다. 예를 들어 ‘이번 버전은 1:1 상담 대화 Activity에서만 사용자가 하드웨어 버튼으로 캡처한 신호를 받아, 대화 상대에게 알릴지 검토할 내부 이벤트를 남긴다. 화면 이미지는 저장하지 않으며, 신호만으로 상대방에게 자동 제재하지 않는다’처럼 범위와 하지 않는 일을 함께 적습니다.
이 문장은 성과 약속이 아닙니다. 사용자에게 표시되는 시스템 알림, 앱의 추가 문구, 신호를 받은 뒤 서버 전송 여부, 보존 기간과 접근 주체는 개인정보·운영 정책에 맞춰 별도로 결정해야 한다는 출발점입니다.
기준 2: 감지 콜백의 범위와 생명주기를 분리해 구현·검수합니다
공식 안내에 따르면 `DETECT_SCREEN_CAPTURE` 설치 시 권한을 선언하고, 감지를 원하는 각 Activity에서 콜백을 준비합니다(C001). Activity가 시작될 때 등록하고 멈출 때 해제하는 흐름이 예시로 제시됩니다. 즉 앱 프로세스가 살아 있다는 사실만으로 모든 화면의 감지를 기대하면 안 됩니다.
신호는 보이는 Activity와 연결해 기록해야 합니다. 같은 사용자가 화면을 전환한 직후라면 어떤 화면이 보였는지, 등록이 살아 있었는지, 앱이 정상 상태였는지를 확인하지 않고 ‘민감 화면이 캡처됐다’고 단정하기 어렵습니다. 콜백은 이미지 원본을 주지 않으므로, 화면 내용을 별도 수집하라는 의미도 아닙니다(C001).
Android 14에서 이 API는 특정 하드웨어 버튼 조합으로 실행한 스크린샷만 감지합니다. ADB 스크린샷 명령이나 instrumentation 테스트가 현재 화면을 캡처한 경우에는 감지하지 않는다고 문서에 적혀 있습니다(C001). 자동화 QA가 콜백을 받지 못했다면 곧바로 등록 실패로 결론 내리지 말고, 실제 지원 기기에서 사용자가 수행하는 조작과 테스트 조작을 구분하세요.
우리 앱 MVP의 민감 화면·감지 범위·QA 기준 점검하기
기준 3: 감지와 차단 중 무엇이 필요한지 화면별로 결정합니다
감지는 사후 신호입니다. 화면을 아예 캡처·비보안 디스플레이에 보이지 않게 해야 한다면 `FLAG_SECURE`처럼 별도 기능을 검토해야 합니다(C001). 그 판단은 ‘스크린샷이 싫다’는 일반 문장이 아니라, 해당 화면의 데이터 성격·사용자 업무·고객지원 대안·접근성 영향·운영 책임을 근거로 해야 합니다.
두 기능을 섞으면 QA도 흐려집니다. 감지 Activity에서는 하드웨어 캡처 때 시스템 안내와 앱의 후속 처리가 기대대로 동작하는지 확인합니다. `FLAG_SECURE` 화면에서는 콜백이 오지 않을 수 있다는 API 제약을 전제로, 실제로 제한이 필요한 화면에서 화면 보호와 사용자의 대체 행동이 함께 동작하는지 확인합니다(C002).
특히 감지 이벤트를 근거로 계정 잠금, 결제 보류, 대화 상대 알림을 자동 실행하려면 별도의 정책·오탐 처리·지원 경로가 필요합니다. 이 글의 공식 근거만으로 그러한 제재 정책이 적법하거나 적절하다고 말할 수는 없습니다. MVP에서는 먼저 신호 수집 여부와 사용자가 볼 안내를 좁게 검토하고, 실제 운영 결정은 별도 검토 기록으로 분리하는 편이 안전합니다.
기준 4: 사용자 안내와 기록 최소화를 한 묶음으로 검토합니다
스크린샷 감지 기능은 신호마다 시스템 안내가 보일 수 있습니다(C001). 사용자는 왜 그런 안내가 떴는지, 앱이 무엇을 처리하는지 궁금할 수 있습니다. 감지를 쓰는 화면이라면 화면 진입 전·후에 “이 화면의 스크린샷 감지 기능과 목적”을 이해할 수 있는 짧고 사실적인 문구를 두는지 검토하세요.
기록 항목도 최소화해야 합니다. 제품이 정말 필요로 하는 것이 감지 시각·화면 종류·앱 버전·처리 결과라면, 실제 화면 이미지·클립보드·무관한 계정 속성을 함께 수집할 이유가 있는지 따져야 합니다. 앱이 이미지 원본을 받지 않는 API라는 공식 제약(C001)은 오히려 기록 범위를 줄이는 설계 출발점이 될 수 있습니다.
기록을 서버로 보내는 경우에는 전송 성공, 저장 성공, 운영자가 열람 가능하다는 상태를 같은 완료 신호로 묶지 마세요. 네트워크 실패·중복 수신·사용자 탈퇴·보존 기한 만료 상황을 각각 정의하고, 사용자에게 고지한 범위와 실제 처리 경로가 맞는지 검수합니다.
관련 글 앱 MVP 민감 화면 보호: 캡처·앱 전환 화면을 나누는 기준은 민감 정보가 보이는 화면의 보호 판단을 다룹니다. 이번 글은 Android 14에서 감지 가능한 신호의 범위, 감지되지 않는 테스트 경로, 감지와 차단을 함께 넣었을 때의 QA 경계에 초점을 둡니다.
기준 5: 실제 기기 QA는 감지된 경우와 감지되지 않는 경우를 함께 남깁니다
출시 전에는 최소한 지원 OS 범위와 Activity별 등록 상태를 확인하세요. API 참조상 `Activity.ScreenCaptureCallback`은 API 34에 추가됐습니다(C002). 지원 OS보다 낮은 기기에서 어떤 화면 경험을 제공할지, 감지를 쓸 수 없는 상태를 오류처럼 보이게 할지 여부도 제품 범위에 포함됩니다.
실제 기기 QA 기록은 ‘스크린샷 성공’ 한 줄보다 다음처럼 분리하는 편이 재현에 도움이 됩니다.
Android 14 이상 지원 기기에서 대상 Activity가 보일 때 하드웨어 버튼 조합으로 캡처하고, 시스템 안내·앱 후속 처리·기록 결과를 분리해 확인합니다.
Activity를 백그라운드로 보내거나 다른 화면으로 전환한 뒤 같은 조작을 수행해, 대상 화면 외의 신호를 대상 화면 이벤트로 읽지 않는지 확인합니다.
`FLAG_SECURE`를 적용한 화면은 콜백이 호출되지 않을 수 있다는 제약을 포함해, 보호 목적과 대체 안내를 별도 확인합니다.
ADB·instrumentation 캡처가 감지되지 않은 경우에는 문서의 테스트 한계와 일치하는지 기록하고, 감지 기능 자체의 실패로 오판하지 않습니다.
OS 버전, 기기 모델, 앱 버전, 화면 경로, 실제 조작, 관찰 결과와 알려진 한계를 남겨 다음 릴리스의 적용 범위를 판단합니다.
이 기록은 모든 유출·캡처·보안 사고를 막았다는 증거가 아닙니다. 어떤 화면에서 어떤 방식의 신호를 관찰했고, 무엇을 관찰하지 않았는지 밝히는 MVP QA 근거입니다.
출시 전 스크린샷 감지·차단·사용자 안내 경계 정리하기
자주 묻는 질문
스크린샷 감지 콜백으로 캡처 이미지도 받을 수 있나요?
아닙니다. Android 14의 스크린샷 감지 API는 감지 신호를 주지만 실제 스크린샷 이미지를 제공하지 않습니다. 신호 시점의 화면 범위를 앱이 정할 수는 있어도, 이미지 원본을 API가 전달한다고 가정하면 안 됩니다.
ADB나 자동화 테스트로 찍은 스크린샷도 감지되나요?
그렇게 단정할 수 없습니다. Android Developers는 Android 14의 시스템 API가 특정 하드웨어 버튼 조합의 스크린샷만 감지하며, ADB와 instrumentation 테스트의 스크린샷은 감지하지 않는다고 안내합니다. 실제 기기 사용자 조작과 자동화 캡처를 나눠 검수하세요.
감지 API만 넣으면 민감 화면의 캡처를 막을 수 있나요?
아닙니다. 감지는 사후 신호이고 차단은 다른 판단입니다. 화면을 스크린샷과 비보안 디스플레이에 표시하지 않으려면 `FLAG_SECURE` 같은 별도 제어를 검토해야 합니다. 적용 화면과 사용자 대체 경로는 실제 기기에서 따로 확인하세요.
FLAG_SECURE를 적용한 화면에서 감지 콜백이 오지 않으면 오류인가요?
자동으로 오류라고 볼 수 없습니다. Android API 참조는 `FLAG_SECURE`가 설정된 Activity에서는 `onScreenCaptured()`가 호출되지 않는다고 설명합니다. 감지와 차단을 함께 적용한 화면은 이 제약을 QA 기준에 포함하세요.
공식 출처
Android Developers: Detect when users take device screenshots — 2026-09-23 직접 확인
Android Developers: Activity.ScreenCaptureCallback API reference — 2026-09-23 직접 확인
발행일: 2026-09-23 · 작성: 유인어스 정책자금·정부지원사업 인사이트