SQL, NoSQL 차이 완벽 분석 – 실무에서 알아야 할 선택 기준과 활용 전략

[SQL 관계형 모델 구조 예시]

users 테이블                    orders 테이블
┌──────┬──────────┬─────┐      ┌──────┬─────────┬────────┐
│ id   │ name     │ age │      │ id   │ user_id │ amount │
├──────┼──────────┼─────┤      ├──────┼─────────┼────────┤
│  1   │ 홍길동   │  25 │      │  101 │    1    │ 50,000 │
│  2   │ 김영희   │  30 │      │  102 │    1    │ 30,000 │
│  3   │ 박민준   │  22 │      │  103 │    2    │ 80,000 │
└──────┴──────────┴─────┘      └──────┴─────────┴────────┘
                                         ↑
                               FK(외래 키)로 users.id 참조

-- SQL 스키마 정의 예시 (MySQL)
CREATE TABLE users (
    id         BIGINT       NOT NULL AUTO_INCREMENT,
    name       VARCHAR(100) NOT NULL,
    email      VARCHAR(255) NOT NULL UNIQUE,
    created_at DATETIME     DEFAULT CURRENT_TIMESTAMP,
    PRIMARY KEY (id)
);

CREATE TABLE user_addresses (
    id         BIGINT       NOT NULL AUTO_INCREMENT,
    user_id    BIGINT       NOT NULL,
    address    VARCHAR(500) NOT NULL,
    is_default BOOLEAN      DEFAULT FALSE,
    PRIMARY KEY (id),
    FOREIGN KEY (user_id) REFERENCES users(id)
);

-- 사용자와 주소를 함께 조회 (JOIN)
SELECT u.name, u.email, a.address
FROM users u
LEFT JOIN user_addresses a ON u.id = a.user_id
WHERE u.id = 1;

// MongoDB 문서 구조 예시 – 사용자와 주소를 한 문서에 내장
{
  "_id": ObjectId("64a1b2c3d4e5f6a7b8c9d0e1"),
  "name": "홍길동",
  "email": "hong@example.com",
  "created_at": ISODate("2024-01-15"),
  "addresses": [                    // 주소 배열을 문서 안에 내장 (Embedding)
    {
      "address": "서울시 강남구 테헤란로 123",
      "is_default": true
    },
    {
      "address": "서울시 마포구 홍대입구로 456",
      "is_default": false
    }
  ],
  "preferences": {                  // 구조가 사용자마다 달라도 됨 (Schemaless)
    "theme": "dark",
    "language": "ko"
  }
}

// 다른 사용자 문서 – preferences 없어도 오류 없음
{
  "_id": ObjectId("64a1b2c3d4e5f6a7b8c9d0e2"),
  "name": "김영희",
  "email": "kim@example.com"
  // addresses, preferences 없어도 저장 가능
}

-- SQL: 수천만 건 테이블에 컬럼 추가 시
ALTER TABLE users ADD COLUMN phone VARCHAR(20);
-- → 테이블 전체 잠금(Lock) 발생 가능
-- → 수천만 건 기준 수 분~수십 분 소요
-- → 운영 서비스 영향 (pt-online-schema-change 등 도구 필요)

-- NoSQL(MongoDB): 새 필드 추가 시
db.users.updateOne(
    { "_id": userId },
    { $set: { "phone": "010-1234-5678" } }
);
-- → 해당 문서만 업데이트, 나머지 문서는 그대로
-- → 서비스 무중단, 즉시 적용 가능
-- → 단, phone 없는 문서도 존재하므로 애플리케이션에서 null 처리 필요

A – Atomicity (원자성)
  트랜잭션의 모든 작업은 전부 성공하거나 전부 실패합니다.
  "계좌 이체: A에서 출금 + B에게 입금"이 하나의 단위로 처리됨.
  출금만 되고 입금이 실패하는 중간 상태는 존재하지 않음.

C – Consistency (일관성)
  트랜잭션 전후로 데이터베이스의 무결성 제약 조건이 항상 만족됨.
  외래 키, NOT NULL, UNIQUE 제약이 항상 유지됨.

I – Isolation (격리성)
  동시에 실행되는 여러 트랜잭션이 서로 간섭하지 않음.
  내 트랜잭션이 완료되기 전까지 다른 트랜잭션에서 중간 상태가 보이지 않음.

D – Durability (지속성)
  커밋된 트랜잭션의 결과는 시스템 장애가 발생해도 보존됨.
  디스크에 영구적으로 기록되며, 정전·장애 후 복구 가능.

