구름 개발일기장

Hibernate Connection Release Mode 커넥션 관리 전략 _ JPA @Transactional

구름뭉치 — Sat, 25 Apr 2026 23:00:44 +0900

Hibernate의 connection release mode는 JDBC 커넥션을 언제 획득하고 언제 풀에 반환할지를 결정하는 전략이다.
이 설정은 단독으로 동작하는 것이 아니라, Spring의 @Transactional 전파 전략과 맞물려서 실제 커넥션 생명주기를 결정한다.
이 글에서는 Spring Boot + JPA 환경에서 커넥션이 풀에서 빠져나가고 돌아오는 과정을 코드 레벨까지 확인한다.

1. Connection Release Mode란?

1. Hibernate의 5가지 커넥션 획득/반환 모드

Hibernate의 커넥션 관리 전략은 PhysicalConnectionHandlingMode라는 enum으로 정의된다. 이 enum은 두 가지 축의 조합으로 구성된다.

획득 시점 (Connection Acquisition Mode)

IMMEDIATE: Session 생성 시점에 즉시 커넥션 획득
AS_NEEDED (DELAYED): 실제 SQL이 필요한 시점까지 획득을 지연

반환 시점 (Connection Release Mode)

ON_CLOSE (HOLD): Session이 닫힐 때까지 커넥션 유지
AFTER_STATEMENT: 매 SQL 실행 후 즉시 반환
AFTER_TRANSACTION: 트랜잭션 종료 후 반환
BEFORE_TRANSACTION_COMPLETION: 트랜잭션 커밋/롤백 직전에 반환

이 축들의 조합으로 다음과 같은 모드들이 만들어진다:

모드	획득	반환
DELAYED_ACQUISITION_AND_HOLD	지연	Session 종료 시
DELAYED_ACQUISITION_AND_RELEASE_AFTER_STATEMENT	지연	매 SQL 후
DELAYED_ACQUISITION_AND_RELEASE_AFTER_TRANSACTION	지연	트랜잭션 후
DELAYED_ACQUISITION_AND_RELEASE_BEFORE_TRANSACTION_COMPLETION	지연	커밋/롤백 직전
IMMEDIATE_ACQUISITION_AND_HOLD	즉시	Session 종료 시

Q. 왜 모드가 8개가 아닌 5개만 존재할까?

커넥션 획득이 즉시일 때를 봐보자.

커넥션을 세션 수립 시 즉시 획득했는데 세션 해제 전 커넥션을 해제하는 경우는 3가지이다.

세션 종료 전 조기 반환 모드 3가지

- AFTER_STATEMENT / AFTER_TRANSACTION / BEFORE_TRANSACTION_COMPLETION

그러면 커넥션을 세션 해제 전에 조기에 해제했고, 세션 내에서 다시 트랜잭션을 사용하는 경우 커넥션 획득이 어떻게 이뤄지는걸까?

이려면 커넥션을 세션 중간에 다시 획득하는 DELAYED 상황이라는 모순적 상황이 발생한다.

따라서, 세션 시작 시 커넥션 즉시 획득의 경우 세션 종료까지 커넥션을 유지하는 HOLD 모드와만 조합할 수 있게 되는 것이다.

그래서 모순적 모드 3개는 제공되지 않는다.

Q. 세션 수립 시 커넥션 획득 주의점 (feat. OSIV)

Hibernate 세션 수립 시점은 언제일까?

OSIV 상태에 따라 달라진다.

OSIV가 true라면 클라이언트의 HTTP 요청이 들어오는 순간, 서블릿 필터나 인터셉터 단에서 이미 Hibernate 세션이 생성된다. 그러면 커넥션 획득 모드가 즉시인 경우 DB 트랜잭션 등 비지니스 로직이 전혀 발생하지 않았는데도 먼저 DB 커넥션 풀에서 커넥션을 하나 빼오고 세션이 종료될 때까지 들고있게 된다.

이렇게 되면 매우 비효율적인 DB 커넥션 사용이 이뤄지게 되므로 커넥션 풀을 급격히 고갈시키고 성능 문제를 발생시키게 된다.

OSIV가 false인 경우는 @Transactional 이 달려있는 메소드부터 Hibernate 세션이 수립된다.

2. Hibernate 기본값 vs Spring Boot 기본값 — 흔한 오해

여기서 많은 개발자가 혼동하는 지점이 있다. Hibernate 자체의 기본값과 Spring Boot 환경에서의 기본값이 다르다.

Hibernate 단독 (resource-local): DELAYED_ACQUISITION_AND_RELEASE_AFTER_TRANSACTION
지연 획득 트랜잭션 후 반환
Spring Boot + JPA (via HibernateJpaVendorAdapter): DELAYED_ACQUISITION_AND_HOLD
지연 획득 세션 종료까지 유지

왜 Spring은 Hibernate의 기본값을 덮어쓸까? HibernateJpaVendorAdapter 소스 코드를 확인해보자.

// HibernateJpaVendorAdapter.java (Spring Framework)
private Map<String, Object> buildJpaPropertyMap(boolean connectionReleaseOnClose) {
    Map<String, Object> jpaProperties = new HashMap<>();
    // ...

    if (connectionReleaseOnClose) {
        jpaProperties.put(
            "hibernate.connection.handling_mode", 
            PhysicalConnectionHandlingMode.DELAYED_ACQUISITION_AND_HOLD
        );
    }
}

위 코드의 `connectionReleaseOnClose`는 `HibernateJpaDialect`의 `prepareConnection` 플래그에서 오며, 이 값은 기본적으로 `true`다.

Spring은 `@Transactional`로 트랜잭션을 시작할 때 단순히 DB에 트랜잭션 시작 명령만 내리지 않는다. 내부적으로 JDBC Connection을 가져와 격리 수준(isolation level)과 readOnly 속성을 직접 설정하는 사전 작업(`prepareConnection`)을 수행한다.

Q. 만약 Hibernate가 트랜잭션 도중 커넥션을 풀에 반납해 버리면 어떻게 될까?

A. 동일한 논리적 트랜잭션 안에서 다음 쿼리를 실행(또는 트랜잭션 전파)할 때, 풀에서 완전히 새로운 물리적 커넥션을 꺼내오게 된다. 이 새로운 커넥션에는 Spring이 처음에 설정해 둔 JDBC 상태(격리 수준, readOnly 등)가 적용되어 있지 않기 때문에 애써 적용한 설정이 무용지물이 되는 현상이 발생하게 된다.

결국 Spring은 트랜잭션 생명주기 동안 자신이 직접 커넥션 설정을 온전히 통제하기 위해, "세션이 닫힐 때까지 원래 쓰던 커넥션을 유지하라(HOLD)"고 Hibernate의 기본값을 강제로 덮어쓰는 것이다.

핵심
Spring Boot + JPA 환경에서는 별도 설정 없이 DELAYED_ACQUISITION_AND_HOLD가 기본값이다.
커넥션은 Session(EntityManager)이 닫힐 때 반환된다.

이 글은 운영 환경 기반으로 spring.jpa.open-in-view=false 설정을 기본 전제로 한다. OSIV=ON 환경에서 특별히 다르게 동작하는 부분이 있을 때만 별도로 표시한다.

2. 트랜잭션 전파 전략과 커넥션 생명주기

Spring Boot의 기본 모드가 HOLD라는 것은 확인했다. 이제 @Transactional의 전파 전략에 따라 커넥션 생명주기가 어떻게 달라지는지 살펴보자.

1. REQUIRED — 트랜잭션 종료 시 반환

가장 일반적인 케이스다:

@Transactional  // propagation = REQUIRED (기본값)
fun updateTemplate() {
    repository.findById(1)     // ← 커넥션 획득 (DELAYED)
    repository.save(entity)    // ← 같은 커넥션 유지
}                              // ← 트랜잭션 커밋 → EntityManager 종료 → 커넥션 반환

REQUIRED는 실제 트랜잭션을 시작한다.

actualTransactionActive는 true가 되고, EntityManager는 트랜잭션에 바인딩된다. 트랜잭션이 커밋(또는 롤백)되면 EntityManager가 닫히고, 그때 HOLD 모드에 따라 커넥션이 풀에 반환된다.

2. SUPPORTS — 메서드 종료 시 반환

이제 핵심적인 SUPPORTS 케이스다. 바깥에 트랜잭션이 없는 상태에서 SUPPORTS로 진입한 경우를 보자.

@Transactional(propagation = SUPPORTS, readOnly = true)
fun search(keyword: String) {
    repository.findByKeyword(keyword)  // EM 생성 → Conn 획득 → SELECT → EM close → Conn 반환
    repository.findRelated(ids)        // 또 새 EM 생성 → 새 Conn 획득 → ... → 반환
}

SUPPORTS는 기존 트랜잭션이 없으면 트랜잭션을 시작하지 않는다.

OSIV=FALS + SUPPORTS + outer Tx 없음 이라면 JpaTransactionManager.doBegin()이 호출되지 않는다.

따라서 TransactionSynchronizationManager에 EM이 바인딩되지 않는다. 매 repository 호출마다 EM을 새로 만들고 close 하게 된다.

3. HOLD 모드에서의 중요한 사실

Spring Boot 기본값인 HOLD 모드에서 OSIV가 TRUE라면 SUPPORTS라 하더라도 커넥션이 쿼리마다 반환되지 않는다. 첫 번째 쿼리에서 획득한 커넥션이 메서드 끝까지 유지된다.

OSIV에 따른 동작 차이 !중요!

OSIV ON
- Session이 HTTP 요청 단위로 살아있어 HOLD가 의미를 갖는다. 첫 쿼리의 Connection이 메서드 종료 후에도 hold된다.
따라서, SUPPORTS의 커넥션 수립은 실제 쿼리가 발생할 때까지 DELAYED 되더라도 반환 시점은 세션 종료 시점이 된다.
OSIV OFF
- SharedEntityManagerCreator가 statement 단위로 EM을 생성/close하므로, 두 쿼리는 별도의 Connection을 사용한다. 사실상 AFTER_STATEMENT처럼 동작하게 된다.

이 원고에서는 OSIV = FALSE 가 설정되어있다고 가정하고 다룬다.

그렇다면 기본 전파전략인 REQUIRED 와 SUPPORTS의 차이점이 뭘까?

	REQUIRED	SUPPORTS (outer tx 없음)
획득 시점	메서드 진입 시 (setAutoCommit(false) 시점)	매 쿼리 직전
반환 시점	트랜잭션 커밋 시	매 쿼리 직후
Tx 오버헤드	BEGIN/COMMIT 있음	없음
EM 수명	메서드 전체	statement 단위

첫째, 커넥션 획득 시점이 다르다.
REQUIRED는 물리적 DB 트랜잭션을 새로 시작(setAutoCommit(false))해야 하므로, 메서드 진입과 동시에 커넥션 풀에서 즉시 커넥션을 확보한다. 반면 SUPPORTS는 트랜잭션을 시작할 필요가 없으므로, 실제 첫 DB 쿼리가 날아가는 순간까지 커넥션 획득을 최대한 지연시킨다.
둘째, 커넥션 유지 시간이 다르다.
REQUIRED는 커넥션을 메서드 진입 시점부터 메소드 종료 시점까지 커넥션을 풀에서 가져와서 들고있게된다. REPEATABLE READ라면 이 기간동안 MySQL DB의 언두로그를 읽게 된다. 따라서 롱 트랜잭션인 경우 언두로그가 오랫동안 쌓이는 부하가 있을 수 있다. 반면에 SUPPORTS는 쿼리직전에 가져와서 쿼리 직후에 바로 반환하므로 커넥션풀이 효율적으로 관리된다. 대신 그만큼 정합성이 떨어진다.
셋째, 트랜잭션 제어 오버헤드가 다르다.
REQUIRED는 쿼리 외에도 데이터베이스에 명시적으로 BEGIN과 COMMIT (또는 ROLLBACK) 명령을 주고받아야 하므로 추가적인 오버헤드가 발생한다. 반면 SUPPORTS는 BEGIN/COMMIT 없이 실행되므로 DB 측 트랜잭션 관리 비용이 절약된다.

4. 하이버네이트 커넥션 관리 모드를 변경하고 싶다면?

hibernate.connection.handling_mode를 명시적으로 설정하면 된다.

spring:
  jpa:
    properties:
      hibernate:
        connection:
          handling_mode: DELAYED_ACQUISITION_AND_RELEASE_AFTER_TRANSACTION

이렇게 설정하면, SUPPORTS에서 실제 트랜잭션이 없을 때(actualTransactionActive = false) Hibernate의 LogicalConnectionManagedImpl.afterTransaction()이 호출되어 커넥션이 반환된다. "트랜잭션 후 반환"인데 트랜잭션이 없으니, 사실상 쿼리 실행 후 바로 반환되는 효과가 나타난다.

단, 이 설정은 OSIV가 true일 때 prepareConnection과 충돌될 수 있으므로 주의해야한다.

Spring이 트랜잭션 시작 시 Connection에 직접 설정하는 격리 수준/readOnly 플래그 값이 있는데, 쿼리마다 커넥션이 바껴버리면 설정해둔게 무의미해지기 때문이다. 이를 사용하려면 prepareConnection의 동작을 함께 고려해야 한다.

물론 "쿼리마다 커넥션이 바뀌는" 이슈는 트랜잭션 외부에서 동일 세션이 여러 쿼리를 처리할 때 발생하는 것이다. 따라서 OSIV가 꺼져 있다면 이 시나리오 자체가 발생하지 않으므로, prepareConnection과의 충돌 우려는 없다보면 된다.

3. SUPPORTS에서 readOnly 라우팅이 동작하는 이유

Read/Write DB 분리 아키텍처에서 AbstractRoutingDataSource를 사용하는 경우, SUPPORTS 전파 전략에서도 readOnly 라우팅이 동작한다. 이것이 가능한 이유를 알기하기 위해 TransactionSynchronizationManager의 ThreadLocal 관리 메커니즘을 알아본다.

1. TransactionSynchronizationManager의 ThreadLocal들

TransactionSynchronizationManager는 다음 값들을 ThreadLocal로 관리한다.

currentTransactionReadOnly — readOnly 플래그
currentTransactionIsolationLevel — 격리 수준
actualTransactionActive — 실제 트랜잭션 존재 여부
currentTransactionName — 트랜잭션 이름
resources — 바인딩된 리소스 (EntityManager, Connection 등)
synchronizations — 트랜잭션 콜백 리스트

2. SYNCHRONIZATION_ALWAYS의 역할

AbstractPlatformTransactionManager의 transactionSynchronization 기본값은 SYNCHRONIZATION_ALWAYS다. 이 설정은 실제 트랜잭션이 없는 "빈 트랜잭션" 상태에서도 동기화를 활성화한다.

AbstractPlatformTransactionManager

@Transactional(propagation = SUPPORTS, readOnly = true)로 진입하면,

Spring은 실제 트랜잭션을 시작하지 않는다.
Empty Transaction 상태로 진입한다.
하지만 SYNCHRONIZATION_ALWAYS이므로 newSynchronization=true가 된다.
prepareTransactionStatus()가 호출될 때 newSync=true이므로 ThreadLocal이 세팅된다.
이때 TransactionSynchronizationManager.setCurrentTransactionReadOnly(true)가 실행된다.
actualTransactionActive는 false로 설정된다.
결과적으로 RoutingDataSource가 read DB로 라우팅된다.

3. RoutingDataSource와의 연결

AbstractRoutingDataSource를 상속한 RoutingDataSource에서 determineCurrentLookupKey()를 오버라이드할 때, 보통 아래와 같이 구현한다.

@Override
protected Object determineCurrentLookupKey() {
    boolean isReadOnly = TransactionSynchronizationManager.isCurrentTransactionReadOnly();

    if (enableLogging) {
        boolean isTransactionActive = TransactionSynchronizationManager.isActualTransactionActive();
        if (isReadOnly) {
            log.info("SQL READ 데이터소스 사용 / 트랜잭션 활성화: {}", isTransactionActive);
        } else {
            log.info("SQL WRITE 데이터소스 사용 / 트랜잭션 활성화: {}", isTransactionActive);
        }
    }

    return isReadOnly ? READ.getLookupKey() : WRITE.getLookupKey();
}

SUPPORTS에서 isCurrentTransactionReadOnly()가 true를 반환하므로, 실제 트랜잭션이 없는 isActualTransactionActive()는 false 이지만 read DB로 라우팅이 정상적으로 이루어진다.

4. 전파 전략별 비교 _ SUPPORTS vs REQUIRED vs NOT_SUPPORTED vs REQUIRES_NEW

각 전파 전략에 따른 커넥션 관리 동작을 표로 정리하면 다음과 같다. readOnly = true를 가정한다.

1. 바깥 트랜잭션이 없는 경우 (컨트롤러에서 직접 호출)

전파 전략	라우팅 키	actualTransactionActive	커넥션 반환 시점 (HOLD 모드)
SUPPORTS	read	false	매 쿼리 후 (statement-level)
REQUIRED	read	true	트랜잭션 커밋 시
NOT_SUPPORTED	read	false	매 쿼리 후 (statement-level)
REQUIRES_NEW	read	true	트랜잭션 커밋 시

바깥 트랜잭션이 없을 때는 네 가지 전략 모두 read로 라우팅된다.

SUPPORTS와 NOT_SUPPORTED는 실제 트랜잭션 없이 동작.
REQUIRED와 REQUIRES_NEW는 실제 트랜잭션과 함께 동작.

2. 바깥에 write 트랜잭션이 있는 경우

전파 전략	라우팅 키	actualTransactionActive	커넥션 반환 시점 (HOLD 모드)
SUPPORTS	write (바깥 tx 합류)	true (바깥 tx)	바깥 트랜잭션 종료 시
REQUIRED	write (바깥 tx 합류)	true (바깥 tx)	바깥 트랜잭션 종료 시
NOT_SUPPORTED	read (바깥 tx 중지)	false	매 쿼리 후. 단, suspend된 outer 커넥션은 별도 보유
REQUIRES_NEW	read (새 tx 시작)	true	내부 트랜잭션 커밋 시

여기서 SUPPORTS의 특징이 드러난다.

바깥에 write 트랜잭션이 존재하면, SUPPORTS는 그 트랜잭션에 합류하면서 isCurrentTransactionReadOnly()가 false가 된다. 결과적으로 read DB가 아닌 write DB로 라우팅된다.

NOT_SUPPORTED 전략 참고 사항

NOT_SUPPORTED는 outer 트랜잭션을 suspend하지만, suspend된 트랜잭션의 커넥션은 풀에 반환되지 않고 DataSourceTransactionObject.suspendedResources가 보유한다.
따라서 outer write tx 안에서 NOT_SUPPORTED 메서드를 호출하면 read 커넥션 + suspend된 write 커넥션 = 동시 2개 점유 상태가 된다. 호출 체인이 깊거나 풀이 작은 환경에선 SUPPORTS보다 풀 압박이 클 수 있다.

3. 유스케이스별 권장 전파 전략

유스케이스 권장 전파 전략 이유

유스케이스	권장 전파 전략	이유
검색 서비스 (항상 컨트롤러에서 호출)	SUPPORTS	심플하고 효율적
검색 서비스 (다른 서비스에서도 호출 가능)	NOT_SUPPORTED	바깥 tx 영향 차단
가격 계산, 결제 관련 조회	REQUIRED	트랜잭션 일관성 보장
독립적인 감사 로그 쓰기 (Audit Log)	REQUIRES_NEW	바깥 tx 롤백과 무관하게 저장

5. 트레이드오프 _ 커넥션 효율 vs 일관성

1. SUPPORTS의 이점

SUPPORTS의 가장 큰 이점은 커넥션 점유 시간 최소화다.

SharedEntityManagerCreator가 statement 단위로 EM을 생성/close하므로, SUPPORTS의 커넥션 점유는 각 쿼리 실행 시간만큼으로 한정된다. HOLD 모드의 hold 효과 자체가 사실상 발휘되지 않는다.

또한 DB 측 트랜잭션(BEGIN/COMMIT)이 없으므로 오버헤드가 줄고, HikariCP 커넥션 풀의 Active Connection 수가 낮게 유지된다.

2. SUPPORTS의 비용

MySQL 기본 격리 수준 Repeatable Read 무력화

@Transactional(propagation = SUPPORTS, readOnly = true)
public BoardPage getBoard() {
    long total = repo.count();           // 스냅샷 #A
    List<Post> list = repo.findTop20();  // 스냅샷 #B
    return new BoardPage(total, list);
}

SUPPORTS는 호출자에 트랜잭션이 없을 때 새로 시작하지 않으므로, 각 SELECT는 개별 Tx 안에서 실행되고 즉시 종료된다.

같은 메서드 내 SELECT가 각각 다른 Read View를 보게 되므로, REPEATABLE READ를 설정해두어도 사실상 READ COMMITTED와 동등한 일관성으로 떨어진다. 페이지 카운트와 목록을 함께 조회하는 두 쿼리 사이에 다른 트랜잭션이 커밋한 변경에 노출될 수 있다.

3. 실무 판단 기준

검색 서비스처럼 읽기 전용이고 최종 일관성을 허용하는 서비스라면 SUPPORTS가 합리적이다. 검색 결과는 본질적으로 "지금 시점의 가장 근사한 결과"이다.

반면, 할인 가격 계산이나 결제 관련 서비스처럼 쿼리 간 정합성이 비즈니스 정확성에 직결되는 경우에는 REQUIRED를 사용해야 한다. 사용자가 주문하기를 누른 시점에는 유효했던 쿠폰이 트랜잭션 진행중에 만료되어 적용되지 않는다면 사용자 경험을 크게 해칠 수 있다. 이런 문제는 MySQL REPEATABLE READ 환경에서 트랜잭션으로 묶는 것만으로도 스냅샷 일관성을 확보할 수 있다.

6. LogicalConnectionManagedImpl — 커넥션 반환 내부 로직

Hibernate 내부에서 커넥션 반환 결정이 실제로 어떻게 이루어지는지 코드 레벨에서 확인해보자.

LogicalConnectionManagedImpl은 Hibernate가 JDBC 커넥션의 획득과 반환을 관리하는 핵심 클래스다.

매 SQL 실행 후 afterStatement()가 호출된다.

LogicalConnectionManagedImpl

afterStatement()는 release mode가 AFTER_STATEMENT일 때만 커넥션을 반환한다.
(단, hasRegisteredResources()로 열린 JDBC 리소스 체크 후 없다면)
Spring Boot 기본값인 HOLD 모드(ON_CLOSE)에서는 이 조건에 걸리지 않으므로, 쿼리 후에도 커넥션이 유지된다.

트랜잭션 종료 시에는 afterTransaction()이 호출된다.

LogicalConnectionManagedImpl

afterTransaction()은 release mode가 ON_CLOSE가 아닌 경우에 커넥션을 반환한다.
HOLD 모드에서는 이 조건에도 걸리지 않는다. 결국 HOLD 모드에서 커넥션은 Session이 close()될 때 비로소 반환된다.

이 동작을 정리하면

SQL 실행 후 (afterStatement) (리소스가 없을 때 가정)
├─ AFTER_STATEMENT 모드 → 커넥션 반환
├─ AFTER_TRANSACTION 모드 → 유지
└─ ON_CLOSE(HOLD) 모드 → 유지

트랜잭션 종료 후 (afterTransaction) (리소스가 없을 때 가정)
├─ AFTER_STATEMENT 모드 → 커넥션 반환 (이전에 리소스 때문에 보류된 경우)
├─ AFTER_TRANSACTION 모드 → 커넥션 반환
└─ ON_CLOSE(HOLD) 모드 → 유지

Session 종료 (close):
└─ 모든 모드 → 커넥션 반환

전파전략 별 세션 범위 및 HOLD 시간 정리

전파전략	Seesion 종료 시점	HOLD 모드가 holding하는 실제 시간
REQUIRED	tx 커밋/롤백 시	트랜잭션 전체
SUPPORTS (outer tx 없음)	매 statement 후	거의 0 (statement 길이)
SUPPORTS (outer tx 합류)	outer tx 종료 시	outer tx 전체

마무리

핵심 요약

Spring Boot의 기본 커넥션 관리 모드는 DELAYED_ACQUISITION_AND_HOLD다.
Hibernate의 기본값 AFTER_TRANSACTION과 다르다.
HOLD 모드에서는 Session이 닫힐 때 커넥션이 반환된다.
OSIV=FALSE 환경에서 Session 수명은 전파 전략에 따라 달라진다
REQUIRED/REQUIRES_NEW는 트랜잭션 전체, SUPPORTS/NOT_SUPPORTED(outer tx 없음)는 statement 단위가 된다.
SUPPORTS에서 readOnly 라우팅이 동작하는 이유는 SYNCHRONIZATION_ALWAYS 때문이다.
실제 트랜잭션이 없어도 ThreadLocal에 readOnly=true가 세팅되어 RoutingDataSource가 read DB로 라우팅한다.
SUPPORTS의 함정: 바깥 write 트랜잭션이 있으면 합류한다.
항상 read DB로 라우팅해야 한다면 NOT_SUPPORTED를 고려한다.
커넥션 풀 효율과 일관성은 트레이드오프다.
검색 서비스는 SUPPORTS가 합리적이고, 정합성이 중요한 서비스는 REQUIRED가 적합하다.

참고 자료

Redis Cluster _ Lettuce Client의 Topology Refresh

구름뭉치 — Sat, 25 Apr 2026 18:05:12 +0900

Redis Cluster를 사용하면서 Lettuce 클라이언트의 Topology Refresh 설정을 빠뜨리는 경우가 생각보다 많다. 이번 글에서는 Redis Cluster에서 클라이언트가 어떻게 올바른 노드를 찾아가는지, 토폴로지가 outdated되면 어떤 장애가 발생하는지, 그리고 Lettuce가 제공하는 두 가지 갱신 전략의 동작 원리를 알아본다.

1. Redis Cluster 슬롯 구조 및 클라이언트 동작

1. 해시 슬롯 기반 분산 구조

Redis Cluster는 전체 키 공간을 16,384개의 해시 슬롯(0~16383)으로 나누고, 각 Primary 노드가 이 슬롯의 일부를 담당한다.

