우석이지 Blog

2025년 11월 23일
Modeling

데이터모델링의 역사와 유래

by 전우석

오늘날 우리는 ERD, 정규화, 차원 모델링, NoSQL 스키마 같은 용어를 너무 자연스럽게 사용합니다.
하지만 데이터모델링은 처음부터 완성된 형태로 존재했던 것이 아니라, DB 기술의 발전과 비즈니스 요구(성능·확장성·분석·AI)의 변화에 맞춰 계속 진화해 온 “방법론의 역사”라고 보는 편이 정확합니다.

데이터모델링을 한 문장으로 정의하면 다음과 같습니다.

현실 세계의 데이터와 관계를, 데이터베이스가 이해할 수 있는 구조(모델)로 추상화하는 작업

그리고 이 작업은 시간이 흐르면서 개념 모델 → 논리 모델 → 물리 모델로 점점 체계화되어 왔습니다.

1. 데이터모델링은 어디서부터 시작됐을까?

초기에는 “데이터모델링”이라는 단어 자체가 지금처럼 명확한 개념으로 자리 잡지 못했습니다.
당시에는 DBMS보다 파일 시스템과 애플리케이션 코드가 중심이었고, 데이터 구조는 “설계 문서”가 아니라 “프로그램 내부 정의”에 가까웠습니다.

이 구조의 문제는 명확했습니다.

  • 데이터 구조가 애플리케이션에 강하게 결합됨(높은 결합도)
  • 재사용성과 확장성이 낮음
  • 변경(스키마 변경) 비용이 폭발적으로 커짐

이 한계를 극복하려는 시도가 DBMS 발전을 촉진했고, 자연스럽게 데이터모델(그리고 모델링 방법론)이 발전하게 됩니다.

2. 파일 시스템 시대(1960년대 초반) — “모델링”이 희미하던 시절

초기 컴퓨팅 환경에서 데이터는 주로 파일로 관리되었습니다.

  • 각 애플리케이션이 자기만의 파일 구조를 보유
  • 레코드 구조, 인덱싱, 접근 방식이 프로그램 로직에 묶임
  • “추상적인 모델” 설계보다 코드에 레코드 레이아웃을 정의하는 수준

결과적으로 “데이터가 자산이 되기보다 프로그램의 부속물”이 되기 쉬웠고, 시스템 규모가 커질수록 변경 비용이 매우 커졌습니다.

3. 계층형·네트워크형 데이터 모델(1960~1970년대) — DBMS의 초기 체계화

파일 중심 운영의 한계를 극복하기 위해 DBMS가 본격 등장하고, 이 시기에 데이터 모델의 1차 진화가 발생합니다.

3.1 계층형 모델(Hierarchical) — 트리 구조 중심

대표적으로 IBM의 IMS 같은 시스템이 계층형(트리) 구조를 기반으로 데이터를 표현했습니다.

  • 루트 → 자식 → 손자로 이어지는 1:N 구조
  • 상위 레코드를 따라 내려가며 탐색(네비게이션 방식)
  • 구조가 직관적이고 특정 패턴에서는 성능이 좋음

하지만 한계도 분명했습니다.

  • “부모가 둘”인 관계(다대다 또는 복잡한 관계)를 표현하기 어렵고
  • 구조 변경이 어렵고 유연성이 떨어짐

3.2 네트워크 모델(Network, CODASYL 계열) — 더 복잡한 관계 표현

네트워크 모델은 계층형보다 더 복잡한 관계를 표현하기 위해 발전했습니다.

  • 레코드 타입(record type)과
  • 소유자–멤버(owner–member) 구조의 set 개념
  • 포인터 기반 탐색(네비게이션)으로 관계를 따라감

장점은 “복잡한 관계 표현력”이었지만, 단점 역시 컸습니다.

  • 개발자가 저장 구조와 탐색 경로를 깊이 이해해야 함
  • 응용 프로그램이 특정 물리 구조에 강하게 결합됨(데이터 독립성 낮음)

이 시기의 핵심 의미는 다음입니다.

Early data models infographic showing three panels: file system records tied to application code, hierarchical tree model (root-parent-child), and network model (owner-member sets) with arrows indicating pointer-based traversal and flexibility.

4. 관계형 데이터 모델(1970년대) — E.F. Codd가 연 “새 시대”

1970년, E.F. Codd는 관계형 모델을 제안하며 데이터모델링의 패러다임을 바꿉니다.
관계형 모델의 핵심은 기술적으로는 “테이블”이지만, 철학적으로는 “분리”에 있습니다.

