김영한 데이터베이스 설계 1편: ERD·정규화·MySQL 설계까지

많은 개발자가 데이터베이스 설계를 처음 배울 때 컬럼 타입, PK, FK, 인덱스부터 떠올립니다. 물론 중요합니다. 하지만 실무에서 더 먼저 필요한 것은 요구사항을 해석하는 능력입니다.

예를 들어 쇼핑몰을 만든다고 할 때, 상품, 주문, 회원, 결제, 배송, 옵션, 장바구니를 각각 어떤 엔티티로 볼 것인지, 어떤 관계로 연결할 것인지, 어떤 데이터는 중복을 허용하고 어떤 데이터는 분리할 것인지 판단해야 합니다.

이 강의의 강점은 바로 이 지점에 있습니다. 결과 ERD만 보여주는 방식이 아니라, 왜 그런 선택을 했는지 고민의 과정을 따라갑니다. 그래서 ‘정답 ERD 암기’가 아니라 ‘설계 판단 기준’을 가져가는 쪽에 가깝습니다.

수강을 고민한다면 여기서 먼저 판단해보면 좋습니다.

• •SQL은 어느 정도 알지만 테이블 설계가 막막하다
• •ERD를 그려도 관계와 카디널리티 판단이 흔들린다
• •정규화를 배웠지만 실제 프로젝트에 적용하는 기준이 애매하다
• •백엔드 개발자로 장기적인 DB 기본기를 만들고 싶다

이 중 2개 이상 해당된다면 김영한 실전 데이터베이스 설계 1편 수강하기를 검토할 만합니다.

데이터베이스 설계를 공부하다 보면 개념적 모델링, 논리적 모델링, 물리적 모델링이라는 말을 자주 듣습니다. 문제는 각각의 정의만 외우면 실제 프로젝트에서 손이 멈춘다는 점입니다.

이 강의는 세 단계를 분리된 이론이 아니라 하나의 흐름으로 보여줍니다.

이 구조가 좋은 이유는 명확합니다. 실무에서 DB 설계는 ‘요구사항 → ERD → 테이블’로 내려갑니다. 이 순서가 몸에 잡혀야 나중에 도메인이 바뀌어도 흔들리지 않습니다.

추상적인 예제만으로는 DB 설계를 오래 기억하기 어렵습니다. 이 강의는 쇼핑몰 프로젝트를 중심으로 요구사항 분석, 핵심 요소 식별, 엔티티 도출, 관계 설정, ERD 완성 흐름을 다룹니다.

쇼핑몰은 데이터 모델링을 배우기에 좋은 도메인입니다. 회원, 상품, 주문, 주문상품, 결제, 배송처럼 익숙한 개념이 많으면서도 실제로 설계하려고 하면 관계가 꽤 복잡해지기 때문입니다.

특히 다음과 같은 질문을 프로젝트 맥락에서 다루게 됩니다.

• •주문과 상품은 왜 직접 다대다로 연결하면 안 될까?
• •연관 엔티티는 언제 필요한가?
• •회원 정보와 주문 당시 배송 정보는 어떻게 다뤄야 할까?
• •비즈니스 요구사항이 바뀌면 ERD는 어떻게 영향을 받을까?
• •논리 모델과 물리 테이블은 어떤 차이를 가져야 할까?

단순히 “이렇게 설계하세요”가 아니라, 설계 선택의 이유를 함께 보는 방식이라 이후 본인 프로젝트에 적용하기 쉽습니다.

데이터베이스 설계에서 ERD는 예쁘게 그리는 다이어그램이 아닙니다. 팀원이 같은 구조를 이해하고, 개발자가 일관된 테이블을 만들고, 운영 중 데이터 무결성을 지키기 위한 설계 언어입니다.

강의에서는 논리적 모델링의 핵심 개념을 단계적으로 다룹니다.

• •기본 키와 외래 키
• •일대다 관계
• •일대일 관계
• •다대다 관계와 해소 방식
• •식별 관계와 비식별 관계
• •카디널리티와 참여도
• •정규화와 데이터 무결성

정규화도 시험용 정의에 머물지 않습니다. 중복을 줄이고 무결성을 높이는 이론적 이유와 함께, 실제 설계에서 어디까지 적용할지 생각할 수 있게 만듭니다.

SQLD를 준비했거나 DBMS/RDBMS 개념을 배운 적이 있어도 실무 설계가 어려웠다면, 이 강의는 지식 조각을 하나의 판단 체계로 묶어주는 역할을 합니다.

