인프런 커뮤니티 질문&답변
작성한 질문수
예약 변경 시 '과거 정책 기준 재계산' 요구사항에 따른 스냅샷 데이터 구조 설계 고민
해결된 질문
작성
·
80
1
안녕하세요 강사님. 지난번 '어드민 예약 변경 시 쿠폰 회수' 관련 질문을 드렸던 수강생입니다. 답변 주신 내용을 바탕으로 설계를 보완하던 중, 스냅샷 데이터의 범위와 확장성에 대해 추가적인 고민이 생겨 조언을 구합니다.
[현재 아키텍처 상황] 현재 예약 테이블에는 예약 시점의 가격 정보를 JSON 형태의 스냅샷으로 저장하고 있습니다.
이유: 가격 결정 요소(할인, 이벤트, 기업 지원 등)가 빈번하게 변경/추가되어 RDB 컬럼으로 대응하기 어렵기 때문입니다.
저장 데이터: 현재는 '결과값' 위주로 저장합니다. (예: 적용된 할인 명, 타입(정액/정률), 최종 할인 금액)
[직면한 문제: 변경 시점의 기준 모호성] 예약 시점(T1)과 변경 시점(T2) 사이에 정책이 변경되었을 때, 어드민에서 예약을 수정하면 어떤 정책을 따라야 하는가에 대한 딜레마입니다.
만약 기획 요구사항이 "변경 시점(T2)의 정책이 아니라, 최초 예약 시점(T1)의 정책 조건을 유지한 채 금액만 다시 계산해 주세요"라고 한다면 문제가 복잡해집니다.
현 구조의 한계: 현재 JSON에는 '결과(할인액)'만 있고 '조건(최소 결제 금액, 당시 허용된 옵션 목록 등)'은 없습니다.
예상되는 부작용: 이를 해결하려면 예약 시점의 모든 검증 조건(Condition)을 JSON에 다 때려 넣어야 합니다.
이렇게 되면 도메인 로직이 바뀔 때마다 JSON 스키마도 계속 비대해지고,
과거 JSON 데이터와 현재 로직 간의 정합성을 맞추기 매우 까다로워질 것 같습니다.
[질문] 이처럼 "빈번하게 변하는 가격 정책"과 "과거 기준 수정"을 동시에 만족해야 할 때, 실무에서는 보통 어떤 접근 방식을 취하나요?
JSON 스냅샷 확장: 다소 복잡해지더라도 예약 시점의 검증 조건(Parameter)들까지 모두 JSON에 스냅샷으로 남기는 게 맞나요? (JSON 컬럼 사용이 잘못된 선택이었을까요?)
Policy Versioning (정책 버전 관리): 아니면 가격/할인 정책 테이블 자체를 버전 관리(Effective Date 등)하여, 예약 시점의
policy_version_id를 매핑해두고 로직을 태우는 방식을 써야 할까요?현실적인 타협: 아니면 보통 어드민 변경 건은 "재계산 불가(단순 금액 입력)"로 처리하거나, "무조건 현재(T2) 정책"을 따르게 하는 등 복잡도를 낮추는 타협점을 찾나요?
확장성 있는 가격 스냅샷 설계에 대한 강사님의 경험과 조언을 부탁드립니다..!
답변 2
0
안녕하세요 질문 감사드립니다!
우선 현실적인 타협이 가장 우선시 되어야 할 것 같습니다, 어드민/CS가 개입한 예약의 변경의 경우 특정 상황에서 진행하는 게 일반 적일 것 같은데, 그런 요청에서도 과거 기준으로 모든 걸 돌려서 진행하려면 상당히 까다로워지고, 사이드 이펙트로 현재의 재고나 현재의 옵션에도 영향이 갈 수 있게 됩니다 (로직상 실수 가능성이 높다는 의미, 가령 delete 된 옵션을 쓰는 로직을 억지로 넣어야 한다거나)
상식적인 선에서는 예약의 변경은 현재 정책을 따르는 게 맞다고 생각합니다.
다만 서비스의 특성 및 고객의 니즈를 맞춰야 하는 게 중요하다면 (한 명이 거래액이 몇천만 원대라던가..)
심플하게는 조건에 대한 값들도 별도 json에 저장하면 될 것 같습니다, 이 값은 어드민 예약 변경 시에만 쓰일 것이기 때문에 그 정도로 구성해도 되지 않을까 싶습니다
+ 변경이 잦을 수 있는 현실 or 상황 or 서비스 특성이라면 json 자체는 괜찮은 선택이라고 봅니다
저도 그런 경우에는 json을 쓰긴 합니다
다만 예약 전까지 정보를 보통 json에 담고 완료된 최종 데이터는 온전한 테이블에 저장하는 편이긴 합니다만, 이건 요구사항+현실에 따라 판단해야 할 것 같습니다!
실제로는 회사의 정확한 상황과 서비스 성장을 위한 니즈가 더욱 중요한 부분이니 답변 내용은 참고만 부탁드립니다!
이번 강의도 수강 감사합니다!
0
안녕하세요, 인프런 AI 인턴입니다. 우으어으님.
복잡한 스냅샷 데이터 구조와 그로 인한 예약 시스템의 변경 정책에 대한 고충을 공유해 주셔서 감사합니다. 가격 정책과 스냅샷 데이터의 복잡성이 증가함에 따라 고려해야 할 요소가 많습니다.
1. JSON 스냅샷 확장
스냅샷을 통해 과거 시점의 모든 검증 조건을 저장하는 것은 한계가 있을 수 있습니다. JSON에 모든 조건을 포함시킬 경우, 유지보수가 어려워지고 데이터의 일관성을 보장하기 어렵습니다. JSON을 사용한 저장 방식은 시스템이 복잡해질수록 리팩토링을 자주 요구하게 될 수 있습니다.
2. Policy Versioning
정책 자체를 버전 관리하는 것은 매우 유용한 접근 방식입니다. 다음과 같이 설계를 고려할 수 있습니다:
- 버전화된 정책 테이블: 정책의 유효기간, 수정 사항 등을 포함하여 정책을 관리하고, 예약 시점에 특정 버전을 지정합니다.
- 이력 관리: 각 예약에 대해 어떤 정책 버전이 적용되었는지를 기록합니다. 이렇게 하면 나중에 정책 변경이 있더라도 특정 버전을 기준으로 계산을 수행할 수 있습니다.
버전 관리 방식은 시스템이 복잡해진다 하더라도 변경 관리 측면에서 명확한 장점을 제공합니다.
3. 현실적인 타협
시스템 복잡도를 최소화하기 위해 어드민 기능에서의 정책 변경에 따른 복잡성을 줄이려면:
- 단순 금액 입력: 어드민 변경 시 금액만 수동으로 조정하고 정책을 변경하지 않거나,
- 현재 정책 따르기: 복잡성을 줄이기 위해 변경 시점의 현재 정책을 기준으로 재계산하는 것을 고려할 수 있습니다.
관련 유사 질문 및 참고
- 🔗 어드민 수정 정책 및 스냅샷 데이터 관리 방안: 비슷한 고민을 다룬 사례로 정책 관리와 필드 스냅샷 전략에 대한 논의가 포함되어 있습니다.
- 🔗 데이터베이스 내 스키마 설계 및 변경 관리: 데이터의 일관성과 변경 관리에 대한 다른 사례를 참고할 수 있습니다.
확장 가능한 스냅샷 시스템 설계의 과정에서 질문자님의 바램과 요구에 부합하는 방향으로 여러 가지 접근 방법을 테스트해보시길 바랍니다.
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.