핵심 아이디어:

  • 데이터를 테이블(릴레이션)의 집합으로 표현
  • 행(튜플)과 열(속성)로 구성
  • 수학적 집합론과 관계 대수 기반
  • 데이터 구조(논리)와 접근 방식(질의)을 분리
  • 사용자는 “논리적 구조 + 선언적 질의” 중심으로 데이터에 접근

즉,

물리적인 저장 구조는 숨기고, 사용자는 논리적 구조와 선언적 질의(SQL)에 집중한다

이 철학은 실무에서 다음 효과로 이어집니다.

  • 데이터 독립성(Data Independence) 강화
  • 스키마 변경 시 프로그램 수정 부담 감소
  • SQL 같은 고수준 질의 언어의 기반 강화
  • 정규화/제약조건/트랜잭션 같은 “모델링-운영-무결성” 개념이 체계화되기 쉬워짐

5. ER(Entity–Relationship) 모델(1970년대 중반) — Peter Chen의 개념적 모델링

관계형 모델이 “테이블/이론” 중심으로 전개되던 흐름에서, ER 모델은 “현실 세계를 어떻게 표현할 것인가”를 더 직관적으로 다룰 수 있게 만들었습니다.

ER 모델의 핵심 구성요소:

  • 엔터티(Entity): 독립적으로 존재하는 객체(예: 고객, 주문)
  • 속성(Attribute): 엔터티의 특성(예: 고객명, 주문금액)
  • 관계(Relationship): 엔터티 간 연관(예: 고객-주문)
  • (실무 확장) 카디널리티(1:1, 1:N, N:M), 선택/필수 관계 등

이로써 데이터모델링은 흔히 다음의 계층적 프로세스를 갖추게 됩니다.

  • 개념 모델(ERD): 업무/현실 세계를 이해 가능한 언어로 표현
  • 논리 모델(관계형 스키마): 테이블/키/정규화/제약조건 중심으로 구체화
  • 물리 모델(DBMS 구현): 인덱스/파티션/스토리지/물리 설계 반영

즉, 지금 우리가 “ERD 기반 모델링”이라고 부르는 방식의 뿌리가 여기서 자리 잡습니다.

ERD에서 테이블로 변환하는 과정에 대한 다이어그램. 개념적 모델에서는 고객과 주문 간의 관계를 보여주고, 논리적 모델에서는 고객과 주문 테이블의 구조를 나타내며, 물리적 모델에서는 기본 키와 외래 키 구조를 설명한다.

6. 데이터웨어하우스와 차원 모델링(1990년대) — 분석을 위한 또 다른 설계 철학

1990년대에는 OLTP뿐 아니라 분석·의사결정(DW/BI) 니즈가 급격히 커졌고,
이 환경에서는 “정규화 중심 설계”만으로는 분석 사용성/집계 성능에 한계가 나타났습니다.

그 대표 해법 중 하나가 Ralph Kimball의 차원 모델링(Dimensional Modeling) 입니다.

차원 모델링의 특징:

  • 정규화보다 조회·집계 성능과 이해 용이성을 우선
  • 비즈니스 프로세스를 중심으로
  • Fact(사실) 테이블: 측정값/이벤트(판매, 주문, 접속 등)
  • Dimension(차원) 테이블: 관점/분류(고객, 상품, 시간, 지역 등)
  • 전형적으로 스타 스키마(Star Schema) 형태를 가짐

차원 모델링은 오늘날에도 DW/데이터마트 설계에서 사실상 표준 패턴으로 널리 쓰입니다.

Comparison of OLTP schema and Star schema for dimensional modeling. Left: Normalized OLTP schema with Customer, Order, and Product tables. Right: Star schema with a central Fact table linked to surrounding Dimension tables.

7. 객체지향, UML, 엔터프라이즈 모델링(1990~2000년대) — 모델링의 범위 확장

소프트웨어 개발이 객체지향 패러다임으로 전환되면서 데이터모델링도 영향받습니다.

  • 클래스/상속/다형성 개념이 확산
  • UML이 표준 모델링 언어로 자리 잡음
  • 데이터 구조를 “테이블”만이 아니라 “객체 모델/서비스 관점”에서도 바라보게 됨

이 시기부터 데이터모델링은 단순 DB 스키마 설계를 넘어,

  • 엔터프라이즈 아키텍처(EA)
  • 데이터 아키텍처
  • 거버넌스/표준/MDM

같은 영역과 결합되며 “조직 차원의 설계”로 확장됩니다.

