데브크래프트님의 포스트

쇼핑몰 앱에서 배송지 변경 요청과 확정을 나누는 이유

가상의 쇼핑몰 앱에서 고객이 주문의 배송지를 A에서 B로 바꾸려 합니다. 새 주소를 입력하고 버튼을 눌렀다면, 화면에는 ‘변경 완료’라고 써도 될까요?

운영자가 확인한 뒤에만 주소를 바꾸는 서비스라면 아직은 아닙니다. 고객의 요청을 받은 것과 실제 주문에 새 주소를 적용한 것은 다른 단계입니다. 이 차이를 먼저 정하면 고객 안내뿐 아니라 관리자 업무와 저장할 정보도 함께 보입니다.

먼저 변경을 허용할 때와 담당자를 정합니다

이번 예시는 한 판매자가 직접 상품을 포장·발송하는 쇼핑몰입니다. 포장을 시작하기 전까지 배송지 변경을 요청할 수 있고, 운영자가 확인한 뒤 확정하는 방식으로 정해보겠습니다. 실제 고객 사례가 아닌 설계 예시이며, 모든 쇼핑몰이 따라야 하는 공통 정책은 아닙니다.

여기에는 운영 규칙도 하나 필요합니다. 요청을 받은 주문은 변경 가능 여부를 판단할 때까지 포장을 보류합니다. 고객에게는 확인 중이라고 안내하면서 운영자는 예전 주소로 계속 발송을 준비한다면, 요청을 받아둔 의미가 없어지기 때문입니다.

버튼을 보여줄 때뿐 아니라 요청을 실제로 받을 때도 현재 주문이 변경 가능한 상태인지 확인하도록 정합니다. 고객이 화면을 열어둔 사이 운영자가 포장을 시작했을 수도 있습니다.

요청한 주소와 확정된 배송지를 나눕니다

이 흐름을 세 단계로 나누고, 저장할 주소와 고객 안내, 포장의 다음 행동을 함께 적어보겠습니다.

• 요청 접수: 주문에 저장된 주소는 A로 유지합니다. 고객에게는 요청한 주소 B와 ‘확인 중’ 안내를 보여주고, 포장을 보류합니다.
• 변경 확정: 주문에 새 주소 B를 적용합니다. 고객에게 변경 완료와 확정된 주소 B를 보여준 뒤 포장을 재개합니다.
• 변경 불가: 주문 기록의 주소 A는 유지하지만 포장도 계속 보류합니다. 고객에게 사유와 문의 방법을 안내하고, 발송할 주소나 다음 처리 방법을 확인한 뒤 보류 해제 여부를 정합니다.

요청 접수 화면에서 주소 B를 보여주더라도, ‘요청한 주소’와 ‘실제 배송에 사용할 주소’가 구분돼야 합니다. 주문 내역의 주소를 먼저 덮어쓰고 운영자에게 나중에 확인하라고 하면, 어느 주소를 기준으로 처리할지 모호해집니다.

운영자는 같은 주문에서 기존 주소·요청 주소와 현재 포장 상태를 보고 판단합니다. 고객은 주문 내역에서 처리 결과와 주문에 저장된 주소를 확인할 수 있도록 합니다. 변경 불가는 기존 주소로 보내도 된다는 뜻이 아닙니다. 새 주소를 적용할 수 없다면 고객과 후속 처리를 정할 때까지 보류를 유지합니다.

관리자 화면에는 판단에 필요한 정보를 둡니다

‘주문 관리 기능’이라고만 적으면 주문 목록을 보여주는 것으로 끝날 수 있습니다. 이 예시에는 변경을 기다리는 주문을 찾고, 두 주소를 비교하고, 변경 가능 여부와 사유를 남기는 업무가 있습니다.

고객 앱에는 요청 접수와 처리 결과 안내가 필요합니다. 관리자에는 확인할 요청과 처리 기능이 필요하고, 데이터에는 주문에 적용된 주소와 별도로 요청한 주소·요청 시각·처리 결과가 남아야 합니다. 배송지 변경 하나도 이 세 범위를 함께 정해야 합니다.

첫 버전에서는 운영자가 직접 확인하고 처리하는 방식으로 시작할 수 있습니다. 다만 수동 처리라는 이유로 고객에게 결과를 알리는 일이나 확정 전 포장 보류까지 빠뜨리면 안 됩니다. 자동화 여부와 업무를 끝내는 기준은 따로 정해야 합니다.

개발 요청에는 버튼보다 처리 규칙을 적습니다

‘배송지 변경 기능을 넣어주세요’ 대신, 앞의 예시를 이렇게 전달할 수 있습니다.

포장 시작 전에는 배송지 변경을 요청할 수 있게 합니다. 요청을 받은 주문은 포장을 보류하고 운영자가 기존 주소와 요청 주소를 확인합니다. 확정하면 새 주소를 적용한 뒤 포장을 재개합니다. 변경할 수 없다면 사유를 안내하고 보류를 유지하며, 고객과 발송할 주소나 다음 처리 방법을 확인한 뒤 보류 해제 여부를 정합니다.

