개념적 데이터 모델링

데이터베이스 설계는 단순히 테이블을 만드는 작업이 아닙니다. 현실 세계의 요구를 데이터 구조로 변환하는 일련의 설계 과정이며, 이 과정은 명확한 단계에 따라 진행됩니다. 각 단계는 서로 연결되어 있으며, 앞 단계에서 얼마나 명확하게 정의했는지가 다음 단계의 품질을 결정합니다.

데이터베이스 설계의 전체 단계

데이터베이스 설계는 일반적으로 다섯 단계로 구분됩니다.

첫 번째는 요구사항 수집 및 분석 단계입니다. 이 단계에서는 서비스가 어떤 데이터를 필요로 하는지, 데이터는 어떤 방식으로 사용되는지, 데이터 간에는 어떤 관계가 존재하는지를 정리합니다. 이는 기획 초기 단계에서 자연스럽게 수행되는 작업과 유사합니다. 기능을 정의하기 전에 어떤 정보가 저장되어야 하는지, 그 정보가 어디에서 생성되고 어떻게 조회되는지를 확인하는 과정이라고 보시면 됩니다.

두 번째는 개념적 설계 단계입니다. 이 단계에서는 수집된 요구사항을 바탕으로 데이터를 개념적인 모델로 표현합니다. 현실 세계의 요소를 개체로 정의하고, 개체의 속성을 정리하며, 개체 간의 관계를 구조화합니다. 이 과정이 바로 개념적 데이터 모델링입니다.

세 번째는 논리적 설계 단계입니다. 개념적 모델을 실제 데이터베이스 관리 시스템(DBMS)에 적합한 구조로 변환하는 단계입니다. ER 다이어그램을 테이블 구조로 전환하고, 각 개체를 테이블로, 속성을 컬럼으로 매핑합니다.

네 번째는 물리적 설계 단계입니다. 실제 DBMS 환경에서 데이터베이스를 구축하기 위한 설정 단계입니다. 테이블 구조를 확정하고, 인덱스를 설정하여 조회 성능을 최적화합니다. 인덱스는 데이터를 효율적으로 검색하기 위한 구조로, 설계 또는 운영 단계에서 적절히 구성하면 성능에 직접적인 영향을 미칩니다.

다섯 번째는 구현 단계입니다. 설계된 구조를 실제 운영 환경에 적용하여 데이터베이스를 생성하고 운용하는 단계입니다.

이 중에서 기획자가 깊이 관여할 수 있는 영역은 요구사항 분석과 개념적 설계 단계입니다. 기획자는 데이터의 종류와 관계를 정의함으로써 개발자와 협업할 수 있습니다. 물리적 설계나 구현을 직접 수행하지 않더라도, 데이터 구조를 이해하고 명확히 정의하는 역할은 충분히 수행할 수 있습니다.

 

개념적 데이터 모델링의 핵심 구조

개념적 설계는 현실 세계의 중요한 데이터를 추출하여 구조화하는 작업입니다. 이 단계에서 사용하는 대표적인 모델이 개체-관계 모델(Entity-Relationship Model)입니다. 개체-관계 모델은 데이터를 세 가지 요소로 나누어 정의합니다.

• 첫째, 개체(Entity)입니다. 개체는 현실 세계에 존재하는 사람, 사물, 장소, 사건과 같은 독립적인 객체를 의미합니다.
• 둘째, 속성(Attribute)입니다. 속성은 개체가 가지는 특성입니다. 하나의 개체는 여러 개의 속성을 가질 수 있습니다. 이 중 개체를 고유하게 식별할 수 있는 속성을 키 속성(Key Attribute)이라고 합니다.
• 셋째, 관계(Relationship)입니다. 관계는 개체와 개체 사이의 연관성을 의미합니다. 관계는 1:1, 1:N, N:M과 같이 연결 유형으로 표현됩니다.

ER 다이어그램은 이러한 요소를 시각적으로 표현한 도식입니다. 개체는 사각형, 속성은 타원, 관계는 마름모 또는 선으로 표현됩니다. 이는 데이터를 개념적으로 정리하는 도구이며, 아직 물리적인 테이블 구조를 의미하지는 않습니다. 

 

커머스 서비스 사례를 통한 개념적 설계

온라인 쇼핑몰 서비스를 가정해 보겠습니다. 사용자는 회원 가입 후 제품을 구매할 수 있으며, 구매 내역은 조회 가능해야 한다는 요구사항이 정의되어 있습니다. 이 요구사항을 데이터 관점으로 정리하면 다음과 같은 구조가 도출됩니다.

• 회원은 중복되지 않는 아이디를 가지며, 이름과 전화번호를 가집니다.
• 제품은 중복되지 않는 제품 아이디를 가지며, 제품명과 가격을 가집니다.
• 회원은 여러 번 제품을 구매할 수 있습니다.
• 구매 시에는 구매 일시, 결제 금액, 결제 수단이 함께 저장되어야 합니다.

이 요구사항을 개념적으로 정리하면 세 개의 주요 개체가 도출됩니다.

• 회원(Member)
• 제품(Product)
• 구매(Purchase)

