화면과 부록의 검사는 2026년 9월 3일 로컬 시험에서 얻었습니다. 인물·연락처·주소·거래는 모두 가상 정보이며, 캡처는 실제 앱 코드를 실행한 화면입니다. 운영 서버에는 연결하지 않았습니다. 시험 데이터는 화면을 새로 열 때 초기화되므로 이 캡처만으로 서버 저장이나 다른 기기 동기화를 입증할 수 없습니다. 9월 9일에는 회원 대조와 정산 확인 순서를 보완했습니다.
이름이 다르다고 고객을 새로 만들지는 않습니다
입력 기록에서는 닉네임을 고쳤는데 택배관리나 정산표에는 이전 이름이 남을 수 있습니다. 반대로 같은 닉네임이 두 줄로 보이더라도 실제로는 다른 고객이거나, 날짜·배송 조건이 다른 거래일 수 있습니다. 이름만 보고 중복이라고 판단해 회원을 지우면 기존 거래와의 연결을 잃을 위험이 있습니다.
먼저 하려는 일을 구분하세요. 거래의 구매자를 잘못 선택해서 바로잡는 일과 동일 고객의 닉네임 자체가 바뀐 일은 다릅니다. 이 글은 거래 수정창에서 구매자를 확인하고, 그 거래가 택배·정산에서 어떻게 보이는지 대조하는 방법을 다룹니다. 회원 전체 병합이나 과거 거래 일괄 변경을 권하는 글이 아닙니다.
수정 전에 대조할 네 가지
- 거래: 날짜·품목·금액으로 수정할 한 건을 찾고, 변경 전 구매자와 상품 수·합계를 남깁니다.
- 사람: 닉네임 전체와 고객명, 업무상 확인 권한이 있는 연락처·주소를 대조합니다. 후보 목록에 정보가 부족하면 회원정보에서 별도로 확인합니다.
- 변경 범위: 구매자를 잘못 선택한 거래인지, 같은 고객의 별칭 변경인지 구분합니다. 한 거래를 고치면서 다른 거래나 회원 전체를 함께 바꾸지 않습니다.
- 확신 여부: 연락처·주소가 충돌하거나 동명이인이 구분되지 않으면 저장을 멈춥니다. 검색 결과의 순서는 동일인 확인 근거가 아닙니다.
서로 다른 회원이 같은 닉네임을 쓸 수 있고, 한 회원이 여러 닉네임을 사용했을 수도 있습니다. 닉네임의 앞부분이 같다는 이유만으로 연결하거나 합산하지 마세요. 회원 병합·삭제가 필요하다면 거래 연결과 원본 보관을 확인하고 담당자의 별도 승인을 받아 진행해야 합니다.
가상 예시: 비슷한 자동완성 후보를 선택할 때
예를 들어 ‘시험구매자A’와 ‘시험구매자A-7’이 함께 검색되는 가상 상황을 생각해 보겠습니다. 원하는 대상이 뒤의 후보라면 끝의 ‘-7’까지 확인하고, 다른 회원정보와 대조한 다음 선택합니다. 이 후보 조합은 절차를 설명하기 위한 예이며, 위 캡처의 클릭 결과를 뜻하지는 않습니다.
- 지금 열린 수정창의 구매자 입력란에서 검색합니다. 배경의 다른 입력란에 후보가 뜬다면 선택하지 않습니다.
- 확인한 후보를 한 번 선택하고, 저장하기 전에 입력란에 들어간 닉네임 전체를 다시 읽습니다.
- ‘시험구매자A-7’을 골랐는데 ‘시험구매자A’로 들어갔다면 저장하지 말고 증상을 남깁니다. 반복 클릭으로 맞추려 하지 않습니다.
- 정확한 대상이 들어갔을 때 수정 범위를 확인하고 저장합니다. 저장 실패 안내가 있으면 성공한 것으로 취급하지 않습니다.
이미 저장한 뒤 다른 이름을 발견했다면 고객을 새로 등록하는 대신 해당 거래의 변경 전후 상태를 확인하세요. 단순히 보이는 이름만 바뀌고 거래가 연결된 회원은 이전 고객으로 남아 있는 문제인지 지원팀의 확인이 필요할 수 있습니다.
정상 결과: 이름뿐 아니라 품목 수와 합계도 맞아야 합니다
위 로컬 화면의 A는 거래 세 건, 구매 합계 60,000원, 결제완료 50,000원, 미수 10,000원입니다. 60,000원 = 50,000원 + 10,000원이라는 대조가 가능합니다. 같은 고객의 표시만 바로잡는다면 이름이 달라졌다는 이유로 품목이 빠지거나 총액이 늘어서는 안 됩니다. 반면 거래의 구매자를 다른 사람으로 정정했다면 기존 구매자와 새 구매자의 내역이 모두 맞는지 비교해야 합니다.
| 화면 | 정상 여부를 판단할 기준 |
|---|---|
| 입력·거래내역 | 수정 대상 한 건의 구매자가 의도한 사람이고, 다른 거래의 이름·금액은 유지됨 |
| 택배관리 | 같은 거래가 올바른 구매자에게 연결되고, 업무상 확인한 수령 정보와 맞음 |
| 정산·출력 미리보기 | 동일 기간으로 조회했을 때 품목 수·금액이 맞고, 같은 거래가 두 사람에게 중복 반영되지 않음 |
| 새로 조회한 화면 | 변경값이 유지되고, 비교한 화면 사이의 구매자 정보가 일치함 |
항목 수가 줄어든 것만으로 성공은 아닙니다. 서로 다른 고객이 섞이지 않았는지, 보존해야 할 닉네임이 본명으로 바뀌지 않았는지도 확인합니다. 같은 고객이라도 날짜나 배송 조건에 따라 나뉜 목록은 무조건 오류가 아니므로 조회 조건을 먼저 맞춥니다.
이럴 때는 수정·발송·정산을 멈추고 문의합니다
- 선택한 자동완성 후보와 실제 입력된 이름이 다릅니다.
- 입력·택배·정산에서 같은 거래가 서로 다른 고객으로 보입니다.
- 새로 조회하자 이전 닉네임이 다시 나타납니다.
- 수정 후 거래가 중복되거나 품목 수·금액이 예상과 다릅니다.
- 후보들의 연락처·주소가 달라 동일인인지 판단할 수 없습니다.
이때는 닉네임을 여러 번 바꾸거나 회원을 삭제하지 말고, 거래일·품목과 선택한 후보·실제 표시 결과를 고객지원에 전달해 주세요. 무관한 고객의 개인정보는 가리고 비밀번호·PIN·전체 고객명부는 보내지 않습니다. 배송이나 정산을 진행하기 전에 어느 회원에게 연결되어야 하는지 확인하는 것이 목적입니다.
이 문서의 근거는 자동완성 표시와 가상 정산 화면, 2026년 9월 3일의 연결 검사 3개·정산 검사 6개, 총 9개 로컬 검사입니다. 실제 고객정보를 변경하거나 운영 회원을 병합하지 않았습니다. 운영 서버 반영, 새로고침 후 유지, 다른 기기, 실제 정산 출력은 이 문서의 통과 범위가 아닙니다.
부록: 회원 연결과 정산의 로컬 검사
구매자 연결 검사 3개
2026년 9월 3일 실행한 record-edit-buyer-sync.test.mjs의 3개 검사가 통과했습니다. 시험에서는 서로 다른 두 회원 식별자를 사용해 아래 조건을 확인했습니다.
| 입력 방법 | 기대 결과와 통과한 검사 |
|---|---|
| 자동완성에서 새 회원 선택 | 이전 회원번호·고객명·유튜브명 사본을 함께 교체하고 택배·정산이 새 회원 식별자를 사용 |
| 닉네임 직접 입력 | 활성 회원 한 명과 정확히 일치할 때만 연결. 후보가 모호하면 이전 회원번호를 끌고 가지 않음 |
| 수정 모달에서 자동완성 | 현재 모달의 구매자 필드에 후보를 표시하고 저장 경로에서 식별정보 갱신 |
직접 입력에서 이전 회원번호를 제거하는 것은 회원 삭제와 다릅니다. 거래의 잘못된 연결을 남기지 않는 처리입니다. 회원을 실제로 삭제하거나 누구에게 과거 거래를 옮길지는 별도 확인과 승인 대상입니다.
구매자 정산 검사 6개
같은 날 settlement-buyer-identity.test.mjs의 6개 검사가 통과했습니다. 주요 조건은 다음과 같습니다.
- 같은 회원번호의 과거·현재 별칭 거래를 하나의 구매자 정산으로 합산합니다.
- 구매자 합산 때문에 서로 다른 판매자의 정산 묶음을 합치지 않습니다.
- 비활성 회원번호의 유튜브명이 활성 후보 한 명과 유일하게 일치하는 경우와, 후보가 둘인 경우를 다르게 처리합니다.
- 회원번호가 없는 거래도 유일한 연결 근거가 있는 경우를 검사합니다.
- 현장수령·개인용달 품목을 판매자 정산에서 잘못 제외하지 않습니다.
여기서 유일한 후보라는 것은 이름이 비슷하다는 뜻이 아닙니다. 같은 닉네임의 활성 회원이 둘이면 합산하지 않는 조건도 함께 검사했습니다. 표시가 같더라도 서로 다른 사람일 수 있고, 같은 사람이라도 정산 날짜가 다르면 화면 항목이 나뉠 수 있습니다.