상태 기반 데이터관리에서 특정 시점에 대한 정보는 어떻게 관리할 수 있나요?
41
작성한 질문수 6
안녕하세요 영한님 마스터패스 구매하고 모든 강의를 재밌게 수강하고 있는 백엔드 개발자 취업준비생입니다. 강의를 듣다가 궁금한 점이 생겨 질문남깁니다! 답변해주시면 너무 감사하겠습니다.
is_deleted 와 같은 컬럼을 사용하는 soft delete 방식은 실제 삭제 시점을 알 수 없기 때문에 주로 사용하진 않고, deleted_at을 컬럼으로 두고 삭제 여부/시점을 모두 판별할 수 있게 한다고 하셨는데,
그렇다면 뒤에 설명해주신 상태 기반 관리를 통해서 ProductStatus나 OrderStatus를 관리할 경우, deleted_at이나 다른 시점을 컬럼으로 두면 나쁜 설계라고 하셨습니다. 그렇다면 결국 ProductStatus와 같은 상태를 가진 것들은 삭제 시점이나 특정 시점을 알 수 없는건 마찬가지 아닌가요?
만약 삭제 시점이나 회원의 탈퇴 시점같은 것들을 관리해야 한다면 어떻게 해야할까요?
이러한 해결 방법으로써 이력 테이블 등의 방법이 있을 것 같은데 취준생의 개인 프로젝트로 사용하기에 규모가 너무 커지지 않을까 걱정됩니다.
실제 사례를 예시로 들어보자면
UserStatus 상태값입니다. 이를 테이블의 한 컬럼으로 두고 내부에는 ACTIVE(정상), SUSPENDED(임시정지), BANNED(영구정지), WITHDRAWN(탈퇴) 등의 여러 상태를 가집니다. 이때 만약 withdrawn_at 컬럼이 존재하지 않고 상태값만으로 관리하면 탈퇴 시점이 언제인지 등을 확인할 수 없게 됩니다.
이 경우에는 withdrawn_at 컬럼을 상태값과 함께 두는 것보다 이력 테이블을 사용하는게 더 나은 설계이자, 개인 소규모 프로젝트에서도 해당되는 사항인지 궁금합니다.
작은 조언이라도 해주시면 감사하겠습니다!
-- 에이전트
인프런 에이전트에 같은 내용으로 질문을 남겨봤는데 withdrawn_at 컬럼을 상태 컬럼과 함께 사용하는 것이 효율적이고 합리적인 설계라고 합니다. 실제로 이력 테이블은 개인 프로젝트 규모정도에서는 사용하기에 관리 복잡도가 증가할 가능성이 있다고 합니다. 이에 대해 어떻게 생각하시는지도 궁금합니다.
답변 1
1
안녕하세요. yeoeol님
상태 컬럼과 함께 deleted_at을 두는 것이 좋지 않은 이유는 "삭제(탈퇴) 여부"라는 같은 사실을 status와 deleted_at 두 곳에서 중복 관리하게 되기 때문입니다. status는 WITHDRAWN인데 deleted_at은 NULL인 것처럼 두 정보가 어긋나면 데이터 정합성이 깨집니다. 시점 정보 자체가 나쁘다는 뜻은 아닙니다.
그래서 실무에서는 보통 이렇게 접근합니다.
1. 현재 상태의 변경 시점만 필요하다면: status + status_changed_at 하나면 충분합니다. 상태가 바뀔 때마다 함께 갱신하면 "언제 탈퇴했는지"는 status=WITHDRAWN + status_changed_at으로 알 수 있습니다. 상태별로 suspended_at, banned_at, withdrawn_at을 각각 두면 컬럼이 계속 늘어나고 관리가 어려워집니다.
2. 모든 상태 변경 이력이 필요하다면(정지 → 해제 → 재정지 같은 흐름): 이력 테이블이 정답입니다. 그런데 생각보다 거창하지 않습니다. user_status_history(id, user_id, status, changed_at, reason) 정도의 테이블 하나에 상태 변경 시 INSERT만 추가하면 끝이라, 개인 프로젝트에서도 충분히 사용할 수 있는 수준입니다.
에이전트의 답변처럼 탈퇴 시점이 업무적으로 특히 중요한 경우 withdrawn_at을 별도로 두는 것도 실무에서 흔히 쓰는 합리적인 선택입니다. 다만 이때는 상태 변경과 시점 기록이 항상 함께 이루어지도록 한 곳(서비스 로직)에서 묶어서 처리해야 정합성이 유지됩니다.
정리하면, 개인 프로젝트라면 status + status_changed_at으로 시작하고, "이력 추적"이라는 요구사항이 생기는 시점에 이력 테이블을 도입하면 됩니다. 설계에 하나의 정답이 있는 것이 아니라, 요구사항에 맞는 트레이드오프를 선택하는 것이 핵심입니다.
감사합니다.
0
저의 개발 선생님이신 영한님께 직접 답변을 받으니 뭔가 울컥하게 되네요.. 해주신 내용 전부 이해했습니다. 질문을 남겼을 때와 달리, 해당 강의를 완강하고 나니 영한님께서 해주시는 말씀들이 잘 이해되는 것 같습니다. 앞으로도 좋은 개발 강의 만들어주세요. 항상 챙겨보겠습니다. 감사합니다!!!
공통 코드 , 계층 구조 질문
1
87
1
공통코드 관련한 질문 드립니다.
0
104
1
다음 강의는 언제쯤 나올까요?
1
144
2
실제 FK제약조건을 설정하지 않는이유
0
116
2
히스토리 관련 질문
0
93
2
통계 데이터 수정 질문
1
110
2
공통 코드에서 Redis Pub/Sub은 최근 실무에서 쓰이진 않나요?
0
195
2
DELETE -> SELECT 질문 드립니다.
0
87
1
상속 관계 모델링의 적용 기준 질문
0
104
1
TTL 캐싱에 대한 질문
0
141
1
공통 코드 사용시 컬럼 타입 설정
0
134
1
history_creted_at과 valid_from
1
99
2
함수 기반 인덱스 (Function-Based Index)
0
120
1
추후 강의 질문있습니다
0
163
2
실무 통계 질문(고민) 드립니다..!
0
133
2
Json 컬럼의 객체 맵핑
0
97
1
[Deprecated] 오타 제보
0
129
1
오타 제보
0
97
2
category_path 테이블에서 idx_descendant 인덱스를 생성하는 이유가 궁금합니다
0
137
2
물리적으로 외래 키 제약 조건을 설정하지 않을 때
0
128
1
`전체 행 스냅샷 이력 테이블`의 대상 테이블 칼럼 변경
2
120
1
common_code_detail의 code 변경 가능성
1
144
1
[해결책 - 코드값 분리] 중 orders(order_status) - common_code(code) 타입 불일치 제보
0
114
1
이미 문자열 타입인 컬럼을 캐스팅하는 이유
0
131
2