Repeatable Read

Repeatable Read

Repeatable Read(반복 읽기) 는 트랜잭션 내에서 같은 조회가 항상 동일한 결과를 반환하도록 보장해 재현성을 확보한다.
구현은 MVCC(스냅샷 기반) 또는 잠금 (범위·next-key) 방식으로 나뉘며, 두 방식은 가시성·충돌 처리·성능 특성이 다르다.
RR 은 Dirty Read 와 Non-repeatable Read 를 방지하지만 Phantom(범위 삽입/삭제) 은 엔진별로 다르게 처리된다.
따라서 금융·결산 같은 재현성이 중요한 워크로드에 유리하되, 실제 적용 전 DB 별 동작 확인, 재현 테스트, 성능·교착 검증, 필요 시 부분적 상향 (Serializable) 또는 리포트 분리가 필요하다.

핵심 개념

Repeatable Read 는 하나의 트랜잭션이 같은 쿼리를 여러 번 실행해도 결과가 바뀌지 않도록 보장하는 격리 수준이다.
데이터베이스는 변경 전 상태를 저장 (언두 로그) 하고 각 트랜잭션에 스냅샷을 제공함으로써 이를 구현한다.
다만 구현 방식에 따라 ’ 팬텀 ’ 이나 ’ 쓰기 왜곡 ’ 같은 특수한 동시성 문제가 남을 수 있으므로, 실무에선 사용 전 DB 엔진의 동작을 확인하고 트랜잭션을 짧게 유지하며 모니터링을 준비해야 한다.

• 핵심 개념들은 이론 (스냅샷·락) 과 운영 (트랜잭션 길이·모니터링) 으로 나뉘며, 실무 적용 시 두 축을 함께 고려해야 안정적으로 운영할 수 있다.

개념 상호관계 및 방향성

• 방향성은 ’ 기초 → 구현 → 보장 ‘(Undo→MVCC→Snapshot→RR) 과 ’ 운영 변수 → 영향 ‘(트랜잭션 길이/인덱스 → 성능·락 범위) 으로 구분된다.
• 실무에서는 이 흐름을 이해해 ’ 어떤 요소를 튜닝하면 어느 문제가 완화되는지 ’ 가 명확해져야 한다.

개념별 실무 적용 매핑표

• 각 개념은 ’ 무엇을 달성 ’ 하고 ’ 어떻게 적용 ’ 되며 그 결과로 ’ 왜 비즈니스에 중요한지 ’ 가 연결된다.
• 실무 적용은 단순 설정이 아니라 엔진 특성·운영 모니터링·코드 패턴을 함께 설계해야 효과적이다.

기초 조사 및 개념 정립

Repeatable Read 핵심 가이드

Repeatable Read(리피터블 리드) 는 트랜잭션 내부에서 한 번 읽은 데이터가 그 거래가 끝날 때까지 변하지 않도록 보장하는 격리 수준이다.
보통 MVCC(버전 스냅샷) 나 읽기 락을 활용해 구현하며, 이로써 Non-repeatable Read는 방지된다.
그러나 Phantom(같은 조건의 쿼리 결과에 새로운 행이 추가되거나 삭제되는 현상) 은 구현에 따라 다르므로 주의가 필요하다.
실무에서는 다단계 계산이나 중간 검증이 필요한 비즈니스에 적합하지만, 긴 트랜잭션·범위 스캔이 많은 워크로드에서는 성능·운영 비용을 고려해 설계해야 한다.

무엇을 보장하나?

• 동일 트랜잭션 내 같은 행에 대한 반복 조회 시 항상 동일한 값을 반환한다.

어떻게 구현되나?

• MVCC 방식: 트랜잭션 시작 시 스냅샷을 찍어 해당 시점의 커밋된 버전을 계속 읽음 → 언두/버전 저장 필요.
• 락 기반 방식: 읽기 시 공유락을 취득하거나 특정 버전을 고정하여 다른 트랜잭션의 쓰기 가시화를 늦춤.

무엇을 허용/금지하나?

• 금지: Non-repeatable Read (같은 행의 값이 바뀌는 경우).
• 허용 (또는 상황에 따라): Phantom—일부 DB/설정에서는 범위 락으로 방지하지만, 스냅샷형 구현에서는 Phantom 특성이 달라질 수 있음.

실무적 고려사항

• 긴 트랜잭션 금지: 버전 축적·GC 문제로 운영 부담이 커짐.
• 인덱스 설계 중요: 범위 스캔이 많으면 gap/next-key 락 확산 → 인덱스 재검토 필요.
• DB 별 테스트 필수: 동일한 ‘Repeatable Read’ 명칭이라도 구현·옵션별 동작 차이가 크므로 환경별 재현 테스트를 권장.

Repeatable Read 등장배경·발전 흐름

