Transaction Isolation

Transaction Isolation

트랜잭션 격리 (Transaction Isolation) 는 ACID 속성 중 ‘I’ 에 해당하며, 다중 사용자 환경에서 데이터 무결성과 일관성을 유지하기 위해 트랜잭션 간 상호작용을 제어한다.

ANSI/ISO SQL 표준은

• Read Uncommitted
• Read Committed
• Repeatable Read
• Serializable
  네 수준을 정의하며, 각 수준은 Dirty Read, Non-repeatable Read, Phantom Read 와 같은 이상 현상 발생 가능성을 다르게 제한한다.

구현 방식에는 MVCC, 2PL, Snapshot Isolation 등이 있으며, 낮은 수준은 성능을 높이지만 일관성을 약화시키고, 높은 수준은 그 반대다.

현대 분산 트랜잭션 환경에서는 SAGA, 2PC, Eventual Consistency 등과 결합해 요구사항에 맞춘 성능·정합성 균형을 설계하며, NoSQL·클라우드 환경에서도 필수 고려 요소로 작용한다.

핵심 개념

• ACID: Atomicity(원자성), Consistency(일관성), Isolation(격리성), Durability(지속성)
• Isolation: 병행 실행되는 트랜잭션 간 간섭을 방지하고, 데이터의 **가시성 (Visibility)**과 **순서 (Ordering)**를 제어

• 직렬화 가능성 (Serializability): 모든 트랜잭션의 실행 결과가 직렬로 실행한 결과와 동일하게 보장되는 성질

동시성 이상 현상 (Concurrency Anomalies)

• 표준 (ANSI/ISO) 가 정의하는 이상 현상은 주로 Dirty / Non-repeatable / Phantom 이며, 실무에선 Lost Update와 Write Skew도 반드시 관리 대상이다.
• 방지 기준은 " 표준 격리 수준 " + " 엔진 구현 " 의 조합으로 결정된다.
  예: InnoDB 의 Repeatable Read는 Next-Key/GAP 잠금으로 팬텀을 실질적으로 막지만, PostgreSQL 은 **Serializable(SSI)**에서야 완전 차단.
• **Snapshot 계열 (RCSI/SI)**은 읽기 성능이 뛰어나고 Lost Update는 보통 막지만 (first-committer-wins), Write Skew는 남는다 → Serializable/SSI 또는 범위잠금/검증 제약으로 보완해야 한다.

해석 팁

• 발생 가능 격리 수준은 일반 경향이며, **" 엔진 구현 “** 에 따라 달라질 수 있다 (특히 Phantom/Write Skew).
• SI/RCSI: 읽기 성능 우수, Lost Update는 보통 막지만 Write Skew는 남는다 → 핵심 규칙 구간만 Serializable/락 강화.

• Dirty/Non-repeatable: RC→RR 로 대부분 해결.
• Phantom: 표준 해법은 Serializable; InnoDB RR은 구현상 거의 해결.
• Lost Update: 락/조건부 갱신/SI로 방지.
• Write Skew: SI 의 고질적 취약점 → Serializable/SSI 또는 관련 행을 한데 잠그는 모델링이 필요.
• 실제 적용은 격리 수준 + 엔진 특성 + 쿼리/인덱스/제약 설계를 함께 봐야 정확히 맞는다.

ANSI 표준 격리 수준과 현상 허용/차단

• **표준 관점:
  **ANSI/ISO SQL-92 는 4 개 격리 수준 (RU/RC/RR/Serializable) 과 3 가지 현상 (Dirty, Non-repeatable, Phantom) 으로 격리를 규정한다. Serializable 만이 직렬 실행과 동일한 효과를 보장한다.
• 엔진 차이의 핵심:
  • MySQL InnoDB는 RR 에서도 Next-Key/GAP 잠금으로 삽입을 막아 팬텀을 실질적으로 차단한다.
  • PostgreSQL은 Serializable=SSI로 팬텀/Write Skew 를 커밋 시 검출·차단하며, RR 은 스냅샷 일관이지만 팬텀/Write Skew 가 가능하다.
  • SQL Server의 RCSI는 RC 를 문장 단위 스냅샷로 구현 (Dirty 차단·읽기 비차단) 하지만 트랜잭션 재조회 간 값 변동 (Non-repeatable/팬텀) 가능; SNAPSHOT은 트랜잭션 단위 스냅샷로 Non-repeatable/팬텀을 피하되 Write Skew 가능.

보충 메모

• InnoDB 의 팬텀 차단: 인덱스 범위에 대해 Next-Key(=레코드 잠금 + 갭 잠금) 을 부여하여 범위 내 삽입을 봉쇄.
• SQL Server 스냅샷 계열: RCSI(문장 스냅샷, 기본 RC 의 구현 변화) vs SNAPSHOT(트랜잭션 스냅샷). 전자는 재조회 시 값/집합 변동 가능, 후자는 트랜잭션 동안 고정된 스냅샷을 읽음. 둘 다 버전 스토어 비용이 따른다.

동시성 제어 기법

• Lock-based
  • Shared Lock, Exclusive Lock, Gap Lock
  • Two-Phase Locking(2PL)
  • MVCC (Multi-Version Concurrency Control)
• 읽기 - 쓰기 충돌 완화, 스냅샷 읽기 제공
  • Snapshot Isolation 지원
• Snapshot Isolation 한계
  • Write Skew 가능
• Serializable Snapshot Isolation (SSI)
  • 충돌 그래프 분석으로 직렬 가능성 보장
• Deadlock Detection
  • Wait-for Graph, Timeout 기반 탐지
• Transaction Log
  • 롤백/복구용 기록 저장

Write Skew

• 정의: 두 개 이상의 트랜잭션이 동시에 같은 조건을 기반으로 읽기를 하고, 이후 서로 다른 행을 수정하여 조건이 더 이상 성립하지 않는 상태를 만드는 현상.
• 중요 포인트:
  1. 읽기 (Read) 시점에는 조건이 참 (true)
  2. 동시에 실행되는 다른 트랜잭션들도 같은 조건이 참이라고 판단
  3. 서로 다른 데이터를 변경하므로 락 충돌이 없고 커밋 가능
  4. 최종적으로 조건 위반 상태가 발생

” 회의실 예약 " 비유

• 규칙: 항상 한 개 이상의 회의실은 비워둬야 함
• 두 사람이 동시에 예약 페이지를 열었더니, 두 개의 회의실이 비어 있음
• 둘 다 " 괜찮네 " 하고 각자 다른 회의실을 예약
• 예약을 동시에 완료 → 결과적으로 회의실이 하나도 안 남음

왜 Snapshot Isolation 에서 발생하나?

• Snapshot Isolation(MVCC) 은 트랜잭션 시작 시점의 데이터 스냅샷을 기반으로 읽기 작업을 수행한다.
• 따라서 다른 트랜잭션이 중간에 어떤 데이터를 변경해도 내 스냅샷에는 반영되지 않는다.
• 이게 장점이지만, 조건 검증 로직이 오래된 스냅샷에 의존하게 되어 문제 발생 가능성이 있다.

병원 예시 (시각화 버전)

규칙: 최소 한 명 이상 당직 상태여야 함 (on_call = TRUE 가 최소 한 명)

트랜잭션 흐름

T1 (의사 1 퇴근 요청):

1. 스냅샷 읽기 → 당직자 2 명 있음 → 규칙 통과
2. UPDATE doctors SET on_call = FALSE WHERE doctor_id = 1
3. 커밋 준비

T2 (의사 2 퇴근 요청):

1. 스냅샷 읽기 → 당직자 2 명 있음 → 규칙 통과
2. UPDATE doctors SET on_call = FALSE WHERE doctor_id = 2
3. 커밋 준비

%% Write Skew 타임라인 (Snapshot Isolation, MVCC)
sequenceDiagram
    autonumber
    participant T1 as 트랜잭션 T1<br/>(의사1 퇴근)
    participant T2 as 트랜잭션 T2<br/>(의사2 퇴근)
    participant DB as DB<br/>(MVCC / Snapshot Isolation)

    Note over DB: 초기 상태 (t0):<br/>doctor(1)=TRUE, doctor(2)=TRUE

    rect rgba(240,240,255,0.6)
    Note over T1,T2: 동시 실행 구간 (서로 다른 행을 수정 → 직접 충돌 無)

    T1->>DB: BEGIN (스냅샷 시점 = t0)
    T2->>DB: BEGIN (스냅샷 시점 = t0)

    T1->>DB: SELECT COUNT(*) WHERE on_call=TRUE
    DB-->>T1: 2  ▶ 규칙 충족(최소 1명 on_call)
    T2->>DB: SELECT COUNT(*) WHERE on_call=TRUE
    DB-->>T2: 2  ▶ 규칙 충족(최소 1명 on_call)

    %% 서로 다른 행을 수정하므로 락 경합이 발생하지 않음
    T1->>DB: UPDATE doctors SET on_call=FALSE<br/>WHERE doctor_id=1
    T2->>DB: UPDATE doctors SET on_call=FALSE<br/>WHERE doctor_id=2

    T1->>DB: COMMIT
    DB-->>T1: OK
    T2->>DB: COMMIT
    DB-->>T2: OK
    end

    Note over DB: 최종 상태:<br/>doctor(1)=FALSE, doctor(2)=FALSE<br/><b>→ 규칙 위반 (on_call 최소 1명 보장 실패)</b><br/>(동일 스냅샷 기반 검증으로 인한 <b>Write Skew</b>)

