Read Committed

Read Committed

Read Committed(읽기 커밋) 는 실무에서 널리 쓰이는 기본 격리 수준으로, 항상 커밋된 데이터만 읽게 해 Dirty Read 를 차단한다.
다만 트랜잭션 내 여러 문장은 서로 다른 시점의 커밋 상태를 볼 수 있어 Non-repeatable Read 와 Phantom이 발생할 수 있다.
내부 구현은 DB 마다 달라 (PostgreSQL/Oracle 은 MVCC 스냅샷 기반, SQL Server 는 기본 락 기반에 RCSI 옵션 존재) 동일 명칭이라도 동작이 다르므로 DB 별로 테스트·검증해야 한다.

일반 웹·OLTP 는 Read Committed 가 성능·정합성의 균형이지만, 회계·결제 등 강한 일관성이 필요한 도메인에서는 Repeatable Read 나 Serializable 을 사용하는 것이 추천된다.
운영 시 장기 트랜잭션 회피, 락 대기·데드락 모니터링, 읽기 풀 설계로 위험을 완화하는 것이 추천된다.

Read Committed 핵심 개념과 실무 적용

Read Committed 는 많은 상용 DB 에서 기본으로 쓰이는 격리 수준으로, **" 각 쿼리는 그 순간 커밋된 값만 본다 “**는 규칙을 따른다.
이로써 **Dirty Read(미커밋 데이터 읽기)**는 차단되어 실무 데이터 신뢰성이 보장되지만, 같은 트랜잭션 내에서 반복 조회를 하면 값이 바뀔 수 있다 (Non-repeatable) 거나, 조건에 맞는 행 수가 달라질 수 있다 (Phantom).

성능과 정합성의 균형점으로 대부분 OLTP 에 적합하다.

RC 는 실용적 균형을 제공하므로 대부분의 OLTP 에서 기본이 된다.
핵심은 비즈니스 요구에 맞춰 " 어떤 이상현상을 허용할 것인가 " 를 명확히 하는 것.

개념 상호관계 매핑표

관계는 대부분 정책 (격리 수준) → 구현 (MVCC/락) → 결과 (허용/차단되는 이상현상) 구조로 이해하면 실무 설계에 적용하기 쉽다.

관계 다이어그램

flowchart LR
  A[Client] -->|SQL| T[Transaction]
  T -->|READ| V[Visibility Rules]
  V -->|MVCC Snapshot or S-Lock| D[(Data Pages)]
  T -->|WRITE| L[Locking / Row Versions]
  L --> D
  D -->|Commit| C[Durability]

핵심 개념의 실무 적용 매핑

실무 적용은 **DB 특성 (엔진 별 동작)**과 **애플리케이션 프레임워크 (ORM)**의 조합으로 결정된다. 운영 시 장기 트랜잭션·GC·데드락·롤백률을 면밀히 관찰해야 한다.

기초 조사 및 개념 정립

Read Committed—개념·실무 적용

• 무엇을 보장하나?:
  한 SQL 문이 실행될 때 그 시점에 커밋된 값만 읽도록 보장한다.

• 무엇을 막나?:
  아직 커밋되지 않은 (임시) 값은 읽지 못하므로 Dirty Read 를 막는다.

• 무엇이 남나?:
  같은 트랜잭션에서 두 번 읽으면 값이 바뀔 수 있다 (다른 트랜잭션이 사이에 커밋했기 때문).

• 언제 쓸까?:
  대부분의 OLTP 에서 기본값으로 널리 사용—성능과 일관성의 현실적 절충.

• 주의점:
  장기 트랜잭션이나 다단계 검증이 필요한 로직 (예: 잔액 확인→결제) 에는 더 강한 격리 (또는 애플리케이션 레벨 보정) 가 필요.

Read Committed(읽기 커밋) 는 각 SQL 문이 실행되는 시점의 커밋된 스냅샷을 읽도록 보장하는 격리 수준이다.
이는 트랜잭션 간의 Dirty Read 를 방지하여 기본적인 데이터 정합성을 확보하면서도, 문 수준에서 최신성을 확보하기 때문에 성능과 동시성 측면에서 합리적인 선택지다.
다만 트랜잭션 내에서 반복 조회 시 다른 트랜잭션의 커밋에 의해 값이 변할 수 있으므로 (Non-repeatable Read), 반복적 비교나 복합 검증을 요구하는 로직에는 Snapshot Isolation 혹은 Serializable 사용을 권장한다.
또한 DBMS 별 구현 (락 기반 vs MVCC, row-versioning 옵션) 에 따라 동작·성능이 달라지므로 적용 전 확인·테스트가 필요하다.

Read Committed: 기원·진화·실무 포인트

• 무엇인가?
  Read Committed 는 다른 트랜잭션이 아직 커밋하지 않은 변경 (미확정) 을 읽지 못하게 하여 Dirty Read 를 방지하는 격리 수준.

• 왜 쓰나?
  락으로 인한 심한 대기 없이도 기본적인 일관성을 보장하려는 현실적 타협.

