+++

핵심 인사이트 (3줄 요약)

  1. 본질: 2단계 잠금 프로토콜(2PL)은 잠금 확장 단계(Growing Phase)와 잠금 수축 단계(Shrinking Phase)로 나뉘어, 확장 단계에서는 잠금만 획득하고 해제는 하지 않는 원칙을 준수한다.
  2. 가치: 2PL을 따르면 직렬 가능성(Serializability)이 보장되어, 동시 실행 결과가 어떤 직렬 실행 결과와 동일함이 수학적으로 보장된다.
  3. 융합: 2PL은 컴퓨터구조의 파이프라인과 유사한 phases 개념을 적용한 것으로, OS의 페이징 알고리즘과도 관련이 있다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

개념

2단계 잠금 프로토콜(2PL, Two-Phase Locking)은 잠금 기반 동시성 제어에서 직렬 가능성을 보장하는 표준 프로토콜이다. 트랜잭션은 잠금 확장 단계(Growing Phase)에서 필요한 잠금을 모두 획득하고,一度 획득한 잠금은 해제하지 않는다. 이후 잠금 수축 단계(Shrinking Phase)에서는 기존 잠금을 해제하기만 하고 새로운 잠금은 획득하지 않는다.

필요성

잠금만으로는 직렬 가능성이 보장되지 않는다. 예컨대 T1이 A를 읽고, T2가 B를 읽은 후 T1이 A에 대해 쓰고 T2가 B에 대해 쓰는 상황은 문제 없이 진행될 수 있지만, 순환적 의존성이 형성되면 교착 상태나 비 직렬 가능한 결과가 나타날 수 있다. 2PL은 이러한 문제을 체계적으로 방지한다.

비유

2PL은 물건 가져오기와 반납하기의 규칙과 같다. 먼저 필요한 물건을 모두 가져온 후(확장 단계), 사용이 끝나면 반납만 하고(수축 단계), 반납 후에는 다시 가져오지 않는다.

등장 배경

  1. 1976년: Eswaran 등의 체계화: 2PL이 직렬 가능성을 보장한다는 것을 처음으로 数学적으로 증명했다.
  2. 엄격한 2PL (Strict 2PL): 커밋 전까지 X-Lock을 해제하지 않아 캐스케이드 롤백을 방지하는 변형이 도입됐다.
  3. 강화 2PL (Rigorous 2PL): 모든 잠금(공유/배타 모두)을 커밋까지 유지하는 변형으로, 대부분의 상용 DBMS에서 채택하고 있다.

섹션 요약 비유

2PL은 크레프트 게임의 작업 대장장이와 같다. 먼저 모든 재료를 벤치에 올려놓고(확장 단계), 제작 후 결과를库存에 넣고(수축 단계), 제작 완료 후에는 다시 재료를 올리지 않는다.


Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)

2PL phases 동작

  ┌───────────────────────────────────────────────────────────────────────┐
  │                    2PL (Two-Phase Locking) 동작 예시                    │
  ├───────────────────────────────────────────────────────────────────────┤
  │
  │   [잠금 확장 단계 (Growing Phase)]                                     │
  │   T1:  LOCK-S(A) ──▶ LOCK-X(B) ──▶ 연산(A, B)                        │
  │        ▲                                                         │
  │        │                                                         │
  │        새 잠금 획득만, 해제는 아직                                  │
  │                                                                       │
  │   [잠금 수축 단계 (Shrinking Phase)]                                  │
  │   T1:  ... ──▶ UNLOCK(A) ──▶ UNLOCK(B) ──▶ COMMIT                   │
  │                        ▲                                          │
  │                        │                                          │
  │                        해제만, 새 잠금 획득 불가                     │
  │                                                                       │
  │   ※ 중요: 수축 단계에서 잠금을 해제하면 다른 트랜잭션이 해당 데이터를   │
  │          사용할 수 있게 되어, 결과적으로 직렬 실행과 동등한 효과를 냄   │
  │
  └───────────────────────────────────────────────────────────────────────┘

[다이어그램 해설] 2PL의 핵심은 확장 단계와 수축 단계의 분리다. T1이 LOCK-S(A)와 LOCK-X(B)를 획득하는 동안은 아직 수축 단계에 진입하지 않은 것이므로 추가로 잠금을 획득할 수 있다. 그러나 첫 번째 UNLOCK(A) 순간, T1은 수축 단계에 진입하며, 이후에는 LOCK(C) 같은 새 잠금 획득이 금지된다. 이 규칙이 지켜지면, 트랜잭션 간의 잠금 의존 관계가 교차하지 않아 교착 가능성이 낮아지고, 동시에 직렬 가능성이 보장된다. 실무에서 엄격한 2PL(Strict 2PL)은 커밋 전까지 X-Lock을 해제하지 않아 롤백 시 캐스케이드를 방지한다.

2PL 변형 비교

