readyoun's devlog

복잡도와 핵심 자료구조 (C++, Java, Python 예시)

readyoun — Mon, 19 May 2025 21:27:29 +0900

[5.1 복잡도] 이해 완전 정복

면접을 위한 CS 전공지식노트 p.231 - 262 기반으로 작성.

✅ 복잡도가 뭐지?

알고리즘의 성능을 수치화한 기준입니다.

복잡도는 코드가 얼마나 빠르고 효율적으로 동작하는지를 판단하는 ‘시간과 공간 자원의 소비량’을 나타내는 척도예요.

시간 복잡도(Time Complexity): 코드가 실행되는데 걸리는 시간 (≒ 반복 횟수)
공간 복잡도(Space Complexity): 코드가 실행될 때 사용하는 메모리 공간

⏱️ 5.1.1 시간 복잡도

시간 복잡도란?

입력의 크기(n)가 커질수록, 코드가 얼마나 더 느려지는지를 보는 것.
실제 걸리는 ‘초’ 단위 시간은 아니고, 입력 크기에 비례하는 ‘연산 횟수’를 수학적으로 나타낸 것이에요.

왜 중요할까?

예를 들어:

O(n²) 알고리즘은 n이 10 → 100이 되면 연산 횟수가 100배 → 10,000배로 늘어나요!
반면 O(n log n)은 훨씬 완만하게 증가해요.

대표적인 시간 복잡도

빅오	설명	예시
`O(1)`	입력 크기와 무관하게 항상 일정한 시간	해시 테이블 조회
`O(log n)`	절반씩 나눠서 탐색	이진 탐색
`O(n)`	모든 요소를 순회	선형 검색
`O(n log n)`	정렬 알고리즘의 평균 성능	병합 정렬, 힙 정렬
`O(n²)`	이중 반복문	버블 정렬
`O(2ⁿ)`	모든 경우의 수 탐색	부분 집합 생성

핵심: 빠른 코드를 짜고 싶다면 O(1) → O(log n) → O(n) 순으로 지향해야 합니다.

빅오 표기법 (Big-O Notation)

가장 영향력 있는 항만 남기고 나머진 버리는 방식

for (int i = 0; i < n; i++) { 
    for (int j = 0; j < n; j++) { 
        cout << i << j << '\n'; 
    }
}

이중 루프 → 반복 횟수: n * n = n²
→ 시간 복잡도: O(n²)

⛔ 왜 상수는 무시할까?

예: 10n² + 5n + 20 → O(n²)
입력 크기 n이 커지면 10, 5, 20은 전혀 중요하지 않게 되니까요.

⌛ 5.1.2 공간 복잡도

알고리즘이 얼마만큼의 메모리를 쓰는가?

정적 배열: int a[1000] → 약 4KB 사용
재귀 호출: 함수 스택 계속 쌓이므로 공간 복잡도 커짐
반복문 vs 재귀함수: 반복문은 공간 낭비 거의 없음, 재귀는 함수 호출마다 스택이 쌓임

5.1.3 자료 구조별 시간 복잡도

✅ 평균 시간 복잡도 (일반적인 상황)

자료구조	접근	탐색	삽입	삭제
배열	`O(1)`	`O(n)`	`O(n)`	`O(n)`
스택/큐	`O(n)`	`O(n)`	`O(1)`	`O(1)`
연결 리스트	`O(n)`	`O(n)`	`O(1)`	`O(1)`
해시 테이블	`O(1)`	`O(1)`	`O(1)`	`O(1)`
이진 탐색 트리	`O(log n)`	`O(log n)`	`O(log n)`	`O(log n)`
AVL, 레드-블랙 트리	`O(log n)` 전부

❗ 최악의 시간 복잡도 (엣지 케이스)

해시 테이블: 모든 key가 같은 해시값 → 연결 리스트처럼 되어 O(n)됨
이진 탐색 트리: 정렬된 값이 삽입되면 선형 구조가 되어 O(n)됨

평균 vs 최악 복잡도 정리

비교	평균	최악
해시 테이블	빠름 (`O(1)`)	느림 (`O(n)`)
AVL 트리	안정적 (`O(log n)`)	안정적 (`O(log n)`)
연결 리스트	삽입은 빠름 (`O(1)`)	탐색은 느림 (`O(n)`)

언제 어떤 걸 선택할까?

빠른 검색이 중요하다 → 해시 테이블 (단, 충돌 대비 필요)
항상 일정 성능 보장 → AVL, Red-Black Tree
삽입/삭제 자주 → 연결 리스트
배열처럼 빠른 접근 + 크기 유동적 → 벡터

한 문장 요약

시간과 공간 복잡도를 분석하면 성능 좋고 버그 없는 코드 설계가 가능해진다.

[5.2 복잡도] 선형 자료 구조

5.2.1 연결 리스트 (Linked List)

✅ 연결 리스트란?

데이터를 저장하는 노드들을 포인터로 연결해서 구성한 선형 자료구조입니다.

배열은 메모리에 연속적으로 저장되지만,
연결 리스트는 각 노드가 흩어져 있으며,
노드 간 연결만 포인터로 이어져 있습니다.

구성 요소

노드(Node): 하나의 데이터 + 다음 노드를 가리키는 포인터
포인터(Pointer): 다음(혹은 이전) 노드의 주소를 저장

즉, 연결 리스트는 ‘노드들의 체인’이다.

연결 리스트의 종류

종류	설명	방향
단일 연결 리스트	각 노드가 다음 노드만 가리킴	한 방향
이중 연결 리스트	각 노드가 이전/다음 노드 모두 가리킴	양 방향
원형 연결 리스트	마지막 노드가 처음 노드를 가리킴	순환 구조

그림 5-3: 세 가지 구조 비교

특징 요약

메모리는 연속적이지 않음
삽입/삭제가 빠름 (중간 삽입도 링크만 바꾸면 됨)
임의 접근이 불가능 (배열처럼 인덱스로 바로 접근 못함)
동적 크기 조절 가능

⏱️ 시간 복잡도 정리

연산	시간 복잡도	설명
접근	O(n)	원하는 위치까지 순회 필요
탐색	O(n)	조건 만족하는 값 찾기
삽입	O(1)	포인터만 조작하면 됨 (위치 알고 있다면)
삭제	O(1)	포인터만 끊으면 됨 (위치 알고 있다면)

주의
삽입/삭제가 빠르다는 것은 "노드 위치를 알고 있는 경우" 에 한정됨.
위치를 모른다면 역시 O(n)만큼 순회해야 함.

C++ 코드 예시 (STL `list` 활용)

#include <bits/stdc++.h>
using namespace std; 

int main() {
    list<int> a; 
    for (int i = 0; i < 10; i++) a.push_back(i); 
    for (int i = 0; i < 10; i++) a.push_front(i); 

    auto it = a.begin(); 
    ++it; 
    a.insert(it, 1000); 

    for (auto x : a) cout << x << " "; 
    cout << '\n';

    a.pop_front(); 
    a.pop_back(); 

    for (auto x : a) cout << x << " ";
    cout << '\n'; 
    return 0; 
}

push_front(): 앞에 삽입
push_back(): 뒤에 삽입
insert(): 특정 위치 삽입
pop_front(), pop_back(): 앞/뒤 삭제

Java와 Python 예시

Java: `LinkedList` 클래스

LinkedList<String> list = new LinkedList<>();
list.add("사과");
list.addFirst("바나나");
list.addLast("오렌지");
list.add(1, "포도");

System.out.println(list.getFirst()); // 바나나
list.remove("포도");
for (String item : list) System.out.println(item);

Python: `collections.deque`

from collections import deque

linked_list = deque()
linked_list.append("사과")
linked_list.appendleft("바나나")
linked_list.append("오렌지")
linked_list.insert(1, "포도")

print(linked_list[0])  # 바나나
linked_list.remove("포도")
for item in linked_list: print(item)

Python의 deque는 이중 연결 리스트 기반으로 되어 있어 삽입/삭제가 효율적입니다.

정리

연결 리스트는 메모리 효율적이고, 삽입/삭제가 빠름
단점은 임의 접근이 느리다는 점 (순차 접근만 가능)
다양한 언어에서 기본 라이브러리로 제공되며, 구조 이해가 중요

5.2.2 배열 (Array)

✅ 배열이란?

같은 타입의 데이터를 연속된 메모리 공간에 저장한 자료 구조입니다.

프로그래밍 언어에서 가장 기본이 되는 자료구조이며, 고정 크기, 빠른 접근 속도가 특징입니다.

배열의 특징

동일한 타입의 요소들을 저장
고정된 크기 (생성 시 크기 결정, 이후 변경 불가)
메모리 연속 배치
인덱스를 통한 직접 접근 가능 (랜덤 접근)
중복 허용, 순서 존재

접근 방식

그림 5-4 참고: 랜덤 접근 vs 순차 접근

접근 방식	설명	대표 자료구조
랜덤 접근	인덱스를 통해 즉시 접근 (주소 계산)	배열, 벡터
순차 접근	앞에서부터 차례로 접근해야 함	연결 리스트

⚔️ 배열 vs 연결 리스트

기준	배열	연결 리스트
메모리 배치	연속적	비연속적
접근 속도	빠름 `O(1)`	느림 `O(n)`
삽입/삭제	느림 `O(n)`	빠름 `O(1)` (위치 알고 있을 경우)
크기 조절	불가능	가능
캐시 적중률	높음	낮음

배열은 메모리 캐시에 잘 맞아서 CPU 접근 속도도 빠름

⏱️ 배열의 시간 복잡도

연산	시간 복잡도	설명
접근	`O(1)`	인덱스만 알면 주소 계산으로 즉시 접근
검색	`O(n)`	선형 검색 필요 (정렬된 경우 이진 탐색은 `O(log n)`)
삽입	`O(n)`	중간 삽입 시 요소 이동 필요
삭제	`O(n)`	중간 삭제 시 요소 이동 필요

단, 끝에 삽입/삭제는 O(1)이 될 수 있음 (배열의 크기만 충분하다면)

C/C++ 배열 예시

int arr[5] = {10, 20, 30, 40, 50};
cout << arr[2];  // 30 출력

arr[2]는 시작 주소 + 2칸 만큼 이동해서 값을 바로 가져옴
→ O(1) 시간

Java 배열 예시

int[] arr = {10, 20, 30, 40, 50};
System.out.println(arr[2]); // 30

배열은 생성 후 크기를 변경할 수 없음
대신 Java에서는 ArrayList로 동적 배열 기능을 확장함 (다음 섹션)

Python 배열 (`list`) 예시

arr = [10, 20, 30, 40, 50]
print(arr[2])  # 30

Python의 list는 내부적으로 동적 배열
append(), insert(), pop() 등의 메서드 제공

정리

배열은 빠른 접근과 고정 크기라는 명확한 장점이 있음
삽입/삭제에는 부적합 (특히 중간에)
알고리즘에서 빠른 참조가 필요한 경우 유리
연결 리스트와 비교해 장단점을 이해하고 상황에 맞게 선택해야 함

5.2.3 벡터 (Vector)

✅ 벡터란?

크기를 동적으로 조절할 수 있는 동적 배열(Dynamic Array)

기본적으로 배열처럼 동작하지만, 필요에 따라 자동으로 메모리를 재할당하면서 크기를 늘릴 수 있습니다.
C++에서는 std::vector, Java에서는 ArrayList, Python에서는 list가 이에 해당합니다.

벡터의 특징

연속된 메모리 공간을 사용
중복 허용, 순서 보장
요소가 가득 차면 더 큰 공간을 새로 할당하고 기존 데이터를 복사
크기 증가 시 보통 2배로 늘려 재할당 → 효율적 성장

배열과의 차이점

기준	배열 (Array)	벡터 (Vector)
크기	고정	동적
메모리	사용자 지정	자동 할당/재할당
삽입/삭제	비효율적	상대적으로 유연
접근 방식	인덱스 기반	인덱스 기반
성능	더 빠름	약간 오버헤드 있음 (성장 시 복사)

⏱️ 벡터의 시간 복잡도

연산	시간 복잡도	설명
접근	O(1)	배열처럼 인덱스로 직접 접근
검색	O(n)	선형 탐색 필요
삽입 (끝)	평균 O(1)	공간이 남아있으면 빠름
삽입 (중간)	O(n)	요소 이동 필요
삭제 (끝)	O(1)	마지막 요소 제거는 빠름
삭제 (중간)	O(n)	요소 이동 필요

삽입/삭제는 끝에서 하면 빠르지만, 중간에서는 느림

amortized time (분할 상환 시간 복잡도)

push_back()은 보통 O(1)이지만, 가끔 O(n)이 발생합니다.

예: 벡터가 가득 찬 경우 → 더 큰 배열 생성 + 전체 복사

하지만 이런 일이 매번 일어나는 게 아니라, 전체적으로 보면 평균 O(1) 로 볼 수 있습니다.

이것을 분할 상환 분석(amortized analysis)라고 합니다.

C++ 벡터 예시

#include <vector>
#include <iostream>
using namespace std;

int main() {
    vector<int> v;

    for (int i = 0; i < 5; i++) v.push_back(i);  // 끝에 삽입

    v.insert(v.begin() + 2, 100);  // 중간 삽입
    v.pop_back();                  // 마지막 요소 제거

    for (int i : v) cout << i << " ";
}

Java ArrayList 예시

import java.util.*;

public class Main {
    public static void main(String[] args) {
        ArrayList<Integer> list = new ArrayList<>();

        list.add(10);              // 끝에 추가
        list.add(1, 20);           // 특정 위치 삽입
        list.remove(0);            // 인덱스로 삭제

        for (int i : list) System.out.println(i);
    }
}

Python list 예시

lst = []
lst.append(10)       # 끝에 추가
lst.insert(1, 20)     # 인덱스 1에 삽입
lst.pop()            # 끝에서 제거
print(lst)

Python의 list는 내부적으로 C 배열 기반의 동적 배열 구조입니다.

정리

벡터는 배열처럼 빠른 접근(O(1)) + 동적 크기 조절이 가능한 자료구조
끝에 삽입/삭제는 빠르지만, 중간 삽입/삭제는 성능 저하
대부분의 현대 언어에서 표준 동적 배열 타입으로 제공
알고리즘 문제 풀 때 배열 vs 벡터는 크기 조절이 필요한지를 기준으로 선택

5.2.5 큐 (Queue)

✅ 큐란?

먼저 넣은 데이터가 먼저 나오는 자료구조
→ FIFO (First-In, First-Out) 구조

일상 예시

줄 서서 기다리는 은행 창구
대기열이 있는 프린터
음식점 번호표 시스템

주요 연산

연산	설명
`enqueue()`	큐 뒤에 삽입
`dequeue()`	큐 앞에서 제거
`front()` 또는 `peek()`	맨 앞의 요소 확인 (삭제 X)
`isEmpty()`	큐가 비었는지 확인

⏱️ 시간 복잡도

연산	시간 복잡도	설명
삽입	O(1)	뒤에 추가
삭제	O(1)	앞에서 제거
조회	O(1)	맨 앞만 확인
검색	O(n)	특정 값 탐색 시 전체 순회 필요

C++ STL 큐 예시

#include <queue>
#include <iostream>
using namespace std;

int main() {
    queue<int> q;

    q.push(10);       // enqueue
    q.push(20);
    q.push(30);

    cout << q.front(); // 10
    q.pop();           // dequeue

    cout << q.front(); // 20
}

Java Queue 예시

import java.util.*;

public class Main {
    public static void main(String[] args) {
        Queue<Integer> q = new LinkedList<>();

        q.add(10);             // enqueue
        q.add(20);
        q.add(30);

        System.out.println(q.peek()); // 10
        q.remove();                   // dequeue
        System.out.println(q.peek()); // 20
    }
}

Python 큐 예시 (`collections.deque` 추천)

from collections import deque

q = deque()
q.append(10)      # enqueue
q.append(20)
q.append(30)

print(q[0])       # front: 10
q.popleft()       # dequeue
print(q[0])       # front: 20

list로 큐를 구현하면 pop(0)이 느려서 deque 사용을 권장

큐는 언제 사용할까?

데이터를 순차적으로 처리할 때
비동기 처리 / 버퍼링 / BFS 탐색 등
시스템 프로그래밍에서 프로세스 대기열 구현 시

5.3.1 그래프 (Graph)

✅ 그래프란?

지금까지 봤던 배열·리스트·큐 등은 "일렬로 나열된 구조"였지만,

그래프는 노드들 간의 관계가 복잡하게 얽힌 구조.

정점(Vertex) 과 간선(Edge) 으로 이루어진 비선형 자료구조

→ 사물 간의 복잡한 관계를 표현할 수 있음

예시

지도(도시와 도로)
SNS 관계(사람과 친구 관계)
웹사이트 연결(페이지와 링크)

구성 요소

요소	설명
정점 (Vertex)	데이터를 담는 단위, 즉 노드
간선 (Edge)	정점 간의 연결 (양방향/단방향 가능)
진입 차수 (In-degree)	특정 정점으로 들어오는 간선 수
진출 차수 (Out-degree)	특정 정점에서 나가는 간선 수

그래프의 종류

종류	설명	특징
무방향 그래프	간선에 방향 없음	A—B: A→B, B→A 모두 가능
방향 그래프	간선에 방향 있음	A→B는 B→A와는 다름
가중치 그래프	간선에 비용/거리 등의 숫자가 있음	길이, 시간, 비용 표현 가능

⛓️ 그래프의 표현 방식

방식	설명	공간 복잡도
인접 행렬 (Adjacency Matrix)	2차원 배열로 간선 표현	O(V²)
인접 리스트 (Adjacency List)	각 정점이 연결된 정점 리스트 보유	O(V + E)

V: 정점 수, E: 간선 수
일반적으로 인접 리스트가 메모리 효율이 좋음

⏱️ 시간 복잡도 참고

연산	인접 리스트	인접 행렬
간선 존재 확인	O(정점 개수)	O(1)
모든 간선 순회	O(V + E)	O(V²)

Python 그래프 인접 리스트 예시

graph = {
    0: [1, 2],
    1: [0, 3],
    2: [0],
    3: [1]
}

Python 인접 행렬 예시

graph = [
    [0, 1, 1, 0],
    [1, 0, 0, 1],
    [1, 0, 0, 0],
    [0, 1, 0, 0]
]

C++ 그래프 표현 예시

1. 인접 리스트 (vector of vector)

#include <iostream>
#include <vector>
using namespace std;

int main() {
    int V = 4;
    vector<vector<int>> graph(V);

    graph[0].push_back(1);
    graph[0].push_back(2);
    graph[1].push_back(0);
    graph[1].push_back(3);
    graph[2].push_back(0);
    graph[3].push_back(1);

    // 출력
    for (int i = 0; i < V; i++) {
        cout << i << " : ";
        for (int j : graph[i]) cout << j << " ";
        cout << '\n';
    }
}

2. 인접 행렬

#include <iostream>
using namespace std;

int main() {
    int graph[4][4] = {
        {0, 1, 1, 0},
        {1, 0, 0, 1},
        {1, 0, 0, 0},
        {0, 1, 0, 0}
    };

    for (int i = 0; i < 4; i++) {
        for (int j = 0; j < 4; j++) {
            cout << graph[i][j] << " ";
        }
        cout << '\n';
    }
}

Java 그래프 표현 예시

1. 인접 리스트 (ArrayList)

import java.util.*;

public class Main {
    public static void main(String[] args) {
        int V = 4;
        ArrayList<ArrayList<Integer>> graph = new ArrayList<>();

        for (int i = 0; i < V; i++)
            graph.add(new ArrayList<>());

        graph.get(0).add(1);
        graph.get(0).add(2);
        graph.get(1).add(0);
        graph.get(1).add(3);
        graph.get(2).add(0);
        graph.get(3).add(1);

        for (int i = 0; i < V; i++) {
            System.out.print(i + " : ");
            for (int j : graph.get(i)) {
                System.out.print(j + " ");
            }
            System.out.println();
        }
    }
}

2. 인접 행렬

public class Main {
    public static void main(String[] args) {
        int[][] graph = {
            {0, 1, 1, 0},
            {1, 0, 0, 1},
            {1, 0, 0, 0},
            {0, 1, 0, 0}
        };

        for (int i = 0; i < graph.length; i++) {
            for (int j = 0; j < graph[i].length; j++) {
                System.out.print(graph[i][j] + " ");
            }
            System.out.println();
        }
    }
}

요약하자면:

언어	인접 리스트	인접 행렬
C++	`vector<vector<int>>`	2차원 배열 `int graph[100][100]`
Java	`ArrayList<ArrayList<Integer>>`	`int[][]` 배열
Python	`dict`, `list of lists`	2차원 리스트

그래프는 언제 쓰일까?

탐색 알고리즘 (BFS, DFS) 에 자주 사용
경로 탐색 / 최단 거리 / 사이클 검출
예: 네비게이션, 추천 시스템, 의존성 그래프

그래프는 단독으로 잘 안 나오고, 대부분 탐색 문제 (BFS/DFS)와 함께 등장

5.3.2 트리 (Tree)

✅ 트리란?

사이클이 없는 연결 그래프이자, 하나의 루트에서 시작되는 계층적 자료 구조

트리는 다음을 모두 만족해야 합니다:

모든 정점이 하나의 루트로 연결
사이클 없음
정점 수 = 간선 수 + 1

기본 용어 정리

용어	의미
루트 노드 (root)	트리의 시작점, 최상위 노드
부모 노드	다른 노드를 직접 가리키는 노드
자식 노드	부모에게 연결된 노드
리프 노드	자식이 없는 노드
내부 노드	자식이 있는 노드
서브트리	특정 노드를 루트로 하는 부분 트리

깊이, 높이, 레벨

개념	설명
깊이 (depth)	루트에서 해당 노드까지의 거리
높이 (height)	해당 노드에서 가장 깊은 리프까지의 거리
레벨	같은 깊이의 노드 묶음

그림 5-15에서 레벨/깊이/높이를 시각적으로 정리하면 이해 쉬움

트리의 특징

