.svg)
AI 솔루션 문의하기
부동산 플랫폼 비대면 본인확인은 가입한 계정의 실제 이용자가 누구인지, 계약을 진행하는 사람이 확인된 당사자인지 판단할 때 사용합니다. 단순 회원가입과 보증금이 오가는 계약은 위험 수준이 다르므로 회원가입·계약·임대인 인증에 동일한 절차를 적용하기보다 확인 목적을 먼저 구분해야 합니다. 본인확인은 신분 도용 위험을 낮추는 수단이지만, 부동산의 소유권이나 대리권까지 자동으로 증명하지는 않습니다.
회원가입에서는 이메일이나 휴대전화 연락처 확인만으로 충분한 서비스인지, 실명 기반의 이용자 확인이 필요한지 정해야 합니다. 일반적인 매물 검색 계정에는 가벼운 가입 절차를 적용하고, 매물을 등록하거나 거래 상대방에게 신뢰 표시를 제공하는 계정에는 신분증 기반 본인확인을 추가하는 방식으로 설계할 수 있습니다.
예를 들어 플랫폼에 매물을 올릴 권한을 부여하기 전에 신분증 정보와 실제 촬영자를 대조하면 타인의 인적사항으로 등록을 시도하는 상황을 검토할 근거가 생깁니다. 다만 인증을 완료했다는 사실과 매물 정보를 올릴 권한이 있다는 사실은 별도로 판단해야 합니다.
전자계약 단계에서는 가입 당시 인증한 계정이 지금도 본인에게 통제되고 있는지 확인해야 합니다. 최초 가입 시 인증이 끝났더라도 오랜 기간 로그인하지 않았거나 계정 복구·기기 변경이 있었다면 계약 서명 직전에 추가 얼굴 인증이나 다른 본인확인 절차를 요청하는 정책을 검토할 수 있습니다.
실무에서는 인증 성공 여부만 보는 대신 인증한 이용자, 인증 시점, 계약 문서, 서명 시점을 연결해 관리하는 것이 좋습니다. 계약 상대방이 변경되거나 계약 조건이 수정된 경우 재확인 기준도 별도로 마련해야 합니다.
임대인 인증에서는 두 가지 질문에 답해야 합니다. 첫째, 인증을 요청한 사람이 제출한 신분증의 당사자인가. 둘째, 그 사람이 해당 부동산을 임대할 권한을 가졌는가. 신분증·얼굴 인증은 첫 번째 질문을 검토하는 기술이며, 두 번째 질문은 등기사항증명서 등 소유권 자료와 위임 관계를 함께 확인해야 합니다.
법인 임대인이거나 관리인·공인중개사 등이 대신 계약하는 경우에는 실제 서명자 신원 확인 외에 법인의 대표권, 위임장, 위임 범위 등을 별도로 검토해야 합니다. 플랫폼은 ‘본인확인 완료’와 ‘임대 권한 확인 완료’를 다른 상태로 표시해야 두 결과를 혼동하지 않습니다.
세 방식은 서로 대체할 수 있는 동일한 인증이 아닙니다. 신분증 인증은 신원정보와 제출 서류, 얼굴 인증은 신분증 속 인물과 현재 인증자 간의 동일인 여부, 1원 계좌 인증은 계좌 이용과 명의 관련 정보를 확인하는 데 초점이 있습니다. 플랫폼은 거래 위험과 서비스 단계에 따라 필요한 결과를 조합해야 합니다.
신분증 OCR은 주민등록증이나 운전면허증 등에서 이름, 생년월일, 발급 정보와 같은 문자를 읽어 입력 부담을 줄이는 기능입니다. 이후 신분증 진위확인을 통해 발급 정보가 유효한지 별도로 검증하고, 사본판별을 적용해 인쇄물이나 화면 재촬영 등 비정상적인 제출 형태를 확인할 수 있습니다.
OCR 결과가 잘 읽혔다고 해서 그 신분증이 진짜라는 뜻은 아닙니다. 또한 진위확인이 성공해도 신분증을 제출한 사람이 실제 명의자인지는 다른 확인이 필요합니다. 플랫폼은 OCR, 진위확인, 사본판별을 각각 구분된 결과로 취급해야 합니다.
얼굴 인증은 스마트폰 카메라로 촬영한 얼굴과 신분증 사진을 비교해 동일인 가능성을 판단합니다. 여기에 라이브니스(Liveness)·얼굴 위변조 탐지를 적용하면 사진이나 영상 등을 이용한 인증 시도를 검사할 수 있습니다. 매칭 실패와 위변조 탐지 실패는 원인이 다를 수 있어 재촬영 안내와 추가 심사 기준도 구분하는 편이 적절합니다.
부동산 플랫폼에서는 특히 계약 서명 직전이나 임대인 계정의 중요한 정보가 바뀌는 시점에 활용할 수 있습니다. 다만 얼굴 매칭만으로 임대인의 소유권이나 계약 의사가 확인되는 것은 아니므로 전자계약 기록 및 권한 검토를 결합해야 합니다.
1원 계좌 인증은 고객이 입력한 계좌로 소액을 송금하고, 입금 내역의 인증코드를 확인하게 하는 방식입니다. 인증 과정에서 계좌의 명의 정보와 신청자 정보를 대조할 수 있도록 구성하면, 보증금 반환 계좌나 정산 계좌 등록 시 추가 검증 단계로 활용할 수 있습니다.
반면 1원 인증만으로 신분증 소유자와 현재 이용자의 얼굴이 일치하는지, 계좌가 실제 계약 당사자의 적법한 수령 계좌인지까지 확정할 수는 없습니다. 계좌 명의 확인과 거래대금 수령 권한 확인은 분리해야 합니다. 은행·계좌 종류별 지원 범위와 실패 처리 방식도 도입 전에 확인해야 합니다.
인증 수단을 많이 넣는 것보다 어떤 행위에 어떤 검증 결과가 필요한지를 정하는 것이 중요합니다. 가입 시점의 본인확인과 계약 시점의 재인증은 목적이 다르며, 임대인 인증에는 본인확인 외에 권한 검토가 추가됩니다.
플랫폼 운영팀은 다음과 같은 정책을 출발점으로 검토할 수 있습니다. 이는 부동산 플랫폼에 일률적으로 적용되는 법정 인증 조합이 아니라 서비스 설계 예시입니다.
이용자가 신분증 촬영에 실패하거나 얼굴 매칭이 일정 기준에 미달해도 곧바로 부정 이용자로 단정해서는 안 됩니다. 실패 사유를 촬영 품질, 정보 불일치, 인증코드 오류, 위변조 의심, 외부 서비스 장애 등으로 나누고 단계별 재시도 및 수기 검토 정책을 만들어야 합니다.
인증 결과는 계약 승인 여부를 판단하는 여러 조건 가운데 하나로 사용합니다. 인증 실패 상태에서 계약 진행을 잠시 제한할지, 상담원 검토 후 진행할지, 대체 인증을 허용할지는 서비스 위험도와 이용자 특성에 맞게 결정해야 합니다.
임대인이나 계약 서명자의 신분증은 유효하지만 제출자가 실제 명의자인지 확인하기 어려운 상황이라면 알체라 eKYC의 얼굴 매칭·라이브니스 검사를 인증 단계에 연결할 수 있습니다. 신분증에 있는 얼굴과 현재 촬영한 이용자를 비교하고 얼굴 위변조 징후를 함께 판단해, 플랫폼이 동일인 확인 결과를 계약 절차의 판단 자료로 활용하도록 구성합니다. 임대 권한과 계약 내용의 진정성은 별도 서류 검토 영역으로 남겨 둡니다.
API·SDK 연동 방식은 인증 기능을 어느 위치에 구현할지에 따라 결정합니다. 플랫폼 서버와 인증 서비스를 연결하는 작업, 모바일에서 촬영 화면을 구성하는 작업, 인증 결과를 계약 승인 로직에 반영하는 작업을 구분해야 연동 범위를 정확히 산정할 수 있습니다.
API(Application Programming Interface) 방식에서는 플랫폼이 인증 요청을 만들고 공급사의 인증 서비스에 전달한 뒤 결과를 받아 처리합니다. 신분증 OCR, 진위확인, 얼굴 비교, 계좌 확인을 각각 호출하거나 서비스가 지원하는 통합 흐름으로 연결할 수 있습니다. 인증 호출만 붙인다고 도입이 끝나는 것은 아니며, 플랫폼이 인증 상태와 계약 상태를 함께 관리하는 로직을 구현해야 합니다.
설계 단계에서 개발팀은 요청별 고유번호, 성공·실패 응답, 타임아웃, 재시도 제한, 중복 요청, 테스트 환경을 확인해야 합니다. 신분증이나 얼굴 원본 이미지를 플랫폼 서버가 직접 보관할 필요가 있는지 검토하고, 필요하지 않다면 결과값만 전달받도록 데이터 흐름을 설계하는 방안이 있습니다.
SDK(Software Development Kit) 방식은 모바일 앱에 촬영이나 얼굴 검출 등 제공되는 기능을 통합할 때 검토합니다. 사용자가 별도 서비스로 이동하지 않고 앱 안에서 신분증 촬영 안내나 얼굴 촬영 과정을 진행하도록 구성할 수 있습니다. 다만 모든 SDK가 같은 촬영 기능과 인증 판정 기능을 제공하는 것은 아니므로 지원 운영체제, 웹·앱 환경, SDK 기능 범위와 서버 API 의존성을 공급사에 확인해야 합니다.
모바일 앱과 웹을 함께 운영한다면 두 환경에서 인증 절차가 달라지지 않도록 확인해야 합니다. 기기 권한 거부, 카메라 미지원, 네트워크 중단, 브라우저 호환성 같은 예외에도 이용자에게 다음 행동을 안내할 수 있어야 합니다.
부동산 플랫폼에는 계약서, 신분정보, 얼굴 이미지처럼 보호가 필요한 정보가 모일 수 있습니다. 따라서 연동 방식과 별개로 개인정보 수집·이용 근거, 접근 권한, 보관 기간, 파기 정책, 인증 결과의 재사용 조건을 검토해야 합니다. 서비스가 이용자에게 표시하는 ‘인증 완료’ 배지도 무엇을 검증한 결과인지 명확해야 합니다.
예를 들어 ‘실명 확인’, ‘얼굴 동일인 확인’, ‘임대 권한 확인’은 서로 다른 상태입니다. API 응답을 하나의 성공·실패값으로만 관리하면 운영자가 검증하지 않은 항목을 검증 완료로 오해할 수 있으므로, 결과를 항목별로 관리하는 편이 적절합니다.
부동산 플랫폼에 적용할 설계를 검토할 때는 신원을 확인한 뒤 어떤 이용 권한을 부여하는지, 원본 개인정보를 어느 시스템에서 처리하는지가 드러나는 사례를 참고할 수 있습니다. 아래 사례는 공식 공개된 플랫폼 적용 사례이며, 특정 부동산 서비스에 도입됐다는 의미는 아닙니다.
알체라 공식 블로그에 따르면 당근알바는 사장님과 구직자 양측의 신원을 확인하기 위해 자회사 유스비의 신분증 OCR·사본판별·얼굴 인증을 SaaS 방식으로 적용했습니다. 당근 측 서버에 신분증 및 얼굴 원본 데이터를 직접 보관하지 않고 인증 결과를 전달받는 구조를 적용했으며, 인증한 이용자에게는 인증 배지를 부여했습니다. 자세한 내용은 알체라의 당근알바 도입 사례 소개에서 확인할 수 있습니다.
부동산 플랫폼도 임대인·임차인처럼 역할이 다른 이용자에게 인증 상태를 구분해 보여주는 방식을 검토할 수 있습니다. 다만 당근알바의 인증 배지 운영 사례가 곧 부동산 소유권 확인이나 임대 권한 검증의 완료를 의미하지는 않습니다.
알체라 네이버 고객사례에 따르면 네이버는 외국인 이용자를 위해 해외여권 정보 확인과 얼굴 인증을 결합한 eKYC를 도입했습니다. 본인확인이 완료되면 네이버지도에서 예약·주문·결제 등 인증이 필요한 서비스로 이어질 수 있도록 구성한 사례입니다.
이 사례는 국내 신분증이나 계좌를 사용하기 어려운 이용자에게 대체 신원확인 수단을 마련하고, 인증 성공 결과를 서비스 권한과 연결한 설계 참고자료입니다. 부동산 플랫폼이 외국인 임차인까지 대상으로 한다면 국내 계좌 보유 여부만을 전제로 인증 흐름을 고정하지 않는 것이 좋습니다.
다음은 실제 고객사 성과가 아닌 설계 예시입니다. 개인 임대인이 매물을 등록하는 경우, 먼저 신분증 정보와 현재 이용자의 얼굴을 대조합니다. 그다음 등기사항증명서 등 권한 자료를 따로 검토해 임대인 등록 권한을 승인합니다. 전자계약 서명 단계에서는 필요 시 얼굴 재인증을 요청하고, 정산 계좌가 새로 등록되면 1원 계좌 인증으로 추가 확인합니다.
이처럼 인증 수단을 기능별로 배치하면 매번 모든 이용자에게 동일한 인증을 반복시키지 않으면서도, 계약 과정에서 검증해야 할 항목을 누락하지 않도록 설계할 수 있습니다. 특히 법인·대리인이 개입한 계약은 본인확인과 별개로 대표권·위임 범위 검토 단계를 유지해야 합니다.
부동산 플랫폼 비대면 본인확인을 도입할 때는 기술 목록보다 인증이 필요한 업무 시점과 최종 승인 책임을 먼저 정해야 합니다. 신분증 진위확인, 얼굴 매칭, 1원 계좌 인증은 검증 대상이 서로 다르며, 소유권·대리권 확인은 별도의 부동산 거래 업무입니다.
가입부터 계약까지 한 번의 인증으로 모든 위험이 해결되지는 않습니다. 플랫폼이 어떤 사실을 확인했고 어떤 판단을 추가로 해야 하는지 명확하게 구분하는 것이 신뢰할 수 있는 부동산 비대면 거래 절차를 설계하는 출발점입니다.
.png)
.svg)
.svg)
