트랜잭션의 격리 수준은 왜 중요할까

[Uechann]

트랜잭션의 격리 수준은 4단계가 존재합니다.
API를 설계할 때 격리 수준을 명시적으로 고민해보신 적 있으신가요?
사용하는 DB마다 기본값도 다르고 개념 자체도 낯설게 느껴질 수 있는데,
막상 실제 동시성 이슈를 마주하고 나서야 뒤늦게 들여다보게 되는 경우가 많은거 같습니다.
격리 수준을 높일수록 정합성은 올라가지만 성능은 떨어집니다.
이러한 트레이드오프를 어떤 기준으로 결정하시나요?

[softmoca]

격리 수준과 이상 현상

격리 수준을 결정하는 기준을 이야기하기 전에,
각 격리 수준에서 어떤 이상 현상(anomaly)이 허용되는지부터 정리해보겠습니다.

각 격리 수준과 허용되는 이상 현상

격리 수준	Dirty Read	Non-Repeatable Read	Phantom Read
READ UNCOMMITTED	허용	허용	허용
READ COMMITTED	방지	허용	허용
REPEATABLE READ	방지	방지	허용
SERIALIZABLE	방지	방지	방지

• Dirty Read : 아직 커밋되지 않은 데이터를 읽는 현상
• Non-Repeatable Read :; 같은 트랜잭션 내에서 같은 row를 두 번 읽었는데 값이 다른 현상
• Phantom Read : 같은 조건으로 두 번 조회했는데 결과 row 집합이 다른 현상

트랜잭션 격리 수준이 중요한 이유

저는 트랜잭션 격리 수준이 중요한 이유는 결국
“동시에 여러 요청이 들어왔을 때, 내가 작성한 비즈니스 규칙이 여전히 지켜지는가?”
와 연결된다고 생각합니다.

단일 요청만 보면 로직이 맞아 보여도, 실제 서비스에서는 같은 데이터를 여러 트랜잭션이 동시에 읽고 수정합니다.
이때 격리 수준이 낮으면 Dirty Read, Non-repeatable Read, Phantom Read, Lost Update 같은 문제가 발생할 수 있고,
결과적으로 애플리케이션 코드에서 의도한 정합성이 깨질 수 있습니다.

이번 미션 예약 API의 규칙을 예시로 들어볼 수 있을 것 같습니다.
"같은 날짜, 같은 시간, 같은 테마에는 예약이 하나만 가능하다."

서비스 코드에서는 아래처럼 검증할 수 있습니다.

if (reservationRepository.existsByDateAndTimeAndTheme(date, timeId, themeId)) {
    throw new IllegalArgumentException("이미 예약된 시간입니다.");
}

reservationRepository.save(reservation);

단일 요청만 보면 문제가 없어 보입니다.
하지만 동시에 두 요청이 들어오면 둘 다 exists 결과를 false로 읽고, 둘 다 save까지 진행할 수 있습니다.

즉, 코드상으로는 “중복 예약 방지” 로직이 존재하지만,
트랜잭션 관점에서는 그 규칙이 안전하게 보호되지 않을 수 있습니다.

그래서 격리 수준은 단순한 DB 옵션이 아니라,
비즈니스 불변식을 동시성 상황에서도 보장하기 위한 설계 요소라고 생각합니다.

이 API에서 깨지면 안 되는 정합성은 무엇인가?

격리 수준을 결정할 때는 저는 먼저 이 질문을 던질 것 같습니다.

예를 들어 단순 조회 API라면 약간 오래된 데이터를 읽는 것이 큰 문제가 아닐 수 있습니다.
이 경우에는 기본 격리 수준을 그대로 사용해도 충분할 수 있습니다.

반대로 결제, 재고 차감, 예약 생성, 쿠폰 사용, 계좌 이체처럼
중복 처리되면 안 되거나 수량이 정확해야 하는 기능에서는 더 강한 정합성 보장이 필요합니다.

이때 선택지는 단순히 “격리 수준을 높인다”만 있는 것은 아니라고 생각합니다.
예를 들어 중복 예약 방지는 아래처럼 여러 방식으로 접근할 수 있습니다.

1. DB 유니크 제약 조건으로 최종 방어선 만들기
   1. UNIQUE(date, time_id, theme_id)
