APICK 성명 주민등록번호 실명확인 API의 안전한 연동 준비
이 글은 2026년 10월 28일 확인한 APICK 공개 화면과 공식 개발가이드를 바탕으로 한 실무 설계 예시입니다. 실제 회원가입 제출, API 키 발급, 인증서 등록, 유료 API 호출은 수행하지 않았으며, 예시를 실제 연동 성공 사례로 제시하지 않습니다.
입력받아도 되는 업무인지 먼저 확인합니다
특정 업무에서 성명과 주민등록번호의 일치 여부를 확인해야 한다는 요구가 생겼다고 가정해 보겠습니다. 이때 개발의 출발점은 입력창이 아니라 해당 업무가 주민등록번호를 처리할 수 있는지 검토하는 일입니다. 개인정보 보호법은 주민등록번호 처리에 별도의 제한을 두고 있으므로, 동의 체크박스를 추가했다는 이유만으로 처리 요건이 충족된다고 판단해서는 안 됩니다. 구체적인 적용 가능성은 개인정보·법무 담당자와 확인해야 합니다. 개인정보 보호법 제24조의2
이 글은 그 검토가 완료된 업무의 연동 준비를 설명합니다. 모든 회원가입이나 일반 고객 관리에 이 API를 추가하라고 권하는 내용은 아닙니다. 주민등록번호 없이 목적을 달성할 수 있는 다른 확인 수단이 있는지도 먼저 살펴보세요. APICK이 기능을 제공한다는 사실과 각 사업자가 특정 정보를 처리할 수 있는지는 구분해야 합니다.
가입과 인증키는 담당자의 관리 아래 준비하기
APICK 가입 화면에는 Google 가입과 다른 이메일 가입이 있습니다. 이메일 방식에서는 이메일·비밀번호·확인·이름 또는 회사명·전화번호, 동의 항목, reCAPTCHA를 확인합니다.
가입 뒤 시작하기의 인증키 확인 링크를 따르세요. 서버 환경변수 APICK_API_KEY에서 키를 읽어 Bearer 인증에 사용하며, 브라우저·모바일 앱·공개 저장소에 넣지 않습니다.
누가 키를 관리하고 어떤 서버에서 호출할지 먼저 정하세요. 개발자가 자신의 개인 계정으로 임의 시험을 진행하기보다 담당자 승인, 서비스 이용 조건, 비용, 사고 시 연락 경로를 정리한 뒤 준비하는 편이 좋습니다. 키가 유출되었을 때 중단과 교체를 담당할 사람도 미리 정해 두세요.
요청 항목을 알아도 바로 실행하지 않습니다
공식 API는 POST /rest/name_rrn_auth이며 form-data에 name, rrn1, rrn2를 사용합니다. 각각 성명, 주민등록번호 앞부분, 뒷부분을 전달하는 항목입니다. 정확한 필수 조건과 결과 해석은 최신 명세를 기준으로 검토합니다. APICK 성명 주민등록번호 실명확인 가이드
여기에는 실제처럼 보이는 주민등록번호나 복사해 실행할 수 있는 호출 코드를 넣지 않았습니다. 다음은 실행하지 않은 내부 설계 메모입니다. APICK이 제공하는 응답 필드나 상태 이름이 아닙니다.
도입 승인 조건 확인
→ 허용된 업무에서 필요한 항목만 입력
→ 우리 서버의 접근 권한 및 요청 목적 확인
→ 서버에서 공식 명세에 따라 처리
→ HTTP 상태와 업무 결과를 분리해서 해석
→ 화면에는 필요한 결과만 전달
→ 원문 정보의 보관 여부와 파기 조건 점검
금지할 예시: 요청 본문 전체 로그, 오류 추적 도구의 입력값 수집,
실제 주민등록번호를 넣은 화면 캡처, 테스트용 타인 정보 사용
입력값을 뒷단까지 전달하는 경로도 살펴봐야 합니다. 브라우저 분석 스크립트, 세션 재생 도구, 프록시 접근 로그, 오류 보고서, 개발자 디버그 출력이 입력 내용을 수집하지 않는지 점검하세요. 전송을 암호화해도 애플리케이션이 원문을 로그에 남기면 별도의 노출 경로가 생깁니다. 민감한 입력을 URL의 쿼리 문자열로 보내는 설계도 피해야 합니다.
일치 결과와 업무 승인을 혼동하지 않기
성명과 번호를 확인하는 결과만으로 현재 화면을 조작하는 사람이 그 명의자라는 사실, 해당 계약에 동의했다는 사실, 거래 권한까지 모두 확인되었다고 판단해서는 안 됩니다. 필요한 본인 확인이나 권한 확인 절차는 업무 요구와 제공 조건에 맞춰 따로 검토해야 합니다. 이 API의 결과를 어디에 사용할지 업무 담당자와 먼저 합의해야 하는 이유입니다.
우리 화면의 상태는 확인 자료 수신, 입력 재확인, 처리 일시 불가처럼 설계할 수 있습니다. 이는 내부 상태 예시일 뿐 실제 APICK 응답값이 아닙니다. 오류가 난 경우에는 사용자를 허위 정보 제출자로 단정하지 말고, 입력 수정이 필요한 상황과 서비스 확인이 지연된 상황을 나누세요. HTTP 응답을 받았다는 사실만으로 최종 업무 처리가 성공한 것으로 판단하지 않습니다.
출시 전에는 데이터가 남는 곳부터 시험하세요
시험을 시작할 때는 APICK과 승인된 테스트 방법을 확인하고, 임의로 만든 주민등록번호나 직원·고객의 실제 정보를 입력하지 않습니다. 입력 취소, 잘못된 형식, 결과 없음, 응답 지연, 화면 재시도 상황을 검증하면서 로그·알림·분석 도구에 원문이 남지 않는지도 함께 확인합니다. 오류 추적을 위해 필요한 내부 요청 번호와 처리 시각은 개인정보 원문과 분리해 관리하는 방식을 검토하세요.
운영 문서에는 수집 목적, 접근 가능한 역할, 보관 필요성, 파기 방식, 문의 대응 시 가릴 항목을 정리합니다. 보관 기간이나 법적 근거를 API 문서만 보고 정하지 말고, 해당 업무에 적용되는 기준을 담당자가 확정해야 합니다. 이 글은 특정 사업자의 적법성을 판정하거나 주민등록번호 수집을 허용하는 법률 의견이 아닙니다.
업무상 처리 가능 조건을 확인했다면 APICK 공식 명세로 필요한 입력과 결과 범위를 검토해 보세요. 실명확인 개발가이드에서 시작해 가입·키 관리·데이터 보호 설계를 준비하고, 별도 승인된 시험으로 연동을 확인하는 순서를 권합니다.
확인 범위: 2026년 10월 28일 공개 문서와 가입 UI를 확인했습니다. 회원가입 완료, API 키 발급, 실제 API 호출은 실행하지 않았고 실제 주민등록번호도 사용하지 않았습니다. 이 글의 이미지는 공개 화면이며 실제 키 화면이나 실행 결과를 포함하지 않습니다.
#APICK #에이픽 #실명확인API #성명확인 #개인정보보호 #서버연동 #API개발
댓글
댓글 쓰기