딥페이크 탐지를 넣은 비대면 본인확인 흐름: 신분증부터 계좌 확인까지 4단계

트렌드
2026-10-28

딥페이크 탐지 비대면 본인확인은 얼굴 이미지가 진짜인지 확인하는 검사만으로 끝나지 않습니다. 신분증이 유효한 문서인지, 신분증의 얼굴과 촬영자가 같은 사람인지, 촬영 영상이 실제 사람에게서 얻어진 것인지, 신청자가 확인 대상 계좌를 이용할 수 있는지를 별도로 판단해야 합니다. 확인 대상이 다른 만큼 한 단계의 성공을 전체 인증 성공으로 해석해서는 안 됩니다.

‍

기업이 비대면 가입이나 계좌 개설을 설계할 때는 다음과 같이 네 가지 검증 단계를 구분할 수 있습니다.

  1. 신분증 진위확인·사본판별: 발급정보의 유효성과 제출한 신분증 이미지의 출력물·화면 재촬영 여부 점검
  2. 얼굴 매칭: 신분증 얼굴 사진과 고객이 새로 촬영한 얼굴이 동일인인지 대조
  3. 라이브니스(PAD): 사진·재생 영상·가면 등 얼굴 위조 수단이 사용됐는지 점검
  4. 1원 계좌 인증: 본인 명의 계좌 정보와 소액 입금 인증코드를 통한 추가 확인

‍

이 순서는 업무상 확인 목적을 설명하기 위한 흐름입니다. 실제 앱에서는 얼굴 매칭과 라이브니스가 같은 촬영 과정에서 처리될 수 있으며, 업종과 거래 유형에 따라 적용 단계도 달라집니다. 모든 기업에 네 가지 절차가 법적으로 일괄 요구된다는 의미는 아닙니다.

‍

딥페이크 생성 모델 자체를 분석하는 방법과 기술 동향은 기존 딥페이크 탐지·얼굴인식 기술 글에서 다루고 있습니다. 이 글에서는 중복 설명을 줄이고, 각 본인확인 단계가 어떤 공격을 점검하는지에 집중합니다.

‍

 1단계: 신분증 진위확인·사본판별로 문서 위조 점검

‍

‍

신분증 진위확인과 사본판별은 서로 다른 위험을 점검합니다. 발급기관 정보와 신분증에 적힌 정보가 일치하더라도, 제출한 이미지가 실제 신분증이 아니라 종이 출력물이나 다른 화면을 다시 촬영한 것일 수 있기 때문입니다.

‍

OCR·진위확인: 존재하지 않거나 유효하지 않은 신분증 정보 점검

고객이 신분증을 촬영하면 OCR로 성명, 발급일자 등 확인에 필요한 항목을 추출합니다. 이후 신분증 종류와 이용 가능한 확인 수단에 따라 발급정보 진위확인을 수행합니다. 예컨대 정보가 임의로 바뀌었거나 이미 무효 처리된 신분증이라면 발급정보 검증에서 불일치를 발견할 수 있습니다.

  • 점검하려는 공격
    • 타인의 인적 사항을 조합해 만든 허위 신분증, 발급정보를 수정한 문서, 무효한 신분증 정보 사용
  • 확인할 사항
    • 지원하는 신분증 종류, OCR 추출값의 정확성, 발급정보 검증의 지원 범위와 결과 코드
  • 한계
    • 발급정보가 유효하다는 사실은 촬영된 신분증이 실물이라는 증거가 아닙니다. 또한 유효한 타인 명의 신분증을 누가 들고 있는지도 이 단계만으로 판단할 수 없습니다.

‍

문서가 흐릿하거나 일부 정보가 가려져 OCR에 실패한 경우에는 바로 위조로 단정하지 말고 재촬영을 안내해야 합니다. 발급정보 불일치나 무효 결과는 단순 화질 오류와 분리해 거래를 보류하고 확인 경로를 마련하는 편이 적절합니다.

‍

사본판별: 종이 출력물과 화면 재촬영 점검

사본판별은 고객이 제출한 이미지가 실제 신분증 촬영인지, 인쇄한 신분증 사진이나 스마트폰·모니터에 띄운 이미지의 재촬영인지 분석합니다. 진짜 신분증의 사진을 다른 기기에 띄워 제출하더라도 발급정보 자체는 유효할 수 있으므로 진위확인과 사본판별을 함께 구성해야 합니다.

‍

알체라 공식 eKYC 페이지에 안내된 신분증 사본판별 정확도는 99%입니다. 이는 사본판별 기능의 공개 성능 수치로, 모든 위조 공격 차단율이나 전체 본인확인 성공률을 의미하지 않습니다. 운영사는 실제 촬영 기기, 빛 반사, 기울기, 화질 저하와 같은 사용 환경에서 판정 결과를 별도로 점검해야 합니다.