8. NoSQL과 다중 데이터 모델(2000~2010년대) — “정규화”보다 “접근 패턴”이 중요해진 시대

웹 서비스와 빅데이터가 본격화되면서 요구가 달라집니다.

  • 수평 확장(Scalability)
  • 유연한 스키마
  • 대량의 반정형/비정형 데이터 처리
  • 낮은 지연/고처리량

이 흐름 속에서 NoSQL과 다양한 데이터 모델이 부상합니다.

대표 유형:

  • 키-값(Key-Value)
  • 문서(Document)
  • 컬럼 패밀리(Column-Family)
  • 그래프(Graph)

이 시기 데이터모델링의 초점 변화는 다음으로 요약됩니다.

“완벽한 정규화”보다
접근 패턴(Access Pattern)과 확장성을 중심으로 스키마를 디자인한다.

즉, 모델러는 관계형뿐 아니라 다양한 데이터 모델을 복합적으로 이해하고 문제에 맞게 선택해야 하는 시대에 들어섭니다.

Flat vector infographic illustrating different NoSQL data models: Key-Value, Document, Column-Family, and Graph. Emphasizes the principle 'Access patterns first' and describes how different models optimize various query patterns and scalability needs.

9. 클라우드·데이터레이크·AI 시대(2010년대 후반~현재) — “플랫폼 레벨 모델링”으로 확장

최근에는 다음 요소가 동시에 얽힙니다.

  • 클라우드 데이터 플랫폼(DWH, Lakehouse 등)
  • 데이터레이크/오브젝트 스토리지
  • 실시간 스트리밍
  • AI/ML, LLM
  • 벡터 스토어(임베딩 기반 검색)

이제 모델링의 대상은 “단일 DB 스키마”만이 아닙니다.

  • RDB(OLTP)
  • DW/마트(분석)
  • Lake/Lakehouse(대규모 저장/유연한 스키마)
  • 스트리밍/이벤트 로그
  • 피처 스토어(ML)
  • 벡터 스토어(RAG/LLM)

같은 여러 저장소를 아우르는 엔터프라이즈/플랫폼 레벨 모델링이 요구됩니다.
말 그대로 “AI 시대 데이터모델링”이라는 새로운 챕터가 열린 셈입니다.

다양한 데이터 플랫폼 구성 요소를 나타내는 다이어그램, OLTP RDBMS, 데이터 웨어하우스, 데이터 레이크/레이크하우스, 스트리밍/이벤트 버스, 피처 스토어, 벡터 저장소와 BI/ML/LLM 애플리케이션이 포함되어 있으며, 거버넌스 및 메타데이터 레이어를 강조함.

10. 타임라인으로 보는 데이터모델링의 큰 흐름(요약)

아주 거칠게 시대 흐름을 정리하면 아래처럼 볼 수 있습니다.

  • 1960s: 파일 시스템 중심, 초기 DBMS, 계층형/네트워크형 모델 등장
  • 1970s: 관계형 모델(Codd), ER 모델(Chen) → 현대적 모델링 기반 형성
  • 1980s: 상용 RDBMS 확산, ERD 기반 설계가 표준화
  • 1990s: DW/BI 확산, 차원 모델링(Kimball) 부상
  • 2000s: UML/EA/거버넌스/MDM 강화, 모델링 범위가 조직 레벨로 확장
  • 2010s: NoSQL/빅데이터/클라우드, 멀티 모델 전략 확산
  • 2020s~: AI/ML/LLM·벡터 스토어 포함, 플랫폼·AI 중심 모델링으로 확장

11. 역사를 알면 모델링이 더 잘 보이는 이유

데이터모델링의 역사는 결국 “요구가 바뀌면 모델도 바뀐다”는 사례들의 연속입니다.
역사를 알고 나면 실무에서 아래 인사이트를 얻기 쉽습니다.

  • 계층형·네트워크형 → 관계형
  • “왜 데이터 독립성과 선언적 질의(SQL)가 중요한지”가 역사적으로 이해됨
  • 관계형 + ER 모델
  • 개념·논리·물리 모델을 나누는 이유와 장점이 명확해짐
  • 차원 모델링
  • “트랜잭션 모델과 분석 모델은 목적이 다르다”는 감각이 생김
  • NoSQL·멀티 모델
  • “정규화 vs 반정규화”가 아니라 문제에 맞는 데이터 모델 선택이 핵심임을 이해
  • AI 시대
  • 피처/로그/레이크/벡터 스토어 같은 새로운 구성요소도
    결국 “데이터를 구조화해서 쓰기 위한 모델링의 연장선”으로 해석 가능

Tags: