한 이용자가 전자도서관에 들어가 휴대전화 본인인증을 마쳤습니다. 이름과 생년월일을 입력하고 문자로 온 절차도 통과했습니다. 이제 곧 기존에 사용하던 서재가 열릴 것이라고 생각했습니다. 하지만 화면에는 낯선 신규 가입 안내가 나타났습니다. 예전에 읽던 책과 대출 기록도 보이지 않았습니다.
본인인증은 성공했습니다. 그런데 서비스는 그 결과를 기존 계정에 붙이지 못했습니다. 현실의 사람이 누구인지는 확인했지만, 그 사람이 서비스 안에서 어느 계정을 사용해 왔는지는 별도로 찾아야 했기 때문입니다.
로그인과 본인확인은 화면에서 비슷한 절차처럼 보입니다. 둘 다 이름이나 전화번호를 입력하고, 인증번호를 받고, 성공 또는 실패라는 결과를 보여줍니다. 그러나 두 절차가 답하려는 질문은 다릅니다.
계정의 주인과 현실의 사람
로그인은 대체로 “이 계정을 통제하는 사람이 맞는가”를 확인합니다. 이용자가 아이디를 제시하고 비밀번호나 패스키 같은 인증수단을 사용하면, 서비스는 그 계정에 연결된 증거가 맞는지 판단합니다. 여기서 확인되는 대상은 서비스 안의 계정입니다.
본인확인은 온라인 계정 바깥의 현실 인물을 확인하려는 절차입니다. 서비스는 휴대전화 본인확인, 아이핀, 인증서, 신분증 확인 같은 외부 수단을 통해 이름이나 생년월일, 연령, 동일인 여부 등 필요한 정보를 확인할 수 있습니다. 어떤 방식과 정보가 사용되는지는 서비스 목적과 제도, 이용자가 선택한 수단에 따라 달라집니다.
개인정보 포털에서도 로그인과 본인인증은 서로 다른 기능으로 사용됩니다. 일부 업무는 별도 로그인 없이 본인인증만으로 진행할 수 있지만, 신청 내역을 계속 관리하는 기능에는 로그인 계정이 필요할 수 있습니다. 현실 인물을 한 번 확인하는 일과 서비스 안에서 지속적으로 이용 기록을 귀속할 계정을 운영하는 일이 다르기 때문입니다.
여권을 보여주는 장면을 떠올려보면 차이가 조금 선명해집니다. 여권은 현실의 특정 사람과 법적 이름을 확인하는 증거가 될 수 있습니다. 그러나 어느 쇼핑몰 아이디를 사용했는지, 어느 회사의 직원 계정에 속하는지, 어떤 전자책 서재가 그 사람의 것인지는 여권만으로 알 수 없습니다. 서비스 안의 계정과 현실의 인물을 대조하는 단계가 한 번 더 필요합니다.
본인확인도 여러 질문으로 나뉜다
본인확인이라는 말 안에도 서로 다른 목적이 섞여 있습니다. 어떤 서비스는 성인이 맞는지만 확인하면 됩니다. 어떤 곳은 법적 이름을 확인해야 하고, 한 사람이 반복 가입하는 것을 구별해야 할 수 있습니다. 기관 서비스라면 현실의 사람을 확인한 뒤에도 그 사람이 현재 어느 기관에 소속돼 있는지 다시 확인해야 합니다.
실명확인은 본인확인의 한 형태입니다. 법적 이름이나 그에 준하는 정보를 확인하는 데 초점이 있습니다. 연령확인은 일정 나이 이상인지 판단하는 데 필요한 정보만 볼 수 있습니다. 동일인 확인은 지금 확인된 사람이 예전에 확인했던 사람과 같은지를 대조합니다. 목적이 다르면 필요한 정보도 달라집니다.
본인확인에 성공했다는 문장은 모든 신원 정보가 완벽히 검증됐다는 뜻이 아닙니다. 서비스가 요청한 범위에서 확인 절차를 통과했다는 의미에 가깝습니다. 이름과 생년월일이 전달될 수 있고, 같은 사람을 구별하기 위한 정보가 사용될 수도 있지만, 서비스가 어떤 값을 받는지는 확인 방식과 동의, 계약 구조에 따라 달라집니다.
휴대전화 본인확인도 “지금 이 휴대전화를 들고 있는 사람이 계정 주인이다”라는 단순한 결론으로 끝나지 않습니다. 휴대전화의 명의자와 실제 사용자가 다를 수 있습니다. 가족 명의의 회선을 쓰거나 법인 휴대전화를 사용하는 경우가 있습니다. 문자 수신 여부와 명의 기반 본인확인도 구별해야 합니다. 인증번호 문자를 받을 수 있다는 사실과 통신사 가입 명의가 그 사람이라는 사실은 서로 다른 증거입니다.
확인 결과와 기존 계정을 대조하는 단계
본인확인을 마치면 서비스는 전달받은 결과를 기존 회원정보와 대조할 수 있습니다. 이 과정을 동일인 연결 또는 계정 매칭이라고 부를 수 있습니다. 서비스는 이름, 생년월일, 전화번호, 이메일, 별도의 동일인 구별값 등 자신이 보유하고 정당하게 사용할 수 있는 정보를 기준으로 기존 계정을 찾습니다.
문제는 현실의 한 사람이 서비스 안에서는 여러 모습으로 남아 있을 수 있다는 점입니다. 가입할 때 쓴 전화번호가 바뀌었을 수 있고, 개명 전 이름이 저장돼 있을 수 있습니다. 기관이 넘겨준 직원 명단의 표기와 본인확인 결과의 표기가 다를 수도 있습니다. 띄어쓰기나 영문 이름 순서처럼 사소해 보이는 차이가 자동 대조를 어렵게 만들기도 합니다.
처음 장면의 이용자에게 신규 가입 화면이 나타난 이유도 이런 구조에서 찾을 수 있습니다. 본인확인 시스템은 현실 인물을 정상적으로 확인했습니다. 하지만 서비스는 그 결과를 기존 전자도서관 계정과 안전하게 대조하지 못했습니다. 이름과 전화번호 중 하나가 달라졌거나, 예전 계정이 기관에서 일괄 생성한 식별자만 갖고 있었을 수 있습니다. 사실 확인 없이 어느 하나를 원인으로 단정할 수는 없지만, 실패 지점이 본인확인 그 자체가 아니라 계정 귀속 단계라는 사실은 구별할 수 있습니다.
서비스가 대조에 실패했다고 무조건 비슷한 이름의 계정을 붙이면 더 큰 문제가 생깁니다. 다른 사람의 이용 기록과 구매 내역이 노출될 수 있기 때문입니다. 자동 연결의 기준은 편리함보다 충분히 확실해야 합니다. 확신할 수 없다면 추가 정보를 요구하거나 고객센터의 검토로 넘기는 편이 안전합니다.
반대로 대조 기준이 지나치게 엄격하면 정상 이용자가 기존 계정을 찾지 못합니다. 전화번호 한 자리의 오래된 정보, 개명 전 이름, 기관 명단의 표기 방식 때문에 새로운 계정이 생길 수 있습니다. 결국 동일인 연결은 기술적인 문자열 비교만의 문제가 아닙니다. 틀리게 붙였을 때의 피해와 붙이지 못했을 때의 불편을 함께 조정하는 정책 문제입니다.
한 사람을 구별하는 값도 목적이 있다
본인확인 결과에는 서비스가 같은 사람을 대조하는 데 사용할 수 있는 값이 포함될 수 있습니다. 국내 온라인 서비스에서는 중복가입 확인이나 동일인 대조를 위한 식별정보가 활용되는 경우가 있습니다. 그러나 이런 값도 어디서나 통하는 사람의 영구 번호처럼 취급해서는 안 됩니다. 발급 구조와 사용 목적, 서비스가 보유할 수 있는 근거가 정해져 있고 필요한 범위 안에서 사용해야 합니다.
서비스가 동일인 대조값을 갖고 있더라도 기존 계정에 무조건 자동 귀속할 수 있는 것은 아닙니다. 과거 계정이 해당 값을 보유하지 않거나, 서로 다른 확인 체계에서 만들어진 값의 범위가 다를 수 있습니다. 여러 회원이 이미 잘못 합쳐져 있거나 가족이 한 계정을 공유해 온 경우도 있습니다. 기계적으로 같은 값이 나온다는 사실과 데이터 전체가 같은 사람의 것이라는 판단 사이에는 검토가 필요합니다.
반대로 전화번호와 이메일처럼 바뀔 수 있는 정보만으로 동일인을 판단하면 정상 이용자가 계정을 잃기 쉽습니다. 전화번호는 해지 뒤 다른 사람에게 배정될 수 있고 이메일 주소도 변경되거나 폐기될 수 있습니다. 서비스는 연락 수단, 로그인 아이디, 동일인 대조 기준을 가능한 한 구분해 설계해야 합니다. 한 값에 세 역할을 모두 맡기면 값 하나의 변화가 계정 전체를 흔듭니다.
회원 생성, 본인확인, 소속 확인은 따로 움직인다
기관용 서비스에서는 계정이 만들어지는 경로가 한 가지가 아닐 수 있습니다. 기관이 이용자 명단을 일괄 반입할 수도 있고, 관리자가 계정을 등록할 수도 있습니다. 이용자가 직접 가입한 뒤 기관 승인코드를 입력하거나, 기관 정보 시스템이 재직 여부를 확인해 줄 수도 있습니다. 통합인증으로 처음 들어온 순간 서비스 내부 계정을 새로 만드는 구조도 있습니다.
이 과정에서 회원 생성과 본인확인, 소속 확인, 권한 부여를 한 덩어리로 보면 오류를 설명하기 어렵습니다. 본인확인은 성공했지만 서비스 계정이 없을 수 있습니다. 계정은 있지만 현재 소속이 확인되지 않을 수 있습니다. 소속까지 맞지만 기관이 구매한 콘텐츠 범위에 포함되지 않을 수도 있습니다.
한 공공기관 전자도서관 이용자가 본인확인을 마치고도 자료를 열지 못했다고 가정해보겠습니다. 첫 번째 확인은 현실의 사람인지에 관한 것입니다. 두 번째는 그 결과가 어느 회원 계정에 귀속되는지에 관한 것입니다. 세 번째는 현재 해당 기관의 이용자인지에 관한 것입니다. 네 번째는 그 기관과 계정에 특정 자료를 열 권한이 있는지에 관한 것입니다.
이용자 화면에서는 모두 로그인 이후에 벌어지는 하나의 문제처럼 보입니다. 그러나 운영자는 단계를 나누어야 합니다. 본인확인 업체에 성공 기록이 있는지, 서비스 계정이 어느 값으로 생성됐는지, 기관 명단이 갱신됐는지, 권한 정보가 정상적으로 반영됐는지를 따로 확인해야 합니다.
이 구분은 고객 안내에도 영향을 줍니다. 이미 본인확인을 통과한 사람에게 같은 절차를 반복하게 해도 계정 대조가 실패한 문제는 해결되지 않습니다. 비밀번호를 다시 설정하게 해도 소속정보가 맞지 않으면 자료는 열리지 않습니다. 화면에서 어느 단계가 실패했는지 정확히 알려줄수록 이용자는 불필요한 인증을 덜 반복합니다.
본인인증을 했는데 다시 로그인하는 이유
본인확인이 끝난 뒤 서비스가 다시 로그인하라고 하면 중복 절차처럼 느껴집니다. 그러나 본인확인 결과는 특정 업무를 처리하기 위한 일회성 확인일 수 있습니다. 그 결과를 장기간 유지되는 서비스 계정으로 자동 전환하지 않을 수도 있습니다.
예를 들어 비회원이 개인정보 관련 신청을 하면서 본인확인을 할 수 있습니다. 이 경우 서비스는 신청 대상이 본인인지 확인하지만 새로운 회원 계정을 만들 필요는 없습니다. 반대로 신청 내역을 여러 달 동안 조회하고 수정하려면 별도의 계정과 로그인 상태가 필요할 수 있습니다.
본인확인과 로그인을 묶을 수도 있습니다. 확인 결과로 기존 계정을 찾고, 해당 계정에 새 인증수단을 등록하거나 일회성 로그인 상태를 발급할 수 있습니다. 하지만 이때도 내부적으로는 현실 인물 확인, 계정 대조, 로그인 상태 발급이 순서대로 일어납니다. 화면에서 한 번에 끝났다고 구조까지 하나인 것은 아닙니다.
서비스는 이 차이를 이용자에게 설명할 책임이 있습니다. “인증에 실패했습니다”라는 문구만으로는 휴대전화 명의 확인이 실패했는지, 기존 계정을 찾지 못했는지, 기관 소속이 맞지 않는지 알 수 없습니다. 서로 다른 실패를 한 문장으로 뭉치면 이용자는 같은 행동만 반복하게 됩니다.
본인확인이 권한을 보장하지는 않는다
현실의 사람임을 확인했다고 해서 모든 기능을 사용할 수 있는 것은 아닙니다. 성인이라는 사실을 확인해도 유료 구독이 생기지는 않습니다. 회사 직원임을 확인해도 모든 관리자 메뉴가 열려서는 안 됩니다. 기관 소속이 맞더라도 해당 기관이 구매하지 않은 콘텐츠까지 이용할 수는 없습니다.
본인확인은 시스템이 판단에 사용할 한 가지 증거를 제공합니다. 서비스는 그 증거를 어느 계정에 붙일지 결정하고, 계정의 소속과 상태를 확인하고, 요청한 기능에 필요한 권한을 다시 판단합니다. 이 단계가 분리되어 있기 때문에 한 곳의 성공이 뒤 단계의 성공을 대신하지 못합니다.
일반 이용자에게도 이 관점은 유용합니다. 본인인증을 마쳤는데 원하는 화면이 열리지 않을 때, 자신의 신원을 의심받았다고만 생각할 필요는 없습니다. 계정 귀속이나 소속정보, 이용 기간, 서비스 권한 중 다른 단계가 문제일 수 있습니다.
서비스 운영자에게는 더 직접적인 의미가 있습니다. 회원가입 화면을 설계할 때 “누구인지 확인하는 값”과 “어느 계정에 귀속할 값”, “무엇을 허용할 값”을 구분해야 합니다. 하나의 전화번호나 이메일을 세 역할에 모두 사용하면 정보가 바뀌었을 때 계정 복구와 동일인 대조, 권한 관리가 함께 흔들릴 수 있습니다.
처음의 이용자는 본인확인에 실패한 사람이 아니었습니다. 서비스가 현실의 사람과 오래된 계정을 안전하게 대조하지 못한 사람이었습니다. 이 차이를 알아야 문제를 엉뚱한 인증 단계로 돌려보내지 않을 수 있습니다.
본인확인은 현실의 사람을 확인하지만, 그 사람이 어떤 서비스 계정을 써야 하는지까지 결정하지는 않는다.