• 무엇이 변했나?
  초기 락 기반 구현에서 MVCC 기반의 ’ 쿼리 시점 스냅샷 ’ 구현으로 발전하여 읽기 성능을 개선.

등장 배경

복수 사용자가 동시에 데이터에 접근하는 환경에서 읽기 작업이 쓰기 작업의 잠금 때문에 지연되면 전체 처리량과 응답성이 저하된다.
실무에서 ’ 어느 정도의 일관성은 유지하되 지나친 동시성 비용은 피하자 ’ 는 요구가 커지자 SQL 표준과 DB 벤더들은 Dirty Read 를 차단하면서도 읽기 지연을 완화하는 Read Committed를 도입·보급했다.
이후 MVCC 의 도입으로 Read Committed 는 읽기 비차단 (스냅샷) 방식으로 개선되어 대다수 엔진에서 널리 쓰이게 되었다.

발전 과정

gantt
  dateFormat  YYYY
  title Read Committed 발전 타임라인
  1970s-1980s :a1, 1975, 1989
  1992       :a2, 1992, 1992
  1995-2005  :a3, 1995, 2005
  2005-2025  :a4, 2005, 2025

  section 사건
  락기반 RDBMS와 성능문제         :a1, 1975, 1989
  SQL-92 격리 수준 표준화       :a2, 1992, 1992
  MVCC 보급 및 스냅샷 구현 확산  :a3, 1995, 2005
  벤더별 최적화·기본 설정 확립  :a4, 2005, 2025

Read Committed 는 ’ 읽기 지연을 줄이되 Dirty Read 는 방지 ’ 라는 목표로 등장했고, MVCC 의 보급으로 읽기 비차단 (스냅샷 기반) 형태로 진화했다.
오늘날 대부분의 DB 엔진은 Read Committed 를 지원하거나 그에 상응하는 동작을 제공하지만, 엔진별 세부 동작과 기본값이 다르므로 적용 전 검증이 필수다.
운영 환경에서는 Read Committed 가 제공하는 일관성 범위 (커밋 시점 일관성) 를 이해하고, 재조회 시 값이 달라질 수 있음을 설계에 반영해야 한다.

Read Committed: 실무적 문제·목적 정리

Read Committed 는 데이터베이스의 격리 수준 중 하나로, 읽을 때 오직 이미 커밋된 데이터만 볼 수 있게 보장한다.
이것으로 미커밋 데이터 (Dirty data) 를 읽어 발생하는 잘못된 집계나 의사결정 문제를 막을 수 있다.
다만 트랜잭션 내에서 같은 쿼리를 다시 실행하면 결과가 달라질 수 있으니 (Non-repeatable read) 재현성 (동일 트랜잭션에서의 반복 일관성) 이 중요한 작업에는 더 강한 격리 수준을 선택해야 한다.
또한 DB 엔진별 구현 차이를 반드시 확인해야 한다 (예: PostgreSQL 의 특성).

Read Committed 이 해결하는 문제들

Read Committed 는 **미커밋 데이터 노출이 가져오는 직접적 위험들 (잘못된 집계, 의사결정, 롤백 후 불일치)**을 차단하는 데 집중한다. 이를 통해 운영 안정성을 높이되, 반복 읽기 일관성까지 보장하지는 않으므로 필요에 따라 더 높은 격리가 요구된다.

Read Committed 의 핵심 목적

핵심 목적은 **정확성 (Dirty Read 방지)**과 성능 (동시성 확보) 사이의 실무적 절충을 제공하는 것이다. OLTP 에서 흔히 채택되는 이유는 _ 충분한 일관성 _ 을 보장하면서도 _ 높은 처리량 _ 을 잃지 않기 때문이다.

문제와 목적의 연관성 맵

각 문제는 Read Committed 가 제공하는 핵심 목적 (정확성 확보·운영 안정성·성능 균형) 과 직접적으로 연결된다. 즉, 문제 해결 (Dirty Read 차단) 은 곧 핵심 목적 (신뢰성 확보) 에 기여하며, 동시에 시스템은 더 높은 격리 수준 대비 성능을 유지한다. 다만 Non-repeatable/Phantom 같은 다른 이상현상은 별도 대책이 필요하다.

격리 적용을 위한 필수 전제조건

Read Committed 를 안전하게 쓰려면 네 가지가 준비되어야 한다.

1. DB 가 커밋 상태를 판별할 수 있는 저장·버전 메커니즘 (undo/redo 또는 MVCC) 이 있어야 한다.
2. 격리 수준을 세션 혹은 트랜잭션 단위로 설정할 수 있어야 해서 특정 쿼리만 RC 로 돌릴 수 있어야 한다.
3. 인덱스·통계 등 튜닝이 되어야 불필요한 스캔으로 락이 오래 걸리는 문제를 줄일 수 있다.
4. 운영 정책 (누가 변경 권한을 가지는지) 과 모니터링 (롱 트랜잭션·버전 bloat 감시) 을 갖춰야 안정적으로 운영할 수 있다.

Read Committed 적용 필수요건표