초기 DB 들은 낮은 격리 (RU/RC) 에서 Dirty Read·Non-repeatable Read 같은 문제로 고생했다.
이를 해결하려고 Repeatable Read가 등장했으며, RR 은 트랜잭션 시작 시점의 읽기 뷰 (스냅샷) 를 유지해서 같은 행을 반복 조회할 때 결과가 변하지 않도록 보장한다.
다만 범위 삽입 (팬텀) 은 구현 방식에 따라 달라지므로, 완전한 방지를 원하면 더 강한 격리 (Serializable) 나 락 전략을 고려해야 한다.

등장 배경

• 문제 상황: 초기 RDBMS 와 낮은 격리 수준 (READ UNCOMMITTED, READ COMMITTED) 에서는 미커밋 데이터 노출과 같은 트랜잭션 내 반복 조회 결과 불일치가 잦았다. 이로 인해 금융·회계 같은 도메인에서 심각한 오류가 발생했다.

• 요구: " 한 트랜잭션 내에서 같은 조회는 동일한 결과를 보여야 한다 " 는 요구가 커졌다 → Repeatable Read 채택으로 이어짐.

발전 과정 표

timeline
    title Repeatable Read 등장·발전 타임라인
    1970s-1990s : 초기 RDBMS (RU/RC 사용)
    1990s-2000s : Repeatable Read 개념/도입 (트랜잭션 스냅샷)
    2000s : InnoDB next-key / gap lock 도입 → 팬텀 제어 강화
    2000s-2010s : MVCC·언두/히스토리 개선으로 읽기 비차단 최적화
    2010s+ : SSI/Serializable 및 DB별 고급 옵션 도입 (정합성 강화)

RR 은 RC 에서 발생하는 반복불가 문제를 해결하려는 실무적 요구에서 태어났고, 그 이후 MVCC 의 보급과 갭/next-key 락 같은 기술이 결합되며 점차 현재의 형태로 발전했다.
현대 DB 는 RR 을 구현하면서도 **읽기 성능 (비차단)**을 유지하려는 최적화를 계속해왔고, 필요에 따라 더 엄격한 일관성 (Serializable/SSI) 을 선택할 수 있게 됐다. 다음 단계로는 엔진별 세부 버전·행동을 문서화해 타임라인을 정확히 채워넣는 작업이 필요하다.

Repeatable Read: 문제·목적·연결

Repeatable Read 는 " 한 트랜잭션이 같은 데이터를 여러 번 읽으면 항상 같은 값을 보게 하는 “ 격리 수준이다.
이렇게 하면 중간에 다른 트랜잭션이 값을 바꿔서 생기는 오류 (Non-repeatable Read) 를 막을 수 있다.
구현은 주로 **MVCC(버전 스냅샷)**나 **잠금 (락)**으로 이루어지며, 재무·재고·정산처럼 정확성이 중요한 업무에서 사용된다.
일부 데이터베이스는 추가 메커니즘으로 팬텀 (범위에 새로 생긴 행) 문제까지 억제해 더 강한 읽기 일관성을 제공하기도 한다.

Repeatable Read 가 해결하는 문제들

Repeatable Read 는 트랜잭션 수준의 재현 가능한 읽기 일관성을 목표로 하며, Dirty Read 는 완전히 차단하고 Non-repeatable Read 를 직접 해결한다. 팬텀 문제는 표준상 허용되지만, 일부 DB 는 범위락이나 내부 최적화로 이를 억제해 범위 기반 연산의 안정성까지 향상시킨다.

Repeatable Read 의 핵심 목적

핵심 목적은 트랜잭션 단위에서의 예측 가능한 동작 보장에 있다. 이는 재무·재고·정산과 같이 반복 조회와 일관성이 핵심인 비즈니스 로직에서 직접적으로 가치가 된다.

문제와 목적의 연관성 매핑표

각 해결 문제는 특정 핵심 목적과 직접 연결된다. 예를 들어 Non-repeatable Read 를 막는 것은 재조회 일관성 보장 목적을 달성하기 위한 수단이며, Dirty Read 차단은 데이터 신뢰성 확보로 직결된다. 따라서 설계자는 해결하려는 문제 (예: 재고 정확성) 에서 출발해 적절한 격리 수준 (Repeatable Read 등) 을 선택해야 한다.

Repeatable Read 적용 전제와 운영 요건

Repeatable Read 를 안정적으로 쓰려면 DB 가 트랜잭션과 버전 (undo/MVCC) 을 잘 지원해야 하고, 쿼리·인덱스·트랜잭션 설계를 신중히 해야 한다.
트랜잭션은 짧게 유지하고, 잠금·버전 비용을 모니터링하며 타임아웃과 재시도 정책을 마련해야 실무에서 성능 저하·교착을 피할 수 있다. 또한 DB 별 차이를 테스트해 정책을 문서화하라.

Repeatable Read 적용 전제·요구사항 표