2. 비관적 락으로 해당 자원을 먼저 잠그기
   1. SELECT ... FOR UPDATE
3. 낙관적 락으로 버전 충돌 감지하기
   1. @Version
      private Long version;
4. 필요한 경우 트랜잭션 격리 수준을 높이기
   1. @transactional(isolation = Isolation.SERIALIZABLE)

그래서 저는 격리 수준을 높이는 것은 중요한 선택지이지만,
항상 첫 번째 선택지는 아닐 수 있다고 생각합니다.
격리 수준을 높이면 정합성은 강해질 수 있지만,
락 경합이 늘어나고 처리량이 줄어들 수 있기 때문입니다.

제 기준으로는 이렇게 정리할 수 있을 것 같습니다.

1. 기본값을 무조건 믿지 않는다

DB마다 기본 격리 수준이 다르기 때문에,
“Spring에서 @transactional 붙였으니 안전하겠지”라고 생각하면 위험할 수 있다고 봅니다.
특히 MySQL, PostgreSQL, H2 등은 기본 격리 수준이나 동작 방식이 다를 수 있어서,
테스트 환경에서는 문제가 없었는데 운영 DB에서는 다르게 동작할 가능성도 있습니다.

2. 읽기 정합성이 중요한지, 쓰기 정합성이 중요한지 구분한다

조회 API는 어느 정도 최신성이 떨어져도 괜찮은 경우가 많습니다.
하지만 생성/수정 API는 다릅니다.
특히 “검증 후 저장” 구조에서는 동시성 문제가 생기기 쉽습니다.
검증한다 -> 저장한다
이 사이에 다른 트랜잭션이 끼어들 수 있기 때문입니다.
그래서 쓰기 API에서는 격리 수준뿐 아니라 DB 제약 조건, 락, 재시도 전략까지 함께 고려해야 한다고 생각합니다.

3. 애플리케이션 검증만으로 불변식을 보장하려 하지 않는다

서비스 코드의 검증은 사용자에게 좋은 예외 메시지를 주거나,
비즈니스 흐름을 명확히 표현하는 데 의미가 있습니다.
하지만 동시성 상황에서 최종 정합성을 보장하는 역할은 DB 제약 조건이 더 적합한 경우가 많다고 생각합니다.
예를 들어 중복 예약을 막아야 한다면 서비스에서 먼저 검증하더라도,
최종적으로는 DB에 unique constraint를 두는 편이 더 안전합니다.

4. 부하 테스트로 실제 트레이드오프를 확인한다

격리 수준이나 락 전략은 이론적으로만 판단하기 어렵다고 생각합니다.
예를 들어 SERIALIZABLE로 격리 수준을 높이면 정합성은 강해질 수 있지만,
실제 요청이 몰렸을 때 락 대기 시간이 길어지거나 처리량이 크게 떨어질 수 있습니다.
반대로 기본 격리 수준을 그대로 두면 성능은 괜찮아 보일 수 있지만,
동시 요청 상황에서 중복 생성이나 Lost Update 같은 문제가 발생할 수 있습니다.

그래서 중요한 API라면 단순히 “이 격리 수준이면 안전하겠지”에서 끝내기보다,
동시 요청을 재현하는 테스트나 부하 테스트를 통해 실제로 정합성과 성능이 모두 요구사항을 만족하는지 확인해야 한다고 생각합니다.

예를 들어 예약 생성 API라면 같은 날짜, 같은 시간, 같은 테마에 대해 동시에 여러 요청을 보내보고,

• 중복 예약이 실제로 생성되지 않는지
• 실패한 요청은 의도한 예외로 처리되는지
• 락 대기 시간이나 응답 시간이 감당 가능한 수준인지
• TPS가 요구사항을 만족하는지
  를 함께 확인할 수 있을 것 같습니다.

즉, 격리 수준 결정은 코드와 DB 설정만으로 끝나는 것이 아니라,
실제 동시성 상황을 재현해보고 정합성과 성능 사이의 균형을 검증하는 과정까지 포함되어야 한다고 생각합니다.

최종 정리

