[개발] 데이터베이스 모델링, 이것만 알면 당신도 전문가!

개발자에게 SQL 만큼이나 중요한 개념, 바로 데이터베이스 모델링입니다. 단순히 쿼리를 잘 짜는 것을 넘어, 훌륭한 백엔드 엔지니어는 클라이언트의 요구사항에 맞춰 최적의 데이터베이스 구조를 설계할 수 있어야 합니다. 오늘은 데이터베이스 모델링이 정확히 무엇인지, 그리고 어떻게 하면 잘할 수 있는지 단계별로 알아보겠습니다.

🚀 1단계: 클라이언트 요구사항 분석하기

모든 프로젝트의 시작은 클라이언트의 요구사항을 듣는 것에서부터 출발합니다. 여기서 클라이언트는 고객사, 상사, 동료 개발자, 기획자 등 다양할 수 있습니다. 가장 중요한 점은 이것입니다.

"클라이언트는 자신이 원하는 것을 100% 완벽하게 설명하지 못한다."

따라서 우리는 수동적으로 듣기만 하는 것이 아니라, 적극적으로 질문하고 숨겨진 요구사항을 파악하여 최적의 해를 찾아야 합니다.

💡 클라이언트 요구사항 끌어내기 경진대회

Q. 여러분이라면 클라이언트에게서 어떻게 요구사항을 효과적으로 끌어내어 빈틈없는 데이터베이스 모델링을 준비하시겠습니까? 5분간 각자의 아이디어를 공유해봅시다!

🏗️ 2단계: 데이터베이스 모델링이란?

클라이언트의 요구사항이 접수되고, 이를 구현하기 위해 데이터베이스를 사용해야 할 때 '설계' 작업이 필요합니다. 게임에 새로운 '퀘스트 시스템'을 추가하는 상황을 예로 들어볼까요? 이 시스템을 위해 어떤 데이터가 필요하고, 데이터들은 서로 어떤 관계를 맺어야 하는지 구조를 짜는 것, 이것이 바로 모델링입니다.

핵심은 현실 세계의 복잡한 문제를 추상화하여 데이터베이스라는 공간에 명확하고 단순하게 표현하는 과정입니다. 모델링은 단순히 스키마를 짜는 것 이상이며, 추상화 수준에 따라 다음과 같은 3단계로 나뉩니다.

데이터베이스 모델링 3단계

개념적 데이터 모델링 (Conceptual Data Modeling)
- 목표: 최상위 수준에서 데이터베이스의 큰 그림을 그립니다.
- 작업: 클라이언트의 요구사항을 바탕으로 필요한 정보(엔티티), 속성, 제약조건, 엔티티 간의 관계를 정의합니다. 정규화를 통해 데이터 중복을 제거하고 무결성을 확보합니다.
- 예시 (온라인 서점): '고객'은 여러 '주문'을 할 수 있고(1:N), '주문'은 여러 '제품'을 포함합니다. '고객'에게는 ID, 이름, 주소 등의 '속성'이 필요합니다.
논리적 데이터 모델링 (Logical Data Modeling)
- 목표: 개념적 모델을 실제 데이터베이스에 적용할 수 있도록 구체화합니다.
- 작업: 테이블, 컬럼, 데이터 타입, 제약조건, 테이블 간의 관계와 카디널리티(1:1, 1:N, M:N)를 명시합니다.
- 예시 (온라인 서점): '고객' 테이블은 CustomerID (PK), Name (VARCHAR), Address (VARCHAR) 등의 컬럼으로 구성됩니다. '주문' 테이블은 CustomerID (FK)를 통해 '고객' 테이블을 참조합니다.
물리적 데이터 모델링 (Physical Data Modeling)
- 목표: 데이터가 하드웨어에 물리적으로 어떻게 저장되고 관리될지 정의합니다.
- 작업: 저장 파일, 인덱스, 저장소 할당(SSD/HDD 등)을 설계합니다.
- 참고: 이 단계는 주로 DBA(데이터베이스 관리자)나 시스템 관리자의 영역입니다. 대부분의 백엔드 개발자는 개념적/논리적 모델링에 집중합니다.

우리가 프로젝트에서 집중해야 할 것은 바로 1) 개념적 & 논리적 모델링을 진행하고, 2) 그 결과를 ERD(Entity-Relationship Diagram)로 시각화하는 것입니다.

📖 3단계: ERD 핵심 용어 정복하기

모델링 결과를 시각적으로 표현하는 ERD를 이해하기 위해 몇 가지 핵심 용어를 알아봅시다.