클라이언트가 특정 키에 대한 명령을 보내면, CRC16(Key) % 16384 연산으로 슬롯 번호를 결정하고, 해당 슬롯을 담당하는 노드에 요청을 보내야 한다.

[3노드 Cluster 예시]
Primary A → 슬롯 0 ~ 5460
Primary B → 슬롯 5461 ~ 10922
Primary C → 슬롯 10923 ~ 16383

2. 프록시가 없는 아키텍처

여기서 중요한 점은 Redis Cluster에는 프록시 계층이 없다는 것이다. 노드 사이에서 요청을 대신 전달해주는 중간자가 없다. 만약 클라이언트가 슬롯 3999에 대한 요청을 Primary C에 보냈다면, Primary C는 이 요청을 Primary A로 전달해주지 않는다. 대신 MOVED 리다이렉션을 응답한다.

MOVED 3999 127.0.0.1:6379

"이 슬롯(3999)은 내가 아니라 127.0.0.1:6379가 담당하고 있으니 거기로 가라"는 길 안내인 셈.

3. Client (Smart)

그렇다면 클라이언트가 매번 아무 노드에나 요청을 보내고, MOVED를 받고, 다시 올바른 노드에 요청을 보내야 할까? 그러면 대부분의 요청이 2번의 네트워크 왕복(round trip)을 거치게 된다.
이 비효율을 해결하기 위해 Lettuce 같은 클라이언트는 슬롯-노드 매핑 정보를 로컬에 캐싱한다.

Lettuce는 처음 Redis Cluster에 연결할 때 CLUSTER SLOTS 또는 CLUSTER NODES 명령을 호출해서 전체 매핑 정보를 한 번 가져온다. 이후 요청부터는 이 로컬 매핑(이걸 Partition Table, 또는 Topology라고 부름)을 참조해서 직접 올바른 노드에 요청을 보낸다. 이런 방식의 클라이언트를 "Smart Client"라고 부른다.

[Smart Client 동작 흐름]

1) 최초 연결 시
   Lettuce ──[CLUSTER SLOTS (명령어)]──→ Redis Cluster
   Lettuce ←── 슬롯 매핑 정보 ── Redis Cluster

2) 이후 요청
   GET user:123 → CRC16("user:123") % 16384 = 3999
                → 로컬 토폴로지 조회: 슬롯 3999 = Primary A
                → Primary A에 직접 요청 (1회 왕복)

2. 토폴로지가 outdated되면 어떤 일이 벌어질까?

Smart Client가 로컬에 토폴로지를 캐싱하는 구조에는 한 가지 본질적인 문제가 있다. 클러스터 구성이 변경되면 로컬 토폴로지와 실제 상태 사이에 불일치가 발생한다는 것이다.

1. 클러스터 구성이 변경되는 세 가지 상황

Failover
Primary가 죽고 Replica가 새 Primary로 승격된다.
이때 슬롯 range는 그대로 유지되고, 해당 슬롯을 담당하는 노드의 주소(IP:Port)만 변경된다.
Scale-out/in
새 노드가 추가되거나 기존 노드가 제거된다.
기존 노드가 가진 슬롯 중 일부를 떼어서 새 노드에 넘기는 Slot Migration 과정을 거친다.
이 과정에서 슬롯이 이동 중인 상태가 생기고, ASK 리다이렉션이 발생한다.
노드 교체
유지보수 등으로 노드의 IP 자체가 변경된다.

2. MOVED로 복구되는 경우

구성 변경 후에도 요청을 받는 노드가 살아있다면, MOVED 리다이렉션을 통해 올바른 노드로 재요청할 수 있다. 레이턴시가 2배로 늘어나는 비효율은 생기지만, 최소한 요청 자체는 성공한다.
단, 100ms 내로 제공해야하는 저지연 API 서비스에서는 이러한 추가 왕복도 치명적일 수 있다.

3. 응답조차 받을 수 없는 경우 (진짜 문제)

Failover 상황이 심각한 이유는 따로 있다. Primary A가 죽었고, Replica A'가 승격된 상황을 생각해보자.
Q. Lettuce는 여전히 죽은 Primary A의 IP:Port를 토폴로지에 들고 있다. 이 경우 Lettuce가 죽은 노드에 요청을 보내면, MOVED 응답이 올까?

A. 올 수 없다. 죽은 노드이기 때문이다.

TCP 연결 자체가 실패하거나, 연결이 되더라도 응답이 오지 않아 커넥션 타임아웃이 발생한다. 그리고 이건 한 번의 타임아웃으로 끝나지 않는다. outdated 토폴로지에는 여전히 죽은 노드가 해당 슬롯의 담당자로 기록되어 있으니, 해당 슬롯 범위에 속하는 모든 키에 대한 요청이 계속 죽은 노드로 간다.

[클러스터 실제 상태]
  Node A  (죽음)     → 슬롯 0~5460
  Node A' (승격됨!)  → 슬롯 0~5460  ← 여기로 가야 함

[Lettuce 로컬 토폴로지 - outdated]
  Node A (IP:6379)   → 슬롯 0~5460  ← 여전히 여기로 보냄
                         ↓
                    timeout... timeout... timeout...

Replica A'가 이미 승격되어 정상 서비스 중인데도, 클라이언트만 그 사실을 모르는 것이다. 이것이 Topology Refresh가 필요한 핵심적인 이유다.

3. Topology Refresh _ 두 가지 갱신 전략

이 문제를 해결하려면 Lettuce가 클러스터 구성 변경을 감지하고 로컬 토폴로지를 갱신해야 한다.

Lettuce는 이를 위해 Periodic Topology Refresh와 Adaptive Topology Refresh 두 가지 전략을 제공한다.(Redis 공식 문서)

1. Periodic Topology Refresh _ 주기적 폴링

말 그대로 고정된 주기마다 CLUSTER SLOTS 명령을 호출해서 최신 토폴로지를 가져오는 방식이다.

디폴트 값은 60초이다.

장점: 클러스터에 어떤 변화가 발생하든 주기가 돌아오면 반영된다. Scale-out으로 노드가 추가되고 Slot Migration이 발생하는 것처럼 점진적인 변화를 점진적으로 반영하기에 적합하다.

단점: 주기 사이에 발생한 변화는 다음 주기까지 반영되지 않는다. 30초 주기로 설정했다면, 최악의 경우 30초 동안 outdated 토폴로지로 요청을 보내게 된다.

2. Adaptive Topology Refresh — 이상 신호 기반 갱신

주기적으로 폴링하는 대신, 클라이언트가 받는 비정상 응답을 트리거로 활용해서 토폴로지를 갱신하는 방식이다. Lettuce가 감지하는 트리거는 다음과 같다.

MOVED 리다이렉션 — 슬롯 소유권이 바뀌었다는 신호
ASK 리다이렉션 — Slot Migration이 진행 중이라는 신호
PERSISTENT_RECONNECTS — 연결 끊김 후 재연결 시도가 반복되는 상황
UNCOVERED_SLOT — 담당 노드가 없는 슬롯 발견
UNKNOWN_NODE — 토폴로지에 없는 노드로부터 응답을 받은 경우

장점: 이벤트 발생 즉시 반응하므로 Periodic 방식보다 빠르게 복구할 수 있다.

단점: 첫 번째 에러는 불가피하다. MOVED나 타임아웃이 발생해야 비로소 갱신이 시작되기 때문이다.

3. Adaptive의 Debounce 메커니즘

장애 상황을 상상해보자.

- 커머스에 수십만 사용자들이 몰려들어왔고 수만가지 상품을 조회하고 있다. 이때 클러스터에 scale out이 발생해서 슬롯 마이그레이션이 발생하고 있다. 특정 상품을 들고 있는 마스터 노드가 변경되었으므로 기존 노드로 요청을 받은 마스터가 ASK 또는 MOVED를 답변하게 된다. 수천~수만의 요청이 발생하고 Adaptive Topololgy Refresh가 동작하게 된다. 이때 그러면 모든 비정상 응답에 대해 트리거가 동작하면서 Topolgy Refrsh를 하게 될까?

위 상황에서 트리거가 발생할 때마다 매번 CLUSTER SLOTS를 호출하면 갱신 요청이 폭주할 수 있다.

-> Lettuce는 바로 이런 상황을 Debounce 방식으로 방어한다.

첫 번째 트리거에서 바로 갱신을 실행하고, 갱신 후 일정 시간(timeout) 동안은 추가 트리거가 와도 무시한다. 이 조용한 기간이 지나면 다시 트리거에 반응할 수 있게 된다.

[Debounce 동작 흐름]

MOVED → 갱신 실행! → [조용한 기간 (timeout)] → MOVED → 갱신 실행! → ...
                   이 구간의 트리거는 무시

또한 PERSISTENT_RECONNECTS 트리거에는 refreshTriggersReconnectAttempts 옵션을 설정할 수 있다.

예를 들어 값을 3으로 설정하면, 재연결 시도를 3번 했는데도 안 될 때 비로소 토폴로지 갱신을 트리거한다. 일시적 네트워크 이슈와 실제 노드 장애를 구분하기 위한 임계값이다.

(*참고로 HTTP에서 패킷 재전송을 위한 ACK 중복 수신 임계값은 3회이다.)

4. 둘 다 키는게 가장 권장된다

	Periodic	Adaptive
트리거	고정 주기 (예: 30초마다)	MOVED, ASK, 연결 끊김 등
장점	점진적 변화를 반영	장애 즉시 반응
단점	주기 사이 공백 존재	첫 에러는 불가피
폭주 방어	주기 자체가 방어	Debounce
적합한 상황	Scale-out, Slot Migration	Failover, 노드 장애

둘은 상호 보완적이다. Periodic으로 평상시 변화를 꾸준히 반영하고, Adaptive로 갑작스러운 장애에 빠르게 대응한다.
실무에서는 두 가지를 모두 활성화하는 것이 권장된다.

4. Spring Boot 3.x + Lettuce 설정 코드

4-1. 설정 객체 생성 흐름

Topology Refresh를 Spring Boot에서 설정하려면, 아래 순서로 객체를 조립해서 LettuceConnectionFactory를 만들어야 한다.

ClusterTopologyRefreshOptions   ← Topology Refresh 전략 설정
        ↓
ClusterClientOptions            ← Lettuce 클라이언트 전체 옵션
        ↓
LettuceClientConfiguration      ← Spring이 이해하는 클라이언트 설정
        ↓
LettuceConnectionFactory        ← 최종 커넥션 팩토리 (+ RedisClusterConfiguration)

4-2. 전체 설정 코드

@Configuration
public class RedisClusterConfig {

    @Bean
    public LettuceConnectionFactory redisConnectionFactory() {
        // 1. Topology Refresh 옵션
        ClusterTopologyRefreshOptions topologyRefreshOptions = ClusterTopologyRefreshOptions.builder()
                .enablePeriodicRefresh(Duration.ofSeconds(30))       // 30초마다 주기적 갱신
                .enableAllAdaptiveRefreshTriggers()                  // 모든 Adaptive 트리거 활성화
                .refreshTriggersReconnectAttempts(3)                 // 재연결 3회 실패 시 갱신
                .build();

        // 2. Cluster Client 옵션
        ClusterClientOptions clientOptions = ClusterClientOptions.builder()
                .topologyRefreshOptions(topologyRefreshOptions)
                .build();

        // 3. Lettuce Client Configuration
        LettuceClientConfiguration clientConfig = LettuceClientConfiguration.builder()
                .clientOptions(clientOptions)
                .build();

        // 4. Cluster 서버 설정 (ElastiCache Configuration Endpoint)
        RedisClusterConfiguration serverConfig = new RedisClusterConfiguration(
                List.of("clustercfg.my-cluster.xxxxx.apn2.cache.amazonaws.com:6379")
        );

        // 5. 조립
        return new LettuceConnectionFactory(serverConfig, clientConfig);
    }
}

enableAllAdaptiveRefreshTriggers()는 위에서 설명한 5가지 트리거를 한 번에 활성화하는 단축 메서드다.
- MOVED_REDIRECT, ASK_REDIRECT, PERSISTENT_RECONNECTS, UNCOVERED_SLOT, UNKNOWN_NODE

ElastiCache Cluster 모드에서는 Configuration Endpoint 하나만 넣어주면 나머지 노드 정보는 자동으로 디스커버리된다. RedisClusterConfiguration에 이 엔드포인트를 전달하는 것으로 서버 설정은 충분하다.

3. 주의사항: RedisClusterConfiguration vs RedisStaticMasterReplicaConfiguration

서버 설정 객체를 선택할 때 주의해야 할 점이 있다.

RedisStaticMasterReplicaConfiguration은 Master-Replica(Sentinel) 구조를 위한 설정 클래스다.

Cluster 모드에서는 반드시 RedisClusterConfiguration을 사용해야 한다.

5. Sentinel 모드에서는 왜 Topology Refresh가 필요 없을까?

Redis의 Master-Replica 구조에서 Sentinel을 사용하는 경우, 슬롯 기반 분산이 없으므로 ClusterTopologyRefreshOptions은 필요하지 않다. 하지만 Failover 시 클라이언트가 새 Master를 알아야 하는 문제는 동일하게 존재한다.

차이점은 토폴로지 관리의 책임 주체가 다르다는 것이다.

[Cluster 모드]
  Client(Lettuce) ──CLUSTER SLOTS──→ Redis 노드들
  → 클라이언트가 직접 토폴로지를 관리

[Sentinel 모드]
  Client(Lettuce) ──"현재 Master 누구?"──→ Sentinel
  Sentinel ──Pub/Sub 알림──→ Client
  → Sentinel이 마스터 변경을 감지하고 클라이언트에게 push

Sentinel 모드에서는 Sentinel 프로세스가 Master 변경 이벤트를 Pub/Sub으로 클라이언트에 push해주기 때문에, 클라이언트가 스스로 폴링하거나 이상 신호를 감지할 필요가 없다.
토폴로지 관리를 Sentinel이 대신해주므로 클라이언트가 별도로 Refresh 전략을 구성할 필요가 없는 것이다.

	Cluster 모드	Sentinel 모드
라우팅	클라이언트가 슬롯 기반 직접 라우팅	단일 Master로 전부 전송
토폴로지 관리 주체	클라이언트 (Smart Client)	Sentinel 프로세스
갱신 방식	Periodic + Adaptive Refresh	Sentinel Pub/Sub 알림
설정	ClusterTopologyRefreshOptions	RedisSentinelConfiguration

6. 정리

Redis Cluster는 프록시 없는 아키텍처이기 때문에, 클라이언트(Lettuce)가 슬롯-노드 매핑 정보(토폴로지)를 로컬에 캐싱하고 직접 올바른 노드에 라우팅하는 Smart Client 방식으로 동작한다.

문제는 클러스터 구성이 변경되었을 때 발생한다. 특히 Failover 상황에서 토폴로지를 갱신하지 않으면, 죽은 노드로 요청이 계속 전달되어 타임아웃이 발생하고, 해당 슬롯 범위 전체가 먹통이 되는 장애로 이어진다.

Lettuce는 이를 위해 두 가지 갱신 전략을 제공한다.

1. Periodic Topology Refresh는 고정 주기(권장 30초 이하)로 폴링하여 점진적 변화를 반영하고,

2. Adaptive Topology Refresh는 MOVED, ASK 리다이렉션이나 연결 끊김 같은 이상 신호를 트리거로 즉시 갱신한다.

실무에서는 두 가지를 모두 활성화하여 평상시 변화와 갑작스러운 장애 모두에 대응하는 것이 권장된다.

핵심 정리

Redis Cluster는 프록시가 없는 구조이므로, Lettuce 같은 Smart Client가 슬롯-노드 매핑 정보를 로컬에 캐싱해서 직접 올바른 노드에 라우팅한다. 하지만 Failover나 Scale-out으로 클러스터 구성이 변경되면 로컬 토폴로지와 실제 상태 사이에 불일치가 생기고, 특히 노드가 죽은 경우에는 MOVED 리다이렉션조차 받을 수 없어 해당 슬롯 범위 전체에서 타임아웃이 지속되는 장애가 발생한다. 이를 방지하기 위해 Lettuce는 Periodic Topology Refresh(주기적 폴링)와 Adaptive Topology Refresh(이상 신호 기반 즉시 갱신 {MOVED, ASK, 연결 끊김 등}) 두 가지 전략을 제공하며, 실무에서는 두 가지를 모두 활성화하여 점진적 변화와 급격한 장애 양쪽에 대응한다.

참고 자료

분산 시스템 CAP 정리

구름뭉치 — Tue, 31 Mar 2026 21:13:43 +0900

분산 시스템을 공부하면 반드시 만나게 되는 이론이 있다. 바로 CAP 정리다. "Consistency, Availability, Partition Tolerance" 중 두 가지만 선택할 수 있다"는 문장은 개발자라면 한 번쯤 들어봤을 것이다. 그런데 이 문장 자체가 오해를 품고 있다.
이번 글에서는 CAP 정리의 이론적 배경부터 세 가지 속성의 정확한 정의, 추측에서 형식적 증명까지의 맥락, 그리고 실제 분산 시스템(ZooKeeper, Cassandra, Redis Cluster, Aurora DB)에서의 구현 방식과 후속 모델인 PACELC까지 정리한다.

1. C, A, P — 각 속성의 정확한 정의

CAP에 대한 오해는 대부분 세 속성의 정의를 부정확하게 이해하는 데서 시작된다. 하나씩 명확하게 알아보자.

1. Consistency(일관성) - Linearizability (선형화가능성)

CAP에서 말하는 Consistency는 우리가 흔히 사용하는 "데이터 정합성"이나 ACID의 C와 다른 개념이다.

CAP의 C는 Linearizability(선형화가능성)을 의미한다. 이것도 뭔소리인지 모르겠어서 더 풀어서 말하면, 어떤 작업이 완료된 후, 그 뒤에 오는 다른 모든 작업은 이전 작업의 결과를 즉시 볼 수 있어야 한다는 규칙인 것이다. 분산 시스템의 모든 노드에서, 어느 노드에 읽기 요청을 보내든, 가장 최근에 완료된 쓰기의 결과를 반드시 돌려받아야 한다.

커머스 시스템을 예로 들어보자.

관리자가 상품 가격을 10,000원 → 8,000원으로 수정했다. 이 시스템이 3대의 노드로 구성되어 있다면, CAP의 Consistency가 보장되려면 노드 1, 2, 3 어디에 SELECT를 날려도 8,000원이 나와야 한다. 노드 2에서 아직 10,000원이 나온다면 그 순간 CAP의 C는 깨진 것이다.

ACID의 C와의 차이를 명확히 구분하면 다음과 같다.

구분	의미	예시
ACID의 C	DB 제약조건(Unique, 음수 졔약 등)이 트랜잭션 전후로 위반되지 않음	FK 참조 무결성, Unique 제약
CAP의 C	분산 시스템의 어느 노드에서 읽어도 최신값을 반환	Linearizability (선형화가능성)
Eventual Consistency	시간이 지나면 모든 노드가 같은 값으로 수렴	Aurora Reader Replica의 복제 지연

AWS Aurora DB를 사용해 본 경험이 있다면 체감할 수 있는 부분이 있다. Writer 인스턴스에 UPDATE를 치고 Reader 인스턴스에서 즉시 SELECT하면, 복제 지연(replication lag) 동안 과거 값이 반환될 수 있다. 이 상태가 Eventual Consistency이며, 이 순간 CAP의 C는 충족되지 않는 것이다.

2. Availability(가용성) — 모든 살아있는 노드의 응답 보장

Availability도 일상적인 의미와 CAP에서의 정의가 다르다.

장애가 나지 않은(non-failing) 모든 노드는, 반드시 응답을 돌려줘야 한다.

두 가지를 짚어야 한다.

"장애가 나지 않은 노드"라는 조건이 붙는다. 물리적으로 죽은 노드는 대상이 아니다. 살아있는 노드에 요청이 도착했다면, 그 노드는 반드시 응답해야 한다는 뜻이다.
응답이 최신값이 아니어도 된다. 에러가 아닌 유효한 응답을 돌려주기만 하면 A는 만족하는 것이다. Aurora Reader가 복제 지연 때문에 10,000원(옛날 값)을 돌려줬다면, C는 깨졌지만 A는 만족한 상황이다.

구분	의미
운영 관점의 가용성	99.99% 업타임, 빠른 응답, 헬스체크 통과
CAP의 A	살아있는 노드는 반드시 응답 (느려도, 옛날값이어도 OK)

3. Partition Tolerance — 전제조건

여기서 파티션은 네트워크 파티션을 말한다. 네트워크 파티션이란 노드 간 통신이 두절되는 상황을 의미한다. 데이터가 쪼개지는 것이 아니라, 노드끼리 서로 연락이 안 되는 것이다.

정상 상태:
  [노드1] ←→ [노드2] ←→ [노드3]

파티션 발생:
  [노드1] ←→ [노드2]   ✕   [노드3]
                         ↑
                    네트워크 끊김

노드3은 살아있고 요청도 받을 수 있다. 그러나 노드1, 2와 대화를 못 한다. 이것이 네트워크 파티션이다.

Partition Tolerance의 정의: 네트워크 파티션이 발생하더라도 시스템이 계속 동작한다.

여기서 결정적인 사실이 있다. 분산 시스템에서 네트워크 파티션은 선택의 문제가 아니다.

해저 케이블 장애, 스위치 고장, AWS 가용영역 간 통신 장애 등 이것은 피할 수 없는 물리적 현실이다.

즉, P는 포기할 수 있는 옵션이 아니라 받아들여야 하는 전제조건이다.

4. 파티션 발생 시 강제되는 선택

관리자가 노드1에 가격을 8,000원으로 UPDATE 쳤다. 그런데 노드3이 네트워크 파티션으로 고립된 상태에서 고객이 노드3에 가격 조회 요청을 보냈다.

이 순간 시스템은 둘 중 하나를 선택해야 한다.

선택지 A: 노드3이 자기가 가진 옛날 값(10,000원)을 그냥 돌려준다 → C 위반, A 충족
선택지 B: 노드3이 "최신값을 확인할 수 없으니 응답을 거부한다" → A 위반, C 보호

이것이 CAP의 본질이다. 파티션이 발생하면 일관성과 가용성 사이에서 선택이 강제된다.

2. "3개중 최대 2개만 충족" 오해

1. 원래 주장

2000년, 에릭 A. 브루어 교수가 분산 컴퓨팅 강연에서 다음과 같이 주장한다. (IBM 참고)

"분산 시스템은 Consistency, Availability, Partition Tolerance 중 최대 두 가지만 동시에 만족할 수 있다."

이걸 벤다이어그램으로 그리면 CP, AP, CA 세 조합이 깔끔하게 나온다.

        C
       / \
      /   \
    CP     CA
    /       \
   P ─ AP ── A

이 그림이 너무 직관적이었기 때문에 모든 개발자들이 "세 가지 메뉴에서 두 개를 고르는 것"으로 인식해버렸다.

2. 세 가지 문제점

첫 번째, P는 선택이 아니다.

분산 시스템에서 네트워크 파티션은 반드시 발생할 수 있는 물리적 현실이다. P를 "포기한다"는 건 "네트워크가 절대 안 끊긴다고 가정한다"는 건데, 현실에선 불가능하다.
그렇다면 CA 조합은 가능할까? P를 포기한다는 것은 "네트워크 파티션이 발생하면 시스템이 동작하지 않아도 된다"는 뜻이다. 하지만 네트워크 파티션이 발생하면서 고립된 노드 쪽에도 클라이언트가 존재한다. 일관된 응답(C)을 위해 고립된 노드를 중지시키면 그 클라이언트는 응답을 못 받게 되고, 이 순간 가용성(A)이 위반된다.
결국 CA는 네트워크 파티션이 아예 발생하지 않는 단일 노드 시스템(전통적 RDBMS)에서만 가능하다. 노드가 두 대 이상인 순간, 분산 시스템의 실질적 선택지는 CP 아니면 AP 두 개뿐이다.

두 번째, 항상 포기하는 게 아니다.

CP 시스템이라 하면 "항상 A를 포기한다"로 보이지만, 실제로는 파티션이 발생한 그 순간에만 트레이드오프가 강제되는 것이다. 네트워크가 정상일 때는 C와 A를 둘 다 제공할 수 있다.

[정상 구간]         [파티션 발생]        [복구]
C ✓  A ✓  P -      C vs A 선택 강제     C ✓  A ✓  P -
                         ↑
                   여기서만 트레이드오프

세 번째, 이분법이 아니라 스펙트럼이다.

현실의 시스템은 CP/AP 두 칸으로 깔끔하게 나뉘지 않는다. "일관성을 약간 느슨하게 하되 가용성은 최대한 확보한다" 같은 튜닝이 가능하다. 이 부분은 Apache Cassandra (분산형 NoSQL DB) 사례로 확인해보자.

3. 브루어 교수 본인의 교정

Brewer는 2012년에 직접 글을 통해 다음과 같이 밝힌다.

"2 out of 3 이라는 표현은 오해를 부른다. 파티션은 드물게 발생하고, 파티션이 없는 동안에는 C와 A를 모두 제공할 수 있다."

즉, 이론을 제안한 본인이 세간의 이해 방식이 잘못되었다고 교정한 것이다.

따라서 정확한 이해는 이것이다.

~~"C, A, P 중 두 개를 고른다"~~

"분산 시스템에서 네트워크 파티션이 발생하면, 그 순간 일관성과 가용성 사이에서 선택해야 한다."

3. 브루어 교수의 추측에 대한 세스 길버트-낸시 린치의 형식적 증명

1. 추측과 증명

2000년에 브루어 교수가 제시한 것은 "추측"이었다. "나는 이렇다고 본다"라는 주장이지, 수학적으로 증명된 것이 아니었다.

학계의 반응은 "직관적으로는 그럴 것 같은데, 정말 불가능한 건지 아직 방법을 못 찾은 건지 어떻게 아는가?"였다.

2002년에 Seth Gilbert와 Nancy Lynch가 이 추측을 형식적으로 증명한다. 증명이 되면 더 이상 시도할 필요가 없어진다. "영리한 알고리즘을 만들면 세 개 다 되지 않을까?"라는 희망을 논리적으로 차단한 것이다.