• Read Committed 를 안전하게 운영하려면 기술 (저장·버전), 설계 (트랜잭션 길이·인덱스), 그리고 운영 (권한·모니터링) 세 축이 모두 준비되어야 한다. 특히 엔진별 동작 차이는 실무 영향이 크므로 적용 전 엔진 문서 확인과 테스트 재현이 필수다.

Read Committed: 본질·근거·실무

Read Committed 는 항상 커밋된 데이터만 읽는 격리 수준으로, Dirty Read 를 차단해 일상적 데이터 왜곡을 막는다.
그러나 각 SQL 문장은 그 시점의 최신 커밋 상태를 참조하므로 같은 트랜잭션 내에서 값이 달라질 수 있어 Non-repeatable Read 나 Phantom 이 발생할 수 있다.
많은 RDBMS 에서 기본값으로 사용되며, 성능과 일관성의 균형이 필요한 웹·OLTP 에서 적합하지만 회계·정산처럼 강한 일관성이 필요한 곳에서는 상위 격리를 선택해야 한다.
DB 별 구현 (MVCC vs 락 기반) 에 따라 동작 차이가 있으니 실제 환경에서 검증하는 것이 필요하다.

Read Committed 특징 정리표

Read Committed 는 실무에서 가장 현실적인 균형점이다. 핵심은 Dirty Read 를 막으면서도 트랜잭션 내부 일관성 (Repeatability) 은 보장하지 않는다는 점이며, MVCC 와 락 기반 엔진 간 구현 차이가 실제 동작과 성능에 큰 영향을 준다. 따라서 기본값으로서 적합하지만, 민감 도메인은 상위 격리를 적용해야 한다.

핵심 원리 및 이론적 기반

Read Committed 원칙·철학 완전정리

Read Committed 는 커밋된 데이터만 읽는다는 간단한 규칙을 따라 Dirty Read 를 차단하면서도, 각 SQL 문장 실행 시점의 최신 커밋 상태를 읽도록 하는 격리 수준이다.
즉, 트랜잭션 내에서 같은 쿼리를 반복하면 다른 트랜잭션의 커밋 때문에 결과가 달라질 수 있다 (Non-repeatable/Phantom 허용).
이 방식은 데이터 무결성은 확보하면서도 성능을 지나치게 희생하지 않는 실무적 균형을 제공하므로 대부분의 OLTP 에서 기본값으로 쓰인다.
적용 시에는 DB 엔진별 동작 차이를 이해하고, 범위·모니터링·검증 정책을 준비하는 것이 핵심이다.

핵심 원칙 요약표

핵심 원칙은 **정확성 (Dirty Read 차단)**과 실용성 (문장 단위로 성능 보전) 사이의 균형을 직접 규정한다. 이 두 원칙이 RC 의 동작과 실무 장점을 설명한다.

설계 철학 요약표

설계 철학은 RC 를 ’ 왜 ’ 선택하는지 (비즈니스 목표) 와 ’ 어떻게 ’ 적용할지 (운영 정책) 를 규정한다. 단순 기술 결정이 아니라 조직·운영 정책과 연결되는 의사결정 프레임워크를 제공하는 것이 핵심이다.

Read Committed: 원리·흐름도

• 문장 단위 스냅샷: Read Committed 는 각 SQL 문이 시작될 때 해당 문이 읽을 ’ 커밋된 상태 스냅샷 ’ 을 결정한다. 이는 MVCC 기반 DB 에서 주로 사용되는 방식이며, 읽으려는 시점에 커밋된 버전만 볼 수 있게 한다.

• 가시성 규칙: 읽기 작업은 문 시작 시점의 commit flag 에 따라 버전을 선택한다. 따라서 다른 트랜잭션이 문 이후에 커밋한 변경은 다음 문에서 보이지만, 현재 문에서는 보이지 않는다.

• 락 기반 예외: 일부 RDBMS(예: SQL Server 기본) 는 읽기 시 공유락을 잡아 쓰기 트랜잭션을 블로킹해 동일한 효과 (Dirty Read 차단) 를 달성한다. 이 경우는 블로킹과 성능 영향이 크다.

• Non-repeatable / Phantom 가능: 문 단위 스냅샷 때문에 트랜잭션 내 반복 조회 시 값이 달라질 수 있고 (Non-repeatable), 반복되는 집계범위가 바뀌어 Phantom 이 발생 가능.

• Undo/Redo 와 상호작용: MVCC 는 변경 전 값 (또는 이전 버전) 을 유지 (undo/version store) 해 문 시점의 결과를 재구성한다. Read Committed 가 " 로그가 없음 " 을 의미하지는 않음.

• 실무 권장: 반복 읽기 불변이 필요한 경우 Snapshot Isolation 또는 Serializable 을 고려하고, 읽기 전용 복제본을 사용해 리포팅 부하를 분리하라.

Read Committed 메커니즘 요약표