구분Basic 2PLStrict 2PLRigorous 2PL
X-Lock 해제 시점수축 단계 시작 시COMMIT 전까지 유지COMMIT 전까지 유지
S-Lock 해제 시점수축 단계 시작 시자유COMMIT 전까지 유지
캐스케이드 롤백가능불가불가
직렬 가능성보장보장보장
주 사용 DB이론적 모델일부 DBOracle, PostgreSQL, MySQL
  ┌───────────────────────────────────────────────────────────────────────┐
  │                    Basic 2PL vs Strict 2PL vs Rigorous 2PL            │
  ├───────────────────────────────────────────────────────────────────────┤
  │
  │   Basic 2PL:                                                          │
  │   T1: [LOCK-S(A)] [LOCK-X(B)] [UNLOCK(A)] [UNLOCK(B)] [COMMIT]       │
  │                      ▲                          ▲                     │
  │                   확장 단계 끝                수축 단계 시작            │
  │
  │   Strict 2PL:                                                         │
  │   T1: [LOCK-S(A)] [LOCK-X(B)] [연산] ... [UNLOCK(A)] [UNLOCK(B)] [COMMIT] │
  │                                                 ▲                     │
  │                                              COMMIT 전까지 X-Lock 유지 │
  │
  │   Rigorous 2PL:                                                      │
  │   T1: [LOCK-S(A)] [LOCK-X(B)] [연산] ... [COMMIT] ──▶ [UNLOCK(A)] [UNLOCK(B)] │
  │                                                         ▲             │
  │                                                    COMMIT 후 잠금 해제  │
  │
  └───────────────────────────────────────────────────────────────────────┘

[다이어그램 해설] 세 가지 2PL 변형은 잠금 해제 시점의 차이다. Basic 2PL은 수축 단계 시작 시 잠금을 해제하므로 다른 트랜잭션이 해당 데이터를 사용할 수 있어 비 직렬 가능한 상황이 발생할 수 있다. Strict 2PL은 커밋 전까지 X-Lock을 유지하여 캐스케이드 롤백을 방지하지만, S-Lock은 즉시 해제될 수 있다. Rigorous 2PL은 모든 잠금을 COMMIT 후 해제하여 가장 엄격한 직렬 가능성을 보장하고, 대부분의 상용 DBMS가 이 방식을 채택한다.

2PL의 한계: 교착 상태

2PL은 직렬 가능성을 보장하지만 교착 상태(Deadlock)는 방지하지 못한다. 두 트랜잭션이 서로 다른 순서로 잠금을 획득하면 순환 대기(Circular Wait) 상태가 발생할 수 있다.

  ┌───────────────────────────────────────────────────────────────────────┐
  │                    2PL에서의 교착 상태 발생 예                          │
  ├───────────────────────────────────────────────────────────────────────┤
  │
  │   T1: LOCK-X(A) ──▶ LOCK-S(B) ──▶ ⏳ 대기 중 (B의 S-Lock 획득 시도)  │
  │    │                                                               │
  │    │  동시에                                                          │
  │    ▼                                                               │
  │   T2: LOCK-X(B) ──▶ LOCK-S(A) ──▶ ⏳ 대기 중 (A의 S-Lock 획득 시도)  │
  │                                                                       │
  │   대기 그래프:                                                        │
  │   T1 ──▶ T2 (T1이 B의 S-Lock 대기)                                    │
  │   T2 ──▶ T1 (T2가 A의 S-Lock 대기)                                    │
  │   → 순환 대기 → Deadlock!                                            │
  │                                                                       │
  └───────────────────────────────────────────────────────────────────────┘

[다이어그램 해설] 교착 상태는 잠금 순서가 다르기 때문에 발생한다. T1이 A→B 순서로 잠금을 획득하고, T2가 B→A 순서로 잠금을 획득하면, T1은 A를 배타적으로, T2는 B를 배타적으로 선점한 상태에서 서로가 가진 잠금의 공유 버전을 기다리게 된다. 이 순환 대기 상황을 해결하기 위해서는 교착 감지(Deadlock Detection) 후 한 트랜잭션을victim으로 선택하여 롤백하거나, 교착 예방(Deadlock Prevention) 프로토콜(Wound-Wait, Wait-Die)을 사용해야 한다.

섹션 요약 비유

2PL은 식당 웨이터两组가 서로 다른 순서로桌을 서비스하는 것과 같다. 한 조的服务원이 A桌 잔을 치우는 동안 다른 조가 B桌을 정리하면, 서로给对方桌을 기다리는Deadlock 상황이 발생할 수 있다.


Ⅲ. 융합 비교 및 다각도 분석

비교: 2PL vs Timestamp Ordering vs Optimistic

구분2PLTimestamp OrderingOptimistic CC
동시성 수준높음중간높음 (경쟁 적을 때)
교착 가능성있음없음거의 없음
롤백 빈도낮음중간높음 (경쟁 심할 때)
주 사용Oracle, MySQL과거 시스템메모리 DB

