195. 격리성 (Isolation) - 고립성 동시성 제어 병행 제어 트랜잭션 간섭 금지 직렬화 가능성 잠금(Lock) MVCC 아키텍처

핵심 인사이트: (192번 ACID 심화) 은행 잔고에 1만 원이 있다. 내가 편의점에서 1만 원 카드를 긁었다(결제 시작). 서버가 잔고 1만 원을 읽어서 0원으로 빼기 연산을 0.001초 동안 하고 있다. 그런데 하필 그 찰나의 0.001초 타이밍에 엄마가 집에서 내 카드로 또 1만 원을 긁었다! 폰뱅킹 서버는 "어? 방금 1만 원 있었잖아!" 하고 또 결제를 허락해 버렸다(이중 결제 대참사). "야! 미쳤냐! 내가 잔고 엑셀 파일을 읽고 빼기 계산하는 그 짧은 1초 동안에는, 엄마든 사장님이든 우주 그 누구도 엑셀 파일 문을 절대 못 열고 밖에서 대기 타게 만들어!! 내가 계산 다 끝내고 0원으로 도장(COMMIT) 딱 찍고 방에서 나가야만, 다음 사람이 문 열고 들어와서 0원짜리 잔고를 보게 쇠사슬 자물쇠(Lock)를 채워버려라!!" 수백만 명의 동시 접속자 속에서도 나 혼자 있는 것처럼 만들어주는 투명 인간 밀실, 격리성이다.

Ⅰ. 동시 접속의 지옥 (간섭 현상)

  • 11번가에서 에어팟 특가 100개가 풀리면 10만 명이 동시에 접속해서 구매 버튼(트랜잭션)을 누릅니다.
  • DB 서버의 메모리(RAM) 안에서는 수만 개의 트랜잭션 스레드들이 1개의 잔고(재고) 변수를 뜯어고치려고 난투극을 벌입니다.
  • 격리성이 없으면? (202번 연계)
    • 내가 고치고 있는데 딴 놈이 그 값을 훔쳐보거나(Dirty Read), 둘이 동시에 고쳐서 내 결제 내역이 허공으로 덮어써져 날아가는(Lost Update) 데이터 모순성 대재앙이 터집니다.

Ⅱ. 격리성 (Isolation / 고립성)의 절대 정의 🌟

  • 개념: 둘 이상의 트랜잭션이 동시에 미친 듯이 병행 실행(Concurrent Execution)되고 있을 때, 어떤 한 트랜잭션이 실행되고 있는 중간 연산 과정(바뀌고 있는 덜 익은 데이터)에 다른 트랜잭션이 절대로 난입하거나 끼어들어서 간섭할 수 없게 철저하게 닫힌 방으로 격리시켜주는 성질입니다.
  • 궁극의 결과 (직렬화 가능성, Serializability): 수만 개의 트랜잭션이 동시에 마구잡이로 실행되어도, 최종 결과물은 신기하게도 마치 1번 끝내고 2번 하고 3번 한 것처럼(순차적으로 한 명씩 직렬로 실행한 것처럼) 100% 똑같이 오차 없이 안전하게 산출되어야 합니다.

Ⅲ. 격리성을 수호하는 흑마법: 병행 제어 관리자 🌟 핵심 기출 🌟

어떻게 다른 놈들이 못 끼어들게 막을까요? DB 안의 병행 제어(Concurrency Control) 모듈이 철퇴를 듭니다.

1. 자물쇠 (Locking 기법) - "내가 쓸 땐 아무도 못 만져"

  • 격리성의 가장 고전적이고 무식한 무기입니다.
  • 내 트랜잭션이 에어팟 재고(데이터)를 건드리려고 다가가는 순간, 데이터에 거대한 **배타적 자물쇠(Exclusive Lock, X-Lock)**를 채워버리고 열쇠를 내 주머니에 넣습니다.
  • 내가 재고를 99개로 깎고 도장(COMMIT)을 찍고 열쇠를 반납할 때까지, 다른 10만 명의 접속자 트랜잭션들은 데이터에 손도 못 대고 문 밖(Queue)에서 줄을 서서 하염없이 대기(Wait)하게 됩니다. 완벽한 격리 달성!

2. MVCC (다중 버전 동시성 제어) - "최신 트렌드"

  • 근데 자물쇠를 걸면 10만 명이 줄 서서 기다리느라 쇼핑몰이 버퍼링으로 터져버립니다. 너무 느립니다.
  • MVCC 마법 (오라클, MySQL 등 현대 DB 표준):
    • 내가 재고를 99개로 고치며 낑낑대고 있을 때 자물쇠를 안 채웁니다!
    • 대신 뒷사람이 들어와서 "재고 몇 개야?"라고 조회를 때리면, 내가 고치기 전의 **과거 데이터(Undo 로그에 저장된 '재고 100개' 스냅샷 사진)**를 복사해서 던져줍니다. "자, 옛날 사진 보고 있어!"
    • 쓰는 놈(나)과 읽는 놈(뒷사람)이 서로 다른 버전(다중 버전)의 데이터를 보며 각자 평화롭게 일하므로, 자물쇠로 기다릴 필요 없이 속도가 수십 배로 뻥튀기되면서도 격리성이 완벽하게 지켜지는 현대 DB의 위대한 꼼수입니다.

Ⅳ. 격리 수준 (Isolation Level)의 딜레마

격리성(I)은 독약입니다. 격리성을 100% 강하게 지키면 성능(속도)이 개박살 나고, 성능을 올리려 격리성을 살짝 풀면 205번 찌꺼기 데이터(Dirty Read)를 읽어버리는 버그가 터집니다. 그래서 SQL 표준은 "성능과 안전성 사이에서 네가 알아서 골라 써!" 라며 격리성을 4단계(Read Uncommitted ~ Serializable)의 레벨로 쪼개 놓았습니다. (실무 DB 면접 0순위 핵심 주제이며 향후 상세히 다룹니다.)

📢 섹션 요약 비유: 데이터베이스의 **격리성(Isolation)**은 은행 화장실의 **'문 잠금장치(자물쇠)'**와 같습니다. 만약 문이 없는 공중 화장실(격리성 제로)이라면, 내가 바지를 내리고 똥을 싸는 중간(미완료된 연산)에 다른 사람이 확 들어와서 나를 보고, 심지어 내 변기를 뺏어서 자기가 싸버리는 대참사(데이터 간섭 및 덮어쓰기 오염)가 벌어집니다. 격리성은 내가 화장실 칸에 들어가는 순간, 안에서 **'철컥' 하고 자물쇠(Locking)**를 걸어버리는 완벽한 사생활 보호 원칙입니다. 밖에서 수백 명(동시 접속 트랜잭션)이 똥이 마려워 죽으려고 대기해도, 절대 화장실 문을 열고 난입할 수 없습니다. 오직 내가 바지를 다 올리고 손을 씻고 나가며 '쾅(COMMIT)' 문을 열어줬을 때만 비로소 다음 사람이 깨끗한 빈 화장실을 순서대로 독차지할 수 있게 만드는(직렬화), 동시성의 지옥에서 무결점을 수호하는 가장 철저한 밀실 통제 아키텍처입니다.