.svg)
AI 솔루션 문의하기
신분증 진위확인 API SDK 차이는 신분증 촬영 화면을 누가 만드느냐에 있습니다. API는 서비스가 직접 만든 촬영 화면에서 받은 이미지를 서버로 보내 결과를 돌려받는 방식이고, SDK는 촬영 화면과 촬영 품질 확인 기능이 들어 있는 모듈을 서비스에 넣어 쓰는 방식입니다. 두 방식 모두 신분증 정보 읽기(OCR), 진위확인, 사본 판별을 쓸 수 있습니다. 다만 그 앞 단계인 촬영의 책임이 서비스와 솔루션 사이에서 다르게 나뉩니다.
신분증 진위확인의 기본 개념과 확인 항목은 신분증 진위확인 글에 정리해 두었습니다. 이 글은 개념 설명보다 어떤 방식을 고를지에 집중합니다.
촬영 화면 담당이 선택 기준이 되는 이유는 인식 성공률, 재촬영 비율, 사본 유입 경로가 모두 촬영 단계에서 정해지기 때문입니다. 서버에서 호출하는 API의 응답 속도보다 고객이 신분증을 어떻게 찍는지가 인증 결과에 더 크게 작용합니다.
신분증 OCR이 실패하는 원인은 대부분 촬영 이미지에 있습니다. 빛 반사로 글자가 하얗게 날아가거나, 손이 흔들려 초점이 맞지 않거나, 신분증 모서리가 화면 밖으로 잘린 경우입니다. 이런 이미지는 서버 쪽 처리 성능과 관계없이 읽히지 않습니다. 실패한 고객은 다시 촬영해야 하고, 재촬영이 반복되면 가입을 포기합니다. 촬영 단계에서 품질을 미리 걸러 주는 기능이 있으면 서버로 가는 이미지의 품질이 일정해집니다.
비대면 인증에는 실물 신분증이 아닌 종이 출력물 촬영 이미지, 화면 재촬영 이미지, 저장된 이미지 파일이 들어올 수 있습니다. 사본 판별은 서버에서 이미지를 분석해 처리하지만, 이미지가 들어오는 입구는 촬영 화면 설계가 정합니다. 서비스가 촬영 화면을 직접 만드는 API 방식에서는 카메라 촬영만 받도록 제한할지, 파일 업로드도 허용할지를 서비스가 결정합니다. 입구를 열어 둘수록 서버의 사본 판별이 맡아야 할 이미지가 다양해집니다.
촬영 화면을 직접 만들면 아래 항목이 서비스의 운영 범위로 들어옵니다.
인증 화면 자체가 서비스의 차별점이어서 화면 설계의 자유도가 필요하다면 API가 맞습니다. 인증이 가입 흐름의 한 단계일 뿐이고 촬영 품질을 빠르게 확보하는 것이 목표라면 SDK가 개발 부담을 줄여 줍니다.
환경별 선택 기준은 모바일 웹에서는 촬영 품질 확보, PC 웹에서는 신분증 촬영 경로 설계에 맞춰 정합니다. 같은 웹 서비스라도 사용자가 신분증을 찍는 환경이 달라 두 환경의 어려움이 서로 다릅니다.
모바일 웹은 고객이 후면 카메라로 신분증을 바로 찍을 수 있다는 장점이 있습니다. 반면 브라우저, 앱 안에서 열리는 인앱 브라우저, OS 버전에 따라 카메라 접근 방식과 해상도, 자동 초점 동작이 다릅니다. 같은 서비스에서도 기기에 따라 촬영 품질이 크게 달라질 수 있습니다. 이 편차를 서비스가 직접 흡수해야 한다면 자동 촬영과 품질 체크가 포함된 SDK가 유리한 경우가 많습니다. 서비스 고유의 촬영 화면이 필요하다면 API로 가되, 품질 체크를 어떻게 넣을지 함께 설계해야 합니다.
PC 웹캠은 해상도, 초점 거리, 카메라 위치 때문에 신분증 글자를 읽기 어렵고, 고객이 신분증을 카메라 앞에 맞춰 들고 있기도 불편합니다. 그래서 PC에서 가입을 시작하고 신분증 촬영 단계에서는 문자나 QR 링크로 휴대폰에 이어서 촬영하는 흐름을 설계하는 경우가 많습니다. 이 전환 흐름은 PC 화면과 휴대폰 화면의 세션을 연결하는 서비스 구조의 문제이므로, 전체 흐름을 직접 설계할 수 있는 API가 맞는 경우가 있습니다. 반대로 PC에서 얼굴만 촬영하는 흐름이라면 선택 기준이 달라집니다.
웹이 아니라 앱에서 가입 단계에 신분증 확인을 붙이는 경우는 환경이 다릅니다. 앱 환경의 API 연동은 앱 가입 신분증 확인 API 글에서 다뤘습니다.
솔루션마다 지원하는 브라우저와 환경이 다릅니다. 도입 전에 아래 항목을 문서로 확인합니다. 지원 범위를 확인하지 않고 도입하면 일부 고객 환경에서 촬영 화면이 열리지 않는 문제가 뒤늦게 드러납니다.
도입 기간은 SaaS 연동이면 30분, 개발을 포함하면 평균 1~3개월로 구분해서 봐야 합니다. 같은 신분증 진위확인이라도 서비스에 붙이는 방식에 따라 서비스 쪽에서 해야 할 개발 범위가 크게 다릅니다.
평균 1~3개월은 서비스 구조에 따라 달라집니다. 기간을 가르는 요인은 다음과 같습니다.
일정이 급하고 인증 화면의 자유도가 필요하지 않다면 SaaS 연동으로 먼저 시작할 수 있습니다. 촬영 품질을 확보하면서 서비스 화면 안에 넣어야 한다면 SDK, 촬영 화면과 전체 흐름을 직접 설계해야 한다면 API로 갑니다. 서비스 구조가 정해지기 전에는 개발 범위를 추정하기 어려우므로, 계약 전에 서비스 쪽에서 맡을 범위를 문서로 나눠 두는 것이 일정 판단에 도움이 됩니다.
도입 전 검증은 실제 촬영 환경에서의 인식 결과, 환경별 동작, 실패 처리 흐름을 소규모로 먼저 확인하는 방식으로 진행합니다. 사내 테스트 기기에서 잘 되는 것과 고객 환경에서 잘 되는 것은 다릅니다.
테스트 기기를 사내에서 쓰는 몇 대로 한정하지 않습니다. 고객이 많이 쓰는 기기와 브라우저, 인앱 브라우저를 목록으로 만들어 그 환경에서 촬영합니다. 조명이 어두운 곳, 빛이 반사되는 곳, 오래되어 코팅이 벗겨진 신분증처럼 인식이 어려운 조건을 일부러 포함합니다.
종이 출력물을 촬영한 이미지와 화면에 띄운 신분증을 다시 촬영한 이미지를 넣어, 사본 판별이 걸러내는지 확인합니다. 촬영 화면에서 파일 업로드 경로를 열어 두었다면 저장된 이미지로도 시도해 봅니다. 사본 판정이 나왔을 때 고객에게 보이는 안내 화면도 함께 점검합니다.
인식 실패, 사본 판정, 카메라 권한 거부가 났을 때 고객이 어디로 가는지 확인합니다. 실패 사유를 구체적으로 보여주는지, 재시도 상한을 넘으면 다른 확인 수단이나 고객센터로 이어지는지 점검합니다. 실패 화면에서 흐름이 끝나면 고객은 가입을 포기합니다.
일부 고객 구간이나 일부 환경에만 먼저 적용해 인식 결과와 실패 사유를 확인한 뒤, 모바일 웹, PC 웹, 앱 순으로 넓혀 갑니다. 한 번에 모든 환경에 적용하면 문제가 생겼을 때 원인이 촬영 단계인지 서버 연동인지 가리기 어렵습니다. 도입 전에 확인할 항목을 체크리스트로 묶은 내용은 eKYC 도입 체크리스트 글에서 확인할 수 있습니다.
신분증 진위확인 API SDK 차이는 촬영 화면을 누가 만드느냐에 있고, 이 차이가 촬영 품질과 사본 유입 경로, 개발 범위를 정합니다. 도입 전에 아래 항목을 점검합니다.
.png)
.svg)
.svg)