좋은 논리 모델도 실제 DBMS에 맞게 구현되지 않으면 운영 가능한 설계가 되기 어렵습니다. 이 강의는 물리적 모델링 단계에서 MySQL 설계 관점까지 연결합니다.

여기서 중요한 것은 ‘이론적으로 완벽한 모델’과 ‘실제로 서비스에서 쓸 수 있는 모델’ 사이의 균형입니다. 데이터 무결성을 지키면서도 성능과 구현 가능성을 고려해야 합니다.

수강 후 기대할 수 있는 산출물은 다음과 같습니다.

1. 01요구사항에서 핵심 엔티티를 추출하는 기준
2. 02엔티티 간 관계를 ERD로 표현하는 방식
3. 03다대다 관계를 연관 엔티티로 해소하는 감각
4. 04정규화를 통해 중복과 이상 현상을 줄이는 방법
5. 05MySQL 기준으로 물리 테이블을 구성하는 흐름
6. 06설계 결정의 이유를 설명하는 언어

즉, 강의를 끝냈을 때 남는 것은 단순한 강의 필기가 아니라 ‘내 프로젝트의 DB 구조를 설명할 수 있는 능력’입니다.

강의를 선택할 때는 커리큘럼의 깊이와 학습 지속 가능성을 함께 봐야 합니다. 이 강의는 짧은 맛보기형 콘텐츠라기보다, DB 설계를 체계적으로 다시 잡는 데 맞춰진 장기 기본기 강의에 가깝습니다.

초급 강의로 분류되어 있지만, 내용의 방향은 가볍지 않습니다. SQL 입문만 하고 끝내는 강의가 아니라 백엔드 데이터베이스 설계의 기본기를 오래 가져가기 위한 구성입니다.

강의 상세와 커리큘럼을 확인하려면 김영한 실전 데이터베이스 설계 1편 보기에서 확인할 수 있습니다.

모든 강의가 모든 사람에게 맞지는 않습니다. 이 강의는 ‘데이터베이스를 처음 듣는 완전 입문자’보다, SQL과 백엔드 개발을 어느 정도 접했지만 설계 판단이 부족하다고 느끼는 사람에게 더 잘 맞습니다.

추천 대상은 다음과 같습니다.

• •데이터베이스 설계를 체계적으로 다시 잡고 싶은 백엔드 개발자
• •ERD 설계, 논리적 모델링, 물리적 모델링을 실무 흐름으로 배우고 싶은 주니어 개발자
• •쇼핑몰 데이터베이스 예제로 데이터 모델링 감각을 쌓고 싶은 학습자
• •SQL과 MySQL은 알지만 테이블 설계 기준이 막막한 개발자
• •정규화와 데이터 무결성을 프로젝트 관점에서 이해하고 싶은 사람
• •면접이나 실무에서 DB 설계 설명력을 높이고 싶은 사람

반대로, 단순히 SQL 문법만 빠르게 배우고 싶거나 특정 ORM 사용법만 찾고 있다면 우선순위가 다를 수 있습니다. 이 강의의 중심은 SQL 실행이 아니라 설계입니다.

이 강의를 수강한 뒤 가장 크게 달라지는 지점은 ‘DB 설계를 시작하는 방식’입니다. 막연히 테이블부터 만들기보다 요구사항을 읽고, 핵심 엔티티를 찾고, 관계를 정리한 뒤, 논리 모델을 물리 모델로 내려가는 순서를 갖게 됩니다.

수강 후 손에 남는 것은 다음과 같이 정리할 수 있습니다.

• •요구사항을 데이터 관점으로 해석하는 습관
• •ERD를 통해 구조를 설명하는 능력
• •키와 관계를 기준으로 테이블을 나누는 판단력
• •정규화와 무결성을 고려한 설계 기준
• •MySQL 구현을 염두에 둔 물리 모델링 감각
• •“왜 이렇게 설계했는가”를 말할 수 있는 백엔드 기본기

데이터베이스 설계는 한 번 제대로 잡아두면 이후 모든 백엔드 프로젝트에 누적됩니다. 지금 테이블 설계가 자주 막힌다면, 이번 강의는 단순한 지식 구매가 아니라 앞으로의 설계 속도를 높이는 기반 투자가 될 수 있습니다.

커리큘럼과 수강 조건을 확인하고 싶다면 김영한의 실전 데이터베이스 설계 1편 수강하기에서 이어서 살펴보세요.