196. 영속성 (Durability) - 지속성 성공 완료 트랜잭션 영구 반영 데이터베이스 회복(Recovery) 관리자 Redo 재실행 디스크 쓰기 보장

핵심 인사이트: (192번 ACID 심화) 내가 100억짜리 빌딩을 인터넷 뱅킹으로 송금했다. 은행 앱에 "100억 송금 성공!(COMMIT)"이라는 초록색 V 마크가 선명하게 떴다. 나는 안심하고 폰을 껐다. 그런데 그 성공 메시지가 뜬 지 0.001초 뒤에, 은행 데이터센터 건물에 소행성이 떨어져 박살이 났다! 은행 서버가 재부팅 된 뒤 내 100억 송금 내역이 허공으로 날아가 버렸다?! "야!! 장난하냐!! 나한테 분명히 '성공(COMMIT)'이라고 알람 띄웠잖아!! 네가 무슨 짓을 해서든, 네 건물이 타버리든 하드디스크가 부서지든 간에 한 번 나한테 성공이라고 도장 찍어준 결제 내역은 우주가 멸망할 때까지 무조건 보존해 내야지!!" DB가 고객에게 바치는 무서운 목숨 건 불멸의 서약, 영속성이다.

Ⅰ. 메모리(RAM)와 디스크의 물리적 딜레마

컴퓨터 구조(CA)의 잔인한 물리 법칙이 DB를 괴롭힙니다.

  • 속도가 생명인 DB는 송금 쿼리가 들어오면 하드디스크에 안 쓰고, 일단 속도가 미친 듯이 빠른 컴퓨터 램(메모리 버퍼 캐시) 위에서 연산을 끝내버리고 "성공(COMMIT)!"을 때려버립니다.
  • 재앙의 씨앗 (휘발성): 램(RAM)에 있는 데이터는 전원이 툭 끊기면 그 즉시 증발해 0과 1의 먼지로 날아갑니다. 램에서 COMMIT을 찍었는데 아직 느려터진 하드디스크로 옮겨 적기(Flush) 전에 정전이 났다? 영원히 사라지는 겁니다.

Ⅱ. 영속성 (Durability / 지속성)의 절대 정의 🌟

  • 개념: 트랜잭션이 모든 작업을 무사히 끝내고 성공적으로 완료(Committed)되었다면, 그 결과(업데이트된 100억 잔고)는 시스템이 뻗거나 하드웨어 크래시가 발생하더라도 절대로 소실되지 않고 데이터베이스에 '영구적으로(Permanently)' 살아남아 반영되어야 한다는 철칙입니다.
  • 즉, 한 번 뱉은 "성공!"이라는 말의 책임은 지구가 두 쪽 나도 기계가 책임져야 한다는 뜻입니다.

Ⅲ. 영속성을 수호하는 자: 회복 관리자 (Recovery Manager) 🌟 핵심 🌟

램(RAM)이 뻗어도 어떻게 죽은 데이터를 멱살 잡고 살려낼까요? 193번에서 배운 일기장(Log)이 또 등장합니다.

1. WAL (Write-Ahead Logging) - 일기장 선빵 필승

가장 위대한 데이터 생존 마법입니다.

  • 트랜잭션이 COMMIT 버튼을 누르는 찰나, DB는 멍청하게 느린 진짜 데이터 파일(.mdf)에 100억을 고쳐 쓰려고 시간 낭비하지 않습니다.
  • 대신 "A가 B에게 100억 줬다!"라는 텍스트 한 줄만 가볍고 빠른 '로그 파일(디스크의 Redo Log)' 끝에다가 빛의 속도로 휘갈겨 써버리고 무조건 디스크에 강제 저장(Sync/Flush)해 버립니다.
  • 일기장에 쓰는 게 진짜 데이터 파일에 쓰는 것보다 훨씬 빠르기 때문에, 로그 파일에 도장을 찍자마자 유저에게 "결제 성공!" 알람을 빵 띄워버립니다.

2. REDO (재실행) 마법 - 부활의 주문 🌟 기출 단골 🌟

로그 파일에 도장은 찍었지만, 아직 진짜 데이터 파일(엑셀)에는 100억이 안 적힌 상태로 은행 서버가 정전으로 죽어버렸습니다.

  • 부활: 서버 전원이 다시 켜집니다.
  • 회복 관리자 출동: 일어나자마자 일기장(Log)부터 미친 듯이 까봅니다. "어? 일기장에 '100억 송금 COMMIT 완료됨' 도장은 찍혀있는데, 진짜 엑셀 파일(데이터) 까보니까 적용이 안 돼 있네? 이 새끼 램에 뒀다가 꺼지면서 디스크에 쓰는 거 까먹고 죽은 놈이네!"
  • REDO 실행: 회복 관리자는 일기장에 적힌 내역을 보고, 100억 송금 쿼리를 **처음부터 똑같이 다시 실행(REDO, 재실행)**해서 진짜 엑셀 파일에 강제로 쑤셔 박아버립니다. (193번의 취소 UNDO와 정반대 개념!)
  • 결과적으로 서버가 타버려도 고객의 100억 결제는 무조건 100% 살아남아 영속성이 달성됩니다.

Ⅳ. 성능과의 트레이드오프 (Sync의 딜레마)

  • 영속성을 100% 지키려면 무조건 쿼리 1번 칠 때마다 디스크(로그 파일)에 I/O를 찍어야 합니다. 엄청난 병목입니다.
  • 그래서 성능에 미친 기업들(게임 서버 등)은 설정 옵션(innodb_flush_log_at_trx_commit=2)을 살짝 비틀어서, "디스크에 1초마다 몰아서 한 번에 쓸게!"라고 영속성을 살짝 훼손하면서 속도를 10배 뻥튀기하는 무서운 줄타기를 실무에서 흔히 합니다.

📢 섹션 요약 비유: 데이터베이스의 **영속성(Durability)**은 법원 등기소의 **'절대 파괴 불가능한 강철 대장부의 맹세'**입니다. 내가 땅을 샀습니다. 등기소 직원이 컴퓨터 전산망(RAM)에 "철수 땅 샀음"이라고 타이핑만 치고 나한테 "도장 쾅(COMMIT)! 이제 당신 땅입니다!"라고 말했습니다. 근데 1초 뒤에 등기소 컴퓨터가 불타서 꺼졌습니다(시스템 크래시). 전산망에서 데이터가 날아갔으니 내 땅이 없어질까요? 절대 안 됩니다. 영속성의 마법인 WAL(미리 쓰기)과 REDO(재실행) 덕분입니다. 등기소 직원은 나한테 "성공!"이라고 외치기 직전 0.001초 찰나에, 무조건 옆에 있는 불에 타지 않는 **'강철 비상수첩(Redo Log)'**에다 볼펜으로 꾹꾹 눌러 "철수 땅 샀음. 확정."이라고 무조건 1줄을 쓰고 철제 금고에 던져 넣었습니다. 나중에 컴퓨터를 새로 사서 부팅하면 직원은 강철 금고부터 열고 비상수첩을 봅니다. "아! 컴퓨터 뻗기 전에 철수 땅 샀다고 약속했었네!" 직원은 즉시 컴퓨터에 그 내역을 다시 타이핑(REDO)하여 완벽하게 복구해 냅니다. 서버가 가루가 되어도 고객과 한 번 맺은 성공(COMMIT)의 약속은 무덤 끝까지 지켜내는 DB 최후의 불사조 생존술입니다.