정점 V개 → 간선 E = V - 1개
모든 정점 간의 경로가 유일함
(루트에서 어떤 노드로 가는 길은 단 하나)
순환 없음

이진 트리 (Binary Tree)

자식 노드가 최대 2개인 트리

이진 트리의 종류

종류	설명
정 이진 트리 (full)	모든 노드가 자식 0개 또는 2개
완전 이진 트리 (complete)	마지막 레벨을 제외하고 꽉 채움
포화 이진 트리 (perfect)	모든 레벨이 완전히 채워짐
변질 이진 트리 (degenerate)	한쪽 자식만 있는 선형 구조
균형 이진 트리 (balanced)	좌우 서브트리 높이 차이가 1 이하

이진 탐색 트리 (BST: Binary Search Tree)

정렬된 데이터를 효율적으로 저장/탐색하기 위한 이진 트리

왼쪽 서브트리: 현재 노드보다 작은 값
오른쪽 서브트리: 현재 노드보다 큰 값

BST 시간 복잡도

연산	평균	최악
검색	O(log n)	O(n) ← 선형 트리 될 때
삽입	O(log n)	O(n)
삭제	O(log n)	O(n)

최악의 경우는 정렬된 순서로 노드가 삽입될 때 (→ Linked List처럼 됨)

⚖️ 균형 이진 탐색 트리

정렬된 데이터를 넣었을 때 한쪽으로 치우치지 않도록 자동으로 균형을 맞춰줌

✅ AVL 트리

각 노드의 좌우 서브트리 높이 차이가 1 이하
삽입/삭제 시 회전 연산으로 균형 조정

✅ 레드-블랙 트리

각 노드에 색상(빨강/검정) 부여
5가지 규칙으로 트리의 균형을 유지
균형 조건은 느슨하지만, 수행 속도가 빠름

비교	AVL	레드-블랙
회전 횟수	더 많음	더 적음
균형 정도	더 엄격	덜 엄격
성능	탐색 빠름	삽입/삭제 빠름

[더보기]

노드에 색상(빨강/검정) 부여
- 레드-블랙 트리에서 빨강/검정 색상은 추상적인 규칙을 시각적으로 표현한 메커니즘으로,
  트리의 구조적 균형을 강제하는 알고리즘의 핵심
  - 빨강 노드: "이 노드가 삽입/삭제로 인해 균형이 깨질 수 있음"을 표시
  - 검정 노드: "이 노드 주변의 균형이 안정적임"을 표시
- 색상 조합이 규칙을 위반하면(예: 빨강 노드 연속 발생), 회전(rebalancing) 또는 재색상(recoloring) 연산이 자동으로 트리거
5가지 규칙으로 균형 유지
1. 모든 노드는 빨간색 또는 검은색이다.
  - 레드-블랙 트리에서 노드에 빨강/검정 색을 부여하는 가장 큰 목적은 트리의 균형을 자동으로 유지하기 위함
  - 빨강/검정 규칙 덕분에 트리의 한쪽으로 치우침(최악의 경우 linked list화)을 막아, 트리 높이가 항상 O(log n)에 머물게
2. 루트 노드는 항상 검은색이다.
3. 모든 NIL 리프 노드는 검은색이다.
  - NIL = 아무 값도 없는(비어있는) 검정색 노드
4. 빨간색 노드의 자식은 모두 검은색이다. (빨간색 노드는 연속될 수 없다)
5. 루트 노드에서 모든 리프 노드까지의 경로에서 검은색 노드의 개수는 같다.
  - 이 규칙은 검정 높이(black height) 개념으로 표현
  - 검정 높이 = 특정 노드에서 리프까지 경로의 검정색 노드 수
  - 모든 서브트리에서 검정 높이가 일정하게 유지
    - 예시: 루트 노드에서 리프까지 경로에 검정 노드가 3개라면, 다른 모든 경로에서도 검정 노드는 3개여야

트리는 언제 사용할까?

계층적 데이터 표현: 파일 시스템, 조직도
탐색 최적화: 이진 탐색 트리, 맵/셋 구현
문법 분석: 파싱 트리, 표현식 트리

트리는 정말 중요하고 자주 쓰이니, 이진 탐색 트리(BST), AVL, 레드블랙트리는 특히 시간 복잡도와 구조 꼭 숙지하자

⛰️ 5.3.3 힙 (Heap)

✅ 힙이란?

지금까지 다뤘던 트리의 연장선상에 있지만, 힙은 우선순위에 따라 정렬된 특수한 완전 이진 트리

완전 이진 트리 형태를 가지면서,
부모 노드가 자식 노드보다 항상 크거나 작아야 하는 자료 구조

즉, 구조는 트리지만, 동작은 우선순위 큐(Priority Queue) 를 위한 용도에 최적화돼 있음.

힙의 종류

종류	설명	루트 노드 특징
최대 힙 (Max Heap)	부모 ≥ 자식	루트 = 가장 큰 값
최소 힙 (Min Heap)	부모 ≤ 자식	루트 = 가장 작은 값

힙의 특징

완전 이진 트리
→ 마지막 레벨을 제외하고 왼쪽부터 빈틈없이 채워짐
(배열로 구현하기 딱 좋음)
정렬된 트리가 아님
→ 왼쪽/오른쪽 간 대소관계는 중요하지 않음
→ 항상 부모와 자식 간의 우선순위만 보장

⏱️ 시간 복잡도

연산	시간 복잡도	설명
삽입 (`push`)	O(log n)	마지막에 추가 후 위로 정렬 (heapify-up)
삭제 (`pop`)	O(log n)	루트 제거 후 마지막 노드를 루트로, 아래로 정렬 (heapify-down)
최대/최소 확인	O(1)	루트만 보면 됨

Python 예시 (기본은 최소 힙)

import heapq

heap = []
heapq.heappush(heap, 5)
heapq.heappush(heap, 3)
heapq.heappush(heap, 8)

print(heapq.heappop(heap))  # 3 (가장 작은 값)

❗ 최대 힙 사용하려면?

heapq.heappush(heap, -5)  # 음수로 변환
max_val = -heapq.heappop(heap)

C++ 예시 (`priority_queue`)

#include <queue>
#include <vector>
#include <iostream>
using namespace std;

int main() {
    priority_queue<int> maxHeap; // 최대 힙

    maxHeap.push(3);
    maxHeap.push(5);
    maxHeap.push(1);

    cout << maxHeap.top(); // 5
}

최소 힙 만들기

priority_queue<int, vector<int>, greater<int>> minHeap;

Java 예시 (`PriorityQueue`)

import java.util.*;

public class Main {
    public static void main(String[] args) {
        PriorityQueue<Integer> minHeap = new PriorityQueue<>();

        minHeap.add(5);
        minHeap.add(3);
        minHeap.add(8);

        System.out.println(minHeap.poll());  // 3
    }
}

최대 힙 만들기

PriorityQueue<Integer> maxHeap = new PriorityQueue<>(Collections.reverseOrder());

언제 쓰나?

우선순위가 있는 작업 관리: CPU 스케줄러, 작업 큐
최소/최대 값 빠르게 꺼내기: Top-K 문제, 다익스트라 알고리즘
정렬 알고리즘: 힙 정렬 (Heap Sort)

정렬이 필요한 상황에서 항상 전체를 정렬할 필요는 없음

예: 가장 큰 값 3개만 꺼낼 때 → 정렬보다 힙이 훨씬 빠름

5.3.4 우선순위 큐 (Priority Queue)

✅ 우선순위 큐란?

힙이랑 거의 세트로 다뤄지는 자료구조

일반적인 큐(FIFO)와 달리,
우선순위가 높은 요소가 먼저 나가는 큐입니다.

삽입된 순서가 아니라 우선순위 값(priority) 기준으로 처리
내부적으로는 보통 힙(Heap) 자료구조로 구현됨

일반 큐 vs 우선순위 큐

구분	일반 큐	우선순위 큐
처리 순서	들어온 순서대로	우선순위 높은 것부터
구현 구조	배열, 리스트	힙
사용 목적	순차 처리	긴급도/중요도 반영

⏱️ 시간 복잡도 (힙 기반일 경우)

연산	시간 복잡도	설명
삽입	O(log n)	힙에 추가 후 정렬
삭제 (최고 우선순위)	O(log n)	루트 제거 후 재정렬
최고 우선순위 조회	O(1)	루트 노드 확인

Python 우선순위 큐 예시

import heapq

# 빈 힙(우선순위 큐) 생성 - 최소 힙이 기본
pq = []

# (우선순위, 작업 내용) 튜플을 push
heapq.heappush(pq, (2, '코딩'))   # 우선순위 2
heapq.heappush(pq, (1, '점심'))   # 우선순위 1 (더 먼저 처리됨)
heapq.heappush(pq, (3, '운동'))   # 우선순위 3

# 우선순위가 낮은 숫자부터 pop됨
while pq:
    priority, task = heapq.heappop(pq)  # 가장 낮은 우선순위 튜플 꺼냄
    print(f"[우선순위 {priority}] {task}")

"""
[우선순위 1] 점심
[우선순위 2] 코딩
[우선순위 3] 운동
"""

(우선순위, 값) 형태로 넣어야 함
기본은 최소 힙, 낮은 숫자가 우선

C++ `priority_queue` 예시

#include <queue>
#include <iostream>
using namespace std;

int main() {
    // 기본 priority_queue는 최대 힙: 큰 값부터 먼저 나옴
    priority_queue<pair<int, string>> pq;

    // (우선순위, 작업 내용) 삽입
    pq.push({2, "코딩"});
    pq.push({1, "점심"});
    pq.push({3, "운동"});

    // 우선순위가 높은 값(숫자 큰 값)부터 나옴
    while (!pq.empty()) {
        cout << "[우선순위 " << pq.top().first << "] " << pq.top().second << '\n';
        pq.pop();  // 하나 꺼냄
    }
}
/*
[우선순위 3] 운동
[우선순위 2] 코딩
[우선순위 1] 점심
*/

기본은 최대 힙 → 우선순위 높은 숫자부터 나감
greater<>를 써서 최소 힙으로도 만들 수 있음

Java `PriorityQueue` 예시

import java.util.*;

public class Main {
    public static void main(String[] args) {
        // PriorityQueue는 기본적으로 낮은 숫자가 높은 우선순위 (최소 힙)
        PriorityQueue<Task> pq = new PriorityQueue<>();

        pq.add(new Task(2, "코딩"));   // 우선순위 2
        pq.add(new Task(1, "점심"));   // 우선순위 1
        pq.add(new Task(3, "운동"));   // 우선순위 3

        while (!pq.isEmpty()) {
            System.out.println(pq.poll().name); // 우선순위 낮은 숫자부터 poll()
        }
    }
}

// 우선순위 비교를 위한 Comparable 구현
class Task implements Comparable<Task> {
    int priority;
    String name;

    Task(int p, String n) {
        priority = p;
        name = n;
    }

    // 우선순위 기준: 숫자가 작을수록 높은 우선순위
    public int compareTo(Task o) {
        return this.priority - o.priority;
    }
}
/*
점심
코딩
운동
*/

Comparable: 어떤 클래스의 객체들끼리 서로 비교할 수 있도록 만들어주는 Java의 인터페이스

PriorityQueue나 Collections.sort() 같은 정렬 관련 기능들은 “어떤 기준으로 비교해서 정렬할지” 알아야 함.

int, String 등은 이미 정해진 기준이 있지만, 사용자 정의 클래스에서는 직접 비교 기준을 정해줘야 함.

언제 사용할까?

시스템 작업 스케줄링 (OS의 Job Queue)
다익스트라 알고리즘 (최단 경로)
A* 탐색 알고리즘(A-star Search)
네트워크 패킷 처리 / 인터럽트 처리

핵심 요약: 우선순위 큐는 힙을 추상화한 개념.

그냥 "우선순위 있는 대기열"이 필요하다? → 바로 Priority Queue 사용

5.3.5 맵 (Map)

✅ 맵이란?

키-값 쌍 (Key-Value Pair) 형태로 데이터를 저장하는 자료구조
→ 특정 키를 통해 값을 빠르게 찾아낼 수 있음

예시:

{
    "이름": "리쿠",
    "나이": 21
}

맵의 특징

키는 유일(unique)
값은 중복 가능
검색, 삽입, 삭제 모두 빠름 (Hash 기반일 경우 O(1), 트리 기반일 경우 O(log n))

구현 방식별 특징

자료구조	기반 구조	시간 복잡도	정렬 여부
`map` (C++/Java)	이진 탐색 트리	O(log n)	키 기준 정렬됨
`unordered_map` / `HashMap`	해시 테이블	O(1) 평균 / O(n) 최악	정렬되지 않음

⏱️ 시간 복잡도 정리

연산	`map`	`unordered_map`
검색	O(log n)	O(1) 평균
삽입	O(log n)	O(1) 평균
삭제	O(log n)	O(1) 평균

언어별 예시

Python `dict`

info = {"name": "Riku", "age": 22}
print(info["name"])  # "Riku"

C++ `map`, `unordered_map`

map<string, int> m;
m["apple"] = 3;
cout << m["apple"];  // 3

unordered_map<string, int> um;
um["apple"] = 3;

Java `HashMap`, `TreeMap`

Map<String, Integer> map = new HashMap<>();
map.put("apple", 3);
System.out.println(map.get("apple"));  // 3

5.3.6 셋 (Set)

✅ 셋이란?

중복을 허용하지 않는 데이터의 집합

하나의 값만 저장 (key만 있음, value는 없음)
주로 빠른 존재 여부 확인(membership test)에 사용

Set의 종류

자료구조	기반 구조	정렬	시간 복잡도
`set` (C++/Java)	이진 탐색 트리	O(log n)	정렬 O
`unordered_set` / `HashSet`	해시 테이블	O(1) 평균	정렬 X

예시

Python `set`

s = {"apple", "banana"}
s.add("cherry")
print("banana" in s)  # True

C++ `set`, `unordered_set`

set<int> s;
s.insert(10);
s.insert(20);

Java `HashSet`

Set<String> s = new HashSet<>();
s.add("apple");
s.contains("apple"); // true

5.3.7 해시 테이블 (Hash Table)

✅ 해시 테이블이란?

데이터를 해시 함수를 통해 고정된 인덱스 공간에 저장하는 구조
→ 평균 O(1)의 빠른 검색/삽입/삭제 가능

구성 요소

해시 함수: 키 → 해시값(정수) 변환
버킷(bucket): 데이터를 저장할 인덱스 공간
충돌 해결 로직: 같은 해시값에 여러 데이터가 맵핑될 경우를 처리

충돌 해결 방법

방식	설명	특징
체이닝 (Chaining)	같은 해시값에 연결 리스트로 저장	구현 쉬움, 공간 추가 필요
개방 주소법 (Open Addressing)	비어 있는 다음 슬롯 찾음	메모리 효율적, 클러스터링 문제 가능

해시 함수 충돌 예시 (비둘기집 원리)

hash("hello") → 42
hash("world") → 42

→ 서로 다른 입력이 동일한 인덱스로 매핑되는 현상 = 충돌

⏱️ 시간 복잡도

연산	평균	최악
삽입	O(1)	O(n)
삭제	O(1)	O(n)
검색	O(1)	O(n)

최악의 경우는 모든 키가 같은 해시값을 가질 때

핵심 비교 요약

자료구조	기반	키-값 쌍	중복	정렬	대표 연산
Map	트리 / 해시	O	키 중복 X	트리: O, 해시: X	get(key), put(key, value)
Set	트리 / 해시	X	값 중복 X	트리: O, 해시: X	contains(value), add(value)
Hash Table	해시	일반 구조	충돌 관리	X	빠른 검색

마치며

자료구조는 단순히 외워야 하는 목록이 아니라,

어떤 문제에 어떤 구조를 써야 할지 판단하는 사고 방식입니다.

이번 정리를 통해 각 자료구조의 목적과 특징, 시간 복잡도까지 흐름을 잡는다면

실제 프로젝트나 알고리즘 문제를 만났을 때
“왜 이 구조를 써야 하는가” 라는 질문에
스스로 답할 수 있도록 합니다.

앞으로는 문제를 풀기 전에 이렇게 생각해봅시다.

"이 데이터, 어떻게 저장하고 꺼내는 게 가장 효율적일까?"

샤딩 vs 파티셔닝, 무엇을 언제 선택해야 할까? – 데이터 분산 전략

readyoun — Wed, 9 Apr 2025 04:12:25 +0900

파티셔닝과 샤딩은 단순한 성능 향상을 위한 기술이 아닙니다.

이 글에서는 두 전략의 개념과 차이를 명확히 구분하고,
Airbyte, LINE 등 실무 사례를 통해 실제 기업들이 왜 각각의 전략을 선택했는지를 살펴봅니다.
마지막엔 분산 전략을 선택할 때 고려해야 할 판단 기준도 함께 정리했습니다.

1. 왜 분산 저장이 필요한가?

서비스가 성장하면서 점점 더 많은 사용자 요청과 데이터가 쌓이게 됩니다. 이때 단일 DB 인스턴스에 모든 데이터를 저장하고 조회하려고 하면 시스템이 감당하지 못하고 병목이 발생하게 됩니다. 그 병목은 성능 저하뿐 아니라, 운영 이슈, 데이터 정합성 문제로 이어질 수 있죠.

이 섹션에서는 왜 데이터를 분산시켜야 하는지 근본적인 이유부터 살펴봅니다.

문제 정의

서비스 이용자가 늘어나면, 데이터도 기하급수적으로 증가합니다.

(출처: simform)

단일 테이블(또는 DB 인스턴스)에서 모든 데이터를 처리하면 다음과 같은 병목이 발생합니다.

I/O 병목
인덱스 비대화
데이터 락 충돌

[더보기] I/O 병목, 인덱스 비대화, 데이터 락 충돌이란?

I/O 병목: 데이터가 많아지면 디스크에서 읽고 쓰는 속도가 느려짐 → 처리 속도 급격히 하락함
인덱스 비대화: 인덱스가 커지면 B-Tree 탐색 비용 증가, CPU 캐시 미스 증가 → 오히려 성능 저하
데이터 락 충돌: 동시성 트랜잭션이 많아질수록 row-level, table-level 락 충돌이 발생 → 대기/충돌 증가

[더보기] 데이터 분산 외 성능 최적화 전략은 뭐가 있을까?

읽기/쓰기 분리

Master-Slave 구조에서 쓰기는 Master, 읽기는 Read Replica로 분산 → 읽기 부하 분산

캐시 계층 도입

Redis, Memcached 등으로 자주 쓰는 데이터는 메모리에서 빠르게 응답 가능

CQRS 패턴

쓰기 연산과 읽기 연산을 분리해 각각 다른 저장소나 처리 흐름 사용 → 동시성 분리 효과

2. 파티셔닝이란?

대용량 데이터를 다루는 테이블에서는 단순한 인덱스 추가나 쿼리 튜닝만으로는 성능 개선이 한계에 부딪힙니다. 이때 활용할 수 있는 전략이 바로 파티셔닝(Partitioning) 입니다.

파티셔닝은 하나의 큰 테이블을 여러 개의 작은 단위로 나누어, 마치 독립적인 테이블처럼 관리할 수 있도록 해주는 기술입니다.

이는 쿼리 성능 향상, 관리 효율성 증대, 아카이빙 자동화 등 다양한 측면에서 효과를 발휘합니다.

개념부터 짚고 가기

논리적으로는 하나의 테이블이지만, 내부적으로는 여러 개의 파티션(partition)으로 구성되어 있음
각 파티션은 물리적으로는 별도의 저장 단위로 취급될 수 있으며, 조건에 따라 개별 접근 가능
DBMS가 파티션을 인식하고, 특정 조건에 따라 일부 파티션만 조회하는 최적화(Partition Pruning, 쿼리 시 필요한 파티션만 선택해서 읽는 동작)를 수행

파티셔닝을 왜 사용하는가?

파티셔닝은 단순한 성능 개선이 목적이 아닙니다.
데이터가 많아질수록 관리 측면에서의 이점이 훨씬 커집니다.

성능 향상: 조건 검색 시 불필요한 데이터 스캔 방지
보관/삭제 용이: 오래된 파티션만 DROP 가능
관리 단순화: 파티션 단위 백업/복구, 통계 수집 가능
데이터 분리 처리: 파티션별 병렬처리, 스케줄 관리 가능

수평 vs 수직 파티셔닝

horizontal

vertical

(출처: SQLShack)

파티셔닝은 크게 행 기준 수평 분할과 열 기준 수직 분할로 나뉩니다.

하지만 실무에서는 대부분 수평 파티셔닝이 사용됩니다.

구분	수평 파티셔닝	수직 파티셔닝
기준	Row 기준	Column 기준
예시	가입 연도별 회원 나누기	개인정보 / 활동 로그 분리
장점	쿼리 범위 축소	보안, 분리 저장
단점	파티션 수 증가 시 관리 부담	JOIN 필요성 증가

[더보기] 수직 파티셔닝은 왜 잘 안 쓰이는가?

수직 파티셔닝은 JOIN 비용 증가와 컬럼 선택성 저하 등으로 인해 잘 쓰이지 않습니다.
대부분의 쿼리가 SELECT * 구조를 가질 경우, 분리된 테이블을 다시 조인해야 하며,
이로 인해 오히려 성능이 악화되는 경우도 있습니다.

파티션 방식: 어떤 기준으로 나눌까?

파티셔닝은 데이터를 나누는 방식에 따라 아래와 같이 구분됩니다.

방식	기준 예시	특징 및 장단점
범위(RANGE)	가입일 기준	시간순 데이터 분할에 적합, 직관적
목록(LIST)	지역 코드	정해진 카테고리 그룹화에 유리
해시(HASH)	해시 함수	균등 분산에 유리, 범위 쿼리에 부적합
키(KEY)	PK 또는 유니크 키	DBMS가 내부적으로 HASH와 유사 처리

[더보기] 파티션과 인덱스는 어떻게 작동할까?