Repeatable Read 는 단순히 격리 수준 선택만으로 끝나지 않는다. DB 의 내부 메커니즘 (MVCC vs 락), 인덱스·쿼리 설계, 트랜잭션 길이, 버전 스토어 관리, 모니터링·재시도 정책이 모두 함께 맞물려야 안정적으로 운영할 수 있다. 적용 전에는 대상 DB 에서 실제 워크로드로 검증 (A/B 테스트, 모니터링 수치 확보) 을 반드시 수행하라.

Repeatable Read: 근거·차별·운영 포인트

Repeatable Read 는 트랜잭션 내에서 같은 조회가 항상 같은 결과를 주도록 보장해 재현성을 확보한다.
구현은 MVCC(스냅샷) 나 범위/next-key 락으로 나뉘며, Dirty Read 와 Non-repeatable Read 를 차단한다.
Phantom 방지는 DB 엔진별 (예: InnoDB 의 갭 락, PostgreSQL 의 스냅샷) 로 달라지므로 적용 전 벤더 동작을 확인해야 한다.

Repeatable Read 특징·근거·차별표

Repeatable Read 는 재현성을 핵심으로 하는 격리 수준이며, 이를 위해 MVCC 스냅샷 또는 범위 락 같은 기술을 사용한다.
Phantom 관련 거동은 DB 엔진에 따라 다르므로, 실무 적용 전 벤더 문서 확인 + 재현 테스트가 반드시 필요하다.

핵심 원리 및 이론적 기반

Repeatable Read 설계 원칙·운영 철학

Repeatable Read 는 트랜잭션 내에서 동일 데이터를 여러 번 읽더라도 같은 값이 보이도록 보장하는 격리 수준이다. 이를 위해 흔히 MVCC(스냅샷) 을 사용하거나 읽기 중 해당 행을 고정한다. 목표는 다단계 연산 시 일관성을 보장하면서도 전체 시스템의 동시성을 가능한 유지하는 것이다. 실제 설계에서는 트랜잭션을 짧게 유지하고 (언두·버전 축적 방지), 쿼리·인덱스 패턴을 최적화하며, 재시도·멱등성 전략과 모니터링을 병행해 운영 리스크를 관리한다.

Repeatable Read 핵심원칙 표

Repeatable Read 의 핵심은 " 트랜잭션 내부 일관성 유지 " 다. 이를 효과적으로 운영하려면 스냅샷/락 메커니즘을 이해하고, 트랜잭션을 짧게 설계하며 인덱스·쿼리를 최적화하고 재시도·멱등 패턴을 적용해야 실제 서비스에서 성능 저하 없이 안전하게 사용할 수 있다.

Repeatable Read 설계 철학 표

설계 철학은 단순한 기술 선택을 넘어 조직의 정책·운영·테스트 문화와 연결된다. Repeatable Read 를 적용할 때는 ’ 어디까지 일관성을 보장할지 ‘, ’ 성능 손해를 어느 수준까지 허용할지 ’ 에 대한 명확한 기준을 세우고 이를 기술·운영·테스트 관점에서 일관되게 구현해야 한다.

Repeatable Read: 원리·구현·운영포인트

Repeatable Read 는 " 한 트랜잭션 안에서 같은 데이터를 여러 번 읽으면 항상 같은 결과를 본다 " 는 약속을 제공하는 격리 수준이다.
이를 위해 DB 는 읽기 시점의 스냅샷(혹은 락) 을 사용해 다른 트랜잭션의 중간 변경을 숨긴다.
결과적으로 같은 트랜잭션에서 값이 바뀌는 문제 (Non-repeatable Read) 는 사라지지만, 범위 (행 집합) 가 바뀌는 팬텀 문제는 DB 구현에 따라 다르게 처리된다.
실무에서는 RR 을 쓰되 트랜잭션을 짧게 유지하고 장기 트랜잭션을 모니터링해야 한다.

RR 핵심 메커니즘 요약표

• RR 핵심은 스냅샷 (또는 범위락) 으로 " 읽는 시점의 일관성 " 을 보장하는 것.
• 운영 관점에서 가장 중요한 위험은 장기 트랜잭션 → 버전 보존 연장 → GC/스토리지 부담이며, 락 기반 구현은 락 오버헤드·데드락을 유발할 수 있다.
• 따라서 RR 도입 시 엔진별 스냅샷 정책·락 전략·GC 동작을 먼저 확인해야 한다.

RR 동작 흐름: 락 Vs MVCC

flowchart TD
  subgraph LockBased["락 기반 RR"]
    A1["T1: SELECT (range) -> acquire next-key/gap lock"]
    B1[T2: INSERT within range] -->|blocked| A1
    A1 --> C1["T1: 작업 계속 (동일 결과 보장)"]
    B1 -->|unblocked after T1 commit| D1[T2: INSERT succeeds]
  end

  subgraph MVCC["MVCC 기반 RR"]
    A2[T1: start -> create snapshot S]
    B2[T2: INSERT x=15 -> commit]
    A2 --> C2[T1: SELECT reads from S -> new row invisible]
    B2 --> D2[T2: committed version visible to new txns]
    C2 --> E2[T1: subsequent SELECT still uses S]
  end

