[Lock-2][Optimization] 다중 트랜잭션 환경과 정합성 문제

2025. 12. 24. 21:24·Database/MySQL

1. 들어가며: 단일 트랜잭션을 넘어 다중 트랜잭션의 세계로

 우리는 앞서 하나의 트랜잭션이 어떻게 시작되고, COMMIT 또는 ROLLBACK을 통해 어떻게 종료되는지 학습하였다. 하지만 이는 데이터베이스를 혼자 사용하는 이상적인 상황(단일 트랜잭션)을 가정한다. 실제 은행 서비스나 뉴스 서비스와 같은 환경에서는 수많은 사용자가 동시에 데이터를 읽고 쓰는 다중 트랜잭션 환경이다.

 

 이처럼 여러 트랜잭션이 뒤섞여 실행될 때, 아직 완료되지 않은(Uncommitted) 트랜잭션의 변경 사항을 다른 트랜잭션이 보게 된다면 어떤 일이 벌어질까? 우리는 이를 통해 동시성 제어의 실질적인 필요성을 체감하게 된다.


2. 동시성 제어의 필요성: 비즈니스 사례 비교

2.1. 금융 서비스: 데이터 부정합의 치명적 결과 (트랜잭션 수준: 上)

사용자가 출금을 시도하다가 취소하는 짧은 찰나에 은행원이 잔고를 조회하는 상황을 가정해 본다.

  1. 유저(T2): 잔액 1,000만 원 중 500만 원 출금을 시도한다. (UPDATE 수행, 아직 COMMIT 전)
  2. 은행원(T1): 대출 심사를 위해 유저의 잔액을 조회한다. 이때 아직 확정되지 않은 500만 원을 읽게 된다.
  3. 유저(T2): 출금 의사를 철회하고 ROLLBACK을 수행한다. 실제 잔액은 다시 1,000만 원이 된다.
  4. 결과: 은행원은 유저의 실제 잔액이 1,000만 원임에도 불구하고, 500만 원이라는 잘못된 정보를 바탕으로 대출 부적격 판정을 내리게 된다.

이처럼 금전적 손실이나 법적 문제가 직결되는 도메인에서는 커밋되지 않은 데이터를 읽는 행위가 시스템의 신뢰도를 완전히 무너뜨릴 수 있다.

2.2. 뉴스 서비스: 허용 가능한 수준의 일시적 오류 (트랜잭션 수준: 下)

이번에는 뉴스 검색과 기사 작성이 동시에 일어나는 상황을 가정해 본다.

  1. 기자(T2): 새로운 기사를 작성하여 임시 저장한다. (INSERT 수행, 아직 COMMIT 전)
  2. 사용자(T1): 특정 키워드로 뉴스를 검색한다. 이때 기자가 작성 중인 기사까지 포함하여 검색 결과가 나타난다.
  3. 기자(T2): 내용에 오류를 발견하고 해당 기사를 ROLLBACK한다.
  4. 결과: 사용자는 방금 전 검색에서 보았던 기사가 다시 검색했을 때 사라진 것을 발견한다.

사용자 입장에서는 "기사가 실시간으로 내려갔나?" 정도의 의문을 가질 뿐, 서비스 전체의 신뢰성에 치명적인 타격을 입지는 않는다. 뉴스나 SNS 같은 도메인에서는 데이터의 완벽한 정합성보다는 빠른 응답 속도와 최신 데이터의 노출이 더 중요할 수 있기 때문이다.


3. 정합성 수준과 비즈니스 도메인의 상관관계

위의 두 사례를 통해 알 수 있듯, 모든 서비스가 최상위 수준의 데이터 정확성을 요구하는 것은 아니다.

  • 높은 정합성 요구 도메인: 금융, 결제, 재고 관리 등 데이터 오류가 금전적/물리적 피해로 이어지는 분야.
  • 유연한 정합성 허용 도메인: SNS, 뉴스, 조회수 카운트 등 일시적인 데이터 불일치가 서비스 경험에 큰 지장을 주지 않는 분야.

데이터베이스는 이러한 다양한 요구사항을 충족하기 위해 정합성의 강도를 선택할 수 있는 장치를 마련해 두었는데, 우리는 이것을 격리성 수준이라고 한다.