Read Committed 는 문장 단위의 일관성 강화를 통해 Dirty Read 를 차단하면서도 시스템에 따라 버전 (Non-blocking) 또는 락 (블로킹) 기반으로 동작한다. 결과적으로 속도와 정합성의 균형을 제공하지만 트랜잭션 내부 반복 읽기에서의 값 변화 (Non-repeatable) 와 팬텀을 허용하므로, 필요한 경우 더 강한 격리로 보완해야 한다.

Read Committed 동작 흐름도 (분기)

sequenceDiagram
  participant T1 as "T1 (Writer)"
  participant DB as "DB Engine"
  participant T2 as "T2 (Reader)"

  T1->>DB: BEGIN
  T1->>DB: UPDATE item SET stock = 0 WHERE id = 1
  Note over DB: 변경 생성 → 버퍼/undo 버전 생성

  alt DB uses MVCC (versioning)
    T2->>DB: BEGIN
    T2->>DB: SELECT …  // 문 시작 시 스냅샷 생성
    Note over DB: statement-level read view(문 시점의 커밋된 버전)
    DB-->>T2: 반환값 = (이전 커밋값)
    T1->>DB: COMMIT
    Note over DB: 변경이 커밋되어 이후 문에서 보임
  else DB uses Lock-based (shared locks)
    T2->>DB: BEGIN
    T2->>DB: SELECT …  // 공유락 시도
    Note over DB: SELECT는 shared lock 획득 시도 → Writer의 X-lock이 있으면 블로킹
    DB-->>T2: (blocked until Writer COMMIT/ROLLBACK)
    T1->>DB: COMMIT
    DB-->>T2: shared lock granted → SELECT returns committed value
  end

• MVCC 는 문 시작 시 스냅샷 생성 → 그 스냅샷에 따라 값 반환하는 흐름이며, 이 경우 Reader 는 Writer 의 미커밋 변경을 보지 못한다. Writer 가 COMMIT 하면 그 변경은 다음 문에서 보이게 된다.

• 락 기반는 Reader 의 SELECT 가 공유락을 획득하려 할 때 Writer 가 이미 배타적 락을 가진 상황이면 Reader 가 블로킹되어 Writer 가 COMMIT/ROLLBACK 할 때까지 대기한다. 이로 인해 Dirty Read 는 방지되지만 블로킹과 성능 저하가 발생할 수 있다.

• 이 흐름은 DB 종류와 설정 (RCSI 등) 에 따라 달라지므로, 운영 환경에 맞춰 분기 중 해당 케이스를 선택해 이해해야 한다.

Read Committed: 흐름·생명주기·실무포인트

• 트랜잭션을 시작한 후 SELECT 할 때마다 DB 는 그 순간 커밋된 최신값을 보여준다.
• 만약 다른 트랜잭션이 중간에 값을 바꾸고 커밋하면, 다음 SELECT 에서 그 변경이 보인다.
• 장점: Dirty Read 차단, 높은 동시성.
• 단점: 같은 트랜잭션 내에서 값이 바뀔 수 있으니 재조회할 때 주의해야 함.

RC 의 문단위 가시성 설명

핵심 흐름 (문장 단위)

1. 문 시작 → DB 는 그 문에 대한 **가시성 기준 (스냅샷 또는 락 판정)**을 확보.
2. 읽기 수행 → 커밋된 버전만 스캔하여 결과 반환 (미커밋 변경은 숨김).
3. 문 종료 → 해당 문 단위의 스냅샷 폐기 또는 공유 락 해제.
4. 트랜잭션이 계속되는 동안 다음 문은 새 가시성 기준으로 다시 평가되므로 이전 문에서 보지 못한 커밋이 이후 문에서 보일 수 있다.

Read Committed 데이터 흐름표

표는 RC 의 핵심: 각 문은 그 문이 시작될 때의 커밋 상태만 본다는 점을 단계별로 정리한 것이다. 적용 시 엔진별 구현 (락 기반 vs MVCC statement-snapshot) 을 확인하고, 같은 트랜잭션 내 재조회 불일치에 대해 애플리케이션 레벨에서 대비하라.

RC 문단위 가시성 흐름도

flowchart LR
  Start[트랜잭션 시작] --> S1[문1 시작: 스냅샷/락 획득]
  S1 --> Q1[문1: SELECT -> 커밋된 값 반환]
  Q1 --> End1[문1 종료: 스냅샷 폐기/락 해제]
  End1 --> S2[문2 시작: 새 스냅샷/락 판정]
  S2 --> Q2{다른 트랜잭션이 커밋했나?}
  Q2 -- 아니오 --> Q2a[문2: 이전 값 반환]
  Q2 -- 예 --> Q2b[문2: 커밋된 새 값 반환]
  Q2a & Q2b --> End2[문2 종료]
  End2 --> Continue[트랜잭션 계속/종료]

이 흐름도는 한 트랜잭션 내에서 각 문 (statement) 이 시작될 때마다 새 가시성 판단을 거쳐 커밋된 값을 읽는다는 RC 의 핵심을 시각화한다. 다른 트랜잭션이 중간에 커밋하면 다음 문에서 그 변경이 보이며, 그렇지 않으면 이전 값이 유지된다.

RC 트랜잭션 생명주기