최종 결과

• 둘 다 커밋

규칙 위반: 당직자가 0 명

발생 조건

• Snapshot Isolation (또는 유사 MVCC)
• 조건 검증 후 수정하는 로직
• 서로 다른 행 수정 (직접적인 쓰기 충돌 없음)

해결 방법

1. Serializable Isolation → 읽기 - 쓰기 충돌 감지 후 하나 롤백
2. SELECT … FOR UPDATE → 읽기 시점에 잠금 걸어 다른 트랜잭션의 변경 차단
3. DB 제약조건 추가 → CHECK, 트리거 등으로 강제 검증

Serializable(SSI)

• 커밋 시 충돌 그래프로 감지 → 하나 롤백

%% Write Skew 방지: Serializable Snapshot Isolation(SSI)
sequenceDiagram
    autonumber
    participant T1 as 트랜잭션 T1<br/>(의사1 퇴근)
    participant T2 as 트랜잭션 T2<br/>(의사2 퇴근)
    participant DB as DB(SSI)<br/>(충돌 그래프 감지)

    Note over DB: 초기(t0): doctor(1)=TRUE, doctor(2)=TRUE

    rect rgba(240,240,255,0.6)
    Note over T1,T2: 동시 실행 (스냅샷은 동일, 서로 다른 행 수정)
    T1->>DB: BEGIN (스냅샷=t0)
    T2->>DB: BEGIN (스냅샷=t0)

    T1->>DB: SELECT COUNT(*) WHERE on_call=TRUE
    DB-->>T1: 2 (규칙 통과)
    T2->>DB: SELECT COUNT(*) WHERE on_call=TRUE
    DB-->>T2: 2 (규칙 통과)

    T1->>DB: UPDATE doctors SET on_call=FALSE WHERE doctor_id=1
    T2->>DB: UPDATE doctors SET on_call=FALSE WHERE doctor_id=2

    %% 커밋 시점 충돌 탐지
    T1->>DB: COMMIT
    DB-->>T1: 준비됨(확정 대기)
    T2->>DB: COMMIT
    DB-->>T2: 충돌 그래프 사이클 감지 ▶ 롤백(Serialization failure)
    end

    Note over DB: 최종 상태: doctor(1)=FALSE, doctor(2)=TRUE<br/>→ 규칙 유지(최소 1명 on_call)

둘 다 업데이트를 했더라도 커밋 시점에 SSI 가 읽기 - 쓰기 의존성 그래프에서 사이클을 감지해 한쪽을 실패시키므로 규칙 위반이 발생하지 않는다.

SELECT … FOR UPDATE

• 읽기 시점에 잠금으로 동시 갱신 차단

%% Write Skew 방지: SELECT ... FOR UPDATE (잠금 기반)
sequenceDiagram
    autonumber
    participant T1 as 트랜잭션 T1<br/>(의사1 퇴근)
    participant T2 as 트랜잭션 T2<br/>(의사2 퇴근)
    participant DB as DB(Locking)<br/>(2PL/Gap Lock 등)

    Note over DB: 초기(t0): doctor(1)=TRUE, doctor(2)=TRUE

    T1->>DB: BEGIN
    T1->>DB: SELECT * FROM doctors WHERE on_call=TRUE FOR UPDATE
    DB-->>T1: 행(doctor 1,2) 잠금 획득

    T2->>DB: BEGIN
    T2->>DB: SELECT * FROM doctors WHERE on_call=TRUE FOR UPDATE
    DB-->>T2: 잠금 대기(블로킹)

    T1->>DB: UPDATE doctors SET on_call=FALSE WHERE doctor_id=1
    T1->>DB: COMMIT
    DB-->>T1: OK (잠금 해제)

    DB-->>T2: 잠금 획득 재개 후 재평가
    T2->>DB: SELECT COUNT(*) WHERE on_call=TRUE
    DB-->>T2: 1 (규칙 임계치) 
    T2->>DB: UPDATE doctors SET on_call=FALSE WHERE doctor_id=2
    DB-->>T2: 제약/비즈니스 로직 실패 ▶ 중단 또는 애플리케이션에서 취소
    T2->>DB: ROLLBACK

• FOR UPDATE로 " 조건을 만족하는 집합 " 을 읽는 순간 해당 행들 (또는 갭) 이 잠겨서, 다른 트랜잭션이 같은 조건으로 들어오면 대기하게 된다. T1 커밋 후 T2 가 깨어나 재평가하면 더 이상 안전하지 않으므로 애플리케이션 로직/제약조건이 변경을 막는다.

DBMS 별 기본 격리 수준 및 특징

실무 적용 전략

이론/실무/기본/심화

트랜잭션 격리 수준은 데이터 정합성과 시스템 성능 간의 균형을 결정하는 핵심 요소다.
ANSI 표준 격리 수준은 각기 다른 동시성 현상을 허용/차단하며, 실무에서는 Lock 기반 제어나 MVCC 를 활용해 동시성과 성능을 조율한다.
DBMS 별 구현 차이를 이해하고, 업무 특성에 맞는 격리 수준을 선택해야 하며, 분산 환경에서는 SAGA, 2PC, TrueTime 같은 기법을 고려해야 한다. Snapshot Isolation 은 성능이 뛰어나지만 Write Skew 를 막기 위해 SSI 또는 추가 제약이 필요하다.

기초 개념 (Foundation Understanding)

개념 정의 및 본질적 이해

트랜잭션 격리는 동시에 실행되는 트랜잭션의 가시성 규칙을 정해 간섭을 통제하고, 결과를 어떤 직렬 순서와 동치가 되도록 (최대 보장은 직렬화) 만드는 동시성 제어의 핵심이다.
SQL 표준은 더티/비반복/팬텀 읽기를 기준으로 4 수준 격리를 정의하지만, 실제 DBMS 는 MVCC·잠금·SSI 등으로 구현이 달라 동작 차이가 난다 (예: PostgreSQL 은 기본 Read Committed, Uncommitted 은 동일 취급). 결국 격리는 일관성 강화 ↔ 동시성 저하의 균형을 설계하는 문제다.

등장 배경 및 발전 과정

등장 배경

다중 사용자 환경에서 동시성으로 인한 이상 현상(Dirty Read, Lost Update, Phantom 등) 이 빈발하자, 연구자들은 트랜잭션과 락 기반 통제를 정립했다.
1970 년 Codd 의 관계형 모델이 데이터 일관성·독립성을 이론적으로 제시했고, 1976 년 IBM 연구진은 2PL·프레디킷 락으로 직렬가능성 조건을 체계화했다.
1983 년 Härder & Reuter 는 ACID로 신뢰성 요구를 정리했고, 1992 년 SQL-92는 격리수준을 표준화했다. 이후 2PL 의 읽기 스케일 한계를 개선하려 MVCC·SI가 확산되었고, SI 의 한계는 SSI로 보완되었다.
상용 DB 는 RCSI 등으로 읽기/쓰기 경합을 줄이며 현대 워크로드에 맞는 격리 구현을 제공한다.

발전 과정

timeline
  title Transaction Isolation 발전 타임라인
  1970 : Codd 관계형 모델 제안
  1976 : Eswaran 등 2PL·프레디킷 락
  1983 : Härder & Reuter ACID 체계화
  1992 : ANSI SQL-92 격리수준 채택
  1990s : MVCC·Snapshot Isolation 확산(Oracle/PG)
  1995 : Critique of ANSI SQL, SI 명확화
  2008 : Serializable Snapshot Isolation(SSI) 제안
  2010s~ : PostgreSQL SSI 구현, SQL Server RCSI 보편화

핵심 목적 및 필요성 (문제 해결 관점)

• 데이터 정합성: 격리 수준과 MVCC/SSI, 잠금·제약을 조합해 핵심 현상 (Dirty/Phantom/Lost/Write Skew) 을 차단한다. 규칙 위반률을 지표화해 관리한다.
• 성능/확장성: 높은 격리는 안전하지만 비용이 크다. MVCC/RCSI 로 읽기 경합을 줄이고, 인덱스/파티셔닝/튜닝으로 대기시간을 통제한다.
• 예측가능성/품질: 표준 격리 계약을 테스트 환경에 명시적으로 반영해 " 같은 입력→같은 결과 " 를 재현 가능하게 만든다.
• 운영/컴플라이언스: 로그·CDC·백업 체계를 격리 전략과 함께 설계하면 감사 대응과 장애 복구가 빨라진다.
• 아키텍처 유연성: 단일 DB 는 격리로 해결, 분산 환경은 SAGA/2PC·아웃박스로 보상/정합성을 달성한다. 서비스 경계마다 다른 선택이 합리적이다.

주요 특징 및 차별점