파티셔닝이 적용된 테이블에서 인덱스를 사용하려면 조건절이 파티션 키를 포함해야 합니다.
그렇지 않으면 파티션을 모두 스캔하는 Full Scan이 발생할 수 있습니다.

-- 파티션 키인 created_at이 조건에 포함된 경우
SELECT * FROM orders WHERE created_at >= '2024-01-01';

-- 파티션 키가 아닌 경우
SELECT * FROM orders WHERE user_id = 1001;

이처럼 Partition Pruning이 작동하려면 파티션 키와 쿼리 조건이 일치해야 합니다.

3. 샤딩이란?

대규모 사용자 트래픽과 급증하는 데이터 볼륨을 감당하기 위해, 단일 데이터베이스로는 더 이상 충분하지 않은 상황이 많아졌습니다. 이럴 때 사용하는 대표적인 분산 저장 방식이 바로 샤딩(Sharding) 입니다.

샤딩은 하나의 데이터베이스 테이블이 아니라, 전체 DB를 여러 개로 나누어 데이터 부하를 분산시키는 구조입니다.

기본적으로 샤딩은 하나의 논리적 데이터셋을 여러 DB 인스턴스에 분산 저장해 병렬성(Parallelism) 과 확장성(Scalability) 을 확보하려는 목적을 갖습니다.

이를 통해 성능 개선뿐 아니라, 장애 격리, 글로벌 리전 운영 등의 장점을 가져올 수 있습니다.

️ 샤딩의 기본 구조

샤딩은 단순히 데이터를 나누는 것을 넘어, 어떻게 나눌지(Shard Key), 어디에 저장할지(Shard), 어떻게 보내고 조회할지(Router) 가 함께 설계되어야 합니다.

구성 요소	역할
Shard	데이터를 실제로 저장하는 DB 인스턴스 (물리적 분산 단위)
Shard Key	데이터를 어떤 샤드로 보낼지 결정하는 기준 값
Router	클라이언트의 쿼리를 알맞은 샤드로 라우팅해주는 계층 (앱/미들웨어/DB 자체)

예: user_id를 기준으로 샤딩한다면, user_id % 3의 결과에 따라 3개의 샤드로 나뉘어 저장됩니다.

routing via mongos

(출처: MongoDB Docs)

샤딩 전략 – 데이터를 어떤 기준으로 나눌 것인가?

range-based ex

(출처: TiDB Sharding Guide)

샤딩은 “샤드 키를 기준으로 어떤 방식으로 데이터를 나눌지”에 따라 크게 4가지 전략으로 구분됩니다.

각 전략은 균등성, 확장성, 유연성 측면에서 트레이드오프가 존재합니다.

전략	기준	장점	단점	예시
Range-based	키의 범위	설계 간단, 직관적	Hotspot 위험	`user_id 1~1000 → A`
Key-based (Hash)	해시 함수	균등 분산	샤드 추가 어려움	`hash(user_id) % N`
Directory-based	매핑 테이블	유연함, 동적 구성 가능	매핑 테이블 관리 필요	`lookup(user_id)`
Geographic-based	사용자 위치 등 지역	지연 최소화, 규제 대응	글로벌 동기화 어려움	`EU → Shard_EU`

[더보기] 샤딩은 어디서 처리하는가?

샤딩은 그 로직을 어디에서 처리하느냐에 따라 다음과 같이 나뉘며, 시스템 설계에 큰 영향을 줍니다:

애플리케이션 레벨: 개발자가 직접 샤딩 로직 작성 (가장 유연하지만 복잡도 ↑)
DBMS 레벨: MongoDB, Citus처럼 DB 자체에서 샤딩 처리 지원
미들웨어 레벨: ProxySQL, mongos 등 중간 계층에서 라우팅 담당

이 구현 위치에 따라 장애 대응, 확장성, 개발 난이도가 달라지므로 사전 검토가 필수입니다.

application level sharding - 앱에서 샤드 키 기준으로 분기 처리

출처: DataGeek.blog

[더보기] 분산된 데이터를 어떻게 일관되게 다룰까?

샤딩된 환경에서는 데이터가 여러 DB 인스턴스에 분산되어 저장되기 때문에,
어디서든 같은 데이터를 보고, 동일한 결과를 얻는 것이 어려워질 수 있습니다.
이런 상황에서는 일관성을 직접 유지할 수 있는 전략적 설계가 필요합니다.

일관성을 유지하기 위한 전략

전략	설명	장점	단점
2PC (Two-Phase Commit)	두 단계로 Commit 전송	강한 일관성	락 오래 잡음, 실패 시 복잡
SAGA 패턴	보상 트랜잭션 기반 순차 처리	마이크로서비스에 적합	중간 실패 보상 로직 필요
Eventual Consistency	시간차 동기화 허용	고가용성 확보	중간 상태 노출 가능
메시지 큐 기반 이벤트 처리	Kafka, RabbitMQ 등으로 분산 동기화	비동기 처리 구성 가능	재처리, 순서 보장 필요

파티셔닝과 비교하자면,

항목	파티셔닝	샤딩
분산 범위	단일 DB 내부	여러 DB 인스턴스
일관성 유지	DBMS가 자동 보장	애플리케이션 또는 설계자가 직접 보장
트랜잭션/제약 조건	자유롭게 가능	제약 있음, 직접 구현 필요

파티셔닝은 “일관성 유지가 기본값”인 구조고,
샤딩은 “일관성을 유지하기 위한 전략이 필요”한 구조입니다.

4. 파티셔닝 vs 샤딩 – 핵심 비교 요약

파티셔닝과 샤딩은 모두 데이터를 나눠서 처리 부하를 줄이고 성능을 개선하기 위한 전략이지만,
그 적용 범위와 목적, 설계 관점은 완전히 다릅니다.

(출처: PingCAP / TiDB Docs)

파티셔닝은 DBMS 내부에서 하나의 테이블을 분할하는 방식으로,
쿼리 성능을 향상시키고 관리 편의성을 높이는 데 초점을 맞춥니다.

반면, 샤딩은 전체 데이터베이스 인스턴스를 수평으로 분산시키는 구조적 설계로,
서비스가 커지면서 생기는 트래픽과 저장소 확장의 한계를 넘어가기 위한 선택입니다.

개념 비교

항목	파티셔닝	샤딩
정의	테이블을 내부적으로 나누는 구조	DB 인스턴스 자체를 수평 분산
단위	행(row), 열(column) 기준	DB 또는 테이블 단위
목적	쿼리 성능 최적화, 관리 효율화	확장성 확보, 시스템 부하 분산
적용 위치	단일 DB 내부	여러 DB 인스턴스
트랜잭션, JOIN	거의 모든 기능 지원	제한적, 추가 설계 필요
정합성 / 일관성	DBMS가 보장	설계자가 직접 유지해야 함

언제 파티셔닝을 고려할까?

단일 테이블이 너무 커서 쿼리가 느려진다
시간 순 데이터가 많아 오래된 데이터를 주기적으로 제거해야 한다
특정 조건(날짜, 지역 등)으로 자주 조회되는 쿼리가 있다
아직 단일 DB 인스턴스에서 충분히 운영 가능하다

예시:
월별 로그 데이터를 조회하는 서비스에서는 created_at을 기준으로 RANGE 파티셔닝을 적용하면
오래된 데이터는 DROP으로 쉽게 제거하고, 최신 데이터만 빠르게 조회 가능해집니다.

언제 샤딩을 고려할까?

단일 DB 인스턴스가 더 이상 감당할 수 없는 수준까지 데이터가 증가했다
동시에 많은 사용자의 요청을 처리해야 한다
글로벌 리전에 따라 데이터를 나눠야 한다
서로 다른 데이터 도메인을 분리해서 관리하고 싶다 (ex. 고객 vs 주문)

예시:
전 세계 유저를 보유한 소셜 플랫폼에서는 사용자 ID 기준으로 샤딩을 하면
각 지역 사용자 데이터를 지역별 샤드에 분산시켜
빠른 응답 속도와 리전 내 저장을 동시에 달성할 수 있습니다.

⚖️ 함께 쓰는 경우도 많다!

실무에서는 파티셔닝과 샤딩을 혼합하여 사용하는 경우도 많습니다.

예:
샤드 A → 2023년 테이블 → 월별 파티셔닝
샤드 B → 2024년 테이블 → 월별 파티셔닝

즉, 샤딩은 저장소와 시스템 확장을 위한 구조이고,
파티셔닝은 각 샤드 내부에서 쿼리 성능을 높이기 위한 수단으로 함께 쓰이는 거죠.

5. 실무 사례와 함께 이해하기

실제로 기업들은 단순히 "데이터가 많아졌기 때문"이 아니라,
데이터의 특성, 사용 패턴, 시스템 구조를 종합적으로 고려해
파티셔닝과 샤딩을 전략적으로 선택하고 있습니다.

Airbyte, LINE 사례를 통해
어떤 상황에서 어떤 분산 전략이 선택되었고,
그로 인해 어떤 아키텍처 구조가 만들어졌는지를 살펴보겠습니다.

Airbyte – ETL(Extract → Transform → Load) 파이프라인에서의 파티셔닝 활용

“단순한 쿼리 성능이 아니라, 병렬 처리와 증분 적재의 효율성을 높이기 위해 파티셔닝을 선택한 사례”

*데이터 적재(Load): 외부에서 데이터를 끌어와서 데이터베이스에 저장하는 작업
*증분 적재(Incremental Load): 전체 데이터를 다시 넣는 게 아니라, “변경되거나 새로 추가된 데이터만” 적재하는 방식

(출처: Airbyte)

원문 보기

Airbyte는 대규모 데이터를 처리하는 ETL 파이프라인 도구입니다.
데이터를 끊임없이 추출, 변환, 적재해야 하는 환경에서 파티셔닝은 다음과 같은 효과를 가져왔습니다.

created_at 기준 RANGE 파티셔닝 → 시간 단위로 데이터를 나누고 관리
각 파티션을 병렬로 처리하여 전체 작업 시간 단축
특정 기간 데이터만 적재하는 증분 로딩(incremental load) 구조와 매우 잘 어울림

✅ 이처럼, 읽기 쿼리 최적화 외에도 데이터 적재 흐름에도 파티셔닝은 강력한 전략이 될 수 있습니다.

LINE – LINE Manga의 샤딩 구조 설계

“국내 대형 서비스에서 샤딩을 애플리케이션 단에서 직접 구현한 대표 사례”

원문 보기

LINE Manga는 수많은 만화 콘텐츠와 사용자 트래픽을 처리하는 대형 서비스입니다.
LINE은 다음과 같은 방식으로 샤딩을 도입했습니다:

manga_id 기준 Key-based Sharding → 특정 작품 데이터가 한 샤드에 집중
애플리케이션 레벨에서 라우팅 구현 → getShardKey(id) 함수로 직접 분산
특정 샤드에 장애 발생 시, 비동기 큐를 활용한 재시도 메커니즘도 함께 설계

✅ 이 사례는 단순한 샤딩이 아닌, 운영 장애 대응 + 샤드 로직 유연성 확보까지 함께 고려한 구조입니다.

LinkedIn 커뮤니티 – 선택 기준 정리와 조언

“정답을 알려주는 것이 아니라, 선택 기준을 어떻게 구성해야 하는지 알려주는 사례”

커뮤니티 조언 보기

LinkedIn의 기술 커뮤니티에서는 다음과 같은 기준을 추천합니다:

단일 인스턴스로 운영 가능하면 파티셔닝을 먼저 고려
쿼리 패턴이 단일 키에 집중되어 있다면 샤딩이 더 효과적
시스템 복잡도 vs 개발 효율 vs 확장성의 균형을 고려해야 함
NoSQL에서는 파티셔닝과 샤딩이 개념적으로 겹칠 수 있음 (→ Mongo, Cassandra 등)

✅ 이 조언은 실제 선택 상황에서 “무조건 이게 정답”이 아니라,
상황별 우선순위를 고려해야 한다는 점을 잘 알려줍니다.

실무에서는 "둘 중 무엇?"보다
"언제, 어떻게 함께 쓸 것인가"가 훨씬 더 중요한 질문일 수 있습니다.

6. 마무리 – 언제, 어떤 전략을 선택할 것인가?

데이터가 많아진다고 무조건 샤딩하거나, 느려진다고 무작정 파티셔닝을 하는 건 올바른 접근이 아닙니다.

파티셔닝과 샤딩은 각각의 목적과 효과가 다르며,
쿼리 패턴, 시스템 구조, 확장성 요구사항, 데이터 정합성/일관성 보장 수준 등을 함께 고려해 판단해야 합니다.

❓ 이런 질문부터 시작해보세요

지금 문제가 되는 건 읽기 성능인가요, 쓰기 부하인가요?
→ 읽기라면 파티셔닝, 쓰기 트래픽이면 샤딩
데이터 크기가 커졌나요, 트래픽(요청 수)이 많아졌나요?
→ 데이터 크기엔 파티셔닝, 트래픽엔 샤딩
데이터는 시간순으로 정리되나요? 주기적으로 삭제되나요?
→ RANGE 파티셔닝 고려
시스템은 아직 단일 DB로 충분한가요?
→ 충분하면 파티셔닝, 부족하면 샤딩
서로 다른 도메인을 물리적으로 나눌 필요가 있나요?
→ 샤딩 or 기능적 샤딩 고려
모든 데이터가 즉시 일관성을 유지해야 하나요?
→ 그렇다면 파티셔닝, 약간의 지연 허용되면 샤딩 가능

선택 가이드: 언제 어떤 전략을?

상황	선택 전략
테이블 하나가 너무 커서 쿼리가 느려진다	✅ 파티셔닝 (RANGE or LIST)
날짜별/지역별로 자주 조회된다	✅ 파티셔닝 (Partition Pruning 유도)
사용자가 수백만 명, 요청이 초당 수천 건 이상	✅ 샤딩 (Key-based, Geo-based)
글로벌 사용자 대상으로 리전 분산 필요	✅ 샤딩 (Geo-based + App Routing)
시스템을 수평 확장하고 싶다	✅ 샤딩
데이터는 많지만 DB는 하나로 유지하고 싶다	✅ 파티셔닝
둘 다 필요하다	✅ 혼합 전략 (샤딩 + 파티셔닝 병행)

선택 기준 요약

작은 데이터지만 쿼리 최적화가 필요하다 → 파티셔닝
시스템 부하를 나눠야 한다 → 샤딩
성능 개선이 아니라 확장이 목적이다 → 샤딩
JOIN이 중요하고 정합성/일관성이 핵심이다 → 파티셔닝

핵심은 '언제 어떤 전략을 도입해야 할까?'보다,
'왜 이 전략이 필요한가'를 명확히 이해하는 것입니다.

찾아보면서 늘 그렇듯, 분산 전략은 단순한 기능이 아니라
서비스 성장 단계에서의 아키텍처 결정인 점을 배웠습니다.

✅ TL;DR

파티셔닝은 단일 DB 안에서 테이블을 나누는 방식 (논리적 분산)
샤딩은 DB 자체를 여러 개로 분산 저장하는 방식 (물리적 분산)
파티셔닝은 관리와 성능, 샤딩은 확장성과 병렬성에 초점
실무에서는 함께 쓰이기도 하고, 상황에 따라 선택 기준이 다름

참고자료

Airbyte: What Is Data Partitioning: Types, Techniques, & Examples
LINE: LINE Manga 데이터베이스 샤딩 – 서버 엔지니어 편
LinkedIn: Sharding in RDBMS vs NoSQL – Vagdevi Kommineni
LinkedIn: Best practices for data sharding and partitioning
System Design School: Sharding vs Partitioning
Chat2DB: Database Sharding: How It Works and Its Benefits
Chat2DB: Sharding vs Partitioning: A Comprehensive Guide to Key Database Optimization Techniques
DEV.to: Sharding vs. Partitioning vs. Replication
Yugabyte: Four Data Sharding Strategies We Analyzed in Building a Distributed SQL Database

NoSQL의 모든 것: 개념, 종류, MongoDB와 Redis 맛보기

readyoun — Tue, 8 Apr 2025 00:07:25 +0900

https://www.mongodb.com/ko-kr/resources/basics/databases/nosql-explained

1. 개요: 왜 NoSQL인가?

프로젝트에서 대용량 데이터를 다루거나 수평적 확장이 필요한 상황이라면, RDBMS 대신 NoSQL을 검토해본 적이 있을 것입니다.

NoSQL의 의미
NoSQL은 'Non-SQL' 또는 'Not only SQL'로 해석되며,
SQL처럼 특정 쿼리 언어를 지칭하는 것이 아닌
새로운 데이터베이스 패러다임을 의미합니다.

전통적인 관계형 데이터베이스의 제약에서 벗어나
데이터를 더 자유롭고 유연한 형태로 저장하고 관리하는 접근 방식입니다.

이 글에서는 NoSQL의 주요 네 가지 종류를 구체적으로 비교하고,

왜 NoSQL이 주목받는지, MongoDB와 Redis의 기본 사용법까지 실습 방법을 공유합니다.

참고: 이 글은 『이것이 취업을 위한 컴퓨터 과학이다』 CHAPTER 06, p.605 ~ p.620의 내용을 기반으로 한 설명입니다.

2. RDBMS vs NoSQL: 무엇이 다른가?

관계형 데이터베이스(RDBMS)는 정형 데이터, 스키마 고정, ACID 트랜잭션을 강점으로 삼습니다.

하지만 대규모 사용자 요청과 다양한 형태의 비정형 데이터를 처리하기엔 한계가 있습니다.

반면, NoSQL은 다음과 같은 특성을 가집니다.

스키마 유연성: 구조가 자유로워 다양한 형태의 데이터를 저장 가능
수평적 확장성: 서버를 늘려 성능 개선
고가용성: 장애 발생 시 빠른 복구 가능
ACID보다는 BASE(Basically Available, Soft state, Eventual consistency) 지향

생각해보기
NoSQL이라는 용어는 단순히 "SQL이 아닌"이라는 의미를 넘어서,

어떤 특별한 가치와 장점을 제공할까요?

RDBMS와 비교했을 때 가장 두드러지는 차이점은 무엇일까요?

☞ 관계형 데이터베이스는 테이블 기반의 구조로서 스키마가 고정되어 있는 반면, 비관계형 데이터베이스인 NoSQL 데이터베이스는 데이터의 저장 및 관리를 위해 고정된 스키마가 없고, 수평 확장이 용이한 구조를 가지고 있습니다. NoSQL 데이터베이스는 키-값, 도큐먼트, 칼럼 패밀리, 그래프 등의 다양한 형태로 저장할 수 있습니다.

3. NoSQL의 네 가지 대표 유형

3.1 키-값(Key-Value) 데이터베이스

대표 사례: Redis, Memcached
구조: 단순히 키(key)와 값(value)으로 구성
특징:
- 매우 빠른 읽기/쓰기 속도
- 대부분 인메모리(in-memory) 기반으로 동작 → 디스크보다 빠름
- 단순 조회에 적합하지만, 복잡한 쿼리는 부적합

인메모리 DB란?
데이터를 디스크가 아닌 RAM에 저장하여 초고속으로 접근 가능한 DB입니다. Redis, Memcached가 대표적입니다.

생각해보기
인메모리 데이터베이스는 데이터를 메모리에 저장하므로 재시작 시 데이터가 손실될 수 있습니다.

그렇다면 Redis와 같은 인메모리 DB들은 이 문제를 어떻게 해결할까요?

☞ Redis는 RDB(Redis Database) 스냅샷과 AOF(Append Only File) 방식을 통해 데이터 영속성을 보장합니다. RDB는 특정 시점의 데이터를 디스크에 저장하고, AOF는 모든 쓰기 명령을 로그로 저장하여 재시작 시 데이터를 복구할 수 있게 합니다.

3.2 도큐먼트(Document) 데이터베이스

대표 사례: MongoDB
구조: JSON 또는 BSON 형식의 도큐먼트 단위로 저장
특징:
- 도큐먼트 하나가 하나의 레코드를 구성
- 필드마다 타입이 달라도 저장 가능 (스키마 유연성)
- 중첩된 데이터(배열, 객체) 구조도 표현 가능

MongoDB는 NoSQL의 대표 주자로, RDBMS의 테이블 → 컬렉션, 행 → 도큐먼트로 대응됩니다.

p.606

생각해보기

MongoDB는 스키마가 자유롭다고 하지만, 완전히 제약이 없는 것은 아닙니다.

데이터의 일관성과 유효성을 어떻게 보장할 수 있을까요?

☞ MongoDB는 JSON Schema 검증, 인덱싱, 애플리케이션 레벨의 검증 로직을 통해 데이터 일관성을 유지할 수 있습니다. 특히 MongoDB 3.6 버전부터는 컬렉션 레벨에서 스키마 검증을 설정할 수 있어, 필요한 경우 RDBMS처럼 엄격한 스키마 제약도 가능합니다.

3.3 그래프(Graph) 데이터베이스

wikipedia 그래프 데이터베이스

대표 사례: Neo4j
구조: 노드(Node)와 간선(Edge)으로 구성된 방향 그래프
특징:
- 노드 간 관계를 빠르게 탐색 가능
- 소셜 미디어 친구 관계, 교통망, 추천 시스템 등 관계형 데이터에 적합
- 복잡한 JOIN을 단순한 그래프 탐색으로 대체

그래프 구조의 핵심은 노드 간 연결 관계를 직접 저장하고 탐색할 수 있는 성능에 있습니다.

생각해보기

소셜 미디어나 추천 시스템에서 그래프 데이터베이스가 RDBMS보다 효율적인 이유는 무엇일까요?

☞ 예를 들어 "친구의 친구 찾기"와 같은 기능을 구현할 때, RDBMS에서는 여러 번의 JOIN 연산이 필요하지만, 그래프 DB에서는 노드 간 관계를 직접 탐색할 수 있어 매우 효율적입니다. 특히 LinkedIn과 같은 소셜 네트워크에서 "n차 연결" 기능을 구현할 때 그래프 DB의 장점이 두드러집니다.

why?

