
채용 플랫폼에서 지원자의 신분증을 확인하는 과정은 단순히 이미지를 업로드받는 것으로 끝나지 않습니다. 제출된 신분증이 실제 발급된 문서인지, 입력된 정보와 문서의 내용이 일치하는지 확인하는 절차가 필요합니다. 이를 위해 플랫폼 내부 시스템과 신분증 진위확인 기능을 API로 연결하면 지원자가 제출한 정보를 별도의 확인 과정으로 전달하고 결과를 다시 채용 시스템에 반영할 수 있습니다. 특히 온라인 채용에서는 지원자와 인사담당자가 직접 대면하지 않는 경우가 많아 서류 제출 단계에서부터 신원정보를 확인할 수 있는 구조를 설계하는 것이 중요합니다.
지원자가 촬영한 신분증 이미지에는 이름과 생년월일, 식별번호 등 다양한 정보가 포함될 수 있습니다. API 연동 과정에서는 문서에서 필요한 항목을 읽어내는 OCR 과정과 해당 정보의 진위 여부를 확인하는 절차를 구분해서 설계하는 것이 중요합니다. OCR은 이미지에 적힌 문자를 읽는 기능이므로 글자가 정상적으로 추출됐다고 해서 신분증 자체의 유효성이 확인되는 것은 아닙니다. 따라서 이미지 판독 결과와 진위확인 결과를 별도의 값으로 관리하면 각 단계에서 발생한 오류를 구분하기 쉬워집니다.

외부 진위확인 서비스를 연동하는 경우 API 응답을 채용 플랫폼 내부에서 처리하는 방식도 중요한 설계 요소가 됩니다. 성공과 실패만 단순하게 저장하기보다 어떤 검증 단계에서 문제가 발생했는지를 구분할 수 있는 응답 체계가 필요합니다. 예를 들어 입력값 오류와 문서 판독 실패, 진위확인 결과 불일치 등은 이후 처리 방식이 달라질 수 있습니다. 인사담당자 화면에는 필요한 결과만 표시하고 시스템 내부에서는 세부 상태값을 관리하는 식으로 구성하면 업무 과정에서 불필요한 개인정보 노출을 줄이는 데도 도움이 됩니다.

신분증 진위확인 API를 호출하기 전에 제출된 이미지의 상태를 확인하는 단계도 필요합니다. 흐릿하거나 일부가 잘린 사진은 문서 정보를 제대로 읽지 못할 수 있고 반사광 때문에 특정 영역이 가려질 수도 있습니다. 촬영 품질 문제와 실제 신분증 검증 실패를 같은 결과로 처리하지 않는 구조가 중요합니다. 이미지가 기준에 미치지 못하면 지원자에게 다시 촬영하도록 안내하고, 정상적인 이미지가 확보된 경우에만 다음 검증 단계로 넘기는 방식입니다. 이렇게 하면 외부 API에 불필요한 요청이 반복되는 것도 줄일 수 있습니다.

채용 과정에서는 지원자가 직접 입력한 이름이나 생년월일 등의 정보와 신분증에 표시된 정보가 함께 존재할 수 있습니다. 이때 두 정보가 서로 다른 경우 어느 단계에서 불일치가 발생했는지를 확인할 수 있어야 합니다. 단순한 오타나 입력 형식의 차이와 실제 신원정보의 불일치는 구분해서 처리할 필요가 있습니다. 따라서 API 결과를 받은 뒤 플랫폼 자체의 지원자 정보와 대조하는 후속 로직을 별도로 두는 방법이 적합합니다. 특히 자동으로 탈락시키기보다 확인이 필요한 사례를 별도로 분류하는 구조도 업무 목적에 따라 고려할 수 있습니다.
신분증 진위확인은 민감한 개인정보를 다루는 과정인 만큼 결과를 얼마나 오래 보관할지도 API 설계와 함께 검토해야 합니다. 검증에 사용한 원본 이미지와 추출된 정보, 단순한 검증 결과값은 서로 다른 보관 기준을 적용할 수 있습니다. 채용 절차가 종료된 뒤에도 원본 신분증 이미지가 계속 필요한지, 결과 기록만 남기면 되는지 등을 서비스 운영 기준에 맞춰 정해야 합니다. 또한 API 요청 과정에서 전달되는 개인정보가 어떤 시스템을 거치는지 확인하고 접근 권한과 로그 관리 범위도 함께 설계할 필요가 있습니다.
모든 지원자의 신분증이 한 번에 정상적으로 확인되는 것은 아닙니다. 촬영 상태가 좋지 않거나 일시적인 시스템 오류가 발생할 수도 있고, 입력정보와 문서 정보가 맞지 않아 추가 확인이 필요한 경우도 있습니다. 이러한 예외를 하나의 ‘실패’ 상태로 묶지 않고 재촬영, 정보 수정, 수동 검토 등 후속 절차와 연결하는 것이 실제 서비스 운영에서 중요합니다. API 응답이 지연되거나 일시적으로 사용할 수 없는 상황에 대비해 요청 상태를 저장하고 재처리할 수 있는 구조도 함께 검토해야 합니다.