• 표준 격리 수준: ANSI 는 4 단계로 정의하지만, 실제 이상은 더 다양해 구현 보완이 필요하다.
• 구현 메커니즘: MVCC·락·SSI 등 조합으로 동일 명칭이라도 체감 격리/성능이 달라진다.
• PostgreSQL: RC 기본, SR 은 SSI 기반이라 직렬화 위반을 런타임 탐지한다.
• MySQL(InnoDB): RR 기본과 MVCC 로 읽기 일관성을 확보하되, 락 읽기 옵션에 따라 동작이 달라진다.
• SQL Server: RC 기본의 비관적 잠금을 쓰되, Snapshot 계열로 전환 시 버전 저장소 비용을 감안해야 한다.

핵심 원리 (Core Theory)

핵심 설계 원칙

• 정확성: 직렬성 확보가 핵심 목표이며, 실행 결과는 순차 실행과 동일해야 함.
• 무결성: 커밋 이전에는 변경 내용을 절대 공개하지 않아야 함.
• 안정성: 이상 현상 방지가 격리 수준 설계의 출발점.
• 효율성: 과도한 격리로 인한 성능 저하를 피하고, 워크로드 특성에 맞게 최소 수준 적용.
• 사용성: 격리 제어가 내부적으로 처리되어 개발자가 의식하지 않아도 동작.
• 아키텍처: 모듈형 구조로 향후 확장이 용이하도록 설계.
• 표준성: 표준 준수로 이식성과 호환성을 보장.
• 안전성: 문제 발생 시 성능보다 무결성을 우선.

기본 원리 및 동작 메커니즘

기본 원리

현상 정리:

• Dirty Read: RC 이상에서 차단.
• Non-repeatable Read: RR/Serializable, SI(트랜잭션 스냅샷) 에서 차단.
• Phantom: 범위/프리디킷 락 또는 SSI/직렬성으로 차단.
• Lost Update: X- 락/첫 커미터 우선/조건부 업데이트로 차단.
• Write Skew: Serializable/SSI 또는 FOR UPDATE+ 제약으로 차단.

• 잠금은 강하게 막고 느려지고, MVCC 는 부드럽게 읽고 충돌 시점에 조정한다.
• 팬텀·Write Skew 같은 범위·검증 문제는 범위잠금/SSI/제약으로 푼다.
• 지속성 (WAL), 데드락 처리, 버전 GC는 격리의 실제 동작을 지탱하는 보조축이다.

동작 메커니즘

flowchart TB
  %% App 계층
  A[BEGIN + 격리 수준 설정] --> B{요청 유형}
  B -->|읽기| R1["스냅샷 확보(MVCC)\n또는 S-Lock/프리디킷 락"]
  B -->|쓰기| W1[쓰기 의도: 새 버전 생성 + X-Lock]

  %% 읽기 경로
  R1 --> R2{범위 스캔?}
  R2 -->|예| R3[갭/레인지/프리디킷 락 부여]
  R2 -->|아니오| R4["가시성 판정(xmin/xmax/CSN)"]
  R3 --> J
  R4 --> J

  %% 쓰기 경로
  W1 --> W2[인덱스 갱신 + WAL 기록]

  %% 엔진 내부 공통 처리
  subgraph Engine
    J{충돌/대기 처리}
    D1["데드락 탐지\n(wait-for graph/timeout)"]
    S1["SSI 검증(Serializable)\n위험 구조 감지"]
  end

  W2 --> J
  J -->|대기| J
  J --> D1
  J --> S1
  D1 -->|사이클| ABORT1[["트랜잭션 중단(희생자)"]]
  S1 -->|위반| ABORT2[["트랜잭션 중단(재시도)"]]

  %% 커밋 단계
  J --> C[COMMIT]
  C --> L1[WAL fsync/Commit Record]
  C --> L2[락/스냅샷 해제]
  C --> V1[오래된 버전 GC/VACUUM]
  L1 --> END[(완료)]
  L2 --> END
  V1 --> END

• 읽기는 스냅샷 또는 S/프리디킷 락으로 일관 보장, 쓰기는 새 버전 +X- 락으로 충돌을 표면화한다.
• 충돌은 대기/데드락/SSI 검증에서 해결되고, 커밋 시 WAL로 영속화·순서가 확정된다.
• 범위 스캔은 범위잠금으로 팬텀을 예방, SSI 는 Write Skew 등 미세 위반을 커밋 직전에 차단한다.
• 긴 트랜잭션은 버전 수명과 GC 에 영향을 주므로 운영 정책 (타임아웃/재시도/배치 분리) 이 필요하다.

아키텍처 및 구성 요소

graph TB
    subgraph Application Layer
        APP[Application/Client]
    end

    subgraph Database Engine
        TM[Transaction Manager]
        CC[Concurrency Control Module]
        LM[Lock Manager]
        MVCC[MVCC Engine & Version Store]
        VR[Visibility Rules Engine]
        LG[Log Manager]
    end

    subgraph Storage Engine
        BM[Buffer Manager]
        DM[Data Manager]
        IM[Index Manager]
        DS[Disk Storage]
    end

    subgraph Optional Distributed Layer
        DC[Distributed Commit Coordinator]
    end

    APP --> TM
    TM --> CC
    CC --> LM
    CC --> MVCC
    MVCC --> VR
    LM --> BM
    VR --> BM
    TM --> LG
    BM --> DM
    DM --> IM
    IM --> DS
    TM --> DC

구성 요소

Lock 기반 vs. MVCC 기반 트랜잭션 처리 흐름 비교

Lock 기반 (Strict 2PL) Vs MVCC 기반 (Snapshot Isolation) 트랜잭션 처리 플로우 비교

Lock 기반 vs. MVCC 기반 비교 시퀀스 다이어그램

sequenceDiagram
    participant App as Application
    participant TM as Transaction Manager
    participant LM as Lock Manager
    participant MV as MVCC Engine
    participant DB as Database Storage

    rect rgb(230,230,250)
    Note over App,DB: Lock 기반 (2PL)
    App->>TM: 트랜잭션 시작
    TM->>LM: 공유/배타 락 요청
    LM-->>TM: 락 획득(대기 가능)
    TM->>DB: 읽기/쓰기 수행
    TM->>LM: 커밋 시 락 해제
    TM->>DB: 로그 기록
    TM-->>App: 커밋 완료
    end

    rect rgb(240,255,240)
    Note over App,DB: MVCC 기반 (Snapshot Isolation)
    App->>TM: 트랜잭션 시작(스냅샷 생성)
    TM->>MV: 읽기 요청 → 스냅샷 버전 반환
    MV->>DB: 읽기 시 디스크/메모리에서 해당 버전 로드
    TM->>MV: 쓰기 요청 → 새 버전 생성
    TM->>MV: 커밋 시 충돌 검사
    alt 충돌 발생
        TM-->>App: 롤백
    else 충돌 없음
        TM->>DB: 새 버전 반영
        TM-->>App: 커밋 완료
    end
    end

주요 기능과 역할

기능 ↔ 역할 관계

트랜잭션 격리의 주요 기능은 이상 현상 방지와 격리 수준 관리를 중심으로 데이터 무결성과 성능 간 균형을 맞추는 데 있다. 이를 위해 **락 기반 (2PL)**과 버전 기반 (MVCC) 접근 방식을 사용하며, 동시성 제어·읽기 일관성·분산 환경 적용까지 포괄한다. 기능과 역할은 서로 맞물려, 하나의 기능이 여러 역할을 동시에 수행하며 비즈니스 로직 안정성과 시스템 효율성을 동시에 추구한다.

ANSI SQL 격리 수준별 기능/역할

• 방지 가능한 이상 현상:

  • Dirty Read: 다른 트랜잭션의 미커밋 데이터를 읽는 문제
  • Non-repeatable Read: 동일 조건의 조회 결과가 트랜잭션 중간에 바뀌는 문제
  • Phantom Read: 동일 조건 조회 시 새로운 행이 나타나거나 사라지는 문제

• 실무 구현 차이:

  • Read Committed: 대부분의 DBMS 기본값, Oracle/SQL Server(RCSI) 는 MVCC 로 구현 → 읽기 락 없이 Dirty Read 방지만 수행
  • Repeatable Read: MySQL(InnoDB) 은 MVCC 기반, PostgreSQL 은 Snapshot Isolation 동작과 유사
  • Serializable: 전통 2PL, MVCC 기반 SSI(PostgreSQL), Predicate Lock 등 다양한 구현

특성 분석 (Characteristics Analysis)

장점 및 이점 분석표

• 트랜잭션 격리는 정합성·성능·운영 안정성을 동시에 달성하는 핵심 장치다.
• Lock/MVCC/범위잠금/SSI 등 메커니즘을 업무 리스크와 성능 목표에 맞춰 조합하면, 오류·사고 비용을 낮추고 처리량과 지연을 관리할 수 있다.
• RC/RCSI/SI/Serializable을 유즈케이스별로 선택하고, **운영 지표 (정합성 결함률, 재시도/롤백률, 교착 비율, p95/p99 지연)**로 효과를 추적하면 실제 비즈니스 가치가 극대화된다.

(참고) 격리 수준별 대표 이점

단점 및 제약사항과 해결방안