2. Gilbert-Lynch 증명

증명 자체는 생각보다 매우 단순한 구조이다.

전제: 노드 2개(G1, G2), 둘 사이에 파티션 발생

1. 클라이언트가 G1에 write(x = 8000) 요청
2. G1은 성공적으로 저장
3. 파티션 때문에 G2에 전파 불가
4. 클라이언트가 G2에 read(x) 요청

이 순간:
- G2가 응답하면(A 충족) → 옛날값 반환(C 위반)
- G2가 거부하면(C 보호) → 응답 없음(A 위반)
- 어떤 알고리즘을 써도 이 구조를 벗어날 수 없음

노드 2개, 메시지 1개로 불가능성을 보인 것이다.

핵심은 파티션으로 인해 두 노드 간 메시지 전달이 불가능한 상태에서, C와 A를 동시에 만족시키는 응답이 논리적으로 존재하지 않는다는 것이다.

4. 실제 시스템에서의 CP / AP 구현

1. CP 시스템 — ZooKeeper

ZooKeeper는 분산 시스템의 코디네이터 역할을 하는 시스템이다. 리더 선출, 설정 관리, 분산 락 등에 사용된다.

내부적으로 ZAB(Zookeeper Atomic Broadcast) 프로토콜을 사용하며, Leader/Follower 구조로 동작한다.

[Follower1]
     ↕
[Leader] ←→ [Follower2]
     ↕
[Follower3]

쓰기 요청이 들어오면 Leader가 받아서 과반수(quorum) 이상의 노드에 복제가 완료된 후에 클라이언트에게 성공 응답을 준다.

파티션이 발생하면 어떻게 될까?

[Follower1] ←→ [Leader]    ✕    [Follower2] ←→ [Follower3]
        (그룹 A: 2대)                  (그룹 B: 2대)

5대 구성에서 과반수는 3대이다. 그룹 A에 Leader가 있지만 2대뿐이므로 과반수를 못 채운다. 이 상황에서 ZooKeeper는 쓰기 요청을 거부한다. 일관성을 지키기 위해 가용성을 포기한 전형적인 CP선택이다.

과반수를 기준으로 삼는 이유 - 교집합 보장

근데 왜 과반수이상의 노드에 복제가 되어야 성공 응답을 줄까?

왜 하필 과반수 일까?

노드가 5대이고 과반수가 3대일 때, 쓰기 시점에 3대에 복제하고, 읽기 시점에 3대에서 조회하면, 5대 중 3대짜리 그룹을 두 번 뽑은 셈이다. 따라서 3 + 3 = 6 > 5이므로 최소 1대는 반드시 겹친다. 이 겹치는 노드가 최신 데이터를 갖고 있는 증인 역할을 한다.

이를 쿼럼(Quorum) 공식으로 일반화하면 다음과 같다.

W + R > N

W = 쓰기 시 복제할 노드 수
R = 읽기 시 조회할 노드 수
N = 전체 노드 수

이 조건을 만족하면 읽기/쓰기 그룹 사이에 반드시 겹치는 노드가 존재하여 일관성이 보장된다.

단, ZooKeeper는 이 쿼럼 공식을 읽기에 직접 적용하지 않는다. 기본 읽기는 아무 Follower 한 대에서 즉시 응답하며(최신값이 아닐 수 있음), 최신값이 필요하면 sync 명령을 통해 Leader와 동기화한 후 읽기를 수행한다. 쿼럼 공식이 직접 적용되는 시스템은 바로 다음에 살펴볼 Cassandra이다.

2. AP 시스템 — Apache Cassandra (분산형 NoSQL DB)

Cassandra는 Facebook이 개발하고 현재 Apache 프로젝트로 운영되는 분산 NoSQL 데이터베이스이다.

아래 구조를 봐보자. ZooKeeper는 Leader/Follwer 구조였는데 카산드라는 리더가 없다.

ZooKeeper:           Cassandra:
[Leader]              [노드1]
  ↕   ↕                ↕   ↕
[F1] [F2]            [노드2]─[노드3]
                       ↕      ↕
리더가 쓰기 통제         [노드4]─[노드5]

                   모든 노드가 동등 (Peer-to-Peer)

리더가 없으므로 아무 노드에나 읽기/쓰기가 가능하다. 이 구조만으로도 가용성을 극대화하려는 설계 의도가 드러난다.

Cassandra에서는 앞서 설명한 쿼럼 공식이 직접 적용된다. 개발자가 요청마다 일관성 레벨을 설정할 수 있다.

Quorum 설정

설정	의미
ONE	노드 1대만 확인
QUORUM	과반수 확인
ALL	전체 노드 확인

N=3인 클러스터에서 적용하면 다음과 같다.

W=QUORUM(2), R=QUORUM(2) → 2+2=4 > 3 ✓ 일관성 보장
W=ONE(1),    R=ONE(1)    → 1+1=2 ≤ 3 ✗ 일관성 미보장
W=ALL(3),    R=ONE(1)    → 3+1=4 > 3 ✓ 일관성 보장

파티션 발생 시 동작이 ZooKeeper와 정반대이다.

[노드1] ←→ [노드2]   ✕   [노드3]

클라이언트가 노드3에 쓰기 요청 →

ZooKeeper였다면: 과반수 못 모으니 거부
Cassandra(W=ONE): 노드3이 혼자 저장하고 성공 응답 반환

파티션이 복구되면 노드 간 데이터를 맞추는 메커니즘이 동작하여 Eventually Consistent 상태로 수렴한다. 즉, 지금은 일관성이 안 맞지만, 나중에 맞춰진다는 AP 선택이다.

다만, Cassandra는 위에서 보다시피 Quorum 튜닝이 가능하다보니 "W=QUORUM, R=QUORUM" 으로 설정하면 CP처럼 동작할 수도 있다. 즉, Cassandra는 "AP 시스템"이라고 딱 잘라 말하기보단, 개발자가 요청 단위로 CP와 AP 사이를 튜닝할 수 있는 시스템이다.

이것이 앞서 말한 "CP/AP는 이분법이 아니라 스펙트럼"이라는 것의 실제 사례이다.

3. Redis Cluster - 유사 CP 시스템

Redis Cluster는 데이터를 16,384개의 해시 슬롯으로 나누어 여러 마스터 노드에 분산 저장한다.

파티션 또는 마스터 장애 발생 시 Redis Cluster는 해당 슬롯에 대한 요청을 거부(CLUSTERDOWN 에러)한다. 과거 데이터를 돌려주는 게 아니라 아예 에러를 내는 것이다. 즉, 일관성을 지키기 위해 가용성을 포기하는 CP선택이다.

[마스터A 담당: 슬롯 0~5000]  ← 이 노드가 죽음
[마스터B 담당: 슬롯 5001~10000]
[마스터C 담당: 슬롯 10001~16383]

마스터A가 죽은 직후 ~ 레플리카 승격 완료 전:
→ 슬롯 0~5000에 대한 요청은 CLUSTERDOWN 에러 반환

단, Redis Cluster가 완벽한 C를 보장하지는 않는다. 마스터 → 레플리카 복제가 비동기이기 때문이다.

1. 클라이언트 → 마스터A: SET price 8000 → "OK"
2. 마스터A가 레플리카에 복제하기 전에 죽음
3. 레플리카 승격 → price는 여전히 10000
4. 방금 쓴 데이터 유실

이래서 현실의 시스템을 CP/AP로 깔끔하게 분류하기 어렵다. Redis Cluster는 CP에 가깝지만 비동기 복제로 인해 완전한 C는 아닌 시스템이다.

4. Amazon Aurora DB - 특이 케이스

Aurora DB는 지금까지 본 시스템과 구조 자체가 다르다.

일반적인 분산 DB:
[노드1: 컴퓨트+스토리지] ←복제→ [노드2: 컴퓨트+스토리지]

Aurora:
[Writer 인스턴스]  [Reader 인스턴스1]  [Reader 인스턴스2]
       ↘               ↓                ↓
       ==========================================
       |        공유 분산 스토리지 레이어          |
       |   (3개 AZ × 2카피 = 6카피 자동 복제)     |
       ==========================================

Aurora 구조의 경우 스토리지와 컴퓨트가 분리되어 있다.

데이터가 노드마다 따로 있는 게 아니라 스토리지가 하나의 공유 레이어이고, Writer와 Reader 모두 같은 스토리지를 바라본다.

스토리지 레이어에는 Quorum 공식이 적용된다.

N=6, W=4, R=3
W+R = 4+3 = 7 > 6 ✓

일관성 (Consistency)

[지키는 부분]

Writer가 죽으면 Reader 중 하나를 Writer로 자동 승격시킨다. Redis Cluster와 다른 점은, Writer가 죽어도 스토리지 레이어에 4/6 쿼럼으로 이미 쓰기가 완료된 상태이므로 데이터 유실이 발생하지 않는다는 것이다.

그리고 Writer는 단 1대이므로, Cassandra처럼 양쪽에서 동시에 다른 값을 쓰는 쓰기 충돌이 원천적으로 발생하지 않는다. 파티션이 발생해도 Reader는 어차피 쓰기를 못 하기 때문이다.

[못 지키는 부분]

Writer와 Reader 사이의 레플리케이션이 아닌, Reader의 버퍼 캐시 갱신 지연으로 인해 최신값이 아닌 데이터가 읽힐 수 있다. Aurora는 전통적 "노드 → 노드" 복제가 아닌 공유 스토리지 구조 덕분에 CAP의 전통적 분류가 잘 맞지 않는 특수 케이스이다.

5. 시스템 비교 종합

시스템	파티션/장애 시 선택	핵심 특징
ZooKeeper	CP	과반수 못 모으면 쓰기 거부. ZAB 프로토콜 기반
Cassandra	AP (튜닝 가능)	Peer-to-Peer 구조. 개발자가 일관성 레벨 선택
Redis Cluster	CP (비동기 복제로 C 불완전)	담당 마스터 없으면 CLUSTERDOWN 에러
단일 RDBMS	CA	단일 노드이므로 파티션 자체가 없음
Aurora DB	전통적 분류 부적합	스토리지-컴퓨트 분리 구조. 레이어별로 다른 선택

5. PACELC — CAP의 한계 보완

1. CAP이 설명하지 못하는 것

CAP은 "파티션이 발생하면 C와 A 중 선택하라"고 말한다. 맞는 이야기다. 그런데 현실에서 네트워크 파티션은 간혈적으로 발생한다. 대부분의 시간은 네트워크가 정상이다. 그렇다면 아래 궁금증이 나온다.

파티션이 없는 평상시에는 아무 트레이드오프도 없는 것인가?

파티션이 없어도 노드 간 데이터 동기화에는 시간이 걸린다.

모든 노드 복제 완료까지 기다린 후 응답할 것인가(C 강화, Latency 증가)
일부만 복제하고 바로 응답할 것인가(Latency 감소, C 약화)

이 선택은 파티션과 무관하게 항상 존재한다.

2. PACELC 모델의 구조

이러한 CAP의 허점을 보완한 PACELC 모델은 이름 자체가 구조를 나타낸다.

P가 발생하면(Partition) → A vs C 선택
E(Else, 평상시)         → L(Latency) vs C(Consistency) 선택

"파티션 시에는 A와 C 중 선택하고, 평상시에도 지연시간(Latency)과 일관성(Consistency) 사이에서 선택해야 한다."

3. PACELC로 본 실제 시스템

시스템	파티션 시 (PA/PC)	평상시 (EL/EC)	표기	의미
ZooKeeper	PC	EC	PC/EC	항상 일관성 우선
Cassandra (기본)	PA	EL	PA/EL	항상 가용성·속도 우선
Redis Cluster	PC	EL	PC/EL	파티션 시 C, 평상시 L 우선
Aurora (스토리지)	PC	EC	PC/EC	쿼럼 쓰기 완료 대기

Redis Cluster를 보면 PACELC의 가치가 드러난다. CAP으로는 그냥 "CP"였는데, PACELC로 보면 파티션 시에는 C를 선택하지만, 평상시에는 Latency를 선택(비동기 복제)한다는 설계 특성이 명시적으로 표현된다.

"CP인데 완벽한 C는 아니다"라는 찝찝함의 정체가 바로 이것이다. CAP만으로는 "평상시에 비동기 복제를 써서 일관성을 약간 포기하고 있다"는 설계 선택이 표현되지 않는다. PACELC는 이를 **EL(평상시 Latency 우선)**이라고 명시해 준다.

6. 정리

CAP 세 속성 정의

C (Consistency)	모든 노드에서 최신값 반환 (Linearizability)	ACID의 C와 다른 개념
A (Availability)	살아있는 모든 노드가 반드시 응답	느려도, 옛날값이어도 OK
P (Partition Tolerance)	파티션 발생해도 시스템 동작	포기 불가능한 전제조건

핵심 원칙

CAP의 정확한 의미: "3개 중 2개 선택"이 아니라, "파티션 발생 시 C와 A 중 선택이 강제된다."
P는 전제조건: 분산 시스템에서 네트워크 파티션은 반드시 발생할 수 있으므로, 실질적 선택지는 CP 또는 AP이다.
CP/AP는 이분법이 아니라 스펙트럼: Cassandra처럼 요청 단위로 일관성 레벨을 튜닝하는 시스템이 존재한다.
CAP만으로는 부족하다: 평상시의 Latency vs Consistency 트레이드오프를 표현하려면 PACELC가 필요하다.
현실의 시스템은 깔끔하게 분류되지 않는다: Aurora처럼 레이어별로 다른 선택을 하는 시스템도 있고, Redis Cluster처럼 CP이면서도 비동기 복제로 완전한 C를 보장하지 못하는 시스템도 있다.

HTTP/1.1, HTTP/2, HTTP/3 프로토콜 비교 정리

구름뭉치 — Tue, 31 Mar 2026 19:55:33 +0900

웹 개발자라면 HTTP를 매일 사용한다. 하지만 "HTTP/2가 HTTP/1.1보다 빠르다" 수준의 이해에 머물러 있다면, 각 버전이 왜 등장했고 어떤 문제를 해결했는지를 놓치고 있는 것이다. 이 글에서는 HTTP/1.1 → HTTP/2 → HTTP/3로 이어지는 진화의 맥락을 짚고, 각 버전의 커넥션 관리, 멀티플렉싱, 헤더 압축, 전송 계층, 한계점을 깊이 있게 비교한다.

1. HTTP/1.0 — 초기 문제점

HTTP/1.0은 요청 하나를 보내고 응답을 받으면 TCP 커넥션(Connection)을 즉시 닫는다.

단순하지만, 현실의 웹에서는 치명적이다.

요청 하나에도 수십 수백개의 요청들이 가고있다

브라우저가 웹페이지 하나를 로드할 때 필요한 것은 HTML 파일 하나가 아니다.

HTML 안에 포함된 CSS, JavaScript, 이미지, 폰트, API 응답 등 수십~수백 개의 리소스를 서버에 요청해야 한다.

요즘 평균적인 웹페이지는 약 70~100개의 리소스를 요청한다.

문제는 이때 연결을 위한 TCP 커넥션이 공짜가 아니라는 것이다. 연결을 맺으려면 3-way Handshake가 필요하다.

클라이언트 → 서버:  SYN
서버 → 클라이언트:  SYN-ACK
클라이언트 → 서버:  ACK

이 과정에 1 RTT(Round-Trip Time)가 소요된다.

서울에서 미국 서버까지 RTT가 약 150~200ms라고 가정하면, 리소스 70개를 요청할 때 순수 연결 비용만 10초 이상이다. HTTPS를 사용하면 TLS Handshake가 추가로 1~2 RTT 더 필요하다.

2. HTTP/1.1 — Keep-Alive 도입 및 한계

1. Persistent Connection (Keep-Alive)

HTTP/1.1의 핵심 해결책은 단순하다. TCP 커넥션을 끊지 말고 재사용하자.

이것이 Persistent Connection, 흔히 Keep-Alive라 불리는 메커니즘이다. HTTP/1.1에서는 해당값이 켜지는게 디폴트이다. 이를 통해 별도로 설정하지 않아도 커넥션이 유지된다.

[TCP 연결] ─────────────────────────────── [TCP 종료]
  GET /index.html  →  응답
  GET /style.css   →  응답
  GET /app.js      →  응답
  GET /logo.png    →  응답

하나의 커넥션에서 여러 요청-응답을 순차적으로 처리한다. 각 요청마다 Handshake를 반복하는 HTTP/1.0에 비하면 훨씬 큰 개선이라고 볼 수 있다.

2. HOL Blocking (Head-of-Line Blocking)

하지만 여기서도 문제가 있다. 바로 동기/블로킹 문제이다.

위 그림을 자세히 보면, 요청-응답이 순서대로 하나씩 처리된다. 첫 번째 요청의 응답이 완료될 때까지 두 번째 요청은 대기해야 한다.

[TCP 커넥션]
  GET /heavy-api  →  ⏳⏳⏳ (3초)  →  응답
  GET /style.css  →  (대기)         →  응답
  GET /app.js     →  (대기)         →  응답

style.css는 10ms면 받을 수 있는데도, 앞에 3초짜리 요청이 있다는 이유만으로 3초를 기다려야 한다. 대기줄 맨 앞(Head-of-Line)이 막히면 뒤가 전부 멈추는 이 현상을 HOL Blocking이라 한다.

운영체제에서 스레드 스케줄링 시 언급되는 Convoy Effect와 유사한 현상이다.

3. 파이프라이닝

HTTP/1.1 스펙에는 파이프라이닝이라는 해결책도 포함되어 있다. 응답을 기다리지 않고 요청을 미리 연달아 보내는 방식이다. 즉, 논블로킹으로 요청을 보낼 수 있게 되는것이다.

→ GET /heavy-api
→ GET /style.css   (응답 안 기다리고 전송)
→ GET /app.js      (응답 안 기다리고 전송)

← 응답: /heavy-api
← 응답: /style.css
← 응답: /app.js

논블로킹으로 이제 해결이 다 된거같지만 문제가 있다. 블로킹 없이 바로 요청이 가능하므로 전송은 빨라졌지만, 응답은 반드시 요청 순서대로 와야 한다는 제약이 있기 때문이다. 즉, 논블로킹으로 다 요청은 보내놨는데 전부 응답이 올 때까지 join()이 걸리고 동기로 응답을 받아야 하는 것이다.

이로인해 style.css 응답이 먼저 준비되어도 heavy-api 응답이 먼저 나가야 한다. 결국 응답 쪽에서 HOL Blocking이 그대로 발생하는 것이다. 이 문제 때문에 대부분의 브라우저가 파이프라이닝을 기본 비활성화했다. 스펙에는 있지만 사실상 죽은 기능이다.

4. 브라우저의 블로킹 우회 - 다중 커넥션

이러한 블로킹으로 인한 HOL 문제를 해결하고자 브라우저들은 하나의 도메인에 대해 TCP 커넥션을 여러 개(보통 6개) 동시에 여는 방식으로 우회했다.

커넥션1: GET /heavy-api  →  ⏳⏳⏳  →  응답
커넥션2: GET /style.css  →  응답 ✅
커넥션3: GET /app.js     →  응답 ✅
커넥션4: GET /logo.png   →  응답 ✅

사실상 병렬처리 형태로, 한 커넥션이 막혀도 다른 커넥션은 독립적으로 진행된다. 마치 멀티 스레드로 요청을 처리하면 하나의 스레드가 블로킹 되어도 나머지가 일할 수 있는것과 동일하다.

하지만 70~100개 리소스에 커넥션 6개로는 여전히 부족하다. 각 커넥션이 독립적으로 3-way Handshake + TLS Handshake를 수행해야 하고, 서버 입장에서는 클라이언트 한 명이 커넥션을 6개씩 점유하므로 리소스 부담도 크다.

따라서 브라우저의 다중 커넥션 사용 외에도 프로토콜의 한계를 애플리케이션 레벨에서 보완하고자 여러 방안들이 나왔다.

Domain Sharding — img1.shop.com, img2.shop.com처럼 도메인을 쪼개어 "도메인당 6개" 제한을 우회
CSS Sprite — 이미지 수십 개를 하나의 큰 이미지로 합쳐서 요청 수를 줄임
JS/CSS 번들링 — 여러 파일을 하나로 합침
인라이닝(Inlining) — 작은 이미지를 Base64로 HTML에 직접 삽입

이러한 방안들은 전부 "요청 수를 줄이자" 라는 목적 하나를 위한 우회 기법들이다.

5. HTTP/1.1의 한계: 비효율적인 헤더

HTTP/1.1의 Header는 평문 텍스트(Plain Text)이다. 즉, 매 요청마다 Cookie, User-Agent, Accept 등 거의 동일한 헤더가 반복 전송된다. 일반적으로 헤더 한 번에 500바이트~수 KB인데, 100개 요청이면 순수 헤더만으로 수백 KB가 낭비된다.

3. HTTP/2 — 프로토콜 레벨의 혁신

HTTP/2는 HTTP/1.1의 핵심 한계 세 가지를 정면으로 해결한다.

1. Binary Framing Layer

HTTP/1.1은 메시지가 텍스트였다. 사람은 읽을 수 있지만 컴퓨터가 파싱하기엔 비효율적이다. HTTP/2는 텍스트 메시지를 Binary Frame이라는 작은 단위로 분해했다.

HTTP/2의 핵심 개념은 세 가지 계층 구조로 정리된다.

Frame — HTTP/2에서 가장 작은 통신 단위. HEADERS Frame, DATA Frame 등 종류가 있으며, 각 Frame에는 자신이 속한 Stream ID가 태그되어 있다.
Stream — 하나의 요청-응답 쌍을 의미하는 논리적 통로. GET /style.css가 Stream 1, GET /app.js가 Stream 3 같은 식이다.
Connection — 모든 Stream을 담는 단 하나의 TCP 커넥션.

┌─ Connection (TCP 커넥션 1개) ─────────────────────────┐
│                                                     │
│  ┌─ Stream 1 ─────────────────────────────────────┐ │
│  │  [HEADERS Frame]  [DATA Frame]  [DATA Frame]   │ │
│  └────────────────────────────────────────────────┘ │
│                                                     │
│  ┌─ Stream 2 ─────────────────────────────────────┐ │
│  │  [HEADERS Frame]  [DATA Frame]                 │ │
│  └────────────────────────────────────────────────┘ │
│                                                     │
│  ┌─ Stream 3 ─────────────────────────────────────┐ │
│  │  [HEADERS Frame]  [DATA Frame]  [DATA Frame]   │ │
│  └────────────────────────────────────────────────┘ │
│                                                     │
└─────────────────────────────────────────────────────┘

2. Multiplexing (멀티 플렉싱) — HOL Blocking 해결

HTTP/1.1에서는 하나의 커넥션에서 요청-응답이 순서대로만 처리되어 HOL Blocking이 발생했다.

HTTP/2에서는 Stream ID로 각 요청-응답을 식별하기 때문에, 서로 다른 Stream의 Frame이 뒤섞여서(Interleaving) 전송될 수 있다.

TCP 위의 Frame 전송 순서 (시간 →):

[S1:HEADERS] [S2:HEADERS] [S1:DATA] [S3:HEADERS] [S2:DATA] [S1:DATA] [S3:DATA]

수신 측에서 Stream별로 분류·재조립:
  Stream 1: HEADERS → DATA → DATA   ✅
  Stream 2: HEADERS → DATA          ✅
  Stream 3: HEADERS → DATA          ✅

같은 Stream 내 Frame 순서는 TCP가 보장하고, 서로 다른 Stream 간에는 순서 제약이 없다. 응답 B가 먼저 준비되면 먼저 보내면 된다. 응답 A가 느려도 B와 C는 영향받지 않는다.

HTTP/1.1에서는 "순서"가 곧 "의존"이었지만, HTTP/2에서는 Stream ID로 "식별"하기 때문에 순차 처리(동기처리)에서 벗어날 수 있다.

3. HPACK — 헤더 압축

HTTP/1.1에서 매 요청마다 중복 헤더를 텍스트로 반복 전송하는 문제를 HPACK이 해결한다. 핵심 아이디어는 두 가지다.

Static Table (정적 테이블) — 자주 사용되는 헤더 61개가 미리 번호로 등록되어 있다.
- ":method: GET"이라는 텍스트 대신 인덱스 2만 보내면 된다.
Dynamic Table (동적 테이블) — 통신하면서 새로 등장한 헤더를 양쪽에 동일한 테이블에 기록한다.

첫 번째 요청:  Cookie: session=abc123  → 전체 전송 + 동적 테이블 62번 등록
두 번째 요청:  Cookie: session=abc123  → 인덱스 62만 전송

추가로 Huffman Encoding을 적용하여 문자열 자체도 압축한다. 두 번째 요청부터는 헤더 대부분이 인덱스 번호 몇 개로 줄어든다. HTTP/1.1에서 수 KB였던 헤더가 수십 바이트로 압축되는 효과를 얻는다.

4. Server Push (폐기된 기능)

HTTP/1.1에서 서버는 클라이언트가 요청해야만 응답할 수 있었다. HTTP/2의 Server Push는 클라이언트가 요청하기 전에 서버가 필요한 리소스를 선제 전송하는 기능이다.

클라이언트: GET /index.html
서버:
  → 응답: /index.html     (Stream 1)
  → 푸시: /style.css      (Stream 2 — 요청 없이 전송)
  → 푸시: /app.js         (Stream 4 — 요청 없이 전송)

아이디어는 좋았지만 실무에서는 기대만큼 효과적이지 못했다.

캐시 낭비 — 서버는 클라이언트의 Cache 상태를 알 수 없다. 이미 Cache에 있는 리소스를 Push하면 대역폭만 낭비된다.
구현 복잡성 — 서버가 "이 HTML에 어떤 리소스가 필요한지"를 미리 파악하는 로직을 별도로 구현해야 한다.
CDN 충돌 — 실무에서 정적 리소스는 보통 CDN에서 서빙하는데, Origin Server가 CDN의 Cache 상태까지 알 수 없어 Push 판단이 어렵다.

실제로 Chrome은 Server Push 지원을 제거했다.

5. Flow Control (흐름 제어) — 커넥션별/스트림별 흐름 제어