4. 격리성 수준(Isolation Level)의 등장 배경

격리성(Isolation)이란 여러 트랜잭션이 동시에 실행될 때, 서로의 연산 결과에 얼마나 노출될지를 결정하는 성질이다. 그리고 이 노출 정도를 단계별로 나눈 것이 바로 격리성 수준(Isolation Level)이다.

4.1. 정합성과 성능의 트레이드오프(Trade-off)

격리성 수준을 설정하는 핵심 이유는 성능과 정합성 사이의 균형을 맞추기 위함이다.

  • 격리 수준이 높을수록: 데이터의 부정합 문제는 사라지지만, 여러 트랜잭션을 순차적으로 처리해야 하므로 시스템의 전체적인 처리량(Throughput)이 떨어진다.
  • 격리 수준이 낮을수록: 데이터 정합성 오류(Dirty Read 등)의 위험은 커지지만, 트랜잭션 간의 간섭이 적어 서비스 응답 속도가 빨라진다.

4.2. 격리성 수준의 의의

결국 격리성 수준이란, "우리가 만드는 서비스가 어느 정도의 정합성 오류까지 견딜 수 있는가?"에 대한 답을 내리는 과정이다. 개발자는 도메인의 특성을 고려하여 가장 적절한 수준의 격리성을 선택함으로써 성능과 안전성이라는 두 마리 토끼를 잡아야 한다.

'Database > MySQL' 카테고리의 다른 글

[Lock-4][Optimization] Redo/Undo 로그와 MVCC 원리  (0) 2025.12.25
[Lock-3][Optimization] Lock: 격리성 수준(Isolation Level) 심층 분석 및 실습  (0) 2025.12.25
[Lock-1][Optimization] 트랜잭션의 정의와 ACID 원칙  (0) 2025.12.24
[Index-7][Optimization] 실무 적용(⭐) - 복합 인덱스/집계 테이블/반정규화  (0) 2025.12.24
[Index-6][Optimization] 실전 분석 (2) - 실행 계획 타입(Type)  (0) 2025.12.24
'Database/MySQL' 카테고리의 다른 글
  • [Lock-4][Optimization] Redo/Undo 로그와 MVCC 원리
  • [Lock-3][Optimization] Lock: 격리성 수준(Isolation Level) 심층 분석 및 실습
  • [Lock-1][Optimization] 트랜잭션의 정의와 ACID 원칙
  • [Index-7][Optimization] 실무 적용(⭐) - 복합 인덱스/집계 테이블/반정규화
h6bro
h6bro
백엔드 개발자의 기술 블로그
  • h6bro
    Jun's Tech Blog
    h6bro
  • 전체
    오늘
    어제
    • 분류 전체보기 (250) N
      • Java (18)
        • Core (9)
        • Design Pattern (9)
      • Spring (80)
        • Core (24)
        • MVC (6)
        • DB (10)
        • JPA (26)
        • Monitoring (3)
        • Security (11)
        • WebSocket (0)
      • Database (33)
        • Redis (15)
        • MySQL (18)
      • MSA (25) N
        • MSA 기본 (11)
        • MSA 아키텍처 (14) N
      • Kafka (30) N
        • Core (18) N
        • Connect (12)
      • ElasticSearch (11)
        • Search (11)
        • Logging (0)
      • Test (4)
        • k6 (4)
      • Docker (9)
      • CI&CD (10)
        • GitHub Actions (6)
        • ArgoCD (4)
      • Kubernetes (18)
        • Core (12)
        • Ops (6)
      • Cloud Engineering (4)
        • AWS Infrastructure (3)
        • AWS EKS (1)
        • Terraform (0)
      • Project (8)
        • LinkFolio (1)
        • Secondhand Market (7)
  • 블로그 메뉴

    • 홈
    • 태그
    • 방명록
  • 링크

  • 공지사항

    • Cloud Engineering 포스팅 정리
  • 인기 글

  • 태그

    ㅈ
  • 최근 댓글

  • 최근 글

  • hELLO· Designed By정상우.v4.10.5
h6bro
[Lock-2][Optimization] 다중 트랜잭션 환경과 정합성 문제
상단으로

티스토리툴바