신분증 확인 요청이 밀릴 때: 에이픽 API로 반복 조회와 예외 검토를 나누는 시나리오

에이픽 API 활용 시나리오 · 이 글은 가상 업무 사례입니다. 실제 고객의 도입 후기나 처리시간 실측이 아닙니다. API 명세는 2026-11-05 공식 문서를 기준으로 확인했습니다.

마감 직전 쌓인 확인 요청, 담당자가 모든 화면을 다시 열어야 할까요?

적법하게 신분증 진위 확인이 필요한 업무라고 가정해 보겠습니다. 신청은 낮에 계속 들어오는데 확인은 저녁에 몰립니다. 담당자는 서류를 열고 입력 내용을 옮긴 뒤 결과를 메모합니다. 다음 날에는 “조회는 됐는데 확인은 통과했나요?”라는 질문이 다시 돌아옵니다.

이 시나리오의 목표는 검토자를 없애는 것이 아닙니다. 반복 조회와 결과 옮겨 적기를 서버에 맡기고, 사람은 추가 확인이 필요한 신청을 먼저 볼 수 있도록 흐름을 바꾸는 것입니다.

상품과 개발가이드로 이동하는 에이픽 공개 홈. 당시 메뉴 화면이며 현재 상품 수를 뜻하지 않습니다. 2026-10-28 보관 화면, 공개 이미지 접근 및 내용 확인 2026-11-05.

에이픽을 붙이는 위치는 접수 화면 뒤쪽입니다

고객 브라우저에서 인증키를 보내지 않고 서비스 서버에서 APICK을 호출합니다. 입력값을 받은 서버가 진위 조회를 요청하고, 결과에 따라 확인 완료 또는 수동 검토 대기 상태로 나눕니다. 공개 블로그·메신저·로그에 이름이나 주민번호를 남기는 방식은 피합니다.

주민등록번호 처리가 허용되는 업무인지와 제공 근거를 먼저 확인해야 합니다. 단순 동의 문구만으로 모든 처리가 허용된다고 가정하지 말고, 필요한 범위와 보관기간을 정한 뒤 연동하세요.

계정 준비 단계에서 만나는 빈 회원가입 양식. 정보 입력이나 가입 실행 화면이 아닙니다. 2026-10-28 보관 화면, 공개 이미지 접근 및 내용 확인 2026-11-05.

1. 계정과 서버 인증 준비

apick.app에서 계정을 준비하고 개발가이드의 인증키 안내를 확인합니다. 키는 서버 환경변수 APICK_API_KEY로 읽게 합니다. 실제 키를 게시물이나 소스 저장소에 붙여 넣지 않습니다. 인증 상태를 확인하는 공통 예제와 상품의 진위 판정은 별도 단계입니다.

서버 환경변수에 인증키를 보관하는 공통 시작 가이드. 실제 키 값은 없는 공개 문서입니다. 2026-10-28 보관 화면, 공개 이미지 접근 및 내용 확인 2026-11-05.

2. 주민등록증 진위확인 요청

이 글은 텍스트 기반 주민등록증 API를 다룹니다. 이름, 주민번호 앞·뒷자리, 발급일자 네 필드가 필요합니다. 아래 코드는 개인정보를 비공개 표식으로 바꾼 구조 설명이며 그대로 실행해 성공하는 샘플이 아닙니다. 실제 개인정보를 사용한 호출은 수행하지 않았습니다.

# 실행하지 않은 연동 구조 예시. 대괄호 값은 실제 개인정보가 아닙니다.
curl --fail-with-body --request POST 'https://apick.app/rest/identi_card/1' \
  --header "Authorization: Bearer $APICK_API_KEY" \
  --form-string 'name=[이름 비공개]' \
  --form-string 'rrn1=[앞자리 비공개]' \
  --form-string 'rrn2=[뒷자리 비공개]' \
  --form-string 'date=[발급일자 비공개]' 

공통 연결 확인용 /rest/info의 정적 cURL 화면. 아래 상품 API의 호출 결과가 아닙니다. 2026-10-28 보관 화면, 공개 이미지 접근 및 내용 확인 2026-11-05.

3. 응답을 업무 상태로 바꾸기

아래는 공식 정적 성공 예시에서 판정에 필요한 필드만 발췌한 JSON입니다. 요청 식별번호와 과금 기록번호, 예시 처리시간은 제외했습니다. 실제 호출 로그가 아닙니다.

{
  "data": {
    "type": 1,
    "result": 1,
    "msg": "",
    "success": 1
  },
  "api": {
    "success": true,
    "cost": 40
  }
}

data.error 유무를 먼저 살피고 data.result로 판정합니다. result=1은 일치, 0은 불일치입니다. 특히 불일치도 조회가 정상 완료됐다면 data.success=1일 수 있으므로 success만 보고 확인 완료로 바꾸면 안 됩니다. 2·3은 판정 미확정 또는 시간 초과로 구분해 별도 검토·재시도 흐름으로 보냅니다.

밤의 반복 입력 대신, 예외를 검토하는 운영으로

연동 후에는 신청별 상태, 마지막 확인 시각, 재확인 필요 사유를 관리 화면에서 보도록 설계합니다. 같은 요청을 무조건 반복 호출하기보다 이미 처리한 요청인지 점검하고, 중단된 작업만 담당자가 확인하도록 만듭니다.

얼마나 빨라지는지는 실제 요청 수와 외부 응답시간, 검토 비율을 재야 알 수 있습니다. 도입 전후의 담당자 작업시간과 재입력 건수를 비교하면 개선을 확인할 수 있습니다. 진위조회 하나로 명의도용이나 모든 사기가 차단되는 것도 아닙니다. 결과는 정해진 확인 절차의 한 단계로 사용하세요.

에이픽으로 반복 조회를 서비스 안에 연결하고, 담당자는 확인이 필요한 지점에 집중해 보세요.

공식 명세: 에이픽 개발가이드. 실제 적용 전 최신 필드·요금·이용 조건을 확인하세요.