• 락 기반 분기: T1 이 범위에 대해 next-key/gap lock 을 획득하면 T2 의 범위 삽입은 블록된다 (팬텀 방지). 이 방식은 팬텀을 강하게 막지만 락 대기·교착 위험이 있다.

• MVCC 분기: T1 은 시작 시 (또는 첫 읽기 시) 스냅샷 S 를 갖고 이후의 SELECT 는 S 기준으로 읽는다. T2 가 삽입·커밋하더라도 T1 은 자신의 스냅샷에 없던 새 행을 보지 못한다. MVCC 는 읽기 비차단으로 성능이 좋으나, 오래된 스냅샷이 버전 보존을 요구한다는 점에 유의해야 한다.

Repeatable Read: 흐름·상태·운영포인트

• 트랜잭션 A 가 어떤 데이터를 읽으면, A 가 끝날 때까지 같은 조회는 같은 결과를 보여준다.
• 이를 위해 DB 는 (1) 조회 범위를 잠그거나 또는 (2) 시작 시점의 스냅샷을 고정한다.
• 결과: 중간에 다른 트랜잭션이 데이터를 넣어도 A 는 그 변화를 보지 않아 재조회 일관성이 보장된다.
• 단점: 범위 잠금은 다른 트랜잭션을 블로킹할 수 있고, 스냅샷은 오래 유지되면 디스크/메모리 부담이 커진다.

RR 의 데이터·제어 흐름 (상세)

핵심 단계 (락 기반)

1. T1 이 SELECT … WHERE x BETWEEN a AND b 시작 → DB 가 해당 범위에 범위/넥스트키 락을 설정 (또는 공유 락 유지).
2. T1 은 조회 결과를 받고, 락은 트랜잭션 종료 시까지 유지되어 다른 트랜잭션의 INSERT/DELETE 를 차단.
3. T2 가 해당 범위에 INSERT 시도 → 락 때문에 대기 또는 오류 발생 (정책에 따름).
4. T1 이 COMMIT/ROLLBACK → 락 해제 → 대기 중이던 T2 가 진행.

핵심 단계 (MVCC / 스냅샷 기반)

1. T1 시작 → DB 는 현재 커밋된 상태를 기준으로 스냅샷 S를 생성 (트랜잭션 수준 또는 statement 수준).
2. T1 의 SELECT 는 스냅샷 S 에 보이는 버전만 반환 (신규 커밋된 행은 보이지 않음).
3. T2 가 INSERT → 커밋해도, T1 은 자신의 스냅샷을 유지하므로 재조회 시에도 해당 신규 행을 보지 않음.
4. T1 종료 → 스냅샷 폐기 → 버전 정리 (garbage collection / undo cleanup).

RR 데이터·제어 흐름 요약표

표는 RR 의 두 구현 축 (락 기반 vs MVCC) 을 단계별로 비교해 가시성 규칙과 운영상 주의점을 정리한 것이다. 운영에서는 **장기 트랜잭션 (버전 누적)**과 **락 웨이트 (대기)**를 반드시 모니터링해야 하며, 워크로드에 따라 적절한 구현 (혹은 DB 옵션) 을 선택해야 한다.

RR 구현 흐름 비교도

flowchart LR
  subgraph LockBased["락 기반 구현"]
    A1[T1: SELECT 범위] --> A2[DB: 범위/넥스트키 락 획득]
    A2 --> A3[T2: INSERT 같은 범위 시도]
    A3 --> A4[DB: T2 대기/차단]
    A4 --> A5[T1: COMMIT/ROLLBACK]
    A5 --> A6[DB: 락 해제 -> T2 진행]
  end

  subgraph MVCC["MVCC/스냅샷 구현"]
    B1[T1 시작] --> B2[DB: 스냅샷 S 확보]
    B2 --> B3[T1: SELECT -> S 기준 반환]
    B3 --> B4[T2: INSERT 및 COMMIT]
    B4 --> B5[T1: 재조회 -> 여전히 S 기준] 
    B5 --> B6[T1: COMMIT -> 스냅샷 폐기]
  end

위 흐름도는 RR 의 두 구현 경로를 병렬로 보여준다. 락 기반은 범위 락을 통해 동시 삽입을 차단해 팬텀을 예방하고, MVCC 는 스냅샷을 통해 읽기 비차단을 유지하면서도 재조회 일관성을 보장한다. 각각의 장단점 (락 경합 vs 버전 누적) 을 운영에서 균형 있게 관리해야 한다.

RR 트랜잭션 생명주기도

