219. 2PL의 한계 - 교착 상태(Deadlock) 연쇄 복귀(Cascading Rollback) 2단계 락킹 프로토콜 문제점 병행 제어 오버헤드 엄격한 2PL 필요성

핵심 인사이트: (217, 218번 총정리) 2단계 락킹(2PL)이라는 완벽해 보이는 법규를 도입했다. 이걸 쓰면 100% 직렬 가능 스케줄(안전빵)이 나오니 학자들이 샴페인을 터뜨렸다. 하지만 얼마 안 가 서버가 멈춰버렸다. "야!! 1단계(확장)에서 한 번 쥔 락을 절대 못 놓게 법으로 묶어버리니까, 서로 남의 락 내놓으라고 멱살 잡고 영원히 멈추는 데드락(Deadlock) 지옥이 열렸잖아!! 게다가 2단계(축소)에서 락을 툭툭 버리며 내려오니까, 딴 놈이 그 덜 익은 데이터 락을 주워 먹었다가 내가 롤백 치면 도미노처럼 다 같이 뒤지는 연쇄 복귀(Cascading Rollback) 대참사까지 터졌어!!" 100% 안전을 약속했지만, 현실 세계의 2가지 거대한 절망(멈춤과 연쇄 파괴)을 방치해버린 반쪽짜리 방패, 2PL의 치명적 한계다.

Ⅰ. 완벽함 이면에 숨겨진 독약 (2PL의 한계 개요)

  • 216번에서 배웠듯, 2단계 락킹 프로토콜(2PL)을 지키면 스케줄이 무조건 '직렬 가능(Serializable)' 해집니다. 즉, 202번에서 배운 갱신 손실, 모순성, 유령 읽기 같은 '데이터 오염 에러'는 100% 완벽하게 수학적으로 차단됩니다.
  • 그러나 DB 엔진을 설계하는 룰을 너무 딱딱하게 강제한 부작용으로, 데이터 오염은 없지만 시스템 운영 자체가 아예 먹통이 되거나 미친 비효율이 터지는 2가지 치명적인 물리적 한계점이 필연적으로 발생합니다. (이 2가지는 정보처리기사 단골 서술형 문제입니다.)

Ⅱ. 한계 1: 교착 상태 (Deadlock) 발생의 필연성 🌟 (확장 단계의 저주)

  • 217번의 '확장 단계(Growing Phase)' 규정은 무시무시합니다. "네가 가진 락(Lock)을 하나라도 풀면 즉시 확장 단계 아웃이다!"
  • 상황:
    • T1은 계좌 A를 수정하려고 X-Lock을 쥐었습니다. 이제 계좌 B의 락을 달라고 요청합니다.
    • T2는 계좌 B를 수정하려고 X-Lock을 쥐었습니다. 이제 계좌 A의 락을 달라고 요청합니다.
  • 절망의 딜레마: T1과 T2 모두 아직 자물쇠를 모으는 1단계(확장)에 있습니다. 만약 룰이 없었다면 T1이 "아유 내가 먼저 양보해서 A락 풀고 기다릴게" 하고 풀어주면(Unlock) 엉킨 실타래가 풀립니다.
  • 하지만 2PL의 절대 법규는 양보(Unlock)를 1%도 허락하지 않습니다. 양보하는 순간 확장 단계에서 쫓겨나 더 이상 남은 B락을 얻을 수 없어 영원히 일을 못 끝내기 때문입니다.
  • 결과: 결국 누구도 자신이 손에 쥔 락을 절대 풀지 못하고 영원히 서로를 기다리는 데드락(Deadlock)의 수렁에 빠져 시스템 전체가 뻗어버립니다. 2PL은 이를 절대 원천 예방하지 못합니다.

