DB 변경에 따라 대대적인 코드 공사, 괜찮을까? (기존에 예측한 설계와는 달랐던 기획...)

오늘은 설계적인 관점에서 얘기해 보고자 합니다!
방끗을 현재 운영하면서 새로운 기능을 하나 도입하기로 했어요

현재 방끗에서는 "내"가 둘러본 방만 조회할 수 있어요
다른 유저의 체크리스트는 조회할 수 없도록 되어 있습니다

하지만 이러한 체크리스트를 홈에서 둘러볼 수 있는 기능을 도입하며,
고민이 생겼어요

고민 포인트

기존에는 위와 같이 체크리스트 각각을 조회하고 있지만 사용자끼리 둘러볼 수 있는 기능을 제공하겠다 결심한 이상 어느 정도의 기준으로 묶어 두고 그에 해당하는 체크리스트는 모아 두어 제공하고자 해요

저희는 그러한 기준을 "건물 단위"로 잡았습니다

즉, 상세 주소가 아닌 건물 주소까지가 일치하는 경우는 같은 원룸 건물이니
체크리스트를 통합하여 제공해 주면 방문하는 자취생 분들이 조금 더 다양한 정보를 얻을 수 있을 예정이에요

하지만 이를 구현하기 위해서는 현재 변경해야 되는 부분이 존재합니다

기존에는 위와 같은 ERD 구조를 설계했어요
설계 당시에는 유저들끼리 체크리스트를 둘러볼 수 없는 구조였지만, 충분히 들어올 만한 기획이라 생각해서 "부동산"의 "불변"한 정보를 모두 room 테이블에 두고 1:1로 맵핑하여 설계하였어요 반면에 유저 별로 다를 수 있는 정보는 checklist 테이블에 두는 것으로 설계하였습니다

1. 해당 정보를 모두 합치기에는 칼럼의 수가 너무 많았고
2. room이 가지는 정보의 특성과 checklist가 가지는 정보의 특성은 매우 다르기 때문이에요

이후, checklist 테이블과 1:N으로 매치해서 해당 기획을 만족할 수 있도록 구현할 생각이었습니다

하지만 실제 기획을 하게 되면서 room의 정보 중 일부만을 활용해서 구현하게 될 예정이 되었어요

이럴 경우에는 어떻게 해야 될까요?

대안을 고민해 보자

저희는 논의 끝에 두 가지 방안을 생각해 보았어요

1. room에 필요한 정보만을 남기고 불필요한 1:1 구조를 해체한다
2. 상위의 house 테이블을 도입한다

해당 부분의 장단점과 상세 설명은 아래에 기재해 보겠습니다

1. room에 필요한 정보만을 남기고 불필요한 1:1 구조를 해체한다

사실 1:1 구조는 해당 정보가 나뉘어서 조회될 경우가 많을 때 유의미하다 생각합니다
하지만 이 경우에는 1:1 정보가 불필요해졌기 때문에 해당 구조를 해체하는 것이 좋다 판단하였습니다

즉 1:N 구조로 변경을 하며 DB 구조와 코드를 바꾸는 것입니다

해당 부분으로 진행하게 되면 코드는 깔끔해질 것이라 생각합니다
의도한 대로의 설계가 될 예정이에요

반면에, 이것을 구현하기 위해 지금까지의 코드를 많이 바꿔야 하며 DB 구조까지 변경해야 되기 때문에
현재 운영 중인 서비스에서 최소한의 운영 중단 시간으로 도입할 수 있는 구조는 아닙니다

즉, 유저가 있는 환경에서는 도입하기 힘든 전략일 거라 생각합니다

2. 상위의 house 테이블을 도입한다

그렇게 해서 나온 전략은 다음과 같아요
필요한 테이블을 추가적으로 도입하는 전략입니다

해당 전략으로 가게 되면 house와 room은 1:N 구조가 될 것이고
room과 checklist는 1:1 구조로 유지하게 됩니다

즉, 새로운 테이블이 추가되고 기존의 테이블 거의 혹은 최소한의 변경만 있기 때문에
운영 중단 시간이 전의 전략에 비해서는 현저히 짧을 것이라 예상됩니다

하지만 기존의 불필요한 1:1 구조는 그대로 유지됩니다

또한, 주소라는 정보가 중복으로 저장되는 문제가 있습니다

무엇을 선택할 것인가?

현재로서는 중복 저장되는 칼럼의 수가 수용 가능한 범위이며,
유저가 있는 환경에서 도입 가능한 전략을 수립해야 되기 때문에 2번의 전략으로 갈 것 같습니다

하지만 어떤 방안이 현업에서 사용되는지 궁금한 생각이 들기도 하고,
더 나은 전략이 있을까 궁금해서 글을 올려 봅니다!

유의미한 토론이 이어지는 글이 되길 바라며 .. 🙇‍♂️