트랜잭션 격리의 주요 단점은 낮은 수준에서의 데이터 불일치와 높은 수준에서의 성능 저하로 양극단의 트레이드오프가 존재한다.
MVCC·Locking·Gap Lock·Serializable 등의 기법은 각기 다른 부작용을 유발하며, 이를 완화하기 위해 격리 수준 선택, 인덱스 최적화, 트랜잭션 소형화, 체크 제약 등 다양한 조합의 대응이 필요하다.
운영 환경에서는 Deadlock, Livelock, 장수 트랜잭션, 버전 저장소 부하를 지속 모니터링해야 하며, 분산 환경에서는 네트워크 지연·장애에 대비한 멱등성·재시도 전략이 필수적이다.

트레이드오프 관계 분석

격리 수준, 동시성 제어 방식, 성능 지표 최적화는 서로 상충하는 목표를 가진다. 높은 격리는 안정성을, 낮은 격리는 성능을 준다. 락 기반은 예측 가능한 직렬화를, MVCC 는 읽기 성능을 준다. 응답 시간과 처리량 최적화는 환경 요구에 따라 선택해야 한다. 실무에서는 업무 특성·SLO·리스크 허용 범위를 종합적으로 고려해 최적 조합을 선택하는 것이 핵심이다.

높은 격리 수준 vs. 낮은 격리 수준

• 높은 격리 수준
  • 장점: 데이터 일관성 극대화, 이상 현상 차단
  • 단점: 처리량·동시성 저하, 잠금 경합/대기 증가
  • 적용 기준: 금융, 미션 크리티컬, 정확성이 최우선인 업무
• 낮은 격리 수준
  • 장점: 처리량·응답속도·동시성 극대화
  • 단점: 데이터 무결성 위험, 이상 현상 가능성
  • 적용 기준: 분석·비즈니스 로직 보완 가능 업무, 읽기 비중이 큰 워크로드

락 기반 (2PL) Vs 버전 기반 (MVCC)

• 락 기반
  • 장점: 예측 가능한 직렬화, 구현 단순
  • 단점: 읽기 - 쓰기 경합 시 대기, 데드락 위험
  • 적용 기준: 경합 낮고, 직렬화 필요성이 높은 환경
• MVCC
  • 장점: 읽기 동시성 우수, 읽기 블로킹 없음
  • 단점: 버전 저장소·GC 비용, Write Skew 가능
  • 적용 기준: 읽기 많고, 쓰기 충돌 빈도 낮은 환경

응답 시간 최적화 Vs 처리량 최적화

• 응답 시간 최적화
  • 장점: 개별 트랜잭션 지연 최소화
  • 단점: 전체 처리량 감소 가능
  • 적용 기준: 실시간 응답 요구 서비스
• 처리량 최적화
  • 장점: 시스템 전체 효율성 극대화
  • 단점: 개별 요청 지연 가능성
  • 적용 기준: 대규모 배치, 비동기 처리 환경

graph LR
    subgraph "격리 수준"
        RU[Read Uncommitted]
        RC[Read Committed]
        RR[Repeatable Read]
        S[Serializable]
    end
    
    subgraph "성능"
        HP[높은 성능]
        MP[중간 성능]
        LP[낮은 성능]
    end
    
    subgraph "일관성"
        LC[낮은 일관성]
        MC[중간 일관성]
        HC[높은 일관성]
    end
    
    RU --> HP
    RU --> LC
    RC --> MP
    RC --> MC
    RR --> MP
    RR --> MC
    S --> LP
    S --> HC

성능 특성 및 확장성 분석

읽기는 RCSI/SI 로 비차단화, 쓰기는 충돌을 국소화 (락/조건부 갱신/SSI), 강한 정합성 구간은 Serializable/SSI 로 한정 적용, 스케일 전략은 복제·샤딩·시간 동기화/합의의 조합으로 선택한다.

• 읽기 많은 서비스는 RCSI/SI로 비차단 일관 읽기를 확보하고, 버전 스토어 모니터링으로 부작용을 통제한다.
• 쓰기·핵심 규칙 구간은 범위를 잠그거나 Serializable/SSI로 국소 적용해 정합성을 끝까지 지킨다.
• 팬텀/범위 문제는 InnoDB Next-Key/GAP Lock(RR) 또는 SSI로 제어한다.
• 확장성은 읽기 복제/샤딩/분산 트랜잭션의 조합으로 달성하되, 2PC 는 지연·블로킹 비용을 인지하고 필요 최소로만 사용한다.
• 글로벌 트랜잭션은 TrueTime + 동기 복제 같은 특수 인프라로 외부 일관성을 실현할 수 있다. 비즈니스 임계 구간에만 적용하는 게 현실적이다.

구현 및 분류 (Implementation & Classification)

구현 기법/방법

• 제어 축: 잠금 기반 vs 버전 기반 vs 검증 기반 (낙관/타임스탬프).
• 목표 축: 직렬화 달성 (정확도) vs 읽기 동시성 (성능) vs 혼합.
• 운영 축: 경합/대기 (락) vs 저장소/GC(MVCC) vs abort 재시도 (SSI/OCC/TO).

2PL (Strict 2PL)—미니멀 락 매니저

 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

from collections import defaultdict, deque

class TwoPL:
    def __init__(self):
        self.locks = defaultdict(lambda: {"mode": None, "holders": set(), "wait": deque()})

    def compatible(self, res, req_mode):
        mode, holders = self.locks[res]["mode"], self.locks[res]["holders"]
        if mode is None: return True
        if req_mode == "S" and mode == "S": return True
        return holders == set() and req_mode == "X" and mode is None

    def acquire(self, tx, res, mode):
        L = self.locks[res]
        if L["mode"] in (None, "S") and (mode == "S" or (mode == "X" and not L["holders"])):
            L["mode"] = "X" if mode == "X" else L["mode"] or "S"
            L["holders"].add(tx)
            return True
        L["wait"].append((tx, mode)); return False

    def release_all(self, tx):
        for res, L in self.locks.items():
            if tx in L["holders"]:
                L["holders"].remove(tx)
                if not L["holders"]:
                    L["mode"] = None
                    # 깨운다
                    while L["wait"]:
                        n_tx, n_mode = L["wait"][0]
                        if self.acquire(n_tx, res, n_mode):
                            L["wait"].popleft()
                        else:
                            break

MVCC + SI—스냅샷 읽기/버전 쓰기

 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

import bisect, time
from collections import defaultdict

class MVCC:
    def __init__(self):
        self.data = defaultdict(list)  # key -> [(ts, value, committed, tx)]
        self.now = lambda: time.monotonic()

    def begin(self):
        return {"start": self.now(), "writes": []}

    def read(self, tx, key):
        chain = self.data[key]
        # 시작 시점 이하의 최신 커밋 버전
        for ts, val, committed, _ in reversed(chain):
            if ts <= tx["start"] and committed:
                return val
        return None

    def write(self, tx, key, value):
        ts = self.now()
        tx["writes"].append((key, ts, value))

    def commit(self, tx):
        # 간단 충돌 검사: 동일 key에 나보다 늦은 커밋이 있으면 실패
        for key, tsw, _ in tx["writes"]:
            for ts, _, committed, owner in self.data[key]:
                if committed and ts > tx["start"]:
                    return False  # 충돌 -> abort
        # 커밋 반영
        for key, tsw, val in tx["writes"]:
            self.data[key].append((tsw, val, True, tx))
        return True

SSI—RW 의존성 (위험 삼각) 감지의 뼈대

 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

from collections import defaultdict

class SSI:
    def __init__(self):
        self.reads = defaultdict(set)   # key -> set(tx)
        self.writes = defaultdict(set)  # key -> set(tx)
        self.active = set()

    def begin(self, txid):
        self.active.add(txid)

    def read(self, txid, key):
        self.reads[key].add(txid)

    def write(self, txid, key):
        # 나보다 먼저 읽은 Tx가 있고, 그들이 또 다른 write와 교차하면 위험
        for rtx in self.reads[key]:
            if rtx in self.active and rtx != txid:
                # 간단한 휴리스틱: 후발 write Tx abort
                return False
        self.writes[key].add(txid)
        return True

    def commit(self, txid):
        self.active.discard(txid)
        # 실제 구현은 RW-의존 그래프 사이클 탐지까지 수행
        return True

범위/갭/넥스트키 락—간단 범위 잠금 모델

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

class RangeLock:
    def __init__(self):
        self.ranges = []  # [(start,end,tx)]

    def collide(self, a, b):
        (s1,e1),(s2,e2) = a,b
        return not (e1 <= s2 or e2 <= s1)

    def acquire(self, tx, start, end):
        for (s,e,t) in self.ranges:
            if self.collide((start,end),(s,e)) and t != tx:
                return False
        self.ranges.append((start,end,tx))
        return True

    def release(self, tx):
        self.ranges = [(s,e,t) for (s,e,t) in self.ranges if t != tx]

Row Versioning (RCSI/SI)—읽기 전용 버전 스토어

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

from collections import defaultdict, deque