이 문장이 있으면 어떤 화면과 기록을 만들지, 누가 어떤 상태에서 처리할지 논의할 수 있습니다. 운영자가 확인하지 않아도 고객이 즉시 바꾸는 정책을 원한다면, 그에 맞춰 허용 조건과 처리 방법부터 달리 정하면 됩니다.

지금 준비 중인 앱의 버튼 하나를 골라보세요. 그 버튼은 요청을 받는 것인지, 실제 처리를 확정하는 것인지부터 적어보면 빠진 운영 업무를 찾는 데 도움이 됩니다.

고객 주문과 관리자 업무의 전체 범위를 함께 정리하고 싶다면 데브크래프트의 쇼핑몰 앱 개발 범위 가이드를 참고할 수 있습니다.

개발사가 ‘수정 완료’라고 했을 때, 발주자는 무엇을 보고 승인할까

“수정했습니다. 확인 부탁드립니다.”

이 연락을 받으면 어디까지 확인하고 승인해야 할지 망설여집니다. 발주자가 볼 것은 미리 합의한 결과입니다. 아래는 가상 예약 앱의 검수 예시입니다. 실제 고객 사례나 검수표 파일에 실린 동일 사례가 아니며, 예약 번호·날짜·증거 파일명도 설명을 위해 만들었습니다.

먼저 합의한 결과를 꺼냅니다

이 앱에서는 취소 가능한 예약을 고객이 취소하면 고객 화면과 관리자 목록 모두 ‘취소’ 상태가 된다고 이미 합의했습니다. 취소 버튼을 눌렀다는 사실만으로 이 항목을 승인할 수는 없습니다. 고객은 취소됐다고 보는데 운영자는 확정된 예약으로 보고 있다면, 합의한 결과가 아직 나오지 않은 것입니다.

최초 문제는 한 항목으로 남깁니다

‘예약 취소 후 두 화면의 상태 일치’라는 항목에 다음처럼 적습니다.

• 확인 조건: 테스트 환경, 테스트 고객 계정과 관리자 계정, 스마트폰의 고객 화면과 PC의 관리자 목록, 안정적인 네트워크. 취소 가능 시간이 남은 확정 예약 A-001.
• 실행 순서: 고객 계정으로 A-001 상세 화면 열기 → 취소 누르기 → 취소 확인 → 고객 예약 화면 다시 열기 → 관리자 목록 새로고침 후 A-001 찾기.
• 기대 결과: 같은 예약 번호가 고객 화면과 관리자 목록에서 모두 ‘취소’로 보인다.
• 실제 결과: 고객 화면은 ‘취소’, 관리자 목록은 ‘확정’. 목록을 새로고침한 뒤에도 두 화면의 상태가 다르다.
• 증거: 두 화면에서 예약 번호와 상태가 함께 보이도록 캡처하고, A001_고객_취소.png, A001_관리자_확정.png처럼 파일명을 남긴다.

이 기록에 수정 담당과 목표 수정일도 함께 적어 개발사와 공유합니다. 최초 결과를 지우지 않아야 무엇을 고쳤고 무엇을 다시 봐야 하는지 이어서 확인할 수 있습니다.

수정 뒤에는 새 예약으로 같은 순서를 확인합니다

개발사가 수정 내용을 테스트 환경에 반영했다고 안내하면, 취소 가능 시간이 남은 확정 예약 A-002를 새로 만듭니다. 이미 취소한 A-001을 다시 취소하지 않습니다. 예약 번호만 바꾸고 계정·기기·네트워크와 취소 가능 조건은 그대로 맞춰 앞의 순서를 실행합니다.

이 가상 예시의 수정 후 결과는 고객 화면 ‘취소’, 새로고침한 관리자 목록도 ‘취소’입니다. 같은 A-002를 보고 있는지 확인하고, 새 증거 파일명 A002_고객_취소.png, A002_관리자_취소.png를 최초 기록에 이어 남깁니다.

재확인 기록은 이렇게 적을 수 있습니다.

“재검수일: 2026-10-02. A-002로 동일 순서 실행. 고객·관리자 모두 취소 확인. 이 항목은 정상으로 확인해 승인. 확인자: 서비스 담당자.”

만약 관리자 목록이 여전히 ‘확정’이라면 항목 승인은 대기로 두고, 새 예약 번호·실제 차이·증거를 다시 기록합니다. 수정 완료 연락만으로 승인이 끝나는 것은 아닙니다. 이 한 항목의 승인은 앱 전체 출시 승인이나 계약상 검수 완료와도 다릅니다.

지금 맡은 기능 하나를 골라 “수정 완료 뒤, 어떤 조건에서 무엇을 실행하고 어느 화면의 어떤 결과를 다시 확인할까”를 한 문장으로 적어 보세요.

데브크래프트의 앱 개발 중간 검수표는 확인 조건·기대/실제 결과·재현 방법·증거·수정 담당·목표 수정일과 재검수일·최종 승인을 기록하는 데 사용할 수 있습니다. 이메일로 다운로드 링크를 한 번 받을 수 있고, 뉴스레터에 자동 등록되지 않습니다.

앱 개발 중간 검수표 보기