Ⅲ. 한계 2: 연쇄 복귀 (Cascading Rollback)의 지옥 🌟 (축소 단계의 저주)

  • 218번의 '축소 단계(Shrinking Phase)' 규정은 "락 포인트를 지나면 쥐고 있던 락을 하나씩 풀어라(Unlock)"입니다.
  • 상황 (오손 읽기 Dirty Read 파생):
    • T1이 계좌 A에 10만 원을 덮어쓰고(수정 완료), 아직 COMMIT 도장(완벽한 종료)을 안 찍은 상태에서, 축소 룰에 따라 쿨하게 계좌 A의 락(X-Lock)을 땅에 버렸습니다(Unlock).
    • 뒤에서 대기 타던 T2가 떨어진 락을 냉큼 줍고 들어가서, 그 덜 익은 쓰레기 10만 원 데이터를 읽어갑니다.
    • 1초 뒤! T1이 마지막 코드에서 에러가 터져 멘탈이 나가며 "아 ㅆㅂ 나 돌아갈래! ROLLBACK!!" 쳐버립니다.
  • 결과: T1이 만든 허깨비 데이터를 진짜인 줄 알고 주워 먹고 일하던 T2, 그리고 T2가 만든 데이터를 주워 먹은 T3, T4 수십 명이 도미노 핀 쓰러지듯 모조리 다 멱살 잡혀 과거로 롤백(연쇄 취소) 당하는 거대한 낭비의 참사가 터집니다. 2PL 기본형은 너무 일찍 락을 풀어버리는 혀의 가벼움 때문에 이 재앙을 막지 못합니다.

Ⅳ. 이 한계를 부수기 위한 진화 (220, 221번 스포일러)

  • 데드락 해결책: 2PL 자체로는 답이 없으므로, OS처럼 주기적으로 DB를 스캔해서 멱살 잡고 있는 놈들 중 한 놈을 몽둥이로 때려죽여서(희생자 선정) 강제 롤백시키는 데드락 탐지(Detection) 꼼수를 병행해서 써야 합니다.
  • 연쇄 복귀 해결책: "야! 2단계 축소고 나발이고, 네가 완전히 COMMIT 도장을 쾅 찍어서 100% 확정 짓기 전까지는 X-Lock(배타 락)을 바닥에 절대 던지지 말고 뒤질 때까지 꽉 쥐고 있어!!" 라며 룰을 독재적으로 개조한 **엄격한 2PL(Strict 2PL)**과 **강건한 2PL(Rigorous 2PL)**이라는 폭군들이 등장하여 현대 DB(Oracle, SQL Server)의 천하통일을 이루게 됩니다.

📢 섹션 요약 비유: 기본형 2PL의 한계는 도로 위의 **'융통성 제로의 멍청한 직진 신호등'**과 같습니다. 신호등(2PL) 덕분에 차들이 옆면을 때려 박는 끔찍한 교통사고(직렬 가능성 파괴)는 100% 막아냈습니다. 하지만 두 가지 심각한 부작용이 터집니다. 첫째, 교차로 꼬리물기(Deadlock)입니다. 내 차가 1단계(확장)라 직진만 해야 하는데 앞차가 막고 있고, 앞차는 옆 차가 막고 있어 꼬리에 꼬리를 무는 사각형 갇힘 상태가 발생합니다. 누구 하나 룰을 어기고 뒤로 후진(Unlock 양보)하면 풀릴 텐데, 2PL 룰 때문에 절대 후진을 못 하니 사거리가 평생 마비됩니다(교착 상태). 둘째, 미완성 공사장의 나비효과(Cascading Rollback)입니다. 앞차가 아스팔트를 까는 공사(T1)를 다 안 끝냈는데 신호등 2단계(축소) 룰에 따라 일단 차단봉(Lock)을 풀어버렸습니다. 뒤차(T2)가 신나게 들어왔다가 덜 굳은 시멘트(Dirty Data)에 바퀴가 빠졌습니다. 1초 뒤 앞차 공사 반장이 "아, 이 시멘트 불량이야 다 뜯어내(ROLLBACK)!"라고 해버리니, 뒤따라 시멘트에 들어왔던 수십 대의 자동차들까지 모조리 크레인으로 견인당해 강제 폐차(연쇄 롤백)되는 생지옥이 열립니다. 안전을 위해 만든 법이 오히려 도로의 흐름을 지옥으로 만들어버리는 맹점입니다.