프론트엔드 개발자가 DB를 다룰 때는 보통 만들 화면에 필요한 데이터를 중심으로 테이블을 설계합니다. 화면이 먼저 있고, 거기에 맞춰 컬럼을 붙이는 방식입니다. 데이터 아키텍처(DA)는 시선이 반대입니다. 사업이 다루는 데이터 전체를 먼저 정리하고, 그 위에 화면이나 API를 얹습니다.
이 글은 그 시선 전환의 첫 단계인 개념 모델까지를 다룹니다. 데이터 모델링이 왜 필요한지, 그리고 가장 먼저 배우는 세 단어인 엔터티·속성·관계가 무엇인지 정리합니다.
집을 지을 때 방부터 짓지 않습니다. 평면도, 배관, 전기 같은 전체 설계도를 먼저 그립니다. 데이터 아키텍처는 그 "전체 설계도"를 담당하는 일입니다. 화면이 바뀌어도 데이터 구조가 튼튼하면 흔들리지 않습니다. 채용 공고에 자주 등장하는 "Biz 변화에 유연한 데이터 아키텍처"가 바로 이 뜻입니다.
그 설계도를 그리는 행위가 데이터 모델링입니다.
[화면 중심 설계]
화면 A 필요 → 테이블 A
화면 B 필요 → 테이블 B ── 화면이 바뀌면 테이블도 흔들린다
화면 C 필요 → 테이블 C
[데이터 중심 설계]
사업 전체 데이터 설계도
│
├── 화면 A
├── 화면 B ── 화면이 바뀌어도 데이터 구조는 그대로
└── 화면 C모델링은 현실 세계를 단순하게 본떠서 표현하는 것입니다. 지하철 노선도를 생각하면 됩니다. 실제 선로는 구불구불하지만 노선도는 직선과 점으로 단순화합니다. 불필요한 건 버리고 "어디서 갈아타는지"라는 목적에 필요한 것만 남깁니다.
데이터 모델링은 현실의 업무를 데이터 관점에서 본떠 그리는 것입니다. 예를 들어 온라인 쇼핑몰을 데이터로 본뜨면 다음과 같이 정리됩니다.
핵심 덩어리와 그 사이의 관계를 정리하는 작업입니다.
모델링은 한 번에 완성하지 않고 세 단계로 점점 구체화됩니다.
| 단계 | 이름 | 무엇을 정하나 | 비유 |
|---|---|---|---|
| 1 | 개념 모델 | 큰 덩어리와 관계만 | 손으로 쓱 그린 집 스케치 |
| 2 | 논리 모델 | 세부 항목, 규칙까지 | 치수가 들어간 정식 도면 |
| 3 | 물리 모델 | 실제 DB에 맞춘 형태 | 실제 시공 도면 |
스케치 → 도면 → 시공도면. 뒤로 갈수록 구체적이며, 앞 단계가 틀리면 뒤가 다 틀어집니다. 그래서 앞 단계부터 제대로 잡는 것이 중요합니다. 이 글은 1단계인 개념 모델까지만 다룹니다.
개념 모델은 세 단어로 시작합니다. 엔터티, 속성, 관계입니다. 이 셋이 개념 모델의 알파벳입니다.
업무에서 데이터로 저장하고 관리할 가치가 있는 대상입니다. 쇼핑몰 예시에서는 회원, 상품, 주문이 엔터티입니다.
엔터티에는 세 가지 공통점이 있습니다.
판별법은 단순합니다. "~들"을 붙여 말이 되고, 그것마다 정보를 적을 칸이 필요하면 엔터티입니다. 물리 모델까지 가면 엔터티는 테이블이 됩니다. 다만 모델링 단계에서는 아직 기술 용어(테이블)가 아니라 업무 언어(엔터티)를 씁니다.
엔터티가 가지고 있는 하나하나의 정보 항목입니다.
회원 엔터티의 속성: 회원번호, 이름, 이메일, 전화번호, 가입일상품 엔터티의 속성: 상품번호, 상품명, 가격, 재고수량물리 모델까지 가면 속성은 컬럼(열)이 됩니다.
모델링 단계의 업무 언어가 물리 모델로 가면 기술 언어로 바뀝니다. 그 대응 관계는 다음과 같습니다.
| 모델링 용어 (업무 언어) | DB 용어 (기술 언어) | 쉬운 말 |
|---|---|---|
| 엔터티 | 테이블 | 데이터 덩어리 |
| 속성 | 컬럼 | 정보 항목 |
| 인스턴스 | 행(row) | 실제 데이터 한 줄 |
예를 들면 이렇습니다. 회원 엔터티(테이블)가 있고, 이름과 이메일은 속성(컬럼)이며, "김미민 / mimin@example.com"이라는 실제 한 줄이 인스턴스(행)입니다.
엔터티와 엔터티 사이의 연결입니다. 회원과 주문은 "회원이 주문을 한다"로 엮입니다. 이 엮임이 관계입니다.
관계에서 가장 중요한 것은 "몇 대 몇이냐"입니다. 이를 카디널리티(cardinality)라고 합니다. 뜻은 단순합니다. "한쪽 하나에 반대쪽이 몇 개 붙느냐"입니다.
카디널리티는 세 종류가 있습니다.
| 종류 | 표기 | 예시 |
|---|---|---|
| 1 대 1 | 1:1 | 회원 한 명은 하나의 회원등급 정보를 가진다 |
| 1 대 다 | 1:N | 회원 한 명은 여러 주문을 하지만, 주문 하나는 한 회원에게만 속한다 |
| 다 대 다 | M:N | 회원은 여러 상품을 사고, 상품도 여러 회원이 산다 |
가장 흔한 것은 1:N입니다. 판별법은 양방향으로 질문하는 것입니다.
[회원 ↔ 주문]
회원 한 명이 주문을 몇 개 하나? → 여러 개
주문 하나는 회원 몇 명의 것인가? → 한 명
─────────
회원 : 주문 = 1 : N카디널리티가 중요한 이유는 논리·물리 모델에서 테이블을 어떻게 쪼개고 연결할지가 여기서 결정되기 때문입니다. 특히 M:N 관계는 DB에 그대로 만들 수 없어 중간 테이블이 필요해집니다. 이 부분은 다음 단계인 논리 모델에서 다룹니다.
개념 모델 단계에서는 의식적으로 DB를 잊는 편이 좋습니다. 테이블, 컬럼, 외래 키, 인덱스 같은 단어가 머릿속에 들어오는 순간 설계가 화면이나 쿼리에 끌려가기 시작합니다.
대신 업무 언어로만 말합니다. "회원이 주문을 한다", "주문은 여러 상품을 가진다", "상품은 카테고리에 속한다". 이 문장들이 그대로 엔터티와 관계가 됩니다. 테이블이 몇 개일지, 키를 어떻게 잡을지는 그다음 단계가 알아서 따라옵니다.
데이터 아키텍처는 화면에 맞춘 데이터가 아니라 사업 전체의 데이터 설계도를 그리는 일이고, 그 설계도를 그리는 작업이 데이터 모델링입니다. 모델링은 개념 → 논리 → 물리 3단계로 구체화되며, 앞 단계가 틀리면 뒤가 다 틀어집니다.
개념 모델의 알파벳은 세 단어입니다. 엔터티는 데이터 덩어리(나중에 테이블), 속성은 세부 항목(나중에 컬럼), 관계는 엔터티 간 연결입니다. 관계에는 1:1, 1:N, M:N 세 종류가 있으며 이를 카디널리티라고 합니다. 이 단계에서 중요한 사고 전환은 하나입니다. DB를 떠올리기 전에 업무부터 그린다.