‍

  • 점검하려는 공격
    • 종이 출력물 제출, 모니터·휴대폰 화면 재촬영 등 신분증 사본을 실물처럼 제시하는 시도
  • 확인할 사항
    • 사본 의심 결과의 분류 방식, 재촬영 허용 기준, 정상 고객이 사본으로 오판되는 경우의 예외 처리
  • 한계
    • 사본이 아닌 실제 신분증을 제출한 사람도 신분증의 명의인과 다른 사람일 수 있습니다. 이 문제는 다음 얼굴 매칭 단계에서 확인합니다.

‍

2단계: 얼굴 매칭으로 타인 신분증 사용 점검

‍

비대면 본인확인 절차와 딥페이크 탐지의 중요성

‍

얼굴 매칭은 신분증 사진의 인물과 현재 인증을 진행하는 고객의 얼굴이 같은 사람인지 비교하는 절차입니다. 유효한 신분증의 실물을 제시했다고 해서 그것을 가진 사람이 명의인이라고 볼 수 없으므로, 문서 검증 뒤에는 사람과 문서의 연결을 확인해야 합니다.

‍

신분증 사진과 신규 얼굴 촬영 비교

서비스는 신분증에서 추출한 얼굴 사진과 앱에서 새로 촬영한 고객 얼굴을 비교합니다. 이때 문서 이미지의 품질과 얼굴 촬영 품질, 동일인 판정 기준이 결과에 영향을 주므로, 단일 유사도 점수만 보고 무조건 승인하는 방식은 피해야 합니다.

  • 점검하려는 공격
    • 가족·지인의 신분증 사용, 습득한 실물 신분증을 이용한 타인 명의 가입, 신분증 명의인과 다른 사람의 인증 시도
  • 확인할 사항
    • 얼굴 대조에 사용할 신분증 사진 추출 방식, 얼굴 촬영 시 품질 기준, 매칭 실패와 판정 불가의 구분
  • 한계
    • 두 얼굴이 비슷하다는 결과만으로 촬영 영상이 실제 사람에게서 나왔다는 뜻은 아닙니다. 공격자가 명의인의 얼굴 사진이나 딥페이크 영상을 제출할 수 있기 때문입니다.

‍

얼굴 매칭 실패 시 처리

매칭에 실패했을 때는 조명·각도·안경·촬영 흔들림에 따른 품질 문제와 명백한 불일치를 구분해야 합니다. 품질이 낮으면 안내에 따라 다시 촬영하도록 하고, 반복 불일치 또는 타인 명의 사용이 의심되면 인증 완료를 보류하고 정해진 추가 확인 절차로 전환합니다.

또한 얼굴 검증 결과를 다른 가입 요청이나 다른 사용자에게 재사용하지 않도록 인증 요청 식별자, 유효기간, 중복 제출 여부를 고객사 서버에서 관리해야 합니다. 얼굴 매칭 기능 자체와 최종 계정 승인 정책은 구분해 설계하는 것이 좋습니다.

‍
3단계: 라이브니스로 사진·영상·딥페이크 위조 점검

‍

딥페이크 탐지 기술의 최신 동향

‍

라이브니스 검증은 얼굴 매칭 결과와 별개로, 인증에 사용한 얼굴 입력이 실제 현장에 있는 사람의 정상적인 촬영인지 평가하는 과정입니다. 예컨대 신분증 사진과 정확히 같은 이미지를 화면에 띄워 촬영하면 얼굴은 일치할 수 있지만 정상적인 본인 인증이라고 볼 수 없습니다.

‍

PAD가 평가하는 프레젠테이션 공격

PAD(Presentation Attack Detection)는 카메라 앞에 제시한 가짜 얼굴 사진, 재생 영상, 가면 등의 프레젠테이션 공격을 탐지하는 기술입니다. 얼굴 매칭이 '누구와 같은 얼굴인가'를 다룬다면 PAD는 '제시된 얼굴이 공격물인가'를 점검합니다.

‍

  • 점검하려는 공격
    • 인쇄 사진을 카메라에 제시하거나 다른 기기에 재생한 얼굴 영상을 촬영하는 시도
  • 확인할 사항
    • 실제 서비스의 카메라 환경에서 어떤 프레젠테이션 공격물을 평가했는지, PAD 테스트 범위, 실패 시 처리 방식
  • 한계
    • PAD의 평가 범위가 모든 딥페이크 변종이나 디지털 입력 변조까지 자동으로 포함하는 것은 아닙니다.

