실무 경험이 없을 때 하기 쉬운 기초적인 실수를 하나 소개해드리겠습니다. 체계적이지 않고 작은 서비스일수록 저지르기 쉬운 실수입니다.
제가 처음 상용 애플리케이션을 혼자 만들었을 때는 안타깝게도 이걸 몰랐고, 당시 조언을 구하는 방법조차 잘 몰랐기 때문에 딱히 조언도 받지 못했습니다. 저는 경험으로 깨달았어요.
#문제 상황
서비스를 최초 설계/구현하는 상황을 가정 해 볼게요.
'회원 탈퇴' 기능에 대한 요구사항을 받았습니다. 탈퇴하면 회원 데이터가 '삭제'되도록 구현했습니다.
판매 상품을 삭제할 수 있어야 한다는 요구사항을 받았습니다. 내부 관리용 어드민 사이트에서 판매 상품을 삭제하면 판매 상품 데이터가 '삭제'되도록 구현했습니다.
그리고 서비스 운영을 시작하자 이런 질문과 요청을 받기 시작합니다.
CS 담당자/마케터 says...
-
이거 탈퇴한 회원 계정 이메일인데, 계정을 다시 활성화해주세요.
-
그 이벤트용 판매 상품을 누가, 언제 삭제했는지 알려주실 수 있어요? 누가 실수로 지운 것 같은데..
-
삭제한 판매 상품 복구할 수 없어요?
개발자 says...
어...... 그 데이터 지워서 없는데요?😅
#해결책
DB로부터 완전히 삭제하는 'hard delete'가 아니라, 레코드는 남겨두되 상태 값을 삭제로 바꾸는 'soft delete'를 해야 합니다.
- 해당 레코드에 delete flag를 boolean으로 저장하거나
- 해당 레코드에 delete flag로 삭제 날짜를 남기거나
- 경우에 따라서는 누가, 언제, 왜 삭제했는지에 대한 delete history를 별도의 테이블에 저장해서 따로 남긴다거나
하는 식으로 말입니다.
거의 모든 '삭제' 기능이 그렇습니다. 삭제뿐만 아니라, 수정에 대해서도 날짜나 이력을 남기는 것이 필요할 때도 있습니다.
최초 기능 추가에 대해 요청을 하는 시점에 기획자는 '추후에 탈퇴한 회원의 복구가 가능해야 한다.'라는 디테일을 생각해내기 힘들 수 있습니다.
이런 디테일의 구멍을 채우는 능력이 개발자에게 필요합니다. 개발을 시작하기 전에 기획에 대한 질문을 주고받는 과정에서 요구사항을 구체화하는 거죠.
그리고 이 글에서 설명한 데이터 DELETE와 같이, 몇몇 경우에 대해서는 개발자가 경험적으로 쉽게 예상/대처할 수 있는 부분도 있습니다.
