.svg)
AI 솔루션 문의하기
모바일 브라우저에서는 열리던 카메라가 앱 안에서 열리지 않거나, 같은 기기로 찍어도 글자가 흐리게 전달되는 경우가 있습니다. 인앱 웹뷰 신분증 촬영 OCR을 도입할 때는 인식 엔진뿐 아니라 카메라를 호출하는 환경과 이미지 전달 경로를 함께 살펴봐야 합니다.
네이티브 앱은 운영체제의 카메라 API로 촬영 기능을 구현합니다. 모바일 웹은 브라우저가 제공하는 API와 사이트 권한 정책을 따릅니다. 인앱 웹뷰는 웹 페이지를 앱 안에 띄우므로 앱의 권한 상태와 웹 콘텐츠의 카메라 접근 처리가 함께 영향을 줍니다. 같은 웹 페이지라도 이를 감싸는 앱의 구현에 따라 결과가 달라질 수 있습니다.
먼저 실시간 카메라 미리보기를 사용하는지, 파일 입력으로 카메라나 사진 선택 화면을 여는지 구분해야 합니다. 두 방식은 권한 요청과 결과 반환 경로가 다릅니다. 실시간 촬영은 getUserMedia()를 기준으로 확인하고, 파일 입력 방식은 별도의 파일 선택 처리까지 점검하는 것이 출발점입니다.
Android 앱에서는 AndroidManifest.xml의 CAMERA 선언과 런타임 권한 상태를 확인해야 합니다. 앱에 권한이 있어도 웹 콘텐츠의 요청이 자동 승인되는 것은 아닙니다. Android 공식 WebChromeClient 문서에 따르면 onPermissionRequest()를 재정의하지 않으면 해당 요청은 거부됩니다.
구현 시에는 요청 출처와 리소스를 확인한 뒤 필요한 범위만 승인하도록 설계합니다. 신분증 사진만 촬영한다면 영상 캡처 리소스를 기준으로 처리하고, 불필요한 마이크 권한까지 함께 요구하지 않는 구성이 적절합니다. 요청받은 리소스를 전부 승인하는 방식보다 허용한 도메인과 기능을 명시적으로 대조하는 편이 안전합니다.
앱 권한을 거부한 상태, 웹 요청이 취소된 상태도 구분해야 합니다. 권한 창을 닫았는데 로딩만 계속되거나, 설정에서 권한을 바꾼 뒤에도 카메라가 다시 열리지 않는 흐름이 없는지 확인합니다. 리소스 승인 방식은 Android PermissionRequest 공식 문서를 참고할 수 있습니다.
파일 입력 방식이라면 같은 WebChromeClient 문서의 onShowFileChooser() 처리도 확인합니다. 촬영 화면에서 돌아왔을 때 결과가 웹 페이지에 전달되는지, 취소한 요청이 남아 다음 촬영을 막지 않는지 점검해야 합니다. 다만 실물 촬영이 필요한 사본판별 흐름에서 사진 보관함 업로드를 무조건 대체 수단으로 열어 두는 것은 인증 정책과 맞지 않을 수 있습니다.
iOS에서는 Info.plist의 NSCameraUsageDescription에 카메라 사용 목적을 명시합니다. 이는 앱의 카메라 접근에 필요한 설명이며, 이 키를 추가했다고 모든 웹 페이지의 요청이 허용되는 것은 아닙니다.
지원 OS에서는 WKUIDelegate의 미디어 캡처 권한 요청 메서드를 통해 요청 출처·프레임·미디어 종류에 따른 정책을 정할 수 있습니다. Apple 문서상 이 메서드를 구현하지 않으면 기본값은 사용자에게 묻는 방식입니다. Android의 기본 거부 동작과 동일하게 설명하면 안 됩니다.
따라서 앱의 카메라 권한과 웹 콘텐츠의 요청 처리 결과를 따로 확인해야 합니다. 카메라가 열리지 않는 문제를 해결하려고 모든 출처를 무조건 승인하기보다, 실제 인증 페이지의 출처와 지원 OS에 맞춰 정책을 검토하는 것이 필요합니다.
웹 카메라 API는 보안 컨텍스트의 영향을 받으므로 운영 인증 페이지는 유효한 HTTPS 환경을 기준으로 구성해야 합니다. 시작 주소뿐 아니라 로그인 이후 이동한 촬영 페이지의 주소도 확인합니다. 개발용 로컬 환경에서 동작한 결과를 그대로 운영 웹뷰의 동작 보장으로 해석해서는 안 됩니다.
WebKit의 WebRTC 기술 설명도 카메라 접근의 보안 정책을 다룹니다. 인증 화면을 iframe 안에 넣었다면 상위 페이지의 카메라 허용 정책과 프레임 권한도 확인해야 합니다. 권한 문제를 해결하기 위해 인증서 오류를 무시하거나 보안 설정을 완화하는 방식은 피해야 합니다.
네이티브 앱에서 가능한 초점 제어가 웹뷰에서도 동일하게 제공되지는 않습니다. 지원 기능은 기기와 웹 엔진에 따라 달라지므로, 화면을 터치하면 항상 초점이 맞는다고 안내하기보다 실제 지원 여부와 촬영 결과를 확인해야 합니다. 초점이 안정되기 전에 자동 촬영되지 않도록 선명도와 흔들림을 함께 판단하는 설계가 필요합니다.
후면 카메라와 희망 해상도를 요청하더라도 실제 적용값은 달라질 수 있습니다. 구현 시에는 지원 범위 안에서 조건을 요청하고, 획득한 영상의 실제 크기를 확인합니다. 충족할 수 없는 해상도를 필수 조건으로 고정하면 카메라 시작 자체가 실패할 수 있어 조건을 완화하는 경로도 마련해야 합니다.
또한 미리보기의 표시 크기와 OCR에 전송하는 이미지 크기는 다릅니다. 고해상도 영상도 캔버스 추출·크기 조정·압축 단계에서 작은 이미지로 바뀔 수 있습니다. 카메라 입력부터 서버 전송까지 크기·회전·잘림·압축을 점검해야 합니다. 1080p나 일정한 촬영 거리 하나를 모든 기기의 충분조건으로 제시하기는 어렵습니다.
OCR은 신분증의 글자를 읽고, 사본판별은 종이 출력물이나 화면 재촬영 등의 특징을 판단합니다. OCR로 이름과 생년월일을 읽었다고 사본판별까지 통과한 것은 아닙니다. 두 기능을 함께 쓸 때는 글자와 신분증 표면의 특징을 모두 확인할 수 있는 입력 품질을 확보해야 합니다.
흑백 변환이나 강한 노이즈 제거를 일괄 적용하면 사본판별에 필요한 특징이 달라질 수 있습니다. 촬영 원본을 기준 입력으로 두고, OCR용 보정 이미지는 별도로 만드는 등 솔루션의 입력 규격에 맞춰 처리 경로를 정하는 것이 좋습니다. 원본을 기준으로 처리한다는 의미가 장기 보관을 뜻하지는 않습니다.
품질 미달과 사본 의심 결과도 구분해 안내해야 합니다. 다음은 서비스에서 적용할 수 있는 재촬영 문구 예시입니다.
이용자용 촬영 요령은 신분증 촬영 가이드라인을 참고할 수 있습니다. 일반적인 인증 실패 유형은 비대면 본인인증 실패 원인에서 확인하고, 개발 단계에서는 실패가 권한·촬영·전송·판별 중 어디에서 발생했는지 구분하는 데 집중해야 합니다.
알체라 eKYC는 알체라 신분증 OCR 인식률 98.47%·1초 이내, 신분증 사본판별 정확도 99%를 안내합니다. 이는 공개된 솔루션 성능 지표이며, 권한 승인과 업로드를 포함한 전체 인증이 모든 환경에서 1초 안에 끝난다는 의미는 아닙니다.
실제 연동에서는 OS·웹뷰 버전·기기를 나눠 첫 권한 요청, 거부 후 복귀, 카메라 재진입을 확인합니다. 촬영 이후에는 전송 이미지의 품질과 두 판별 결과가 올바르게 처리되는지 점검해야 합니다. 로그에는 단계별 오류와 처리 시간을 남기되 신분증 이미지나 번호가 불필요하게 기록되지 않도록 구성합니다. 도입 상담에서는 입력 이미지 규격과 지원 환경, 재촬영 기준을 함께 협의할 수 있습니다.
.png)
.svg)
.svg)