class RowVersioning:
    def __init__(self):
        self.store = defaultdict(deque)  # key -> deque of (commit_ts, value)

    def write_commit(self, key, value, ts):
        self.store[key].append((ts, value))

    def read_rcsi(self, key, read_ts):
        # read_ts 이전의 최신 커밋 버전 반환 (읽기 블로킹 없음)
        best = None
        for ts, val in self.store[key]:
            if ts <= read_ts:
                best = val
        return best

Timestamp Ordering (TO)—순서 위반 시 늦은 Tx 중단

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

class TO:
    def __init__(self):
        self.r_ts, self.w_ts = defaultdict(int), defaultdict(int)  # key->ts

    def read(self, tx_ts, key):
        if tx_ts < self.w_ts[key]:
            return False  # 너무 늦게 읽음 → abort
        self.r_ts[key] = max(self.r_ts[key], tx_ts); return True

    def write(self, tx_ts, key):
        if tx_ts < self.r_ts[key] or tx_ts < self.w_ts[key]:
            return False  # 순서 위반 → abort
        self.w_ts[key] = tx_ts; return True

Optimistic Concurrency Control (OCC)—커밋 시 검증

 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

class OCC:
    def __init__(self):
        self.committed = {}  # key -> (ts, value)
        self.clock = 0

    def begin(self):
        return {"start": self.clock, "readset": set(), "writes": {}}

    def read(self, tx, key):
        tx["readset"].add(key)
        return self.committed.get(key, (0, None))[1]

    def write(self, tx, key, value):
        tx["writes"][key] = value

    def commit(self, tx):
        end_ts = self.clock + 1
        # 검증: 시작 이후 해당 key가 갱신되었는지 체크
        for k in tx["readset"]:
            if self.committed.get(k, (0, None))[0] > tx["start"]:
                return False
        # 커밋
        for k, v in tx["writes"].items():
            self.committed[k] = (end_ts, v)
        self.clock = end_ts
        return True

분류 기준에 따른 유형 구분

격리 수준은 ANSI SQL 표준에 따라 RU→RC→RR→SE 순으로 강해지며, 방지 가능한 이상 현상 범위가 넓어지고 성능은 떨어진다. 하지만 실제 DBMS 구현은 표준 정의와 다를 수 있어, PostgreSQL 의 RR 이 SI 로 동작하거나 MySQL InnoDB 의 RR 이 Gap Lock 으로 팬텀을 차단하는 등 차이가 있다.
구현 메커니즘은 2PL, MVCC, SSI, Gap Lock 등으로 다양하며, 각 메커니즘은 성능·일관성·충돌 가능성 측면에서 트레이드오프를 가진다. 따라서 이론적 표준과 실무 구현의 차이를 모두 이해하고 선택하는 것이 중요하다.

ANSI 표준 Vs 실제 엔진별 구현 차이 비교

• PostgreSQL
  • RR 이 사실상 Snapshot Isolation으로 동작 → Phantom Read 와 Write Skew 가능
  • Serializable 은 SSI 로 구현해 MVCC 기반 직렬성 보장
• MySQL InnoDB
  • RR 에서 Gap Lock과 Next-Key Lock을 사용해 팬텀까지 방지 → 표준 RR 보다 강함
• Oracle
  • ANSI RR 을 별도로 제공하지 않고, RC 를 MVCC 로 구현
  • Serializable 은 버전 기반 직렬화
• SQL Server
  • 기본 RC 는 Lock 기반
  • RCSI(Read Committed Snapshot Isolation) 옵션으로 RC 도 MVCC 로 동작
  • SNAPSHOT 격리 수준 존재, Serializable 은 Lock 기반

도구 및 프레임워크 생태계

트랜잭션 격리 생태계는 단일 DB 엔진의 기능만으로 완성되지 않는다.

• DBMS 계층이 기본 격리 구현과 성능을 책임지고,
• 테스트·검증 도구가 이론적 보장을 실환경에서 확인하며,
• 프레임워크/ORM이 애플리케이션에서 격리 수준을 제어하고,
• 모니터링·분석 도구가 운영 중 문제를 조기에 발견·해결한다.
  이 네 축을 균형 있게 활용해야 안정성과 성능을 모두 확보할 수 있다.

표준 및 규격 준수사항

트랜잭션 격리 수준은 ANSI/ISO SQL 표준에 정의되어 있으며, 각 DBMS 는 이를 기반으로 자체 확장을 제공한다.

• SQL-92: 4 가지 격리 수준 (READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ, SERIALIZABLE) 과 각 수준에서 차단하는 현상 정의.
• SQL:1999: 스냅샷 격리 (Snapshot Isolation) 개념 도입, 객체·트리거 기능 확장.
• SQL:2003: 윈도우 함수, XML 지원 등 부가 기능 표준화.
• SQL:2011: Temporal Table 표준화로 시계열 데이터 접근 가능.
• 벤더별 확장: Oracle 의 Flashback Query, PostgreSQL 의 DEFERRABLE 트랜잭션, MySQL 의 Gap Lock 등.
• 준수 여부: 대부분 표준 격리 수준을 지원하나, 내부 구현 방식은 상이 (MVCC vs 2PL).

SQL 표준은 격리 수준과 동시성 제어의 기반을 제공하지만, 각 DBMS 는 표준을 구현하는 방식에서 차이를 두고 있다.

• SQL-92가 격리 수준 정의의 핵심 뼈대이며,
• 이후 표준들은 스냅샷 격리, 시간 기반 데이터 접근, 부가 기능을 추가했다.
• 실무에서는 표준을 참고하되, DBMS 별 구현 차이와 확장 기능을 반드시 이해해야 격리 수준을 올바르게 설정하고 성능·일관성을 균형 있게 유지할 수 있다.

실무 적용 (Practical Application)

실제 도입 사례

실습 예제 및 코드 구현

실습 예제: PostgreSQL, Python

학습 목표: RC/RR/Serializable 에서 Non-repeatable/Phantom/Write Skew 차이를 실습
시나리오: 재고 감소와 조회가 경합
시스템 구성:

• PostgreSQL 15+, psycopg
• 애플리케이션 2 개 워커 (Reader/Writer)

graph TB
  App1[Reader Tx] -->|RC or SI| PG[(PostgreSQL)]
  App2[Writer Tx] --> PG
  PG --> VS[MVCC/SSI]

Workflow

1. Tx A 가 재고 읽기
2. Tx B 가 재고 갱신 후 커밋
3. Tx A 가 재조회 (RC vs RR 비교)

유무 차이

• 도입 전 (RC): 재조회 값 변동 가능
• 도입 후 (RR/Serializable): 재조회 일관/팬텀 차단

구현 예시: Python/psycopg

 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
38
39
40
41
42
43
44
45
46
47
48
49

import psycopg
from contextlib import contextmanager

@contextmanager
def txn(conn, iso):
    # Isolation 수준 설정
    with conn.cursor() as cur:
        cur.execute(f"BEGIN TRANSACTION ISOLATION LEVEL {iso};")
    try:
        yield conn
        conn.commit()
    except Exception:
        conn.rollback()
        raise

def setup(conn):
    with conn.cursor() as cur:
        cur.execute("drop table if exists stock; create table stock(id int primary key, qty int);")
        cur.execute("insert into stock values (1, 10);")
    conn.commit()

# Non-repeatable Read 관찰 (READ COMMITTED)
def non_repeatable_demo(conn_a, conn_b):
    setup(conn_a)
    with txn(conn_a, "READ COMMITTED"):
        with conn_a.cursor() as ca:
            ca.execute("select qty from stock where id=1;")
            print("A first read:", ca.fetchone()[0])  # RC: 10
            # B가 업데이트
            with txn(conn_b, "READ COMMITTED"):
                with conn_b.cursor() as cb:
                    cb.execute("update stock set qty=qty-5 where id=1;")
            ca.execute("select qty from stock where id=1;")
            print("A second read:", ca.fetchone()[0])  # RC: 5 (비반복 읽기 발생)

# Phantom 방지 (SERIALIZABLE에서 범위 조건)
def phantom_block_demo(conn_a, conn_b):
    setup(conn_a)
    with txn(conn_a, "SERIALIZABLE"):
        with conn_a.cursor() as ca:
            ca.execute("select count(*) from stock where qty >= 10;")  # 범위 쿼리
            print("A count:", ca.fetchone()[0])
            # B가 조건을 만족하는 행을 추가하려 시도
            try:
                with txn(conn_b, "SERIALIZABLE"):
                    with conn_b.cursor() as cb:
                        cb.execute("insert into stock values (2, 20);")
            except Exception as e:
                print("B aborted due to serialization:", e)  # SSI가 충돌 감지 가능

• 첫 함수는 RC 에서 Non-repeatable Read를 보여준다 (재조회 값 변동).
• 두 번째는 Serializable/SSI 에서 팬텀 방지/충돌 중단을 시연한다.

실습 예제: 격리 수준별 동작 방식과 동시성 문제 해결 과정 이해

학습 목표: Transaction Isolation 의 각 격리 수준별 동작 방식과 동시성 문제 해결 과정 이해

시나리오: 온라인 도서 대여 시스템에서 동시에 여러 사용자가 같은 책을 대여하려고 할 때의 처리

