플랫폼 개발, 도메인 몰라도 데이터 모델 설계하는 방법
개발자를 위한 실전 플랫폼 데이터 모델링 가이드
안녕하세요! 개발빔입니닷!!
외주든 인하우스든 플랫폼 개발을 하다 보면,
도메인은 하나도 모르겠는데 DB부터 만들어야 할 때가 종종 생기는데요ㅠㅠ
저도 다양한 프로젝트를 거치던 시절...
도메인이 전부 다른 플랫폼들을 계속 만들면서
결국 서비스를 오래 버티게 하는 힘은 데이터 모델에서 나온다는 걸 많이 느꼈어요!!
오늘은 플랫폼 개발을 할 때 도메인을 다 알고있지 못하더라도
데이터 모델을 어떻게 설계하면 되는지
저의 방법들을 조금 소개해드리려고 해요~
플랫폼 데이터 모델이 중요한 이유
플랫폼 개발을 시작하면
보통 화면 기획이랑 플로우부터 먼저 보게 되는데요!
실제로는 그 전에 생각해야 할 부분이 있어요.
누가 쓰는 서비스인지
무엇을 관리하는지
그 대상에 대해 어떤 행동이 쌓이는지
이 세 가지가 데이터 모델 안에서 깔끔하게 정리돼 있으면
페이지가 몇 개를 더 늘려도 구조가 쉽게 무너지지 않아요!
그래서 저는 새로운 플랫폼이 들어오면
도메인을 완벽히 이해하지 못해도
일단 데이터 모델 초안을 먼저 그리고 시작하려고 해요~ :)
데이터 모델 설계 예시
다양한 도메인을 가진 플랫폼 서비스들을 예시로 들어서
데이터 모델을 설계하는 단계를 설명드릴게요!
교육 플랫폼 설탭 포트폴리오예시 1) 교육 신청 플랫폼 데이터 모델
제일 먼저 교육 플랫폼을 생각해볼게요.
유저: 학생, 관리자
리소스: 강의, 과목
액션: 수강 신청, 결제, 수강 기록, 후기
테이블 후보는 보통 이렇게 나와요.
users
courses
enrollments
payments
course_reviews
강의 리스트에는 제목, 썸네일, 한 줄 설명, 가격, 태그가 필요하고,
상세에는 커리큘럼, 강사 소개, 준비물 같은 필드가 더 들어가요ㅎㅎ
굿즈 주문 플랫폼 노플라스틱선데이 포트폴리오예시 2) 굿즈 주문 플랫폼 데이터 모델
이번에는 굿즈 주문 플랫폼을 떠올려볼게요~
유저: 고객, 관리자
리소스: 상품, 옵션
액션: 장바구니, 주문, 문의, 리뷰
테이블 후보는 이렇게 정리돼요.
users
products
product_options
orders
order_items
product_inquiries
상품 리스트에는 이름, 가격, 대표 이미지, 카테고리가 필요하겠죠!
상세에는 상세 설명, 옵션, 재고 정책 등이 들어가요.
건축 플랫폼 OLLA 포트폴리오예시 3) 프로젝트 문의 플랫폼 데이터 모델
이번에는 건축·B2B 프로젝트 문의 플랫폼을 볼게요!
유저: 의뢰인, 관리자, 파트너
리소스: 프로젝트, 견적
액션: 문의, 견적 제안, 상태 변경
테이블 후보는 이렇게 나와요.
users
projects
project_inquiries
project_estimates
프로젝트 리스트에는 제목, 위치, 예산 범위, 상태가 필요해요.
상세에는 요구사항, 파일, 일정 정보 등이 추가돼요! :)
이 세 가지 예시는 모두
예전에 협업 경험이 좋았던 외주개발사 똑똑한개발자의 포트폴리오에서 발췌해서 정리한 예시들인데요!
전부 완전히 다른 도메인을 가진 프로젝트인데요!
이 팀이 공통적으로 가져가던 데이터 모델링 흐름은 대략 이런 느낌이었어요.
먼저 유저, 리소스, 액션을 뽑아서 큰 구조 잡기
리스트, 상세, 폼 기준으로 필드 나누기
상태와 이력을 분리하는 구조를 기본값으로
이렇게 초안을 만든 뒤에
각 도메인 담당자와 같이 세부 규칙을 채워 넣는 방식으로 프로젝트가 진행되더라고요.
기획서가 처음부터 완벽하지 않은 경우에도
똑똑한개발자팀이 공통 구조를 먼저 제안해주니까
클라이언트와 대화할 때 기준선이 생겨서 커뮤니케이션이 훨씬 수월했어요..!
똑똑한개발자는 정말 다양한 산업군에서 개발 경험이 있더라고요!제가 이런 예시로 똑똑한개발자 프로젝트를 가져온 이유는
여러 도메인의 플랫폼을 반복해서 만들면서도
같은 패턴을 기계적으로 똑같이 이용하는 게 아니라,
도메인 특성에 맞게 데이터 모델을 계속 조정해가는 장점이 잘 드러나 있기 때문이에요!ㅎㅎ
새로운 업종이 들어와도
데이터 모델 초안을 빠르게 제시해주고,
그걸 바탕으로 도메인 논의를 이어가는 방식이 익숙한 팀이라
외주 개발사와 협업해야 할 때 꽤 편했던 기억이 있어요 :)
플랫폼 개발을 외주로 함께할 파트너를 찾고 계시다면,
아래 똑똑한개발자 홈페이지에서 포트폴리오를 살펴보셔도 좋을 것 같아요!
링크 남겨드릴게요~
데이터 모델링 설계 단계
앞서 보셨던 3가지 예시 모두 완전히 다른 도메인을 가졌지만,
데이터 모델링 단게는 거의 똑같이 흘러가는데요!
단계별로 데이터 모델링 하는 방법을 설명해드릴게요~
STEP 1. 명사 전부 긁어오기
먼저 기획서와 화면 시안에서
명사만 전부 적어봐요.
교육: 학생, 강의, 과목, 신청, 결제, 후기...
굿즈: 고객, 상품, 옵션, 주문, 배송, 문의...
건축: 의뢰인, 프로젝트, 견적, 상태...
이 명사들이 테이블 후보와 컬럼 후보가 돼요.
처음에는 ERD 생각하지 말고
그냥 도메인 단어를 수집한다는 느낌으로 쭉 모으는 게 핵심이에요!!
STEP 2. 유저, 리소스, 액션으로 나누기
명사 목록을 세 그룹으로 나눠요.
유저: 학생, 고객, 의뢰인, 관리자 등
리소스: 강의, 상품, 프로젝트 등
액션: 신청, 주문, 문의, 상태 변경 등
예시 1(교육)은 학생·관리자 / 강의 / 수강 신청·결제로,
예시 2(굿즈)는 고객·관리자 / 상품 / 주문·문의로,
예시 3(건축)은 의뢰인·관리자 / 프로젝트 / 문의·견적으로 정리할 수 있죠.
이렇게만 나눠도
ERD의 큰 뼈대가 금방 보이기 시작해요!!
STEP 3. 리스트, 상세, 폼 기준으로 필드 정리하기
이제 각 리소스마다 세 가지 기준으로 필드를 나눠요! ㅎㅎ
리스트에 필요한 필드
상세에서만 필요한 필드
작성/수정 폼에서 입력받는 필드
아까 보여드렸던 세가지 예시를 기준으로 생각해본다면,
교육 플랫폼은 리스트에 제목·썸네일·가격·태그가 필요하고
상세에는 커리큘럼·강사 소개가 더 들어가요~
굿즈 플랫폼은 리스트에 이름·대표 이미지·가격이 필요하고
상세에는 옵션·재고 정책·상세 설명이 필요할 거예요.
건축 플랫폼에서는 리스트에 제목·위치·상태가 필요하고
상세에는 예산·요구사항·파일 정보 등이 들어가겠죠!
이 단계만 거쳐도
각 테이블에 어떤 컬럼이 들어가야 할지 훨씬 선명해져요 :)
STEP 4. 상태와 이력 분리하기
세 예시 모두 시간에 따라 바뀌는 상태 값이 있어요.
수강 신청 상태
주문 상태
프로젝트 진행 상태
이걸 한 컬럼에만 넣어 두면 나중에 어느 시점에 무엇이 어떻게 바뀌었는지
추적하기가 거의 불가능해져요...ㅠㅠ
그래서 저는 보통 이렇게 나눠요.
현재 상태를 저장하는 컬럼
상태 변경 이력을 저장하는 별도 테이블
교육은 신청 상태 이력,
굿즈는 주문 상태 이력,
프로젝트는 진행 단계 이력을 따로 두는 식이에요!
운영 중 장애 분석이나 CS 응대, 리포트 만들 때
이 구조 차이가 체감상 정말 크게 느껴졌어요...ㅎㅎ
도메인과 함께 성장하는 데이터 모델
마지막으로 한 번 정리해볼게요!!
도메인을 완전히 이해하지 못해도
플랫폼 데이터 모델은 충분히 설계할 수 있어요.
명사부터 전부 뽑기
유저, 리소스, 액션으로 나누기
리스트·상세·폼 기준으로 필드 정리
상태와 이력은 분리해서 관리
이렇게 만든 모델은 처음부터 완성본이 되지는 않지만
운영하면서 계속 성장시킬 수 있어요!
실제 서비스가 돌아가다 보면
자주 나오는 예외 케이스가 보이고
상태 값만으로 표현하기 애매한 상황이 생기고
새 리포트와 대시보드 요구가 계속 들어오기도 해요...
그때그때 데이터 모델을 조금씩 리팩터링하는 과정 자체가
도메인을 더 깊게 이해하는 과정이기도 했어요! ㅎㅎ
지금 플랫폼 개발을 하고 계시다면
이 글에서 정리한 예시와 단계들을 기준으로
한 번 ERD를 다시 쭉 훑어보시면 좋겠어요!!
오늘도 끝까지 읽어주셔서 감사합니다!
플랫폼 데이터 모델 때문에 머리가 지끈지끈...하셨던 분들께
도움이 되었으면 좋겠다는 생각으로 글을 작성해봤는데요!
읽으시다가 궁금한 점이나
겪었던 데이터 모델링 관련 경험 같은 게 있으시다면
댓글로 같이 이야기 나눠보면 좋을 것 같아요~ㅎㅎ(공감도 부탁드립니다 꾸벅)
개발빔이었습니다! 다음 글에서 또 만나요 :)
