장바구니 옵션·수량 변경, 앱과 서버는 금액을 어떻게 맞출까요?

그래서 화면에는 ‘변경할 옵션·수량’과 ‘저장된 장바구니’를 구분해 둡니다. 선택 중에는 저장 전이라는 사실을 알리고, 변경을 요청한 뒤에는 처리 중 상태를 표시합니다. 서버 결과를 받기 전에 ‘변경 완료’로 표시하지 않는 것입니다.

선택 화면에서 예상 금액을 계산해 보여줄 수도 있지만, 그 값은 저장 결과와 구분해야 합니다. 이번 흐름에서는 서버가 확인한 상품 합계를 저장 결과로 보여주도록 정합니다. 앱의 계산식과 서버의 계산식이 우연히 같다는 이유만으로 저장이 끝났다고 판단하지 않습니다.

수량도 숫자라는 사실만으로 충분하지 않습니다. 이번 규칙은 1부터 5까지의 정수입니다. 0개·6개·소수·문자열 같은 값은 허용하지 않습니다. 앱에서 잘못된 선택을 막아도 서버에서 같은 핵심 조건을 확인해야 화면을 거치지 않은 요청에도 규칙을 적용할 수 있습니다. OWASP 입력값 검증 안내도 서버에서 형식과 허용 범위, 값 사이의 의미를 확인하도록 설명합니다.

가격은 앱이 보낸 숫자로 확정하지 않습니다. 서버가 상품·옵션의 현재 가격을 읽어 대형의 단가가 24,000원인지 확인합니다. 이번 요청 형식에는 단가나 합계 필드를 두지 않고, 그런 값을 끼워 보낸 요청은 거절하도록 정합니다. 화면에서 가격 입력란을 숨기는 것보다 서버가 받아들일 값을 분명히 정하는 일이 먼저입니다.

장바구니 항목에는 같은 변경에 속한 옵션·수량·단가·상품 합계를 함께 반영하도록 구성합니다. 옵션만 대형으로 바뀌고 합계는 기본형 1개의 18,000원으로 남는 중간 결과를 성공으로 제공해서는 안 됩니다. 저장이 확정된 뒤 변경 버전을 응답하고, 앱은 별도의 조회로 저장 결과를 읽습니다.

다른 화면에서 같은 항목을 먼저 바꾼 경우도 구분합니다. 앱은 마지막으로 읽은 변경 버전을 함께 보내고, 서버는 현재 버전과 맞는지 확인하도록 정합니다. 이미 다른 변경이 저장됐다면 오래된 선택으로 덮어쓰는 대신 충돌을 알리고 현재 장바구니를 다시 읽게 합니다. 버튼을 잠그는 것만으로 여러 화면의 변경까지 막았다고 보지 않는 이유입니다.

앱은 수량 입력 옆에 ‘1개부터 5개까지 선택할 수 있습니다’라고 안내하고, 저장된 결과는 별도로 유지합니다. 사용자가 6개를 입력했다는 사실과 서버에 6개가 저장됐다는 사실은 다릅니다. 선택을 수정할 수 있게 하면서도 실패한 값을 저장 완료처럼 보여주지 않아야 합니다.

반면 변경 응답을 받지 못한 상황은 서버가 거절했다고 단정할 수 없습니다. 서버에 저장은 됐지만 응답만 도착하지 않았을 수 있기 때문입니다. 이때는 ‘변경 결과 확인 필요’로 안내하고 저장된 장바구니를 다시 조회하는 흐름을 둡니다. 이전 금액으로 즉시 되돌리거나 같은 변경을 무조건 반복하는 대신, 현재 확인할 수 있는 결과부터 읽는 것입니다.

검증에서는 정상 변경뿐 아니라 거절된 변경의 뒤도 봅니다. 수량 6개를 요청한 뒤 별도로 조회했을 때 기존 대형 2개·48,000원이 유지돼야 합니다. 존재하지 않는 옵션이나 금액 필드를 보낸 요청도 저장값을 바꾸지 않아야 합니다. 새로고침 후에도 같은 항목을 다시 읽어야 화면에만 남아 있던 숫자를 저장 결과로 오인하지 않습니다.

오래된 변경 버전으로 요청한 경우에는 충돌 응답과 현재 저장값을 함께 대조합니다. 정상 변경·입력 거절·변경 충돌을 각각 확인해야 한 번 성공한 화면만으로 모든 경로가 맞는다고 판단하지 않을 수 있습니다.