결론적으로 저는 트랜잭션 격리 수준을 이렇게 이해할 수 있을 것 같습니다.
"트랜잭션 격리 수준은 성능 옵션이 아니라, 동시성 상황에서 비즈니스 규칙을 어느 정도까지 보호할 것인지 결정하는 설계 선택"이다.

다만 격리 수준을 무조건 높이는 방향보다는,
깨지면 안 되는 불변식이 무엇인지 먼저 정의하고,
그 불변식을 DB 제약 조건 / 락 / 격리 수준 / 재시도 전략 중 어떤 조합으로 지킬지 선택하는 것이 더 현실적인 접근이라고 생각합니다.
그리고 그 선택이 실제로 유효한지는 단순 추측이 아니라,
동시성 테스트와 부하 테스트를 통해 정합성과 성능을 함께 확인해야 한다고 생각합니다.

[koreaioi]

모카가 잘 설명해주어서, 비슷한 답변이겠네요

---

이론을 현실에 대입하는 건 실험뿐이다.

주장에 근거가 없으면 설득력이없습니다. 이때 근거는 단순한 이론이 아니라, 실험을 통해 증명하는 게 효과적이라고 생각합니다.

A는 이런 트레이드 오프가 B는 이런 트레이드 오프가 있습니다.
그래서 저희는 A를 선택했습니다.

보다는

A 상황으로 테스트하였을 때, 이러한 장점과 단점을 겪었고, B 상황으로 테스트하였을 때, 이러한 장점과 단점을 겪었습니다.
그래서 저희는 A를 선택했습니다. (+A 상황의 트레이드 오프가 더 좋은 이유까지...)

가 주변 동료들 그리고 제 자신에게도 설득력있는 의견이라 생각합니다.

---

Q. API를 설계할 때 격리 수준을 명시적으로 고민해보신 적 있으신가요?

격리 수준을 고려하는 시기는 대부분 동시성 문제를 맞닿뜨렸을 때이지만,
동시성 문제를 만났을 때, 해결책으로 격리수준을 바로 떠오르지는 않는 편입니다.

때문에, API를 설계할 때, 이 부분은 동시성 이슈로 인해 격리수준을 조절해야겠다라고 결정해본 적은 없는 거 같네요.
동시성 문제 해결책이 격리수준만 있는 게 아니니까요.

REPEATABLE READ이지만, Phantom Read까지 막아주는 MySQL을 주로 사용해서, 격리수준에 대한 고민을 해본 적이 없는 거 같아요.

---

그래서 READ COMMITTED, REPEATABLE READ, SERIALIZABLE를 고민하기 보다는, 해당 API가 반드시 지켜야 하는 부분과 느슨해도 되는 부분을 고민해보는 편입니다.

반드시 지켜야하는 부분의 예시는 다음이 있겠습니다.

• 예약이 중복되면 안된다.
• 결제 시 돈은 한 번만 빠져나가야한다.
• 정해진 쿠폰의 수량

느슨해도 되는 부분은 다음과 같습니다.

• 조회수가 정확히 표기되지 않아도 된다. (조회수 12300를 12.3k로 표기)
• 인기 콘텐츠 순위가 실시간으로 정확히 반영될 필요는 없다. (인기 영상 순위가 1초 단위로 정확히 반영되지 않아도 사용자 경험에 큰문제가 X)

여기서 고민한다는 이유는 비슷한 상황에서도 도메인에 따라, 반드시 지켜야할 수 도 있기 때문입니다.
게시판의 경우 조회수는 큰 정합성을 요구하지 않지만, 유튜브의 경우 조회수 1회당 1원이라면 보다 높은 정합성을 요구할테니까요.

상황마다 너무 다르기 때문에, 비즈니스 규칙을 나열한 뒤, 가설은 세우고 이를 증명하면서 적절한 선택을 해볼 것 같습니다.

[sangjun121]

결론 먼저

저는 격리 수준이 높을수록 단순히 더 안전하고 좋다기 보다는, 해당 도메인에서 어떤 데이터 이상현상을 허용할 수 있을지를 기준으로 결정해야 한다고 생각합니다. 즉, 도메인 규칙과 비즈니스 정책에 따라 달라질 것 같습니다.

1. 격리 수준 조정에 앞서 선행되야 할 것

사실, 질문의 방향을 조금 벗어나지만, 동시성 제어의 첫번째 옵션으로 격리 수준을 먼저 조정하는 것은 말씀하신대로 트레이드 오프가 크다고 생각합니다.