stateDiagram-v2
    [*] --> Active: 트랜잭션 시작
    Active --> Statement: 문 시작 (스냅샷/락 획득)
    Statement --> Read: SELECT 수행 (커밋 버전 스캔)
    Read --> EndStatement: 문 종료 (스냅샷 폐기/락 해제)
    EndStatement --> Decision: 트랜잭션 계속?
    Decision --> Statement: 문 시작
    Decision --> Commit: COMMIT
    Decision --> Rollback: ROLLBACK
    Commit --> [*]
    Rollback --> [*]

이 상태도는 트랜잭션이 문 (statement) 을 시작 → 읽기 수행 → 문 종료 패턴을 반복하다가 최종적으로 COMMIT/ROLLBACK 으로 종료되는 생명주기를 보여준다. RC 에서는 각 문이 독립적으로 가시성을 평가하므로 동일 트랜잭션 내에서도 문마다 다른 커밋 상태를 반영할 수 있다.

특성 분석 및 평가

Read Committed: 장점·실무적 가치

Read Committed 는 읽을 때마다 ’ 확정된 ‘(커밋된) 데이터만 보여줘서 잘못된 (미확정) 값을 읽는 위험을 없애고, 동시에 읽기 작업을 차단하지 않아 많은 사용자가 동시에 조회할 때 처리량을 높여준다.
즉, ’ 데이터 신뢰성 (Dirty Read 차단)’ 과 ’ 실무적 성능 (높은 동시성)’ 사이에서 균형을 맞춘 현실적 선택이다.
하지만 동일 트랜잭션 내에서 값이 바뀔 수 있으니 (재조회 불일치) 중요 연산에는 적절한 보완이 필요하다.

Read Committed 장점 요약표

표는 RC 가 어떤 기술 메커니즘(MVCC/락) 으로 동작하는지와, 그 결과로 **운영에서 어떤 개선 (신뢰도·처리량·예측 가능성·도입 용이성)**을 기대할 수 있는지를 요약한다. 현실적으로는 워크로드 특성 (읽기 비율, 트랜잭션 길이, 핫스팟 유무) 에 따라 효과의 크기가 달라지므로, 실제 적용 전 성능 측정과 재조회 불일치 (Non-repeatable Read) 에 대한 애플리케이션 보호 방안 (재검증·낙관적 재시도 등) 을 준비해야 한다.

Read Committed 의 한계·운영 대비체계

Read Committed 는 미커밋 데이터 (Dirty Read) 를 차단해 일상적인 OLTP 에서 안정적인 읽기를 제공한다.
다만 트랜잭션 전체의 재현성 (같은 트랜잭션 내에서 여러 번 읽었을 때 항상 같은 결과) 은 보장하지 못한다 (Non-Repeatable, Phantom). 따라서 보고·회계처럼 재현성이 필수인 작업은 더 강한 격리 수준이나 스냅샷 기반 리포트로 분리해야 한다.
실무에서는 문제 범위를 좁히고 (테이블·쿼리 화이트리스트), DB 별 동작을 테스트 후 적절한 완화책을 적용하는 것이 안전한 접근 방식이다.

Read Committed 단점 개요표

단점들은 RC 자체의 설계 한계에서 비롯된다. 운영상 영향은 **재현성 결여 (회계/감사 위험)**와 **범위 질의 불안정 (집계/페이징 문제)**이며, 해결책은 필요 수준에 맞춰 격리 수준 상향 또는 아키텍처 (리플리카/스냅샷) 분리로 보통 처리한다.

Read Committed 제약사항 개요표

제약사항은 환경·정책·엔진 특성에서 발생하므로 시스템 설계 단계에서 요구사항 (정확성·성능·규제) 을 바탕으로 격리 수준 정책을 수립하고, DB 별 특성을 반영한 운영 매뉴얼을 만들어야 한다.

RC 트레이드오프·혼합 전략 안내

Read Committed 는 " 커밋된 데이터만 읽게 해서 더티 리드는 막지만, 같은 트랜잭션에서 반복해서 읽을 때 값이 바뀔 수는 있는 " 중간 수준의 격리다.
장점은 빠른 응답과 높은 동시성, 단점은 일부 일관성 문제가 남는 것이다.
실무에서는 중요한 결정 (결제·정산) 경로엔 더 높은 격리를 쓰고, 대시보드·로그처럼 정확도가 덜 중요한 읽기에는 RC 를 적용하는 식으로 균형을 맞춘다.

Read Committed 주요 선택별 트레이드오프

• 핵심은 비즈니스 민감도(금전/상태 변경 여부) 와 성능 목표 (p95/p99) 를 기준으로 선택하는 것.
• 대부분 시스템은 전역 한가지만 택하지 않고 핵심 경로는 상향 격리, 나머지는 RC/Replica 기반으로 하이브리드 운영한다.

RC 완화용 하이브리드 패턴 비교표

• 하이브리드 패턴들은 RC 의 성능 장점은 살리고 결정적 경로의 일관성은 보장하도록 설계된 현실적 방법들이다.
• 선택은 비즈니스 위험도, 허용 가능한 지연 (신선도), 개발·운영 복잡도를 저울질해 결정해야 한다.