시스템 구성:

• 웹 애플리케이션 서버 (Python Flask)
• 데이터베이스 (PostgreSQL)
• 연결 풀 (psycopg2)

시스템 구성 다이어그램:

graph TB
    subgraph "Client Layer"
        U1[User 1]
        U2[User 2]
        U3[User 3]
    end
    
    subgraph "Application Layer"
        APP[Flask Application]
        CP[Connection Pool]
    end
    
    subgraph "Database Layer"
        PG[PostgreSQL]
        TM[Transaction Manager]
        LM[Lock Manager]
    end
    
    U1 --> APP
    U2 --> APP
    U3 --> APP
    APP --> CP
    CP --> PG
    PG --> TM
    TM --> LM

Workflow:

1. 사용자가 도서 대여 요청
2. 애플리케이션이 재고 확인
3. 재고가 있으면 대여 기록 생성
4. 재고 수량 감소
5. 트랜잭션 커밋

핵심 역할:

• Transaction Isolation 이 동시 대여 요청 시 재고 일관성을 보장하고 오버대여를 방지

유무에 따른 차이점:

• 도입 전: 동시 요청 시 재고보다 많은 대여 발생 가능
• 도입 후: 정확한 재고 관리와 선착순 대여 처리

구현 예시 (Python):

  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
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156

import psycopg2
from psycopg2.extras import RealDictCursor
import threading
import time
from contextlib import contextmanager

class BookRentalSystem:
    def __init__(self, connection_string):
        self.connection_string = connection_string
    
    @contextmanager
    def get_db_connection(self, isolation_level):
        """
        데이터베이스 연결 및 격리 수준 설정
        - Transaction Isolation의 핵심: 격리 수준별 동작 제어
        """
        conn = psycopg2.connect(self.connection_string)
        try:
            # 격리 수준 설정 - Transaction Isolation의 실제 적용
            conn.set_isolation_level(isolation_level)
            yield conn
        finally:
            conn.close()
    
    def rent_book_read_uncommitted(self, user_id, book_id):
        """
        Read Uncommitted 격리 수준에서의 도서 대여
        - 커밋되지 않은 데이터도 읽어서 Dirty Read 문제 발생 가능
        """
        with self.get_db_connection(psycopg2.extensions.ISOLATION_LEVEL_READ_UNCOMMITTED) as conn:
            try:
                cursor = conn.cursor(cursor_factory=RealDictCursor)
                
                # 재고 확인 (Dirty Read 가능)
                cursor.execute("SELECT stock FROM books WHERE book_id = %s", (book_id,))
                result = cursor.fetchone()
                
                print(f"User {user_id}: 현재 재고 {result['stock']}")
                
                if result['stock'] > 0:
                    # 의도적 지연으로 동시성 문제 시뮬레이션
                    time.sleep(0.1)
                    
                    # 재고 감소
                    cursor.execute(
                        "UPDATE books SET stock = stock - 1 WHERE book_id = %s", 
                        (book_id,)
                    )
                    
                    # 대여 기록 생성
                    cursor.execute(
                        "INSERT INTO rentals (user_id, book_id, rental_date) VALUES (%s, %s, NOW())",
                        (user_id, book_id)
                    )
                    
                    conn.commit()
                    print(f"User {user_id}: 대여 성공!")
                    return True
                else:
                    print(f"User {user_id}: 재고 부족으로 대여 실패")
                    return False
                    
            except Exception as e:
                conn.rollback()
                print(f"User {user_id}: 오류 발생 - {e}")
                return False
    
    def rent_book_serializable(self, user_id, book_id):
        """
        Serializable 격리 수준에서의 도서 대여
        - Transaction Isolation의 최고 수준: 모든 동시성 문제 방지
        - 직렬화 가능한 스케줄로 실행되어 데이터 일관성 완벽 보장
        """
        with self.get_db_connection(psycopg2.extensions.ISOLATION_LEVEL_SERIALIZABLE) as conn:
            try:
                cursor = conn.cursor(cursor_factory=RealDictCursor)
                
                # 재고 확인 및 잠금 (SELECT FOR UPDATE)
                # Transaction Isolation의 핵심: 읽기와 동시에 배타적 잠금 획득
                cursor.execute(
                    "SELECT stock FROM books WHERE book_id = %s FOR UPDATE", 
                    (book_id,)
                )
                result = cursor.fetchone()
                
                print(f"User {user_id}: 현재 재고 {result['stock']} (잠금 획득)")
                
                if result['stock'] > 0:
                    # 재고 감소
                    cursor.execute(
                        "UPDATE books SET stock = stock - 1 WHERE book_id = %s", 
                        (book_id,)
                    )
                    
                    # 대여 기록 생성
                    cursor.execute(
                        "INSERT INTO rentals (user_id, book_id, rental_date) VALUES (%s, %s, NOW())",
                        (user_id, book_id)
                    )
                    
                    # 트랜잭션 커밋 - Transaction Isolation의 원자성 보장
                    conn.commit()
                    print(f"User {user_id}: 대여 성공! (일관성 보장)")
                    return True
                else:
                    print(f"User {user_id}: 재고 부족으로 대여 실패")
                    conn.rollback()
                    return False
                    
            except psycopg2.extensions.TransactionRollbackError:
                # 직렬화 실패 시 재시도 (Transaction Isolation의 충돌 해결)
                conn.rollback()
                print(f"User {user_id}: 직렬화 충돌로 재시도 필요")
                time.sleep(0.01)  # 짧은 대기 후 재시도
                return self.rent_book_serializable(user_id, book_id)
            except Exception as e:
                conn.rollback()
                print(f"User {user_id}: 오류 발생 - {e}")
                return False

def simulate_concurrent_rentals():
    """
    동시 대여 시뮬레이션
    - Transaction Isolation 유무에 따른 차이점 실증
    """
    rental_system = BookRentalSystem("postgresql://user:password@localhost/bookstore")
    
    print("=== Read Uncommitted 테스트 (문제 상황) ===")
    threads = []
    for i in range(3):
        thread = threading.Thread(
            target=rental_system.rent_book_read_uncommitted, 
            args=(f"user_{i}", 1)
        )
        threads.append(thread)
        thread.start()
    
    for thread in threads:
        thread.join()
    
    print("\n=== Serializable 테스트 (해결 상황) ===")
    threads = []
    for i in range(3):
        thread = threading.Thread(
            target=rental_system.rent_book_serializable, 
            args=(f"user_{i}", 2)
        )
        threads.append(thread)
        thread.start()
    
    for thread in threads:
        thread.join()

# 테스트 실행
if __name__ == "__main__":
    simulate_concurrent_rentals()

실습 예제: 격리 수준별 데이터 정합성 변화 실습

학습 목표: 트랜잭션 격리 수준별 데이터 정합성 변화 실습
시나리오: 두 개 트랜잭션 (트랜잭션 A, B) 이 동일한 데이터를 동시에 조회/수정
시스템 구성:

• DBMS (예: MySQL)
• 트랜잭션 처리 어플리케이션

시스템 구성 다이어그램:

graph TB
    A[트랜잭션 A] --> D[(데이터베이스)]
    B[트랜잭션 B] --> D
    D --> E[Isolation Level 컨트롤]

Workflow:

1. 트랜잭션 A 가 데이터 조회
2. 트랜잭션 B 가 동일 데이터 수정 및 커밋
3. 트랜잭션 A 가 재조회 → 격리 수준에 따라 결과 다름

핵심 역할:

• 격리 수준이 데이터 정합성에 어떻게 관여하는지 실습

유무에 따른 차이점:

• 도입 전: 데이터 무결성 침해 빈번
• 도입 후: 동시성 문제 예방, 데이터 보호

구현 예시 (Python, pymysql + SQL):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

# Transaction Isolation Level 실습 예제
import pymysql

# DB 연결 및 트랜잭션 시작 시 격리 수준 설정
conn = pymysql.connect(host='localhost', user='root', password='', db='test')
try:
    with conn.cursor() as cursor:
        cursor.execute('SET TRANSACTION ISOLATION LEVEL READ COMMITTED;') # 격리 수준 설정
        conn.begin()
        cursor.execute('SELECT balance FROM account WHERE id=1;')  # 데이터 조회
        # 주석: 동시간대에 다른 트랜잭션에서 데이터롤 변경했을 경우, Read Committed는 변경된 값만 조회 가능
        conn.commit()
finally:
    conn.close()

실습 예제: 주문 → 결제 → 재고 → 정산 흐름에 따른 구간별 권장 격리/락 전략

• 핵심 원칙: 읽기는 RC/RCSI(Snapshot) 로 비차단, 규칙 핵심 구간은 짧게 Serializable/SSI 또는 범위 락, 트랜잭션은 짧고 멱등적으로.

흐름 & 격리 레이어