저는 지금까지 동시성 문제를 해결할 때, 좀더 좁은 범위에서의 락 전략이나 제약 조건을 추가하는 방향으로 동시성을 제어했었습니다. SERIALIZABLE로 올려 정합성을 해결할 수 있겠지만 DB 전체의 동시성 처리 성능에 영향을 주기 때문에 너무 큰 비용의 트레이드 오프가 발생한다고 생각합니다. (물론 송송이 말씀해주신 대로, 이 주장도 실험을 통한 검증을 근거로 삼는다면 더 설득력 있을 것이라고 생각합니다)

따라서 우선은, 격리 수준을 먼저 검토하기 보다, unique constraint, optimistic lock, pessimistic lock 같은 더 좁은 범위의 해결책을 먼저 고려해야 하지 않을까 합니다.

2. 그래도 격리 수준을 조절해야 한다면

그럼에도 불구하고, 위와 같은 방법만으로 해결되지 않아 격리수준을 조절해야 한다면, 결국 기준은 도메인 규칙과 비즈니스 정책이 되어야 한다고 생각합니다.

예를 들어, 예약 시스템과 같이 중복 예약이 발생하면 비즈니스 자체에 문제가 생기는 도메인이라면, 성능을 일부 포기하더라도 데이터 정합성을 우선시해야한다고 생각합니다.

반대로 유튜브 조회수처럼 순간적으로 정확한 값이 아니더라도 비즈니스 자체에 큰 문제가 없는 시스템이라면, 읽기 불일치나 읽기 모델의 업데이트에 시간차가 발생하더라도(최종 일관성 보장) 성능을 우선하는 선택도 합리적이라고 생각합니다.

[haeyoon1]

지금까지는 프로젝트에서 격리수준을 따로 설정하여 적용해볼일이 없었는데, 이번 기회에 생각해보게 되었습니다.

먼저 "트랜잭션 격리를 어느 수준으로 설정해야하는가?"에 대한 기준은
위에 다른 분들이 자세히 작성해준 것 과 비슷한 의견입니다.

간단하게 얘기하자면
값을 변경하거나, post 요청을 보내는 경우에는 등에는 일반적으로 엄격하게 지켜져야하나,
조회를 통해 보여지는 값들은 그렇지 않은 경우들이 있는 것 같아요.

하지만 저도 송송님의 의견처럼 동시성 이슈를 마주쳤을 때 트랜잭션의 격리수준을 1차적으로 고려하지는 않는 편인 것 같습니다.
주제에서 조금 벗어났지만 다른 분들이 이미 격리수준 자체에 대해서는 충분히 자세히 적어주신 것 같아, 저는 동시성 이슈를 해결할 때 사용했던 다른 방법들에 대해 몇 가지 적어보려고 합니다.

동시성 이슈 해결 방법

1. 동시성 부하가 큰 영역은 아예 DB 바깥으로 빼서 인메모리에 저장합니다
   외부에서 초당 여러개의 데이터가 들어오는 부분이 있었는데, 이를 map에 적재하도록 했습니다.
   그렇게 되면 갱신과 조회가 동시에 일어나도 DB 트랜잭션이 충돌할 일이 없게 되더라구요!

2. 배치로 DB에 적재할 때는 큐와 락을 조합해서 짧은 구간만 보호합니다
   데이터를 바로바로 DB에 저장하면 부하가 크기 때문에, 큐에 일단 쌓아뒀다가 일정 개수가 모이면 한 번에 저장하는 방식으로 처리했어요.
   이때 큐에서 데이터를 꺼내오는 짧은 구간만 synchronized로 묶고, 실제 DB 저장은 락 밖에서 진행하도록 했습니다. 그렇게 되니 락을 잡고 있는 시간을 최소화하면서도, 여러 스레드가 동시에 같은 데이터를 꺼내가서 중복 저장되는 상황을 막을 수 있더라구요.

적고 보니 저는 동시성 부하가 큰 곳은 아예 DB 바깥으로 빼거나 락 범위를 좁히는 방식으로 풀어왔던 것 같습니다.
격리수준이라는 관점으로도 한번 고민해봐야겠네요!