화면과 부록의 검사는 2026년 9월 3일 로컬 시험에서 얻었습니다. 인물·연락처·주소·거래는 모두 가상 정보이며, 캡처는 실제 앱 코드를 실행한 화면입니다. 운영 서버에는 연결하지 않았습니다. 시험 데이터는 화면을 새로 열 때 초기화되므로 이 캡처만으로 서버 저장이나 다른 기기 동기화를 입증할 수 없습니다. 9월 9일에는 현장 확인 순서와 설명을 보완했습니다.
이전 값이 보이면 먼저 같은 거래인지 확인합니다
판매자명을 수정했는데 이전 이름으로 보이거나, 발송완료를 눌렀는데 다시 발송대기로 보이는 경우가 있습니다. 수정창이 닫혔다는 사실만으로 저장 완료를 판단하면 안 됩니다. 저장 요청이 실패했을 수도 있고, 다른 날짜나 사업장의 거래를 보고 있을 수도 있으며, 다른 담당자가 같은 거래를 변경했을 수도 있습니다. 화면만 보고 원인을 하나로 단정하지 않는 것이 먼저입니다.
같은 고객이나 거래를 새로 만드는 것은 해결 방법이 아닙니다. 원래 거래가 남아 있다면 중복 매출이나 이중 발송으로 이어질 수 있습니다. 저장 실패 안내가 있거나 값이 서로 다를 때는 반복 저장보다 현재 상태를 기록하는 편이 안전합니다.
원본을 바꾸지 않고 확인하는 순서
- 변경 전 값과 입력한 값, 거래일·품목·금액, 작업 시각을 메모합니다. 오류 안내가 있으면 함께 남깁니다.
- 저장 중인 상태라면 버튼을 연속해서 누르지 않습니다. 성공·실패 안내를 구분하고, 수정창이 닫힌 것만으로 성공 처리하지 않습니다.
- 저장하지 않은 입력이 남아 있으면 필요한 내용을 먼저 메모합니다. 미저장 입력을 잃을 수 있는 상태에서 바로 새로고침하지 않습니다.
- 선택한 사업장과 날짜·검색 조건을 확인합니다. 이름이 같다는 이유만으로 다른 품목의 거래와 비교하지 않습니다.
- 미저장 입력이 없는 상태에서 새로 조회한 뒤, 같은 거래의 해당 값만 대조합니다.
- 다른 기기는 접근 권한이 있는 담당자가 같은 사업장·날짜의 거래를 새로 조회하도록 합니다. 비밀번호나 PIN을 공유하지 않습니다.
다른 담당자가 작업 중이었다면 마지막으로 누가 어떤 값을 저장했는지도 확인합니다. 두 기기에서 값이 다르면 둘 중 하나를 임의로 정답으로 삼아 덮어쓰지 말고, 아래 기준으로 어느 단계에서 달라졌는지 기록하세요.
가상 예시: 머그컵 거래의 판매자명을 고친 경우
다음은 확인 방법을 설명하는 가상 상황입니다. 머그컵 한 건의 판매자를 ‘시험판매자A’에서 ‘시험판매자B’로 바로잡았다고 가정합니다. 확인 대상은 그 거래의 판매자입니다. 같은 이름이 다른 거래에도 있다는 이유로 함께 수정하지 않습니다. 금액·구매자·배송 상태는 이번에 바꾸지 않은 값이므로 그대로 남아 있어야 합니다.
| 비교 지점 | 정상이라면 확인할 내용 | 문제가 의심되는 경우 |
|---|---|---|
| 입력·거래내역 | 같은 머그컵 거래의 판매자가 B이고, 상품 수와 금액은 이전과 같음 | 새 거래가 추가되거나 금액까지 달라짐 |
| 새로 조회한 화면 | 동일 사업장·날짜·거래에서 B가 유지됨 | 다른 변경 작업이 없는데 A로 돌아옴 |
| 정산·출력 미리보기 | 해당 기간의 그 품목이 B의 판매 내역에 반영됨 | A와 B에 중복으로 잡히거나 품목이 빠짐 |
| 다른 담당자의 화면 | 새로 조회한 동일 거래의 값이 일치함 | 같은 조건으로 조회해도 값이 다름 |
발송 상태를 바꾼 경우에도 확인 방식은 같습니다. 거래를 구분한 뒤 택배관리와 거래내역의 상태를 비교합니다. 일괄처리는 전체 성공 안내만 보지 말고, 실패한 항목이 남아 있는지와 실제 처리된 건수가 맞는지도 확인합니다.
값이 계속 다르면 작업을 멈추고 이 정보를 전달합니다
새로 조회할 때마다 값이 바뀌거나, 서로 다른 고객·금액으로 보이거나, 삭제했던 거래가 다시 보이면 해당 거래의 재입력·재삭제·일괄처리를 멈추세요. 발송과 정산을 이어가기 전에 고객지원으로 확인을 요청합니다.
- 어느 화면에서 어떤 버튼을 눌렀는지와 대략적인 시각
- 거래를 찾을 날짜·품목·거래번호 등 최소 식별 정보
- 변경 전·후 값과 새로 조회했을 때의 값
- 오류 안내, 비교한 화면의 사업장·날짜 조건, 다른 담당자의 동시 수정 여부
캡처에서 무관한 고객의 이름·연락처·주소는 가리고, 비밀번호·PIN·전체 고객명부는 보내지 않습니다. 저장 실패를 의도적으로 재현하는 시험은 운영 고객 거래가 아닌 격리된 시험 환경에서 해야 합니다.
검증 한계: 아래 11개 로컬 검사 통과는 지정된 조건에 대한 코드 근거입니다. 실제 데이터베이스 상태, 네트워크 단절, 배포된 버전과 다른 기기의 동작을 모두 확인한 결과는 아닙니다. 따라서 이 글은 ‘모든 저장 오류 해결’을 보장하지 않으며 운영 저장 성공률이나 복구 건수도 제시하지 않습니다.
부록 1: 저장 응답에 대한 로컬 검사 7개
2026년 9월 3일 record-edit-ack.test.mjs의 아래 7개 조건이 통과했습니다. 여기서 서버 응답은 시험 코드가 통제한 모의 응답입니다. 실제 PostgreSQL이나 운영 API에 요청한 통합 시험은 아닙니다.
| 시험 조건 | 검사한 결과 |
|---|---|
| 응답이 아직 오지 않음 | 현재 거래를 먼저 확정하거나 성공 모달을 닫지 않음 |
| 일괄 수정 일부 실패 | 성공 대상만 반영, 실패 대상의 기존 값 유지 |
| 일괄 수정 초안 생성 | 응답 전 원본 거래를 변경하지 않음 |
| 응답 전에 사업장 전환 | 이전 사업장의 늦은 응답을 적용하지 않음 |
| 기존 거래에 서버 ID가 없음 | 정본을 조회하고 수정 의도를 적용해 제출 |
| 서버 ID는 있지만 버전이 없음 | 최신 버전을 읽고 수정 의도 보존 |
| 버전 충돌 응답(409) | 다른 최신 필드는 보존하고 사용자가 바꾼 필드만 한 번 재시도 |
마지막 조건은 ‘어떤 충돌이든 무조건 덮어쓴다’는 뜻이 아닙니다. 이 검사에서 확인한 것은 거래 수정 경로의 제한된 재시도 규칙입니다. 발송 직전에 미수로 바뀌는 등 작업 자격이 달라진 상황은 별도 경로와 검사로 다룹니다.
부록 2: 삭제 이력에 대한 로컬 검사 4개
같은 날 ledger-tombstone-merge.test.mjs의 4개도 통과했습니다. 삭제 이력(tombstone)은 “이 서버 거래는 삭제되었다”는 식별 정보를 조회 결과에 전달하는 방식입니다. 단순히 목록에서 행을 숨기는 것과 다릅니다.
- 다른 기기에서 삭제한 같은 서버 거래를 로컬 목록에서도 제거합니다.
- 삭제된 거래의 클라이언트 식별자를 새 거래가 재사용해도 새 서버 거래까지 차단하지 않습니다.
- 오래된 삭제 이력이 같은 클라이언트 식별자의 다른 활성 거래를 지우지 않습니다.
- 첫 전체 동기화에서는 사라진 확정 거래만 제거하고 아직 전송 중인 거래는 보존합니다.