stateDiagram-v2
    [*] --> Active: 트랜잭션 시작
    Active --> Acquire: 스냅샷/락 획득
    Acquire --> Read: 읽기 수행 (가시성 적용)
    Read --> Continued: 추가 문 반복 (새 가시성 없음)
    Continued --> Commit: COMMIT
    Continued --> Rollback: ROLLBACK
    Commit --> Release: 락 해제/스냅샷 폐기
    Rollback --> Release
    Release --> [*]

트랜잭션은 시작 후 가시성 기준을 획득 (스냅샷 또는 락) 하고, 그 기준을 유지하며 여러 문을 실행한다. 트랜잭션이 끝나면 가시성 자원을 반환 (락 해제/스냅샷 폐기) 하여 시스템 일관성이 유지된다. 이 생명주기 동안 자원 (락·버전) 이 오래 유지되면 다른 트랜잭션 성능에 영향을 줄 수 있다.

특성 분석 및 평가

RR 장점·실무 적용 요약

Repeatable Read 는 한 트랜잭션이 같은 쿼리를 여러 번 실행해도 결과가 바뀌지 않도록 보장하는 격리 수준이다.
데이터베이스는 트랜잭션별로 읽을 버전을 고정 (스냅샷) 하거나 범위 잠금을 걸어 이 동작을 구현한다.
그 결과 보고·정산·감사 같은 작업에서 결과 재현성이 확보되어 오류를 줄이고, 읽기 중심 환경에서는 동시성을 유지하면서도 일관성을 어느 정도 보장할 수 있다.
단, 실제 동작은 DBMS 마다 달라 팬텀이나 쓰기왜곡 같은 특수 사례는 추가 대비가 필요하다.

RR 장점 및 실무 가치표

• RR 의 장점들은 **” 일관성 (재현성) 확보 " 와 " 읽기 성능 유지 “**라는 두 축에서 실무 가치를 제공한다.
• 실제로 얻는 이득의 크기와 남는 위험 (팬텀, write-skew) 은 DBMS 구현 방식과 **쿼리 패턴 (범위/집계 여부)**에 따라 달라지므로 적용 전에 엔진별 테스트와 모니터링이 필수다.

Repeatable Read 의 한계와 운영 대응

Repeatable Read 는 트랜잭션 내에서 같은 쿼리를 반복하면 같은 결과를 보장하려는 격리 수준이다.
하지만 이 보장은 락 확대, 갭락, 또는 MVCC 버전 축적 같은 본질적 비용을 동반한다.
결과적으로 응답 지연·교착, 자원 증가, 일부 논리적 위반 (쓰기 스큐) 이 발생할 수 있다.
실무에서는 인덱스·트랜잭션 길이·모니터링·타임아웃·재시도 정책을 조합해 위험을 완화하거나, 필요하면 Serializable 로 격리 수준을 올리거나 아키텍처 (복제·CQRS) 로 분리해야 한다.

Repeatable Read 의 주요 단점

Repeatable Read 는 ’ 반복 읽기 보장 ’ 이라는 이득을 주지만, 그 대가로 락 경합·쓰기 스큐·버전 축적·벤더별 동작 차이 같은 실무적 위험을 동반한다. 각 위험은 설계 (인덱스·트랜잭션 범위), 운영 (모니터링·GC 튜닝), 정책 (재시도·타임아웃) 으로 완화 가능하며, 필요 시 더 강한 격리나 다른 아키텍처로 전환해야 한다.

Repeatable Read 의 제약사항

Repeatable Read 를 제대로 운영하려면 인덱스 설계·트랜잭션 길이 관리·버전 스토어 모니터링 등 환경적 전제조건을 충족해야 한다. 이 제약들을 무시하면 락 확대·자원 폭증·성능 저하가 발생하므로, 아키텍처적 대안 (샤딩, 복제본, CQRS, 분산 DB) 도 검토해야 한다.

Repeatable Read 의 트레이드오프와 실무적 해법

Repeatable Read 는 트랜잭션 내 같은 조회 결과를 고정해 재현성을 보장한다. 락 기반은 Phantom 억제에 강하지만 대기/데드락이 늘고, MVCC(스냅샷) 은 읽기 성능이 좋지만 일부 동시성 문제 (write-skew) 가 발생할 수 있다. 실무에서는 민감 트랜잭션만 상향하거나 (Serializable/SSI), 리포트는 리플리카로 분리하는 등 하이브리드 전략을 사용해 성능·일관성 균형을 맞춘다.

RR 트레이드오프 비교표

각 선택은 일관성 수준과 성능·확장성 사이의 전형적 트레이드오프를 반영한다. 서비스 특성 (읽기 대 쓰기 비율, 규제 요구, 응답성 요구) 에 따라 적절한 균형을 택하라.

RR 트레이드오프 완화 하이브리드 기법

