🛒 Backend Engineering · 9/9 · 약 8분
사용자가 같은 버튼을 반복해서 누르거나 실패 화면에서 멈추는 현상은 화면 배치만의 문제가 아닐 수 있다. 처리가 시작됐는지, 다시 시도해도 되는지, 어떤 결과가 확정됐는지를 시스템이 충분히 설명하지 못한 신호일 수 있다.
가상의 주문 서비스 사용성 점검을 기준으로 관찰을 상태 의미, 재시도 안전성, 오류 응답 계약으로 번역해 보았다. 그러자 화면과 백엔드가 함께 책임져야 할 기준이 선명해졌다.
#Backend · #UX · #API · #UsabilityTesting
같은 버튼을 반복해서 눌렀다는 사실만으로 버튼 비활성화를 정답으로 정할 수는 없다. 요청이 접수됐는지 알 수 없었거나, 이전 결과를 다시 확인할 경로가 보이지 않았을 수 있다. 먼저 행동 뒤의 불확실성을 한 문장으로 정의해야 한다.
예를 들어 ‘사용자는 처리 중인지 실패했는지 구분할 수 없다’는 문제 문장은 화면과 시스템의 책임을 함께 드러낸다. 화면은 진행 상태와 다음 행동을 보여 줘야 하고, 백엔드는 현재 처리 상태와 기존 결과를 일관되게 반환해야 한다. 해결책을 먼저 고르면 한쪽 책임만 수정하고 근본 원인을 남길 수 있다.
관찰 기록에는 개인을 식별할 표현이나 실제 발언을 남기지 않는다. 수행한 행동, 관찰된 결과, 해석한 불확실성, 검증할 가설만 분리한다. 이렇게 일반화해야 기술 판단을 재사용하면서도 실제 사용자와 서비스 맥락을 노출하지 않는다.
화면에서 ‘다시 시도해도 된다’고 안내하려면 백엔드는 같은 사용자 의도를 식별해야 한다. 동일 의도의 요청이 반복되면 기존 처리 상태를 이어서 보여 주거나 이미 확정된 결과를 반환해야 한다. 그렇지 않으면 친절한 안내가 중복 주문과 반복 부수 효과를 만들 수 있다.
반대로 백엔드가 반복 요청을 안전하게 처리해도 화면이 진행 중임을 알리지 않으면 사용자는 불필요한 재시도를 계속한다. 요청 의도 식별, 처리 상태 조회, 기존 결과 재사용, 진행 안내가 하나의 계약으로 이어져야 한다.
사용자 행동 관찰
↓
불확실성 정의
├─ 화면: 현재 상태와 다음 행동 표시
└─ API: 같은 의도 식별과 기존 결과 제공
↓
안전한 재시도 경험
이 흐름의 불변식은 반복 행동이 새로운 부수 효과를 만들지 않는다는 것이다. 처리 중, 완료, 다시 시도 가능, 별도 확인 필요 같은 상태를 화면과 API가 같은 의미로 사용해야 한다.