데이터 삭제, 정말 지워야 할까?

안녕하세요 makeviibe 입니다.

​

서비스를 만들다 보면 “사용자가 탈퇴하면 데이터를 다 지워야 하지 않나요?” 같은 질문을 자주 받아요.

특히 MVP(최소 기능 제품) 단계에서는 이런 고민이 많습니다.

결론부터 말하면, MVP에서는 웬만하면 물리 삭제(완전 삭제)는 피하고 논리 삭제(숨김 처리)를 추천합니다.

---

1. 물리 삭제가 위험한 이유

​

물리 삭제는 데이터를 DB에서 완전히 지우는 방식이에요.

겉보기엔 깔끔해 보이지만, MVP 상황에서는 생각보다 많은 문제가 생깁니다.

​

❌ 복구 불가능

• MVP는 자주 기능을 바꾸고 테스트를 반복합니다.
• 잘못 지운 데이터를 되돌릴 수 없으면, 운영팀과 개발팀 모두 곤란해집니다.

​

❌ 관계가 깨질 수 있음

• 대부분 DB에는 FK(외래키) 관계가 있어요.
• 예를 들어, 사용자가 탈퇴했는데 주문 내역이 남아있으면?
• FK 제약 때문에 삭제가 막히거나, 억지로 지우면 데이터 정합성이 깨집니다.

​

❌ 요금 문제는 당장은 크지 않음

• 보통 “DB 용량이 커지면 요금이 올라가니 지워야 하지 않나?”라는 생각을 많이 해요.
• 하지만 AWS RDS 같은 클라우드 DB는 100GB에 월 1만 원 남짓이에요.
• MVP 단계에서 수십 GB 데이터를 쌓는 일은 거의 없으니, 비용보다 안정성이 훨씬 중요합니다.

---

2. 논리 삭제가 현실적인 이유

​

논리 삭제는 DB에서 데이터를 지우지 않고,

is_deleted = true 같은 플래그만 남기는 방식이에요.

​

✅ 복구 가능

• 실수로 지운 글, 탈퇴한 회원도 필요하면 다시 살릴 수 있습니다.

​

✅ 운영 안정성 확보

• FK 관계를 유지하면서도 “삭제된 데이터는 조회에서만 안 보이게” 만들 수 있어요.
• 주문, 로그 같은 기록이 꼬이지 않습니다.

​

✅ 개발 속도 향상

• 실제로 완전 삭제 로직을 짜는 것보다,
• “삭제 여부 필터”만 추가하는 게 훨씬 빠르고 안전합니다.

---

3. 데이터를 쉽게 버리면 안 되는 이유

​

여기서 중요한 포인트가 하나 더 있어요.

바로 사용자가 만든 데이터 자체가 스타트업에게는 자산이라는 점이에요.

​

• 사용자가 남긴 게시글, 댓글, 리뷰 같은 데이터는 단순한 기록이 아니라, 서비스 개선을 위한 피드백의 집합이에요.
• 최근에는 이런 데이터를 기반으로 새로운 기능을 추가하거나, AB 테스트에 활용하는 경우도 많습니다.
• 예를 들어 “어떤 기능을 많이 사용하는지, 어떤 행동에서 이탈하는지”를 보려면 과거 데이터가 꼭 필요해요.

​

👉 결국 데이터를 지워버린다는 건, 스타트업 입장에서는 학습 기회를 스스로 버리는 것과 같아요.

초기에는 특히 데이터 한 줄, 한 줄이 굉장히 소중하기 때문에 “지우지 말고 남겨두자”라는 전략이 현명합니다.

---

4. 현실적인 MVP 전략

​

👉 회원/게시글/댓글 → 논리 삭제 (복구, 이력 관리 필요)

👉 개인정보(전화번호, 이메일) → 암호화 후 마스킹 or 최소한만 보관

👉 로그/이벤트 데이터 → 논리 삭제 or 일정 기간 후 배치 작업으로 정리

​

즉, “완전히 지워야 하는 데이터는 극히 일부”이고,

대부분은 숨기는 게 운영과 개발 양쪽에 훨씬 유리합니다.

---

5. 실제 예시

• 회원 탈퇴
  • 물리 삭제: 회원 FK 때문에 주문 내역이 깨짐 → 오류 발생
  • 논리 삭제: is_deleted = true → 주문 내역은 그대로, 회원은 비활성 처리
• 댓글 삭제
  • 물리 삭제: 대댓글이 있으면 관계 깨짐 → 화면도 꼬임
  • 논리 삭제: “삭제된 댓글입니다” 메시지 표시

---

6. 정리

• MVP 단계에서는 물리 삭제는 가급적 하지 않는 게 안전
• 데이터 용량 문제는 아주 나중에 고민해도 늦지 않음
• 사용자가 만든 데이터는 곧 서비스의 자산 → 쉽게 버리면 안 됨
• 안정성과 복구 가능성을 지키는 게 훨씬 더 중요
• 서비스가 커진 뒤, 정말 필요한 데이터만 물리 삭제로 전환하면 됨