이 lesson 을 다 읽고 나면 아래 3가지를 자신 있게 할 수 있습니다.

• ▸✅ RDBMS vs NoSQL 선택 기준 (정합성 vs 유연성)
• ▸✅ Redis 3대 활용 (캐시 · 세션 · Rate Limit)
• ▸✅ MongoDB Document 가 적합한 경우 vs 안 맞는 경우

학습 목표를 체크리스트로 두고 다 답할 수 있게 되면 lesson 을 닫으세요.

RDBMS 의 강점 — 데이터 무결성

MySQL·PostgreSQL 은 수십 년간 검증된 표준. 트랜잭션·외래키·정규화로 데이터 일관성 을 보장합니다.

RDBMS 의 한계 — 수평 확장이 어렵다

• ▸트래픽이 폭증하면 서버 1대로는 한계
• ▸여러 서버로 데이터를 쪼개기 (샤딩) 어려움 — JOIN·외래키가 서버 경계 넘으면 깨짐
• ▸모든 행이 같은 컬럼 구조 — 유연성 부족

NoSQL 의 4가지 종류

실무 선택 기준 — RDBMS 가 기본

2026년 현재 대부분의 신규 프로젝트는 RDBMS 가 메인. NoSQL 은 특정 용도의 보조 로 사용:

[웹 앱]
   ↓
[MySQL] ← 사용자·주문·상품 (정합성 중요)
[Redis] ← 캐시·세션·랭킹 (속도 중요)
[Elasticsearch] ← 전문 검색 (옵션)

"MySQL + Redis" 가 실무의 80% 표준 조합. 처음부터 MongoDB 메인으로 가는 케이스는 점점 줄어드는 추세.

Redis 가 빠른 이유

모든 데이터를 메모리에 보관. MySQL 이 디스크 (밀리초) 라면 Redis 는 메모리 (마이크로초) — 100배 차이.

패턴 1 — 캐시 (가장 많이 쓰는 용도)

def get_user(user_id):
    cached = redis.get(f"user:{user_id}")
    if cached:
        return json.loads(cached)        # 캐시 적중 → DB 안 감

    user = db.query("SELECT * FROM users WHERE id = ?", user_id)
    redis.setex(f"user:{user_id}", 300, json.dumps(user))   # 5분 캐시
    return user

Read 가 압도적으로 많은 데이터 (조회 100 / 수정 1 비율) 에 효과 폭발적.

캐시 무효화 — 가장 어려운 문제

def update_user(user_id, data):
    db.update(...)
    redis.delete(f"user:{user_id}")   # 캐시 즉시 삭제

"There are only two hard things in Computer Science: cache invalidation and naming things." — 캐시 무효화 누락이 실무 버그의 단골.

패턴 2 — 세션 저장소

# 로그인 시 세션 저장
session_id = secrets.token_urlsafe(32)
redis.setex(f"session:{session_id}", 86400, user_id)   # 24시간 유효

# 매 요청 검증
user_id = redis.get(f"session:{session_id}")
if not user_id:
    raise Unauthorized()

여러 서버 (Tomcat 클러스터) 가 같은 세션 공유 가능. JWT 와 달리 서버에서 즉시 무효화 가능.

패턴 3 — Rate Limit

def check_rate_limit(user_id, limit=100, window=60):
    key = f"rate:{user_id}"
    count = redis.incr(key)
    if count == 1:
        redis.expire(key, window)        # 첫 요청에 TTL 설정
    if count > limit:
        raise TooManyRequests()

1분에 100회 초과 차단. INCR + EXPIRE 두 줄로 구현 끝. API 남용 방지·DDoS 1차 방어.

다른 자주 쓰는 용도

• ▸랭킹 — ZADD leaderboard 100 user1 → Sorted Set 으로 실시간 랭킹
• ▸Pub/Sub — 가벼운 메시지 브로커 (작은 규모 한정)
• ▸분산 락 — Redlock 알고리즘 (조심해서 써야)

한계 — 영속성에 약함

메모리가 날아가면 데이터도 날아갑니다. AOF·RDB 백업이 있지만 주력 저장소로는 부적합. 항상 원본은 DB, 캐시는 Redis 구조.

Document 가 뭔가

JSON 처럼 생긴 문서가 한 행. 컬럼 미리 정의 X.

// users 컬렉션 (= RDBMS 테이블)
{
    "_id": ObjectId("..."),
    "email": "[email protected]",
    "name": "Alice",
    "address": {
        "city": "Seoul",
        "zip": "06000"
    },
    "hobbies": ["coding", "music"]
}

객체·배열을 그대로 저장. RDBMS 라면 3개 테이블 + JOIN 이 필요한 구조를 한 문서로.

기본 쿼리

// 추가
db.users.insertOne({ email: "[email protected]", name: "Alice", age: 30 });

// 조회
db.users.find({ age: { $gte: 18 } });

// 수정
db.users.updateOne(
    { email: "[email protected]" },
    { $set: { age: 31 } }
);

// 삭제
db.users.deleteOne({ email: "[email protected]" });

언제 MongoDB 가 맞나

✅ 적합

• ▸유연한 스키마 — 콘텐츠 메타데이터 (영상·기사 — 필드가 매번 다름)
• ▸빠른 프로토타이핑 — 마이그레이션 부담 적음
• ▸로그·이벤트 저장 — 시계열 데이터
• ▸계층 구조 데이터 — 댓글·메뉴 트리

❌ 부적합

• ▸트랜잭션 + 강한 일관성 — MongoDB 도 트랜잭션 있지만 RDBMS 만큼 견고하지 않음
• ▸복잡한 JOIN — MongoDB 의 $lookup 은 느림
• ▸고정 스키마 + 정합성 중요 — 사용자·결제·주문 — MySQL 이 정답

RDBMS 와 비교 한 줄

권장 학습 순서

1. MySQL 부터 마스터 — 모든 백엔드 개발자의 공통 기본기
2. Redis — 캐시·세션 가장 자주 쓰임
3. MongoDB — 필요한 프로젝트가 생겼을 때

"NoSQL 잘 알아요" 보다 "MySQL 잘 알아요" 가 면접에서 훨씬 강력합니다.

이 lesson 의 개념을 알면 AI 에게 구체적으로 지시할 수 있습니다. 막연한 "고쳐줘" 가 아니라 어휘를 가진 요청 — 그게 토큰 절약의 출발점입니다.

• ▸"users · orders · products 3 테이블 설계 + FK + INDEX 까지 만들어줘"
• ▸"최근 7일 가입한 사용자 수를 일별로 집계하는 쿼리 작성해줘"
• ▸"이 쿼리에 EXPLAIN 붙여서 실행계획 해석해줘"

왜 이게 토큰을 줄이나

개념을 모를 땐 AI 답변을 받고도 "그게 뭐예요?" 를 다시 물어야 합니다. 그 "다시 물음" 이 토큰을 잡아먹습니다. 개념 한 번 익혀두면 대화가 한 번에 끝납니다.