그래프 데이터베이스가 SNS나 추천 시스템에서 RDBMS보다 효율적인 이유는 데이터 탐색 방식과 데이터 모델링의 유연성에 있습니다. RDBMS에서는 "친구의 친구"를 찾기 위해 여러 번의 JOIN 연산을 수행해야 하며, 탐색 깊이가 깊어질수록 계산량이 기하급수적으로 증가합니다.

반면, 그래프 데이터베이스는 노드(사용자)와 엣지(관계)를 물리적으로 연결된 상태로 저장하여 직접 포인터를 따라 탐색하므로 탐색 복잡도가 선형적으로 증가(O(n))하며 매우 빠릅니다. 또한 그래프 DB는 스키마가 없거나 유연한 구조를 제공해 새로운 관계 유형을 쉽게 추가할 수 있고, 엣지에 가중치나 속성을 저장하여 추천 시스템에서 고급 분석을 가능하게 합니다.

특히 LinkedIn과 같은 소셜 네트워크에서 "n차 연결" 기능을 구현할 때:

그래프 DB는 엣지를 따라 실시간으로 관계를 탐색할 수 있어 대규모 연결 데이터를 효율적으로 처리할 수 있으며, 그래프 알고리즘(PageRank, 최단 경로 등)을 활용해 사용자 간 관계망 분석이나 추천을 최적화할 수 있습니다.

이러한 이유로 SNS와 추천 시스템에서 그래프 데이터베이스는 RDBMS보다 더 적합한 선택입니다.

3.4 칼럼 패밀리(Column Family) 데이터베이스

대표 사례: Cassandra, HBase
구조: 행(Row)과 열(Column) 구조를 가지지만 스키마 고정 X
특징:
- 각 행마다 다른 열을 가질 수 있음
- 정규화나 JOIN 없이 사용 (데이터 중복을 허용)
- 대규모 쓰기/읽기에 강한 성능

"칼럼 패밀리"란 연관된 열들을 묶어 저장하는 단위입니다. 한 패밀리 안에서 열 구조는 유연하게 변할 수 있습니다.

p.608

생각해보기

빅데이터 처리에서 칼럼 패밀리 데이터베이스가 선호되는 이유는 무엇일까요? 특히 데이터 압축과 조회 성능 측면에서 생각해봅시다.

☞ 데이터 저장 방식과 효율적인 읽기 성능 이점

칼럼 패밀리 DB는 데이터를 행(row) 단위가 아닌 열(column) 단위로 저장합니다. 같은 유형의 데이터를 물리적으로 인접하게 저장하므로, 데이터 압축 효율이 매우 높아지고 저장 공간을 절약할 수 있습니다. 예를 들어, 동일한 열에 반복적으로 나타나는 값(예: 센서 데이터의 상태 플래그)을 효과적으로 압축할 수 있습니다.

또한, 칼럼 단위로 데이터를 읽기 때문에 필요한 열만 선택적으로 조회할 수 있어 입출력(IO) 성능이 크게 향상됩니다. 이는 특히 대규모 데이터셋에서 일부 열만 자주 읽는 경우(예: 로그 분석에서 특정 필드만 조회) 매우 유리합니다. 이러한 특성 덕분에 칼럼 패밀리 DB는 센서 데이터, 로그 데이터, 시계열 데이터와 같이 대규모로 생성되고 특정 열에 집중된 분석이 필요한 빅데이터 처리에 적합합니다.

4. NoSQL을 선택하는 이유

NoSQL은 다음과 같은 상황에서 선택합니다.

조건	RDBMS	NoSQL
데이터 정형성	높음	낮음
트랜잭션 무결성(ACID)	중요	덜 중요
수평적 확장 필요 여부	낮음	높음
데이터 관계 복잡성	높음	낮음~중간
빠른 읽기/쓰기 성능	일반적	매우 빠름
유연한 구조의 데이터 처리 필요	부족	매우 유연

⚠️ ACID를 아예 포기하는 것은 아닙니다. MongoDB, Cassandra 등은 상황에 따라 ACID 일부를 지원하거나 옵션으로 제공합니다.

생각해보기

데이터베이스 선택은 프로젝트의 성공을 좌우하는 중요한 결정입니다.

NoSQL과 RDBMS는 각각 어떤 상황에서 더 적합할까요?

NoSQL 데이터베이스는 대규모의 비정형 데이터를 처리할 때, 높은 확장성과 빠른 읽기/쓰기 성능이 필요할 때 유리합니다.

그러나 엄격한 트랜잭션 관리나 데이터 일관성 보장, 관계형 데이터 모델링이 필요한 애플리케이션에서는

관계형 데이터베이스가 더 적합하므로 NoSQL 데이터베이스는 불리할 수 있습니다.

5. 실습으로 이해하는 NoSQL

실습 전 준비
환경 설정은 강태공 GitHub 실습 자료를 참고해주세요.
MongoDB와 Redis 모두 로컬 혹은 Docker로 손쉽게 구성할 수 있습니다.

5.1 MongoDB 실습 요약

MongoDB에서 레코드는 도큐먼트 단위로 저장됩니다. 도큐먼트가 모여 컬렉션이 되고, 컬렉션이 모여 데이터베이스를 구성합니다.

# 데이터베이스 및 컬렉션 생성
use mydb
db.createCollection("mycollection")

# 단일 도큐먼트 삽입
db.mycollection.insertOne({ name: "Robin", age: 28 })

# 다중 도큐먼트 삽입
db.mycollection.insertMany([{ name: "Ash" }, { name: "Hanna" }])

# 도큐먼트 조회
db.mycollection.find()

여기서 잠깐! MongoDB의 주요 연산자 정리

MongoDB는 $set, $inc, $push, $pull 등 연산자를 통해 도큐먼트 내부 필드를 유연하게 갱신할 수 있습니다. SQL의 UPDATE SET과 유사하지만, JSON 구조를 직접 조작한다는 점에서 차별화됩니다.

(p.612)

Tip

$set과 $eq는 거의 모든 MongoDB 작업에서 사용됩니다
$in은 여러 조건을 한 번에 처리할 때 매우 유용합니다
$inc는 카운터나 통계 처리에 필수적입니다
배열 처리는 $push와 $pull이 가장 기본입니다

5.2 Redis : 빠르고 유연한 인메모리 데이터베이스

Redis는 Remote Dictionary Server의 약자로, 인메모리 기반의 키-값 데이터베이스입니다.

모든 데이터를 RAM에 저장하여 초고속 성능을 제공하며,

데이터베이스, 캐시(Cache), 메시지 브로커, 세션 관리, 실시간 데이터 분석 등 다양한 용도로 활용됩니다.

Asim Hafeez - Redis and Its Data Structures

Redis는 단순한 키-값 저장소를 넘어

문자열(String), 리스트(List), 해시(Hash), 집합(Set), 정렬된 집합(Sorted Set) 등

다양한 자료구조를 지원하여 애플리케이션의 요구사항에 유연하게 대응할 수 있습니다.

# 문자열 저장 및 조회
SET username "Robin"
GET username

# 리스트 연산
LPUSH tasks "task1"
RPUSH tasks "task2"
LRANGE tasks 0 -1  # 전체 리스트 조회

참고 : REDIS- -데이터-타입Collection-종류-정리

p.616

이러한 구조 덕분에 Redis는 지연 시간이 중요한 애플리케이션에서 널리 사용되며,

대규모 트래픽 환경에서도 안정적으로 작동합니다.

장점: 빠른 속도와 유연성

데이터를 디스크가 아닌 RAM에 저장하기 때문에

읽기 및 쓰기 작업이 마이크로초 단위로 처리되며,

초당 수백만 건의 요청을 처리할 수 있습니다.

또한, Redis는 아래 3가지를 지원해 확장성과 고가용성을 제공합니다.

데이터 복제(Replication)
영속성(Persistence)
클러스터링(Clustering)

Redis 활용 사례

Redis는 빠른 속도와 유연한 자료구조 덕분에 다음과 같은 다양한 상황에서 활용됩니다.

캐싱: 웹 애플리케이션에서 자주 조회되는 데이터를 저장하여 응답 시간을 단축.
메시지 브로커: Pub/Sub 기능을 활용해 실시간 알림 시스템 구현.
세션 관리: 사용자 로그인 세션을 관리하여 빠르게 접근 가능.
실시간 분석: 로그 데이터나 센서 데이터를 처리하여 실시간 통계를 제공.
순위표 및 리더보드: 정렬된 집합(Sorted Set)을 활용해 실시간 순위 계산.

생각해보기

많은 기업들이 Redis를 캐시 시스템으로 활용하고 있습니다.

Redis의 어떤 특성이 캐시 서버로서 특별한 가치를 제공하는 걸까요?

사용자의 로드 시간이 적을수록 전환율이 높습니다.

그런데 Redis는 인메모리 데이터베이스이기 때문에 디스크 접근 시간을 단축할 수 있습니다.

또한 Redis는 여러 자료구조를 지원하는 키-값 데이터베이스로써,

RDBMS보다 정형화되어 있지 않은 데이터에 대한 빠른 입출력이 가능합니다.

따라서 RDBMS 등을 주요 데이터베이스로 삼고,

Redis를 캐시 역할을 수행하는 부차적인 데이터베이스로 삼으면

주요 데이터베이스의 입출력 성능을 상당 부분 보강할 수 있습니다.

Redis와 캐싱 패턴

캐싱은 시스템의 성능을 향상시키는 가장 쉬운 방법이라고 합니다.

Redis는 특히 캐시(Cache)로 자주 사용되며, 다양한 캐싱 전략 패턴이 있습니다.

Static/Dynamic Caching : 데이터 변경 가능성과 일관성 유지 여부 기준
- Static: 읽기 전용, 변경 불가 → Cache-Aside, Write-Around.
- Dynamic: 읽기/쓰기 가능, 변경 가능 → Write-Through, Write-Back.
캐싱 전략 패턴 : 데이터 처리 흐름 기준
- Cache-Aside: 필요할 때만 캐시 사용. 가장 일반적.
- Write-Through: 실시간으로 캐시와 DB 동기화.
- Write-Around: 쓰기는 DB에만, 읽기는 캐시에서.
- Write-Back: 쓰기는 먼저 캐시에, 이후 비동기로 DB에 반영.
- Read-Through: 읽기를 자동으로 처리하며 필요 시 DB에서 가져옴.

참고

- https://minnseong.tistory.com/49

- https://velog.io/@zenon8485/%EC%BA%90%EC%8B%B1%EC%A0%84%EB%9E%B5

6. 마무리 및 배운 점

NoSQL은 단순히 RDBMS의 대체재가 아닌, 특정 문제에 특화된 대안
정형 데이터, 트랜잭션 중심이면 여전히 RDBMS가 우위
반면, 유연성, 확장성, 속도가 중요하면 NoSQL이 탁월
MongoDB와 Redis의 기본 동작 원리를 알아봄

Tip: 실제 프로젝트에서는 RDBMS와 NoSQL을 혼합하여 사용하는 하이브리드 구조도 많이 사용됩니다.

7. 참고 자료

『이것이 취업을 위한 컴퓨터 과학이다』 CHAPTER 06, p.605 ~ p.620
MongoDB - NoSQL이란 무엇입니까?
- sql vs nosql : https://www.mongodb.com/ko-kr/resources/basics/databases/nosql-explained/nosql-vs-sql
- types: https://www.mongodb.com/resources/basics/databases/types
큰돌의터전 - MySQL과 MongoDB의 완벽한 비교
쉬운코드 - BJ.53 NoSQL 설명!! RDB와는 어떤 차이가 있는지도 설명!! MongoDB, Redis 매우 간단한 예제 포함!!
Simply Explained - How do NoSQL databases work? Simply Explained!
Anton Putra - Types of Databases: Relational vs. Columnar vs. Document vs. Graph vs. Vector vs. Key-value & more
Awesome - The Fascinating History of Databases
F-Lab 스프링 부트와 레디스를 활용한 캐싱 전략

더 알아보기

CAP 이론과 NoSQL의 일관성 모델: Eventually Consistent란?
Redis의 TTL(Time to Live)과 만료 처리 전략
MongoDB의 인덱싱 구조와 복합 인덱스 설계

정규화(Normalization): 중복 없는 데이터베이스 설계 (1NF - BCNF)

readyoun — Mon, 7 Apr 2025 16:55:17 +0900

정규화 단계 정리

1. 개요

데이터베이스 설계를 하다 보면, 모든 정보를 한 테이블에 넣고 싶어질 때가 있어요. 그런데 그렇게 만들면 어떤 문제가 생길까요?

데이터가 중복되고
수정할 때 실수하고
삭제했더니 같이 날아가고

이런 문제를 막기 위해 등장한 게 바로 정규화(Normalization) 입니다.

정규화는 테이블을 잘게 나누고, 각 속성을 적절한 자리에 배치해서 데이터의 무결성과 유지보수성을 높이는 설계 방식입니다.

정규화를 하면 단순히 중복만 줄이는 게 아니라,

데이터 일관성(consistency) 유지
삽입/삭제/수정 이상(Anomaly) 방지
테이블 구조가 더 확장성 있게 설계됨

같은 이점이 있습니다.

참고: 이 글은 『이것이 취업을 위한 컴퓨터 과학이다』 CHAPTER 06, p.593 ~ p.604의 내용을 기반으로 한 설명입니다.

2. 정규화 핵심 용어 쉽게 풀어보기

용어	쉽게 설명하면…
함수 종속 (A → B)	하나를 알면 다른 게 자동으로 결정돼요. (예: 학번 → 이름)
부분 함수 종속	키가 여러 개인데, 그 중 일부에만 종속됨 (예: 학번+과목이 키인데 이름은 학번만으로도 알 수 있음)
이행 함수 종속	중간 단계를 거쳐 종속됨 (예: 과목 → 교수 → 사무실)
후보 키	기본키로 쓸 수 있는 후보들 (예: 주민번호, 이메일 등)
결정자	다른 값을 결정짓는 열 (예: 학번이 이름의 결정자)

3. 제1정규형 (1NF) - 원자값으로만 구성하기

책 용어

제1정규형이란, 모든 속성이 원자값(Atomic Value) 만 가지도록 구성한 테이블입니다.

쉽게 말하면

하나의 칸에 값이 두 개 이상 들어가면 안 된다는 뜻이에요!

❗ 문제 예시

학번	이름	수강 과목	담당 교수
1	김현수	운영체제, 데이터베이스	김교수, 이교수

✅ 해결 후 (1NF)

학번	이름	수강 과목	담당 교수
1	김현수	운영체제	김교수
1	김현수	데이터베이스	이교수

4. 제2정규형 (2NF) - 부분 함수 종속 제거

책 용어

제2정규형은 제1정규형을 만족하고, 기본키의 일부에만 종속된 속성이 없어야 합니다.

쉽게 말하면

키의 ‘일부’만 알아도 값이 정해지는 관계라서 ‘부분’ 종속이라고 불러요.

테이블의 기본키가 두 개일 때, 그 중 하나만 알아도 알 수 있는 값은 따로 빼줘야 합니다.

❗ 문제 예시

학번	이름	과목	성적
1001	김현수	국어	90

여기서 (학번 + 과목)이 기본키인데, 이름은 학번만으로도 알 수 있죠. 이게 바로 부분 함수 종속입니다.

✅ 해결 후

학생 테이블

학번	이름
1001	김현수

수강 테이블

학번	과목	성적
1001	국어	90

5. 제3정규형 (3NF) - 이행 함수 종속 제거

책 용어

제3정규형은 제2정규형을 만족하고, 이행 함수 종속이 없어야 합니다.

쉽게 말하면

직접 연결된 게 아니라 ‘중간 단계를 거쳐서’ 값이 정해지니까 ‘이행(거쳐가는)’ 종속이에요.

어떤 값을 알면 → 다른 값을 알고 → 또 다른 값을 알 수 있다면?

중간 단계를 거친 종속은 제거해야 합니다.

❗ 문제 예시

과목	교수	교수 사무실
운영체제	김교수	3층 301호

과목 → 교수 → 사무실 → 이행 함수 종속 발생!

여기서 과목만 알아도 교수, 교수만 알아도 사무실을 알 수 있으니
과목 → 사무실이라는 이행 종속이 생깁니다.

✅ 해결 후

과목-교수 테이블

과목	교수
운영체제	김교수

교수 테이블

교수	사무실 위치
김교수	3층 301호

6. 보이스/코드 정규형 (BCNF) - 결정자 조건 추가

사실 이름만 보면 뭔가 어려워 보이는데, 알고 보면 단순합니다.

Boyce-Codd Normal Form은 그냥… “보이스(Boyce)와 코드(Codd)라는 두 사람 이름을 딴 정규형”입니다;;

두 사람이 3NF로는 해결되지 않는 데이터 종속 문제를 발견하고, 이를 해결하기 위해 만든 정규화 기준입니다.

BCNF는 “모든 결정자가 후보 키여야 한다”는 조건을 추가한 제3정규형의 강화 버전입니다. 제3정규형은 시험 볼 때 “틀린 것만 안 쓰면 된다” 수준이라면, BCNF는 “맞춘 것까지 모두 정답인지 증명해야 한다” 수준이라고 보면 됩니다.

“3NF로도 막지 못하는 특이한 종속 케이스를 더 강하게 필터링한 거”입니다.

책 용어

BCNF는 모든 결정자가 후보 키여야 합니다.

쉽게 말하면

어떤 값을 기준으로 다른 값을 정한다면, 그 기준이 기본키로 쓸 수 있는 값이어야 해요.

후보 키(Candidate Key)는 테이블에서 각 행을 유일하게 식별할 수 있는 모든 열 또는 열 조합을 말해요.

이 중에서 하나를 골라 실제로 테이블의 식별자로 사용하는 것이 바로 기본 키(Primary Key)입니다.

즉, 모든 기본 키는 후보 키지만, 모든 후보 키가 기본 키인 건 아니에요!

예를 들어 주민번호, 이메일, 학번이 모두 유일하다면 셋 다 후보 키이고,
이 중 하나만 기본 키로 선택해서 사용합니다.

모든 후보 키는 결정자다. 하지만 모든 결정자가 후보 키인 것은 아니다.
그래서 BCNF에서는 “모든 결정자는 후보 키여야 한다”는 조건을 추가로 요구합니다.

결정자(Determinant):
어떤 속성 A가 다른 속성 B를 결정짓는다면, A는 B의 결정자
예: 학번 → 이름이면, 학번은 이름의 결정자.
후보 키(Candidate Key):
테이블에서 튜플(행)을 유일하게 구분할 수 있는 속성 또는 속성 집합
후보 키는 무조건 테이블의 다른 모든 속성을 결정할 수 있어요 → 즉, 항상 결정자

하지만!

어떤 결정자는 후보 키가 아닐 수도 있어요.
예를 들어 과목 코드 → 교수인 경우, 과목 코드는 교수는 결정하지만 학생을 구분하지는 못하니까 후보 키는 아니죠.

✅ 후보 키는 다 결정자다. 근데 결정자라고 해서 다 후보 키인 건 아니다.

        ┌────────────────────┐
        │     결정자(D)      │ ← 가장 큼 (값을 '결정'한다? 전부 포함)
        │  ┌──────────────┐ │
        │  │ 후보 키(CK)   │ ← 테이블의 행을 유일하게 식별할 수 있는 키들
        │  │  ┌──────────┐│ │
        │  │  │ 기본 키(PK) │ ← 후보 키 중에서 선택된 단 하나의 키
        │  │  └──────────┘│ │
        │  └──────────────┘ │
        └────────────────────┘

기본 키 ⊂ 후보 키 ⊂ 결정자
(선택된 키 ⊂ 유일한 키들 ⊂ 뭔가를 결정할 수 있는 애들)

❗ 문제 예시

학번	과목 코드	담당 교수
1	CS101	김교수

여기서 과목 코드가 교수님을 정하지만, 과목 코드 자체는 기본키가 아니에요.

과목 코드 → 담당 교수인데, 과목 코드가 후보 키가 아니라면 BCNF 위반입니다.

✅ 해결 후

과목 테이블

과목 코드	담당 교수
CS101	김교수

학생-과목 테이블

학번	과목 코드
1	CS101

7. ERD로 보는 정규화 예시

ERD 예시

[비정규형 (UNF)]
학번, 이름, 수강 과목(복수), 교수(복수)

↓ 원자값 분해

[1NF]
학번, 이름, 과목, 교수

↓ 부분 종속 제거

[2NF]
학생(학번, 이름)  
수강(학번, 과목, 성적)

↓ 이행 종속 제거

[3NF]
과목(과목, 교수)  
교수(교수, 사무실)

↓ 모든 결정자 → 후보 키

[BCNF]
과목(과목 코드, 교수 코드)  
교수(교수 코드, 사무실)

학생이 수강한 과목과 교수 정보를 1NF → BCNF까지 정규화한 결과입니다.

1NF, 2NF

• 교수 이름이 바뀌면 → 과목과의 관계가 모두 깨질 수 있음
• 교수명이 유일하다는 보장도 없음 (김민수 교수 3명 있을 수 있음)
• 데이터 무결성 깨질 위험 + 변경 이상 발생

~~틀린 그림 찾기가 아니라 '과목코드' '교수코드'가 추가됨.~~

처음에는 하나의 테이블에 모든 정보가 들어 있었지만,

정규화 과정에서 학생, 수강, 과목, 교수로 분리되었고,
각 테이블은 외래키(FK)를 통해 관계를 맺고 있습니다.

BCNF에서는 “모든 결정자는 반드시 후보 키여야 한다”는 조건이 적용됩니다.

예를 들어 과목명이 교수님을 결정짓는다면, 과목명은 반드시 후보 키여야 해요.
이를 위해 ‘과목 코드’와 ‘교수 코드’ 같은 식별 가능한 속성으로 테이블을 재설계하게 됩니다.

여기서 잠깐! 식별 관계 vs 비식별 관계

ERD를 설계할 때, 테이블 간 연결 관계는 식별 관계와 비식별 관계로 나뉩니다.
두 개념은 외래키가 기본키에 포함되는지 여부에 따라 구분돼요.