TCP에도 흐름 제어(Flow Control)가 있지만, 이는 커넥션 단위이다. HTTP/2에서는 하나의 커넥션 안에 수십~수백 개의 Stream이 공존하므로, Stream별 독립적인 흐름 제어가 필요하다.

HTTP/2는 두 단계의 흐름 제어를 운영한다.

커넥션 레벨 윈도우(Connection-level Window) — 커넥션 전체의 전송 허용량
스트림 레벨 윈도우(Stream-level Window) — 각 Stream의 전송 허용량

초기 윈도우 크기는 65,535 바이트이다. 데이터 전송 시 커넥션과 스트림의 윈도우를 둘다 사용하고, 수신 측이 데이터를 처리한 후 WINDOW_UPDATE Frame으로 윈도우를 채우게 된다.

즉, 커넥션 전체 전송량을 조절하여 과한 요청이 가는 흐름 제어를 하는 것.
커넥션 내 스트림 별로 자원을 독식하지 못하게 흐름 제어하는 것.

이 흐름 제어에 핵심 설계 원칙이 있다.

흐름 제어는 DATA Frame에만 적용되고, HEADERS Frame에는 적용되지 않는다.

HEADERS Frame은 새로운 Stream을 여는 행위 자체이기 때문에, 이를 흐름 제어 대상에 포함시키면 새 요청 자체가 차단되는 문제가 발생한다. 기존 Stream이 윈도우를 소진했을 때 새 요청조차 보낼 수 없게 되면, 커넥션의 자원 독점과 교착 상태(Deadlock)로 이어질 수 있다.

즉, "데이터의 양은 조절하되, 의사소통 자체는 절대 막지 않는다" 는 원칙이다.

6. HTTP/2의 치명적 한계: TCP-레벨 HOL Blocking

HTTP/2는 Application Layer에서 스트림을 통한 Multiplexing으로 HOL Blocking을 해결했다. 하지만 TCP 레이어에서 고려해야할 문제가 또 있다.

HTTP/2의 모든 Stream은 하나의 TCP 커넥션 위에서 흐른다.

TCP는 바이트 스트림을 순서대로 전달하는 프로토콜이다.
TCP 입장에서 Stream이라는 개념은 존재하지 않는다.

TCP 위의 Frame 전송:
[S1:DATA] [S2:DATA] [S3:DATA] [S1:DATA] [S2:DATA]
    ↑
  이 패킷 유실

스트림으로 전달하는 상황에서 패킷이 유실된 경우를 봐보자. 이때 HTTP/2 TCP는 유실된 패킷이 재전송되어 도착할 때까지 그 뒤의 모든 바이트 전달을 멈춘다. Stream 1의 패킷이 유실되었을 뿐인데, Stream 2와 Stream 3까지 블로킹된다.

이게 TCP-레벨 HOL Blocking 문제이다. HTTP/2가 커넥션을 1개로 통합했기 때문에, 패킷 유실률이 2%만 넘어도 6개 커넥션을 분산 사용하는 HTTP/1.1보다 오히려 느려질 수 있다. 이 한계가 HTTP/3의 등장 배경이다.

심화: HTTP/2에서의 다중 커넥션을 사용하는건 어떨까?

HTTP/1.1처럼 커넥션을 여러 개 열면 TCP-레벨 HOL Blocking을 분산시킬 수 있지 않을까?

결론부터 말하면, 스펙상 금지는 아니지만 권장하지 않는다.

HTTP/2에서는 클라이언트가 특정 서버에 대해 "하나의 HTTP/2 커넥션만 열어야 한다"고 규정한다. 단, MUST가 아니므로 기술적으로 여러 개를 열 수 있고, 브라우저도 TLS 인증서가 다르거나 기존 커넥션이 비정상적일 때 등 예외적으로 2개 이상을 열기도 한다. 하지만 의도적으로 다중 커넥션을 사용하면 HTTP/2의 핵심 이점이 훼손된다.

[단점]

멀티플렉싱 대상이 분산됨 — 하나의 커넥션에 모든 Stream이 있어야 스케줄링 효율이 극대화된다.
HPACK 동적 테이블(61개 헤더)이 커넥션마다 분리됨 — 헤더 압축 효율이 저하된다. 동적 테이블은 커넥션 단위로 유지되므로, 커넥션이 나뉘면 학습된 헤더 정보도 나뉜다.
Slow Start를 커넥션마다 따로 겪음 — TCP 혼잡 제어의 초기 속도 저하가 커넥션 수만큼 반복된다.

[유일한 장점]

커넥션이 분산되므로 패킷 유실 시 영향 범위가 줄어든다.
하지만 이는 HTTP/2의 설계 의도를 거스르는 판단이다. (커넥션 부하로 인해 하나로 묶고 스트림으로 처리하고자 한것인데)

TCP-레벨 HOL Blocking을 프로토콜 차원에서 근본적으로 해결한 것은 HTTP/3(QUIC)이다.

심화: TCP 재전송 메커니즘의 이해

HTTP/3의 QUIC가 왜 TCP를 대체했는지를 깊이 이해하려면, TCP가 패킷 유실을 어떻게 감지하고 재전송하는지를 알아야 한다. TCP의 재전송은 네 가지 메커니즘이 계층적으로 협력하는 구조이다.

타임아웃 기반 재전송 (RTO Retransmission)

가장 기본적인 메커니즘이다. 세그먼트를 보낸 후 RTO(Retransmission Timeout) 시간 내에 ACK가 오지 않으면 재전송한다.

송신 →  [SEQ=1000]  → (유실 ❌)
         ⏳ RTO 대기... (수백 ms ~ 수 초)
         ⏳ 타임아웃!

송신 →  [SEQ=1000]  → 수신 (재전송)

이때 RTO는 고정값이 아니라 RTT 측정값을 기반으로 동적 계산된다.

SRTT = Smoothed RTT (평활화된 RTT)
RTTVAR = RTT 변동폭
RTO = SRTT + 4 × RTTVAR

RTT가 안정적이면 RTO가 짧아지고, 변동이 크면 RTO가 길어진다. 보통 수백 ms~수 초로 설정되므로, 유실 감지까지 시간이 오래 걸린다는 한계가 있다. 이 한계를 보완하기 위해 이후 메커니즘들이 추가되었다.

Fast Retransmit (빠른 재전송)

중복 ACK(Duplicate ACK)가 3개 쌓이면, 타임아웃을 기다리지 않고 즉시 재전송한다.

송신 →  [SEQ=1000]  → 수신 ✅
송신 →  [SEQ=1100]  → ❌ 유실
송신 →  [SEQ=1200]  → 수신 ✅
송신 →  [SEQ=1300]  → 수신 ✅
송신 →  [SEQ=1400]  → 수신 ✅

수신: 1200·1300·1400은 도착했지만 1100이 빠짐
  ← ACK=1100  (중복 1)
  ← ACK=1100  (중복 2)
  ← ACK=1100  (중복 3)

송신: 중복 ACK 3개 → 즉시 재전송!
송신 →  [SEQ=1100]  → 수신 ✅

중복 ACK 임계값이 1이 아니라 3인 이유는, 네트워크에서 패킷이 서로 다른 경로를 타면서 순서가 바뀌는 재정렬(Reordering) 이 발생할 수 있기 때문이다. 재정렬 시에도 중복 ACK가 1~2개 발생할 수 있으므로, 이를 유실로 오판하지 않기 위해 경험적으로 3개를 임계값으로 설정한 것이다.

SACK (Selective Acknowledgment)

TCP의 기본 ACK는 누적 ACK(Cumulative ACK) 이다. "여기까지 받았다"만 알려줄 뿐, 그 뒤에 어떤 패킷이 도착했는지는 알려주지 않는다.

[누적 ACK만 있는 경우]
  수신 상태: 1✅ 2✅ 3❌ 4✅ 5❌ 6✅
  ACK=3 ("3번부터 보내줘")
  → 송신 측은 3이 빠진 것만 알고, 4·5·6 상태를 모름
  → 최악의 경우: 3~6을 전부 재전송 (불필요한 재전송)

SACK은 수신 측이 "어디어디를 받았다"를 구체적으로 알려주는 TCP 옵션이다.

[SACK 활성화된 경우]
  수신 상태: 1✅ 2✅ 3❌ 4✅ 5❌ 6✅
  ACK=3, SACK=[4-4, 6-6]
  → "3과 5만 빠졌구나" → 3과 5만 재전송

SACK는 TCP의 선택적 옵션이며 헤더 공간 제한으로 최대 4개 블록까지만 표현 가능하다. QUIC의 ACK Range는 이 SACK의 개념을 기본 스펙으로 흡수하면서 공간 제한도 크게 완화한 것이다.

Tail Loss Probe (TLP)

앞의 메커니즘들로도 해결이 어려운 특수한 케이스가 있다. 커넥션에서 마지막으로 보낸 패킷이 유실된 경우이다.

송신 →  [SEQ=1000]  → 수신 ✅
송신 →  [SEQ=1100]  → 수신 ✅
송신 →  [SEQ=1200]  → ❌ 유실 (마지막 전송)

수신: 더 이상 받을 패킷이 없으므로 중복 ACK를 보낼 계기가 없음
송신: 중복 ACK가 안 오니 Fast Retransmit 발동 불가
      → RTO 타임아웃(수백 ms~수 초)까지 기다려야 함

마지막 패킷 뒤에 후속 패킷이 없으므로, 수신 측에서 중복 ACK가 발생하지 않는다. 따라서 Fast Retransmit이 작동할 수 없다.

TLP는 RTO 발동 전에 Probe 패킷을 먼저 보내 수신 측의 ACK를 유도한다.

송신 →  [SEQ=1200]  → ❌ 유실
         ⏳ PTO(Probe Timeout, RTO보다 짧음) 대기...

송신 →  [Probe 패킷]  → 수신
         (마지막 데이터 또는 새 데이터를 전송하여 ACK 유도)

수신 ←  ACK=1200  ("1200번부터 보내줘")
송신: "1200이 유실됐구나" → 재전송

재전송 메커니즘의 계층 구조

네 가지 메커니즘은 서로 대체하는 것이 아니라, 상황에 따라 단계적으로 발동한다.

패킷 유실 발생!

① Fast Retransmit (가장 빠름, 수 ms ~ 수십 ms)
   조건: 중복 ACK 3개
   한계: 마지막 패킷 유실 시 발동 불가

② TLP — Tail Loss Probe (수십 ms ~ 수백 ms)
   조건: 일정 시간 ACK 없음 (PTO)
   한계: Probe 응답이 없으면 RTO로 넘어감

③ RTO — 타임아웃 재전송 (최후의 보루, 수백 ms ~ 수 초)
   조건: ACK 타임아웃
   특징: 느리지만 가장 확실한 안전망

+ SACK (보조 메커니즘)
  역할: 위 메커니즘들에서 "어떤 패킷을 재전송할지" 정밀 판단 보조

이 모든 메커니즘이 OS 커널에 구현되어 있다. QUIC는 이 개념들을 유저 스페이스에서 재구현하면서, Packet Number 단조 증가로 재전송 모호성을 제거하고 ACK Range를 기본 탑재하여 재전송 판단의 정밀도를 높였다.

4. HTTP/3 — 전송 계층 프로토콜 교체

1. TCP를 버리고 UDP로

HTTP/1.1은 다중 커넥션으로, HTTP/2는 스트림 기반 Multiplexing으로 HOL Blocking에 대응했다.

하지만 근본 원인은 TCP가 바이트 스트림을 순서대로만 전달하는 프로토콜이라는 점이다. 이 한계는 Application Layer에서 아무리 고쳐도 해결할 수 없다. HTTP/3는 TCP 자체를 버리고 QUIC이라는 새로운 전송 프로토콜 위에서 동작한다.

2. 왜 UDP일까?

새로운 전송 프로토콜을 만든다면 커널에 구현해야 하고, 전 세계 OS와 중간 네트워크 장비를 업데이트해야 한다. 현실적으로 불가능하다.

QUIC는 UDP 위에서 동작하는 전략을 택했다.

UDP는 거의 모든 네트워크 장비가 이미 통과시켜주고, 애플리케이션 레벨에서 구현할 수 있다. QUIC는 UDP라는 "최소한의 껍데기"만 빌리고, 그 위에 신뢰성·순서 보장·혼잡 제어 등 TCP가 하던 일을 직접 구현한 것이다.

HTTP/2 스택:             HTTP/3 스택:
┌──────────┐            ┌──────────┐
│  HTTP/2  │            │  HTTP/3  │
├──────────┤            ├──────────┤
│   TLS    │            │   QUIC   │  ← TCP + TLS를 하나로
├──────────┤            ├──────────┤
│   TCP    │            │   UDP    │  ← 최소한의 전송 껍데기
├──────────┤            ├──────────┤
│    IP    │            │    IP    │
└──────────┘            └──────────┘

특징. HTTP/2에서 별도 계층이던 TCP와 TLS가, QUIC에서는 하나로 통합되었다.

3. 스트림 인식 — TCP 레벨 HOL Blocking 해결

QUIC는 Transport Layer에서 Stream을 직접 인식한다. TCP가 Stream을 인식하지 못하고 바이트스트림으로만 인식했던것과 결정적인 차이이다.

[HTTP/2 + TCP]
TCP가 보는 것:  [바이트][바이트][바이트][바이트]...
→ 하나의 연속된 흐름. 중간이 빠지면 전부 대기.
→ 어느 바이트가 어디 스트림인지 구분할수 가 없음.

[HTTP/3 + QUIC]
QUIC가 보는 것: [S1:DATA] [S2:DATA] [S3:DATA]
→ Stream별 독립적 흐름. S1이 빠져도 S2, S3는 계속 진행.

패킷 유실 시 동작을 비교하면 차이가 명확하다.

HTTP/2 + TCP:
  S1 패킷 유실 → TCP 재전송 대기 → S2, S3 전부 블로킹 ❌

HTTP/3 + QUIC:
  S1 패킷 유실 → S1만 재전송 대기
                → S2 계속 수신 ✅
                → S3 계속 수신 ✅

4. QUIC 패킷 구조

TCP Segment와 QUIC Packet을 나란히 놓으면 설계의 차이가 보인다.

[TCP Segment]
┌──────────────────────────────┐
│ TCP Header                   │
│  - Source/Dest Port          │
│  - Sequence Number           │
│  - ACK Number                │
│  - Window Size               │
├──────────────────────────────┤
│ Payload (바이트 스트림)         │
│  → Stream 구분 없음            │
└──────────────────────────────┘

[QUIC Packet]
┌──────────────────────────────┐
│ QUIC Header                  │
│  - Connection ID             │
│  - Packet Number             │
├──────────────────────────────┤
│ Frame 1: STREAM              │
│  - Stream ID: 1              │
│  - Offset: 0                 │
│  - Data: ...                 │
├──────────────────────────────┤
│ Frame 2: STREAM              │
│  - Stream ID: 3              │
│  - Offset: 500               │
│  - Data: ...                 │
├──────────────────────────────┤
│ Frame 3: ACK                 │
│  - 수신 확인 정보               │
└──────────────────────────────┘

TCP vs. QUIC 비교

Connection ID - IP/Port 조합이 아니라 이 ID로 커넥션을 식별한다. 네트워크 전환(Wi-Fi → LTE)으로 IP가 바뀌어도 커넥션이 유지된다.
(길에서 와이파이에서 LTE로 변환될 때 끊기는 현상이 바로 이것 때문이다. IP/Port 가 바뀌면서 TCP 커넥션을 새로 맺어야 하기 때문이다.)
Stream ID + Offset - 하나의 패킷 안에 여러 Stream의 Frame이 공존하며, 각 Frame이 자신이 속한 Stream과 해당 Stream 내 위치(Offset)를 명시한다. TCP는 하나의 연속된 바이트 스트림이므로 이런 구분이 불가능하다.
Packet Number의 순 증가. - TCP의 Sequence Number는 재전송 시 같은 번호를 재사용한다. 이로인해 ACK가 돌아왔을 때 원본에 대한 것인지 재전송에 대한 것인지 구분할 수 없다.
반면에 QUIC의 Packet Number는 절대 재사용되지 않는다. 재전송에도 새 번호를 부여한다. 데이터의 위치는 Stream Offset으로 식별하므로 수신 측이 동일 데이터의 재전송임을 알 수 있고, 동시에 어떤 패킷에 대한 ACK인지를 정확히 구분할 수 있다.

[TCP 재전송]
  원본:   SEQ=1100, 데이터 A
  재전송: SEQ=1100, 데이터 A   ← 같은 번호
  → ACK=1200이 원본에 대한 응답인지 재전송에 대한 응답인지 불분명 (RTT 측정 부정확)

[QUIC 재전송]
  원본:   Packet 10, [Stream 1, Offset 100, 데이터 A]
  재전송: Packet 25, [Stream 1, Offset 100, 데이터 A]   ← 새 번호
  → Packet 25에 대한 ACK → 재전송의 RTT를 정확히 측정 가능

5. QUIC 혼잡 제어

QUIC의 혼잡 제어는 TCP의 개념을 따른다. 기본 알고리즘으로 Slow Start, Congestion Avoidance, Recovery Period를 규정하고 있고, TCP의 구조와 유사하다.

개념은 비슷하지만 정밀도가 다르다. Packet Number의 순증가 덕분에 재전송 모호성이 없고, RTT를 매우 정확하게 측정할 수 있다. 이를 통해 혼잡 상태를 정밀하게 판단하여 불필요한 전송 속도 감소를 줄이고 ACK 방식도 개선되었다.

[TCP — 누적 ACK(Cumulative ACK)]
  패킷 상태: 1✅ 2✅ 3❌ 4✅ 5✅ 6✅
  ACK=3 ("3번부터 보내줘")
  → 4·5·6이 도착했는지 알 수 없음

[QUIC — ACK Range]
  패킷 상태: 1✅ 2✅ 3❌ 4✅ 5✅ 6✅
  ACK Frame: [1-2 수신, 4-6 수신]
  → "3만 빠졌구나" 정확히 파악 → 3만 재전송

추가로 TCP와 QUIC의 구현에 있어 전략적인 차이가 있다.

- TCP의 혼잡 제어는 OS 커널에 구현되어 있어 알고리즘 변경에 OS 업데이트가 필요하다.

- 반면에, QUIC는 User Space(애플리케이션)에서 동작하므로, 애플리케이션 업데이트만으로 새 알고리즘을 적용할 수 있다.
Google은 Chrome 업데이트 한 번으로 전 세계에 새 혼잡 제어 알고리즘을 배포하고 테스트할 수 있다.

6. 핸드셰이크 혁신: 1-RTT와 0-RTT

1-RTT — 최초 연결

TCP + TLS 1.3은 TCP Handshake에 1 RTT, TLS Handshake에 1 RTT로 총 2 RTT가 필요하다. QUIC는 전송 핸드셰이크와 TLS 핸드셰이크를 하나로 통합하여 1 RTT만에 연결을 수립한다.

[TCP + TLS 1.3 — 2 RTT]
  RTT 1: SYN → SYN-ACK → ACK          (TCP 연결)
  RTT 2: ClientHello → ServerHello     (TLS 연결)
  → 첫 데이터 전송

[QUIC — 1 RTT]
  RTT 1: Initial Packet (전송+TLS 통합 핸드셰이크)
  → 첫 데이터 전송

서울에서 미국 서버까지 RTT가 150ms라면, 이것만으로 150ms를 절약하는 셈이다.

0-RTT — 재연결

한번 연결했던 서버에 다시 접속할 때 더 극적이다. 클라이언트가 이전 연결에서 받은 Session Ticket 또는 Pre-Shared Key를 로컬에 저장해뒀다가, 재연결 시 첫 패킷에 암호화된 요청 데이터를 바로 실어 보낸다. 핸드셰이크 완료를 기다리지 않으므로 0-RTT에 데이터 전송이 시작된다.

0-RTT의 보안 취약점: Replay Attack

다만, 0-RTT에는 보안 취약점이 존재한다. 공격자가 0-RTT의 첫 패킷을 암호 해독 없이 그대로 복사하여 서버에 재전송하면, 서버는 이를 정상 요청으로 인식하여 처리할 수 있다.

정상 사용자:  [암호화된 "POST /payment {amount:100000}"]  → 서버
공격자:      [동일 패킷 복사]                             → 서버 (결제 2회 실행)

공격자는 응답을 복호화할 수 없지만, 요청이 서버에서 재실행되는 것 자체가 문제이다.

이 때문에 0-RTT에는 멱등한 요청만 허용하는 것이 원칙이다. GET처럼 동일 요청을 두 번 해도 결과가 같은 요청은 0-RTT에 실을 수 있지만, POST처럼 중복 실행 시 사이드 이펙트가 있는 요청은 1-RTT Handshake가 완료된 후에만 전송해야 한다.

7. 네트워크 전환에도 끊기지 않는 연결

TCP 커넥션은 (Source IP, Source Port, Dest IP, Dest Port) 4-Tuple로 식별된다. Wi-Fi에서 LTE로 전환되면 클라이언트의 IP가 바뀌므로 TCP 커넥션이 끊어지고 새로 연결해야 한다.

QUIC 커넥션은 Connection ID로 식별한다. IP/Port가 바뀌어도 Connection ID가 동일하면 같은 커넥션으로 인식한다. 네트워크가 전환되어도 TCP 핸드셰이크 없이 데이터 전송이 이어진다.

5. 전체 비교

	HTTP/1.1	HTTP/2	HTTP/3
전송 계층	TCP	TCP	QUIC (UDP 기반)
TLS	별도 계층 (선택)	별도 계층 (사실상 필수)	QUIC에 내장 (필수)
커넥션 모델	도메인당 최대 6개 TCP 커넥션	도메인당 TCP 커넥션 1개	도메인당 QUIC 커넥션 1개
멀티플렉싱	없음 (순차 처리)	Stream 기반 멀티플렉싱	Stream 기반 멀티플렉싱
HOL Blocking	Application 레벨 ❌	App 레벨 ✅ / TCP 레벨 ❌ (재전송)	App 레벨 ✅ / Transport 레벨 ✅
헤더 처리	평문 텍스트, 중복 전송	HPACK (정적+동적 테이블)	QPACK (HPACK의 QUIC 적응)
핸드셰이크	TCP 1 RTT + TLS 1~2 RTT	TCP 1 RTT + TLS 1 RTT = 2 RTT	최초 1 RTT / 재연결 0 RTT
Server Push	없음	지원 (하지만 사실상 폐기)	지원하지 않음
흐름 제어	TCP 커넥션 단위	TCP + Stream별 이중 구조	QUIC Stream별 독립 제어
네트워크 전환	커넥션 끊김 (IP 기반 식별)	커넥션 끊김 (IP 기반 식별)	Connection ID로 유지
혼잡 제어 진화	OS 커널 의존 (느린 개선)	OS 커널 의존 (느린 개선)	User Space (빠른 개선)

MSA에서 CORS 문제를 해결하는 4가지 전략

구름뭉치 — Fri, 27 Mar 2026 22:15:47 +0900

실무나 사이드프로젝트를 하면 항상 만나게 되는 에러가 있는데 바로 CORS이다.

자주 보는 CORS 에러지만 우리가 제대로 이해하고 해결하고 있는지는 곰곰히 생각해보자.

프로젝트를 진행하면서 CORS 에러를 만나면 "Access-Control-Allow-Origin: *" 을 추가하고 넘어가곤 했다.

모놀리식에서는 그걸로 충분할 수 있지만, MSA 환경에서는 이 접근이 보안 취약점이 되거나 운영상 큰 장애 요인이 될 수 있다.

이번 글에서 CORS의 동작 원리를 정확히 이해하고, MSA에서 CORS를 어느 계층에서 어떻게 관리할 수 있는지 설계 관점까지 알아보고자 한다.

1. Same-Origin Policy — 왜 브라우저는 Cross-Origin 요청을 막을까?

1. 브라우저를 악용하는 공격

하나의 시나리오를 봐보자.

우리가 https://my-bank.com에 로그인한 상태에서, 다른 탭으로 https://evil-site.com에 접속했다. 이 악성 사이트의 JavaScript가 다음 코드를 실행한다.

fetch("https://my-bank.com/api/transfer?to=hacker&amount=1000000");

브라우저는 https://my-bank.com으로 요청을 보낼 때, 요청을 시작한 주체와 무관하게 해당 도메인의 쿠키를 자동으로 포함한다.

서버 입장에서는 정상 로그인된 사용자의 요청과 악성 요청을 구분할 수가 없는것이다.

이것이 바로 CSRF(Cross-Site Request Forgery) 공격이다.

Same-Origin Policy는 이러한 위협을 막기 위해 브라우저에 내장된 보안 정책이다.

핵심은 다른 Origin에서 온 스크립트가 응답 데이터를 읽는 것을 차단하는 것이다. 해커가 네트워크를 가로채는 것을 막는 것(이건 TLS/HTTPS의 역할이다)이 아니라, 사용자의 브라우저를 대리인으로 악용되는걸 막는다.

2. Origin의 정확한 정의

여기서 말하는 Origin은 세 가지 요소의 조합으로 결정된다.

Scheme(프로토콜) + Host(도메인) + Port

예를 들어 https://api.example.com:8443이라면, Scheme는 https, Host는 api.example.com, Port는 8443이다.

세 요소 중 하나라도 다르면 Cross-Origin이다.

비교	결과	이유
https://example.com vs https://example.com/api/users	Same-Origin	Path는 Origin 판단에 포함되지 않음
https://example.com vs http://example.com	Cross-Origin	Scheme이 다름
https://example.com vs https://api.example.com	Cross-Origin	Host가 다름 (서브도메인도 다른 Host)
https://example.com vs https://example.com:8443	Cross-Origin	Port가 다름

3. Same-Origin Policy가 차단하는 것

많은 사람들이 오해하는 부분이 있는데, Same-Origin Policy는 요청 자체를 막지는 않는다.

Cross-Origin 요청은 실제로 서버에 도달하고, 서버는 처리하고 응답도 보낸다. 브라우저가 차단하는 것은 JavaScript가 그 응답을 읽는 행위다.

이 구분이 왜 중요한지는 바로 다음에 나오는 Preflight 메커니즘에서 명확해진다.

