데이터 모델링, 설계 안 하면 나중에 울게 되는 이유

 

"테이블 대충 만들어 놓고, 나중에 고치면 되지 않나요?"

 

개발 현장에서 이 말을 들어보신 적 있으신가요. 아니면 본인이 직접 이렇게 생각하신 적 있으신가요. 프로젝트 일정은 빠듯하고, 당장 기능을 만들어야 하는 상황에서 데이터 설계에 시간을 쏟는 건 사치처럼 느껴지기도 합니다.

 

그런데 경험이 쌓일수록 한 가지 사실을 깨닫게 됩니다. 데이터베이스 설계를 대충 넘긴 프로젝트는 반드시 나중에 대가를 치른다는 것입니다. 쿼리가 느려지고, 데이터가 꼬이고, 수정 한 번에 관련된 테이블을 줄줄이 고쳐야 하는 상황. 이 모든 것의 원인을 거슬러 올라가면 결국 처음의 데이터 모델링으로 돌아가게 됩니다.

 

오늘은 SQLD 1과목의 핵심 주제인 '데이터 모델링의 이해'를 다루면서, 왜 이 개념이 시험뿐 아니라 실무에서도 그토록 중요한지를 정리해 보겠습니다.

---

데이터 모델링이란 무엇인가

쉽게 말하면, 데이터 모델링은 현실 세계의 정보를 데이터베이스에 담기 위한 설계도를 그리는 작업입니다.

 

건축가가 집을 짓기 전에 청사진을 설계하는 것과 같은 방식으로, 데이터베이스를 만들기 전에 먼저 데이터 모델을 설계합니다. 회원 정보는 어떤 항목으로 구성할 것인지, 주문과 상품은 어떤 관계로 연결할 것인지, 결제 이력은 어떻게 쌓을 것인지를 미리 정의하는 과정입니다.

 

SQLD 시험에서는 데이터 모델링의 특징을 세 가지로 정리하고 있습니다.

 

추상화(현실 세계를 일정한 형식에 맞추어 표현),

단순화(복잡한 현실을 약속된 표기법으로 표현),

명확화(애매모호함을 제거하여 누구나 이해할 수 있게 표현)입니다.

 

이 세 가지는 시험에서도 자주 등장하니 기억해 두시기 바랍니다.

---

설계 없이 만들면 벌어지는 일들

이 부분을 제대로 하지 않으면 어떤 일이 벌어지는지, 실무에서 흔히 볼 수 있는 사례를 들어보겠습니다.

 

첫째, 데이터 중복이 발생합니다. 같은 고객 정보가 주문 테이블, 배송 테이블, 정산 테이블에 각각 들어가 있다면 어떻게 될까요. 고객이 전화번호를 바꾸면 세 군데를 전부 수정해야 합니다. 하나라도 놓치면 시스템마다 다른 전화번호가 표시되는, 이른바 '갱신 이상(Update Anomaly)'이 생깁니다.

 

둘째, 쿼리 성능이 나빠집니다. 테이블 구조가 엉망이면 단순한 조회에도 불필요한 JOIN이 늘어나고, 인덱스를 아무리 걸어도 근본적인 속도 개선이 어렵습니다. 성능 데이터 모델링은 프로젝트의 분석/설계 단계에서 수행되어야 추후 성능 개선 비용이 감소합니다. 프로젝트 후반에 성능 문제를 잡으려면 비용이 기하급수적으로 올라갑니다.

 

셋째, 확장이 불가능해집니다. 새로운 기능을 추가할 때마다 기존 테이블을 뜯어고쳐야 하는 상황이 반복됩니다. 처음에 유연성을 고려하지 않으면, 서비스가 커질수록 기술 부채가 눈덩이처럼 불어납니다.

 

더 흥미로운 건, 이 문제의 규모입니다. 시스템 간 인터페이스가 전체 시스템 비용의 25%에서 70%까지 차지할 수 있으며, 이 비용의 주된 이유가 바로 공통 데이터 모델을 공유하지 않기 때문이라는 분석도 있습니다.

---

데이터 모델링의 3단계, 이것만 기억하세요

SQLD 시험에서도 자주 출제되는 내용이지만, 실무에서도 이 흐름을 이해하고 있느냐 없느냐가 큰 차이를 만듭니다.

 

1단계: 개념적 모델링은 업무에서 관리해야 할 데이터의 큰 그림을 그리는 단계입니다. "우리 시스템에서 고객, 상품, 주문이라는 데이터가 존재한다"는 수준의 정의입니다. 추상화 수준이 가장 높고, 업무 중심적이며, 전사적(EA) 수립 시 사용됩니다. 기술적인 용어 없이도 기획자와 대화할 수 있는 수준의 모델이죠.

 