구분	의미	외래키 특징	예시
식별 관계 (Identifying)	부모 없이는 자식도 존재할 수 없음	외래키가 기본키에 포함됨	주문 → 주문 상세
비식별 관계 (Non-identifying)	부모 없어도 자식은 독립적으로 존재 가능	외래키는 일반 속성 (기본키 아님)	사용자 → 게시글

- 식별 관계: “부모 없으면 나도 없어” → FK가 PK 안에 들어감
- 비식별 관계: “부모 없어도 난 있어” → FK는 그냥 참조용

ㄴ “외래키는 일반 속성”이란? 비식별 관계에서는 외래키가 자식 테이블의 기본키에 포함되지 않는다 : 외래키는 그냥 “참조용”일 뿐이고, 그 자체가 이 테이블에서 행을 식별하는 기본키 역할을 하지는 않음

예를 들어
- `주문 상세`는 해당 주문이 반드시 있어야만 존재할 수 있어요 → 식별 관계
- `게시글`은 작성한 사용자가 탈퇴해도 게시글 자체는 남길 수 있어요 → 비식별 관계

식별 관계는 부모 테이블이 삭제되면 자식 테이블도 함께 사라질 수 있는 구조로,

생명선을 공유하며 논리적으로 완전 종속된 관계입니다.

반면, 비식별 관계는 실무에서 더 자주 사용되며,

데이터 삭제나 수정 시에도 유지보수가 유연하고 독립성이 보장되는 장점이 있습니다.

8. 정규화 흐름도 요약

p.603

참고: 비정규형(UNF) 이란?

한 셀에 여러 개의 값이 들어 있는 상태 (예: 전화번호: "010-1111-2222, 010-3333-4444")
정규화를 하기 전의 '지저분한 테이블' 상태예요.

→ 1NF부터는 이걸 원자값으로 분해합니다.

요약

1NF: 칸칸이 정리하자 (엑셀 한 셀에 값 하나씩)
2NF: 덜 중요한 건 따로 떼자 (부분 종속 분리)
3NF: 간접적인 연결은 없애자 (이행 종속 제거)
BCNF: 모든 기준이 진짜 고유해야 한다 (결정자 = 후보 키)

9. 역정규화는 언제 쓸까?

정규화에도 단점이 있다

테이블이 지나치게 분리되어 JOIN이 많아지고 성능이 저하될 수 있어요
너무 많은 정규형을 적용하면 데이터 구조가 복잡해져 개발자/쿼리 작성자 모두 힘들 수 있습니다

→ 그래서 실무에서는 '정규화 vs 역정규화'를 적절히 조절하는 게 핵심입니다.

p.604

즉, 정규화가 항상 좋은 건 아닙니다. 아래와 같은 경우에는 역정규화가 필요할 수 있어요.

JOIN이 너무 많아서 조회 성능이 떨어지는 경우
분석/리포트 시스템처럼 빠른 읽기가 중요한 경우
NoSQL 환경에서는 기본적으로 정규화를 하지 않기도 해요

이럴 땐 의도적으로 중복을 허용하고, 테이블을 통합하기도 합니다.

마무리

실무에서는 항상 BCNF까지 정규화를 할 필요는 없어요.

데이터 무결성이 중요한 테이블은 정규화하고,

조회 성능이 중요한 테이블은 역정규화하는 식의

균형감 있는 설계가 중요합니다.

정규화는 단순히 테이블을 쪼개는 게 아니라,

왜 쪼개야 하는지, 어떤 문제가 생기기 때문인지를 이해하는 게 핵심입니다.

참고자료

효율적 쿼리란? - 서브쿼리와 조인, 뷰, 인덱스로 쿼리 최적화

readyoun — Mon, 7 Apr 2025 15:20:47 +0900

https://www.flaticon.com/free-icon/sql_9543826?related_id=9543826&origin=search

효율적 쿼리란 무엇일까?

데이터베이스는 수많은 데이터를 저장하고, 이 데이터에 대해 빠르고 정확한 응답을 제공해야 합니다. 하지만 단순히 작동하는 SQL 문을 작성하는 것만으로는 부족합니다. "어떻게 하면 더 빠르게, 더 적은 비용으로 원하는 결과를 가져올 수 있을까?" 가 바로 효율적인 쿼리를 고민해야 하는 이유입니다.

참고: 이 글은 『이것이 취업을 위한 컴퓨터 과학이다』 CHAPTER 06, p.573 ~ p.592의 내용을 기반으로 한 설명입니다.

[참고] 쿼리 실행 과정

SQL 문은 단순한 명령어처럼 보이지만, DB 내부에서는 복잡한 과정을 거칩니다. 실행 과정을 크게 요약하면 다음과 같습니다.

파싱(Parsing) – SQL 문법 분석 및 내부 표현으로 변환
최적화(Optimization) – 실행 계획 수립 (인덱스, 조인 순서 고려)
실행(Execution) – 결정된 계획에 따라 쿼리 수행

이 중 "최적화" 단계는 성능을 좌우하는 핵심입니다. 어떤 쿼리는 수천 배의 성능 차이를 만들 수 있습니다.

쿼리 최적화기(Query Optimizer) 는 가능한 실행 경로 중 비용이 가장 적은 계획을 선택합니다.

이때 비용은 CPU 연산, 디스크 I/O, 네트워크 트래픽 등을 기준으로 평가되며,

통계 정보(statistics)를 바탕으로 실행 계획을 세웁니다.

따라서 데이터 양이 급변했거나, 통계 정보가 오래된 경우, 예상보다 비효율적인 계획이 선택될 수 있습니다.

구조와 실행 과정 참고 : Real MySQL - MySQL 기본 구조(+ 쿼리 실행 과정, 메모리 할당 구조, ...)

1. 서브쿼리와 조인 - 여러 테이블에 질의하려면

1.1 서브 쿼리 - 쿼리 안에 쿼리?

서브쿼리는 하나의 쿼리 안에서 또 다른 쿼리를 사용하는 방식입니다. 특히 WHERE, FROM, SELECT절에서 활용할 수 있죠.

자세한 종류 : [SQL] 서브쿼리란? 서브쿼리 종류 - 스칼라, 인라인 뷰, 중첩

책에서 다루는 대표 두 가지 유형이 있습니다.

SELECT문 안에 SELECT문이 포함된 서브 쿼리
DELETE문 안에 SELECT문이 포함된 서브 쿼리

p.575 예제 - "사용자 테이블의 각 사용자별 게시글 수를 함께 출력하려면?"

SELECT users.username,
       (SELECT COUNT(*)
        FROM posts
        WHERE posts.user_id = users.user_id) AS post_count
FROM users;

결과:

+----------+-------------+
| username | post_count  |
+----------+-------------+
| kim      | 2           |
| lee      | 1           |
| park     | 1           |
+----------+-------------+

또는 특정 사용자 이메일로 조건을 걸어 그 사람의 게시글을 모두 삭제하고 싶다면?

DELETE FROM posts
WHERE user_id = (
  SELECT user_id
  FROM users
  WHERE email = 'kim@example.com'
);

서브쿼리는 비상관 서브쿼리와 상관 서브쿼리로 나뉩니다. 비상관 서브쿼리는 외부 쿼리와 독립적으로 한 번만 실행되지만, 상관 서브쿼리는 외부 쿼리의 각 행에 대해 반복 실행되므로 성능에 악영향을 줄 수 있습니다. 예를 들어 다음과 같은 형태는 성능상 좋지 않을 수 있습니다.

SELECT name FROM student s 
WHERE kor > (SELECT AVG(kor) FROM student WHERE class_id = s.class_id);

상관 쿼리 vs 비상관 쿼리

참고 : SQL 튜닝 용어 정리(2)

상관쿼리와 비상관쿼리의 쓰임새가 헷깔립니다.

1.2 조인 - 테이블을 연결하는 더 효율적인 방법은?

조인은 여러 테이블 간의 연관 데이터를 결합하는 방식입니다.

사용자와 게시글 테이블을 조인해 사용자 이름과 게시글 제목을 함께 출력하려면?

SELECT users.username, users.email, posts.title
FROM users, posts
WHERE users.user_id = posts.user_id;

결과:

+----------+------------------+-------------------------------+
| username | email            | title                         |
+----------+------------------+-------------------------------+
| kim      | kim@example.com  | One                           |
| kim      | kim@example.com  | Two                           |
| lee      | lee@example.com  | Three                         |
| park     | park@example.com | Four                          |
+----------+------------------+-------------------------------+

INNER JOIN을 명시적으로 사용해도 되는데, 보통 INNER 를 생략하기도 합니다.

SELECT customers.name, customers.age, customers.email,
       orders.product_id, orders.quantity, orders.amount
FROM customers
INNER JOIN orders
ON customers.id = orders.customer_id;

조인에는 다양한 종류가 있습니다.

종류	설명
INNER JOIN	테이블 A와 B의 레코드 중 조인 조건을 모두 만족하는 레코드만 반환
LEFT OUTER JOIN	테이블 A의 모든 레코드 + 조인 조건 만족하는 B의 레코드. 만족 못 하면 B는 NULL
RIGHT OUTER JOIN	테이블 B의 모든 레코드 + 조인 조건 만족하는 A의 레코드. 만족 못 하면 A는 NULL
FULL OUTER JOIN	A와 B 모두의 모든 레코드를 포함. 어느 한쪽이 없으면 상대는 NULL로 채워짐

❗ 유의사항:

조인 조건 누락 시 카티션 곱(Cartesian Product) 발생 → 폭발적인 행 수 증가!
항상 ON 조건 또는 USING을 명확히 지정해야 합니다.

카티션 곱(Cartesian Product) 발생 가능성과 그로 인한 성능 문제

카티션 곱은 조인 조건이 누락되었을 때 발생하며, 두 테이블의 모든 행을 조합하여 결과를 생성합니다.

예를 들어, 테이블 A에 1,000개의 행이 있고 테이블 B에 500개의 행이 있다면, 카티션 곱은 1,000 × 500 = 500,000개의 행을 반환하게 됩니다. 이러한 결과는 데이터베이스 서버에 과도한 부하를 주고 쿼리 실행 시간을 크게 증가시킬 수 있습니다.

SELECT * FROM table1, table2; 같은 쿼리는 조인 조건이 없으므로 카티션 곱을 생성합니다.

카티션 곱을 방지하기 위한 방법은 항상 조인 조건을 명확히 지정하는 것입니다. SQL에서 ON 또는 USING 절을 사용하여 테이블 간의 관계를 정의해야 합니다. 조건이 명확하지 않으면 SQL은 기본적으로 모든 행을 조합하는 CROSS JOIN으로 처리합니다.

▶ LEFT OUTER JOIN 예제 (p.582)

SELECT customers.name, orders.id AS order_id, orders.product_id,
       orders.quantity, orders.amount
FROM customers
LEFT OUTER JOIN orders
ON customers.id = orders.customer_id;

▶ RIGHT OUTER JOIN 예제 (p.582)

SELECT customers.name, orders.id AS order_id, orders.product_id,
       orders.quantity, orders.amount
FROM customers
RIGHT OUTER JOIN orders
ON customers.id = orders.customer_id;

❗ LEFT vs RIGHT OUTER JOIN 유의점

JOIN 순서가 바뀌면 결과도 바뀜 → 기준이 되는 테이블이 무엇인지 항상 확인할 것
가독성, 명확한 의도를 위해 LEFT JOIN을 선호하고, RIGHT JOIN은 최소화하는 것이 일반적

항목	LEFT OUTER JOIN	RIGHT OUTER JOIN
기준 테이블	왼쪽 테이블(LEFT)이 기준	오른쪽 테이블(RIGHT)이 기준
NULL 채워짐	오른쪽 테이블의 매칭 안 되는 값	왼쪽 테이블의 매칭 안 되는 값
사용 예	고객은 있지만 주문 없는 경우 포함	주문은 있지만 고객 정보 없는 경우 포함 (드묾)

▶ FULL OUTER JOIN 구현 예시 (p.583)

SELECT customers.name, orders.id AS order_id, orders.product_id,
       orders.quantity, orders.amount
FROM customers
LEFT OUTER JOIN orders ON customers.id = orders.customer_id
UNION
SELECT customers.name, orders.id AS order_id, orders.product_id,
       orders.quantity, orders.amount
FROM customers
RIGHT OUTER JOIN orders ON customers.id = orders.customer_id;

FULL OUTER JOIN은 MySQL에서 직접 지원되지 않기 때문에
위와 같이 LEFT JOIN + RIGHT JOIN + UNION을 조합하여 구현합니다.

▶ JOIN으로 서브쿼리 대체 (p.583)

SELECT users.username, COUNT(posts.post_id) AS post_count
FROM users
LEFT JOIN posts ON users.user_id = posts.user_id
GROUP BY users.username;

앞서 사용한 서브쿼리 기반 카운트 쿼리를 JOIN과 GROUP BY를 통해 동일하게 구현할 수 있습니다. 이 방식은 보다 효율적이며 명확한 실행 계획을 만들어주는 장점이 있습니다.

2. 뷰(View) - 뷰는 왜 필요할까?

뷰(View)는 테이블처럼 사용 가능한 가상의 테이블입니다.

복잡한 쿼리를 단순화하고, 보안을 강화할 수 있습니다.

사용자와 게시글을 조인한 결과를 뷰로 저장하고 활용하려면?

CREATE VIEW myview AS
SELECT users.username, users.email, posts.title
FROM users, posts
WHERE users.user_id = posts.user_id;

해당 뷰를 이용한 조회 예시:

SELECT username, email, title
FROM myview
WHERE username = 'kim';

뷰는 SHOW TABLES 명령어를 통해 확인 가능:

mysql> SHOW TABLES;
+----------------+
| Tables_in_mydb |
+----------------+
| myview         |
| posts          |
| users          |
+----------------+

❗ 유의사항:

뷰는 실제 데이터를 저장하지 않음 → 원본 테이블 변경 시 함께 변경됨
복잡한 뷰에 대해 또 JOIN하면 실행 성능에 주의
여러 테이블을 조인한 뷰에서는 갱신이 제한될 수 있음
- ERROR 1393 (HY000): Can not modify more than one base table through a join view

뷰는 보안과 재사용성 관점에서 유용합니다.

민감한 정보를 제외한 컬럼만 노출 가능
복잡한 조인 쿼리를 캡슐화하여 코드의 가독성과 유지보수성 향상
GRANT를 통해 특정 사용자에게만 접근 권한 부여 가능

3. 인덱스 - 왜 빠른 걸까?

인덱스는 테이블의 특정 컬럼에 대한 검색 속도를 향상시키는 자료구조입니다. 일종의 책의 목차라고 생각할 수 있습니다.

3.1 인덱스의 성능 영향

아래 예제로 인덱스가 성능에 미치는 영향을 확인해보겠습니다.

-- 테이블에 70만 개의 행이 있는 상태
SELECT COUNT(*) FROM users;
-- 결과: 700000 rows in set (0.86 sec)

-- 인덱스 없이 조건 검색
SELECT * FROM users WHERE nickname='User290562U';
-- 결과: 1 row in set (0.21 sec)

-- 인덱스 생성
CREATE INDEX idx_user ON users(nickname);

-- 다시 실행
SELECT * FROM users WHERE nickname='User290562U';
-- 결과: 1 row in set (0.00 sec)

인덱스를 사용하면 전체 테이블 탐색(Full Table Scan) 대신 인덱스를 통해 바로 데이터 위치를 찾을 수 있습니다.

단, SELECT *와 같은 경우 인덱스만으로는 모든 데이터를 가져올 수 없어 테이블 접근이 추가로 필요합니다.

3.2 인덱스 종류와 구조

인덱스의 종류

클러스터형 인덱스(Clustered Index)는 기본 키(primary key)에 적합하며,

세컨더리 인덱스(Secondary Index, Non-Clustered Index)는 다양한 쿼리를 처리하기 위한 보조 도구로 활용됩니다.

구분	설명
클러스터형 인덱스	실제 데이터가 인덱스 순서대로 정렬됨 (MySQL InnoDB 기본값)
세컨더리 인덱스	별도 인덱스 구조에 실제 데이터 위치를 가리킴

자세히 보기 : [MySQL] Clustered Index와 Secondary Index 정리

인덱스 자료구조

B-Tree:
- 균형 이진 트리의 일반화 형태
- 범위 검색과 정렬이 가능
- 루트 → 내부 노드 → 리프 노드 구조
- 검색/삽입/삭제 모두 O(log n) 시간 복잡도
- RDBMS의 기본 인덱스 구조

참고
- [MySQL] Index의 구조 : B-Tree, B+Tree
- [MySQL] B-tree, B+tree란? (인덱스와 연관지어서)
- [MySQL] B-Tree로 인덱스(Index)에 대해 쉽고 완벽하게 이해하기

Hash Table:
- 정확히 일치하는 키 검색에 특화
- 범위 검색 불가
- NoSQL에서 주로 활용

잼씀: DB 인덱스에서는 왜 HashTable을 사용하지 않을까?

3.3 인덱스 사용 시 고려사항

인덱스가 적용되는 조건:

WHERE, JOIN, ORDER BY 절에 사용된 컬럼
LIKE 검색은 접두어 기준일 때만 (LIKE 'A%')
함수 적용 컬럼에는 적용 안 됨 (WHERE UPPER(name) = 'ROBIN' ❌)

주의사항:

INSERT/UPDATE/DELETE 시 인덱스도 갱신 필요 → 쓰기 성능 저하
인덱스가 많으면 Optimizer가 최적 인덱스 선택을 못할 수 있음
자주 변경되는 컬럼(예: 로그인 실패 횟수)은 인덱스 설정 신중히 고려
다중 컬럼 인덱스는 컬럼 순서가 성능에 큰 영향
EXPLAIN으로 인덱스 사용 여부 확인 필수

EXPLAIN은 SQL 쿼리의 실행 계획을 미리 확인하는 도구다. 인덱스가 쓰였는지, 조인이 어떻게 수행되는지, 몇 행을 탐색하는지 알 수 있다. 성능 개선(쿼리 튜닝)에서는 무조건 확인해야 할 1순위 도구다.

결론: 자주 조회되지만 변경이 적은 컬럼 위주로 선택적 인덱스 생성이 중요합니다.

정리하며

효율적인 쿼리 작성은 데이터베이스 성능을 최적화하고 애플리케이션의 응답 시간을 줄이는 데 매우 중요합니다. 잘 설계된 쿼리는 불필요한 데이터 검색과 연산을 최소화하여 서버의 부하를 줄이고, 시스템 자원을 효율적으로 활용할 수 있게 합니다.

반면, 비효율적인 쿼리는 과도한 I/O 작업과 CPU 사용을 초래하며, 데이터베이스의 성능 저하와 비용 증가로 이어질 수 있습니다. 이를 방지하기 위해 인덱스 활용, 필요한 컬럼만 조회, 조인 및 서브쿼리 최적화, 실행 계획 분석 등 다양한 최적화 기법을 적용해야 합니다.

따라서, 단지 SQL이 동작하는 것에 만족하지 말고, 동시에 얼마나 빠르고 효율적으로 동작하는가를 고민해야 합니다. 데이터가 적을 때는 문제가 없어 보여도, 데이터가 많아질수록 설계 미비는 곧바로 성능 저하로 나타납니다.

요약

✅ 효율적 쿼리란?

같은 결과를 더 빠르고, 더 적은 비용으로 얻는 SQL
실행 계획 최적화가 핵심 (쿼리 옵티마이저, 통계 정보)

서브쿼리 vs 조인

상관 서브쿼리는 행마다 서브쿼리 실행 → 느림
JOIN + GROUP BY는 집합 기반 연산 → 더 효율적

OUTER JOIN 종류

LEFT JOIN: 왼쪽 테이블 기준, 없는 값은 NULL
RIGHT JOIN: 오른쪽 테이블 기준 (덜 선호됨)
FULL OUTER JOIN: MySQL은 UNION으로 구현

‍ VIEW 사용법

복잡한 SELECT를 재사용 가능한 가상 테이블로
보안과 쿼리 간결화에 유용하지만 갱신 제약 있음

⚡ 인덱스 최적화

B-Tree 기반, 검색 속도 비약적 향상
SELECT, WHERE, ORDER BY 등에서 유리
너무 많은 인덱스 = 오히려 비효율 (쓰기 성능 저하)

팁

EXPLAIN으로 쿼리 실행 계획을 꼭 확인하자!

참고자료

이것이 취업을 위한 컴퓨터 과학이다

웹 개발자라면 꼭 알아야 할 데이터베이스 기초 정리

readyoun — Mon, 7 Apr 2025 11:57:45 +0900

From Wikipedia, the free encyclopedia

1. 왜 데이터베이스가 중요한가?

웹 서비스를 개발하다 보면 사용자 정보, 게시글, 주문 내역 등 수많은 데이터를 다루게 됩니다. 이 데이터를 안전하고 안정적으로 관리하기 위해 반드시 필요한 것이 바로 데이터베이스(Database) 입니다.

데이터베이스란, 여러 사람이 공유하고 사용할 목적으로 체계화된 데이터의 집합이며, 이러한 데이터를 효율적으로 저장, 수정, 조회할 수 있도록 돕는 프로그램이 바로 DBMS(Database Management System) 입니다.

✅ 데이터베이스는 단순한 저장 공간이 아니라, 웹 서비스의 핵심 기반 인프라입니다.

2. DBMS의 종류와 RDBMS가 중요한 이유

DBMS는 크게 두 가지로 나뉩니다:

관계형 DBMS(RDBMS): MySQL, Oracle, PostgreSQL 등
비관계형 DBMS(NoSQL): MongoDB, Redis 등

2023년 개발자 설문조사에 따르면, 관계형 데이터베이스가 가장 널리 사용되고 있으며, 특히 MySQL은 오픈소스이자 높은 점유율을 자랑합니다.

신입 개발자라면 RDBMS부터 익히는 것이 실무 진입에 유리합니다.

3. DBMS의 역할과 SQL

DBMS는 단순히 데이터를 저장하는 것에서 그치지 않고, 응용 프로그램과 상호작용하며 데이터를 효율적으로 관리합니다.
이때 사용하는 언어가 바로 SQL(Structured Query Language)입니다.