2. CORS 동작 방식 — 브라우저와 서버의 협의 프로토콜

CORS(Cross-Origin Resource Sharing)는 Same-Origin Policy의 제한을 통제된 방식으로 완화하는 메커니즘이다.

브라우저가 서버에게 "이 Cross-Origin 요청을 허용해도 될까?"를 묻고, 서버가 HTTP 헤더로 응답하는 구조다.

CORS 요청은 세 가지로 분류된다.

1. Simple Request (단순 요청)

브라우저가 특정 조건을 만족하는 요청을 "단순 요청"으로 분류하고, Preflight 없이 바로 서버에 보내는 방식이다. 조건은 다음과 같다.

HTTP 메서드가 GET, HEAD, POST 중 하나
헤더가 Accept, Accept-Language, Content-Language, Content-Type 등 기본 헤더만 포함
Content-Type이 application/x-www-form-urlencoded, multipart/form-data, text/plain 중 하나

근데 의문이 드는 부분이 있다. GET, HEAD는 일리있는데 POST가 preflight 없이 가도되는 단순요청인게 이상하다.

분명히 CORS는 프론트나 서버에서 막지 않고 상대 서버까지 요청이 수행되어서 응답이 돌아오고, 브라우저에서 응답을 보여줄지 말지 차단하는 것이라고 했다.

그렇다면 POST의 경우 데이터의 생성/수정/삭제 등 조작이 가능한 Header이므로 미리 요청이 가기전에 막는 Preflight를 적용해야할거 같은데 왜 Simple Request에 포함되도록 설계했을까?

사실 이 조건이 이렇게 설계된 이유는 역사적 호환성때문이다. CORS 명세가 만들어지기 이전에도 브라우저는 이미 Cross-Origin 요청을 보낼 수 있었고 보내고 있었다.

HTML <form> 태그의 submit → POST 가능
Content-Type은 application/x-www-form-urlencoded이나 multipart/form-data
<img>, <script>, <link> 태그 → GET 요청

이 요청들은 CORS 이전에도 자유롭게 Cross-Origin으로 날아가고 있었다.

이걸 갑자기 막으면 기존 웹 생태계가 깨지므로, CORS 명세는 "기존에 이미 가능했던 요청은 그대로 허용하고, CORS 이전에는 불가능했던 새로운 종류의 요청만 Preflight으로 사전 검증하자"는 방향으로 설계되었다.

Simple Request의 흐름

브라우저가 바로 요청을 보냄 (Origin 헤더 포함)
서버가 응답에 Access-Control-Allow-Origin 헤더를 포함
브라우저가 응답의 Allow-Origin과 요청의 Origin을 비교
일치하면 JavaScript에게 응답을 전달, 불일치하면 차단

2. Preflight Request (사전 요청)

Simple Request 조건을 만족하지 않는 요청은 Preflight 대상이 된다.

우리가 REST API에서 흔히 쓰는 Content-Type: application/json이나 Authorization 헤더는 Simple Request 조건에 포함되지 않으므로, 사실상 대부분의 API 호출은 Preflight 대상이다.

개발자 도구를 켜서 보면 실제 프리플라이트 요청을 볼 수 있다

Preflight이 필요한 이유는 앞서 설명한 Same-Origin Policy의 특성과 관련된다.

Same-Origin Policy는 "응답 읽기"를 차단할 뿐, 요청은 서버에 도달한다. DELETE나 PUT처럼 서버 상태를 변경하는 요청은 도달하는 것 자체가 위험하다. 그래서 브라우저는 본 요청을 보내기 전에 서버에게 먼저 허락을 구한다.

Step 1 — 브라우저가 OPTIONS 메서드로 사전 질의

"내 Origin은 ~이야. 헤더는 ~이야. DELETE 명령을 해도 될까?" 라고 미리 묻는다.

OPTIONS /api/users HTTP/1.1
Host: api.example.com
Origin: https://frontend.example.com
Access-Control-Request-Method: DELETE
Access-Control-Request-Headers: Authorization, Content-Type

Step 2 — 서버가 허용 여부를 헤더로 응답

"Ok. 요청해도돼. 우리가 허용하는 도메인은 ~고, ~ 명령만 허용하고, ~ 헤더타입만 허용해. 3600초 동안은 또 묻지마." 라고 답한다.

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://frontend.example.com
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
Access-Control-Allow-Headers: Authorization, Content-Type
Access-Control-Max-Age: 3600

Access-Control-Max-Age: 3600은 "이 허락은 3600초 동안 유효하니까 그동안은 Preflight을 다시 보내지 않아도 된다"는 뜻이다.

Step 3 — 허락을 확인한 후 본 요청 전송

브라우저가 Preflight 응답을 확인하고, 허용된 경우에만 실제 DELETE /api/users 요청을 보낸다.

3. Credentialed Request (인증 포함 요청)

쿠키나 Authorization 헤더 같은 인증 정보를 포함하는 Cross-Origin 요청은 추가적인 제약이 적용된다.

기본적으로 Cross-Origin fetch는 쿠키를 보내지 않는다. 보내려면 양쪽 모두의 명시적 동의가 필요하다.

클라이언트 — credentials: "include" 설정
서버 — Access-Control-Allow-Credentials: true 응답

그리고 이때 핵심 제약이 붙는다.

Access-Control-Allow-Origin에 와일드카드(*)를 사용할 수 없고, 정확한 Origin을 명시해야 한다.

이유는 단순하다.
Allow-Origin: * + Allow-Credentials: true가 조합되면, 인터넷의 어떤 사이트든 사용자의 인증 정보를 포함한 요청을 보내고 응답까지 읽을 수 있게 된다. 앞서 설명한 은행 시나리오에서 잔액 조회, 개인정보 열람까지 모두 가능해지는 것이다.

4. 세 분류의 관계

참고로 이 세 분류(Simple Request, Preflight Request, Credentialed Request)는 서로 배타적이지 않다는 것이다.

Credentialed Request는 별도의 카테고리가 아니라, Simple이든 Preflight이든 그 위에 얹어지는 추가 제약이다.

예를 들어 Authorization 헤더 + Content-Type: application/json을 포함해서 credentials: "include"로 요청하면, Preflight 조건도 충족하고 Credentialed 조건도 충족한다.

-> 그러면 이제 Preflight 요청도 하면서 + 쿠키도 보내게 되고, 서버는 Access Control-Allow-Origin에 명시적인 값을 채워야 하는것이다.

3. MSA에서 CORS가 복잡해지는 이유

모놀리식 아키텍처에서는 프론트엔드와 백엔드가 같은 Origin에서 서빙되거나, CORS 설정을 한 곳에서 관리하면 끝이다. 그러나 MSA에서는 구조 자체가 CORS 관리를 복잡하게 만든다.

프론트엔드:   https://app.example.com
유저 서비스:  https://user-api.example.com
주문 서비스:  https://order-api.example.com
결제 서비스:  https://payment-api.example.com

1. CORS는 브라우저 → 서버 구간에서만 적용된다

여기서 반드시 짚고 넘어가야 할 개념이 있다. 마이크로서비스 간 통신에는 CORS가 적용되지 않는다. 주문 서비스가 유저 서비스를 RestTemplate이나 WebClient로 호출하는 건 서버 대 서버 통신이다. 브라우저가 없으므로 Same-Origin Policy 자체가 개입하지 않는다.

CORS가 문제가 되는 구간은 오직 브라우저(프론트엔드) → 마이크로서비스 요청뿐이다.

2. 개별 마이크로서비스에서 CORS를 관리하면 생기는 문제

각 마이크로서비스가 개별적으로 CORS를 설정하면 다음과 같은 문제가 발생한다.

설정 중복 — 모든 서비스에 동일한 프론트엔드 Origin을 등록해야 한다. 서비스가 50개라면 50곳 전부에!
변경 전파의 어려움 — 프론트엔드 도메인이 변경되거나 새 클라이언트(관리자 페이지 등)가 추가되면 모든 서비스를 수정·배포해야 한다.
설정 불일치 위험 — 서비스 A는 Allow-Methods에 DELETE를 넣었는데 서비스 B는 빠뜨리는 식으로, CORS 정책이 서비스마다 미묘하게 달라질 수 있다.

이 문제의 본질은 횡단 관심사를 각 서비스에 분산시킨 것이다. 인증, 로깅, 호출량 제어 등을 각 서비스에 개별 구현하면 안 되듯이, CORS도 마찬가지다.

4. MSA에서 CORS를 처리하는 4가지 전략

1. API Gateway에서 처리

API Gateway는 North - South를 담당하는 영역으로, MSA에서 모든 외부 트래픽이 통과하는 단일 진입점(Single Entry Point)이다. North-South 트래픽의 연결점으로서, 브라우저와의 통신이 반드시 거치는 지점이므로 CORS 처리에 가장 자연스러운 위치다.

Spring Cloud Gateway 설정 예시

application.yml 선언적 설정

spring:
  cloud:
    gateway:
      globalcors:
        cors-configurations:
          '[/**]':
            allowedOrigins: "https://app.example.com"
            allowedMethods:
              - GET
              - POST
              - PUT
              - DELETE
              - OPTIONS
            allowedHeaders:
              - Authorization
              - Content-Type
            allowCredentials: true
            maxAge: 3600

Java Config 방식

@Configuration
public class CorsConfig {

    @Bean
    public CorsWebFilter corsWebFilter() {
        CorsConfiguration config = new CorsConfiguration();
        config.addAllowedOrigin("https://app.example.com");
        config.addAllowedMethod("*");
        config.addAllowedHeader("*");
        config.setAllowCredentials(true);
        config.setMaxAge(3600L);

        UrlBasedCorsConfigurationSource source =
            new UrlBasedCorsConfigurationSource();
        source.registerCorsConfiguration("/**", config);

        return new CorsWebFilter(source);
    }
}

allowCredentials: true를 설정했기 때문에 allowedOrigins에 [*]를 사용할 수 없다.
위에서 다룬 Credentialed Request의 제약이 그대로 적용되는 것이다.

게이트웨이를 통한 설정 장점

CORS 설정을 단일 지점에서 관리하므로 중복과 불일치가 없다.
코드 레벨에서 동적이고 세밀한 정책 관리가 가능하다.
단위 테스트를 통한 검증이 가능하다.
프론트엔드 도메인 변경 시 한 곳만 수정하면 된다.

주의점 — CORS 헤더 중복

API Gateway에서 CORS를 처리하기로 했으면, 개별 마이크로서비스에서는 CORS 설정을 반드시 제거해야 한다.

Gateway에 CORS 헤더가 있고, 뒤쪽 마이크로서비스에도 @CrossOrigin 같은 설정이 남아있으면 응답에 동일한 CORS 헤더가 두 번 포함된다.

Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Origin: https://app.example.com

브라우저는 Access-Control-Allow-Origin 헤더가 두 개 이상이면, 값이 동일하더라도 CORS 에러로 처리한다. 서버 로그에서는 정상으로 보이는데 브라우저에서 CORS 에러가 발생하는 이 상황은 디버깅이 매우 까다롭다.

즉, 원칙은 단순하다. CORS 처리 계층을 딱 하나로 정하고, 나머지에서는 전부 제거하자.

2. 리버스 프록시(Nginx)에서 처리

실무에서 API Gateway 앞에 Nginx 같은 리버스 프록시를 두는 구조가 흔하다.

Nginx는 L7(Application Layer) 리버스 프록시로서 HTTP 헤더를 읽고 조작할 수 있으므로, CORS 처리가 가능하다.

Nginx CORS 설정 예시

server {
    listen 443 ssl;
    server_name api.example.com;

    location / {
        # Preflight 요청은 즉시 응답
        if ($request_method = 'OPTIONS') {
            add_header 'Access-Control-Allow-Origin' 'https://app.example.com';
            add_header 'Access-Control-Allow-Methods' 'GET, POST, PUT, DELETE';
            add_header 'Access-Control-Allow-Headers' 'Authorization, Content-Type';
            add_header 'Access-Control-Max-Age' 3600;
            return 204;
        }

        # 본 요청에 CORS 헤더 부착
        add_header 'Access-Control-Allow-Origin' 'https://app.example.com' always;
        add_header 'Access-Control-Allow-Credentials' 'true' always;

        proxy_pass http://api-gateway;
    }
}

Preflight인 OPTIONS 요청을 Nginx에서 즉시 204로 응답하고, 본 요청만 Gateway로 넘기는 구조다.

Nginx를 통한 설정 장점

Preflight 응답이 Gateway까지 도달하지 않아 응답 속도가 빠르다.
API Gateway의 불필요한 Preflight 처리 부하를 제거할 수 있다.

한계점

Nginx 설정은 기본적으로 정적 텍스트 파일이므로, 서비스별로 다른 CORS 정책을 적용하기가 까다롭다.
Access-Control-Allow-Origin은 하나의 Origin만 넣을 수 있어서, 여러 Origin을 허용하려면 $http_origin을 검사하는 if 분기를 직접 작성해야 한다. 근데 텍스트 파일 베이스이므로 문법 오류가 나기 쉽상이다.
코드 레벨의 정합성 검증이 어렵고, 테스트 코드를 작성하기도 제한적이다.
설정 변경 시 Nginx reload가 필요하다.

Nginx vs API Gateway 비교

	Nginx	API Gateway
Preflight 응답 속도	빠름 (앞단에서 즉시 응답)	상대적으로 느림
Gateway 부하	Preflight 부하 없음	Preflight도 처리해야함
세밀한 정책 관리	어려움 (정적 설정)	용이함 (코드 레벨 제어)
테스트·검증	제한적	단위 테스트 가능
설정 변경 시	Nginx reload 필요	애플리케이션 재배포

즉, CORS 정책이 단순하고 전체 API에 동일하게 적용된다면 Nginx에서 처리하는 게 효율적이고, 정책이 복잡하거나 동적이면 API Gateway에서 처리하는 게 관리에 유리하다.

3. BFF(Backend For Frontend) 패턴으로 CORS 제거

앞의 두 방식이 "CORS를 어디서 처리할까"였다면, BFF는 발상 자체를 바꿔서 CORS가 발생하지 않게 만드는 접근이다.