Read Committed 적용성·운영 전략

Read Committed 는 항상 커밋된 데이터만 읽어 Dirty Read 를 방지하면서도, 트랜잭션 내부 여러 문장 사이의 값 일관성은 보장하지 않는다.
그래서 웹 UI 조회·OLTP 처럼 성능과 합리적 정합성의 균형이 필요한 곳에 적합하다. 반면 회계·정산·재고처럼 같은 트랜잭션 내 반복 읽기 일관성이 필수인 도메인엔 부적합하다.
실무에서는 읽기 전용 풀, CQRS, 결과 재검증, 모니터링·자동격상 같은 설계·운영 가드레일을 결합해 리스크를 관리한다.

Read Committed 적용 적합성 표

• Read Committed 는 UI·일반 OLTP·로그/프로젝션 등 대다수 읽기 시나리오에 적합하지만, 금융/정산/재고 같은 동일 트랜잭션 반복 읽기가 요구되는 도메인에는 부적합하다.
• 적용 시엔 **설계 (읽기 풀/CQRS), 분석 (성능·일관성 지표 측정), 운영 (모니터링·자동격상)**의 삼중 방어선으로 리스크를 관리하라.

DB 별 Read Committed 동작 비교

• 모두 Dirty Read 는 차단한다.
• 차이점은 ’ 어떻게 ’ 차단하는지 (락 vs 버전관리) 와 성능·블로킹 특성:
  • Postgres / Oracle / MySQL(RC) → MVCC/문 수준 스냅샷 (읽기 블로킹 거의 없음, 같은 트랜잭션 내 Non-repeatable 발생).
  • SQL Server 기본 RC → 락 기반 (읽기 시 공유락) 으로 쓰기와 충돌 시 블로킹 발생; RCSI 켜면 row-versioning 동작으로 블로킹 완화.

PostgreSQL (psql)—재현 스크립트

준비 (한 번만)

1
2
3
4
5

-- psql로 접속 후
CREATE TABLE item (id serial PRIMARY KEY, stock int);
INSERT INTO item(stock) VALUES (10);
-- 확인
SELECT * FROM item;

시나리오 1: Dirty Read 방지 (T1: Writer, T2: Reader)

T1 (세션 A):

1
2
3

BEGIN;
UPDATE item SET stock = 0 WHERE id = 1;
-- 아직 COMMIT 하지 않음

T2 (세션 B):

1
2
3
4

-- 기본이 Read Committed인 경우
BEGIN;
SELECT stock FROM item WHERE id = 1;  -- 결과: 10 (원래 커밋된 값) -> Dirty Read가 발생하지 않음
COMMIT;

T1 (세션 A):

1

ROLLBACK;

시나리오 2: Non-repeatable Read (T1 가 두 번 읽는 케이스)

T1 (세션 A):

1
2
3

BEGIN;
SELECT stock FROM item WHERE id = 1;  -- A1: 10
-- **다른 세션에서 커밋된 변경이 발생하면**

T2 (세션 B):

1
2
3

BEGIN;
UPDATE item SET stock = 5 WHERE id = 1;
COMMIT;

T1 (세션 A):

1
2

SELECT stock FROM item WHERE id = 1;  -- A2: 5  (값 변경 확인 -> Non-repeatable Read)
COMMIT;

시나리오 3: Phantom Read (간단)

T1 (세션 A):

1
2

BEGIN;
SELECT count(*) FROM item WHERE stock > 0;  -- e.g., 1

T2 (세션 B):

1
2
3

BEGIN;
INSERT INTO item(stock) VALUES(7);
COMMIT;

T1 (세션 A):

1
2

SELECT count(*) FROM item WHERE stock > 0;  -- 값 증가 -> Phantom 발생 가능
COMMIT;

메모: PostgreSQL 은 MVCC 로 동작하므로 Read Committed 의 의미는 " 문장 시점의 커밋된 스냅샷 " 을 보는 것. 위 결과는 그 의미에 부합함.

MySQL (InnoDB)—재현 스크립트

참고: MySQL(InnoDB) 기본 격리 수준은 REPEATABLE READ. Read Committed 로 테스트하려면 세션 또는 글로벌 격리 수준을 변경해야 한다.

준비

1
2
3

-- mysql 클라이언트 접속
CREATE TABLE item (id INT AUTO_INCREMENT PRIMARY KEY, stock INT);
INSERT INTO item(stock) VALUES (10);

세션을 Read Committed 로 설정 (각 세션에서)

1

SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;

Dirty Read 방지

T1 (세션 A):

1
2
3

START TRANSACTION;
UPDATE item SET stock = 0 WHERE id = 1;
-- 아직 COMMIT 없음

T2 (세션 B):

1
2
3
4

SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;
START TRANSACTION;
SELECT stock FROM item WHERE id = 1; -- 결과: 10 (커밋된 값) -> Dirty Read 없음
COMMIT;

T1 (세션 A):

1