2단계: 논리적 모델링은 개념 모델을 좀 더 구체화해서, 각 엔터티의 속성과 관계를 정의하고, 정규화를 통해 데이터 중복을 제거하는 단계입니다. 여기서 Key, 속성, 관계 등을 정확하게 표현하며, 재사용성이 높은 것이 특징입니다. PK(기본키)와 FK(외래키)가 결정되고, 테이블 간의 참조 관계가 확정됩니다. 특정 DBMS에 종속되지 않는 단계라는 점도 중요합니다.

 

3단계: 물리적 모델링은 실제 사용할 DBMS(Oracle, MySQL, PostgreSQL 등)에 맞춰서 데이터 타입, 인덱스, 파티셔닝 전략 등을 결정하는 단계입니다. 성능, 저장 등 물리적인 성격을 고려하여 설계합니다. 같은 논리 모델이라도 Oracle에서 구현하느냐, MySQL에서 구현하느냐에 따라 물리적 설계가 달라질 수 있습니다.

 

이 3단계를 한마디로 정리하면, "무엇을 담을지 → 어떻게 구성할지 → 어디에 어떤 형태로 저장할지"의 과정입니다.

---

데이터 독립성, 왜 알아야 하나

3단계 구조를 이해했다면, 여기서 한 발 더 나아가 데이터 독립성이라는 개념도 짚어야 합니다. SQLD 시험에서 자주 등장하는 주제이기도 합니다.

 

ANSI/SPARC 3단계 데이터독립성 모델은 각 단계가 상호간의 영향에서 벗어나 고유의 기능을 제공하도록 하는 것입니다. 쉽게 말하면 아래와 같습니다.

• 외부 스키마: 개개 사용자가 보는 개인적 DB 스키마
• 개념 스키마: 모든 사용자 관점을 통합한 전체 DB 구조
• 내부 스키마: 물리적 장치에서 데이터가 실제로 저장되는 방식

여기서 두 가지 독립성이 나옵니다.

 

논리적 독립성은 개념 스키마가 변경되어도 외부 스키마에 영향을 미치지 않는 것이고,

물리적 독립성은 내부 스키마가 변경되어도 외부/개념 스키마에 영향을 주지 않는 것입니다.

 

실무적으로 풀어보면 이렇습니다. DB 서버를 SSD로 교체하거나 파티셔닝 전략을 바꿔도(내부 스키마 변경), 개발자가 쓰는 SQL이나 사용자 화면이 바뀌지 않아야 한다는 뜻입니다. 이런 독립성을 보장하는 것이 데이터 모델링의 근본적인 목적 중 하나입니다.

---

📝 SQLD 기출 유형 문제로 점검하기

이론만 읽으면 머리에 잘 안 남습니다. 실제 시험에서 어떤 형태로 나오는지, 기출 유형 문제 2개를 풀어보겠습니다.

---

Q1. 다음 중 데이터 모델링에 대한 설명으로 가장 부적절한 것은?

① 업무 정보를 일정한 표기법으로 표현하여 정보시스템 구축의 대상이 되는 업무 내용을 정확하게 분석하는 것이다
② 데이터 모델링은 추상화, 단순화, 명확화의 특징을 가진다
③ 물리적 데이터 모델링은 DBMS에 독립적이며, Key와 속성, 관계를 정확하게 표현하는 단계이다
④ 데이터 모델링의 유의점으로 중복성, 비유연성, 비일관성을 들 수 있다

 

정답 및 해설 보기

:

:

:

:

:

:

:

:

:

:

:

:

:

:

:

:

:

:

:

:

정답: ③ 물리적 데이터 모델링은 오히려 특정 DBMS에 맞춰서 성능, 저장 등 물리적인 성격을 고려하여 설계하는 단계입니다. "논리적"과 "물리적"을 뒤바꿔 놓는 것은 시험에서 단골로 등장하는 함정이니 주의하시기 바랍니다.

• ①: 데이터 모델링의 정의에 대한 올바른 설명입니다.
• ②: 추상화, 단순화, 명확화는 모델링의 세 가지 특징으로 정확합니다.
• ④: 중복성(같은 데이터가 여러 곳에 저장), 비유연성(작은 변화에 큰 영향), 비일관성(데이터 간 상호 관계 불일치)은 모델링 시 유의해야 할 점으로 올바른 설명입니다.

---