브라우저 (https://app.example.com)
  ↓ Same-Origin → CORS 발생 안 함
BFF 서버 (https://app.example.com)
  ↓ 서버 대 서버 → CORS 무관
마이크로서비스들 (내부 네트워크)

BFF 서버가 프론트엔드 정적 파일도 서빙하고 API 요청도 받아서 뒤쪽 마이크로서비스로 프록시한다.

브라우저 입장에서 모든 요청이 https://app.example.com으로 가니까 Cross-Origin이 성립하지 않고, BFF에서 마이크로서비스로의 호출은 서버 대 서버 통신이라 CORS가 적용되지 않는다.

BFF 패턴 장점

BFF는 단순히 CORS를 없애는 것 이상의 가치를 제공한다.

응답 조합(Aggregation) — 하나의 화면에 유저 정보 + 주문 내역 + 결제 상태가 필요하면, BFF가 세개의 서비스를 호출해서 하나의 응답으로 합쳐준다.
클라이언트별 최적화 — 웹용 BFF, 모바일용 BFF를 분리해서 각 클라이언트에 최적화된 API를 제공할 수 있다.

한계

관리 포인트 증가 — 프론트엔드 클라이언트(웹, 모바일, 어드민 등)마다 별도의 BFF가 필요할 수 있다. 각 BFF를 별도로 개발, 배포, 모니터링해야 한다.
네트워크 홉 추가 — 모든 요청이 BFF를 거치므로 네트워크 홉이 하나 더 생긴다. 이는 지연 시간 증가와 네트워크 유실 가능성 증가로 이어질 수 있다.
병목 위험 — BFF에 모든 트래픽이 집중되므로, BFF 자체의 장애가 해당 클라이언트의 전체 서비스 장애로 이어진다.

4. 전략 조합

이 네 가지 전략은 반드시 하나만 선택해야 하는 것이 아니다. 실무에서는 상황에 맞게 조합하는 것이 효과적이다.

Nginx + API Gateway 조합

가장 흔한 조합이다. 역할을 명확히 분리하는 것이 핵심이다.

Nginx — Preflight(OPTIONS)에 대해 즉시 204 응답. 본 요청은 CORS 헤더 없이 Gateway로 프록시.
API Gateway — 본 요청의 응답에 CORS 헤더 부착. 서비스별 세밀한 정책 관리.

이렇게 하면 Preflight은 Nginx에서 빠르게 처리되면서도 복잡한 정책은 API Gateway에서 코드 레벨에서 관리할 수 있고, 어떤 응답에도 CORS 헤더가 정확히 한 번만 붙는다.

API Gateway + BFF 조합

트래픽이 집중되는 주력 클라이언트는 BFF로 CORS 자체를 제거하고, 나머지 클라이언트는 API Gateway에서 일괄적으로 CORS를 처리하는 하이브리드 전략이다. 모든 브라우저 별 클라이언트의 CORS 관리는 Gateway에 맡기고 핵심 진입점은 BFF를 통해 CORS를 없애고 성능을 관리한다.

Nginx + API Gateway + BFF 조합

대규모 서비스에서 사용하는 구조다.

브라우저 (웹)
  ↓ Same-Origin
BFF (https://app.example.com) ─── 정적 파일 서빙 + API 프록시
  ↓ 서버 대 서버
Nginx (L7 로드밸런서, SSL 종료)
  ↓
API Gateway (인증, 라우팅, 레이트리밋)
  ↓
마이크로서비스들

이 구조에서 CORS는 BFF 덕분에 아예 발생하지 않는다.

Nginx와 API Gateway는 CORS가 아닌 다른 횡단 관심사(SSL 종료, 로드밸런싱, 인증, 라우팅)에 집중한다. 복잡성은 높지만, 각 계층이 명확한 책임을 가지므로 대규모 환경에서는 오히려 체계적인 관리가 가능하다.

아키텍처 다이어그램

5. 정리

1. CORS 메커니즘 요약

	조건	브라우저 동작
Simple Request	CORS 이전에 이미 가능했던 요청 형태 (특정 메서드, 헤더, Content-Type)	Preflight 없이 바로 전송. 응답의 Allow-Origin 확인 후 차단 여부 결정
Preflight Request	Simple Request 조건 불충족 (application/json, Authorization 헤더, DELETE/PUT 등)	본 요청 전 OPTIONS로 사전 질의. 허락받은 후에만 본 요청 전송
Credentialed Request	쿠키, Authorization 등 인증 정보 포함 시	클라이언트·서버 양쪽 명시적 동의 필요. Allow-Origin에 와일드카드 사용 불가

Credentialed Request는 별도 카테고리가 아니라, Simple/Preflight 위에 얹어지는 추가 제약이다.

2. MSA CORS 처리 전략 비교

전략 CORS 처리 위치 핵심 장점 핵심 한계

전략	CORS 처리 위치	핵심 장점	핵심 한계
개별 마이크로서비스	각 서비스	서비스 자율성	설정 중복, 불일치 위험, 변경 전파 어려움
API Gateway	Gateway 단일 지점	일원화된 관리, 세밀한 정책, 테스트 가능	Preflight도 Gateway까지 도달
리버스 프록시 (Nginx)	인프라 앞단	Preflight 빠른 응답, Gateway 부하 감소	동적 정책 어려움, 정적 설정 한계
BFF 패턴	CORS 자체 불필요	CORS 문제 원천 제거	관리 포인트 증가, 네트워크 홉 추가

3. 실무 설계 원칙

CORS 처리 계층은 반드시 하나로 통일하자. 여러 계층에서 CORS 헤더를 붙이면 헤더 중복으로 오히려 CORS 에러가 발생한다.
CORS는 브라우저 ↔ 서버 구간에서만 적용된다. 서비스 간(East-West) 통신에는 CORS가 무관하다.
Credentialed Request를 사용할 경우 와일드카드(*)를 쓸 수 없다. 허용할 Origin을 명시적으로 지정해야 한다.
전략은 조합할 수 있다. Nginx에서 Preflight를 빠르게 처리하고, API Gateway에서 세밀한 정책을 관리하는 식의 역할 분담이 효과적이다.

TCP/IP 체크섬(Checksum) 내부 동작 원리

구름뭉치 — Mon, 23 Mar 2026 20:57:18 +0900

개요

TCP/IP 프로토콜 스택에서 체크섬(Checksum) 은 데이터가 전송 과정에서 손상되지 않았는지 검증하는 오류 검출 메커니즘이다.

오늘날 인터넷의 모든 패킷은 이 체크섬을 거쳐 전송된다.

체크섬은 TCP/IP 스택의 여러 계층에서 동작하며, 각 계층의 체크섬은 보호 범위와 목적이 다르다.

이번 정리에서는 체크섬의 내부 동작 원리를 세 계층으로 나누어 정리한다.

L2 데이터 링크 계층의 Ethernet CRC (32bit)
L3 네트워크 계층의 IP Header Checksum (16bit)
L4 전송 계층의 TCP/UDP Checksum (16bit)

1. 기반 원리 - 1의 보수 연산과 설계 배경

checksum에 대해 들어가기 전에 bit 세계에서 역수를 취하기 위한 보수 방법 2가지에 대해 알아보자.

1의 보수 vs 2의 보수

현대 컴퓨터는 음수를 표현할 때 2의 보수 방식을 사용한다.

2의 보수는 모든 비트를 반전한 후 1을 더하는 방식으로, 0의 표현이 하나뿐이라는 장점이 있다.
- 0000 -> 반전 -> 1111 -> +1 -> 1_0000 -> carry 버림 -> 0000
반면에! 1의 보수는 모든 비트를 반전하는 방식이다. 단, +0(0000)과 -0(1111)이라는 두 개의 영(zero) 이 존재한다.

4비트 기준으로 비교하면 다음과 같다.

값	1의 보수	2의 보수	차이점
+5	0101	0101	동일
-5	1010	1011	1 차이
+0	0000	0000	동일
-0	1111	0000	1의 보수: 2개의 zero

TCP/IP 체크섬이 1의 보수를 선택한 이유

1의 보수 덧셈에는 핵심 속성 네 가지가 존재한다.

(P1) 교환법칙(Commutative)

더하는 순서가 결과에 영향을 미치지 않는다. -> 패킷 내 16비트 워드를 어떤 순서로 합산해도 동일한 체크섬을 얻는다.

(P2) 항등원 존재

1의 보수에는 +0과 -0 두 개의 항등원이 있다. -> 송신 측이 체크섬 필드에 0을 넣고 계산할 수 있다.
덧셈에 항등원이 없다면 초기값을 설정하는것부터 어려워진다.
초기값이 합산 결과에 영향을 주면 안되는데 항등원이 아닌 초기값이라면 영향을 주게 된다.

(P3) 역원 존재

어떤 수에 대해 더하면 0이 되는 수가 존재한다. -> 수신 측이 전체 합산 후 결과가 0인지만 확인하면 검증이 완료된다.
수정되지 않음을 증명하는 수에 대한 역원을 갖고 있다면 더해서 0이 되는지 확인하면 된다.

(P4) 결합법칙(Associative)

어떤 순서로 묶어 더해도 결과가 같다. -> 체크섬 필드가 패킷 어디에 위치하든 문제없이 계산할 수 있고, 병렬 처리도 가능하다.

End-Around Carry와 Endian 독립성

1의 보수 덧셈에서 가장 특별한 점은 end-around carry 이다.

16비트 덧셈 결과가 17비트로 넘치면(carry 발생)

- 2의 보수에서는 초과된 비트를 버리지만,
- 1의 보수에서는 그 1을 최하위 비트에 다시 더해준다.

  FFFF
+ 0001
------
 10000  ← 17비트, carry 발생

2의 보수: carry 버림 → 0000 (0 + 1 = 0)?
1의 보수: carry 다시 더함 → 0000 + 1 = 0001 (0 + 1 = 1)

이 특성이 실용적으로 중요한 이유는 Endian 독립성 때문이다.

1980년대 인터넷은 Little Endian, Big Endian 등 바이트 순서가 다른 기종이 혼재했다.

1의 보수 합은 바이트 순서를 바꿔 계산해도 결과가 정확히 바이트만 뒤집힌 형태가 된다.

체크섬 최종 검증 시 `0xFFFF`인지만 확인하는데, 0xFFFF는 바이트를 뒤집어도 0xFFFF이므로

어떤 Endian 장비에서 검증하든 동일한 결과가 나온다.

반면 2의 보수에서는 carry를 버리는 순간 이 대칭성이 깨진다.

예시로 확인해 보자.

[Big Endian]
  0x 01FF
+ 0x FE01
---------
01 + FE =  FF (하위 바이트)    carry 없음
FF + 01 = 100 (상위 바이트)    carry 1 발생

   FF  |
+   100|
-------
= 10000 → 1 캐리 더함 → 0000 + 1 = 0001 (carry 더함)
= 10000 → 1 캐리 버림 → 0000 = 0000 (carry 버림)

1의 보수: 0001
2의 보수: 0000

[Litten Endian]
  0x FF01
+ 0x 01FE 
---------
FF + 01 = 00 (상위 바이트)    carry 1 발생
01 + FE = FF (하위 바이트)    carry 없음

  100  |
+    FF|
--------
= 100FF → 1 캐리 더함 → 0100 (carry 더함)
= 100FF → 1 캐리 버림 → 00FF (carry 버림)

1의 보수
=> 00|01, 01|00
- 정확히 바이트 swap 관계 성립 ✅

2의 보수
=> 00|00, 00|FF
- 대칭성 깨짐 ❌

2. IP Header Checksum

IP 헤더 구조와 체크섬의 위치

IPv4 헤더는 최소 20바이트(5개의 32비트 워드)로 구성된다.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version|  IHL  |Type of Service|          Total Length         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Identification        |Flags|    Fragment Offset      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Time to Live |    Protocol   |       Header Checksum         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Source Address                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                  Destination Address                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

IP 체크섬은 IP Header만 보호한다. 페이로드(데이터)는 포함하지 않는다.
TTL 같은 필드가 라우터를 지날 때마다 변경되므로, 페이로드까지 포함하면 매 홉마다 수십 KB의 데이터를 재합산해야 하는 부담이 발생하기 때문이다.

계산 과정 예시

다음 IPv4 헤더를 예로 들어 계산 과정을 따라가 보자.

Source IP는 192.168.0.1, Destination IP는 192.168.0.199, Protocol은 UDP(17)이다.

IP Header (hex): 4500 0073 0000 4000 4011 [0000] C0A8 0001 C0A8 00C7
                                          ^^^^^^ 체크섬 필드 (0으로 초기화)

Step 1: 모든 16비트 워드 합산

4500 + 0073 + 0000 + 4000 + 4011 + 0000 + C0A8 + 0001 + C0A8 + 00C7
= 2479C   ← 17비트, carry 발생!

Step 2: End-Around Carry 처리

479C + 0002 = 479E

상위 carry를 하위 16비트에 더한다.

Step 3: 1의 보수 (비트 반전)

NOT 479E = B861   ← 최종 체크섬 값

이 값 0x B861이 IP 헤더의 체크섬 필드에 삽입된다.

즉, IP Header의 구성요소 + 체크섬 = FFFF == 0000(Zero)이 되어야 하는것이다.

수신 측 검증

수신 측은 체크섬 필드를 포함한 전체 헤더를 동일하게 합산한다.

4500 + 0073 + 0000 + 4000 + 4011 + [B861] + C0A8 + 0001 + C0A8 + 00C7
= 2FFFD

carry 처리: FFFD + 2 = FFFF
1의 보수:   NOT FFFF = 0000  ← 결과가 0이면 오류 없음

-> 결과가 0이면 정상, 0이 아니면 패킷 폐기.

라우터에서의 증분 업데이트

라우터는 패킷을 포워딩할 때 TTL을 1 감소시키므로 IP 헤더 체크섬을 재계산해야 한다.

매번 헤더 전체를 다시 합산하는 것은 비효율적이므로, TTL이 1 감소한만큼 +1 증분 업데이트 방식을 사용한다.

변경된 필드의 차이만큼만 체크섬을 보정하면 되며, 이것이 가능한 이유는 1의 보수 덧셈의 결합법칙과 교환법칙 덕분이다.

IPv6에서의 제거

IPv6에서는 IP 헤더 체크섬 필드가 제거되었다.

매 홉마다 재계산하는 부담을 없애고, 오류 검출은 기존 링크 계층(Ethernet CRC)과 전송 계층(TCP/UDP 체크섬)에 위임한다.

단, 이 결정으로 인해 IPv6에서는 UDP 체크섬이 필수가 되었다.

IP 헤더 체크섬이 없으면 UDP까지 체크섬을 끌 경우 IP 주소 손상을 감지할 계층이 아예 없어지기 때문이다.

참고: IPv6에서 없어진 것은 IP 헤더 자체가 아니라, 헤더 안의 "Header Checksum" 필드이다.
출발지/목적지 주소는 오히려 128비트로 확장되었고, TTL은 이름만 "Hop Limit"으로 바뀌었을 뿐 기능은 동일하다.

3. TCP/UDP Checksum과 Pseudo Header

IP 체크섬과의 결정적 차이

IP 체크섬이 헤더만 보호하는 것과 달리, TCP/UDP 체크섬은 헤더 + 페이로드 전체를 보호한다.

비교 항목	IP Header Checksum	TCP/UDP Checksum
보호 범위	헤더만	헤더 + 페이로드 전체
재계산	매 홉마다	없음 (end-to-end)
성격	라우팅 정보 무결성	end-to-end 데이터 무결성
IPv6	제거됨	유지 (UDP 필수화)

TCP는 end-to-end 프로토콜이므로 출발지에서 한 번 생성하고, 목적지에서 검증한다.
중간 라우터는 TCP 체크섬을 건드리지 않는다.

Pseudo Header의 필요성

TCP/UDP 체크섬을 헤더와 페이로드만으로 계산하면 심각한 문제가 발생한다.

IP 헤더의 목적지 주소가 전송 중 손상되어 엉뚱한 호스트에 도착하더라도, TCP 헤더와 페이로드 자체는 손상되지 않았으므로
체크섬 검증을 통과해 버린다. -> 이것이 바로 misrouted segment 문제이다.

=> 이 문제를 해결하기 위해 Pseudo Header(의사 헤더)를 도입했다.

Pseudo Header 구조 (IPv4)

필드	크기	설명
Source Address	32비트	IP 헤더의 출발지 IP 주소
Destination Address	32비트	IP 헤더의 목적지 IP 주소
Zero + Protocol	16비트	8비트 예약(0) + Protocol(TCP=6, UDP=17)
TCP/UDP Length	16비트	TCP/UDP 헤더 + 데이터 길이

Pseudo Header의 각 필드 역할

Source/Destination Address:
- IP 주소가 체크섬 계산에 포함된다. (뒤에서 얘기하겠지만 전송 계층에서 IP 주소를 보는건 엄밀히 규약 위반이다.)
- 주소가 손상되어 엉뚱한 호스트에 도착하면 수신 측이 자기 IP로 Pseudo Header를 만들어 검증할 때 체크섬이 불일치한다.
Protocol: TCP 세그먼트가 실수로 UDP로 해석되거나 그 반대 상황을 방지한다.
TCP/UDP Length: 데이터가 잘리거나 뒤에 쓰레기 바이트가 붙는 경우를 잡아낸다.

핵심: Pseudo Header는 실제로 전송되지 않는다. 체크섬을 계산할 때만 임시로 만들어서 쓰고, 계산이 끝나면 버린다.
수신 측도 도착한 패킷의 IP 헤더에서 동일한 정보를 꺼내 Pseudo Header를 재구성해서 검증한다.

TCP 체크섬 계산 대상

┌─────────────────────────┐
│  Pseudo Header (12byte) │  ← 실제 전송 안 됨, 계산에만 사용
├─────────────────────────┤
│  TCP Header (20+byte)   │  ← 체크섬 필드는 0으로
├─────────────────────────┤
│  TCP Payload (가변)      │  ← 홀수 바이트면 끝에 0 패딩
└─────────────────────────┘

계산 알고리즘은 IP Header Checksum과 완전히 동일하다 (16비트 1의 보수 합의 1의 보수).
달라지는 것은 입력 데이터의 범위 뿐이다.

Pseudo Header의 계층 위반 논쟁

Pseudo Header는 엄밀히 말해 계층 위반(layer violation)이다. 전송 계층(L4, TCP)이 네트워크 계층(L3, IP)의 정보를 직접 참조해야 하기 때문이다.

실제 구현에서는 두 계층이 같은 소켓 구조체를 공유한다.

TCP 계층이 connect()/bind() 시점에 이미 결정된 주소 정보를 읽어오는 방식으로 동작한다.
"3계층이 먼저" 또는 "4계층이 먼저"가 아니라, 두 계층 모두 같은 소켓 컨텍스트를 참조하는 것이다.

이 커플링 때문에 IP가 변경되면 TCP 체크섬 계산도 함께 수정되어야 한다.

실제로 IPv6에서는 Pseudo Header 구조가 변경되었다 (12바이트 → 40바이트, 주소가 128비트로 확장).

UDP 체크섬의 특이점

UDP 체크섬은 TCP와 계산 방식이 동일하지만, IPv4에서는 선택사항(optional)이다.

체크섬 필드에 0x0000을 넣으면 "체크섬을 사용하지 않겠다"는 의미이다. 실시간 스트리밍처럼 약간의 오류보다 재전송 지연이 더 치명적인 경우를 위한 설계이다.

단, IPv6에서는 UDP 체크섬이 필수이다. 3계층에서 IP 헤더 체크섬이 제거되었으므로, UDP까지 체크섬을 끄면 IP 주소 손상을 감지할 계층이 아예 없어지기 때문이다.

4. 데이터 링크 계층: Ethernet CRC-32

CRC의 동작 원리

TCP/IP 체크섬이 덧셈 기반인 반면, Ethernet CRC는 다항식 나눗셈 기반이다.

전송할 데이터를 하나의 거대한 이진수로 취급하고, 미리 약속된 생성 다항식으로 나눈 나머지가 CRC값이 된다.
CRC 계산의 핵심은 모듈로-2 연산(XOR 기반)이다.
- 13 mod 5 = 3
- 13/5 = 몫: 2, 나머지 3
일반적인 산술 나눗셈과 달리 빌림이나 올림이 없어서 하드웨어에서 매우 효율적으로 구현된다.

FCS(Frame Check Sequence) 필드에 이 CRC 값이 들어간다.

계산 범위

Source/Destination MAC 주소
Type 필드
Payload
Padding

위 목록을 포함한 프레임 거의 전부이다.

CRC vs 1의 보수 합산 비교

특성 TCP/IP Checksum CRC-32

특성	TCP/IP Checksum	CRC
수학적 기반	1의 보수 덧셈	GF(2) 다항식 나눗셈
출력 크기	16비트	32비트
워드 순서 변경 감지	불가능	가능
상쇄 오류 감지	불가능	거의 항상 감지
감지못할 확률	약 1/65,536	약 1/4,294,967,296
처리 주체	OS 커널 / NIC offload	NIC 하드웨어

CRC 재계산의 사각지대

Ethernet CRC는 체크섬 성능이 높은 편이지만 한 가지 중요한 약점이 있다. 매 홉마다 재계산된다는 것이다.

- 라우팅마다 비용도 높아지고, 중간 과정에서 오류가 발생했을 때 감지가 안된다.

[Host A] ──CRC 정상──→ [스위치] ──CRC 정상──→ [Host B]
                           │
                      여기서 메모리 오류로
                      패킷 데이터 손상!
                           │
                      하지만 스위치가 나갈 때
                      CRC를 새로 계산해서 붙임
                           │
                      → 나가는 CRC는 정상 OK
                      → 하지만 데이터는 손상됨 Damage!

스위치나 라우터의 메모리 오류, 버스 오류, 펌웨어 버그 등으로 패킷 내용이 손상되더라도,

해당 장비가 나가는 프레임에 새 CRC를 붙이므로 수신 측에서 보면 CRC는 완벽하게 유효하다.

이런 오류를 잡아내는 마지막 방어선이 바로 TCP/UDP 체크섬이다.

TCP 체크섬은 출발지에서 한 번 생성되고 중간에 재계산되지 않으므로, 중간 장비에서 발생한 손상을 end-to-end로 감지할 수 있다.

5. 계층별 종합 비교

패킷 송수신 전체 흐름

송신 측에서는 체크섬이 TCP → IP → Ethernet 순서로 생성된다.

TCP 계층이 Pseudo Header + TCP Header + Payload로 체크섬 계산
IP 계층이 IP Header만으로 체크섬 계산
NIC 하드웨어가 Ethernet CRC를 붙여 전송

수신 측에서는 정반대 순서(Ethernet → IP → TCP)로 검증한다.

중간 라우터 에서는 Ethernet CRC와 IP 체크섬만 검증/재계산한다.
TCP 체크섬은 건드리지 않으며, 이것이 end-to-end 무결성을 보장하는 핵심이다.

종합 비교표

	Ethernet CRC	IP Header Checksum	TCP/UDP Checksum
계층	L2 데이터 링크	L3 네트워크	L4 전송
알고리즘	CRC 다항식 나눗셈	1의 보수 합	1의 보수 합 (동일)
보호 범위	프레임 전체	IP 헤더만	Pseudo Header + 헤더 + Payload
보호 목적	물리적 전송 오류	라우팅 정보 무결성	end-to-end 데이터 무결성 + 오배송 방지
검증 위치	매 홉	매 홉	최종 목적지만
재계산	매 홉마다 새로 생성	매 홉 (TTL 변경)	없음
감지 강도	매우 강함 (32비트)	약함 (16비트)	약함 (16비트)
IPv6	유지	제거됨	유지 (UDP 필수화)

7. 결론

TCP/IP Checksum은 오랜기간 동안 네트워크 환경에서 사용되고 있는 단순하지만 효과적인 오류 검출 메커니즘이다.

1의 보수 합산이라는 단순한 연산으로 Endian 독립성, 빠른 연산 속도, 증분 업데이트 가능성을 동시에 확보한 설계이다.

각 계층의 체크섬은 서로 보완 관계에 있다.

Ethernet CRC-32: 물리적 전송 오류를 강력하게 감지하지만, 매 홉에서 재계산되는 약점이 있다.
IP Header Checksum: 라우팅 정보를 보호하지만 헤더만 커버한다.
TCP/UDP Checksum: 약하지만 유일하게 end-to-end로 동작하는 검증 메커니즘이다.

Java 기반 동기/비동기, 블로킹/논블로킹 정리

구름뭉치 — Mon, 23 Mar 2026 00:05:23 +0900

서로 다른 관심사

동기/비동기와 블로킹/논블로킹은 흔히 혼용되지만, 실제로는 서로 다른 관심사를 다루는 별개의 축이다.
이 구분을 명확히 하는것이 모든 논의의 바탕이 되므로 명확히 짚어보자.

동기(Synchronous) vs 비동기(Asynchronous)

작업 완료를 누가 확인하는가?

동기(Synchronous)
- 호출자(Caller)가 직접 작업의 완료 여부를 확인하거나 기다린다. 결과를 호출자가 내놓으라고 끌어오는 Pull 방식이다.
비동기(Asynchronous)
- 피호출자(Callee)가 작업이 완료되면 호출자에게 알려준다. 콜백(callback), 이벤트(event) 등을 통해
  결과를 내보내는 Push 방식이다.

즉, 동기/비동기의 핵심은 완료 통지의 주체가 누구인가이다.

블로킹 (Blocking) vs 논블로킹 (Non-Blocking)

제어권이 즉시 반환되는가?

블로킹 (Blocking)
- 호출된 함수가 작업을 완료할 때까지 호출자에게 제어권을 돌려주지 않는다. 호출자의 스레드는 그자리에서 멈추고 대기한다.
논블로킹 (Non-Blocking)
- 호출된 함수가 즉시 제어권을 반환한다. 작업이 완료되지 않았더라도 호출자는 다음 코드를 실행할 수 있다.

즉, 블로킹/논블로킹의 핵심은 호출자의 스레드가 멈추느냐 아니냐이다.

4가지 조합 - Java 코드 예시

	블로킹(Blocking)	논블로킹(Non-Blocking)
동기(Sync)	① Sync + Blocking	② Sync + Non-Blocking
비동기(Async)	③ Async + Blocking	④ Async + Non-Blocking

1. 동기 + 블로킹

호출자가 결과를 직접 확인하고 (동기), 결과가 올 때까지 스레드가 멈춤. (블로킹)
일반적인 Java 개발에서 볼 수 있는 형태이다. 대부분의 I/O 호출이 여기에 해당한다.

예시

1)
// JDBC 호출 — 전형적인 동기 + 블로킹
String name = jdbcTemplate.queryForObject(
    "SELECT name FROM users WHERE id = ?",
    String.class, userId
);
// DB가 결과를 반환할 때까지 이 스레드는 여기서 멈춘다.
System.out.println(name);

2)
// RestTemplate — 동기 + 블로킹 HTTP 호출
RestTemplate restTemplate = new RestTemplate();
String result = restTemplate.getForObject(
    "https://api.example.com/data", String.class
);
// 응답이 올 때까지 스레드가 블로킹된다.

3)
// CompletableFuture.get() — 비동기로 시작했지만, get()에서 동기 + 블로킹이 된다
CompletableFuture<String> future = CompletableFuture.supplyAsync(() -> heavyWork());
String result = future.get(); // 호출자가 직접 결과를 가져오고(동기), 완료까지 멈춘다(블로킹)

특징

코드가 순차적이므로 가독성이 높고 디버깅이 쉽다.
요청 하나당 스레드 하나가 점유되므로, 동시 요청이 많아지면 스레드 풀이 고갈될 수 있다.
Spring MVC + JDBC 기반의 전통적인 서버 아키텍처가 이 모델이다.

적합한 상황

요청량이 예측 가능하고, 개발 생산성과 코드 유지보수성을 우선시하는 경우에 적합하다.

2. 동기 + 논블로킹 (Synchronous + Non-Blocking)

호출자가 직접 결과를 확인하고 (동기), 제어권은 즉시 반환됨. (논블로킹)
호출자는 반환된 제어권으로 다른일도 하고 주기적으로 응답 완료 여부를 확인 (Polling) 한다.

예시

CompletableFuture<String> future = CompletableFuture.supplyAsync(() -> heavyWork());

// isDone()은 즉시 반환된다 (논블로킹)
// 호출자가 직접 완료 여부를 반복 확인한다 (동기 — polling)
while (!future.isDone()) {
    doSomethingElse(); // 제어권이 있으므로 다른 작업 가능
}
String result = future.get(); // 이미 완료되었으므로 즉시 반환

특징

호출자가 주기적으로 확인해야 하므로 CPU 타임(싸이클)을 소모한다. (Busy Wating 방식)
호출자가 완료를 직접 확인하는 만큼 호출자의 흐름안에서 결과를 처리할 수 있다.
실무에서 실제 사용하는 경우보다는 비동기-논블로킹을 가기 위한 단계로 볼 수 있다.

의문점 - 제어권이 호출자에게 반환되었는데, 피호출자의 작업은 어떻게 진행될 수 있을까?

바로 스레드가 분리되기 때문이다.

supplyAsync()는 기본적으로 ForkJoinPool.commonPool()의 워커 스레드에서 작업을 실행한다.

호출자의 스레드와 작업 스레드는 서로 다르기 때문에, 호출자가 제어권을 돌려받아도 작업은 다른 스레드에서 동시에 진행된다.

System.out.println("Caller: " + Thread.currentThread().getName());
// 출력: Caller: main

CompletableFuture<String> future = CompletableFuture.supplyAsync(() -> {
    System.out.println("Worker: " + Thread.currentThread().getName());
    // 출력: Worker: ForkJoinPool.commonPool-worker-1
    return heavyWork();
});

3. 비동기 + 블로킹 (Asynchronous + Blocking)

피호출자가 작업완료를 알려주고 (비동기), 제어권은 반환되지 않아 호출자의 스레드가 멈춰있다. (블로킹)
의도적인 설계보다는 비동기로 전환하던 중 블로킹 지점이 일부 남아있을 때 자연스럽게 발생하는 경우이다. (webflux + JDBC)

예시 1 (Spring WebFlux + JDBC Blocking)

Mono.fromCallable(() -> {
        // 리액티브 파이프라인 안에서 블로킹 JDBC 호출이 발생
        return jdbcTemplate.queryForObject(
            "SELECT name FROM users WHERE id = ?",
            String.class, userId
        );
    })
    .subscribeOn(Schedulers.boundedElastic())
    .subscribe(name -> sendResponse(name)); // 콜백으로 결과 수신 (비동기)

위 코드를 분석해보면
- 비동기인가? -> subscribe에 콜백을 등록하고, 파이프라인이 완료되면 알려주는 push 방식이다.
  호출자가 결과를 직접 끌어오지 않으므로 비동기다.
- 블로킹인가? -> 파이프라인 내부에서 jdbcTemplate 호출이 실행되는 순간, 그 작업을 실행하는 스레드는 DB 응답이 올 때까지 멈춘다. JDBC 자체가 블로킹 API이기 때문이다.
  호출자가 멈추므로 블로킹이다.

예시 2 (WebClient + JDBC)

// 비동기 + 논블로킹으로 의도한 코드
WebClient webClient = WebClient.create();

Mono<String> result = webClient.get()
    .uri("https://api.example.com/data")
    .retrieve()
    .bodyToMono(String.class)
    .flatMap(data -> {
        // ⚠️ 여기서 블로킹 JDBC 호출이 발생!
        String saved = jdbcTemplate.queryForObject(
            "INSERT INTO logs(data) VALUES(?) RETURNING id",
            String.class, data
        );
        return Mono.just(saved);
    });

result.subscribe(id -> log.info("저장 완료: {}", id));

위 코드를 분석해보면
- 1. 요청 수신 → Netty 이벤트 루프 스레드(reactor-http-nio-1)가 처리 시작
- 2. webClient.get()...bodyToMono()
  - 외부 API에 HTTP 요청 전송 (A)
  - 응답을 기다리는 동안 이벤트 루프 스레드는 해방됨
  - 다른 요청(B, C, D...)를 처리할 수 있다.
- 3. 외부 API 응답 도착 (A)
  - 이벤트 루프 스레드가 깨어나서 flatMap 진입
- 4. flatMap 내에서 jdbc.queryForObject() 호출 (블로킹!)
  - JDBC 블로킹 API - DB가 응답할 때까지 현재 스레드가 멈춘다!
  - 이 스레드는 Netty 이벤트 루프 스레드 (중요, Netty는 CPU 코어수만큼의 스레드로만 처리함)
  - DB 응답을 대기하는 수십~수백 ms 동안 이 루프에 할당된 모든 요청이 멈춘다.

특징

비동기 방식을 도입했으나 병목 지점에서 블로킹이 발생하여 비동기의 장점이 상쇄된다.
시스템 전체를 논블로킹으로 전환하지 않으면 제대로된 리액티브가 되지 못한다.

R2DBC의 등장 배경

즉, WebFlux를 도입하면 HTTP 요청 처리는 비동기 + 논블로킹이 된다.

하지만 DB 접근 계층에서 JDBC를 사용하면, 결국 그 지점에서 스레드가 블로킹된다.

비동기의 핵심 장점인 "적은 스레드로 높은 처리량"을 온전히 누릴 수 없는 것이다.

이 문제를 해결하기 위해 등장한 것이 R2DBC(Reactive Relational Database Connectivity)다.
R2DBC는 관계형 데이터베이스에 대한 완전한 논블로킹 API를 제공하여, WebFlux와 결합했을 때 요청 처리 전 구간에서
비동기 + 논블로킹을 달성할 수 있게 해준다.

Netty의 이벤트 루프 스레드 방식

Netty는 기본적으로 CPU 코어 수만큼의 이벤트 루프 스레드로 전체 요청을 처리한다.

예를 들어 4코어 서버에서는 reactor-http-nio-1 ~ reactor-http-nio-4, 총 4개의 스레드가 모든 동시 요청을 나눠 처리하는 구조이다.

이 중 하나의 스레드가 JDBC 호출로 100ms만 블로킹되어도, 그 스레드에 할당된 모든 커넥션의 요청처리가 100ms동안 완전히 멈추게 되는것이다. 4개중 한개의 스레드가 막히면 전체 처리량의 25%가 줄어드는 셈이된다.

4. 비동기 + 논블로킹 (Asynchronous + Non-Blocking)

작업 완료는 피호출자가 알려주고 (비동기), 호출자의 스레드도 즉시 해방된다. (논블로킹)
가장 효율적인 방식이다. 호출자는 요청만 보내고 즉시 다른일을 할 수 있고, 피호출자의 작업이 완료되면 콜백이나 이벤트를 통해
확인하게 된다.

예시

// 1. CompletableFuture — thenAccept()는 콜백을 등록하고 즉시 반환된다
CompletableFuture
    .supplyAsync(() -> callExternalApi())    // 별도 스레드에서 실행 (논블로킹)
    .thenApply(response -> parse(response))  // 완료 시 자동으로 체이닝
    .thenAccept(result -> save(result));      // 피호출자가 완료를 알려줌 (비동기)
System.out.println("요청 전송 완료 — 결과를 기다리지 않고 다음 로직 실행");

// 2. Spring WebFlux — 완전한 비동기 + 논블로킹 (WebFlux + R2DBC)
@GetMapping("/users/{id}")
public Mono<User> getUser(@PathVariable Long id) {
    return userRepository.findById(id);  // R2DBC — 논블로킹 DB 호출
    // 반환 즉시 스레드 해방, 결과가 준비되면 Reactor가 응답을 push
}

// 3. Java 11+ HttpClient — 비동기 + 논블로킹 HTTP 호출
HttpClient client = HttpClient.newHttpClient();
HttpRequest request = HttpRequest.newBuilder()
    .uri(URI.create("https://api.example.com/data"))
    .build();

client
    .sendAsync(request, HttpResponse.BodyHandlers.ofString())
    .thenAccept(response -> {
        System.out.println("Status: " + response.statusCode());
    });
// sendAsync()는 즉시 반환되고, 응답이 오면 thenAccept()로 콜백이 실행된다

특징

적은 수의 스레드로 많은 요청을 처리할 수 있다. 스레드가 I/O 대기로 낭비되지 않는다.
코드 복잡도가 올라간다. 콜백 체이닝, 에러 전파, 디버깅이 동기식 코드보다 어려워진다.

마무리 정리

4가지 조합 간략 요약

	완료 확인	제어권 반환	예시	스레드 효율
동기 + 블로킹	호출자가 직접 확인	완료까지 미반환	JDBC, RestTemplate, future.get()	낮음 (스레드 점유)
동기 + 논블로킹	호출자가 직접 확인 (polling)	즉시 반환	future.isDone() While 루프	보통 (busy-wait)
비동기 + 블로킹	피호출자가 알려줌	중간에 블로킹 발생	WebFlux 요청 내 JDBC (블로킹)	낮음 (블로킹 병목)
비동기 + 논블로킹	피호출자가 알려줌	즉시 반환	thenAccept(), WebFlux + R2DBC	높음

헷갈리는 내용 정리

한줄 정리

동기/비동기는 - 완료를 누가 알려주는가!
블로킹/논블로킹은 - 호출자 스레드를 멈추는가!

CompletableFuture를 사용하면 항상 비동기 + 논블로킹인가?

-> No! CompletableFuture를 어떻게 사용하냐에 따라 동기/비동기 블로킹/논블로킹이 다르다.

future.get(): 결과 내놔! Polling 이므로 동기이다. get()으로 응답 내놔 하는동안 호출자 스레드가 블로킹된다.
while(future.isDone().not()): 결과 확인! Polling 이므로 동기이다. 단, while 내에서 다른 작업을 할 수 있는 논블로킹이다.
future.thenAccept(callback): 결과를 확인하지 않고 thenAccept로 결과를 콜백받으므로 비동기이다. 그동안 다른 작업을 할 수 있으므로 논블로킹이다.

ANSI Isolation Level vs MySQL Isolation Level

구름뭉치 — Sun, 15 Mar 2026 17:50:31 +0900

들어가며