알체라 eKYC는 공식 페이지에서 RGB 카메라 기반 iBeta PAD 평가 통과를 안내하고 있습니다. 다만 실제 서비스에서 어떤 입력 경로와 공격 유형까지 점검하는지는 연동 환경을 기준으로 확인해야 합니다.

‍

딥페이크와 영상 입력 변조는 구분해 검토

딥페이크는 합성·변조된 얼굴 콘텐츠를 의미하며, 그 콘텐츠가 사용되는 경로에 따라 공격 방식이 달라집니다. 다른 화면에 영상을 재생하고 카메라로 촬영하면 프레젠테이션 공격에 가까운 반면, 가상 카메라나 조작된 입력 경로로 영상을 직접 공급하면 디지털 인젝션 공격에 해당할 수 있습니다.

따라서 라이브니스 도입 시에는 PAD 성능 외에도 촬영 원본의 출처, 입력 경로 변조 탐지, 기기·앱 무결성 확인 등을 공급 범위에 포함할지 질문해야 합니다. 이 기능들이 자동으로 모두 제공된다고 가정하지 않고, 고객사 시스템의 책임 범위도 구분해야 합니다.

촬영 실패는 품질 문제에 따라 재시도를 허용하되, 위조 의심 결과에는 동일한 재시도를 무제한 허용하지 않아야 합니다. 의심 계정은 인증을 보류하고 대체 확인 또는 담당자 심사로 전환하는 정책을 마련해야 합니다.

‍

알체라 eKYC로 본인확인 단계를 연결하면

신분증은 정상으로 판정됐지만 촬영자가 다른 사람일 수 있고, 얼굴이 일치해도 재생 영상을 사용했을 수 있습니다. 따라서 문서 진위확인·사본판별, 얼굴 매칭, 라이브니스를 별도로 검증하고 결과를 묶어서 판단하는 구조가 필요합니다.

알체라 eKYC는 신분증 OCR·진위확인·사본판별과 얼굴 매칭·위변조 판별을 제공합니다. 기업은 해당 검증 결과를 자체 가입·거래 승인 정책과 연동하고, 필요한 업무에서는 다음 단계의 1원 계좌 인증까지 조합할 수 있습니다. 최종 승인과 예외 처리 기준은 고객사 시스템에서 관리해야 합니다.

‍

4단계: 1원 계좌 인증으로 계좌 명의와 이용 가능 여부 추가 확인

 

딥페이크 기술의 위험성과 방지 전략

 

1원 계좌 인증은 고객이 입력한 계좌로 소액을 송금하고, 입금내역에 표시된 인증코드를 확인하는 방식입니다. 신분증과 얼굴 검사로 사람의 신원을 점검한 뒤, 그 사람이 제출한 계좌와 연결된 확인 절차를 수행할 수 있는지 확인하는 용도로 구성할 수 있습니다.

‍

계좌 인증이 추가로 점검하는 위험

고객이 다른 사람의 신분증과 얼굴 정보를 악용해 인증을 시도하더라도, 제시한 계좌의 입금 인증코드까지 확인해야 한다면 계좌 이용정보 확인이라는 별도 검증이 추가됩니다. 계좌 명의 정보와 신분증상 성명을 대조할 수 있는 서비스 환경에서는 명의 불일치도 별도로 확인할 수 있습니다.

  • 점검하려는 위험
    • 신청자 정보와 계좌 명의 불일치, 제출한 계좌의 입금내역을 확인할 수 없는 상태, 앞선 얼굴 검증 이후의 계좌 정보 불일치
  • 확인할 사항
    • 지원 금융기관, 계좌 명의 대조 제공 여부, 인증코드 유효기간, 재전송·오입력 제한, 계좌 정보 변경 시 재검증 조건
  • 한계
    • 입금 인증코드를 입력했다고 해서 계좌의 실질적 소유나 거래 자금의 적법성이 모두 확인되는 것은 아닙니다. 탈취한 계좌 접근 수단이나 제3자와의 공모 등 별도 위험도 고려해야 합니다.

또한 1원 인증은 딥페이크를 직접 탐지하는 기능이 아닙니다. 앞선 얼굴 검사와 계좌 확인을 결합해 서로 다른 종류의 신원 불일치를 점검하도록 돕는 추가 단계입니다. 이를 독립적인 딥페이크 차단율로 표현해서는 안 됩니다.

‍

1원 인증 실패·계좌 변경 시 처리

인증코드 오입력, 입금 반영 지연, 지원하지 않는 금융기관, 명의 불일치 등은 원인이 서로 다릅니다. 코드 재입력을 허용할지, 새 송금을 요청할지, 다른 확인 수단으로 넘길지 업무 정책을 미리 정해야 합니다.

