데이터 베이스 개념적 설계의 중요성 (Feat. 스타트업에서 흔히 하는 크나큰 실수)

설계가 왜 중요한가?

하나의 애플리케이션을 사람에 비유하게 됐을때 에플리케이션 코드가 근육, 피부조직 등의 요소를이루어 그들을 유기적으로 옮기게 한다고 하면 데이터베이스의 설계는 그 근육이 붙어있는 뼈대로 비유할 수 있다. 즉 한번 고착화 되면 굉장히 바꾸는것이 어렵고 품이 많이들면서 리스크까지 크게 떠 안아야 한다는 뜻이다.

그렇기 때문에 설계를 하는 사람 혹은 추후 배우게 될 개념적설계에 참여하는 비즈니스 참가자들은 데이터베이스설계에 목을 메어 신중을 가해야한다.

잘못된 설계?

강의에서는 잘못된 설계에 대해서 자세히 설명하였다. 하지만 이는 너무 기본적인 내용이니 좀 더 깊게 잘못된 설계란 무엇인가? 에 대한 의문점을 가져야한다.

예를들어 영상에서와 같은 데이터에서 데이터계선을 위해 최소한의 정규화 단계라고 익히 알려진 3NF(이행적 종속 제거) 까지 클로드를 통해 진행 해본 후 이 3nf까지 진행했는데도 비즈니스의 흐름에 따라 어떻게 되는지 시뮬레이션을 해보는 것이다.

원본 테이블 구조 분석

Order (order_id, customer_id, customer_name, customer_address, product_id, product_name, product_price)

문제점:

• 1NF 위반: 원자값 위반 (한 주문에 여러 제품 가능)
• 2NF 위반: 부분 함수 종속성 존재
• 3NF 위반: 이행적 함수 종속성 존재

정규화 과정

1NF (제1정규형)

원자값을 만족하도록 분리:

Order (order_id, customer_id, customer_name, customer_address, product_id, product_name, product_price)
PK: (order_id, product_id)

2NF (제2정규형)

부분 함수 종속성 제거 (후보키의 일부에만 종속된 속성 분리):

Order (order_id, product_id, quantity)
PK: (order_id, product_id)

Customer (customer_id, customer_name, customer_address)
PK: customer_id

Product (product_id, product_name, product_price)
PK: product_id

Order_Info (order_id, customer_id, order_date)
PK: order_id
FK: customer_id → Customer

3NF (제3정규형) - 최종 구조

이행적 함수 종속성은 이미 제거되어 있으므로 2NF 구조가 곧 3NF입니다.

Customer (customer_id, customer_name, customer_address)
PK: customer_id

Product (product_id, product_name, product_price)
PK: product_id

Order_Info (order_id, customer_id, order_date)
PK: order_id
FK: customer_id → Customer

Order_Detail (order_id, product_id, quantity, unit_price)
PK: (order_id, product_id)
FK: order_id → Order_Info
FK: product_id → Product

이 구조에서 받을 수 없는 요구사항

"고객별로 배송지 주소를 여러 개 관리하고, 주문 시마다 다른 배송지를 선택할 수 있어야 합니다."

이유: 현재 정규화된 구조에서는 Customer 테이블에 customer_address가 단일 값으로 저장되어 있습니다. 한 고객이 여러 배송지를 가질 수 없고, 주문마다 다른 배송지를 지정할 수도 없습니다. 이 요구사항을 처리하려면 별도의 Address 테이블과 Order_Info 테이블에 배송지 참조를 추가해야 합니다.

 

큰일났다!!! 이미 성장하고 있는 서비스에 크리티컬한 이슈가 생겼다...

투자자들은 왜 이런 간단한 기능도 빨리 안생기냐며 애플리케이션과 회사의 개발 수준에 대한 신뢰가 떨어졌고, 다음 스탭으로 가기위한 자금유치에 굉장히 중요한 투자건이 무산되며 회사는 문을 닫았다.

극단적인가? 말도안된다 생각하는가? 현업에 있다보면 한번쯤 듣게 되는 그런 얘기라고 생각한다 (들어 봤기때문...) 만약 투자자가 한번 봐줘서 시간을 좀 연기해줬다. 개발자는 매일 밤을 새어가며 구조를 조금씩 바꿔가며 요구사항을 완수했다. 그럼 그 다음은? 매번 밤을 새며 모래성위에 콘크리트 건물을 지을 것인가?

그럼 왜 이런일이 발생했을까?

데이터베이스 설계에는 3가지 단계가 있다. 개념적, 논리적, 물리적 이 세단계를 “순차적”으로 거치며 설계를 이어나가게 된다.

이 세가지 단계에서 비즈니스를 수행하고 운영해 나가는데에 있어서 가장 가장 짱 개 중요한것은 “개념적 설계”이다.

위 예시에서 새로운 요구사항에 유연하게 반응하지 못했던 것은 “논리적 설계”는 괜찮게 했지만 “개념적 설계”를 심도있게 하지않아 발생한 이슈라고 분석할 수 있다.

계념적 설계시에는 사내에 모든 주요 비즈니스 결정자들이 모여 작업하려는 도메인에 대한 사내 “용어사전”을 구축하고 앞으로 받아들여야할 예상될 모든 시나리오들을 최대한 예측해 내서 그 모든 사항들을 고려한 유연한 설계를 ERD에 녹여내야한다.

하지만 대부분의 스타트업들은 이 과정을 무시하고 사업을 진행하기위한 아이디어만 줄줄이 내놓으며 애플리케이션을 만드는데에 급급하여 중요한 타이밍에 애플리케이션을 더이상 성장시키지 못해 시장에서 도태된다.

요약

새로운 프로젝트를 진행하는데 개념적 설계 단계에서 회사가 방향성이나 디테일한 비즈니스 방향을 내놓지 않고, 아무리 요구를 해도 얘기조차 해보려 하지 않고 그건 너네 개발팀이 하는거지 왜 그런걸 알려고 하는거야?, 미팅때문에 시간없으니 그건 너희들이 알아서해~ 하면 퇴사를 고려해 보심이… 돔황챠…