트랜잭션 격리 수준(Transaction Isolation Level)은 동시에 실행되는 트랜잭션 사이에서 데이터의 일관성을 어디까지 보장할지를 결정하는 설정이다. 격리 수준이 높을수록 일관성은 강해지지만 동시성은 떨어지고, 낮을수록 동시성은 좋지만 이상현상(anomaly)에 노출될 수 있다.

대부분의 개발자가 REPEATABLE READ, READ COMMITTED 같은 격리 수준 이름을 알고 있다.

그런데 ANSI SQL-92 표준이 정의한 REPEATABLE READ와 MySQL InnoDB가 실제로 제공하는 REPEATABLE READ는 같은 수준의 격리를 보장할까?

결론부터 말하면, 같은 이름이지만 보장하는 범위가 다르다.

이 글에서는 ANSI SQL-92 (이하 ANSI SQL) 표준의 격리 수준 정의를 먼저 살펴보고, A Critique of ANSI SQL Isolation Levels 비판 논문을 통해 그 한계를 분석한 뒤, MySQL InnoDB의 실제 구현과 비교한다.

1. ANSI SQL의 격리 수준

1.1 세 가지 이상현상

ANSI SQL-92 표준은 트랜잭션 격리 수준을 "어떤 이상현상을 허용하느냐"로 정의한다. 표준이 정의한 세 가지 이상현상은 다음과 같다.

P1: Dirty Read (더티 읽기)

다른 트랜잭션이 수정했지만 아직 커밋하지 않은 데이터를 읽는 현상이다. 해당 트랜잭션이 롤백되면, 읽은 데이터는 DB에 존재한 적 없는 값이 된다.

(*참고) 용어설명, w: write, r: read, a: abort, c: commit, p: 조건

w1[x] ... r2[x] ... (a1 and c2 in either order)

T1이 x를 수정 → T2가 x를 읽음 → T1이 ROLLBACK
→ T2는 존재한 적 없는 데이터를 기반으로 동작하게 됨

예를 들어, T1이 계좌 잔고를 1000원에서 500원으로 수정한 뒤 아직 커밋하지 않은 상태에서 T2가 잔고를 읽으면 500원이 보인다. 이후 T1이 롤백되면 실제 잔고는 1000원인데, T2는 500원을 기준으로 출금 처리를 진행하게 된다.

P2: Non-Repeatable Read (반복 불가능한 읽기)

한 트랜잭션 안에서 같은 데이터를 두 번 읽었을 때, 그 사이에 다른 트랜잭션이 해당 데이터를 수정·커밋하여 결과가 달라지는 현상이다.

r1[x] ... w2[x] ... c2 ... r1[x] ... c1

T1이 x를 읽음 → T2가 x를 수정하고 COMMIT → T1이 x를 다시 읽음
→ 같은 트랜잭션 안에서 같은 데이터의 값이 다름

잔고가 1000원 이상이면 1000원을 출금하는 로직을 생각해보자. T1이 잔고를 읽어 1000원을 확인하고 검증을 통과한 뒤, 실제 출금 전에 다시 잔고를 읽었더니 다른 트랜잭션이 이미 500원만 남겨놓은 상태다. 트랜잭션 내에서 읽은 데이터를 신뢰할 수 없게 된다.

P3: Phantom Read (팬텀 읽기)

P2가 "특정 row의 값이 바뀌는" 문제라면, P3는 "조건에 맞는 row의 집합 자체가 바뀌는" 문제다.

r1[P] ... w2[y in P] ... c2 ... r1[P] ... c1

T1이 조건 P로 조회 → T2가 P를 만족하는 데이터를 INSERT/UPDATE/DELETE하고 COMMIT → T1이 같은 조건으로 다시 조회
→ 결과 목록이 달라짐

SELECT * FROM employee WHERE dept = 'engineering'으로 3명을 조회한 뒤, 다른 트랜잭션이 engineering 부서에 신규 직원을 추가하고 커밋하면, 같은 쿼리를 다시 실행했을 때 4명이 조회된다.

1.2 네 가지 격리 수준

ANSI SQL은 이 세 가지 이상현상의 허용 여부로 네 가지 격리 수준을 정의한다.

격리 수준	P1 (Dirty Read)	P2 (Non-Repeatable Read)	P3 (Phantom)
READ UNCOMMITTED	허용	허용	허용
READ COMMITTED	차단	허용	허용
REPEATABLE READ	차단	차단	허용
SERIALIZABLE	차단	차단	차단

위에서 아래로 갈수록 더 많은 이상현상을 차단하며, 그만큼 격리가 강해진다.

이 테이블만 보면 깔끔한 체계처럼 보인다. 하지만 1995년, 이 정의에 근본적인 문제가 있다는 비판이 제기되었다.

2. Berenson 논문의 비판: ANSI 표준의 한계

1995년 Hal Berenson, Phil Bernstein, Jim Gray 등은 "A Critique of ANSI SQL Isolation Levels"이라는 논문을 발표했다.

- 참고

Jim Gray는 트랜잭션 이론의 창시자 중 한 명이고, Phil Bernstein은 동시성 제어 교과서의 저자다. DB 이론의 거장들이 표준을 정면으로 비판한 것이다.

논문이 지적한 핵심 문제는 세 가지다.

2.1 이상현상 정의의 모호성: Strict (엄격) vs Broad (포괄) 해석

ANSI 원문의 P1(Dirty Read) 설명은 "T1이 수정한 데이터를 T2가 읽은 뒤, T1이 Abort되어 ROLLBACK하면 문제가 된다"라는 뉘앙스로 작성되어 있다. 이를 문자 그대로 해석하면 다음과 같다.

Anomaly 1 (Strict)

A1 (strict): w1[x] ... r2[x] ... a1
→ T1이 반드시 abort해야 Dirty Read로 인정

그런데 다음 예제 히스토리를 보자.

예제 History 1

H1: r1[x=50] w1[x=10] r2[x=10] r2[y=50] c2 r1[y=50] w1[y=90] c1

t1 -> x=50을 읽음, x=10을 씀
t2 -> x=10을 읽음, y=50을 읽음 (t2 커밋)
t1 -> y=50을 읽음, y=90을 씀 (t1 커밋)

즉, T1이 x에서 y로 40을 이체하는 중에, T2가 x(=10)와 y(=50)를 읽어 합계를 계산한다.

T2가 본 합계는 60인데, 실제 총액은 100이어야 한다. 이러한 합계 결과는 분명히 비직렬적(non-serializable)인 히스토리다.

즉 트랜잭션을 하나씩 순서대로 실행했다면 절대 나올 수 없는 결과가 나온 실행 이력이다.

하지만 위 strict 해석(Anomaly 1)에서는 이 히스토리 1번 예제가 Dirty Read에 해당하지 않는다.

T1이 abort하지 않고 commit했기 때문이다.

- 하지만 분명히 커밋되지 않은 트랜잭션의 데이터를 읽어서 생긴 문제는 맞다.

Berenson은 이 문제를 해결하기 위해 아래와 같은 broad (포괄적) 해석이 ANSI의 진짜 의도라고 말한다.

P1 (broad): w1[x] ... r2[x] ... (c1 or a1)
→ T1이 commit하든 abort하든, 커밋 전에 읽은 것 자체가 문제

broad 해석에서 예제 1 히스토리는 P1 위반에 해당한다. P2, P3에 대해서도 같은 구조의 문제가 존재하며, strict 해석으로는 잡히지 않는 비직렬적인 히스토리들이 있다.

2.2 누락된 이상현상

ANSI 표준은 세 가지 이상현상만 정의했지만, 실제로는 그 외에도 발생할 수 있는 이상현상들이 존재한다.

P0: Dirty Write

두 트랜잭션이 모두 커밋 전에 같은 데이터를 덮어쓰는 현상이다.

P0: w1[x] ... w2[x] ... (c1 or a1)

T1이 x를 수정한 뒤 아직 커밋 전인데, T2가 같은 x를 다시 수정한다. 이 상태에서 T1이 롤백하면, DB는 T1의 before-image로 복원하는데 그 과정에서 T2의 수정까지 함께 사라진다. 이후 T2까지 롤백하려고 하면 복구 자체가 불가능해진다.

ANSI SQL에서는 P0을 아예 정의하지 않았다. READ UNCOMMITTED조차 Dirty Write를 금지해야 롤백이 가능한데, 표준에는 이 제약이 빠져 있다.

Berenson 논문은 모든 격리 수준에서 P0을 금지해야 한다는 것이고 실제로 현대 데이터베이스에서는 P0가 모두 지켜지고 있다.

ANSI 표준 문서에 누락된게 문제인것이다.

이걸 방지하는건 간단한데, x 대상에 대한 UPDATE, INSERT, DELETE 등 수정 시 x 대상에 배타락인 Long duration Write lock을 거는 방법으로 방지하면 된다.

Read Skew [A5A]

한 트랜잭션이 서로 관련된 두 데이터를 각각 다른 시점에 읽어서, 일관성이 깨진 상태를 보게 되는 현상이다.

r1[x] ... w2[x] ... w2[y] ... c2 ... r1[y]
→ T1은 x의 구버전과 y의 신버전을 보게 됨

x=50, y=50(합계 100 유지 제약) 상태에서, T2가 x=25, y=75로 수정하고 커밋한다.

T1이 x를 먼저 읽어 50을 얻고, t2 트랜잭션 이후 나중에 y를 읽어 75를 얻으면, T1이 보는 합계는 125가 된다.

한 트랜잭션 안에서 서로 다른 시점의 데이터를 보게 되는 것이다.

Write Skew [A5B]

두 트랜잭션이 겹치는 데이터를 읽고, 각각 서로 다른 데이터를 수정하여 전체적으로 제약조건이 깨지는 현상이다.

r1[x] ... r2[y] ... w1[y] ... w2[x] ... (c1 and c2)

병원 당직 시나리오로 이해해보자.

- 제약조건: "최소 1명은 당직"이어야하며, 현재 Andy와 Brad 모두 당직이다.

T1(Andy)은 "Brad가 당직이니 나는 빠져도 된다"고 판단해 자기 당직을 해제
T2(Brad)는 "Andy가 당직이니 나는 빠져도 된다"고 판단해 자기 당직을 해제

각 트랜잭션은 자신이 읽은 시점에는 제약조건을 만족했지만, 결과적으로 당직자가 0명이 된다. 핵심은 두 트랜잭션이 서로 다른 row를 수정했다는 점이다. write-write 충돌이 없으니 일반적인 충돌 감지로는 잡히지 않는다.

2.3 ANSI 한계: MVCC 기반 구현을 다루지 못함

ANSI 표준은 기본적으로 Lock 기반 동시성 제어를 전제로 설계되었다. 그런데 현대 데이터베이스 대부분은 MVCC(Multi-Version Concurrency Control)를 사용한다.

Berenson 논문은 MVCC 기반 구현에서 등장하는 Snapshot Isolation이라는 격리 수준을 새로 정의했다.

Snapshot Isolation는 ANSI가 정의한 세 가지 이상현상(P1, P2, P3)과 Read Skew 모두 차단하지만, Write Skew(A5B)를 허용하므로 Serializable이 아니다.

즉, ANSI 테이블에 깔끔하게 들어맞지 않는 이상현상과 격리 수준인 것이다.

다만, MySQL(MVCC)에서 Snapshot Read와 Locking Read를 혼용하여 사용하면 Read Skew는 발생한다.

2.4 격리 수준 간의 강약 관계

Berenson 논문은 Snapshot Isolation을 포함한 격리 수준 간의 강약 관계를 다음과 같은 순서로 정리했다.

           Serializable
          /            \
  Repeatable Read   Snapshot Isolation
          \            /
          Read Committed
                 |
         Read Uncommitted

여기서 주목할 점은 ANSI Repeatable Read와 Snapshot Isolation이 비교 불가능한 관계라는 것이다.

Snapshot Isolation은 Write Skew를 허용하지만 Phantom을 차단하고,
ANSI Repeatable Read는 Phantom을 허용하지만 Write Skew를 차단한다.

3. Locking 기반 ANSI 구현 vs MVCC 기반 MySQL 구현

ANSI 표준과 MySQL의 차이를 이해하려면, 격리를 구현하는 메커니즘의 차이를 이해해야 한다.

3.1 Locking 기반 ANSI 구현

Locking 기반 REPEATABLE READ의 특성은 다음과 같다.

개별 데이터 항목에 대한 Read Lock: Long duration (트랜잭션 끝까지 유지)
Predicate Lock (범위 조건): Short duration (즉시 해제)
Write Lock: Long duration (트랜잭션 끝까지 유지)

Read Lock이 트랜잭션 끝까지 유지되므로, 읽은 row를 다른 트랜잭션이 수정하려면 반드시 현재 트랜잭션이 끝나기를 기다려야 한다.

이 때문에 Write Skew 시나리오에서는 데드락이 발생해 하나가 롤백되고, 결과적으로 Write Skew가 방지된다.

반면 Predicate Lock은 즉시 해제되므로, 범위 조건에 새 row가 삽입되는 Phantom은 방지하지 못한다.

ANSI Locking 기반 Write Skew 방지 흐름

[공유자원 읽기]

T1: SELECT ... WHERE oncall=TRUE FOR SHARE

→ Andy, Brad 두 row에 S 락 획득
T2: SELECT ... WHERE oncall=TRUE FOR SHARE

→ Andy, Brad 두 row에 S 락 획득 (S + S는 호환되므로 성공!)

[공유자원 업데이트]

T1: UPDATE SET oncall=FALSE WHERE name='Andy'

→ Andy row에 X 락 필요 → T2가 S 락 보유 중 → 대기...
T2: UPDATE SET oncall=FALSE WHERE name='Brad'

→ Brad row에 X 락 필요 → T1이 S 락 보유 중 → 대기...

[데드락]

→ DEADLOCK 발생! → DB가 하나를 강제 rollback

3.2 MySQL InnoDB의 MVCC + Locking 하이브리드

InnoDB는 MVCC를 핵심 동시성 제어 메커니즘으로 사용한다. 이 구현을 이해하려면 InnoDB의 두 가지 읽기 방식을 구분해야 한다.

Consistent Nonlocking Read (Snapshot Read)

일반 SELECT 문이 이 방식으로 동작한다. 락을 걸지 않고, MVCC를 통해 특정 시점의 스냅샷을 읽는다.

REPEATABLE READ에서는 트랜잭션 내 첫 번째 SELECT 시점의 스냅샷이 고정되어, 이후 몇 번을 읽어도 같은 결과를 반환한다.
READ COMMITTED에서는 매 SELECT마다 새로운 스냅샷을 생성한다.

Current Read (Locking Read)

SELECT ... FOR UPDATE, SELECT ... FOR SHARE, 그리고 UPDATE, DELETE 문이 이 방식으로 동작한다.

스냅샷이 아닌 최신 커밋 데이터를 읽으며, 읽은 row에 락을 건다.

4. MySQL InnoDB 격리 수준별 동작

4.1 READ UNCOMMITTED

InnoDB는 내부적으로 undo log 기반으로 항상 다중 버전을 유지하고 있다. 이 다중 버전을 격리 수준에 따라 스냅샷 시점을 기준으로 "이 버전이 내 트랜잭션에게 보여야 하는가?"를 판단하게 되는데, Snapshot Read에서 가시성 판단 없이 가장 최신 버전을 커밋 여부와 관계없이 읽는다. 사실상 MVCC 스냅샷을 쓰지 않는 유일한 레벨이다.

ANSI 정의와 거의 동일하다.

4.2 READ COMMITTED

Snapshot Read에서 매 SELECT마다 새로운 스냅샷을 생성한다. 따라서 같은 트랜잭션 안에서도 다른 트랜잭션의 커밋이 반영된 결과를 볼 수 있다.

Locking Read에서는 record lock만 사용하고, gap lock이 비활성화된다. 따라서, gap lock이 없으므로 다른 세션이 갭에 새 row를 삽입할 수 있어 phantom이 발생할 수 있다.

또한 UPDATE나 DELETE 시, WHERE 조건에 맞지 않는 row에 대한 lock은 조건 평가 후 즉시 해제된다.

4.3 REPEATABLE READ (MySQL InnoDB 기본값)

MySQL의 기본 격리 수준이며, ANSI 정의와 가장 큰 차이가 나는 레벨이다.

Snapshot Read 측면

트랜잭션 내 첫 번째 SELECT 시점의 스냅샷이 고정된다.
이후 같은 트랜잭션 안에서는 몇 번을 SELECT해도 동일한 결과를 반환한다. 이 메커니즘만으로 P2(Non-Repeatable Read)와 P3(Phantom) 모두 원천 차단된다. 스냅샷이 고정되어 있으므로 다른 트랜잭션의 INSERT, UPDATE, DELETE가 보이지 않기 때문이다.

Locking Read 측면

SELECT ... FOR UPDATE, UPDATE, DELETE 등은 최신 커밋 데이터를 읽으며 next-key lock(record lock + gap lock)을 사용한다.
유니크 인덱스로 단일 row를 검색하는 경우에는 record lock만 걸지만, 범위 조건이나 비유니크 인덱스를 사용하는 경우에는 gap lock을 포함한 next-key lock으로 해당 구간의 INSERT를 차단한다.

핵심: ANSI REPEATABLE READ는 Phantom(P3)을 허용하지만, MySQL REPEATABLE READ는 Snapshot Read의 스냅샷 고정과 Locking Read의 gap lock 두 가지 메커니즘으로 Phantom을 방지한다.

단, MySQL 공식 문서는 Snapshot Read(일반 SELECT)와 Locking Read(SELECT ... FOR UPDATE 등)를 하나의 REPEATABLE READ 트랜잭션에서 혼용하지 말라고 권고한다.

왜나하면, Snapshot Read는 스냅샷 시점의 데이터를, Locking Read는 현재 시점의 커밋된 최신 데이터를 보기 때문에, 한 트랜잭션 안에서 두 개의 서로 다른 현실을 보게 되는 상황이 발생할 수 있다. 즉, Phantom Read 문제가 발생하는 것이다.

START TRANSACTION;

-- Snapshot Read: 스냅샷 시점 기준
SELECT COUNT(*) FROM employee WHERE dept = 'engineering';  -- 결과: 3

-- 이 사이에 다른 트랜잭션이 INSERT & COMMIT

-- Locking Read: 최신 커밋 데이터 기준
SELECT COUNT(*) FROM employee WHERE dept = 'engineering' FOR UPDATE;  -- 결과: 4

참고: Next-Key Lock의 범위는 인덱스 구조에 의해 결정된다

REPEATABLE READ에서 Locking Read가 Phantom을 방지하는 원리를 이해하려면, next-key lock이 어디에 걸리는지를 정확히 알아야 한다.

next-key lock은 쿼리 결과로 반환된 row에 거는 것이 아니라, 쿼리가 스캔한 인덱스 레코드와 그 주변 gap에 건다.

이 때문에 WHERE 절에 사용된 컬럼의 인덱스 존재 여부가 lock 범위를 결정적으로 좌우한다.

인덱스가 있는 경우: 필요한 범위만 잠금

age 컬럼에 secondary index가 있는 상태에서 다음 쿼리를 실행한다고 가정하자.

SELECT * FROM employee WHERE age = 20 FOR UPDATE;

InnoDB는 age 인덱스를 스캔하면서 age=20에 해당하는 인덱스 레코드들과 그 주변 gap에 next-key lock을 건다.

예를 들어 age 인덱스에 ..., 18, 20, 20, 20, 25, ... 값이 있다면, (18, 20] 구간의 next-key lock과 (20, 25) 구간의 gap lock이 설정된다.

이 상태에서 다른 트랜잭션이 id=2330인 row의 age를 20으로 UPDATE하려고 하면, age 인덱스의 20 구간에 새 엔트리를 삽입해야 하는데 해당 구간이 잠겨 있으므로 블록된다. 결과적으로 Phantom이 방지된다.

인덱스가 없는 경우: 사실상 테이블 전체 잠금

만약 age 컬럼에 인덱스가 없으면 상황이 달라진다. InnoDB는 age=20인 row를 찾기 위해 클러스터드 인덱스(= primary key 인덱스)를 풀스캔해야 한다. MySQL에서 모든 테이블은 클러스터드 인덱스 구조이므로, 인덱스가 없는 컬럼으로 검색하면 PK 인덱스 전체를 스캔하게 된다.

이때 InnoDB는 스캔하는 모든 PK 인덱스 레코드에 next-key lock을 건다. age=20이 아닌 row까지 전부 포함해서 잠기므로, 사실상 테이블 전체가 잠기는 것과 다름없다.

실무적 관점

Locking Read의 lock 범위가 인덱스 구조에 의해 결정되기 때문에, gap lock이 관여하는 REPEATABLE READ 환경에서는
적절한 인덱스 설계가 동시성에 직결된다. 인덱스가 없으면 불필요하게 넓은 범위를 잠그게 되어, 동시성이 크게 저하되고 데드락 발생 확률도 높아진다.

참고: 어떻게 Read Skew가 발생하지 않는지 궁금하면 봐보자.

Read Skew 상황을 다시 봐보자.

- T1이 x를 읽음 → T2가 x, y를 수정하고 커밋 → T1이 y를 읽음

t1의 read lock이 long duration이 적용된다.

T1이 x를 읽으면 S(공유) 락이 트랜잭션 끝까지 유지된다.

T2가 x를 수정하려고 X(배타) 락을 요청하면 T1의 S 락에 블록된다.

T2는 x를 수정할 수 없으니 y도 수정하지 못하게 된다.

T1이 나중에 y를 읽어도 T2의 트랜잭션을 적용되지 못했으므로 구버전 그대로이게 된다.

즉, T1이 공유락을 해제할 때까지 T2는 배타락을 갖지 못하여 수정을 못하게되어 최종적으로 Read Skew가 발생하지 않게 된다.

4.4 SERIALIZABLE

일반 SELECT가 자동으로 "SELECT ... FOR SHARE"로 변환된다.

즉 Snapshot Read 자체가 사라지고, 모든 읽기가 Locking Read가 된다.

읽기에도 공유(Share) 락이 걸리므로 다른 트랜잭션의 쓰기가 블록되어, Write Skew를 포함한 모든 이상현상이 방지된다. 단, 락 경합이 늘어나면서 데드락 발생 확률이 높아진다.

참고: 어떻게 Write Skew가 발생하지 않는지 궁금하면 봐보자.

Write Skew 상황을 다시 봐보자.

- r1[x] ... r2[y] ... w1[y] ... w2[x] ... (c1 and c2)

t1이 읽고 t2가 읽고, t1이 쓰고 t2가 쓰고이다.

이때, t1, t2는 공유락으로 둘다 읽기가 이뤄지지만, t1이 쓰려고할 때 t2의 공유락이 해제되어야 배타락을 잡고 쓸 수 있게 되는데

t2도 t1의 공유락이 해제되면 배타락을 잡고 쓰려고 기다리게 된다.

즉, 둘다 서로 락 해제를 기다리는 데드락이 발생하고 Write Skew가 발생하지 않게 된다.

5. 핵심 비교: ANSI vs MySQL

5.1 격리 수준별 차이점 요약

격리 수준	ANSI 표준 (Locking 기반)	MySQL InnoDB (MVCC + Locking)
READ UNCOMMITTED	P1, P2, P3 허용	거의 동일
READ COMMITTED	P2, P3 허용	유사하나, gap lock 비활성화를 명시적으로 수행
REPEATABLE READ	P3(Phantom) 허용, Write Skew 차단	Phantom 차단, Write Skew 허용
SERIALIZABLE	완전 직렬화	모든 SELECT를 FOR SHARE로 변환하여 구현

5.2 REPEATABLE READ: 가장 큰 차이

ANSI(Locking)과 MySQL(MVCC)의 REPEATABLE READ가 다른 이유는 동시성 제어 메커니즘의 차이에서 비롯된다.

비교 항목	ANSI (Locking) Repeatable Read	MySQL (MVCC) Repeatable Read
읽기 시 락	읽은 row에 Long duration Shared lock	Snapshot Read는 무 락(no lock)
Phantom (P3)	허용 (predicate lock이 short duration)	차단 (스냅샷 고정 + gap lock)
Write Skew	차단 (long Shared lock → 데드락으로 방지)	허용 (Snapshot Read가 무 락이므로)
Read Skew	차단 (long Shared lock이 수정을 블록)	Snapshot Read/Locking Read 단독 사용 시 차단 (단, Snapshot & Locking Read 혼용 시 발생 가능)

ANSI (Locking) Repeatable Read (Write Skew 차단)

long duration read lock이 읽은 데이터를 보호하는 원리
당직 시나리오에서 T1이 Brad의 당직 상태를 읽으면 그 row에 S 락이 트랜잭션 끝까지 유지된다.
T2가 Brad의 row를 수정하려면 T1의 S 락 해제를 기다려야 하고, T1도 T2의 S 락을 기다리는 상황이 된다.
결국 데드락 상황이 발생해 하나가 롤백된다.

MySQL(MVCC) Repeatable Read (Write Skew 허용)

Snapshot Read가 아무 락도 걸지 않아서 생기는 문제
T1이 Brad의 당직 상태를 읽어도 Brad의 row에 아무 락이 없다.
T2는 자유롭게 Brad의 당직을 해제할 수 있고, T1도 마찬가지로 Andy의 당직을 해제할 수 있다.
결국 Write Skew가 발생한다.

5.3 MySQL REPEATABLE READ 정리

ANSI Repeatable Read 보다 강한 점: Snapshot Read의 스냅샷 고정과 Locking Read의 gap lock으로 Phantom을 방지.
ANSI Repeatable Read 보다 약한 점: Snapshot Read에서 락을 걸지 않으므로 Write Skew가 발생할 수 있음.
Snapshot Isolation 보다 약한 점: Snapshot Read와 Locking Read의 혼용으로 read skew, lost update가 발생할 수 있다.

MySQL의 REPEATABLE READ는 ANSI Repeatable Read도 아니고 순수한 Snapshot Isolation도 아닌, InnoDB 고유의 격리 수준이라고 보는 것이 정확하다.

6. 실무에서의 격리 수준 선택

MySQL 기본값(REPEATABLE READ)을 유지하는 경우

