.svg)
AI 솔루션 문의하기
얼굴 인증 SDK 업데이트는 새 버전을 앱에 넣는 작업이 아니라, 이미 가입과 로그인, 이체에서 쓰이는 본인확인 경로를 바꾸는 작업입니다. 그래서 업데이트 전에 지원 기기, 촬영 화면, 결과 코드를 점검하고 단계 배포와 롤백 기준까지 정해 두어야 안전합니다.
OS가 새로 나오거나 보안 패치가 필요할 때, 혹은 인증 정확도 개선 버전이 나왔을 때 업데이트 요청이 들어옵니다. 이때 기획자는 일정을, 개발자는 호환성을, 보안 담당자는 취약점 대응을 각각 우려합니다. 기준 없이 진행하면 의견이 갈리고 배포 직전까지 판단이 미뤄집니다.
이 글은 도입 시점의 선정 기준이 아니라 운영 중 업데이트와 릴리스 절차에 집중합니다.
업데이트 이후 가장 흔한 문제는 본인확인이 완전히 막히기보다 일부 사용자에게서만 조용히 실패하는 형태입니다. 전체 지표는 정상처럼 보여도 특정 기기나 특정 앱 버전에서 완료율이 떨어질 수 있어 발견이 늦어집니다.
원인은 크게 두 가지로 나뉩니다. 하나는 앱, SDK, 서버가 서로 다른 버전을 기준으로 동작하는 버전 불일치입니다. 다른 하나는 기기별 카메라 특성 차이입니다.
본인확인은 금융 거래나 계정 개설 직전에 놓이는 단계라, 끊기면 곧바로 이탈과 민원으로 연결됩니다. 이 때문에 업데이트는 기능 개선보다 서비스 연속성 관점에서 먼저 평가해야 합니다.
점검은 세 영역으로 나누면 빠뜨림이 줄어듭니다. 지원 기기, 촬영 화면, 결과 코드입니다. 각 항목은 이전 버전과 새 버전을 같은 조건에서 비교하는 방식으로 확인합니다.
점검 결과는 통과 여부만 남기지 말고 기기, OS, 앱 버전, SDK 버전, 재현 절차를 함께 기록해 두는 것이 좋습니다. 다음 업데이트 때 같은 테스트를 그대로 반복할 수 있고, 장애 시 원인 추적도 빨라집니다.
사전 점검을 마쳐도 실제 사용자 환경의 모든 조합을 재현할 수는 없습니다. 그래서 한 번에 전체 배포하지 않고 범위를 넓혀 가는 단계 배포가 필요하며, 각 단계의 진행 조건과 되돌릴 조건을 미리 숫자로 정해야 합니다.
롤백이 가능하려면 이전 SDK 버전과 서버 설정을 보존하고, 원격 설정이나 기능 플래그로 신규 경로를 끌 수 있어야 합니다. 앱스토어 심사를 다시 거쳐야 하는 구조라면 롤백에 시간이 걸리므로 그만큼 초기 노출 범위를 좁게 잡는 것이 안전합니다.
알체라 eKYC는 얼굴 인증(1:1 얼굴 대조), 라이브니스, 얼굴 위변조 판별을 제공하며, SaaS와 설치형을 모두 지원합니다. 인증 기능을 직접 만들지 않고 연동하면 앞에서 본 점검과 배포 절차를 한 번 정해 두고 반복해서 쓸 수 있습니다. 다만 지원 기기 목록과 버전 정책의 세부는 고객사 환경에 따라 달라지므로, 업데이트 전 담당자와 확인하는 절차를 릴리스 체크리스트에 넣어 두는 것이 좋습니다.
인증 품질 면에서는 NIST FRTE 국내 1위, iBeta PAD(RGB) 국내 유일로 ISO/IEC 30107-3 평가를 받은 점이 근거가 됩니다. 도입은 SaaS 연동 30분, 개발을 포함한 전체 도입은 평균 1~3개월 수준이며, 고객사 환경에 따라 빠르면 2일 내 연동도 가능합니다. 고객사는 110곳 이상이고 누적 인증은 1,430만 건 이상입니다.
운영 단계에서는 관리자 페이지에서 수동 심사와 EDD 설정을 조정할 수 있어, 자동 인증이 실패한 사용자를 별도 경로로 처리하는 구성이 가능합니다. 업데이트 직후 실패 비율이 오를 때 수동 심사 경로가 완충 역할을 합니다.
공개 사례로는 네이버가 2026년 6월에 여권 인식, 출입국 체류 정보 조회, 1:1 얼굴 대조, 라이브니스를 조합해 국내 번호가 없는 외국인 인증에 도입했습니다. 얼굴 인증이 왜 금융·통신 보안의 기준으로 거론되는지는 SKT 해킹 사태 이후 부상한 안면인증 글에서 이어서 볼 수 있습니다.
.png)
.svg)
.svg)
