화면의 삭제가 부르는 것

반품이 중복 생성되어 하나를 지워야 했고 관리 화면에서 삭제를 눌렀다. 아무 일도 안 일어났고 목록을 새로고침해도 그대로 남아 있었다.

Open Table of contents

에러 없이 안 지워진 건

오류 메시지도 없고 화면에 아무 변화도 없었다. 실패했다는 신호가 어디에도 없으니 눌린 것인지도 확실하지 않았다.

이런 상태에서는 화면만 봐서는 다음에 무엇을 볼지가 안 정해진다. 그래서 화면이 실제로 무엇을 보내는지부터 확인했다.

화면은 삭제 요청을 보내는데 서버 쪽을 따라가니 다른 계층의 인터페이스에 철회 작업을 요청하고 있었다. 요청에는 강제 여부를 뜻하는 플래그가 꺼진 채로 실려 있었다.

처리기 코드를 보니 강제가 아니면서 완료 상태이면 아무것도 하지 않고 그대로 반환했다. 이 반품의 상태가 완료였으므로 그 분기로 빠진 것이었다.

같은 결과라도 완료 상태는 삭제할 수 없다는 메시지가 뜨면 사용자가 이유를 안다. 조용히 반환하면 아무 단서 없이 안 된 상태만 남는다.

화면에 단서가 없는 실패는 코드를 열기 전까지 원인이 안 나오므로 조사 비용이 통째로 사람에게 넘어온다. 조용한 실패를 만나면 화면을 더 보지 않고 바로 코드로 간다.

강제 플래그를 켜면 다른 작업 유형으로 동작하는데 옛 화면에서는 그것을 켤 방법이 없었다. 인터페이스를 직접 불러야 했다.

완료된 반품이면 정산에 반영됐을 수 있어서 강제로 철회하면 정산이 어긋날지 확인했다. 철회 시 정산 보정 이벤트가 자동 발행되고 있어서 수동 보정이 필요 없었고 그것을 확인한 덕에 이중 보정을 피했다.

엔티티를 보니 삭제가 행을 지우는 것이 아니라 삭제 시각을 남기는 방식이었다. 조회에서만 빠지고 데이터는 남아 있으므로 되돌릴 수 있다.

되돌릴 수 있는 작업과 없는 작업은 같은 위험도로 다룰 필요가 없다. 복구가 가능하다는 확인 하나가 실행할지 말지의 판단을 바꿨다.