SQL은 다음과 같은 언어로 구성됩니다.

DDL (데이터 정의어): 테이블 생성/수정/삭제
DML (데이터 조작어): 데이터 조회/삽입/수정/삭제
DCL (데이터 제어어): 권한 부여/회수
TCL (트랜잭션 제어어): COMMIT, ROLLBACK 등

SQL은 면접에서도 자주 등장하는 핵심 기술입니다. 실무 SQL 작성에 익숙해지는 것이 좋습니다.

4. 파일 시스템과 데이터베이스는 어떻게 다를까?

간단한 프로젝트에서는 데이터를 JSON이나 텍스트 파일로 저장할 수도 있습니다. 하지만 이런 파일 시스템은 데이터의 중복, 무결성, 검색 효율성, 백업 문제에 취약합니다.

반면, 데이터베이스는 다음과 같은 이유로 더 적합합니다:

데이터의 일관성 유지
중복 저장 방지
정교한 조건 검색 가능
트랜잭션 처리 및 복구 기능 제공

= 파일 시스템 | ️ = 데이터베이스
✅ 실제 서비스 운영에는 데이터베이스가 필수입니다!

5. 데이터베이스의 저장 단위와 트랜잭션

데이터베이스는 다음과 같은 구조로 데이터를 관리합니다.

스키마(Schema): 데이터베이스 구조 정의
엔티티(Entity): 실제 데이터가 저장되는 단위 (ex. 테이블)

그리고 데이터베이스와의 논리적 작업 단위를 트랜잭션(Transaction) 이라고 하며, 다음 네 가지 특성(ACID)을 보장해야 합니다. 자세한 설명은 9. 트랜잭션과 ACID에서 이어집니다.

Atomicity(원자성)
Consistency(일관성)
Isolation(격리성)
Durability(지속성)

트랜잭션은 실시간 데이터 처리에서 신뢰성을 보장하는 핵심 기능입니다.

6. 데이터베이스 설계와 무결성 제약 조건

효율적인 DB 설계를 위해선 다음을 고려해야 합니다.

어떤 테이블이 필요한가?
테이블 간 관계(Relation) 는 어떤가?
무결성 제약 조건은 무엇인가?

무결성 제약 조건의 종류는 다음과 같습니다.

제약 조건 종류	설명
도메인 제약	값의 데이터 타입 제한
키 제약	유일한 값을 보장 (기본키 등)
엔티티 무결성	기본키는 NULL이 될 수 없음
참조 무결성	외래키는 실제 존재하는 값만 참조 가능

좋은 설계는 불필요한 중복을 줄이고, 데이터 정합성을 높입니다.

7. SQL의 주요 명령어 정리

아래는 SQL 주요 명령어 유형과 그 역할입니다.

✅ DDL (데이터 정의어)

CREATE TABLE users (...);
ALTER TABLE users ADD COLUMN age INT;
DROP TABLE users;

✅ DML (데이터 조작어)

SELECT * FROM users;
INSERT INTO users VALUES (...);
UPDATE users SET age = 30 WHERE id = 1;
DELETE FROM users WHERE id = 1;

✅ TCL (트랜잭션 제어어)

BEGIN;
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
UPDATE accounts SET balance = balance + 100 WHERE id = 2;
COMMIT; -- 또는 ROLLBACK;

실무에서는 DML과 TCL이 가장 자주 사용되며, 트랜잭션 처리가 중요한 역할을 합니다.

8. 관계형 DB vs NoSQL – 상황에 따라 달라지는 선택

관계형 데이터베이스(RDBMS)는 정형 데이터, 복잡한 관계, 데이터 정합성이 중요한 시스템에 적합합니다. 테이블 간 관계(1:N, M:N)를 명확하게 설정하고, SQL을 통해 조인, 서브쿼리 등을 활용한 정교한 데이터 처리도 가능합니다.

반면, NoSQL은 유연한 스키마 구조와 수평 확장성이 강점입니다. JSON 형태의 비정형 데이터를 저장할 수 있고, MongoDB나 Redis는 실시간 처리, 캐싱, 로그 저장 등에서 유용하게 사용됩니다.

실제로, 정형 데이터를 주로 다루는 회원관리, 게시판, 주문 처리 등의 시스템에서는 RDBMS가 자연스럽게 선택되며, 복잡한 데이터 구조를 설계하고 관리하는 데 유리합니다.

정리하자면, 데이터의 구조, 읽기/쓰기 패턴, 확장성 요건, 일관성 요구 수준을 기준으로 적절한 DBMS를 선택하는 것이 중요합니다.

9. 트랜잭션과 ACID – 신뢰할 수 있는 데이터 처리

웹 애플리케이션에서 사용자 요청이 DB로 이어질 때, 대부분의 조작은 트랜잭션 단위로 처리됩니다.

예를 들어, 계좌 이체처럼 두 테이블에 동시에 영향을 미치는 작업은 중간에 실패할 경우 모든 처리가 롤백되어야 합니다.

트랜잭션의 4가지 핵심 속성(ACID)은 다음과 같습니다.

Atomicity (원자성): 전체 작업이 전부 수행되거나 전혀 수행되지 않음
Consistency (일관성): 트랜잭션 전후에 DB 상태가 유효해야 함
Isolation (격리성): 동시에 실행되는 트랜잭션이 서로 간섭하지 않음
Durability (지속성): 커밋된 데이터는 시스템 장애에도 보존됨

Java/Spring 기반의 ERP 시스템 개발 프로젝트에서 생산관리 도메인을 담당하며 트랜잭션의 필요성을 직접 체감하기도 했는데요.

예를 들어, 하나의 생산 지시가 생성될 때는 다음과 같은 일련의 작업이 함께 수행됩니다.

생산 지시 등록
관련 자재 차감 처리
작업 지시 등록 및 설비 배정

이 중 한 단계라도 실패할 경우, 전체 작업이 롤백되지 않으면 데이터 정합성이 깨지고, 재고 수량이나 작업 이력이 실제와 불일치하는 문제가 발생합니다.

특히 ERP 시스템은 운영 데이터가 즉시 현장 업무와 연결되기 때문에, 일관성 있는 트랜잭션 처리가 필수적입니다.

이런 상황을 고려해, 실제 프로젝트에서는 주요 비즈니스 로직을 하나의 서비스 계층에서 묶고, Spring에서 제공하는 @Transactional 기반의 트랜잭션 처리를 적용할 수 있도록 설계했습니다.

@Transactional
public void processProductionOrder(ProductionOrderRequest request) {
    productionOrderRepository.save(...);   // 생산 지시 등록
    materialService.deductMaterial(...);   // 자재 차감
    workService.createWorkAssignment(...); // 작업 지시 및 설비 할당
}

위 코드는 실제 구현과는 다르지만, 당시 제가 설계에 접근한 방식을 설명하기 위한 예시입니다. 실제로는 모듈별 책임이 분리되어 있었고, 트랜잭션 범위도 세분화되어 관리되었습니다.

이 경험을 통해, 트랜잭션은 단순한 기술 요소를 넘어 업무의 신뢰성과 품질을 보장하는 핵심적인 설계 고려사항이라는 점을 배웠습니다.

특히 트랜잭션은 장애 상황, 예외 처리와도 밀접하게 연결되기 때문에, 단순한 개념이 아닌 실무적인 맥락 속에서 체득하는 것이 중요합니다.

데이터 정합성이란?

ERP 시스템과 같은 업무 중심 애플리케이션에서는 데이터 정합성(Data Integrity) 이 매우 중요합니다.

정합성이란 쉽게 말해, 데이터가 서로 모순되지 않고 실제 업무 흐름과 논리적으로 일치하는 상태를 의미합니다.

예를 들어, 생산 지시가 생성되었는데 자재는 차감되지 않았거나, 작업 지시가 없는데 생산 결과가 등록된 경우는 정합성이 깨진 상태입니다.

이 개념은 흔히 ACID 트랜잭션의 일관성(Consistency) 과 혼동되기도 하지만, 조금 다른 의미를 가집니다.

ACID에서 말하는 일관성은 트랜잭션 전과 후의 데이터가 정해진 규칙(제약 조건, 트리거 등)을 항상 만족하는 상태를 말합니다. 예를 들어, 외래키 제약 조건이 깨지지 않는 것, 숫자 필드에 문자열이 들어가지 않는 것이죠.

반면, 데이터 정합성은 시스템 전반의 '업무적 논리'까지 포함하는 더 넓은 개념입니다.

즉, 트랜잭션이 일관성을 만족한다고 해서 정합성이 항상 보장되는 것은 아닙니다. 여러 트랜잭션이 모여 하나의 비즈니스 흐름을 만들기 때문에, 이들 간의 연결 상태까지 고려해야 진정한 의미의 데이터 정합성을 확보할 수 있습니다.

정합성은 비즈니스 현실과 데이터의 싱크를 맞추는 작업이고,
⚙️ ACID의 일관성은 그 데이터가 시스템 내부 규칙을 지키는지를 보장하는 메커니즘입니다.

ACID의 각 특성과 정합성 비교 정리

항목	의미	중점	예시	키워드
Atomicity (원자성)	트랜잭션 내 모든 작업이 전부 수행되거나 전혀 수행되지 않아야 함	작업의 일괄성	자재 차감 중 오류 → 생산 지시도 취소됨	"All or Nothing"
Consistency (일관성)	트랜잭션 전후 DB가 항상 유효한 상태여야 함	제약 조건, 규칙	외래키 위반 없이 정상 입력됨	정해진 룰을 만족하는지
Isolation (격리성)	여러 트랜잭션이 동시에 실행돼도 서로 간섭하지 않음	동시성 보장	동시에 재고 차감 시 충돌 방지	트랜잭션 간 간섭 방지
Durability (지속성)	커밋된 데이터는 시스템 장애에도 유지됨	장애 복원	전원 꺼져도 커밋된 생산이력 보존	영속 저장 보장
정합성 (Integrity)	데이터가 현실 업무 흐름과 모순되지 않도록 유지됨	업무 논리	생산 지시 있음 → 자재 차감 반드시 수행	여러 트랜잭션의 의미적 연결

✔️ ACID는 DB 내부 동작의 신뢰성을 위한 기술적 개념이고,
정합성은 '현실 업무와 데이터가 맞물리는가'에 대한 비즈니스적 검증입니다.

ERP나 실시간 재고 시스템처럼 다수의 트랜잭션이 유기적으로 연결된 도메인에서는
ACID만으로는 부족하며, 정합성 검증 로직을 따로 구성해야 할 때도 있습니다.

예를 들어, 생산 지시 등록 트랜잭션은 성공했지만 자재 차감 트랜잭션은 실패한 경우,
기술적으로는 문제없는 상태일지라도, 업무 관점에서는 모순된 데이터가 생성된 것입니다.

이런 부분을 검증하고 복구할 수 있는 흐름 설계가 바로 실전 트랜잭션 설계의 핵심입니다.

10. 파일 시스템 대신 데이터베이스를 선택하는 이유

처음 프로젝트를 시작할 때는 간단한 데이터를 파일(JSON, CSV 등)에 저장해도 괜찮아 보입니다. 하지만 프로젝트가 커지면서 다음과 같은 문제가 발생합니다.

특정 조건으로 데이터를 검색하기 어렵고,
데이터 중복이 자주 발생하며,
누락되거나 깨진 데이터가 복구되지 않음

파일 저장 방식이 가진 한계입니다. 그러니 필수적으로 RDBMS를 활용하여 데이터의 무결성과 일관성을 확보해야 합니다.

특히 정규화를 적용해 중복을 최소화하고, 참조 무결성을 통해 잘못된 관계를 막는 설계 방식은 서비스 안정성과 유지보수 측면에서 큰 차이를 만들어낼 수 있습니다.

마무리하며

데이터베이스는 단지 데이터를 담아두는 공간이 아니라, 웹 서비스의 신뢰성과 확장성을 책임지는 중심 축입니다.

초기 설계부터 실제 운용, 장애 대응까지 폭넓게 영향을 미치기 때문에, 기본 개념은 물론 실무 상황에 대한 감각까지 갖춰야 합니다.

참고 자료

이것이 취업을 위한 컴퓨터 과학이다 Chapter 6. 데이터베이스

프록시와 스케일링: 안정적인 트래픽 처리

readyoun — Wed, 26 Mar 2025 05:35:34 +0900

https://www.techbuyer.com/au/blog/what-is-a-proxy-server

트래픽이 몰리는 순간, 시스템은 어떻게 안정성을 유지할까?

백엔드 아키텍처에서 핵심이 되는 개념인 프록시, 로드 밸런서, 스케일링 전략을

『이것이 취업을 위한 컴퓨터 과학이다』 5-7절 내용을 바탕으로 정리합니다.

1. 오리진 서버와 중간 서버: 포워드 프록시와 리버스 프록시

『이것이 취업을 위한 컴퓨터 과학이다』 p.480

프록시는 말 그대로 중간에서 통신을 중개하는 서버입니다.
하지만 ‘누구를 대신해서’ 요청을 보낼 것인지에 따라 두 가지 종류로 나뉩니다.

✅ 포워드 프록시 (Forward Proxy)

『이것이 취업을 위한 컴퓨터 과학이다』 p.481

클라이언트 입장에서 중간 서버
내부망 사용자 → 외부 서버 요청 시 사용
접근 제어, 캐싱, 보안 우회(우회 접속) 등에 활용

ex) 회사 내부에서 외부 웹사이트 접근 시, 포워드 프록시 서버를 거쳐야 하는 경우

Q: 프록시 서버와 VPN의 차이는 무엇인가요?
→ 둘 다 중계 서버 개념이지만, VPN은 전체 트래픽을 암호화하고 IP 자체를 숨겨 '네트워크를 확장하는' 개념입니다. 프록시는 애플리케이션 계층 수준에서 중계합니다.

✅ 리버스 프록시 (Reverse Proxy)

『이것이 취업을 위한 컴퓨터 과학이다』 p.482

서버 입장에서 중간 서버
외부 사용자 → 여러 내부 서버 중 하나로 연결
로드 밸런싱, SSL 처리, 보안 필터링 등에 사용

ex) Nginx를 리버스 프록시로 설정하여 여러 웹 서버 앞단에서 트래픽 분산

Q: 리버스 프록시와 로드 밸런서는 어떻게 다른가요?
→ 리버스 프록시는 외부 요청을 받아 내부로 전달하는 역할, 로드 밸런서는 내부 서버 간 '트래픽 분산'이 핵심입니다. 둘이 함께 쓰이기도 합니다.

2. 고가용성: 로드 밸런싱과 스케일링

✅ 가용성(Availability)

서비스가 정상적으로 동작하는 시간의 비율
업타임(Uptime): 서비스가 켜져 있는 시간
다운타임(Downtime): 서비스가 꺼져 있는 시간

파이브 나인스(99.999%)

연간 약 5.26분의 다운타임만 허용하는 매우 높은 신뢰성 기준
주요 금융 시스템, 글로벌 IT 기업에서 추구

Q: 실제로 파이브 나인스를 달성하기 위해선 어떻게 해야 하나요?
→ 이중화된 전원, 분산 데이터 센터, 장애 조기 감지 시스템 등 매우 고도화된 인프라와 운영이 필요합니다.

✅ 헬스 체크와 하트비트

헬스 체크 (Health Check):
로드 밸런서가 서버의 상태를 주기적으로 확인 → 문제가 있으면 요청 대상에서 제외
하트비트 (Heartbeat):
서버 간 정기적으로 신호를 주고받으며 살아있는지 확인
→ 클러스터 환경에서 유용

Q: 헬스 체크 실패 시, 로드 밸런서는 즉시 해당 서버를 제거하나요?
→ 대부분의 로드 밸런서는 여러 번의 실패 후에 제거합니다. false positive를 방지하기 위해 grace time이나 실패 횟수 기준이 설정됩니다.

3. 로드 밸런싱

✅ 정의 및 필요성

여러 서버로 들어오는 요청을 균등하게 분산 처리하여 서버 과부하를 방지하는 기술

Q: 로드 밸런서는 트래픽 외에도 SSL 처리나 인증 기능을 맡기도 하나요?
→ 예, 특히 리버스 프록시와 결합된 경우 TLS 종료(SSL termination), 인증 헤더 삽입 등 기능도 수행합니다.

✅ 로드 밸런싱 알고리즘

알고리즘	설명
라운드 로빈	순차적으로 요청 분배
가중 라운드 로빈	서버 성능에 따라 가중치 부여
최소 연결(Least Connection)	현재 연결 수가 가장 적은 서버 선택
IP 해시	클라이언트 IP 기반으로 고정 서버 연결

Q: 라운드 로빈과 최소 연결 알고리즘은 언제 어떤 기준으로 선택하나요?
→ 요청 처리 시간이 짧고 균일하다면 라운드 로빈, 그렇지 않고 요청에 따라 부담이 다르다면 최소 연결이 더 효과적입니다.

✅ 스케일링: 스케일 업, 스케일 아웃, 오토스케일링

스케일 업 (Scale-Up)

더 좋은 성능의 장비로 교체 (수직 확장)

스케일 아웃 (Scale-Out)

서버 수를 늘림 (수평 확장)

오토스케일링 (Auto Scaling)

트래픽 상황에 따라 서버를 자동으로 늘리거나 줄이는 기능

Q: 오토스케일링이 발생하는 기준은 어떻게 설정하나요?
→ CPU 사용률 80% 초과, 메모리 임계치, 네트워크 트래픽 등을 기준으로 설정 가능하며, 클라우드 환경에서 정책 기반으로 관리됩니다.

4. Nginx로 알아보는 로드 밸런싱 실습

Nginx는 리버스 프록시 + 웹 서버 + 로드 밸런서 역할을 모두 할 수 있는 가볍고 강력한 오픈소스 도구입니다.

특히 로드 밸런싱 기능은 설정만으로도 쉽게 구현할 수 있어, 학습용이나 실무 프로토타이핑에 널리 사용됩니다.

http {
  upstream backend {
    server backend1.example.com;
    server backend2.example.com;
  }

  server {
    listen 80;

    location / {
      proxy_pass http://backend;
    }
  }
}

• upstream 블록: 실제 요청을 처리할 백엔드 서버들을 정의

• proxy_pass: 클라이언트 요청을 backend 그룹 중 하나로 자동 전달

Q: upstream 블록에서 서버마다 weight를 설정할 수 있나요?
→ 예, server backend1.example.com weight=3; 형식으로 가중치를 부여할 수 있습니다. 처리 능력이 더 높은 서버에 더 많은 요청을 할당하기 위해 사용합니다.

[3편] 브라우저는 어떻게 나를 기억할까? - HTTP 활용

readyoun — Wed, 26 Mar 2025 04:54:37 +0900

쿠키부터 HTTPS까지, HTTP 활용 기술

IconScout

1. 개요

웹 개발을 하면서 가장 자주 접하게 되는 프로토콜은 HTTP(Hypertext Transfer Protocol) 입니다.

우리는 흔히 이 프로토콜을 통해 데이터를 주고받고 있지만,

단순히 텍스트를 요청하고 응답하는 것 외에도,

사용자 상태 유지, 콘텐츠 최적화, 보안 통신, 인증 처리 등 매우 다양한 기능을 제공한다는 점은 간과하기 쉽습니다.

이번 글에서는 실전 프로젝트에서 꼭 필요한 다음과 같은 HTTP 활용 기술들을 정리해봅니다.

사용자의 로그인 상태를 유지하는 쿠키
서버 응답을 효율적으로 재활용하는 캐시
클라이언트와 서버가 언어, 포맷을 조율하는 콘텐츠 협상
사용자의 신원을 검증하는 인증
전송 중 데이터의 보안을 책임지는 HTTPS(보안 통신)

2. 쿠키 (Cookie)

2.1 쿠키란?

HTTP는 무상태(stateless) 프로토콜입니다.

즉, 클라이언트와 서버가 통신을 할 때,

이전 요청과 현재 요청 간의 상태가 연결되어 있지 않습니다.

이를 해결하기 위해 등장한 것이 쿠키(Cookie) 입니다.

mdn web docs - Using HTTP cookies

2.2 Set-Cookie 헤더의 동작 방식

Set-Cookie: session_id=abcd1234; Path=/; HttpOnly

클라이언트는 이후 요청마다 다음과 같은 헤더를 전송합니다.

Cookie: session_id=abcd1234

2.3 쿠키의 주요 속성

속성	설명
`Name=Value`	쿠키의 이름과 값
`Path`	어떤 경로에 대해 쿠키를 전송할지 지정
`Domain`	쿠키를 전송할 도메인 지정
`Expires` / `Max-Age`	쿠키의 유효 시간
`Secure`	HTTPS 통신에서만 쿠키 전송
`HttpOnly`	JavaScript에서 접근 불가 → 보안 강화

2.4 쿠키의 활용과 문제점

✅ 활용 사례

로그인 유지 (session_id)
방문자 추적 (GA, 광고 등)
사용자 설정 저장 (언어, 테마 등)

❌ 문제점

보안 위험: 쿠키 탈취(XSS), 세션 하이재킹 등
용량 제한: 도메인당 4KB 이하
무조건 자동 전송: 필요 없는 요청에도 함께 전송

✍️ 실전 예시 (가상의 사례)

Set-Cookie: session_id=abc123; HttpOnly; Secure; Path=/; Max-Age=3600

보안 강화를 위해 HttpOnly와 Secure 옵션을 추가하고, 세션 만료 시간 설정으로 안정성 확보.

2.5 웹 스토리지: 로컬 스토리지와 세션 스토리지

쿠키 외에도 브라우저는 클라이언트 측에 데이터를 저장하기 위해 Web Storage API를 제공합니다.

대표적으로 로컬 스토리지(LocalStorage)와 세션 스토리지(SessionStorage)가 있으며, 쿠키보다 용량이 크고, 단순한 구조를 가집니다.