회원 개체의 속성은 아이디, 이름, 전화번호입니다. 이 중 아이디는 고유하므로 키 속성입니다. 제품 개체의 속성은 제품 아이디, 제품명, 가격입니다. 제품 아이디가 키 속성입니다. 구매는 회원과 제품 사이에서 발생하는 관계이며, 단순 연결이 아니라 자체 속성을 가집니다. 구매 번호, 구매 일시, 결제 금액, 결제 수단은 관계에서 발생하는 속성입니다. 이 중 구매 번호는 키 속성입니다. 관계의 유형은 한 명의 회원이 여러 번 구매할 수 있으므로 1:N 관계로 정의됩니다.

이 구조를 ER 다이어그램으로 표현하면, 회원과 제품이 개체로 존재하고, 그 사이에 구매 관계가 위치하며, 관계에 구매 관련 속성이 연결됩니다.

 

개념적 모델에서 기획안으로의 전환

ER 다이어그램은 데이터 구조를 이해하는 데 유용하지만, 기획 문서로는 충분하지 않습니다. 기획 단계에서는 각 데이터 항목을 구체적으로 정의해야 합니다.

예를 들어, 회원 테이블을 정의할 경우 다음과 같은 항목을 정리합니다.

• ID: 회원이 등록한 고유 값, 중복 불가, 필수
• 이름: 회원의 이름, 중복 가능, 필수
• 전화번호: 회원의 연락처, 중복 여부는 정책에 따라 설정

제품 역시 동일하게 정의합니다.

• 제품 ID: 고유 값, 중복 불가
• 제품명: 제품의 이름
• 가격: 판매 가격

구매 데이터는 다음과 같이 정리됩니다.

• 구매번호: 고유 값
• 구매일시: 구매가 발생한 시점
• 결제금액: 실제 결제된 금액
• 결제수단: 사용된 결제 방식
• 회원 ID: 구매한 회원의 식별자
• 제품 ID: 구매된 제품의 식별자

이처럼 각 항목의 중복 여부, 필수 여부, 식별 기준을 명확히 정의하면 개발자는 데이터베이스를 설계할 때 기획 의도를 정확히 반영할 수 있습니다. 이러한 정의가 없다면 데이터가 중복 저장되거나, 구조가 의도와 다르게 설계될 가능성이 있습니다.

결국 개념적 설계는 단순히 그림을 그리는 작업이 아니라, 데이터의 의미를 구조화하고 정책을 명확히 하는 과정입니다. 

 

논리적 설계와 테이블 구조

개념적 설계를 바탕으로 논리적 설계를 수행하면 각 개체는 테이블로 변환됩니다.

• member 테이블 / product 테이블 / purchase 테이블
• member 테이블에는 member_id가 기본키로 설정됩니다.
• product 테이블에는 product_id가 기본키로 설정됩니다.
• purchase 테이블에는 purchase_number가 기본키로 설정되며, member_id와 product_id는 외래키(FK)로 포함됩니다.

이 구조를 통해 “누가 어떤 제품을 언제 얼마에 어떤 방식으로 구매했는지”를 명확히 추적할 수 있습니다.

 

데이터 중심 플랫폼 확장의 관점

서비스가 성장하면 데이터의 범위와 양이 증가합니다. 데이터 간 관계가 복잡해지고, 하나의 서비스 안에 다양한 역할이 혼재되기 시작합니다. 이 때, 데이터의 성격을 기준으로 서비스를 분리하는 전략이 필요해집니다.

예를 들어,

• 회원 데이터가 확장되면 회원 관리 플랫폼으로 분리할 수 있습니다.
• 결제 수단이 다양해지면 빌링 시스템으로 독립시킬 수 있습니다.
• 제품에 공급처 정보가 추가되면 파트너 관리 플랫폼으로 확장할 수 있습니다.

이러한 분리는 기능이 아니라 데이터 도메인(Data Domain)을 기준으로 이루어집니다. 데이터 도메인 단위로 플랫폼을 나누면 서비스 간 강결합을 줄이고, 각 영역이 독립적으로 확장될 수 있습니다.
데이터 구조를 명확히 이해하고 정의하는 작업은 단순한 설계 단계에 그치지 않습니다. 이는 향후 서비스 확장 전략과도 직결됩니다.

 

정리

데이터베이스 설계는 요구사항 분석에서 시작하여 개념적 설계, 논리적 설계, 물리적 설계, 구현 단계로 이어지는 구조적 과정입니다. 기획 단계에서 가장 중요한 영역은 개념적 데이터 모델링입니다. 개체, 속성, 관계를 명확히 정의하고, 키 속성과 관계 유형을 정리하면 데이터 구조의 뼈대가 완성됩니다. 이 구조를 기반으로 데이터 정의를 구체화하면 기획 의도가 데이터에 반영됩니다. 그리고 이 데이터 구조는 향후 플랫폼 확장과 서비스 분리 전략의 기준이 됩니다.

결국 데이터 설계는 개발을 위한 준비 작업이 아니라, 서비스 구조를 이해하는 가장 본질적인 작업입니다

.