Day 2 — 데이터 설계의 시작: 무엇을, 어떻게 저장할까
오늘의 목표
- 내 명세서를 "저장할 데이터"로 번역한다
- 표(테이블)와 관계라는 개념을 이해한다
- 내 프로젝트의 DB 설계도(ERD) 초안을 그려서 나간다
오늘 끝나면 여러분 손에 본인 프로젝트의 데이터 설계 초안이 들려 있어야 합니다.
준비물: Day 1에 만든 프로젝트 명세서 v0.1
0. 복습 — 지난 시간 우리는
지난 시간에 명세서 한 장을 만들었습니다. 한 줄 소개, 타겟 사용자, 핵심 기능 3개. 오늘은 그 기능들을 데이터로 바꾸는 작업을 합니다.
왜 이걸 먼저 할까요? 집을 지을 때 가구부터 사지 않고 방 구조를 먼저 정하는 것과 같습니다. 데이터 구조가 흔들리면 나중에 기능 전체를 다시 짜야 합니다. 그래서 코딩보다 먼저 합니다.
1. "기능"을 "데이터"로 번역하기
핵심 질문 하나로 시작합니다.
"이 서비스가 동작하려면, 무엇을 기억하고 있어야 하지?"
예를 들어 할 일 관리 앱이라면:
- 로그인이 되려면 → 사용자를 기억해야 함 (이메일, 비밀번호)
- 할 일을 보여주려면 → 할 일을 기억해야 함 (내용, 완료 여부, 마감일)
- "내" 할 일만 보여주려면 → 각 할 일이 누구 것인지 기억해야 함
이렇게 "기억해야 하는 것들"이 곧 데이터입니다. 보통 명사로 떨어집니다 — 사용자, 할 일, 댓글, 주문, 게시글...
✍️ 같이 해보기
여러분 명세서의 핵심 기능 3개를 보면서, "기억해야 할 명사"를 뽑아보세요.
내 서비스가 기억해야 할 것들:
1.
2.
3. (보통 2~4개면 충분합니다)
2. 테이블 — 데이터를 담는 표
데이터는 표(테이블) 에 저장합니다. 엑셀 시트를 떠올리면 정확합니다.
- 표 하나 = 명사 하나 (사용자 표, 할 일 표)
- 세로 칸(열/컬럼) = 그 명사의 속성 (이름, 이메일...)
- 가로 줄(행/로우) = 실제 데이터 하나 (사용자 1명)
예시: 사용자(users) 테이블
| id | password | created_at | |
|---|---|---|---|
| 1 | kim@test.com | (암호화된 값) | 2026-01-10 |
| 2 | lee@test.com | (암호화된 값) | 2026-01-11 |
예시: 할 일(todos) 테이블
| id | title | is_done | due_date | user_id |
|---|---|---|---|---|
| 1 | 장보기 | false | 2026-01-15 | 1 |
| 2 | 운동하기 | true | 2026-01-12 | 1 |
| 3 | 책 읽기 | false | 2026-01-20 | 2 |
💡 id 가 뭐예요? 각 줄을 구별하는 고유 번호입니다. 이름이 같은 사람이 있어도 id로 구분합니다. 거의 모든 테이블에 들어가는 필수 칸이라고 생각하세요. (전문 용어로 기본키 / Primary Key)
3. 자료형 — 칸마다 들어갈 데이터의 "종류"
각 칸에는 어떤 종류의 값이 들어갈지 미리 정해줘야 합니다. 자주 쓰는 것만 추리면:
| 자료형 | 용도 | 예시 |
|---|---|---|
INTEGER | 정수 | id, 나이, 개수 |
VARCHAR / TEXT | 글자 | 이름, 이메일, 제목, 내용 |
BOOLEAN | 참/거짓 | 완료 여부, 공개 여부 |
DATE / TIMESTAMP | 날짜·시간 | 마감일, 가입일 |
DECIMAL | 소수 (돈 등) | 가격, 평점 |
⚠️ 돈은 절대 소수(float)로 대충 저장하면 안 됩니다.
DECIMAL을 쓰세요. (나중에 1원씩 안 맞는 지옥을 겪지 않으려면...)
4. 관계 — 테이블끼리 연결하기
여기가 오늘의 핵심입니다.
위 할 일 테이블에 user_id 라는 칸이 있었죠? 이게 바로 "이 할 일은 누구 것" 인지를 가리키는 연결고리입니다.
할 일 테이블의
user_id(1) = 사용자 테이블의id(1) → "장보기는 kim@test.com의 할 일이다"
이렇게 한 테이블이 다른 테이블의 id를 들고 있어서 연결되는 것을 관계라고 하고, 그 연결용 칸을 외래키(Foreign Key) 라고 합니다.
관계의 3가지 유형
대부분 이 세 가지로 설명됩니다.
| 유형 | 뜻 | 예시 |
|---|---|---|
| 1 : N (일대다) | 하나가 여러 개를 가짐 | 사용자 1명 → 할 일 여러 개 |
| N : N (다대다) | 서로 여러 개씩 | 학생 ↔ 수강과목 (학생도 여러 과목, 과목도 여러 학생) |
| 1 : 1 (일대일) | 하나에 하나 | 사용자 ↔ 프로필 상세 |
💡 가장 흔한 건 1 : N 입니다. "한 명의 사용자가 여러 개의 ○○을 가진다" — 이 문장이 되면 1:N입니다. 여러분 프로젝트도 십중팔구 여기 해당합니다.
N:N은 어떻게 저장하죠?
다대다는 직접 연결이 안 돼서, 중간에 연결 전용 테이블을 하나 둡니다. 예를 들어 게시글에 태그를 다는 경우(글도 여러 태그, 태그도 여러 글):
posts 테이블 post_tags 테이블 (연결용) tags 테이블
id post_id / tag_id id
title 1 1 name
1 2
2 1
지금 단계에서 N:N이 나온다면, "혹시 1:N으로 단순화할 수 있나?"를 먼저 고민해보세요. 초보 프로젝트는 단순할수록 완성됩니다.
5. ERD — 데이터 설계도 그리기
테이블과 관계를 그림으로 그린 것이 ERD(Entity Relationship Diagram) 입니다. 설계도라고 생각하면 됩니다.
거창한 도구 필요 없습니다. 종이에 그려도 되고, 아래처럼 글로 적어도 충분합니다.
글로 쓰는 ERD 예시 (할 일 앱)
[users]
id (PK, 정수, 자동증가)
email (글자, 중복불가)
password (글자, 암호화)
created_at (날짜시간)
[todos]
id (PK, 정수, 자동증가)
title (글자)
is_done (참/거짓, 기본값 false)
due_date (날짜, 비어도 됨)
user_id (FK → users.id) ← 연결고리!
created_at (날짜시간)
관계: users 1 : N todos
(한 사용자가 여러 할 일을 가진다)
🛠 그림 도구 추천 (선택): dbdiagram.io — 글로 쓰면 자동으로 그림 그려줌 / draw.io / 또는 그냥 종이와 펜. 도구보다 관계를 제대로 잡는 것이 100배 중요합니다.
6. 실습 — 내 프로젝트 ERD 초안 그리기
이제 직접 합니다. 아래 템플릿을 채우세요.
🛠 실습 템플릿
# 내 프로젝트 데이터 설계 v0.1
## 1단계: 기억해야 할 명사 뽑기
-
-
-
## 2단계: 각 테이블의 칸 채우기
[테이블명: ____________]
id (PK)
____________ (자료형 / 설명)
____________ (자료형 / 설명)
created_at (날짜시간)
[테이블명: ____________]
id (PK)
____________ (자료형 / 설명)
____________ (자료형 / 설명)
____________ (FK → ______.id) ← 연결되는 경우
## 3단계: 관계 정리
- ______ 1 : N ______ (설명: )
## 4단계: 셀프 점검
- [ ] 모든 테이블에 id가 있는가?
- [ ] "누구 것인지" 알아야 하는 데이터에 user_id 같은 FK가 있는가?
- [ ] 돈/날짜의 자료형이 올바른가?
✍️ 막힐 때 보세요
테이블을 몇 개나 만들어야 하죠? → 첫 프로젝트는 2~4개면 충분합니다. 너무 많으면 오히려 못 끝냅니다.
이 정보, 새 테이블로 빼야 하나 그냥 칸으로 둬야 하나? → 그 정보가 "여러 개" 생길 수 있으면 테이블로 빼세요. 사용자의 전화번호는 보통 1개 → 칸. 사용자의 주문은 여러 개 → 테이블.
나중에 바꿔도 되나요? → 됩니다. 우리는 애자일이니까요. 지금은 완벽이 아니라 시작이 목표입니다. 다만 큰 뼈대(테이블과 관계)는 신중히 잡으세요. 칸 추가는 쉽지만 관계 변경은 아픕니다.
7. 오늘의 체크리스트
- "기능 → 기억할 명사 → 테이블"의 흐름을 이해했다
- 테이블 = 표, id의 역할을 안다
- 자료형(글자/정수/참거짓/날짜)을 구분할 수 있다
- 외래키(FK)로 테이블이 연결되는 원리를 이해했다
- 내 프로젝트 ERD 초안을 작성했다 ← 가장 중요!
- 테이블 간 관계(주로 1:N)를 한 문장으로 설명할 수 있다
8. 다음 시간 예고
Day 3 — API 설계: 화면과 서버는 어떻게 대화하나
- 오늘 만든 테이블을 기준으로, "데이터를 주고받는 통로(API)"를 설계합니다
- REST API 설계 원칙 / 엔드포인트 정하기
- 준비물: 오늘 만든 ERD 초안
📌 숙제: ERD를 dbdiagram.io에 옮겨 그려오면 좋습니다(선택). 안 되면 종이 사진도 OK. 핵심은 관계가 맞는지 다시 점검하는 것.
데이터 구조는 프로젝트의 뼈대입니다. 오늘 잡은 뼈대 위에 앞으로 모든 기능이 올라갑니다. 🦴