flowchart LR
  subgraph Client
    U[사용자]
  end
  subgraph Services
    O[Order Svc\nRC/RCSI]
    P[Payment Svc\nPSP연동 + 내부 Ledger=Serializable/SSI]
    I["Inventory Svc\nFOR UPDATE / RR(+Next-Key)"]
    S[Settlement Svc\nSnapshot + 구간별 Serializable]
  end
  subgraph Infra
    MQ[(Kafka/Rabbit Outbox)]
    CACHE[(Redis)]
    SEARCH[(Elasticsearch)]
  end

  U --> O --> P --> I --> S
  O -- Outbox 이벤트 --> MQ
  P -- Outbox 이벤트 --> MQ
  I -- Outbox 이벤트 --> MQ
  O --- CACHE
  O --- SEARCH

엔진별 치트시트

실전 SQL 패턴 모음

1. 주문 생성—멱등키로 중복 방지

   1 2 3 4 5 6 7 8 9 10

   -- 공통(모든 엔진): 멱등키 유니크 인덱스 -- CREATE UNIQUE INDEX ux_order_idem ON orders(idempotency_key); -- 주문 생성: RC/RCSI에서 짧게 수행 BEGIN; -- 이미 처리된 요청이면 바로 반환 -- SELECT id FROM orders WHERE idempotency_key = :k FOR UPDATE; INSERT INTO orders(idempotency_key, user_id, amount, status) VALUES(:k, :user_id, :amount, 'PENDING'); COMMIT;

2. 결제 원장—Serializable/SSI 구간 (짧게)

   1 2 3 4 5 6 7 8 9 10 11 12 13

   -- Postgres 예시: 직렬화 보장(SSI) SET TRANSACTION ISOLATION LEVEL SERIALIZABLE; BEGIN; -- 멱등키로 이중 결제 방지 -- CREATE UNIQUE INDEX ux_pay_key ON payments(pay_key); INSERT INTO payments(pay_key, order_id, amount, state) VALUES(:k, :oid, :amt, 'CAPTURED'); -- 복식부기 원장: 차변/대변 동시 기록 (합계 일치 제약은 트리거/제약으로 보강) INSERT INTO ledger_entries (entry_id, account, debit, credit) VALUES (gen_random_uuid(), 'Cash', :amt, 0), (gen_random_uuid(), 'AR', 0, :amt); COMMIT; -- 직렬화 충돌 시 애플리케이션에서 재시도

3. 재고 차감—비관적 (행 잠금) 패턴

   1 2 3 4 5 6 7 8 9 10

   -- 단일 SKU: 재고 음수 방지 (Postgres/MySQL 유사) BEGIN; -- 선택 행 잠금으로 동시 차감 직격 SELECT qty FROM stock WHERE sku = :sku FOR UPDATE; -- 수량 충분할 때만 차감 UPDATE stock SET qty = qty - :n WHERE sku = :sku AND qty >= :n; -- 적용 여부 확인 (0행이면 부족/다른 Tx가 선점) COMMIT;

4. 재고 차감—낙관적 (조건부 갱신) 패턴

   1 2 3 4 5 6 7 8 9 10

   -- 스키마: stock(sku PK, qty, version) BEGIN; -- 현재 버전 조회 (스냅샷/RC) SELECT qty, version FROM stock WHERE sku = :sku; -- 조건부 업데이트로 충돌 검출 UPDATE stock SET qty = qty - :n, version = version + 1 WHERE sku = :sku AND qty >= :n AND version = :ver; COMMIT; -- 영향 행 수=0이면 재시도(버전 충돌 or 수량 부족)

5. 범위 (로트/유통기한 우선) 차감—팬텀 방지

   1 2 3 4 5 6 7 8 9 10 11 12

   -- InnoDB: 인덱스( (sku, expire_at) ) 위에서 RR + Next-Key 락 활용 SET TRANSACTION ISOLATION LEVEL REPEATABLE READ; BEGIN; -- 가장 빠른 만기 로트부터 집계 & 잠금 SELECT lot_id, available FROM lots WHERE sku = :sku AND available > 0 ORDER BY expire_at FOR UPDATE; -- 인덱스 범위에 Next-Key/GAP 잠금 부여 -- 선택 로트들에서 차감 처리... COMMIT;

6. 워커 병렬화—SKIP LOCKED 로 핫큐 처리

   1 2 3 4 5 6 7 8 9

   -- 대량 주문 재고예약 워커 BEGIN; -- 이미 잠긴 행은 건너뛰고 다른 워커가 병렬 처리 SELECT id FROM reservations WHERE state = 'READY' FOR UPDATE SKIP LOCKED LIMIT 100; -- 처리 후 상태 전이... COMMIT;

7. Outbox—이벤트 정확 1 회 전달

   1 2 3 4 5 6 7

   BEGIN; -- 비즈니스 변경 + 아웃박스 레코드를 동일 Tx에 기록 UPDATE orders SET status='PAID' WHERE id=:oid; INSERT INTO outbox(event_type, aggregate_id, payload, published) VALUES('OrderPaid', :oid, :json, false); COMMIT; -- 별도 퍼블리셔가 outbox(published=false)만 읽어 MQ에 퍼블리시 후 true로 마크

운영 팁

• 트랜잭션은 짧게: 읽기/검증 → 쓰기/커밋까지 한 번에, 네트워크 왕복 최소화.
• 재시도는 기본값: Serializable/SSI 충돌, 낙관적 잠금 실패는 멱등키와 함께 안전 재시도.
• 지표로 관리: 직렬화 실패율, 교착 비율, 잠금 대기, 버전 스토어/테이블 bloat, p95/99 지연.
• 엔진별 동작 차 검증: InnoDB 의 Next-Key, PostgreSQL 의 SSI, SQL Server 의 RCSI/힌트는 동일하지 않다—통합테스트 필수.
• 분리와 구간화: 전체를 Serializable 로 두지 말고, 핵심 구간만 강화해 처리량을 지킨다.

실제 도입 사례의 코드 구현

사례: 금융거래 시스템

사례 선정: 금융거래 시스템
비즈니스 배경: 동시 거래 환경에서 부정 거래와 데이터 오염 예방
기술적 요구사항: 모든 트랜잭션이 독립적으로 처리되어 동시에 일어나는 거래 데이터가 서로 영향을 받지 않아야 함

시스템 구성:

• Application Server
• Database Cluster (트랜잭션 관리 포함)

시스템 구성 다이어그램:

graph TB
    subgraph "금융 서비스 시스템"
        A[Application 서버] --> B[DB 트랜잭션 관리자]
        B --> C[DB 클러스터]
    end

Workflow:

1. 서버가 트랜잭션 요청
2. 트랜잭션 관리자 격리 수준 적용
3. 트랜잭션 처리 및 결과 반환

핵심 역할:

• 데이터 불일치와 부정거래 실시간 예방

유무에 따른 차이점:

• 도입 전: 동시 거래 오류, 부정거래 증가
• 도입 후: 동시 거래 데이터 오류 미발생, 신뢰 보장

구현 예시 (Spring Transaction 설정, YAML):

1
2
3
4
5
6
7
8
9

# Spring 환경에서 Serializable 격리 수준 적용 예시
spring:
  datasource:
    url: jdbc:mysql://localhost:3306/finance
    username: user
    password: pass
  jpa:
    properties:
      hibernate.connection.isolation: 8  # 8(SERIALIZABLE)

성과 분석:

• 성능 개선: Dirty read 등 동시성 오류 ‘0 건 '
• 운영 효율성: 예외·오류 자동 탐지율 99% 로 향상
• 비용 절감: 부정거래 탐지로 연간 손실 50% 감소

사례: 전자상거래 플랫폼의 재고 관리 시스템

사례 선정: 대규모 전자상거래 플랫폼의 재고 관리 시스템

비즈니스 배경:

• 일일 주문량 100 만건 이상 처리
• 동시 접속자 50 만명 이상
• 재고 오버셀링으로 인한 고객 불만과 손실 문제

기술적 요구사항:

• 재고 정확성 100% 보장
• 주문 응답 시간 500ms 이내
• 높은 동시성 처리 능력
• 시스템 장애 시 데이터 일관성 유지

시스템 구성:

• 애플리케이션 서버: Node.js (Express.js)
• 데이터베이스: MySQL 8.0 (InnoDB)
• 캐시: Redis Cluster
• 메시지 큐: Apache Kafka
• 로드 밸런서: NGINX

시스템 구성 다이어그램:

graph TB
    subgraph "Frontend"
        WEB[Web Interface]
        MOBILE[Mobile App]
    end
    
    subgraph "Load Balancer"
        LB[NGINX Load Balancer]
    end
    
    subgraph "Application Cluster"
        APP1[Node.js Server 1]
        APP2[Node.js Server 2]
        APP3[Node.js Server 3]
    end
    
    subgraph "Data Layer"
        MYSQL[(MySQL Master)]
        REDIS[(Redis Cluster)]
        KAFKA[Kafka Cluster]
    end
    
    subgraph "Monitoring"
        METRICS[Prometheus]
        LOGS[ELK Stack]
    end
    
    WEB --> LB
    MOBILE --> LB
    LB --> APP1
    LB --> APP2
    LB --> APP3
    APP1 --> MYSQL
    APP1 --> REDIS
    APP1 --> KAFKA
    APP2 --> MYSQL
    APP2 --> REDIS
    APP2 --> KAFKA
    APP3 --> MYSQL
    APP3 --> REDIS
    APP3 --> KAFKA
    APP1 --> METRICS
    APP2 --> LOGS

