236. WAL (Write-Ahead Logging) 프로토콜 - 데이터 갱신 전 로그 기록 트랜잭션 회복 영속성 성능 최적화 오버헤드

핵심 인사이트: (234, 235번 회복을 굴리는 궁극의 전제 조건) 234번에서 DB가 죽었다 깨어나면 '블랙박스 일기장(로그 파일)'을 보고 죽은 데이터를 다시 살려낸다(Redo, Undo)고 했다. 근데 만약, DB가 엑셀 원본(디스크)을 먼저 뜯어고친 다음에, 귀찮다고 "아따, 로그 일기장은 10분 뒤에 몰아서 천천히 하드디스크에 적어둬야지~" 라고 미루는 순간 벼락이 친다면?! 엑셀 원본은 똥이 묻었는데, 로그 일기장은 디스크에 안 적히고 허공에 날아갔다! DB가 눈을 떴을 때 일기장이 없으니 Redo/Undo 흑마법을 쓸 수가 없어서 그대로 은행 전산망이 영구 파괴된다!! "야 이 미친놈아!! 엑셀 원본(Data) 디스크에 고친 글씨를 저장(Write)하는 건 천천히 해도 좋고 1시간 뒤에 해도 좋아! 하지만 그 어떤 일이 있어도, 네가 방금 '무슨 짓을 했는지 적어둔 1줄짜리 일기장(Log)'만큼은, 엑셀 원본보다 '무조건 앞서서 먼저(Ahead)' 단단한 쇳덩어리 하드디스크에 안전하게 쾅! 박아버리고 엑셀을 고쳐라!!" 전 세계 모든 상용 DB의 멱살을 잡고 있는 최우선 생존 절대 법규, WAL(Write-Ahead Logging)이다.

Ⅰ. 디스크 쓰기의 미친 속도 딜레마

  • 하드디스크(쇳덩어리)는 메모리(RAM)보다 속도가 10만 배 느립니다.
  • 손님 1명이 돈을 보낼 때마다 10GB짜리 메인 엑셀 파일(Data File)을 열어 디스크에 매번 실시간으로 덮어쓰기(Write)를 때리면, DB 서버는 버벅대다가 그 자리에서 폭발합니다.
  • 그래서 234번에서 말했듯, DB는 엑셀 내용을 일단 '빠른 RAM 메모리 버퍼'에만 살짝 고쳐두고 꿀을 빨다가, 나중에 한가할 때 디스크로 한 번에 몰아서 스윽 내보냅니다(Flush).

Ⅱ. WAL (Write-Ahead Logging) 프로토콜의 개념 🌟

  • Write-Ahead (앞서서 먼저 쓰다) + Logging (일기장을)
  • 개념: 메모리(버퍼)에 있는 엑셀 변경 데이터가 쇳덩어리 디스크(Data File)로 덮어 쓰여 기록되기 전에는, 그 변경 사항에 대한 이력을 적어둔 '로그(Log) 데이터'가 하늘이 두 쪽 나도 반드시 쇳덩어리 디스크(Log File)에 '먼저' 안전하게 기록되어 있어야만 한다는 절대적인 트랜잭션 회복 규칙입니다.

Ⅲ. 왜 로그(Log)부터 먼저 쓸까? (WAL의 핵심 천재성) 🌟 기출 🌟

1. 로그는 한 줄짜리 새치기(Append)라 미치도록 빠르다!

  • 10GB짜리 메인 엑셀(데이터 파일)을 중간에 열어서 덮어쓰기(Random Write) 하는 건 기계 팔이 미친 듯이 움직여야 해서 엄청 무겁고 느립니다.
  • 반면, 로그 파일은 그냥 맨 밑바닥에다가 텍스트로 "<T1, 잔고, 10만, 5만>" 이라고 한 줄 살짝 덧붙이고(순차 쓰기, Sequential Append) 빠지면 끝입니다. 속도가 메인 엑셀 덮어쓰기의 100배 이상 미치도록 빠릅니다.
  • 천재적 전략: 느려 터진 메인 엑셀 저장은 메모리에 냅두고 나중에 미루더라도, 빛의 속도로 1줄만 쓰면 끝나는 이 '로그 일기장'만큼은 실시간으로 디스크에 쾅 박아두는 게 성능(속도) 저하를 최소화하면서도 완벽한 생명줄(영속성)을 챙기는 궁극의 가성비라는 것을 깨달은 것입니다.