하이브리드 기법들은 특정 트레이드오프 (성능 vs 일관성) 를 국지적으로 해결한다. 적용 시에는 목적 (무엇을 보호할지), 구성요소 (데이터베이스·인프라·애플리케이션), 운영 비용 (테스트·모니터링·복구) 을 반드시 고려하라.

Repeatable Read 적용성·운영 전략

Repeatable Read 는 트랜잭션 내부에서 같은 데이터를 여러 번 읽어도 동일한 값이 보이도록 보장하는 격리 수준이다. 따라서 범위 조회와 동시 삽입 충돌이 잦고 재현성·정합성이 중요한 OLTP(예: 재고 할당, 결제 정산) 에 적합하다.
다만 팬텀 (행 집합 변동) 이 치명적일 경우에는 Serializable 이나 명시적 범위 락을 병행해야 안전하다.
적용 전에 DB 별 동작 차이와 성능 영향 (락 대기, 언두 증가) 을 검증하고, 트랜잭션 짧게 설계·모니터링·자동화된 재시도 정책을 준비해야 한다.

Repeatable Read 적용 적합성 표

Repeatable Read 는 동시성 충돌이 잦고 거래 재현성이 필요한 핵심 OLTP에 적합하다. 그러나 대규모 범위 스캔·배치성 집계에는 언두/버전 스토어 증가와 긴 트랜잭션 문제로 부적합하거나 별도 설계가 필요하다. 팬텀 통제가 필수적이면 Serializable 또는 명시적 잠금을 병행 적용하라.

엔진별 Repeatable Read 동작 비교표

아래 표는 PostgreSQL, MySQL(InnoDB), Oracle, SQL Server 네 엔진의 Repeatable Read 관련 구현 메커니즘·기본값·주의점을 실무 관점에서 정리한 것이다.

• Postgres: MVCC 기반으로 REPEATABLE READ 는 트랜잭션 시점 스냅샷을 보장. 장시간 트랜잭션이 언두/버전 부하를 일으킬 수 있음.
• MySQL/InnoDB: 기본값이 REPEATABLE READ. MVCC + 갭락으로 많은 경우 팬텀을 억제하나, 인덱스·쿼리 패턴에 민감. 성능·락 행태를 반드시 워크로드로 테스트.
• Oracle: READ COMMITTED 가 기본. SERIALIZABLE 이 트랜잭션 수준의 repeatable 읽기를 제공. Oracle 특유의 read-consistency(UNDO 기반) 를 이해 후 설정.
• SQL Server: 전통적 REPEATABLE READ 은 락 유지 방식. 필요시 Snapshot/RCSI를 켜 MVCC 스타일 동작을 적용할 수 있음 (운영 리스크·tempdb 영향 고려).

실무 적용 및 사례

실습 예제 및 코드 구현

실습 예제: MySQL InnoDB 에서 Repeatable Read 동작

목적

• 동일 트랜잭션 내에서 외부 트랜잭션의 데이터 변경을 반복 조회 시 반영하지 않는 원리 실습

사전 요구사항

• MySQL, InnoDB 엔진 테이블 (users)

단계별 구현

1. 트랜잭션 시작 및 초기 조회

1
2

START TRANSACTION;
SELECT price FROM products WHERE id = 100; -- 결과: 50000

1. 외부 트랜잭션에서 값 변경 후 커밋

1
2
3

-- 별도 세션
UPDATE products SET price = 45000 WHERE id = 100;
COMMIT;

1. 트랜잭션 내에서 재조회

1
2

SELECT price FROM products WHERE id = 100; -- 결과: 50000 (변경 안 반영)
COMMIT;

실행 결과

• 처음 조회한 시점의 값을 계속 반환, 트랜잭션 외 데이터 변경이 실시간 반영되지 않음.

추가 실험

• 동일 조건 반복 조회에서 신규 데이터 삽입 (PHANTOM READ) 여부, Gap Lock 영향도 실습 가능.

실습 예제: MySQL InnoDB—RR 에서 팬텀 차단 (Next-Key)

목적

• RR + 인덱스 조건에서 삽입 팬텀 차단 동작 관찰

사전 요구사항

• MySQL 8.0+/8.4+, InnoDB, 테스트 DB 권한

단계별 구현

1. 스키마/데이터 준비

   1 2 3 4 5 6

   CREATE TABLE orders ( id BIGINT PRIMARY KEY AUTO_INCREMENT, amount INT NOT NULL, KEY idx_amount (amount) ) ENGINE=InnoDB; INSERT INTO orders(amount) VALUES (10),(12),(15);

2. 세션 1(T1)

   1 2 3 4 5

   SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ; START TRANSACTION; -- 인덱스 범위를 스캔하여 next-key 잠금 설정 SELECT COUNT(*) FROM orders WHERE amount BETWEEN 10 AND 15; -- 결과: 3 -- 커밋 전까지 유지