특히 명의 불일치를 단순 입력 오류로 처리해 임의로 통과시키지 않아야 하며, 동일 세션에서 인증 대상 계좌가 바뀌었다면 기존 계좌 인증 결과를 그대로 재사용하지 않는 편이 적절합니다. 사용자가 정당하게 계좌를 변경한 경우라도 새 계좌의 명의와 인증코드를 다시 확인하는 방식으로 설계할 수 있습니다.

서비스 운영자는 계좌 인증 요청을 만든 사용자와 인증 결과를 받는 사용자가 같은 세션에 속하는지도 점검해야 합니다. 인증코드를 다른 가입 신청에 연결하거나 이미 성공한 결과를 새 요청에 재사용할 수 없도록 요청별 식별자와 만료 정책을 설정합니다. 코드 입력 횟수가 초과됐을 때는 재전송을 무제한 허용하기보다 일시 보류와 추가 확인 기준을 두는 것이 좋습니다.

특히 신분증과 얼굴 검증에 성공했더라도, 계좌 인증에서 다른 이름이 확인되면 이전 단계의 성공 상태와 계좌 인증 결과를 합쳐 자동 승인하지 않아야 합니다. 고객 지원 담당자가 어느 단계에서 불일치했는지 확인할 수 있도록 결과 코드를 분리하고, 실명확인 규정이 적용되는 서비스라면 해당 업종의 추가 요건도 함께 검토해야 합니다.

‍

정리: 딥페이크 탐지 비대면 본인확인 4단계 도입 전 점검할 것

‍

‍

딥페이크 탐지 비대면 본인확인을 설계할 때는 인증 수단을 많이 추가하는 것보다 각 단계가 어떤 공격을 확인하고, 어떤 위험은 확인하지 못하는지 구분하는 작업이 우선입니다. 신분증 검증만으로 실제 촬영자를 알 수 없고, 얼굴 매칭만으로 위조 영상 여부를 확정할 수 없으며, 1원 계좌 인증만으로 신원검증 전체를 대체할 수도 없습니다.

‍

단계별 공격 대응과 실패 처리 체크리스트

‍

  • 1단계 — 신분증 진위확인·사본판별
    • 대응 대상: 허위·무효 신분증 정보, 종이 출력물과 화면 재촬영
    • 실패 처리: 촬영 품질 오류는 재촬영, 발급정보 불일치·사본 의심은 보류 및 추가 확인
  • 2단계 — 얼굴 매칭
    • 대응 대상: 타인 명의 실물 신분증 사용, 문서 명의인과 촬영자의 불일치
    • 실패 처리: 저화질은 재촬영, 반복 불일치는 심사 또는 거래 보류
  • 3단계 — 라이브니스
    • 대응 대상: 사진·재생 영상·가면 등 PAD 평가 범위에 포함된 프레젠테이션 공격
    • 실패 처리: 위조 의심은 즉시 승인하지 않고 제한된 재시도와 추가 검증 적용
  • 4단계 — 1원 계좌 인증
    • 대응 대상: 계좌 명의 불일치, 인증코드 확인 실패 등 앞선 신원검사에서 확인하지 못한 계좌 관련 위험
    • 실패 처리: 코드 만료·전송 지연과 명의 불일치를 구분하고 계좌 변경 시 재검증

‍

전체 흐름에서 따로 결정할 운영 기준

본인확인 결과를 종합하는 서버 정책도 필요합니다. 단계를 통과할 때마다 검증 요청의 식별자, 수행 시각, 결과 상태, 실패 사유를 한 건의 인증 세션에 연결해야 합니다. 특정 단계가 실패했는데 이후 단계만 성공했다는 이유로 전체 인증을 완료 처리하지 않도록 승인·보류·거절 조건을 명확히 두어야 합니다.

얼굴 촬영물과 신분증 이미지에는 개인정보가 포함되므로 수집 목적, 보관기간, 접근 권한 및 파기 기준을 별도로 검토해야 합니다. 또한 사진 위조 의심과 단순 촬영 품질 오류를 똑같이 처리하지 않도록 사용자 안내 문구와 상담·수동 심사 절차를 구분해야 합니다. 정상 고객의 반복 실패도 운영 품질 점검에 활용할 수 있습니다.

네 단계는 각자 다른 확인 목적을 갖기 때문에, 어떤 거래에 네 단계를 모두 적용할지, 어느 단계에서 추가 확인을 요구할지, 실패한 고객을 어떻게 처리할지를 먼저 결정해야 합니다. 이 구조를 확정한 뒤 알체라 eKYC의 신분증·얼굴·1원 인증 기능을 연결하면, 개별 검증 결과를 실제 업무의 승인 정책과 연계하는 기준을 보다 명확하게 관리할 수 있습니다.

‍