주소를 코드로 연결하기: APICK 주소 표준화에서 confidence를 읽는 법
이 글은 에이픽 운영 측에서 AI의 도움을 받아 작성한 서비스 소개입니다. 공식 공개 문서를 확인했으며, 실제 고객 데이터 조회나 유료 API 실행 결과를 제시하는 체험 후기는 아닙니다.
같은 지점의 주소가 영업팀 자료에는 도로명으로, 운영팀 목록에는 지번으로 남아 있으면 지역별 집계부터 어려워집니다. 에이픽 주소 표준화·코드 변환 API는 주소 표기와 지역 코드를 연결하는 기능을 제공합니다. 단순히 글자를 정리하는 작업을 넘어 어떤 항목까지 확인됐는지 함께 관리하는 지점 기준정보 설계를 살펴보겠습니다.
1. 원래 주소와 표준 결과를 별도로 둡니다
지점 번호, 원래 입력 주소, 표준 주소, 확인 상태를 각각 보관하는 표부터 준비하세요. 원래 입력을 바로 덮어쓰면 담당자가 왜 다른 표기로 바뀌었는지 확인하기 어렵습니다. 예를 들어 도로명으로 받은 지점을 지번 기준으로 확인했다면 두 표기를 연결하되 하나를 없애지 않는 편이 검토에 유리합니다.
공식 요청은 address와 pnu 중 하나를 받습니다. 주소를 기반으로 표준화할 것인지 이미 가진 필지번호를 코드 구조로 변환할 것인지 목적을 먼저 정하세요. 이 두 방식은 결과가 같다고 볼 수 없으므로 화면에서도 “주소 확인”과 “필지번호 변환”을 구분해 안내하는 것이 좋습니다.
2. PNU 입력을 좌표 조회와 혼동하지 않습니다
유효한 19자리 pnu가 전달되면 address보다 우선하며, 좌표 조회 없이 코드와 지번을 만든다고 문서에 안내돼 있습니다. 이 경우 confidence는 code이고 좌표·주소 표기·우편번호가 제공되지 않는 범위가 있습니다. 필지번호만 넣고 지도 표시까지 완료됐다고 처리하지 않도록 결과 상태를 나눠 두세요.
코드 값은 숫자로 계산할 대상이 아니라 식별자이므로 내부 저장 형식을 신중히 정합니다. 지점 집계에서 어떤 지역 코드가 필요한지도 미리 확인하세요. 법정동과 행정동은 응답에서 구분된 항목이므로, 이름이 비슷하다는 이유로 서로 대체해 쓰기보다 각 업무가 사용하는 기준을 명확히 적어 두면 됩니다.
3. confidence와 warnings를 검토 화면에 연결합니다
공식 confidence 안내는 exact, refined, partial, code를 구분합니다. exact는 입력 유형으로 필지번호까지 확인한 경우, refined는 다른 유형으로 보정해 찾은 경우이며 partial은 좌표를 찾았지만 필지번호를 확인하지 못한 경우입니다. 이를 전부 “검증 완료” 한 상태로 합치면 후속 업무에 필요한 차이가 사라집니다.
예를 들어 지도에 후보 지점을 표시하는 업무는 좌표를 우선 볼 수 있지만, 필지 기준으로 자료를 연결하는 업무는 누락된 필지번호를 추가 확인해야 합니다. warnings의 안내를 해당 행 옆에 보여 주고, 담당자가 보완할 항목을 바로 알 수 있게 구성하세요. API의 확인 수준을 우리 업무의 완료 기준과 연결하는 단계입니다.
4. 지점 기준정보의 변경 이유를 남깁니다
주소를 새로 확인했을 때는 이전 표기와 달라진 코드, 담당자 검토 여부를 함께 남기는 방식을 권합니다. 주소가 바뀐 이유는 이전 입력 오류일 수도 있고 실제 이전일 수도 있으므로 결과만 보고 임의로 지점 이동 이력을 만들면 안 됩니다. 업무 담당자가 확인한 사실과 자동 변환 결과를 구분해 보관하세요.
처음에는 공개된 자사 지점 몇 곳처럼 사용 범위가 분명한 자료로 표준화 표를 검토해 보세요. 개인 주소를 불필요하게 섞거나 실제 자료를 테스트 로그에 복사하지 않습니다. 정리의 목표는 모든 칸을 억지로 채우는 것이 아니라, 연결할 수 있는 코드와 아직 확인할 내용을 분명히 만드는 것입니다.
주소 표준화 개발가이드의 PNU 입력 방식과 confidence 표를 먼저 확인해 보세요. 지점 자료를 합치는 데 필요한 기준을 더 명확하게 잡을 수 있습니다.
공식 안내
공식 공개 자료와 화면을 바탕으로 작성했습니다. 화면별 촬영일은 캡션에 표시했습니다. 현재 이용 조건은 공식 안내에서 확인해 주세요.
댓글
댓글 쓰기