3. 세션 2(T2)

   1 2 3 4

   SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ; START TRANSACTION; -- 잠금된 범위(10.)에 삽입 시도 → 대기 또는 타임아웃 INSERT INTO orders(amount) VALUES (11); -- 잠금 대기/타임아웃 발생 가능

4. 세션 1 커밋 후 세션 2 진행

   1	COMMIT; -- T1 커밋되면 T2 진행/커밋 가능

실행 결과/검증

• T2 의 INSERT 는 T1 커밋 전까지 대기 (또는 타임아웃). RR+ 인덱스 +Next-Key 로 팬텀 차단됨.

실습 예제: PostgreSQL—RR(Snapshot) 에서 Write Skew 시연

목적

• 스냅샷형 RR 에서 Write Skew 가능성을 관찰

사전 요구사항

• PostgreSQL 14+/15+/16+, psql 또는 Python(psycopg2)

단계별 구현

1. 스키마/데이터

   1 2 3 4 5 6

   CREATE TABLE oncall ( doctor TEXT PRIMARY KEY, on_duty BOOLEAN NOT NULL ); INSERT INTO oncall VALUES ('A', TRUE), ('B', TRUE); -- 업무 규칙: 최소 1명 이상 on_duty 여야 함 (DB 제약 미설정 상태)

2. T1 과 T2 를 각각 시작 (두 세션 모두 RR)

   1 2 3

   SET TRANSACTION ISOLATION LEVEL REPEATABLE READ; -- 양 세션 동일 BEGIN; SELECT COUNT(*) FROM oncall WHERE on_duty = TRUE; -- 각자 2를 관측 (동일 스냅샷)

3. 동시 갱신

   1 2 3 4

   -- T1 UPDATE oncall SET on_duty = FALSE WHERE doctor = 'A'; -- T2 UPDATE oncall SET on_duty = FALSE WHERE doctor = 'B';

4. 순차 커밋 (충돌 없이 모두 커밋될 수 있음)

   1 2	COMMIT; -- T1 COMMIT; -- T2

5. 결과 확인

   1	SELECT COUNT(*) FROM oncall WHERE on_duty = TRUE; -- 0 (업무 규칙 위배)

완화 실습

1
2
3
4
5

-- 체크 제약 또는 직렬화 사용
ALTER TABLE oncall ADD CONSTRAINT at_least_one CHECK (
  (SELECT COUNT(*) FROM oncall WHERE on_duty) >= 1
) NOT VALID; -- 정책에 맞게 구현(실무에선 트리거/락 사용 권장)
-- 또는 SERIALIZABLE 격리로 재시도 패턴 적용

실습 예제: Python(psycopg2) 로 RR/SSI 비교 (요지)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

# 목적: PostgreSQL에서 RR vs SERIALIZABLE 충돌/재시도 동작 비교
# 필요: psycopg2, PostgreSQL 접속 권한
import threading, time
import psycopg2

DSN = "dbname=test user=postgres password=postgres host=127.0.0.1"

def run(level, doctor):
    conn = psycopg2.connect(DSN)
    conn.autocommit = False
    cur = conn.cursor()
    cur.execute(f"SET TRANSACTION ISOLATION LEVEL {level}")
    cur.execute("BEGIN")
    cur.execute("SELECT COUNT(*) FROM oncall WHERE on_duty")
    print(level, doctor, "count=", cur.fetchone()[0])
    cur.execute("UPDATE oncall SET on_duty=FALSE WHERE doctor=%s", (doctor,))
    time.sleep(1)
    try:
        conn.commit()
        print(level, doctor, "COMMIT OK")
    except Exception as e:
        print(level, doctor, "COMMIT FAIL:", e)
        conn.rollback()
    finally:
        cur.close(); conn.close()

# 준비: oncall 테이블/데이터는 예제 B와 동일
for iso in ["REPEATABLE READ", "SERIALIZABLE"]:
    # 초기화는 생략(실무에선 각 라운드 전 데이터 리셋)
    t1 = threading.Thread(target=run, args=(iso, 'A'))
    t2 = threading.Thread(target=run, args=(iso, 'B'))
    t1.start(); t2.start(); t1.join(); t2.join()

예상: RR 에선 두 커밋 모두 성공 가능 (쓰기왜곡), SERIALIZABLE(SSI) 에선 한 트랜잭션이 충돌로 롤백될 수 있음 → 재시도 필요.

실제 도입 사례 분석

실제 도입 사례: 결제/계좌 관리 시스템

배경 및 도입 이유

• 실거래 결제, 계좌 잔액 등의 비즈니스 트랜잭션에서 데이터 변동이 발생할 경우 금전적 오류 방지 목적으로 Repeatable Read 적용.

구현 아키텍처

graph TD
    U[사용자 요청] --> S[애플리케이션 서버]
    S --> DB
    DB --> T["트랜잭션 매니저 (MVCC 구현)"]
    T --> UL[언두 로그]