항목	쿠키	로컬 스토리지	세션 스토리지
용도	상태 유지, 인증	클라이언트 데이터 저장	탭 단위 임시 저장
저장 위치	서버/브라우저	브라우저
자동 전송	✅ 서버에 매 요청마다 전송	❌ 서버에 전송 안 됨
만료 시점	지정 가능	직접 삭제 전까지	탭 종료 시 소멸
저장 용량	약 4KB	수 MB

보안이 중요한 정보(예: JWT)는 쿠키 + HttpOnly 조합으로 저장하고, 일반 UI 상태 정보(예: 다크 모드)는 로컬 스토리지를 활용하는 방식이 이상적입니다.

3. 캐시(Cache)

3.1 웹 캐시란?

웹 캐시는 서버로부터 받은 리소스를

클라이언트(브라우저)나 중간 서버(CDN, 프록시 등)에 저장해두었다가,

같은 요청이 반복될 때 재사용하는 기술입니다.

목적: 성능 향상, 트래픽 감소, 서버 부하 완화
예: 이미지, JS, CSS, API 응답 등을 반복 요청 없이 재사용

3.2 캐시의 장점

이점	설명
✅ 성능 향상	로딩 속도 개선 (사용자 체감 속도 ↑)
✅ 트래픽 절감	동일 리소스 요청 생략
✅ 서버 부하 감소	동시 접속 수 증가에도 안정성 확보
✅ 비용 최적화	CDN + 캐시로 네트워크 요금 절감 가능

3.3 캐시 저장 위치

브라우저(로컬) : 사용자 개인 장치에 저장 (private cache)
중간 서버(프록시, CDN) : 다수 사용자 간 공유 캐시 (public cache)

Cache-Control: private은 브라우저 캐시에만 저장되고, public은 공유 캐시도 허용합니다.

3.3 캐시 제어 HTTP 헤더

Cache-Control: max-age=1200, public
Expires: Tue, 06 Feb 2024 12:00:00 GMT
ETag: "v1.3"
Last-Modified: Mon, 05 Feb 2024 10:00:00 GMT

주요 캐시 관련 헤더

헤더	설명
Cache-Control	캐시 동작 제어의 핵심
Expires	만료 시점 설정 (HTTP/1.0)
ETag	컨텐츠 식별용 버전 태그
Last-Modified	리소스 최종 수정 시각

Cache-Control 디렉티브

디렉티브	설명
max-age=3600	1시간 동안 fresh
no-cache	캐시 사용 전 서버에 재검사 필요
no-store	캐시에 절대 저장 금지 (민감 정보)
private	개인 클라이언트 전용 캐시 (공유 캐시 금지)
public	누구나 캐시 가능 (프록시, CDN 허용)
must-revalidate	만료 시 재검사 반드시 수행

Cache-Control: public, max-age=600, must-revalidate

3.4 Expires vs Cache-Control

항목	설명
Expires	절대 시간 기반 만료 (HTTP/1.0 스타일)
Cache-Control: max-age	상대 시간 기반 만료 (HTTP/1.1 이후 권장)

두 개가 함께 있을 경우, Cache-Control이 우선 적용됩니다.

3.5 ETag vs Last-Modified

둘 다 조건부 요청(Validation)에 사용되는 헤더입니다.

항목	설명
ETag	리소스의 고유 버전 ID (정밀 비교)
Last-Modified	최종 수정 시각 (초 단위, 정밀도 낮음)

If-None-Match: "v1.2.3"     → 서버가 ETag 비교
If-Modified-Since: Tue, 25 Mar 2025 10:00:00 GMT

둘 다 있다면 브라우저는 ETag를 우선적으로 사용합니다.

3.6 캐시 신선도(freshness)

캐시가 fresh(신선)한지, stale(만료)됐는지를 판단하는 기준

현재 시각 - 응답 수신 시각 < max-age → fresh

fresh: 서버 요청 없이 캐시 사용
stale: 재검사 필요 → 304 or 새로 받음

3.7 캐시 동작 방식: 3가지 케이스

① 캐시 그대로 사용 (fresh)

• 캐시가 아직 유효함

• 서버 요청 없이 클라이언트가 그대로 사용

② 조건부 요청 (stale, 변경 없음)

• 캐시가 만료됐지만 서버 리소스가 변경되지 않음

• 304 Not Modified 응답

• 기존 캐시 재사용

If-None-Match: "v1.2.3"
→ 304 Not Modified

③ 캐시 무효화 (stale, 변경됨)

• 캐시 만료 + 리소스 변경됨

• 서버가 새 리소스를 200 OK로 재전송

3.8 프록시 캐시 vs 브라우저 캐시

구분	브라우저 캐시	프록시 캐시 / CDN
대상	개인 사용자	여러 사용자 공유
private	✅ 허용	❌ 금지
public	✅ 허용	✅ 허용
사용 예	로그인 상태 유지	정적 리소스 CDN 제공

✍️ 실전 예시 (가상의 사례)

사용자 프로필 이미지가 변경되었는데도, 브라우저에선 이전 이미지를 계속 보여주는 문제가 발생.

해결 방안

1. 이미지 URL에 버전 쿼리 추가 → /profile.jpg?v=20250325

2. 서버 응답 헤더 설정:

Cache-Control: private, max-age=300
ETag: "profile-img-v2"

브라우저는 캐시 유효 시간이 지나면 서버에 If-None-Match로 조건부 요청 →

변경 없음: 304 → 재사용 / 변경됨: 200 → 새로 받음

이후 브라우저는 적절히 캐시를 활용하면서도 최신 이미지 동기화를 유지할 수 있습니다.

✅ 캐시 요약 정리

요소	역할
Cache-Control	캐시 정책 제어 (핵심)
ETag / Last-Modified	변경 여부 판단용
Expires	HTTP/1.0 호환 만료 시간
Fresh / Stale	신선도 판단 기준
304 응답	조건부 요청의 결과

4. 콘텐츠 협상 (Content Negotiation)

4.1 콘텐츠 협상이란?

클라이언트가 요청 시 수신 가능한 포맷/언어/인코딩을 제안하고, 서버가 최적 콘텐츠를 제공하는 기능

4.2 콘텐츠 협상의 유형

유형	설명
서버 주도	Accept 헤더 기반
에이전트 주도	클라이언트 UI 선택
투명 협상	프록시가 판단

4.3 주요 헤더

Accept: application/json
Accept-Language: ko-KR, en-US;q=0.8
Accept-Encoding: gzip, deflate

✍️ 실전 예시 (가상의 사례)

브라우저 언어 설정 기반으로 자동 언어 제공

const lang = req.headers['accept-language'];

[여기서 잠깐!] 인증(Authentication)

방식	설명	보안성
Basic	ID/PW를 base64 인코딩	낮음
Form 기반	세션과 쿠키 조합	중간
JWT	토큰 기반 stateless 인증	높음

주의: HTTPS 미적용 시 인증 정보 노출 위험! 반드시 보안 채널에서만 사용하세요.

5. 보안 (HTTPS, TLS)

5.1 HTTPS가 필요한 이유

평문 전송 문제 해결 (도청, 위조, 변조 방지)

기본 HTTP 통신은 평문(Plain Text)입니다.

즉, 누군가가 네트워크 중간에서 통신을 엿본다면 다음과 같은 정보가 그대로 노출됩니다.

로그인 ID, 비밀번호
카드번호, 주소 등 민감 정보
쿠키 값 → 세션 하이재킹 위험

이러한 문제를 해결하기 위해 사용되는 것이 바로 HTTPS (HTTP Secure) 입니다.

5.2 HTTPS의 핵심: TLS 프로토콜

HTTPS는 내부적으로 TLS(Transport Layer Security) 프로토콜을 사용하여 다음 3가지를 보장합니다.

기밀성 : 전송되는 데이터가 암호화되어 도청 불가
무결성 : 중간에 데이터가 변경되었는지 여부 확인 가능
인증성 : 서버(또는 클라이언트)의 신원을 검증 가능

5.3 TLS 통신 흐름 요약

HTTPS 통신이 시작되면, 클라이언트와 서버는 TLS 핸드셰이크 과정을 통해

서로의 신원을 확인하고 안전하게 대칭키를 공유하게 됩니다.

아래 이미지는 TLS 1.3 기준의 핸드셰이크 흐름입니다.

『이것이 취업을 위한 컴퓨터 과학이다』, p.475

단계별 설명

1. ClientHello : 클라이언트가 지원하는 프로토콜 버전, 암호화 스위트, key_share(선택적) 등을 서버에 전달

2. ServerHello : 서버가 선택한 암호화 방식과 자신의 key_share(선택적)을 응답

3. EncryptedExtensions : 서버의 추가 옵션 정보를 클라이언트에게 전달

4. Certificate : 서버의 공개키 인증서를 클라이언트에게 전달

5. CertificateVerify : 서버가 해당 인증서의 개인키로 서명해 신뢰성을 증명

6. Finished : 서버가 핸드셰이크 완료를 알림

7. Finished : 클라이언트가 인증 확인 후 핸드셰이크 완료

TLS 1.3에서는 보안성과 성능을 모두 고려하여, 핸드셰이크가 1 RTT(왕복 시간)만에 완료됩니다. 또한, 일부 메시지는 선택적으로 포함되며, 이전 버전보다 더 간결하고 안전한 구조를 제공합니다.

* TLS 핸드셰이크는 전송 계층의 TCP 핸드셰이크가 끝난 후에 진행되는 보안 절차임.

5.4 대칭키 vs 공개키 암호화

️ 대칭키 암호화란?

“열쇠 하나로 잠그고 여는 방식”

대칭키 암호화는 하나의 동일한 비밀키(key)를 사용하여

데이터를 암호화하고 복호화합니다.

보내는 사람과 받는 사람이 같은 키를 공유해야 하기 때문에 빠르고 효율적하지만,

그 키를 안전하게 전달하는 것이 큰 과제입니다.

예시

편지를 보낼 때, 자물쇠로 잠근 뒤 그 열쇠를 따로 전달해야 한다면?

→ 열쇠가 도중에 유출될 위험이 큼

사용 알고리즘

: AES, DES, RC4 등

공개키 암호화란?

“잠그는 열쇠는 공개, 여는 열쇠는 비밀”

공개키 암호화는 열쇠가 두 개입니다.

공개키(Public Key): 누구나 볼 수 있음 → 데이터를 잠그는 용도
개인키(Private Key): 서버만 가지고 있음 → 데이터를 여는 용도

클라이언트는 서버의 공개키로 데이터를 암호화해서 전송하고,

서버는 그에 상응하는 개인키로만 이를 복호화할 수 있습니다.

→ 키를 미리 공유할 필요가 없으므로 안전하지만, 처리 속도가 느림

예시

어떤 금고를 누구나 잠글 수 있지만, 여는 열쇠는 금고 주인만 가지고 있음

사용 알고리즘

RSA, ECC 등

TLS에서 어떻게 쓰일까?

TLS에서는 두 방식의 장점을 모두 활용합니다.
1. 클라이언트가 서버의 공개키로 Pre-Master Key를 암호화해서 전송 (공개키 암호화)
2. 서버는 개인키로 이를 복호화하고, 클라이언트와 동일한 대칭키를 생성
3. 이후 실제 데이터는 대칭키로 암호화하여 빠르게 통신

✅ 결론

대칭키는 빠르지만 키 전달이 문제
공개키는 안전하지만 느림

→ 그래서 TLS에서는 공개키로 안전하게 대칭키를 주고받고, 대칭키로 데이터를 주고받는다.

6. 정리 및 배운 점

주제	키워드	실전 활용
쿠키	세션, 상태 유지	로그인 관리
캐시	Cache-Control, ETag	정적 자산 최적화
콘텐츠 협상	Accept-* 헤더	다국어, API 대응
인증	Basic, JWT	사용자 검증
보안	HTTPS, TLS, 인증서	민감 정보 보호

참고 자료

『이것이 취업을 위한 컴퓨터 과학이다』, p.464~479
https://developer.mozilla.org/ko/docs/Web/HTTP/Cookies
https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching
https://developer.mozilla.org/en-US/docs/Web/HTTP/Content_negotiation

https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html

[2편] HTTP 메서드부터 상태 코드, 주요 헤더까지

readyoun — Wed, 26 Mar 2025 03:23:47 +0900

“Top 10” HTTP Status Code explained you need to know as a Front End Developer

1. 개요

이번 포스트에서는 HTTP의 핵심 요소인 메서드, 상태 코드, 주요 헤더에 대해 살펴봅니다.

REST API 설계, 클라이언트-서버 통신 흐름 파악, 인증 및 보안 처리 등

실무 전반에서 자주 마주치는 필수 기초입니다.

2. HTTP 메서드 – 요청의 목적을 나타내는 방식

HTTP는 클라이언트가 서버에 요청을 보낼 때 무엇을 하고 싶은지를 명시합니다.
이는 HTTP 메서드(Method)를 통해 표현됩니다.

메서드	설명
GET	리소스를 조회할 때 사용. URL에 데이터를 포함하고 본문은 없음
HEAD	GET과 같지만 본문 없이 헤더 정보만 요청
POST	서버에 리소스를 생성할 때 사용. 본문에 데이터 포함
PUT	리소스를 전체 수정할 때 사용
PATCH	리소스를 일부 수정할 때 사용
DELETE	리소스를 삭제할 때 사용

✅ 예시: GET 요청

GET /posts/1 HTTP/1.1
Host: example.com

✅ 예시: POST 요청

POST /posts HTTP/1.1
Host: example.com
Content-Type: application/json
Content-Length: 52

{
  "title": "Hello",
  "body": "World"
}

3. 상태 코드 – 요청 결과를 알려주는 번호

HTTP 응답은 항상 세 자리 숫자인 상태 코드(Status Code) 를 포함하며,
클라이언트가 요청한 작업의 처리 결과를 알려줍니다.

✅ 상태 코드 범위

범위	설명
1xx	처리 중 (정보성 응답)
2xx	요청 성공
3xx	리다이렉션 (다른 URL로 이동 필요)
4xx	클라이언트 오류 (요청 문제)
5xx	서버 오류 (서버 문제)

✅ 자주 사용하는 2xx 상태 코드

코드	설명
200 OK	요청이 성공적으로 처리됨
201 Created	새로운 리소스가 생성됨 (POST)
202 Accepted	요청을 받았지만 아직 처리되지 않음

『이것이 취업을 위한 컴퓨터 과학이다』, p.454

✅ 리다이렉션 관련 3xx 상태 코드

리다이렉션(redirection)이란?

: 클라이언트가 요청한 자원이 다른 곳에 있을 때 다른 곳으로 요청을 이동시키는 것

『이것이 취업을 위한 컴퓨터 과학이다』, p.455

자원이 이동되었을 때 서버는 Location 헤더와 함께 리다이렉션 상태 코드를 반환하여
“이 자원은 여기로 옮겨졌어요” 라고 클라이언트에게 알려줍니다.

클라이언트는 이를 수신한 후, Location에 명시된 주소로 자동으로 재요청을 수행하고,
새 위치의 자원에 대한 응답을 새롭게 받아 처리하게 됩니다.

코드	설명
301 Moved Permanently	요청한 리소스가 영구적으로 이동됨
302 Found	일시적으로 이동됨
304 Not Modified	클라이언트 캐시 사용 가능 (변경 없음)

『이것이 취업을 위한 컴퓨터 과학이다』, p.455

리다이렉션(Redirection)의 종류와 상태 코드 비교

1. 영구적 리다이렉션 (Permanent Redirect)

자원이 영구적으로 이동되었음을 나타내는 리다이렉션입니다.

- 대표 상태 코드: `301 Moved Permanently`, `308 Permanent Redirect`

- 클라이언트는 이후부터 항상 새 URL을 사용해야 함

- 검색 엔진도 URL 변경을 반영함 (SEO 영향 있음)

『이것이 취업을 위한 컴퓨터 과학이다』, p.456

- `301`: 원래는 GET 요청만 고려했으나, 실제 구현에서는 POST → GET으로 바뀌는 경우도 있음

- `308`: 요청 방식(예: POST)을 그대로 유지하고 새 URL로 리다이렉트 (보다 명확한 동작)

2. 일시적 리다이렉션 (Temporary Redirect)

자원이 임시로 다른 위치에 있는 경우, 혹은 특정 조건에서만 위치가 변경된 경우 사용됩니다.

- 대표 상태 코드: `302 Found`, `307 Temporary Redirect`, `303 See Other`
- 이후 요청에서는 여전히 원래 URL을 사용할 수 있음

『이것이 취업을 위한 컴퓨터 과학이다』, p.457

- `302`: 전통적으로 많이 사용되었으나, 명확한 의미 없이 POST → GET으로 바뀌는 등 불명확성 존재
- `307`: 요청 메서드를 그대로 유지하여 재요청 (POST → POST)
- `303`: 메서드를 GET으로 변경하여 리소스를 다시 요청하는 방식 (주로 응답 페이지 안내 시 사용)

✅ 상황에 따라 적절한 리다이렉션 선택이 중요합니다!

상태 코드	설명	요청 방식 유지 여부	주 용도
301	영구 이동	유지 안 될 수 있음	URL 구조 변경
308	영구 이동	유지됨	REST API 안전한 리다이렉션
302	임시 이동	유지 안 됨 (대개 GET)	전통적 웹 페이지 이동
307	임시 이동	유지됨	폼 제출 등 보존 필요
303	다른 위치 보기	GET으로 변경됨	응답 안내 페이지 등

REST API에서는 308, 307을 사용하는 것이 안전하며, 브라우저 기반 응답 페이지 안내에는 303이 유용합니다.

✅ 클라이언트 오류 4xx 상태 코드

코드	설명
400 Bad Request	잘못된 요청 형식
401 Unauthorized	인증 필요 (로그인 안 됨)
403 Forbidden	권한 없음 (로그인해도 접근 불가)
404 Not Found	존재하지 않는 자원 요청
405 Method Not Allowed	지원하지 않는 메서드 사용

『이것이 취업을 위한 컴퓨터 과학이다』, p.457

401 vs 403의 차이:
401은 인증(authentication)이 필요함,
403은 인증했지만 인가(authorization)가 없음.

[ 여기서 잠깐! ]
인증(Authentication) vs 인가(Authorization)

구분 인증 (Authentication) 인가 (Authorization)

의미 "당신이 누구인지 확인" "당신이 이걸 할 수 있는 권한이 있는가?"

목적 사용자의 신원 확인 접근 권한 부여 여부 결정

예시 로그인 (ID/PW, 토큰 등) 관리자만 설정 페이지 접근 허용

상태 코드 관련 401 Unauthorized 403 Forbidden

인증은 "너 누구야?", 인가는 "너 이거 해도 돼?"

인증 vs 인가 자세히 : ‍ 쉽게 이해하는 Authentication vs Authorization 차이

✅ 서버 오류 5xx 상태 코드

코드	설명
500 Internal Server Error	서버 내부 처리 오류
502 Bad Gateway	중간 게이트웨이 서버 오류

『이것이 취업을 위한 컴퓨터 과학이다』, p.458

4. HTTP 주요 헤더

HTTP 헤더는 요청과 응답 메시지에 포함되어 메타데이터를 전달합니다.
헤더는 이름과 값으로 구성되며, Header-Name: value 형식을 가집니다.

✅ 요청 메시지에서 자주 쓰는 헤더

헤더	설명
Host	요청 대상 도메인 이름 (필수)
User-Agent	브라우저/클라이언트 정보
Referer	이전 요청 페이지의 주소 (출처)

✅ 응답 메시지에서 자주 쓰는 헤더

헤더	설명
Server	서버 소프트웨어 정보
Location	새로 생성된 리소스 주소 (POST 201, 리다이렉션 3xx)
Allow	지원하는 메서드 목록 (405 응답 시 포함됨)

✅ 요청/응답 공통으로 사용되는 헤더

헤더	설명
Content-Type	본문의 타입 (예: application/json, text/html)
Content-Length	본문의 크기 (바이트 단위)
Content-Language	콘텐츠 언어 (예: ko-KR)
Content-Encoding	압축 방식 (예: gzip)
Date	메시지 생성 시점
Connection	연결 방식 (`keep-alive`, `close`)

6. 면접 질문 예시

Q. HTTP의 킵 얼라이브(Keep-Alive)란 무엇인가요?

HTTP/1.0은 요청마다 TCP 연결을 새로 맺는 비지속 연결 방식이었지만,
HTTP/1.1부터는 기본적으로 연결을 끊지 않고 지속 연결(Persistent Connection)을 유지합니다.

Keep-Alive는 이러한 지속 연결을 가능하게 하는 HTTP 헤더로,
여러 개의 요청/응답을 하나의 TCP 연결로 처리할 수 있도록 합니다.

장점: 연결 수 감소 → 속도 향상 + 리소스 절약
예시 헤더: Connection: keep-alive

HTTP/1.0에서는 요청을 보낼 때마다 매번 새로운 TCP 연결을 맺고, 응답 후 즉시 연결을 끊는 방식인 비지속 연결을 사용했습니다. 하지만 HTTP/1.1부터는 기본적으로 지속 연결(Persistent Connection)을 지원하며, Connection: keep-alive 헤더를 통해 하나의 TCP 연결을 재사용할 수 있게 되었습니다. 이를 통해 여러 개의 요청과 응답을 하나의 연결로 처리할 수 있어, 연결 수를 줄이고 네트워크 자원을 절약하며 전체 통신 속도를 향상시킬 수 있습니다.

Q. HTTP 1.1과 HTTP 2.0의 차이점은 무엇인가요?

구분	HTTP/1.1	HTTP/2.0
데이터 형식	텍스트 기반	바이너리 기반
연결 방식	요청당 순차 처리 (HOL blocking 발생)	멀티플렉싱으로 동시 요청 가능
서버 푸시	미지원	서버 푸시(Server Push) 가능
성능	헤더 중복 많음, 느린 처리	헤더 압축 + 빠른 처리

HTTP/1.1은 텍스트 기반 프로토콜로, 요청을 순차적으로 처리하기 때문에 하나의 요청이 끝날 때까지 다음 요청을 대기해야 하는 HOL(Head-of-Line) 블로킹 문제가 있었습니다.

