관계형 데이터베이스 기초

​

왜 관계형 데이터베이스를 알아야 하나요?

​

관계형 데이터베이스(RDBMS)란?

💡 RDBMS(Relational Database Management System, 관계형 데이터베이스 관리 시스템) 란 데이터를 테이블(표) 형태로 저장하고, 테이블 간의 관계(Relationship) 를 통해 데이터를 연결하는 데이터베이스 시스템입니다.

​

핵심 개념

​

테이블 (Table)

​

키 (Key)

💡 기본 키(Primary Key, PK) 는 테이블에서 각 행을 고유하게 식별 하는 컬럼입니다. 중복될 수 없고, NULL이 될 수 없습니다. 실무에서 가장 흔한 실수는 “이름”이나 “이메일”을 기본 키로 쓰는 것입니다. 동명이인이 있을 수 있고, 이메일은 변경될 수 있으므로 반드시 의미 없는 순번(Surrogate Key) 을 사용하세요.

💡 외래 키(Foreign Key, FK) 는 다른 테이블의 기본 키를 참조 하여 두 테이블을 연결하는 컬럼입니다. 위 예시에서 주문 테이블의 customer_id는 고객 테이블의 customer_id를 참조합니다. 이를 통해 “주문 101은 김철수(customer_id=1)의 주문이다”라는 관계가 형성됩니다. 존재하지 않는 customer_id(예: 999)를 넣으려고 하면 RDBMS가 거부합니다 — 이것이 참조 무결성(Referential Integrity) 입니다.

​

조인 (JOIN)

💡 조인(JOIN) 은 두 개 이상의 테이블을 공통 컬럼을 기준으로 합치는 연산입니다. 관계형 데이터베이스의 핵심 기능이며, 이것이 “관계형”이라는 이름의 이유입니다.

-- 고객 이름과 주문 정보를 함께 조회
SELECT
    c.name AS 고객명,
    o.product AS 상품,
    o.amount AS 금액,
    o.order_date AS 주문일
FROM customers c
INNER JOIN orders o ON c.customer_id = o.customer_id;

​

주요 JOIN 유형

⚠️ 현업에서 가장 흔한 JOIN 실수: CROSS JOIN을 의도치 않게 만드는 것입니다. JOIN 조건을 빼먹으면 100만 × 100만 = 1조 건 의 결과가 나옵니다. 쿼리가 영원히 안 끝나고, 서버 메모리가 터지는 장애의 원인 1위입니다. JOIN에는 반드시 ON 조건을 명시하세요.

​

SQL 기본 구문

💡 SQL(Structured Query Language) 은 관계형 데이터베이스에서 데이터를 조회, 삽입, 수정, 삭제하기 위한 표준 언어입니다. 1970년대 IBM에서 개발되었으며, 현재 거의 모든 데이터 플랫폼(Databricks 포함)에서 사용됩니다. SQL을 한 번 배우면 MySQL, PostgreSQL, Databricks, Snowflake 어디서든 95%는 그대로 쓸 수 있습니다.

​

데이터 조회 (SELECT)

-- 기본 조회
SELECT name, city FROM customers;

-- 조건 필터링
SELECT * FROM orders WHERE amount > 100000;

-- 집계 함수 — 실무에서 가장 많이 쓰는 패턴
SELECT
    city,
    COUNT(*) AS 고객수,
    SUM(amount) AS 총매출,
    AVG(amount) AS 평균주문금액,
    MAX(amount) AS 최대주문금액
FROM customers c
JOIN orders o ON c.customer_id = o.customer_id
GROUP BY city
HAVING COUNT(*) >= 2
ORDER BY 총매출 DESC;

​

SELECT 구문 실행 순서

​

데이터 조작 (DML)

-- 삽입 (INSERT)
INSERT INTO customers (customer_id, name, email, city)
VALUES (4, '최지은', 'je@mail.com', '인천');

-- 수정 (UPDATE) — 반드시 WHERE를 확인하세요!
UPDATE customers SET city = '서울' WHERE customer_id = 3;
-- ⚠️ WHERE 없이 UPDATE하면 전체 행이 변경됩니다. 실무에서 이 실수로 장애가 정말 많이 납니다.

-- 삭제 (DELETE) — UPDATE보다 더 위험합니다
DELETE FROM orders WHERE order_date < '2024-01-01';
-- ⚠️ 프로덕션에서는 DELETE 대신 soft delete(is_deleted 플래그)를 권장합니다

