테이블이 아니라 관계가,
데이터베이스의 본질입니다

이번 섹션의 여정

여기서부터가 진짜 메인입니다

이 강의를 만들면서 “이 섹션 하나가 강의의 값어치를 결정한다” 고 생각한 부분이 바로 여기입니다. 강의 소개의 메인 메시지도 여기서 나옵니다.

섹션 3까지와 무엇이 다른가

섹션 3까지 우리가 한 건 SQL 문법이었습니다. SELECT, WHERE, JOIN, GROUP BY — 도구함을 채운 거예요. 그런데 솔직히 — “AI가 이거 다 짜주는 시대잖아요?” 맞습니다. 그래서 진짜 실력은 다른 데서 갈립니다. AI가 SQL을 짜준다고 해도, “이 SQL이 의미가 맞는지” 는 사람이 판단해야 하고 — 그 판단의 근거가 데이터의 구조입니다.

데이터베이스의 본질 — “관계”

그럼 “데이터의 구조” 라는 게 뭘까요? 한 단어로 — 관계입니다. 우리 강의 데이터 shop DB를 봅시다. 회원·카테고리·상품·주문·주문상세, 5개 테이블. 그런데 이 5개가 따로 떨어져 있는 게 아니에요. 선으로 다 연결돼 있습니다.

• 회원 ↔ 주문 — “한 회원이 여러 주문을 한다”
• 주문 ↔ 주문상세 — “한 주문에 여러 상품이 담긴다”
• 카테고리 ↔ 상품 — “한 카테고리에 여러 상품이 속한다”

이 선이 진짜입니다. 테이블은 그냥 데이터 묶음일 뿐 — 선, 즉 관계가 데이터베이스의 본질이에요.

말로만 들으면 추상적이니, 선 하나를 데이터로 직접 확인해봅시다. ERD에서 members와 orders를 잇는 선 — 김철수 님 한 명을 따라가 보면:

USE shop;
 
SELECT
  m.member_name,
  o.order_id,
  o.ordered_at
FROM
  members m
JOIN orders o
  ON m.member_id = o.member_id
WHERE
  m.member_name = '김철수';

members 테이블에서 김철수는 딱 1행입니다. 그런데 orders에는 그를 가리키는 주문이 6건 — member_id라는 선으로 연결돼 있죠. 섹션 3에서 기계적으로 쓰던 JOIN의 ON 절이, 사실은 이 선을 따라가는 행위였던 겁니다.

왜 데이터를 쪼개놨을까

여기서 자주 받는 질문 — “왜 한 테이블에 다 넣지 않고, 여기저기 흩어놨어요?” 만약 한 덩어리 테이블이었다면 이런 모양이 됩니다.

AI 시대에 모델링이 더 중요한 이유

자 — 그럼 “왜 모델링이 AI 시대에 더 중요한가” 로 마무리하겠습니다. AI에게 SQL을 시킬 때, 우리가 줘야 할 건 딱 두 가지입니다.

1. 어떤 데이터가 있는지 — 테이블과 컬럼
2. 그 데이터가 어떻게 연결됐는지 — 관계, 곧 모델링

이 두 가지를 정확히 전달하면 AI는 SQL을 거의 안 틀립니다. 못 전달하면 — AI는 “아무거나” 짜줍니다. 그게 사고의 시작이에요.

어디서 본 장면이죠? 2-4에서 init.sql을 던져주자 AI 과외 선생님이 정확해졌던 이유가 바로 이겁니다. init.sql 안에 두 가지 — 테이블·컬럼, 그리고 관계 — 가 전부 들어있었으니까요. 섹션 4를 마치면 여러분이 그 구조를 직접 읽고, 직접 설명할 수 있게 됩니다.

섹션 4 로드맵 — 앞으로 8강

오늘 바뀐 건 코드가 아니라 보는 눈입니다. 연습 문제로 사고법 전환을 점검하고, 가장 중요한 4-2로 넘어갑시다.