조회 검토 화면을 키보드로 끝까지 사용할 수 있는지 확인하는 법
에이픽(APICK)을 운영하며 작성한 AI 보조 홍보 글입니다. 아래 내용은 애플리케이션 설계 제안이며, 에이픽이 해당 기능을 기본 제공한다는 설명이나 실측 결과가 아닙니다.
신규 판매자를 받는 플랫폼에서 사업자 정보 확인은 유용한 접점입니다. 그러나 조회가 완료되었다는 사실만으로 상품 취급 기준, 계약 조건, 정산 준비까지 충족되었다고 말할 수는 없습니다. 조회 결과와 입점 상태를 같은 칸에 저장하면 담당자는 무엇이 끝났는지 알기 어렵고, 신청자는 판매를 시작해도 된다고 오해할 수 있습니다.
두 종류의 상태를 따로 설계하기
우리 애플리케이션에서는 정보 확인 상태와 입점 업무 상태를 분리하는 구성을 제안합니다. 정보 확인에는 확인 전, 조회 중, 결과 수신, 추가 확인 필요 같은 내부 표현을 사용할 수 있습니다. 입점 업무에는 작성 중, 제출됨, 검토 중, 보완 요청, 승인 같은 별도 흐름을 둡니다. 이 명칭들은 설계 예시이며 에이픽의 응답 코드가 아닙니다.
예를 들어 가상의 생활용품 판매자가 사업자 정보를 확인했지만 반품 주소를 제출하지 않았다면, 조회 결과는 보관하면서 입점은 보완 요청으로 남길 수 있습니다. 반대로 담당자가 계약 검토를 끝냈어도 조회가 실패했다면 어떤 확인 절차가 남았는지 분명히 보여 줍니다. 한쪽 상태를 바꿀 때 다른 쪽을 자동으로 바꿔야 하는지에 대해서는 명시적인 규칙을 작성하세요.
승인 이유를 나중에도 설명할 수 있게
운영팀이 사용하는 검토 카드에는 입력 정보, 조회 결과의 출처와 시각, 남은 업무, 판단 이유를 나눠 표시하는 편이 좋습니다. 원문 전체를 한꺼번에 보여 주기보다 현재 검토에 필요한 항목부터 배치하세요. 실제 API가 어떤 항목을 제공하는지는 도입 전에 최신 명세로 확인해야 하며, 없는 항목을 화면 기획의 전제로 삼으면 안 됩니다.
정책이 바뀔 때도 과거 승인 이력을 덮어쓰지 않도록 주의합니다. 당시 적용한 내부 정책 버전과 담당자의 판단 근거를 연결하면 예전 결과를 재검토할 때 도움이 됩니다. 예외 승인이 필요하다면 누가 어떤 이유로 허용했는지를 기록하되, 불필요한 신분증 사본이나 사생활 정보를 메모에 남기지 않도록 입력 안내를 마련하세요.
팀 회의에서 먼저 합의할 질문
- 조회 결과만으로 진행할 수 있는 단계와 사람의 검토가 필요한 단계는 어디인가.
- 입력 내용과 조회 내용이 다를 때 사용자에게 어떤 보완 경로를 제공할 것인가.
- 결과를 받지 못한 신청은 대기, 재조회, 별도 확인 중 어느 흐름으로 이동하는가.
- 승인 이후 변경 사항을 발견하면 기존 이력을 유지하면서 어떻게 재검토할 것인가.
이 네 가지를 먼저 정하면 개발자는 불분명한 예외를 코드에서 임의로 판단하지 않아도 됩니다. 신청자에게도 접수 완료와 승인 완료를 다른 문구로 안내할 수 있습니다. 다만 이런 설계가 심사의 적법성이나 거래 안전을 자동으로 확보해 주는 것은 아닙니다. 업종과 업무에 필요한 확인 기준은 담당 전문가와 별도로 검토하고, 조회 데이터는 그 판단에 필요한 하나의 근거로 사용하세요.
에이픽 도입을 검토한다면
에이픽은 사업자정보, 신분증 진위확인, 법인·부동산 등기 관련 서비스를 공개 홈페이지에서 안내합니다. 에이픽 데이터 상품 살펴보기에서 도입 후보를 찾고, 실제 지원 범위·최신 명세·이용 조건을 확인한 뒤 적용하세요.
댓글
댓글 쓰기