.svg)
AI 솔루션 문의하기
안면인증 시스템 구축은 얼굴 인식 엔진과 서버를 회사가 직접 만들고 운영하는 자체 구축 방식과, 검증된 안면인증 서비스를 API로 연동해 서비스에 붙이는 방식으로 나뉩니다. 두 방식 모두 촬영 화면, 위변조 판별, 얼굴 매칭, 결과 처리라는 같은 구성 요소를 갖추지만, 누가 엔진을 만들고 서버를 운영하며 성능을 검증하는지가 다릅니다. 자체 구축은 데이터와 시스템을 직접 통제할 수 있는 대신 학습 데이터, 서버, 검증, 유지보수를 모두 회사가 맡아야 하고, API 연동은 이 부담을 제공사와 나누는 대신 제공사의 처리 방식과 운영 기준을 따르게 됩니다. 이 글은 안면인증 시스템을 도입하려는 기업 담당자가 두 방식을 비교할 때 볼 항목과 고르는 기준을 정리합니다.
어떤 방식으로 구축하든 안면인증 시스템은 다음 다섯 가지 요소로 이루어집니다. 방식을 비교하기 전에 각 요소를 누가 맡게 되는지부터 정리하면 판단이 쉬워집니다.
고객의 얼굴을 촬영하는 앱·웹 화면입니다. 얼굴 가이드, 밝기 경고, 재촬영 안내가 여기에 들어가며, 촬영 품질이 이후 단계의 성공률을 크게 좌우합니다.
촬영된 얼굴이 실제 사람인지, 사진이나 화면, 마스크를 비춘 것인지 가려냅니다. 위변조 판별이 없으면 다른 사람의 사진만으로 인증을 통과할 수 있습니다.
촬영한 얼굴을 신분증 사진이나 이미 확인된 얼굴과 비교해 같은 사람인지 판단합니다. 비대면 가입처럼 처음 만나는 고객은 신분증 사진과, 재인증은 가입 때 확인한 결과와 비교합니다.
위변조 판별과 매칭 결과를 함께 보고 통과, 재촬영, 추가 확인으로 판정하고, 결과와 일시를 기록합니다. 판정 규칙은 서버 한 곳에서 관리해야 기준을 바꿀 때 빠뜨리는 곳이 생기지 않습니다. 얼굴 이미지를 얼마나 보관할지도 이 단계에서 정합니다.
인증 이력 조회, 실패율과 위변조 의심 비율 모니터링, 기준값 조정, 장애 대응이 여기에 해당합니다. 구축이 끝난 뒤에도 계속 사람이 맡아야 하는 부분입니다.
자체 구축은 위 다섯 요소를 모두 회사가 만들고 운영하는 방식이라, 개발 외에도 준비해야 할 것이 많습니다.
얼굴 매칭과 위변조 판별 모델을 직접 만들거나 도입해 학습시켜야 합니다. 특히 위변조 판별은 사진, 화면, 마스크 같은 공격 데이터를 충분히 모아야 성능이 나오는데, 이런 데이터를 확보하는 것이 자체 구축에서 가장 어려운 부분입니다.
얼굴 이미지를 받아 처리할 서버와 저장소, 보안 구간을 직접 구축하고 운영합니다. 가입이 몰리는 시간대에도 처리가 늦어지지 않도록 용량을 계획하고, 장애에 대비한 이중화도 갖춰야 합니다.
만든 시스템이 위조 시도를 얼마나 막고 정상 고객을 얼마나 통과시키는지 검증해야 합니다. 내부 시험만으로는 실제 공격 유형을 다 담기 어려워, 외부 평가를 받으려면 별도의 준비가 필요합니다.
새로운 위변조 수법이 나오면 모델을 다시 학습시키고, 서버와 보안 패치를 관리할 인력이 계속 필요합니다. 생체정보를 직접 보관하게 되므로 접근 권한과 보관 기준도 회사가 책임지고 관리해야 합니다.
API 연동 방식은 위변조 판별과 얼굴 매칭을 제공사의 엔진에 맡기고, 회사는 촬영 화면과 결과 처리, 운영 관리에 집중합니다.
인식 엔진과 처리 서버를 제공사가 운영하므로, 회사는 자체 서버의 API 호출과 결과 처리만 구현하면 됩니다. 가입이 몰리는 시간대의 처리 용량도 제공사가 관리합니다. 모델 학습과 서버 용량 계획을 직접 하지 않아도 됩니다.
제공사가 위변조 데이터를 학습시키고 외부 평가를 받은 엔진을 그대로 쓸 수 있습니다. 비교할 때는 어떤 평가를 받았는지, 실제 촬영 환경과 비슷한 조건에서 측정한 결과인지 확인합니다.
신분증 OCR, 진위확인, 1원 인증까지 같은 제공사에서 제공한다면 가입 단계 전체를 한 흐름으로 묶을 수 있습니다. 단계마다 다른 시스템을 연동하지 않아도 돼 결과 저장 구조도 단순해집니다.
얼굴 이미지가 어디서 처리되고 얼마나 보관되는지, 제공사 장애 시 대응 범위와 연락 경로, 매칭 기준값이나 재촬영 횟수를 회사가 조정할 수 있는지 계약 전에 확인합니다.
알체라 eKYC는 별도 서버 구축 없이 API 연동만으로 얼굴 위변조 판별과 신분증 사진 매칭을 포함한 얼굴 인증을 붙일 수 있고, 앱과 웹 환경을 모두 지원합니다. RGB 카메라 기반으로 iBeta 얼굴 위변조 탐지(PAD) 평가를 통과했으며, 신분증 OCR(정확도 98.47%), 진위확인, 사본판별(정확도 99%), 1원 인증까지 같은 흐름으로 구성할 수 있습니다. 알체라 eKYC는 고객사 110곳, 누적 1,430만 회 인증, 제1금융권 70%가 사용하고 있습니다.
두 방식 중 어느 쪽이 낫다고 단정하기보다, 회사 상황을 다음 기준에 대입해 고릅니다.
비대면 가입, 계좌 개설, 휴대폰 개통처럼 신분증과 얼굴을 함께 확인하는 업무는 신분증 확인과 얼굴 인증을 한 흐름으로 제공하는 API 방식이 구성하기 쉽습니다. 사내 출입이나 근태처럼 등록된 직원 얼굴만 비교하는 업무는 요구 조건이 달라 따로 검토합니다. 한 회사 안에서도 고객 가입과 직원 출입처럼 목적이 다른 업무가 함께 있다면, 업무마다 다른 방식을 쓰는 것도 가능합니다.
인식 모델을 학습시키고 위변조 데이터를 계속 확보할 인력과 데이터가 있다면 자체 구축을 검토할 수 있습니다. 그렇지 않다면 엔진을 직접 만들기보다 검증된 엔진을 연동하는 편이 성능과 운영 면에서 안정적입니다.
내부 규정상 얼굴 이미지가 회사 밖으로 나갈 수 없다면, 제공사가 회사 내부망에 설치하는 방식을 지원하는지 확인하거나 자체 구축을 검토합니다. 외부 처리가 가능하다면 이미지 보관 기간과 파기 기준을 계약에 명시합니다. 금융권처럼 감독 기관 점검이 있는 업종은 처리 위치와 보관 기준을 점검 때 바로 설명할 수 있도록 문서로 정리해 둡니다.
자체 구축은 초기 개발과 서버, 인력에 큰 비용이 먼저 들고, API 방식은 호출 건당 비용이 쓰는 만큼 생깁니다. 예상 호출 건수와 내부 인력 비용을 함께 놓고 비교해야 실제 차이를 알 수 있습니다. 자체 구축은 새로운 위변조 수법에 대응하기 위한 재학습과 성능 재검증 비용이 계속 생긴다는 점도 함께 계산에 넣습니다.
처음부터 한 방식으로 정하기 어렵다면, 위험이 큰 업무 한 곳에 API 방식으로 먼저 적용해 실제 호출 건수와 실패율, 위변조 시도 유형을 확인한 뒤 범위를 넓히는 방법이 있습니다. 운영 데이터가 쌓이면 자체 구축이 필요한지, API 방식으로 충분한지 근거를 갖고 판단할 수 있습니다. 어느 쪽으로 가든 결과 저장 구조와 실패 안내 기준은 회사가 정해야 하므로, 이 부분은 처음부터 방식과 상관없이 설계해 둡니다.
구축 방식과 관계없이 위변조 의심 비율, 매칭 실패 비율, 재촬영 비율을 꾸준히 보고 기준값과 안내를 조정해야 합니다. 기준을 바꿀 때는 변경 일시와 이유를 남기고 전후 결과를 비교해, 다음 조정의 근거로 씁니다. 생체정보 처리 동의와 이미지 보관 기준도 방식과 관계없이 회사가 책임지는 부분입니다.
.png)
.svg)
.svg)