2. 최후의 보루 (Undo / Redo의 보장)

  • 만약 WAL을 안 지킨다면? (재앙): 엑셀 원본(디스크)이 '5만 원'으로 오염되었는데, 로그 일기장은 메모리에 떠 있다가 벼락을 맞고 날아갔습니다. 부팅 후 DB는 "어? 엑셀이 5만 원인데, 이게 맞는 거야 틀린 거야? 지워야(Undo) 해?" 로그가 없으니 판단을 못 하고 시스템 무결성이 영구 붕괴합니다.
  • WAL을 지켰다면? (부활): 벼락을 맞아 메모리가 날아가도, 쇳덩어리 디스크 안에는 "T1이 아까 10만을 5만으로 고치려다 죽었음" 이라는 로그 1줄이 완벽하게 생존해 있습니다. 이걸 쥐고 235번 흑마법(Undo)을 발동해 쓰레기를 완벽하게 닦아냅니다.

Ⅳ. 트랜잭션 COMMIT의 진짜 의미 🌟 실무 핵심 🌟

  • 개발자가 COMMIT 버튼을 누르면 화면에 0.01초 만에 "성공!"이 뜹니다.
  • 비밀: 이때 메인 엑셀 쇳덩어리(Data File)에 저장이 끝난 게 아닙니다!! DB는 메인 엑셀 저장은 뒷전으로 냅두고, 오직 "네 로그(Log) 1줄을 쇳덩어리(Log File)에 방금 무사히 쾅 박아넣었어! 나중에 메인 엑셀 날아가도 이 로그 보고 100% 살려줄게(Redo) 보장해!!"라는 뜻으로 "성공(COMMIT)!"을 뱉어주는 것입니다. 이것이 현대 DB가 로켓 속도로 결제를 쳐내면서도 데이터가 절대 날아가지 않는 (영속성) 기적의 이유입니다.

📢 섹션 요약 비유: WAL (Write-Ahead Logging) 프로토콜은 바쁘디바쁜 은행 금고의 **'원본 장부 미루기 & 1줄 메모지 선방 날리기 기술'**입니다. 은행원(DB 엔진)이 10만 명의 손님을 응대합니다. 손님이 1만 원을 입금할 때마다 저 지하 창고에 있는 100kg짜리 두꺼운 원본 철제 장부(디스크 Data File)를 낑낑대며 꺼내와서 지우개로 빡빡 지우고 덮어쓰고(Write) 다시 집어넣으면 은행은 병목으로 터져 망합니다(속도 최악). 천재 은행원은 원본 장부는 냅두고, 책상 위에 아주 얇은 '포스트잇 메모장(로그 파일 Log)' 하나만 꺼내 놓습니다. 손님이 오면 포스트잇에 볼펜으로 "철수 1만 입금(로그)" 이라고 1초 만에 휘갈겨 적고(Sequential Append) 지갑에 찔러 넣습니다(디스크 안전 보장). 그리고 손님에게 "수고하셨습니다(COMMIT)!" 하고 즉각 돌려보냅니다. 원본 철제 장부 업데이트는 은행 문 닫고 밤에 천천히 한 방에 몰아서 고칩니다(지연 갱신). 만약 점심때 은행에 폭탄이 떨어져 책상(메모리)이 날아가도? 은행원의 딴딴한 지갑 속에 넣어둔 '포스트잇 메모장 뭉치(로그 파일)'는 살아남아 있으므로, 나중에 그 메모장만 보고 철제 장부를 완벽하게 재건(Redo)해 낼 수 있습니다. 메인 데이터를 늦게 적는 한이 있더라도, 그 변경 사실(Log)만큼은 반드시 가장 앞서서(Ahead) 안전한 곳에 쑤셔 박아둬야 성능과 안전을 모두 잡을 수 있다는 클라우드 시대 DB의 절대 헌법입니다.