ROLLBACK;

Non-repeatable Read

T1 (세션 A):

1
2
3

SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;
START TRANSACTION;
SELECT stock FROM item WHERE id = 1; -- 10

T2 (세션 B):

1
2
3
4

SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;
START TRANSACTION;
UPDATE item SET stock = 5 WHERE id = 1;
COMMIT;

T1 (세션 A):

1
2

SELECT stock FROM item WHERE id = 1; -- 5 (값 변경 관찰)
COMMIT;

Phantom Read

T1 (세션 A):

1
2
3

SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;
START TRANSACTION;
SELECT COUNT(*) FROM item WHERE stock > 0; -- e.g., 1

T2 (세션 B):

1
2
3
4

SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;
START TRANSACTION;
INSERT INTO item(stock) VALUES (7);
COMMIT;

T1 (세션 A):

1
2

SELECT COUNT(*) FROM item WHERE stock > 0; -- 값 증가 -> Phantom
COMMIT;

메모: InnoDB 는 gap-lock 등으로 phantom 을 제어하려는 메커니즘이 있으나, 동작은 격리 수준 및 쿼리 형태에 따라 달라짐. REPEATABLE READ 와 비교해 동작이 다르므로 실제 적용 전 테스트가 필수.

SQL Server (T-SQL)—재현 스크립트

참고: SQL Server 기본은 Read Committed(락 기반). DB 수준에서 READ_COMMITTED_SNAPSHOT 을 ON 으로 하면 Read Committed 가 row-versioning(스냅샷 기반) 으로 동작해 블로킹을 줄임. (설정 전 주의: DB 재기동/활성 연결 처리 필요)

준비

1
2

CREATE TABLE item (id INT IDENTITY PRIMARY KEY, stock INT);
INSERT INTO item(stock) VALUES (10);

기본 Read Committed (락 기반)—Dirty Read 방지

T1 (세션 A):

1
2
3

BEGIN TRAN;
UPDATE item SET stock = 0 WHERE id = 1;
-- 미커밋 상태

T2 (세션 B):

1
2
3
4
5

SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
BEGIN TRAN;
SELECT stock FROM item WHERE id = 1;  -- 블로킹 발생(쓰기가 풀릴 때까지 기다리거나 타임아웃)
-- 즉, Dirty Read 없음(읽기 시 공유락으로 쓰기 차단)
COMMIT;

T1 (세션 A):

1

ROLLBACK TRAN;

Non-repeatable Read

T1 (세션 A):

1
2
3

SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
BEGIN TRAN;
SELECT stock FROM item WHERE id = 1; -- 10

T2 (세션 B):

1
2
3

BEGIN TRAN;
UPDATE item SET stock = 5 WHERE id = 1;
COMMIT;

T1 (세션 A):

1
2

SELECT stock FROM item WHERE id = 1; -- 5  (Non-repeatable)
COMMIT;

Phantom Read

T1 (세션 A):

1
2
3

SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
BEGIN TRAN;
SELECT COUNT(*) FROM item WHERE stock > 0; -- e.g., 1

T2 (세션 B):

1
2
3

BEGIN TRAN;
INSERT INTO item(stock) VALUES (7);
COMMIT;

T1 (세션 A):

1
2

SELECT COUNT(*) FROM item WHERE stock > 0; -- 증가 -> Phantom
COMMIT;

Read Committed Snapshot (RCSI) 예 (옵션)

DB 에 RCSI 를 켜면 읽기 시 버전 기반으로 동작하여 읽기 - 쓰기 블로킹 완화:

1
2

ALTER DATABASE YourDB SET READ_COMMITTED_SNAPSHOT ON;
-- 주의: 변경은 DB에 따라 재기동/활성 연결 영향 있음

메모: RCSI 를 켜면 읽기 시 writer 와 블로킹을 피하고 statement-level snapshot 을 제공하므로 성능/일관성 트레이드오프가 달라짐.

실무 적용 및 사례

실습 예제 및 코드 구현

실습 예제: RC 에서 비반복 읽기/팬텀 관찰 (PostgreSQL)

목적

• RC 의 문장 단위 스냅샷, 비반복/팬텀 현상 체험

사전 요구사항

• PostgreSQL 14+ / psycopg[binary] 3.x / 두 개의 세션 또는 아래 파이썬 스크립트

단계별 구현

1. 스키마 준비

   1 2	CREATE TABLE inv(id int primary key, qty int); INSERT INTO inv VALUES (1, 10), (2, 10);