반면 HTTP/2.0은 바이너리 기반 프로토콜이며, 하나의 연결 내에서 여러 요청과 응답을 동시에 주고받을 수 있는 멀티플렉싱(Multiplexing)을 지원하여 병목 현상을 해결했습니다. 또한 헤더를 압축해 오버헤드를 줄이고, 서버가 클라이언트 요청 없이도 데이터를 푸시할 수 있는 서버 푸시 기능도 도입되어, 웹 페이지 로딩 성능이 크게 개선되었습니다.

Q. HTTP 메서드인 GET과 POST의 차이는 무엇인가요?

구분	GET	POST
목적	데이터 조회	데이터 생성 / 전송
데이터 전달 위치	URL (쿼리 스트링)	HTTP 본문 (Body)
브라우저 캐시	가능	일반적으로 불가능
예시	`/search?q=chatgpt`	`/login` (본문에 id/pw 포함)

GET 메서드는 리소스를 조회할 때 사용되며, 전달할 데이터가 URL의 쿼리 문자열에 포함됩니다. 반면 POST 메서드는 리소스를 생성하거나 서버로 데이터를 전송할 때 사용되며, 데이터는 HTTP 메시지의 본문(Body)에 담깁니다.

GET 요청은 브라우저의 캐시에 저장되거나 URL로 공유될 수 있는 반면, POST는 그렇지 않기 때문에 민감한 정보를 전송할 때는 반드시 POST 방식을 사용하는 것이 바람직합니다.

특히 비밀번호, 토큰, 주민번호와 같은 정보는 URL에 노출될 경우 보안 사고로 이어질 수 있으므로, POST 본문을 활용하고 가능하면 HTTPS를 통해 암호화하여 전송해야 안전합니다.

Q. HTTP 메서드인 PUT과 PATCH의 차이는 무엇인가요?

구분	PUT	PATCH
목적	전체 리소스 교체	일부 필드 수정
데이터 구조	전체 객체 필요	변경될 필드만 포함
멱등성	멱등 (같은 요청 여러 번 가능)	멱등일 수도, 아닐 수도 있음

PUT 메서드는 전체 리소스를 대체하는 방식으로 동작하며, 해당 리소스를 통째로 덮어쓰기 때문에 요청 본문에는 전체 객체 구조가 포함되어야 합니다.

반면 PATCH는 리소스의 일부 필드만 선택적으로 수정할 때 사용되며, 수정하고자 하는 필드만 전달하면 됩니다.

예를 들어 사용자의 모든 정보를 업데이트할 때는 PUT을 사용하고, 비밀번호만 변경할 경우 PATCH를 사용하는 것이 적절합니다. PUT은 동일한 요청을 여러 번 보내더라도 결과가 같기 때문에 멱등성을 가지지만, PATCH는 구현 방식에 따라 멱등성이 보장되지 않을 수도 있습니다.

Q. 리다이렉션의 정확한 의미는?

리다이렉션은 서버가 클라이언트에게
“요청한 리소스는 다른 곳으로 이동되었어요” 라고 알려주는 응답입니다.

대표 상태 코드: 301, 302, 303, 307, 308
함께 전달되는 Location 헤더를 통해 이동할 URL 경로가 포함됩니다.

HTTP/1.1 301 Moved Permanently
Location: /new-page

리다이렉션은 서버가 클라이언트에게 요청한 리소스가 다른 위치로 이동되었음을 알리는 응답을 보내는 것을 말합니다. 이때 클라이언트는 응답에 포함된 Location 헤더 값을 참고하여 자동으로 새 위치로 이동합니다.

대표적인 상태 코드는 301 Moved Permanently, 302 Found, 303 See Other, 307 Temporary Redirect, 308 Permanent Redirect 등이 있으며, 각각 리다이렉션의 성격에 따라 영구/임시 여부와 요청 방식 유지 여부 등이 다릅니다. 예를 들어 301은 해당 리소스가 완전히 이동되었음을 의미합니다.

Q. HTTP 요청 메시지를 보낸 클라이언트들이 이전에 접속한 URL을 알고 싶을 때?

➡️ Referer~~(오타 아님)~~ 헤더를 확인하면 됩니다.

Referer: https://www.example.com/previous-page

브라우저가 이전에 방문한 페이지의 URL을 서버로 전송함
사용 예시: 유입 경로 분석, 보안 정책 설정 (e.g., 이미지 hotlinking 방지)

이전 페이지에서 현재 페이지로 이동했을 때의 URL 정보를 알고 싶다면, 요청에 포함된 Referer 헤더를 확인하면 됩니다.

이 헤더는 클라이언트(주로 브라우저)가 현재 요청을 보내기 전 어떤 페이지에서 왔는지를 나타내는 정보를 담고 있어, 유입 경로 분석이나 리퍼러 기반 접근 제어 등에 사용됩니다.

예를 들어, 이미지 핫링크 방지를 위해 특정 사이트에서 온 요청만 허용하는 등의 보안 정책을 설정할 때도 활용됩니다.

Q. HTTP 요청 메시지를 보낸 클라이언트들의 접속 정보를 알고 싶을 때?

➡️ User-Agent 헤더를 확인합니다.

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) Chrome/123.0

브라우저, 운영체제, 디바이스 정보가 포함됨
사용 예시: 사용자 환경별 렌더링, 크롤러 식별 등

클라이언트의 브라우저 종류나 운영체제, 디바이스 정보 등을 확인하고 싶을 때는 요청 메시지에 포함된 User-Agent 헤더를 확인합니다.

이 헤더에는 예를 들어 "Mozilla/5.0 (Windows NT 10.0; Win64; x64) Chrome/123.0" 같은 문자열이 포함되며, 이를 통해 접속한 클라이언트의 환경을 유추할 수 있습니다. 이 정보는 다양한 디바이스에 맞게 화면을 조정하거나, 웹 크롤러와 일반 사용자를 구분하는 용도로도 사용됩니다.

7. 마무리

이번 포스트에서는 다음을 학습했습니다.

HTTP 메서드를 통해 요청의 목적을 정의한다.
상태 코드를 통해 요청 결과를 숫자로 표현한다.
헤더를 통해 다양한 요청/응답 정보를 함께 전달한다.

다음 포스트에서는 HTTPS, TLS, 인증과 상태 유지 (쿠키/세션/토큰) 등을 심화 학습할 예정입니다.

참고 자료

『이것이 취업을 위한 컴퓨터 과학이다』, p.448~463
“Top 10” HTTP Status Code explained you need to know as a Front End Developer
MDN Web Docs – HTTP Methods
MDN Web Docs – HTTP Status Codes

[1편] 브라우저는 어떻게 서버를 찾을까? – DNS와 HTTP 메시지 구조까지

readyoun — Wed, 26 Mar 2025 01:47:24 +0900

flaticon - kerismaker

1. 들어가며

웹 개발을 하다 보면 가장 기초적이면서도 중요한 개념이 바로 HTTP입니다.

하지만 그 시작점인 DNS, 그리고 HTTP 메시지의 구조에 대해 정확히 알고 있어야 합니다.

이번 글에서는 다음의 흐름을 따라가며 웹 요청의 여정을 함께 따라가보겠습니다.

사용자가 브라우저에 www.example.com을 입력하면,
어떻게 서버의 IP를 찾고,
어떤 형식의 메시지를 주고받으며,
어떻게 웹 페이지가 뜨는지?

2. DNS와 URI/URL – 웹 통신의 출발점

2-1. 도메인 네임과 DNS

컴퓨터는 IP 주소(예: 1.2.3.4)로 통신하지만,
우리는 www.example.com 같은 도메인 이름을 사용합니다.

이걸 IP로 바꿔주는 시스템이 바로 DNS (Domain Name System) 입니다.

즉, DNS는 사람이 읽기 쉬운 도메인 네임을

→ 컴퓨터가 이해할 수 있는 IP 주소로 변환(resolve) 해줍니다.

『이것이 취업을 위한 컴퓨터 과학이다』 p.432

DNS 서버 역할: 사용자가 입력한 도메인을 해석하여 IP를 반환
DNS 질의 흐름:
1. 루트 네임 서버
2. 최상위 도메인(TLD, .com 등)
3. 권한 네임 서버(예: example.com을 관리)

예시 흐름: www.example.com → 루트 → TLD → NS → IP 주소 반환

2-2. FQDN과 도메인 구성

www.example.com은 FQDN (Fully Qualified Domain Name)
→ 정확한 서버를 찾기 위한 전체 경로
구성: 호스트 이름(www) + 도메인 이름(example) + 최상위 도메인(com)

면접 대비 포인트:
FQDN이란 무엇인가요? → "정확히 하나의 호스트를 지칭할 수 있는 전체 도메인 네임입니다."

3. Name Server와 DNS 질의 과정

3-1. 네임 서버(Name Server)란?

DNS 질의를 처리하는 서버로, 도메인 이름을 관리하며 계층 구조를 가집니다.

루트 네임 서버: 최상위 .com, .org 등으로 연결
TLD 네임 서버: .com, .net 등 관리
권한 네임 서버: 실제 도메인의 IP 정보 보유

3-2. 질의 흐름과 캐싱

『이것이 취업을 위한 컴퓨터 과학이다』 p.434

클라이언트 → 로컬 DNS 서버 (ISP 또는 OS 내)
로컬 DNS 서버가 없으면 재귀 질의를 통해 루트부터 탐색
자주 쓰이는 도메인은 DNS 캐시에 저장되어 응답 속도 개선

캐시의 TTL(Time To Live)은 제한 시간 내 재사용 가능
대표적인 퍼블릭 DNS: 8.8.8.8 (Google), 1.1.1.1 (Cloudflare)

4. DNS 레코드 타입 – 도메인과 IP를 연결하는 방식

DNS 서버에는 다양한 형태의 레코드(기록)가 존재합니다. 이를 통해 도메인 이름이 어떤 리소스를 가리키는지 정의할 수 있습니다.

레코드 타입	설명
A	도메인 → IPv4 주소
AAAA	도메인 → IPv6 주소
CNAME	도메인 → 다른 도메인 이름
NS	도메인에 대한 권한 네임 서버 지정
MX	메일 서버 관련 레코드

실무 예시:
example.com → A 레코드 → 1.2.3.4
www.example.com → CNAME → example.com

5. URI와 URL – 리소스를 가리키는 방식

5-1. URI, URL, URN의 차이

용어	의미	예시
URI	자원 식별자 전체 개념	urn:isbn:0451450523
URL	자원의 위치 (주소)	https://example.com/index.html
URN	이름 기반 식별	urn:isbn:1234

→ URL은 URI의 한 형태이며, 우리가 주로 사용하는 주소는 대부분 URL입니다.

6. URL의 구성 요소 상세 분석

https://www.example.com:8042/over/there?name=ferret#nose
└──────┬──────┘ └────┬────┘ └──────┬────┘ └──────┬──────┘ └───┬───┘
 scheme  host(DN/IP)   port      path         query         fragment

주요 구성요소

요소	설명
scheme	프로토콜 명시 (http, https 등)
authority	호스트 주소 (도메인 or IP)
path	리소스의 경로 (/images/logo.png)
query	파라미터 (ex. ?name=value)
fragment	특정 위치(anchor)로 스크롤 이동

실무 예시:
/search?keyword=book → 검색 키워드
#section1 → 페이지 내 특정 위치로 이동

7. HTTP의 특징 4가지

각 특징은 HTTP가 웹에서 널리 쓰이는 이유이기도 하며, API 설계나 성능 최적화, 인증 처리 등에서 자주 언급됩니다.

① 요청 응답 기반 프로토콜

HTTP는 클라이언트가 요청(Request)을 보내고, 서버가 그에 대한 응답(Response)을 보내는 구조로 동작합니다.

- 브라우저, 앱 등이 요청을 보내고, 서버는 그에 맞는 HTML, JSON 등의 데이터를 응답합니다.
- 단방향 통신이기 때문에, 서버는 클라이언트에게 먼저 메시지를 보낼 수 없습니다.

실전 포인트:
서버가 먼저 메시지를 보내야 하는 경우는 WebSocket, SSE 같은 별도 기술이 필요합니다.

② 미디어 독립적 프로토콜

HTTP는 전송하는 데이터의 종류에 제한이 없습니다.

HTML, CSS, JS, 이미지, JSON, PDF 등 모든 콘텐츠 유형을 전송할 수 있으며,
어떤 콘텐츠가 오가는지는 Content-Type 헤더를 통해 명시합니다.

Content-Type: application/json

이로 인해 HTTP는 문서 전송뿐 아니라

REST API, 이미지 전송, 동영상 스트리밍 등 모든 웹 기능에 대응할 수 있습니다.

✅ 이 특성 덕분에 웹이 ‘문서 중심’에서 ‘앱 플랫폼’으로 진화할 수 있었습니다.

③ 스테이트리스 프로토콜 (Stateless)

HTTP는 상태를 유지하지 않는(stateless) 프로토콜입니다.

서버는 각 요청이 독립적이라고 가정하고, 이전 요청의 정보를 저장하지 않습니다.

이 덕분에 서버 구조는 단순하고, 확장성(Scalability)이 뛰어나지만,

로그인 상태 유지, 장바구니 유지 등 사용자 상태 저장이 필요한 기능은

별도 기술로 구현해야 합니다. (→ 쿠키, 세션, 토큰 등)

면접 단골 질문:
“Stateless한 HTTP에서 사용자 인증 상태는 어떻게 유지할까요?”

④ 지속 연결 프로토콜 (Persistent Connection)

기본적으로 HTTP는 요청-응답 후 연결을 끊었지만,
HTTP/1.1부터는 연결을 유지하여 여러 요청을 한 번에 처리할 수 있는 ‘지속 연결’을 지원합니다.

예전 방식: 요청할 때마다 TCP 연결 → 비효율
지속 연결: 하나의 TCP 연결로 여러 요청/응답 처리 → 지연(latency) 감소, 속도 개선

Connection: keep-alive

특히 브라우저는 HTML, CSS, JS, 이미지 등

다수의 리소스를 병렬로 요청해야 하므로

지속 연결은 필수적입니다.

이후 등장한 HTTP/2, HTTP/3는 이 특성을 더욱 강화합니다. (멀티플렉싱, 스트림 병렬화 등)

이처럼 HTTP의 4가지 특징은 단순한 개념이 아니라,

웹의 작동 원리와

️ 서비스 설계,

보안 및 인증 처리,

성능 최적화에까지

영향을 줍니다.

MIME 타입 (Content-Type)

HTTP는 다양한 미디어 타입을 지원합니다.

타입	서브타입	설명
text	plain, html, css	텍스트 문서, HTML, 스타일
image	jpeg, png, gif	이미지 리소스
video	mp4, webm	영상
application	json, pdf	데이터 포맷

8. HTTP 메시지 구조

HTTP 메시지는 요청과 응답 두 종류로 나뉘며, 다음과 같은 구조를 가집니다.

✅ 요청 메시지 구조

GET /index.html HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0
Accept: text/html

시작 라인: 요청 방식(GET), 경로, HTTP 버전
헤더 필드: 요청 정보들 (브라우저 종류, 허용 포맷 등)
본문: (POST일 경우) 추가 데이터

✅ 응답 메시지 구조

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 648

<html>...</html>

상태 라인: HTTP 버전 + 상태 코드 + 상태 메시지
헤더 필드: 응답 정보
본문: 실제 콘텐츠

면접 질문

Q. HTTP가 스테이트풀한지, 스테이트리스한지에 대해 그 이유와 함께 설명하세요.

HTTP는 스테이트리스(Stateless) 프로토콜입니다.
특징:
- 각 요청은 독립적으로 처리
- 이전 요청의 정보를 저장하지 않음
- 쿠키, 세션으로 상태 관리 보완
장점: 서버 확장성 향상, 효율적인 자원 관리
단점: 클라이언트의 추가 정보 전송 필요

예: HTTP는 각각의 요청이 독립적으로 처리되는 스테이트리스 프로토콜로, 서버가 클라이언트의 이전 요청 정보를 저장하지 않아 확장성과 자원 관리 측면에서 효율적이지만, 상태 유지가 필요한 경우 쿠키나 세션과 같은 추가적인 방법을 사용해야 합니다.

Q. 웹 브라우저에서 'https://www.google.com' 접속 과정

DNS 조회: 도메인 이름 → IP 주소 변환
TCP 연결 수립 (3-way handshake)
SSL/TLS 핸드셰이크
HTTP 요청 전송
서버 응답 처리
웹 브라우저 렌더링

예: 웹 브라우저에서 구글 접속 시, DNS를 통해 도메인 이름을 IP 주소로 변환하고, TCP 3-way handshake로 연결을 수립한 후, SSL/TLS 핸드셰이크로 보안 연결을 설정합니다. 이후 HTTP 요청을 전송하고 서버로부터 응답을 받아 웹 브라우저가 이를 렌더링하여 사용자에게 보여줍니다.

Q. 도메인 네임 웹사이트 연동 과정

도메인 등록 업체에서 도메인 구매
네임서버 설정
DNS 레코드 설정 (A 레코드, CNAME 등)
전파 시간 대기 (24-48시간)
DNS 설정 확인 및 연결 테스트

예: 도메인 네임을 웹사이트에 연동하기 위해서는 먼저 도메인 등록 업체에서 도메인을 구매하고, 호스팅 서버의 네임서버를 설정한 후, A 레코드나 CNAME 등의 DNS 레코드를 설정합니다. 이후 DNS 설정이 전파되는 시간(보통 24-48시간)을 기다린 후, 연결이 제대로 되었는지 확인하고 테스트합니다.

마무리: HTTP 요청의 출발점 정리

이번 글에서는 다음을 중심으로 정리했습니다.

브라우저가 도메인을 입력하면, DNS를 통해 IP를 조회
조회된 IP로 TCP 연결 후, HTTP 요청 메시지 전송
HTTP 4가지 특징
요청 메시지에는 메서드, 경로, 헤더, 본문이 포함
응답 메시지로는 상태 코드 + 콘텐츠가 돌아옴

이 구조는 API 설계, 네트워크 디버깅, 면접 질문 어디서든 기반이 됩니다.

다음 편 예고

✅ [2편]에서는 상태 코드, 쿠키/세션, HTTPS, 그리고 HTTP의 진화(1.1/2.0/3.0)를 살펴봅니다.

서버는 어떻게 로그인 상태를 기억할까요? HTTPS는 왜 필요한 걸까요?

참고 자료

『이것이 취업을 위한 컴퓨터 과학이다』 p.431~447
MDN - HTTP 메시지
Cloudflare - What is DNS?

구분	인증 (Authentication)	인가 (Authorization)
의미	"당신이 누구인지 확인"	"당신이 이걸 할 수 있는 권한이 있는가?"
목적	사용자의 신원 확인	접근 권한 부여 여부 결정
예시	로그인 (ID/PW, 토큰 등)	관리자만 설정 페이지 접근 허용
상태 코드 관련	401 Unauthorized	403 Forbidden

readyoun's devlog

복잡도와 핵심 자료구조 (C++, Java, Python 예시)

[5.1 복잡도] 이해 완전 정복

✅ 복잡도가 뭐지?

⏱️ 5.1.1 시간 복잡도

시간 복잡도란?

왜 중요할까?

대표적인 시간 복잡도

빅오 표기법 (Big-O Notation)

⛔ 왜 상수는 무시할까?

⌛ 5.1.2 공간 복잡도

5.1.3 자료 구조별 시간 복잡도

✅ 평균 시간 복잡도 (일반적인 상황)

❗ 최악의 시간 복잡도 (엣지 케이스)

평균 vs 최악 복잡도 정리

언제 어떤 걸 선택할까?

한 문장 요약

[5.2 복잡도] 선형 자료 구조

5.2.1 연결 리스트 (Linked List)

✅ 연결 리스트란?

구성 요소

연결 리스트의 종류

특징 요약

⏱️ 시간 복잡도 정리

C++ 코드 예시 (STL list 활용)

Java와 Python 예시

Java: LinkedList 클래스

Python: collections.deque

정리

5.2.2 배열 (Array)

✅ 배열이란?

배열의 특징

접근 방식

⚔️ 배열 vs 연결 리스트

⏱️ 배열의 시간 복잡도

C/C++ 배열 예시

Java 배열 예시

Python 배열 (list) 예시

정리

5.2.3 벡터 (Vector)

✅ 벡터란?

벡터의 특징

배열과의 차이점

⏱️ 벡터의 시간 복잡도

amortized time (분할 상환 시간 복잡도)

C++ 벡터 예시

Java ArrayList 예시

Python list 예시

정리

5.2.5 큐 (Queue)

✅ 큐란?

일상 예시

주요 연산

⏱️ 시간 복잡도

C++ STL 큐 예시

Java Queue 예시

Python 큐 예시 (collections.deque 추천)

큐는 언제 사용할까?

5.3.1 그래프 (Graph)

✅ 그래프란?

예시

구성 요소

그래프의 종류

⛓️ 그래프의 표현 방식

⏱️ 시간 복잡도 참고

Python 그래프 인접 리스트 예시

Python 인접 행렬 예시

C++ 그래프 표현 예시

1. 인접 리스트 (vector of vector)

2. 인접 행렬

Java 그래프 표현 예시

1. 인접 리스트 (ArrayList)

2. 인접 행렬

그래프는 언제 쓰일까?

5.3.2 트리 (Tree)

✅ 트리란?

기본 용어 정리

깊이, 높이, 레벨

트리의 특징

이진 트리 (Binary Tree)

C++ 코드 예시 (STL `list` 활용)

Java: `LinkedList` 클래스

Python: `collections.deque`

Python 배열 (`list`) 예시

Python 큐 예시 (`collections.deque` 추천)

C++ 예시 (`priority_queue`)

Java 예시 (`PriorityQueue`)

C++ `priority_queue` 예시

Java `PriorityQueue` 예시

Python `dict`

C++ `map`, `unordered_map`

Java `HashMap`, `TreeMap`

Python `set`

C++ `set`, `unordered_set`

Java `HashSet`