과목 융합 관점

  • 컴퓨터구조 (CA): 2PL의 두 단계(Growing/Shrinking)는 파이프라인의Fetch/Execute 단계와 유사한 구분이다.
  • 네트워크 (Network): TCP의 3-way handshake는 연결 수립(잠금 획득)과 해제(잠금 해제)의 단계 개념이 있다.

섹션 요약 비유

2PL은 건설 현장의 크레인과 같다. 물건을 모두 싣고(확장 단계), 목적지에 내려놓고(수축 단계), 내려놓은 후에는 다시 실으러 가지 않는다.


Ⅳ. 실무 적용 및 기술사적 판단

실무 시나리오

  1. 시나리오 — 동일 순서 잠금 강제: 모든 트랜잭션이 동일한 순서로 객체에 접근하도록 규칙을 정하면, 순환 대기 가능성을 원천 차단할 수 있다. 예컨대 "항상 account_id 오름차순으로 잠금을 획득"이라는 규칙을 적용하면, T1이 A→B 순서, T2가 A→B 순서로 접근하므로 교착이 발생할 수 없다.

  2. 시나리오 — Victim 기반 교착 해결: 교착 상태가 감지되면, 비용이最小的 트랜잭션을victim으로 선택하여 롤백한다. 롤백된 트랜잭션은 다시 시작하므로, 전체 시스템의 처리량은 유지하면서 교착을 해소한다.

도입 체크리스트

  • 기술적: 잠금 순서 규칙이 모든 개발자에게 공표되었는가? 교착 감지 주기와 타임아웃 값이 적절한가?
  • 운영·보안적: 교착 발생 시 롤백 되는 트랜잭션이 중요한 트랜잭션인지 모니터링하는가?

안티패턴

  • 잠금 순서 불일치: 다른 개발자가 다른 순서로 잠금을 획득하면 교착 가능성이大增한다.
  • 확장 단계에서의 논잠금 연산: 2PL 위반을 방지하기 위해 트랜잭션 내부의 모든 데이터 접근이 잠금으로 보호되어야 한다.

섹션 요약 비유

잠금 순서 강제는 톨게이트 차선 규칙과 같다. 모든 차가同一 차선(예: 중앙선左侧)에서 추월하면 사고 가능성이 크게 줄어드는原理이다.


Ⅴ. 기대효과 및 결론

정량/정성 기대효과

구분2PL 미적용2PL 적용개선 효과
정량비 직렬 가능 결과: 수십 회/일0회데이터 무결성 100% 보장
정량교착 가능성: 높음교착 감지 후 해결시스템 안정성 향상
정성결과 비결정적결과 결정적예측 가능성 향상

미래 전망

  • adaptive 2PL: 트랜잭션 작업량을 동적으로 분석하여 잠금 Granularity와 모드를 조절하는 연구가 진행 중이다.
  • 분산 2PL: 클러스터 환경에서 중앙 잠금 관리자의 bottleneck을 해결하기 위해 분산 잠금 메커니즘이 발전하고 있다.

섹션 요약 비유

2PL은 연극의台本과 같다. 배우들이台本的顺序에 따라 행동하면(잠금 순서 준수), 어떤 조합으로 연습해도(동시 실행) 최종 공연(결과)은同一하다(직렬 가능).


📌 관련 개념 맵 (Knowledge Graph)

개념 명칭관계 및 시너지 설명
교착 상태 (Deadlock)2PL은 직렬 가능성은 보장하지만 교착은 보장하지 못하므로, 교착 감지/예방 메커니즘이 필수적이다.
직렬 가능성 (Serializability)2PL의 최종 목표로, 동시 실행 결과가 어떤 직렬 실행 결과와 동일함을 보장한다.
잠금 (Lock)2PL의 구현 수단으로, S-Lock과 X-Lock의 두 모드가 있다.
캐스케이드 롤백Basic 2PL에서 발생할 수 있는 현상으로, Strict/Rigorous 2PL로 방지한다.
격리 수준2PL 위에서 READ COMMITTED, REPEATABLE READ 등 다양한 수준을 구현한다.

👶 어린이를 위한 3줄 비유 설명

  1. 2PL은 냉장고 정리 규칙과 같아서, 필요한 재료를 모두 꺼낸 후(확장 단계) 요리하고, 다 쓴 후에는 반납만 해(수축 단계).
  2. 요리사가 재료를 사용한 후 즉시 냉장고에 넣고, 그 후에 필요한 재료를 다시 꺼내려 하면 곤란하듯, 컴퓨터도 먼저 다 쓴 후 반납해야 해요. 3.建造游戏中 크레인이 물건을 내려놓은 후(잠금 해제)에는 다시 같은 물건을 실으면困反하기 때문에, 내려놓은 후에는 다른 물건을 취급해야 해요.