2. 파이썬 동시 시나리오 (두 커넥션)

   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 33 34 35 36 37

   # pip install psycopg[binary] import psycopg, time DSN = "postgresql://user:pass@localhost:5432/db" # 각 줄 주석으로 RC의 동작을 설명합니다. with psycopg.connect(DSN) as conn1, psycopg.connect(DSN) as conn2: conn1.autocommit = False conn2.autocommit = False with conn1.cursor() as c1, conn2.cursor() as c2: # 세션 1: 트랜잭션 시작 c1.execute("BEGIN;") # 첫 번째 읽기(문장 스냅샷 1) c1.execute("SELECT SUM(qty) FROM inv;") print("T1 sum-1:", c1.fetchone()[0]) # 20 # 세션 2: 다른 트랜잭션에서 업데이트 후 커밋 c2.execute("BEGIN;") c2.execute("UPDATE inv SET qty = qty + 10 WHERE id = 1;") c2.execute("COMMIT;") # 이제부터 새로운 문은 변경을 볼 수 있음 time.sleep(0.5) # 세션 1: 같은 트랜잭션에서 두 번째 읽기(문장 스냅샷 2) c1.execute("SELECT SUM(qty) FROM inv;") print("T1 sum-2:", c1.fetchone()[0]) # 30 (비반복 읽기) # 팬텀 관찰: 행 추가 c2.execute("BEGIN;") c2.execute("INSERT INTO inv VALUES (3, 5);") c2.execute("COMMIT;") c1.execute("SELECT COUNT(*) FROM inv WHERE qty >= 5;") print("T1 count after phantom:", c1.fetchone()[0]) # 3 (팬텀) c1.execute("ROLLBACK;")

실행 결과/검증

• sum-1=20, sum-2=30 → Non-Repeatable Read
• count=3 → Phantom Read

추가 실험

• 같은 시나리오를 SET TRANSACTION ISOLATION LEVEL SERIALIZABLE; 로 비교 실행

실습 예제: Read Committed 트랜잭션 테스트

목적

• 커밋된 데이터만 읽는 Read Committed 의 특징과 Non-Repeatable Read 현상을 직접 코드로 검증.

사전 요구사항

• 데이터베이스: MySQL, PostgreSQL 등 (격리 수준 변경 가능)
• 계정 권한: 트랜잭션 및 테이블 조회/변경 권한
• 실습 환경: CLI 또는 DB 툴, AUTOCOMMIT OFF

단계별 구현

1. 트랜잭션 시작 및 데이터 조회

   1 2 3 4

   -- 세션 A SET TRANSACTION ISOLATION LEVEL READ COMMITTED; START TRANSACTION; SELECT price FROM product WHERE id = 100; -- ex: 1000원

2. 다른 트랜잭션에서 데이터 변경 및 커밋

   1 2 3 4 5

   -- 세션 B SET TRANSACTION ISOLATION LEVEL READ COMMITTED; START TRANSACTION; UPDATE product SET price = 1200 WHERE id = 100; COMMIT;

3. 원래 트랜잭션에서 재조회

   1 2 3

   -- 세션 A SELECT price FROM product WHERE id = 100; -- 1200원으로 변경됨 COMMIT;

실행 결과

• 같은 트랜잭션 내에서 SELECT 결과가 바뀌는 Non-Repeatable Read(반복 읽기 불가능) 확인.

추가 실험

• REPEATABLE READ 로 격리 수준을 변경하면 반복 조회 시 동일 결과가 반환됨.

최종 정리 및 학습 가이드

내용 종합

Read Committed 는 데이터베이스 격리 수준 중 실무에서 널리 쓰이는 균형점이다.
이 모드는 트랜잭션이 다른 트랜잭션의 미커밋 변경을 볼 수 없도록 보장해서 Dirty Read 로 인한 잘못된 보고·오류를 예방한다. 대신, RC 는 문장 (statement) 단위 가시성을 제공하므로 동일 트랜잭션에서 같은 쿼리를 반복하면 결과가 달라질 수 있는 Non-Repeatable Read 와 범위 질의에서 행의 추가·삭제로 결과가 달라지는 Phantom Read 를 허용한다.

실무에서는 다음 원칙을 권장한다.
핵심 데이터 (금융·결제·사용자 상태) 는 반드시 더 높은 격리 수준 (예: Repeatable Read, Serializable 또는 Snapshot 기반 트랜잭션) 에서 처리하고, 리포트·집계·로그 같은 읽기 중심 워크로드는 RC 적용을 검토하되 DB 별 동작 차이 확인, 재현 테스트, 모니터링·롤백 계획을 필수로 준비하라.
또한 필요한 경우 특정 쿼리나 트랜잭션만 선별적으로 상향 적용하는 접근 (쿼리 힌트·세션 단위 변경) 이 현실적이며 안전한 운영으로 이어진다.

실무 적용 가이드

학습 로드맵

학습 항목 정리

용어 정리

참고 및 출처

• PostgreSQL: Transaction Isolation
• Oracle Database: Data Concurrency and Consistency
• Microsoft Learn: SET TRANSACTION ISOLATION LEVEL (Transact-SQL)
• MySQL Reference Manual: InnoDB Transaction Isolation Levels
• A Critique of ANSI SQL Isolation Levels (Berenson et al., 1995) — PDF
• Weak Consistency: A Generalized Theory and Optimistic Implementations (Atul Adya, 1999) — PDF
• 트랜잭션의 격리 수준(Isolation Level)에 대해 쉽고 이해하기 — mangkyu.tistory.com
• 트랜잭션의 격리 수준(Isolation Level) — chaewsscode.tistory.com