Workflow:

1. 고객이 상품 주문 요청
2. 로드 밸런서가 애플리케이션 서버로 분산
3. Redis 에서 재고 캐시 확인
4. MySQL 에서 트랜잭션 시작 (Repeatable Read)
5. 재고 차감 및 주문 생성
6. Kafka 로 이벤트 발행
7. 트랜잭션 커밋 및 응답

핵심 역할:

• Transaction Isolation 이 동시 주문 처리 시 재고 데이터의 일관성 보장
• Repeatable Read 격리 수준으로 주문 프로세스 중 재고 정보 일관성 유지
• 잠금 최소화로 높은 동시성과 성능 확보

유무에 따른 차이점:

• 도입 전: 재고 오버셀링으로 일일 평균 1000 건의 주문 취소 발생
• 도입 후: 재고 정확성 99.99% 달성, 고객 만족도 15% 향상

구현 예시 (Node.js):

  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
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251

const mysql = require('mysql2/promise');
const Redis = require('ioredis');
const { Kafka } = require('kafkajs');

class ECommerceInventorySystem {
    constructor() {
        // 데이터베이스 연결 풀 설정
        this.dbPool = mysql.createPool({
            host: 'mysql-master',
            user: 'ecommerce_user',
            password: 'secure_password',
            database: 'ecommerce',
            waitForConnections: true,
            connectionLimit: 100,
            queueLimit: 0,
            // Transaction Isolation 설정: Repeatable Read
            // 주문 프로세스 중 재고 일관성 보장을 위한 격리 수준
            isolationLevel: 'REPEATABLE READ'
        });
        
        // Redis 클러스터 연결
        this.redis = new Redis.Cluster([
            { host: 'redis-1', port: 6379 },
            { host: 'redis-2', port: 6379 },
            { host: 'redis-3', port: 6379 }
        ]);
        
        // Kafka producer 설정
        this.kafka = new Kafka({
            clientId: 'inventory-service',
            brokers: ['kafka-1:9092', 'kafka-2:9092', 'kafka-3:9092']
        });
        this.producer = this.kafka.producer();
    }
    
    async processOrder(customerId, productId, quantity) {
        /**
         * 주문 처리 메인 로직
         * - Transaction Isolation의 핵심 적용 부분
         * - Repeatable Read 격리 수준으로 재고 일관성 보장
         */
        const connection = await this.dbPool.getConnection();
        
        try {
            // 트랜잭션 시작 - Transaction Isolation 적용 시점
            await connection.beginTransaction();
            console.log(`주문 처리 시작: Customer ${customerId}, Product ${productId}`);
            
            // 1. 캐시에서 빠른 재고 확인 (성능 최적화)
            const cachedStock = await this.redis.get(`stock:${productId}`);
            if (cachedStock && parseInt(cachedStock) < quantity) {
                throw new Error('재고 부족 (캐시 기준)');
            }
            
            // 2. 데이터베이스에서 정확한 재고 확인 및 잠금
            // Transaction Isolation의 핵심: FOR UPDATE로 배타적 잠금 획득
            const [stockRows] = await connection.execute(
                `SELECT stock_quantity, reserved_quantity 
                 FROM product_inventory 
                 WHERE product_id = ? FOR UPDATE`,
                [productId]
            );
            
            if (stockRows.length === 0) {
                throw new Error('상품을 찾을 수 없습니다');
            }
            
            const availableStock = stockRows[0].stock_quantity - stockRows[0].reserved_quantity;
            console.log(`현재 가용 재고: ${availableStock} (잠금 획득됨)`);
            
            if (availableStock < quantity) {
                throw new Error(`재고 부족: 요청 ${quantity}, 가용 ${availableStock}`);
            }
            
            // 3. 재고 예약 (실제 차감 전 단계)
            // Transaction Isolation 보장 하에 안전한 재고 업데이트
            await connection.execute(
                `UPDATE product_inventory 
                 SET reserved_quantity = reserved_quantity + ? 
                 WHERE product_id = ?`,
                [quantity, productId]
            );
            
            // 4. 주문 생성
            const orderId = await this.createOrder(connection, customerId, productId, quantity);
            
            // 5. 재고 실제 차감 및 예약 해제
            await connection.execute(
                `UPDATE product_inventory 
                 SET stock_quantity = stock_quantity - ?,
                     reserved_quantity = reserved_quantity - ?
                 WHERE product_id = ?`,
                [quantity, quantity, productId]
            );
            
            // 6. 트랜잭션 커밋 - Transaction Isolation의 원자성 완성
            await connection.commit();
            
            // 7. 캐시 업데이트 (일관성 유지)
            const newStock = stockRows[0].stock_quantity - quantity;
            await this.redis.set(`stock:${productId}`, newStock, 'EX', 300);
            
            // 8. 이벤트 발행 (비동기 처리)
            await this.publishInventoryEvent(productId, quantity, 'STOCK_DECREASED');
            
            console.log(`주문 처리 완료: Order ${orderId}`);
            return { success: true, orderId, remainingStock: newStock };
            
        } catch (error) {
            // 트랜잭션 롤백 - Transaction Isolation의 원자성 보장
            await connection.rollback();
            console.error(`주문 처리 실패: ${error.message}`);
            
            // 캐시 무효화 (데이터 일관성)
            await this.redis.del(`stock:${productId}`);
            
            return { success: false, error: error.message };
        } finally {
            // 연결 해제
            connection.release();
        }
    }
    
    async createOrder(connection, customerId, productId, quantity) {
        /**
         * 주문 레코드 생성
         * - 동일한 트랜잭션 내에서 실행되어 Transaction Isolation 보장
         */
        const [result] = await connection.execute(
            `INSERT INTO orders (customer_id, product_id, quantity, order_status, created_at)
             VALUES (?, ?, ?, 'PENDING', NOW())`,
            [customerId, productId, quantity]
        );
        
        const orderId = result.insertId;
        
        // 주문 상세 정보 추가
        await connection.execute(
            `INSERT INTO order_items (order_id, product_id, quantity, unit_price)
             SELECT ?, product_id, ?, price 
             FROM products WHERE product_id = ?`,
            [orderId, quantity, productId]
        );
        
        return orderId;
    }
    
    async publishInventoryEvent(productId, quantity, eventType) {
        /**
         * 재고 변경 이벤트 발행
         * - Transaction Isolation 외부에서 실행되는 비동기 처리
         */
        try {
            await this.producer.send({
                topic: 'inventory-events',
                messages: [{
                    key: productId.toString(),
                    value: JSON.stringify({
                        productId,
                        quantity,
                        eventType,
                        timestamp: new Date().toISOString()
                    })
                }]
            });
        } catch (error) {
            console.error(`이벤트 발행 실패: ${error.message}`);
            // 별도 재시도 로직 필요
        }
    }
    
    async handleConcurrentOrders() {
        /**
         * 동시 주문 처리 시뮬레이션
         * - Transaction Isolation의 효과 검증
         */
        const productId = 12345;
        const orderPromises = [];
        
        // 10개의 동시 주문 시뮬레이션
        for (let i = 1; i <= 10; i++) {
            const promise = this.processOrder(`customer_${i}`, productId, 1);
            orderPromises.push(promise);
        }
        
        // 모든 주문 처리 완료 대기
        const results = await Promise.all(orderPromises);
        
        // 결과 분석
        const successCount = results.filter(r => r.success).length;
        const failureCount = results.filter(r => !r.success).length;
        
        console.log(`동시 주문 처리 결과:`);
        console.log(`- 성공: ${successCount}건`);
        console.log(`- 실패: ${failureCount}건`);
        console.log(`Transaction Isolation로 재고 일관성 보장됨`);
        
        return results;
    }
}

// Express.js 라우터 설정
const express = require('express');
const app = express();
const inventorySystem = new ECommerceInventorySystem();

app.use(express.json());

app.post('/orders', async (req, res) => {
    /**
     * 주문 API 엔드포인트
     * - Transaction Isolation이 적용된 주문 처리 호출
     */
    try {
        const { customerId, productId, quantity } = req.body;
        
        // 입력 검증
        if (!customerId || !productId || !quantity || quantity <= 0) {
            return res.status(400).json({
                error: '잘못된 요청 데이터'
            });
        }
        
        // 주문 처리 (Transaction Isolation 적용)
        const result = await inventorySystem.processOrder(customerId, productId, quantity);
        
        if (result.success) {
            res.status(201).json({
                message: '주문이 성공적으로 처리되었습니다',
                orderId: result.orderId,
                remainingStock: result.remainingStock
            });
        } else {
            res.status(409).json({
                error: result.error
            });
        }
        
    } catch (error) {
        console.error('주문 처리 중 오류:', error);
        res.status(500).json({
            error: '서버 내부 오류가 발생했습니다'
        });
    }
});

// 서버 시작
app.listen(3000, () => {
    console.log('E-commerce 재고 관리 시스템이 포트 3000에서 실행 중입니다');
    console.log('Transaction Isolation (Repeatable Read) 적용됨');
});