대부분의 일반적인 CRUD 작업에 적합하다. Snapshot Read만 사용하면 일관된 읽기가 보장되며, 단일 row 업데이트 위주의 트랜잭션에서는 충분하다. gap lock에 의한 Phantom 방지도 기본으로 제공된다.

READ COMMITTED로 내리는 경우

gap lock으로 인한 데드락이 빈번한 고처리량 환경에 적합하다. 범위 기반 UPDATE/DELETE가 많은 배치 작업, 대량 데이터 처리에서 gap lock이 동시성을 크게 저하시킬 수 있다.

READ COMMITTED에서는 gap lock이 비활성화되므로 동시성이 개선되지만, phantom이 발생할 수 있으므로 애플리케이션 레벨에서 이를 허용할 수 있는지 검토해야 한다.

SERIALIZABLE로 올리거나 별도 조치가 필요한 경우

Write Skew가 비즈니스 로직상 치명적인 경우에 해당한다. 다만 SERIALIZABLE 전체 적용보다는, 해당 트랜잭션의 핵심 읽기만 [SELECT ... FOR UPDATE]로 변경하는 것이 일반적인 실무 패턴이다.

성능 트레이드오프 요약

동시성	락 오버헤드	오버헤드	데드락	데이터 정합성
READ UNCOMMITTED	낮음	최소	낮음	최저
READ COMMITTED	낮음	낮음 (gap lock 없음)	낮음	중간
REPEATABLE READ	중간	중간 (gap lock 존재)	중간~높음	높음 (Write Skew 제외)
SERIALIZABLE	높음	최대 (모든 SELECT에 S lock)	최고	최고

마무리

ANSI SQL 표준은 세 가지 이상현상(더티 읽기, 반복 불가능한 읽기, 팬텀 읽기)으로 격리 수준을 정의했으나, 현상 정의 자체의 모호성, 누락된 이상현상(Dirty Write[P0], Read Skew[A5A], Write Skew[A5B]), 그리고 MVCC 기반 구현을 다루지 못하는 한계가 있었다.

MySQL InnoDB는 ANSI 표준의 네 가지 격리 수준 이름을 그대로 사용하지만, MVCC + Locking 하이브리드 방식으로 구현했기 때문에 실제 보장 범위가 다르다. 특히 REPEATABLE READ에서 ANSI 표준은 Phantom을 허용하고 Write Skew를 차단하는 반면, MySQL은 Phantom을 차단하고 Write Skew를 허용한다.

Isonlation Level의 이름만 보고 동작을 가정하지 말고, 사용하는 DB의 실제 구현을 확인해야 한다.

참고 자료

ANSI X3.135-1992, American National Standard for Information Systems — Database Language SQL, November 1992
Berenson, H., Bernstein, P., Gray, J., Melton, J., O'Neil, E., & O'Neil, P. (1995). "A Critique of ANSI SQL Isolation Levels." Proc. ACM SIGMOD 95, pp. 1-10
MySQL 8.4 Reference Manual — Transaction Isolation Levels
MySQL 8.4 Reference Manual — InnoDB Locking
MySQL 8.4 Reference Manual — Consistent Nonlocking Reads
Jepsen. MySQL 8.0.34 Analysis
Vlad Mihalcea. A beginner's guide to the Write Skew anomaly, and how it differs between 2PL and MVCC
Adrian Colyer. A Critique of ANSI SQL Isolation Levels — the morning paper

MSA에서 ACID의 의미

구름뭉치 — Tue, 10 Mar 2026 21:17:20 +0900

ACID

ACID의 의미부터 확인하자.

ACID 자체의 의미

RDBMS 단일 트랜잭션을 기준으로

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

위 4가지 속성이 하나의 DB 커넥션 안에서 트랜잭션을 통해 보장되는 것을 말한다.

사실 데이터베이스 관점에서 트랜잭션을 정의하는 속성이므로 ACID 트랜잭션이라 말하는게 맞다.

MSA에서 ACID가 깨지는 이유

MSA의 본질은 서비스별로 독립된 데이터를 가지는 것이다. 이로인해 단일 DB 트랜잭션으로 여러 서비스의 데이터 정합성을 보장하는 것이 원칙적으로 불가능해진다.
ACID의 4가지 속성 모두가 서비스의 경계를 넘는 순간 보장할 수 없게 된다.

ACID 각 속성이 어떻게 깨지는가

Atomicity
모놀리식에서는 하나의 트랜잭션안에서 여러 테이블을 수정해도 DB가 All or Noting을 보장한다.
하지만 MSA에서 주문 생성 -> 재고 차감 -> 결제 처리 흐름이 각각 다른 서비스, 다른 DB에서 이뤄진다면 어떻게 될까?
주문은 생성 됐는데 결제 서비스가 실패했을 때 주문 서비스 DB에서 이미 커밋된 데이터는 어떻게 될까?
-> DB가 해주던 롤백을 이제 애플리케이션이 직접 해줘야 한다.

Consistency
단일 DB에서는 FK, Unique Constraint, Check Constraint 같은 제약 조건을 통해 데이터 정합성을 DB 레벨에서 강제해준다.
하지만 MSA에서 주문 서비스의 주문 상태와 결제 서비스의 결제 상태가 항상 일치해야한다는 제약 조건은 어디서 정의해아할까?
-> DB 제약 조건으로 표현할 수 없는, 서비스 간 비지니스 규칙이 된다.

Isolation
단일 DB에서는 격리 수준인 READ_UNCOMMITED, READ_COMMITED, REPEATABLE_READ 등을 통해 동시성 문제를 관리했다.
하지만 MSA에서 주문 서비스가 아직 처리중인 데이터를 결제 서비스가 읽어 간다면 어떻게 될까?
-> 서비스 간 이런 격리 매커니즘은 존재하지 않는다.

Durability
각 서비스의 DB에서는 Durability를 여전히 보장해준다.
하지만 MSA에서 각 서비스의 DB에는 커밋이 완료되어 영속화 되었지만, 주문 완료 등 이벤트가 발송되지 않을 수 있다.

주문 완료 이벤트를 수신하여 배송 서비스 등이 이뤄져야하는데 발송이 이뤄지지 않는다면 하나의 동작 관점에서는 불완전한 영속성인 것이다. (데이터는 저장되었지만 이벤트는 발송되지 않았음)
-> 일부 영속화는 되지만 전체가 된건 아니다.

ACID의 재해석: 각 속성별로 MSA는 어떻게 풀어내는가

Atomicity -> Saga 패턴

단일 DB에서는 DB 엔진이 이를 보장해줬다. MSA에서는 이를 애플리케이션 레벨로 올려야한다.

SAGA는 하나의 분산 트랜잭션을 각 서비스의 트랜잭션 체인으로 분해한다. 각 서비스의 트랜잭션은 여전히 ACID를 준수하며 동작하고, 체인 중간에 실패하면 이미 완료된 트랜잭션들을 보상 트랜잭션으로 되돌린다.

[주문 흐름]

[정상 흐름] 주문 생성(주문 서비스) → 재고 차감(재고 서비스) → 결제 처리(결제 서비스) 
[결제 실패 시 보상 흐름] 결제 실패 → 재고 복원(보상) → 주문 취소(보상)

Saga에서 중요한 것은 DB 롤백과는 본질적으로 다르다는 것이다. DB 롤백은 아무일도 없었다는 것처럼 트랜잭션이 실패하면 데이터를 되돌리지만, 보상 트랜잭션은 되돌리는 행위 자체가 새로운 트랜잭션이 된다.
위 보상흐름을 보면, 주문 취소라는 이벤트가 기록으로 남으며, 재고 복원도 비지니스 로직으로 기록에 남게 된다. 따라서 의미론적 되돌림(Undo)이며 물리적 롤백은 아니다.

SAGA 구현 방식

안무 사가 (Choreography Saga)
오케스트레이션 사가 (Orchestration Saga)

안무 사가 (Choreography Saga)
안무 사가는 각 서비스가 이벤트를 발행하고 다음 서비스가 이 이벤트를 구독해서 자율적으로 반응하는 구조이다. 서비스 간 직접적인 의존이 없으므로 느슨한 결합을 유지할 수 있다는 장점이 있다.
단, 서비스가 많아지면 이벤트 흐름 추적이 어렵고 전체 플로우를 한눈에 파악하기 어렵다는 단점이 있다.

오케스트레이션 사가 (Orchestration Saga)
중앙의 Saga Orchestrator (지휘자)가 전체 흐름을 제어하는 구조이다.
흐름이 명시적이므로 디버깅과 모니터링이 용이하다는 장점이 있다.
단, Orchestrator가 단일 실패 지점(SPOF)가 될 수 있고 서비스 간 결합도가 상대적으로 높아지는 단점이 있다.

Orchestration Saga는 Temporal과 같은 워크플로우 엔진을 활용하여 구현할 수 있으며, 클러스터 구축을 통해 SPOF 와 같은 문제를 상당 부분 해소할 수 있다.

Consistency → Eventual Consistency

기존 Consistency는 트랜잭션이 끝나는 순간 모든 데이터가 일관된 상태를 의미했다. MSA에서는 이를 시간축으로 완화한다.

Eventual Consistency는 "지금 이 순간 모든 서비스의 데이터가 일치하지 않을 수 있지만, 충분한 시간이 지나면 결국 최종적으로 일치하게 된다"는 정의다.

즉, MSA 환경에서는 비지니스 관점에서 허용 가능한 일시적 불일치를 명시적으로 설계하는 것이다. 상품이 매진 되어도 즉시 미노출되지 않고, 결제가 완료된 직후에 주문 상태가 결제 대기로 일시적으로 보이는 등이다.

이런 일시적인 현상은 대부분 비지니스적으로 문제가 되지 않으며 이러한 판단이 설계의 일부가 된다.

메시지 브로커(Kafka, RabbitMQ) 등은 이 모델을 뒷받침하는 핵심 인프라이다.

Isolation → 명시적 동시성 제어

이제 단일 DB의 격리수준이 없는 상황이며, 서비스 간 동시성 문제는 애플리케이션이 직접 전략을 결정하고 적용해야 한다.

전략 1. Semantic Lock (의미론적 락)
Saga가 진행 중인 리소스에 상태 플래그를 둬서("PENDING", "PROCESSING" 등) 다른 트랜잭션이 해당 리소스를 마음대로 수정하지 못하게 막는 방법이다.
마치 DB 레벨의 row lock을 비즈니스 상태값으로 표현한것과 같다.

전략 2. Commutative Update (교환적 업데이트)
연산 순서가 바뀌어도 결과가 같도록 설계하는 방법이다.
예를 들어 재고를 9로 설정하는 요청(10에서)이 아니라, 재고를 1 줄이는 요청(델타값)으로 표현하는 것이다.
이를 통해 메시지 순서가 바뀌어도 (동시성 이슈) 최종 결과에 영향을 주지 않도록 한다.

전략 3. Version-based Optimistic Control (버전 기반 낙관적 제어)
각 리소스에 버전 번호를 부여하고, 업데이트 시 자신이 읽었던 버전과 현재 버전이 일치하는지 확인하는 방법이다. JPA에서 낙관적락에서 사용하는 @Version과 동일한 개념이며, 서비스 간 통신에 적용하는 것이다.

Durability → 변하지 않는 영역 + Outbox Pattern

Durability는 각 서비스의 트랜잭션에서 보장한다. 하지만 위에서 언급한 것 처럼 로컬 DB에는 커밋이 되었지만, 이벤트 발행은 실패한 경우의 문제가 있다.
이러한 문제는 일부 서비스의 데이터는 영속화 되었어도 다른 서비스는 이 데이터(이벤트)를 전혀 모르게 된다.

이를 해결하는 것이 Transactional Outbox Pattern이다. 비지니스의 데이터와 이벤트의 발행을 같은 트랜잭션으로 묶어서 DB에 저장(영속화)한다. 이후 별도의 프로세스 (Message Relay)가 Outbox 테이블에서 이벤트를 읽고 메시지 브로커에 발행하는 구조이다.

이를 통해 데이터 저장과 이벤트 발행의 원자성을 트랜잭션 레벨에서 보장할 수 있게 된다.

[참고] Outbox 테이블을 읽는 방법은 대표적으로 2가지가 존재한다.

Polling Publisher(주기적 폴링)
CDC(Change Data Capture, 대표 도구: Debezium)

- 리디 - Transactional Outbox 패턴으로 메시지 발행 보장

정리

MSA에서 ACID는 사라지는 게 아니라, 보장 주체와 보장 방식이 바뀌는 것이다.

속성	모놀리식	MSA
Atomicity	DB 엔진의 트랜잭션	Saga + 보상 트랜잭션
Consistency	DB 제약조건	Eventual Consistency + 도메인 이벤트
Isolation	DB 격리 수준	Semantic Lock, 낙관적 제어 등 애플리케이션 전략
Durability	DB 엔진	DB 엔진 + Outbox Pattern으로 이벤트 전파 보장

결국 MSA에서의 ACID는 DB가 해주던 것을 애플리케이션 아키텍처가 떠안는 것이고, 그 복잡성을 감수하는 대가로 서비스 독립 배포, 독립 확장, 기술 이기종성 같은 MSA의 이점을 얻는 것이다.

객체지향 설계 원칙 - SOLID

구름뭉치 — Sun, 8 Mar 2026 21:30:14 +0900

개요

객체지향의 핵심은 구현과 역할을 분리하는 것이다.

객체에게 역할을 부여하고, 그 역할에 따라 책임을 할당하며, 객체 간 협력을 통해 시스템이 동작한다.

그렇다면 객체지향에서 좋은 설계와 아키텍처란 무엇일까?

바로 SOLID 원칙이다.

SOLID는 좋은 설계를 얻기 위해 지켜야 할 규범이며, 이 원칙들은 소프트웨어의 유지보수성과 확장성을 높이기 위한 것이다.

유지보수성

무엇이 유지보수성을 높이는 것일까? 가독성?

가독성은 사람마다 다르며, 좋지 못한 코드가 오히려 가독성이 더 좋을 수도 있다. 가독성은 유지보수성의 명확한 기준이 되지 못한다.

유지보수성을 높이는 명확한 기준은 다음 세 가지이다.

영향 범위 — 코드 변경으로 인한 영향 범위가 어떻게 되는가?
의존성 — 소프트웨어의 의존성 관리가 잘 이뤄지고 있는가?
확장성 — 쉽게 확장 가능한가?

SOLID 설계 원칙을 따르면 변경에 의한 영향 범위를 축소할 수 있고, 의존성을 제대로 관리할 수 있고, 쉽게 확장할 수 있다.

S - SRP (Single Responsibility Principle) 단일 책임 원칙

원칙의 목적

변경으로 인한 영향 범위를 최소화하자는 것이다.

그래서 클래스를 변경해야 할 이유는 단 한 가지여야 한다.

책임이란 무엇인가?

책임의 범위는 어디까지일까?

예를 들어 Developer 클래스에 프론트엔드 개발, 백엔드 개발, 프론트 배포, 백엔드 배포가 모두 들어있다면 SRP 위반일까?

FE, BE로 나눠야 하나?
FE, BE, SRE로 나눠야 하나?
외부(비개발자)가 보기엔 하나의 Developer가 아닌가?

책임은 문맥을 포함한다. 따라서 바라보는 이의 입장이나 상황마다 다르게 해석될 수 있다.

액터(Actor) 기준

이를 위한 기준이 있다.

하나의 모듈은 하나의, 단 하나의 액터에 대해서만 책임져야 한다.

액터란 메시지를 전달하는 주체이다. 액터가 클래스(객체)에 메시지를 보내고, 클래스는 그에 응답한다.

액터가 한 명인가? → SRP 원칙을 지킴
액터가 여럿인가? → SRP 원칙을 위배함

따라서 객체지향에서 논하는 객체가 갖는 「역할, 책임, 협력」에서 책임은 곧 액터에 대한 책임이고 협력이다.

이제 클래스를 변경할 이유는 단 하나로, 액터의 요구사항이 변경되었을 때이다.

SRP의 목표

클래스가 변경됐을 때 영향받는 액터는 단 하나여야 한다.
클래스를 변경할 이유는 유일한 액터의 요구사항이 변경될 때 뿐이어야 한다.

O - OCP (Open-Closed Principle) 개방 폐쇄 원칙

원칙의 목적

기존 코드를 수정하지 않으면서도 확장이 가능한 시스템을 만드는 것이다.

코드를 확장하고자 할 때 취할 수 있는 최고의 전략은, 기존 코드를 아예 건드리지 않는 것이다.

이를 위해 역할과 구현을 분리하고, 구현이 아닌 역할에 의존해야 한다.

AS-IS

[Order] → [Food]
   ↘
    [Brand Product]

Order 내부
- if 등 조건절...

Order가 Food라는 구현체에 의존하고 있는 상태에서 Brand Product가 추가되면, Order는 Brand Product에도 의존하게 된다.
Order 내부에서 타입에 따른 if 조건절 분기가 필요해지며, 새로운 상품 유형이 추가될 때마다 기존 코드를 수정해야 한다.

즉, 수정에 열려있는 확장이 되는것이다.

TO-BE

[Order] → [Calculable]  ← 역할 (인터페이스)
             ↑    ↑
         [Food]  [Brand Product]  ← 각각의 구현체

Order는 Calculable이라는 역할(인터페이스)에 의존한다.

Food와 Brand Product는 각각 Calculable을 구현하는 구현체이다.

새로운 상품 유형을 추가할 때 기존 코드를 수정할 필요 없이 새로운 구현체만 추가하면 된다.

따라서, 수정에는 닫힌채 확장할 수 있다.

OCP의 목표

확장하기 쉬우면서도 변경으로 인한 영향 범위를 최소화하는 것이다.

L - LSP (Liskov Substitution Principle) 리스코프 치환 원칙

원칙의 목적

기본 클래스(상위)의 파생 계약을 파생 클래스(하위)가 제대로 치환할 수 있어야 한다.

위반 사례

interface Member {
    double getDiscountRate(); // 정상적인 할인율 값 반환
}

class BlacklistedMember implements Member {
    @Override
    public double getDiscountRate() {
        throw new RuntimeException("블랙리스트 회원은 할인 불가");
    }
}

Q. 다형성을 이용하는 곳에서 Member 인터페이스 하위 객체를 반복문으로 순회하며 getDiscountRate()를 호출하면 어떤 문제가 발생할까?

A. 상속받은 하위 객체가 상위 객체를 대신하여 역할을 수행할 수 없다. 상속받은 하위 객체를 신뢰할 수 없게 되며, 하위 객체의 변경이 외부로 전파되게 된다. 왜나면 결국 호출하는 쪽에서 아래와 같은 instanceof 체크가 필요해지기 때문이다..

if (member instanceof BlacklistedMember) {
    // 예외 처리...
}

즉, LSP는 안전한 다형성 사용과 OCP를 지키기 위한 필수 전제 조건이다.

올바른 설계

애초에 Member와 BlacklistedMember 둘 다가 getDiscountRate()를 구현해야 하는 것이 잘못된 설계다.
ISP 원칙에 맞게 분리해야 한다.

// 회원의 공통 속성
interface Member {
    // 아이디, 패스워드, 가입일 등 ...
}

// 할인 적용 역할
interface Benefitable {
    double getDiscountRate();
}

// 일반 회원 - 할인 가능
class RegularMember implements Member, Benefitable {
    @Override
    public double getDiscountRate() { return 0.1; }
}

// 블랙리스트 회원 - 할인 불가
class BlacklistedMember implements Member {
    // getDiscountRate()를 구현할 필요가 없다
}

Meber와 Benefitable로 역할을 분리함으로써, 할인이 가능한 회원만 Benefitable을 구현하고 블랙리스트 회원은 Member만 구현하면 된다.

I - ISP (Interface Segregation Principle) 인터페이스 분리 원칙

원칙의 목적

어떤 클래스가 자신에게 필요하지 않은 인터페이스의 메소드를 구현하거나 의존하지 않음으로써, 인터페이스의 크기를 작게 유지하고 클래스가 필요한 기능에만 집중하는 것이다.

통합된 인터페이스는 구현체에 불필요한 구현을 강요할 수 있다.

범용성을 갖춘 하나의 인터페이스보단 다수의 특화된 인터페이스를 만드는 게 낫다.

역할을 다 쪼개면 응집도가 낮아지는 것 아닌가?

단순히 "유사한 코드라서 한 곳에 모아두겠다"는 것은 가장 낮은 응집도이다.

인터페이스 분리 원칙에서 말하는 인터페이스는 곧 역할이다. 따라서 역할과 책임을 분리하고, 역할을 세세하게 나누라는 것이다.

이를 통해 기능적 응집도를 높이는 것이다.

기능적 응집도란?

모듈 내 컴포넌트들이 같은 기능을 수행하도록 설계된 경우를 말한다.

모듈이 [어떤 목적]을 갖고 있고, 컴포넌트들은 [그 목적]을 달성하기 위해 협력하며, 오직 [그 목적]에 관련된 작업만 수행하는 것이다.
목적 예시: 주문 처리, 주문 취소, 주문 예약 등 — 모두 하나의 목적을 위해 존재하는 컴포넌트가 된다.

D - DIP (Dependency Inversion Principle) 의존 역전 원칙

원칙의 목적

"구체화가 아닌 추상화에 의존해야 한다."

상위 모듈은 하위 모듈에 의존해서는 안 된다. 상위, 하위 모듈 둘 다 추상화에 의존해야 한다.
추상화는 세부사항에 의존해서는 안 된다. 세부사항이 추상화에 의존해야 한다.

쉽게 표현하면 다음과 같다.

고수준 모듈은 추상화에 의존해야 한다.
고수준 모듈이 저수준 모듈에 의존해서는 안 된다.
저수준 모듈은 추상화를 구현해야 한다.

여기서 말하는 의존이란?

의존은 다른 객체나 함수를 사용하는 상태이다. 즉, 사용만 해도 의존하는 것이다.

중요한 것은 "어떻게 하면 의존성을 낮출 수 있는가"이다.

Q. 사용하면 의존인데, 강약의 차이가 있을 수 있을까?

A. 있다. 강한 의존과 약한 의존이 있다.

의존은 다시 말해 결합(Coupling)이고, 결합에는 강도가 있으며, 결합에는 다양한 방법이 존재한다.

의존성을 약화시키는 기법 — 의존성 주입(DI)

의존성 주입은 필요한 의존성을 외부에서 넣어주는 것이다. 여기엔 아래 방법들이 있다.

생성자 주입 — 생성자 파라미터로 의존성을 전달
수정자 주입 — setter 메소드로 의존성을 전달
필드 주입 — Spring의 @Autowired로 의존성을 전달

상세한 구현 객체(new 사용)에 의존하는 것을 지양하고, 구현 객체가 인스턴스화되는 시점을 최대한 뒤로 미루는 것이 핵심이다.

참고로 Spring 프레임워크가 바로 이를 해주는 도구다.
개발자가 직접 객체를 생성하지 않고, 프레임워크가 애플리케이션 실행 시점에 의존 관계를 해석하여 주입한다.

의존성 "역전"

의존성의 정의는 했다. 그렇다면 역전은 무엇일까?

AS-IS

[Restaurant] ——의존——→ [HamburgerChef]
 - 상위 모듈               - 구현체
 - 고수준 모듈              - 하위 모듈
                         - 저수준 모듈

레스토랑이 햄버거 셰프에 직접 의존한다.

TO-BE

[Restaurant] ——의존——→ [Chef]  ← 추상화 (역할)
 - 상위 모듈               ↑
 - 고수준 모듈        [HamburgerChef]
                       - 세부사항
                       - 저수준 모듈
                       - 하위 모듈

레스토랑은 셰프라는 역할에 의존하며, 햄버거 셰프도 셰프라는 역할에 의존한다.

위에서 무엇이 역전되었는가?

HamburgerChef(햄버거 요리사)가 의존을 당하고 있었는데, 의존을 하도록 변경되었다. 의존 화살표가 들어오고있었는데 나가도록 역전된 것이다.

의존성 역전의 효과

의존성 역전을 적용함으로써 추상화에 의존하는 형태로 바뀐다. 즉, 의존성 역전 원칙은 곧, "세부사항에 의존하지 않고 정책에 의존하도록 코드를 작성하라"이다.

경계의 형성

의존성 역전을 적용하면 경계가 만들어진다. Chef 인터페이스를 기준으로 경계가 형성되는 것이다.

┌─────────────────────────┐
│  레스토랑 모듈 (상위 모듈)    │
│  [식당] → [Chef]         │
└─────────────────────────┘
              ↑
┌─────────────────────────┐
│  햄버거 모듈 (하위 모듈)     │
│      [햄버거 요리사]       │
└─────────────────────────┘

이 경계를 기준으로 모듈을 나눌 수 있고, 모듈 간 상하 관계를 파악할 수 있다.

Chef가 하위 모듈 경계로 들어가면 안 되는 이유

만약 Chef 인터페이스가 햄버거 모듈(하위 모듈) 안에 있다면, 상위 모듈인 레스토랑이 하위 모듈의 Chef에 의존하게 된다.

이때 햄버거 모듈의 Chef를 한식 요리 모듈의 Chef로 교체해야 한다면, 상위 모듈이 하위 모듈의 변경에 영향을 받게 된다.

따라서 추상화(인터페이스)는 반드시 상위 모듈 경계 안에 위치해야 한다.

정리

원칙	핵심	목표
SRP	단일 액터, 단일 책임	변경의 영향 범위 최소화
OCP	역할과 구현 분리	수정 없는 확장
LSP	하위 타입 치환 보장	안전한 다형성 사용 및 OCP 원칙을 지킴
ISP	인터페이스 세분화	기능적 응집도 향상
DIP	추상화에 의존	의존성 역전으로 경계 형성

보다시피 SOLID 원칙들은 서로 독립적인 것이 아니라, 유기적으로 연결되어 있다.

"SRP로 책임을 분리하고, OCP로 확장에 열린 구조를 만들며, LSP로 다형성의 안전성을 보장하고, ISP로 역할을 세분화하며, DIP로 의존성을 역전시켜 모듈 간 경계를 형성한다."

결국 이 모든 원칙이 지향하는 것은 하나다. 유지보수성과 확장성이 높은 소프트웨어를 만드는 것.