-- ACID 트랜잭션 실무 예시 – 계좌 이체
BEGIN TRANSACTION;

UPDATE accounts SET balance = balance - 100000 WHERE account_id = 'A001';
UPDATE accounts SET balance = balance + 100000 WHERE account_id = 'B001';

-- 중간에 오류 발생 시 전체 롤백
COMMIT;  -- 모두 성공 시 영구 반영
-- ROLLBACK;  -- 하나라도 실패 시 전부 취소

BA – Basically Available (기본적 가용성)
   시스템 일부에 장애가 발생해도 나머지는 계속 서비스됨.
   일부 노드가 다운되어도 전체 서비스가 멈추지 않음.

S – Soft State (소프트 상태)
   시스템 상태는 시간이 지남에 따라 변할 수 있음.
   외부 입력이 없어도 데이터 복제·동기화가 진행되며 상태가 바뀔 수 있음.

E – Eventual Consistency (최종 일관성)
   즉각적 일관성을 보장하지 않지만, 시간이 지나면 결국 일관성이 맞춰짐.
   "지금 당장은 노드A와 노드B의 데이터가 다를 수 있지만, 결국 같아진다."

[최종 일관성 실제 시나리오 – SNS 좋아요 수]

사용자가 게시물에 좋아요 클릭
  └─ 노드A: 좋아요 수 1,024 → 즉시 반영
  └─ 노드B: 아직 1,023 → 복제 지연 중
  └─ 노드C: 아직 1,023 → 복제 지연 중

200ms 후:
  └─ 노드A, B, C 모두 1,024 → 최종 일관성 달성

→ 좋아요 수가 잠깐 다르게 보여도 서비스에 큰 영향 없음
→ 반면, 계좌 잔액이 잠깐이라도 다르게 보이면 심각한 문제 발생

// MongoDB 멀티 도큐먼트 트랜잭션 (v4.0+)
const session = client.startSession();
session.startTransaction();

try {
    await ordersCollection.insertOne(
        { userId: "user1", amount: 50000, status: "pending" },
        { session }
    );
    await inventoryCollection.updateOne(
        { productId: "prod1" },
        { $inc: { stock: -1 } },
        { session }
    );
    await session.commitTransaction();
} catch (error) {
    await session.abortTransaction();  // 실패 시 전체 롤백
} finally {
    session.endSession();
}

[수직 확장 흐름]

초기:    서버 1대 (8코어, 32GB RAM)       → 트래픽 감당
성장:    서버 1대 (16코어, 64GB RAM)      → 비용 2배
급성장:  서버 1대 (32코어, 256GB RAM)     → 비용 10배
한계:    물리적 최대 사양 도달 → 더 이상 확장 불가 ⚠️

[MySQL 읽기/쓰기 분리 구조]

애플리케이션
    │
    ├─── 쓰기 요청(INSERT/UPDATE/DELETE) ──→ [Primary DB]
    │                                              │ 복제(Replication)
    └─── 읽기 요청(SELECT) ──→ [Replica DB 1] ←──┤
                             → [Replica DB 2] ←──┤
                             → [Replica DB 3] ←──┘

→ 읽기 트래픽을 여러 레플리카로 분산
→ 단, 쓰기는 여전히 Primary 1대에 집중 → 쓰기 병목은 해결 어려움

[NoSQL 수평 확장 구조 – Sharding]

                 [라우터/로드밸런서]
                /         |         \
          [샤드 1]    [샤드 2]    [샤드 3]
         user_id       user_id     user_id
          1~1M          1M~2M      2M~3M

→ 트래픽 증가 시 [샤드 4] 추가하면 됨
→ 이론적으로 무한히 확장 가능
→ 노드 1개 장애 시 나머지 샤드는 정상 동작 (부분 장애 허용)

노드 3개:  초당 쓰기 30만 건
노드 6개:  초당 쓰기 60만 건  (선형 확장)
노드 30개: 초당 쓰기 300만 건 (선형 확장 유지)

→ 노드를 추가하는 만큼 성능이 비례해서 증가
→ 이것이 NoSQL 수평 확장의 핵심 경쟁력

// MongoDB – 상품 카탈로그 예시 (상품마다 다른 속성)
// 의류 상품
{
  "_id": "prod-001",
  "name": "프리미엄 티셔츠",
  "category": "clothing",
  "price": 39000,
  "attributes": {
    "sizes": ["S", "M", "L", "XL"],
    "colors": ["화이트", "블랙", "네이비"],
    "material": "면 100%"
  }
}

