211. 직렬 가능 스케줄 (Serializable Schedule) - 비직렬 실행 결과 직렬 스케줄 동일 보장 데이터베이스 트랜잭션 동시성 제어 목표 무결성

핵심 인사이트: (209, 210번 종합 결론) "야! 209번 직렬 스케줄은 1명씩 들여보내서 데이터가 100% 안전한데 속도가 거북이고, 210번 비직렬 스케줄은 10만 명을 마구잡이로 섞어서 짬뽕으로 돌렸더니 속도는 로켓인데 잔고 데이터가 박살이 났잖아!! 이 딜레마를 어떻게 깨?! 답은 하나야. 비직렬처럼 10만 명의 쿼리를 미친 듯이 섞어 치긴 섞어 쳐!! 근데 그 수만 가지 섞는 방법 중에, **'최종적으로 은행 계좌 잔고를 까봤을 때, 1명씩 안전하게 처리했던 직렬 스케줄과 결과값이 소름 돋게 100% 똑같이 떨어지는 마법의 황금 섞기 패턴'**만 골라서 통과시켜!! 그럼 체감 속도는 로켓이면서 데이터는 신처럼 완벽하게 안전하잖아!!" 동시성(성능)과 일관성(안전), 두 마리 토끼를 동시에 잡아낸 현대 DB 엔진의 궁극적 존재 이유, 직렬 가능 스케줄이다.

Ⅰ. 성능과 안전의 극한 대립 (딜레마 요약)

• 직렬 (Serial): 교차(인터리빙) 금지 ➜ 동시성 0% (최악의 속도) ➜ 일관성 100% (최고의 안전)
• 비직렬 (Non-Serial): 마구 교차 ➜ 동시성 100% (최고의 속도) ➜ 일관성 0% (5대 재앙 폭발)
• 어떻게 하면 여러 개를 섞어 치면서도(빠르게) 데이터가 절대 오염되지 않게(안전하게) 만들 수 있을까요?

Ⅱ. 직렬 가능 스케줄 (Serializable Schedule)의 개념 🌟

• 개념: 분명히 여러 트랜잭션의 연산을 이리저리 뒤섞어서 병행 실행(비직렬 스케줄 형태)했지만, 그 모든 연산이 끝난 후의 데이터베이스 '최종 결과 상태'가, 트랜잭션들을 섞지 않고 1명씩 순차적으로 실행(직렬 스케줄 형태)했을 때의 결과 상태와 수학적으로 100% 정확히 일치함을 보장해 주는 기적의 짬뽕 스케줄입니다.

Ⅲ. 어떤 섞기 패턴이 직렬 가능한가? (작동 원리) 🌟 핵심 🌟

비직렬로 마구 섞은 수만 가지 시간표 중에, 어떤 놈이 착한 놈(직렬 가능)이고 어떤 놈이 나쁜 놈(데이터 파괴)인지 알아내는 기준입니다.

1. 충돌(Conflict) 연산의 비밀

• 두 개의 트랜잭션 T1, T2가 **똑같은 데이터(예: 홍길동의 잔고 엑셀 칸)**에 접근할 때, 둘 중 하나라도 **'쓰기(Write/Update)'**를 하려고 들면 두 연산은 서로 싸우는 **'충돌 연산'**이 됩니다. (Read-Write 충돌, Write-Write 충돌)
• 반대로 둘 다 '읽기(Read-Read)'만 하면 100만 명이 동시에 읽어도 절대 충돌이 안 납니다.

2. 충돌 직렬 가능 (Conflict Serializable)의 마법 🌟 (212번 스포일러)

• 섞어놓은 시간표(비직렬) 안에서, 충돌하지 않는 착한 연산(Read-Read나, 아예 서로 다른 데이터 건드리는 놈들)들의 순서는 앞뒤로 마구마구 바꿔치기(Swap)해도 최종 결과에 단 1%의 영향도 안 줍니다!
• 이렇게 순서를 내 마음대로 교환(Swap)해서 싹싹 밀어봤더니, 어라? 처음에 난장판으로 섞여 있던 짬뽕 시간표(비직렬)가 어느새 'T1 ➜ T2' 처럼 깔끔하게 줄을 선 모범생 시간표(직렬 스케줄) 모양으로 완벽하게 변신(변환)했습니다!
• 이렇게 마구 섞인 시간표가 수학적 교환 법칙을 통해 직렬 스케줄로 완벽히 성형(변환)될 수 있다면, 그 섞인 시간표는 무조건 100% 데이터 안전이 보장되는 **'직렬 가능 스케줄(Serializable Schedule)'**로 합격 도장을 받습니다.

Ⅳ. 현대 DBMS의 목표와 구현 (어떻게 달성하나?)

• 모든 상용 데이터베이스 엔진(Oracle, MySQL)의 '동시성 제어 칩'은 **"수많은 유저가 쏜 쿼리를 섞어 칠 때, 오직 이 '직렬 가능 스케줄'로 판명된 안전한 패턴만 허락하고, 조금이라도 모순이 터질 것 같은 섞기 패턴은 자물쇠(Lock)로 가차 없이 막아버리거나 롤백시켜라!"**라는 유일한 지상 목표를 향해 돌아갑니다.
• 달성 무기: 이것을 완벽하게 구현하기 위해 216번의 **'2단계 락킹 프로토콜(2PL)'**이나 222번의 '타임스탬프 오더링' 같은 무지막지한 수학적 통제 알고리즘이 등장하게 됩니다.

📢 섹션 요약 비유: **직렬 가능 스케줄(Serializable Schedule)**은 천재 칵테일 바텐더(DB 엔진)의 **'절대 실패하지 않는 황금비율 흔들기 마술'**입니다. 바텐더에게 오렌지 주스 주문(T1)과 포도 주스 주문(T2)이 동시에 쏟아집니다. 만약 한 명씩 순서대로 주스를 따르면(직렬 스케줄) 손님들이 기다리다 늙어 죽습니다. 만약 컵 하나에 오렌지와 포도를 마구 섞어 따르고(최악의 비직렬 스케줄) 나눠 마시라고 주면 맛이 썩어버려(데이터 모순, 갱신 손실) 손님이 컴플레인을 겁니다. 이 천재 바텐더(직렬 가능 스케줄)는 양손에 각기 다른 컵을 쥐고 두 주스를 공중에서 1초에 10번씩 묘기를 부리며 동시에 교차로 따릅니다(인터리빙 섞기). 겉보기엔 미친 듯이 섞어 짜는 난장판 비직렬 스케줄 같지만, 바텐더의 기가 막힌 손목 스냅(동시성 제어 알고리즘) 덕분에 단 한 방울의 주스도 옆 컵으로 튀지 않습니다(충돌 회피). 쇼가 끝난 뒤 손님들에게 전달된 컵을 보면, 오렌지 주스와 포도 주스가 한 방울도 안 섞이고 한 명씩 순서대로 조심해서 따랐을 때(직렬 스케줄)와 맛과 용량이 소름 돋게 100% 똑같이 유지된 채로 완성되어 있습니다. 여러 손님을 동시에 퍼포먼스로 접대해(동시성 100%) 속도는 로켓처럼 뽑아내고, 최종 맛(일관성 100%)은 순서대로 한 것과 똑같이 완벽하게 지켜내는 DB 동시성 제어의 궁극의 마스터피스입니다.