⚠️ 현업 필수 습관: UPDATE나 DELETE를 실행하기 전에, 반드시 같은 WHERE 조건으로 SELECT를 먼저 실행 하여 영향받는 행의 수를 확인하세요. “1건만 바꾸려고 했는데 10만 건이 바뀌었습니다”는 실제로 매우 흔한 사고입니다.

​

데이터 정의 (DDL)

-- 테이블 생성 (CREATE)
CREATE TABLE products (
    product_id INT PRIMARY KEY,
    name VARCHAR(100) NOT NULL,
    category VARCHAR(50),
    price DECIMAL(10, 2),
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

-- 테이블 구조 변경 (ALTER)
ALTER TABLE products ADD COLUMN stock INT DEFAULT 0;

-- 테이블 삭제 (DROP) — 되돌릴 수 없습니다!
DROP TABLE products;

💡 DML과 DDL의 차이: DML(Data Manipulation Language) 은 데이터 자체를 다루는 명령어(SELECT, INSERT, UPDATE, DELETE)이고, DDL(Data Definition Language) 은 테이블의 구조(스키마)를 정의하는 명령어(CREATE, ALTER, DROP)입니다. DDL은 대부분의 RDBMS에서 자동 COMMIT되므로, ROLLBACK이 불가능합니다. DROP TABLE을 하면 끝입니다.

​

ACID 트랜잭션 — 데이터 안전의 핵심

​

실생활 예시: 은행 이체에서 실제로 벌어지는 일

BEGIN TRANSACTION;

-- 1. A 계좌에서 100만 원 차감
UPDATE accounts SET balance = balance - 1000000 WHERE account_id = 'A';

-- 2. B 계좌에 100만 원 입금
UPDATE accounts SET balance = balance + 1000000 WHERE account_id = 'B';

-- 두 작업 모두 성공하면 확정
COMMIT;

​

격리 수준(Isolation Level)과 실제 발생하는 문제

• Dirty Read (더티 리드): A가 계좌 잔액을 100만 원에서 0원으로 UPDATE했지만 아직 COMMIT 안 한 상태에서, B가 잔액을 조회하면 0원이 보입니다. A가 ROLLBACK하면 실제 잔액은 100만 원인데, B는 0원이라고 잘못된 정보를 본 것입니다. 대부분의 운영 DB는 READ COMMITTED 이상을 사용하므로 이 문제는 드뭅니다.
• Phantom Read (팬텀 리드): “VIP 고객 수를 세는 쿼리”를 같은 트랜잭션에서 두 번 실행했는데, 첫 번째는 100명, 두 번째는 101명이 나옵니다. 그 사이에 다른 트랜잭션이 VIP 고객을 한 명 추가했기 때문입니다. 리포트 정합성이 중요한 경우 문제가 됩니다.

💡 실무 팁: 대부분의 웹 애플리케이션은 READ COMMITTED 로 충분합니다. 금융 시스템에서도 SERIALIZABLE까지 가는 경우는 드물고, 보통 REPEATABLE READ + 낙관적 잠금(Optimistic Locking) 조합을 사용합니다.

​

Deadlock — 실제로 발생하는 패턴

-- 트랜잭션 A                    -- 트랜잭션 B
UPDATE accounts                  UPDATE accounts
SET balance = balance - 100      SET balance = balance - 200
WHERE id = 1;  -- A가 id=1 잠금   WHERE id = 2;  -- B가 id=2 잠금

UPDATE accounts                  UPDATE accounts
SET balance = balance + 100      SET balance = balance + 200
WHERE id = 2;  -- id=2 대기 🔒    WHERE id = 1;  -- id=1 대기 🔒
-- A는 B가 id=2를 놓기를 기다림   -- B는 A가 id=1을 놓기를 기다림
-- → 영원히 대기 = DEADLOCK!

1. 같은 순서로 접근: 항상 id가 작은 것부터 UPDATE하면 데드락이 원천 차단됩니다
2. 트랜잭션을 짧게: 잠금을 오래 들고 있을수록 데드락 확률이 올라갑니다
3. RDBMS의 데드락 감지: MySQL, PostgreSQL 등은 자동으로 데드락을 감지하고, 한쪽 트랜잭션을 강제 ROLLBACK합니다. 애플리케이션에서는 이때 재시도 로직을 구현해야 합니다

​

인덱스 (Index) — 성능의 핵심

💡 인덱스(Index) 란 테이블에서 특정 데이터를 빠르게 찾기 위한 색인 입니다. 책 뒤의 “찾아보기” 페이지와 동일한 원리입니다.

​

B-Tree 인덱스가 실제로 동작하는 방식

데이터 100만 건에서 1건을 찾을 때:

인덱스 없음 (Full Table Scan):
→ 최악의 경우 100만 번 비교
→ 디스크 I/O: 수천 회
→ 소요 시간: 수 초 ~ 수십 초

B-Tree 인덱스 있음:
→ log₂(1,000,000) ≈ 20번 비교
→ 디스크 I/O: 3~4회 (트리 깊이만큼)
→ 소요 시간: 수 밀리초

​

B-Tree vs Hash 인덱스

💡 실무에서는 거의 항상 B-Tree를 씁니다. Hash 인덱스는 “정확히 일치하는 값을 찾는 것만 필요하고, 범위 검색은 절대 안 하는” 경우에만 유리합니다. 확신이 없으면 B-Tree를 쓰세요.

​

Composite Index (복합 인덱스) — 순서가 매우 중요합니다

-- 이 인덱스를 만들었다고 합시다
CREATE INDEX idx_orders_date_customer
ON orders(order_date, customer_id);

-- ✅ 이 쿼리는 인덱스를 활용합니다 (왼쪽부터 매칭)
SELECT * FROM orders WHERE order_date = '2025-03-01';
SELECT * FROM orders WHERE order_date = '2025-03-01' AND customer_id = 1;

-- ❌ 이 쿼리는 인덱스를 활용하지 못합니다!
SELECT * FROM orders WHERE customer_id = 1;
-- order_date 없이 customer_id만 쓰면, 인덱스의 왼쪽 컬럼을 건너뛰므로 Full Scan

⚠️ 많은 팀이 이 실수를 합니다: 쿼리 성능이 느려서 인덱스를 추가했는데, 컬럼 순서가 잘못되어 효과가 전혀 없는 경우. EXPLAIN 명령어로 실행 계획을 반드시 확인하세요.

​

인덱스의 비용

💡 실무 원칙: “조회가 많고 변경이 적은 테이블”에는 인덱스를 적극적으로 만들고, “변경이 빈번한 테이블”에는 꼭 필요한 인덱스만 만드세요. 하나의 테이블에 인덱스가 10개 이상이면 INSERT 성능이 눈에 띄게 나빠집니다.

​

Connection Pooling — 왜 중요한가

​

커넥션이 왜 비싼가

1. TCP 3-way handshake (네트워크 왕복)
2. 인증 및 권한 확인
3. 서버 측 메모리 할당 (MySQL 기준 커넥션당 약 10MB)
4. 세션 초기화

사용자 1,000명이 동시에 요청하는 상황:

Connection Pooling 없이:
→ 1,000개의 커넥션 동시 생성 시도
→ 서버 메모리: 10MB × 1,000 = 10GB 소진
→ CPU: 커넥션 생성/해제에 대부분 소비
→ 결과: 서버 다운 또는 극심한 지연

Connection Pooling 사용 시:
→ 미리 20~50개 커넥션을 만들어 재사용
→ 서버 메모리: 10MB × 50 = 500MB
→ 요청이 밀리면 큐에서 대기 (서버는 안전)
→ 결과: 안정적으로 처리

⚠️ 실무 경험: 서비스가 갑자기 느려져서 확인해 보면, DB 커넥션이 max에 도달해서 새 요청을 처리할 수 없는 경우가 정말 많습니다. Connection Pool 설정은 반드시 애플리케이션 배포 전에 확인하세요. Java는 HikariCP, Python은 SQLAlchemy의 connection pool이 대표적입니다.

​

대표적인 RDBMS 제품

​

RDBMS의 한계 — 왜 Lakehouse가 필요한가

💡 오해하지 마세요: RDBMS가 나쁜 기술이라는 것이 아닙니다. 운영 시스템(주문 처리, 결제, 회원 관리)에서는 여전히 RDBMS가 최적입니다. 문제는 분석과 AI 워크로드를 RDBMS로 처리하려 할 때 발생합니다. “OLTP는 RDBMS, 분석은 Lakehouse” — 이것이 현대 데이터 아키텍처의 기본 원칙입니다.

​

정리

​

참고 링크

• Databricks: SQL language reference
• PostgreSQL Tutorial
• MySQL Documentation
• Use The Index, Luke (인덱스 심화)