// 전자제품 – 완전히 다른 구조, 같은 컬렉션에 공존 가능
{
  "_id": "prod-002",
  "name": "무선 이어폰",
  "category": "electronics",
  "price": 129000,
  "attributes": {
    "battery_life": "24시간",
    "connectivity": "Bluetooth 5.3",
    "noise_cancellation": true,
    "certifications": ["KC인증", "CE마크"]
  }
}

// Spring Boot + Redis 실무 활용 예시

// 1. 세션 캐시 (TTL 30분 자동 만료)
redisTemplate.opsForValue().set(
    "session:" + sessionId,
    userInfo,
    Duration.ofMinutes(30)
);

// 2. DB 쿼리 결과 캐싱 (Cache-Aside 패턴)
@Cacheable(value = "productDetail", key = "#productId")
public Product getProductDetail(Long productId) {
    return productRepository.findById(productId).orElseThrow();
    // 첫 번째 호출: DB 조회 후 Redis에 캐시
    // 이후 호출: Redis에서 즉시 반환 (DB 미접근)
}

// 3. 실시간 순위표 (Sorted Set 활용)
// 점수 업데이트
redisTemplate.opsForZSet().add("weekly:ranking", userId, score);

// 상위 10명 조회
Set<ZSetOperations.TypedTuple<String>> top10 =
    redisTemplate.opsForZSet()
        .reverseRangeWithScores("weekly:ranking", 0, 9);

-- Cassandra CQL 예시 – IoT 센서 데이터
CREATE TABLE sensor_data (
    device_id  UUID,
    timestamp  TIMESTAMP,
    temperature FLOAT,
    humidity    FLOAT,
    pressure    FLOAT,
    PRIMARY KEY (device_id, timestamp)
) WITH CLUSTERING ORDER BY (timestamp DESC);

-- 특정 기기의 최근 1시간 데이터 조회
SELECT * FROM sensor_data
WHERE device_id = 550e8400-e29b-41d4-a716-446655440000
  AND timestamp >= '2024-01-15 09:00:00'
  AND timestamp <= '2024-01-15 10:00:00';

-- Neo4j Cypher 쿼리 – "홍길동과 2단계 이내 아는 사람 중 공통 관심사 보유자"
MATCH (me:Person {name: '홍길동'})
      -[:KNOWS*1..2]-> (friend:Person)
      -[:INTERESTED_IN]-> (topic:Topic)
      <-[:INTERESTED_IN]- (me)
WHERE friend <> me
RETURN DISTINCT friend.name, collect(topic.name) AS common_topics
ORDER BY size(collect(topic.name)) DESC
LIMIT 10;

-- SQL로 같은 쿼리를 작성하면 재귀 CTE + 복잡한 JOIN
-- → 관계 깊이가 깊어질수록 기하급수적 성능 저하

[실무 이커머스 서비스 데이터베이스 아키텍처 예시]

                     [API 서버]
                         │
         ┌───────────────┼───────────────┐
         ▼               ▼               ▼
    [MySQL]         [MongoDB]         [Redis]
   (핵심 도메인)    (상품 카탈로그)    (캐시·세션)
   - 회원 정보     - 상품 상세        - 로그인 세션
   - 주문 내역     - 리뷰·Q&A         - 상품 조회 캐시
   - 결제 기록     - 이벤트 배너      - 장바구니 임시 저장
   - 재고 현황     - 개인화 설정      - 실시간 인기 상품 순위
         │
         ▼
   [Elasticsearch]           [Cassandra]
   (검색 엔진)              (로그·분석)
   - 상품 풀텍스트 검색      - 사용자 행동 로그
   - 자동완성·추천 검색      - 클릭스트림 데이터
                             - 실시간 통계 집계

[CAP 정리 – 분산 시스템에서 세 가지를 동시에 만족할 수 없음]

         C (Consistency, 일관성)
              /\
             /  \
            /    \
           / CA   \
          /  SQL   \
         /──────────\
        / CP   | AP  \
       /  HBase| Cassandra
      /  Mongo | DynamoDB
     /─────────────────\
    P (Partition)   A (Availability)
      Tolerance       가용성
      네트워크분리

CA 선택 (SQL): 일관성 + 가용성 → 네트워크 분리 시 서비스 중단 감수
CP 선택 (MongoDB 기본): 일관성 + 분리허용 → 장애 노드 응답 거부
AP 선택 (Cassandra, DynamoDB): 가용성 + 분리허용 → 최종 일관성 수용