Q2. 다음 중 ANSI/SPARC 3단계 스키마 구조에서 데이터 독립성에 대한 설명으로 가장 적절한 것은?

① 외부 스키마가 변경되면 개념 스키마도 반드시 변경되어야 한다
② 논리적 독립성이란 내부 스키마가 변경되어도 외부 스키마에 영향을 미치지 않는 것이다
③ 물리적 독립성이란 내부 스키마가 변경되어도 외부/개념 스키마에 영향을 미치지 않는 것이다
④ 개념 스키마는 개개인의 사용자 관점에서 본 개인적 DB 스키마이다

 

정답 및 해설 보기

:

:

:

:

:

:

:

:

:

:

:

:

:

:

:

:

:

:

:

:

정답: ③ 예를 들어, 디스크 교체나 인덱스 재구성 같은 물리적 변경이 응용 프로그램이나 전체 논리 구조에 영향을 미치지 않아야 합니다.

• ①: 외부 스키마는 개별 사용자의 뷰(View)이므로, 외부 스키마가 변경되더라도 개념 스키마가 반드시 변경될 필요는 없습니다.
• ②: 이것은 "물리적 독립성"의 설명입니다. 논리적 독립성은 개념 스키마가 변경되어도 외부 스키마에 영향을 미치지 않는 것입니다. "논리적"과 "물리적"을 뒤바꿔 놓는 함정입니다.
• ④: 개개인의 사용자 관점에서 본 DB 스키마는 외부 스키마입니다. 개념 스키마는 모든 사용자 관점을 통합한 전체 DB 구조를 말합니다.

---

SQLD 시험에서는 어떻게 나올까

SQLD 1과목 '데이터 모델링의 이해'는 10문제, 문항당 2점으로 총 20점이 배점되며, 8점 미만이면 과락입니다. 문항 수가 적다 보니 가볍게 보시는 분들이 많은데, 과락 기준인 4문제를 틀리면 2과목을 아무리 잘 봐도 불합격이니 주의하셔야 합니다.

 

주로 출제되는 개념은 이렇습니다. 데이터 모델링의 3단계 구분, 3단계 스키마와 데이터 독립성, 엔터티의 종류와 특징, 속성의 분류(기본/설계/파생), 관계의 종류, 식별자의 유형, 정규화와 반정규화 개념, 그리고 ERD 표기법 해석입니다.

 

특히 ERD를 읽고 해석하는 문제는 2과목에서도 등장하기 때문에, 1과목을 공부하면서 ERD 읽는 연습을 충분히 해두면 2과목에서도 도움이 됩니다.

---

집을 지을 때 설계도가 필요한 이유

여기서 한 가지 비유를 들어보겠습니다. 건축과 데이터베이스는 놀랍도록 비슷한 구조를 가지고 있습니다.

 

개념적 모델링은 "3층짜리 상가 건물을 짓겠다"라는 큰 계획에 해당합니다. 논리적 모델링은 각 층의 구조, 방의 배치, 배관과 전기 설계도에 해당합니다. 물리적 모델링은 실제로 어떤 자재를 쓸지, 어떤 공법으로 시공할지를 결정하는 것에 해당합니다.

 

설계도 없이 건물을 짓는 사람은 없습니다. 그런데 데이터베이스는 왜 설계 없이 바로 CREATE TABLE부터 치는 걸까요. 빠른 개발이 필요해서, 당장 결과물을 보여줘야 해서, 모델링이 번거롭게 느껴져서. 이유는 다양하지만 결과는 같습니다. 나중에 훨씬 더 큰 비용을 치르게 됩니다.

---

실무에서 데이터 모델링이 빛나는 순간

개발팀과 기획팀이 처음 프로젝트를 시작할 때, ERD 하나를 놓고 대화하면 커뮤니케이션 비용이 눈에 띄게 줄어듭니다. 데이터 모델은 비즈니스 요구 사항을 중심으로 구축되며, 이해관계자의 피드백을 통해 규칙과 요구 사항이 미리 정의되기 때문입니다.

 

또한 서비스가 성장하면서 기능이 추가될 때, 잘 설계된 데이터 모델이 있으면 기존 구조를 크게 건드리지 않고도 확장이 가능합니다. 효율적으로 설계된 기본 데이터 모델은 조직 내 다른 시스템의 목적에 맞게 최소한의 수정만으로 재작업을 줄일 수 있습니다.

 

데이터 모델링 개념이 아직 낯설거나, ERD를 직접 그려보면서 연습하고 싶으신 분이라면 온라인 학습 플랫폼에서 제공하는 SQLD 대비 과정 중 모델링 파트를 집중적으로 다루는 강의도 있더라고요. 기출문제 해설까지 포함된 과정은 혼자 교재만 보는 것보다 이해가 빠를 수 있습니다.

