20210307 [dev] 데이터의 상태를 변경한다는 것.

개요

시스템에서 특정한 데이터의 상태가 'A' 일 때, 다시 한번 'A' 로 변경요청이 오는 것을 에러로 보는게 좋을까 아니면 그대로 다시 덮어쓰는게 좋을까?

 

상태를 변경한다는 것

도서 관리 시스템을 만든다고 가정하자. 도서관에 있는 참을 수 없는 존재의 가벼움 이라는 책이 있다. 많은 사람들이 대여하고, 반납하고 있다. 도서 관리 시스템은 해당 책이 대여가 된 상태인지 혹은 도서관에 보관중인 상태인지 여부를 확인해서 대여가능여부를 사용자에게 알려준다. 여기서 데이터는 책이다. 책의 상태는 두 가지가 있다.

• 대여 가능 상태
• 대여 중 상태

외부 클라이언트의 요청으로 인해서 대여 가능 상태인 책을 대여 중 상태로 변경하는 것이 아닌 대여 가능 상태로 다시 한번 변경 요청이 왔을 때 이걸 단순히 덮어써도 상관이 없는지 생각해보아야한다.

 

웹/앱에서의 요청이 중복된 상태변경의 요청이라서 상관없다고 생각할지 모르지만, 생각해볼 것이 있다.

• 중복된 상태 변경요청이 프론트 기능 상에 존재하는지 여부
• 중복된 상태 변경요청이 어디선가 유효성 체크 버그로 인해서 새는지 여부
• 비즈니스 상 그러한 요청이 있는지 혹은 없는지 여부

위의 일련의 생각들을 거치게 되었을 때, 데이터의 상태를 변경하는 것은 단순히 동일한 상태를 덮어쓰면 된다라고 생각하기 어렵다. 도서 관리 시스템에서 책의 대여상태는 매우 중요하다. 단순히 시스템 내에 요청이 왔고, 그 요청이 동일한 요청이라고 덮어쓴다고 가볍게 생각할 수 없다. 우리는 그 상태가 전체적인 시스템의 관점으로 봤을 때 있을법한 요청인지 혹은 버그로 새는 요청인지 확인을 해야하고 수정이 필요하면 수정을 해야한다. 거시적인 관점으로 볼 필요가 있다.

 

위의 내용은 회사업무를 하면서, 나온 이야기 일부를 본인 나름 해석을 하여 작성하였음을 알린다.