엔티티 (Entity): 데이터로 관리해야 할 대상. 현실의 개체(연구원, 프로젝트)나 개념(스토리, 태스크)이 될 수 있습니다.
애트리뷰트 (Attribute): 엔티티가 가지는 속성 또는 구성 요소. (예: 프로젝트 엔티티의 '프로젝트_번호', '프로젝트_이름')
릴레이션 (Relation): 엔티티와 엔티티 간의 관계를 의미합니다.
카디널리티 (Cardinality): 관계에 참여하는 인스턴스의 수를 나타냅니다. (1:1, 1:N, M:N)
기본키 (Primary Key, PK): 엔티티 내에서 각 인스턴스(행)를 유일하게 식별하는 값입니다.
외래키 (Foreign Key, FK): 다른 테이블의 기본키를 참조하여 테이블 간의 관계를 맺어주는 역할을 합니다.

✅ 4단계: 데이터베이스 모델링 기본 원칙

좋은 모델을 만들기 위해 반드시 지켜야 할 몇 가지 원칙이 있습니다.

업무에 필요한 모든 데이터를 모델에 정의해야 합니다.
비슷한 속성으로 구성된 두 엔티티는 하나로 통합하는 것을 고려합니다.
애트리뷰트 이름은 누가 봐도 이해하기 쉽게 작성하되, 너무 길지 않게 합니다.
하나의 애트리뷰트가 여러 값을 가지려 한다면, 별도의 엔티티로 분리하는 것이 좋습니다.
엔티티와 애트리뷰트는 '명사', 관계는 '동사'로 표현하는 것이 자연스럽습니다.
데이터 중복(Data Redundancy)을 최소화해야 합니다. 데이터 중복은 저장 공간 낭비와 데이터 일관성 유지 보수 비용을 증가시킵니다.

🗂️ 5단계: 올바른 데이터 타입 선택하기

각 컬럼에 올바른 데이터 타입을 지정하는 것은 성능, 공간 효율성, 데이터 무결성과 직결되는 매우 중요한 작업입니다.

💡 Tip: 소수점의 정확한 계산이 중요하다면 DECIMAL, 그렇지 않다면 보통 FLOAT나 DOUBLE로도 충분합니다!

정수 타입: TINYINT, SMALLINT, INT, BIGINT 등. 저장할 값의 범위를 고려하여 최소한의 타입으로 선택하는 것이 효율적입니다.
문자열 타입: CHAR(고정 길이), VARCHAR(가변 길이), TEXT(긴 텍스트).
날짜/시간 타입: DATE, TIME, DATETIME, TIMESTAMP.
부동소수점 타입: FLOAT, DOUBLE. 넓은 범위의 실수를 근사치로 표현합니다.
고정소수점 타입: DECIMAL. 금융 계산 등 정확한 소수점 연산이 필요할 때 사용합니다.

Q1. 서비스 최종 이용자가 1,000명 정도로 예상된다면, 회원 ID 컬럼에 어떤 정수 타입을 선택하는 것이 가장 효율적일까요?

A1. TINYINT(1바이트, 0~255)는 부족하고, SMALLINT(2바이트, 0~65,535)가 적합합니다. INT(4바이트)도 가능하지만, 필요한 범위를 훨씬 초과하므로 약간의 공간 낭비가 발생할 수 있습니다.

Q2. 왜 보통 테이블의 ID 필드는 문자열(VARCHAR)보다 정수(INT) 타입을 선호할까요?

A2. 정답은 크게 세 가지 이유 때문입니다.

성능: 숫자 비교는 문자열 비교보다 훨씬 빠릅니다. 특히 WHERE 절에서 자주 사용되는 ID의 경우 이 성능 차이가 매우 커질 수 있습니다.
공간: 일반적으로 같은 값을 표현할 때 정수 타입이 문자열 타입보다 더 적은 저장 공간을 사용합니다.
정렬: 숫자는 값의 크기대로 정렬되지만, 문자열은 사전 순서로 정렬됩니다. ('10'이 '2'보다 앞에 오는 문제) 이로 인해 의도치 않은 정렬 결과가 발생할 수 있습니다.

부동소수점 vs 고정소수점, 언제 뭘 쓸까?

부동소수점 (Floating-Point): 소수점의 위치가 움직이는 방식(지수 표현). 매우 크거나 작은 수를 포함한 넓은 범위의 수를 표현하는 데 유리하지만, 근사값으로 저장되어 정밀도에 오차가 발생할 수 있습니다. (과학, 공학 계산에 주로 사용)
고정소수점 (Fixed-Point): 소수점의 위치가 고정된 방식. 표현 범위는 좁지만, 지정된 소수점 자리까지는 정확한 값을 표현합니다. 오차가 없어야 하는 금융, 회계 데이터에 필수적입니다.

지금까지 데이터베이스 모델링의 전반적인 과정과 핵심 개념들을 살펴보았습니다. 탄탄한 모델링은 안정적이고 확장성 있는 서비스를 만드는 첫걸음입니다. 처음에는 어렵게 느껴질 수 있지만, 여러 번 연습하고 고민하다 보면 분명 좋은 구조를 설계하는 눈을 기를 수 있을 것입니다. 😊