• 트랜잭션 매니저가 각 쿼리마다 스냅샷 관리, 언두 로그로 반복 조회 값 고정.

핵심 구현 코드

1
2
3
4
5
6

# Python 예제: Repeatable Read 트랜잭션 시나리오 (MySQL connector)
conn.start_transaction(isolation_level='REPEATABLE READ')
price1 = conn.execute('SELECT price FROM products WHERE id=100').fetchone()
# 외부세션에서 price 데이터는 45000으로 변경
price2 = conn.execute('SELECT price FROM products WHERE id=100').fetchone()
# price1, price2 모두 50000 반환

성과 및 결과

• 데이터 정합성 확보, 사용자의 예기치 않은 잔액 오류/실적 오류 예방
• 운영 안정성 증가 및 동시성 처리 효율도 상승

교훈 및 시사점

• Gap Lock, 트랜잭션 관리 전략에 따른 성능/일관성 Trade-off 관리 필수
• 대규모 배치·집계 환경에서 팬텀 리드/쓰기 충돌에 대한 명확한 운영 설계 필요.

실제 도입 사례 분석—전자상거래 재고 중복 방지

배경/이유

• ’ 수량 1’ 한정 상품 동시 결제 시 중복 판매 방지.

아키텍처

graph TB
  API[Checkout API] --> SVC[Order Service]
  SVC --> DB[(RDBMS: InnoDB RR)]
  SVC --> Q[Outbox/Event Bus]
  DB --> INV[Inventory Table]

• 구현 요지: RR + SELECT … FOR UPDATE 로 대상 행 잠금 → 주문 레코드 삽입 → 결제 승인 → 커밋. 실패 시 롤백/재시도.

핵심 코드 (의사 예시)

1
2
3
4
5
6

START TRANSACTION;
SELECT quantity FROM inventory WHERE sku=? FOR UPDATE; -- 행 잠금
-- 수량 확인 후 감소
UPDATE inventory SET quantity = quantity - 1 WHERE sku=? AND quantity > 0;
INSERT INTO orders(order_id, sku, …) VALUES (…);
COMMIT;

성과

• 중복 판매 0 건, 대기 시간 평균 +5~15ms 증가 (잠금 경합), 실패 재시도율 < 1%.

교훈

• 인덱스 정합(SKU PK/Unique) 과 짧은 트랜잭션이 효과적. 관측 지표 (락 대기/타임아웃) 로 상시 튜닝.

최종 정리 및 학습 가이드

내용 종합

Repeatable Read 는 트랜잭션이 같은 데이터를 반복 조회할 때 결과를 고정함으로써 읽기 일관성을 보장하는 격리 수준이다.
일반적으로 MVCC(다중 버전 동시성 제어) 와 언두/버전 로그를 통해 구현되며, 이를 통해 Dirty Read 와 Non-Repeatable Read 를 차단한다.
그러나 팬텀 (read-range 변화) 에 대한 처리 수준은 데이터베이스 엔진에 따라 달라지므로, 팬텀 완전 차단이 필요하면 더 높은 격리 (Serializable) 나 추가적인 락 전략을 선택해야 한다.
실무에서는 RR 을 적용할 때 인덱스/트랜잭션 설계, 장기 트랜잭션의 영향 관리, 재시도와 보상 로직 설계, 그리고 스냅샷·락 관련 메트릭을 모니터링하는 것이 필수적이다.

실무 적용 가이드

학습 로드맵

학습 항목 정리

용어 정리

참고 및 출처

• 트랜잭션 격리 수준 완벽 가이드: 실무에서 만나는 문제와 해결법
• REPEATABLE READ는 어떻게 구현되는가? (feat. MVCC)
• [MySQL] 트랜잭션의 격리 수준(Isolation Level)에 대해 쉽고 완벽하게 이해하기 - MangKyu’s Diary
• RepeatableRead 에서 발생할 수 있는 동시성 문제와 락
• [MySQL] REPEATABLE READ vs SERIALIZABLE 차이 완전분석
• Achieve a high-speed InnoDB purge on Amazon RDS for MySQL and Amazon Aurora MySQL (AWS Tech Blog)
• KCSE2022 proceedings v5 (한국소프트웨어공학 학술대회 논문집)
• 데이터베이스 설계 및 최적화 (CDragon)
• PostgreSQL: Transaction Isolation
• PostgreSQL: SET TRANSACTION
• MySQL :: InnoDB Locking
• MySQL :: Transaction Isolation Levels
• Microsoft Learn: SET TRANSACTION ISOLATION LEVEL (Transact-SQL)
• Oracle Database: Data Concurrency and Consistency (11g Release 2)
• A Critique of ANSI SQL Isolation Levels (Berenson et al., 1995) — PDF
• ODBC: Transaction Isolation Levels (Microsoft Learn)
• Cockroach Labs: SQL Isolation Levels Explained