---

데이터 모델링에서 가장 중요한 세 가지 원칙

SQLD 교재에서도 강조하고, 실무에서도 반복해서 확인하게 되는 핵심 원칙은 세 가지입니다.

 

중복성 배제: 같은 데이터베이스 내의 데이터 혹은 속성이 중복으로 저장되는 것을 지양해야 합니다. 하나의 사실은 한 곳에만 저장되어야 합니다. 이것이 정규화의 출발점이기도 합니다.

 

유연성 확보: 현재 요구사항뿐 아니라 향후 변경 가능성까지 고려해서 설계해야 합니다. 데이터의 정의를 데이터의 사용 프로세스와 분리함으로써, 작은 변화가 전체 시스템에 중대한 영향을 미치는 상황을 방지합니다.

 

일관성 유지: 데이터 간 관계를 명확히 정의하여, 연관된 정보를 무시하고 데이터가 갱신되는 경우를 피해야 합니다. 주문이 취소되면 재고도 자동으로 복원되어야 하는 것처럼, 데이터 간의 규칙이 일관되게 유지되어야 합니다.

---

시험 공부 팁: 1과목은 이렇게 접근하세요

SQLD 1과목 모델링 파트를 공부할 때 가장 흔한 실수는, 용어 정의만 외우려는 것입니다. "엔터티란 무엇이다, 속성이란 무엇이다" 식의 암기만으로는 응용 문제에서 틀립니다.

 

추천하는 방법은 실제 ERD를 보면서 "이 엔터티는 왜 이렇게 나눴을까", "이 관계는 1:N인가 M:N인가"를 스스로 판단하는 연습을 하는 것입니다. 한국데이터산업진흥원에서 발간한 'SQL 자격검정 실전문제'(노랭이 책)에 모델링 관련 문제가 포함되어 있으니, 이것을 반복해서 풀어보시면 됩니다.

 

그리고 모델링 용어 중 시험에 자주 나오는 것들을 짧게 정리하면 이렇습니다.

• 엔터티: 관리하고자 하는 데이터의 집합
• 속성: 엔터티를 구성하는 더 이상 쪼갤 수 없는 최소 정보 항목
• 관계: 엔터티 간의 연결
• 식별자: 각 인스턴스를 구별하는 속성 (유일성, 최소성, 불변성, 존재성)
• 도메인: 속성이 가질 수 있는 값의 범위, 데이터 타입, 크기, 제약사항

---

모델링을 모르면 SQL도 불완전하다

데이터 모델링은 2과목 SQL을 제대로 이해하기 위한 토대이기도 합니다. JOIN을 쓰려면 테이블 간의 관계를 알아야 하고, 서브쿼리를 최적화하려면 데이터 구조를 이해해야 합니다. 정규화가 왜 필요한지 모르면, 반정규화를 언제 해야 하는지도 판단할 수 없습니다.

결국 데이터 모델링은 SQL의 출발점이자 기초 체력입니다. SQLD 시험에서도 1과목이 먼저 나오는 이유가 여기에 있습니다.

---

정리하면

데이터 모델링은 "나중에 해도 되는 것"이 아니라 "처음에 해야만 하는 것"입니다. 설계를 건너뛰고 만든 데이터베이스는 기능이 추가될수록 비용이 기하급수적으로 늘어나고, 결국 전체를 다시 설계하는 상황까지 갈 수 있습니다.

 

SQLD 시험을 준비하시는 분이라면, 1과목 모델링을 단순한 '가벼운 과목'이 아니라 SQL 전체를 관통하는 기반 지식으로 접근하시기 바랍니다. 이 개념을 제대로 이해하고 나면 2과목의 SQL 문제를 풀 때도 훨씬 수월해지실 겁니다.

 

시험 접수와 일정은 한국데이터산업진흥원 데이터자격검정 홈페이지(dataq.or.kr)에서 확인하실 수 있습니다. 오늘부터 ERD 하나 그려보는 것으로 시작해 보세요.

---

 

---

썸네일 이미지 생성 프롬프트:

"A clean, modern flat illustration of a blueprint-style database schema diagram with connected entity boxes and relationship lines, a magnifying glass hovering over the diagram revealing hidden errors and cracks, soft blue and orange color palette, minimal corporate style, Korean text '설계 안 하면 나중에 울게 되는 이유' at the top, 16:9 aspect ratio, professional blog thumbnail style"