276. Write-Through (동시 쓰기)

핵심 인사이트 (3줄 요약)

본질: Write-Through(동시 쓰기)는 CPU가 데이터를 변경할 때, 그 값을 캐시 메모리뿐만 아니라 하위의 메인 메모리(DRAM)에도 동시에 업데이트하여 두 장치의 데이터를 항상 똑같게 묶어두는 맹목적인 쓰기 정책이다.

가치: 캐시와 메모리의 값이 100% 일치하므로 정전이 나도 데이터가 안전하며, 멀티코어 환경에서 복잡한 캐시 일관성 프로토콜이나 더티 비트 관리 회로를 생략할 수 있는 극강의 하드웨어 단순성과 무결성을 제공한다.

융합: 치명적인 단점인 '매 쓰기마다 메모리 버스 지연(Stall) 발생'을 가리기 위해, CPU와 캐시 사이에 데이터를 잠시 던져놓고 잊어버리는 '쓰기 버퍼 (Write Buffer)' 큐 아키텍처와 반드시 한 쌍으로 융합되어 사용된다.

Ⅰ. 개요 및 필요성

개념: CPU가 1바이트의 데이터를 덮어쓸 때, 빠른 L1 캐시에 값을 갱신함과 동시에 그 즉시 시스템 버스를 타고 느려터진 메인 메모리까지 내려가 원본을 덮어쓰는 정책이다.
필요성: 캐시는 속도를 위해 만든 '가짜 복사본'이다. 만약 캐시에만 값을 고쳐놓고 원본 메모리를 방치했다가(Write-Back), 갑자기 전원 코드가 뽑히면 휘발성인 캐시에 있던 최신 데이터는 허공으로 영원히 증발해 버린다. 이처럼 **"속도가 좀 느려도 좋으니 절대 데이터가 어긋나서는 안 된다"**는 무결성 지상주의 환경에서 Write-Through는 필수적인 시스템 보증 수표다.
💡 비유: 직장인이 자기 수첩(캐시)에 일정을 수정할 때마다, 즉시 벌떡 일어나서 회사 로비에 있는 공용 캘린더(메인 메모리)까지 걸어가 똑같이 화이트보드에 수정해 놓고 돌아오는 깐깐하고 피곤한 업무 방식입니다.
등장 배경: 마이크로프로세서 초창기, CPU와 메인 메모리의 속도 차이가 그리 크지 않았을 때는 Write-Through가 대세였다. 하지만 CPU 클럭이 기하급수적으로 빨라지면서 버스 대역폭이 CPU의 쓰기 속도를 감당하지 못하게 되었고, 결국 현대의 범용 CPU들은 이 방식을 버렸으나 일부 무결성이 생명인 스토리지 캐시나 특정 MMIO 영역에서 여전히 사용되고 있다.

┌──────────────────────────────────────────────────────────────┐
│           Write-Through 정책과 병목, 그리고 쓰기 버퍼(Write Buffer) 구원     │
├──────────────────────────────────────────────────────────────┤
...

- **📢 섹션 요약 비유**: 우체국(메모리)에 편지를 부칠 때마다 직접 차를 타고 다녀오는 것(순수 Write-Through)은 시간 낭비입니다. 그래서 집 앞 대문에 작은 우체통(쓰기 버퍼)을 달아놓고 편지를 1초 만에 휙 던져 넣고 다시 집안일을 하는 것이 현대 아키텍처의 꼼수입니다.

---

## Ⅱ. 아키텍처 및 핵심 원리

### 하드웨어 단순화 (Simplicity)의 축복

Write-Through는 하드웨어 엔지니어에게 천국을 선사한다.
- **Dirty Bit 불필요**: Write-Back(나중 쓰기)은 "이 방 데이터는 원본과 다르다"는 꼬리표(Dirty Bit)를 관리해야 한다. Write-Through는 항상 원본과 똑같으므로 이 비트 자체가 아예 필요 없다.
- **간단한 방출(Eviction)**: 캐시가 꽉 차서 데이터를 쫓아낼 때, Write-Through는 "어차피 메모리랑 똑같아! 그냥 쓰레기통에 쿨하게 버려!"라며 1클럭 만에 기존 데이터를 삭제해 버릴 수 있어 미스 패널티 갱신 로직이 극도로 가볍다.

### Write Miss 발생 시의 짝꿍: No Write-Allocate
CPU가 데이터를 쓰려고 캐시를 봤는데 데이터가 없는 경우(Miss).
- **Write-Allocate**: 메모리에서 데이터를 캐시로 강제로 퍼 끌어온다.
- **No Write-Allocate**: Write-Through 방식의 영혼의 짝꿍이다. 어차피 쓸 때마다 메모리에 써야 하는데 굳이 캐시에 무겁게 데이터를 끌어올릴 필요가 없다. 캐시는 그대로 내버려 두고, 쿨하게 메모리에 있는 원본 주소에 다이렉트로 데이터를 쏘아버린다. 캐시 용량 오염을 완벽히 방어한다.

- **📢 섹션 요약 비유**: 어차피 정수기에서 물을 마실 때마다 새 컵을 쓸 거면, 굳이 무겁게 생수통 전체를 내 책상으로 낑낑대며 들고 올 필요가 없습니다. 그냥 정수기에 가서 물 한잔 마시고 버리는 것이 깔끔합니다.

---

## Ⅲ. 비교 및 연결

### Write-Through vs Write-Back 트레이드오프

| 특성 | Write-Through (동시 쓰기) | Write-Back (나중 쓰기) |
|:---|:---|:---|
| **메모리 트래픽**| 쓰기 명령이 뜰 때마다 발생 (버스 학살자) | 쫓겨날 때 딱 1번만 발생 (대역폭 절약) |
| **데이터 무결성** | **항상 100% 완벽 일치** (전원 차단에도 안전) | 캐시에만 있는 최신 값이 날아갈 위험 존재 |
| **캐시 코히런시** | 무효화 신호가 즉시 전파되어 쉬움 | 상태 천이 로직이 무겁고 통신이 복잡함 |
| **적용 워크로드**| 한 번 쓰고 다시 안 읽는 로그성 데이터 | 같은 변수를 루프에서 수만 번 고쳐 쓰는 데이터 |

### 일관성 문제에서의 맹활약
멀티코어 환경에서 4개의 코어가 각자 캐시를 들고 싸울 때 일관성을 맞추는 건 지옥이다. 하지만 L1 캐시를 모조리 Write-Through로 만들어버리면 어떻게 될까? 코어 1이 변수를 수정하자마자 메인 버스에 "나 메모리 쓴다!"라고 쩌렁쩌렁 소문을 내게 된다. 나머지 코어들은 버스를 지켜보고 있다가 "어? 저 주소 나도 들고 있는데?"라며 즉시 자기 캐시의 데이터를 무효화해 버리면 된다. 엄청나게 간단한 스누핑 프로토콜로 멀티코어를 쉽게 묶어낼 수 있다.

- **📢 섹션 요약 비유**: Write-Through는 '모두에게 공개된 카톡방'입니다. 내가 말을 바꿀 때마다 카톡방에 쳐서 모두가 즉시 알게 되니 데이터 불일치가 없습니다. 반면 Write-Back은 '개인 일기장'에 혼자 쓰고 나중에 발표하는 식이라, 발표 전까지 다른 사람들은 내가 무슨 생각을 하는지 모릅니다.

---

## Ⅳ. 실무 적용 및 기술사 판단

### 실무 시나리오

1. **데이터베이스 복구 아키텍처 (WAL 패턴)**
   오라클이나 PostgreSQL에서 정전 시 데이터가 날아가는 것을 막기 위한 Redo Log 설계. 데이터베이스의 WAL(Write-Ahead Logging) 파일은 철저하게 소프트웨어 레벨의 **Write-Through** 철학을 따른다. DB 버퍼 풀에서 데이터를 요리조리 Write-Back으로 고치더라도, "데이터를 고쳤다"는 사실 그 자체(Log)만큼은 커밋 순간에 OS 캐시를 무시하고 하드디스크의 로그 파일에 **동시에, 무조건 꽂아버린다.** 신뢰성이 스피드를 압도하는 아키텍처의 전형이다.

2. **비휘발성 스트리밍 데이터 (비디오 렌더링 / 네트워크 패킷)**
   10GB짜리 4K 비디오 픽셀을 순차적으로 렌더링 하여 디스플레이 버퍼에 때려 넣는 작업. 이 10GB의 픽셀 데이터는 "방금 썼지만, 다시 읽어올 일은 절대 없는" 스트리밍 데이터다. 이걸 Write-Back으로 쓰면, 아까운 캐시 공간이 쓰레기 픽셀로 오염된다. 최적화 엔지니어는 x86의 특수 명령어인 `Non-Temporal Store`를 사용하여 캐시를 완전히 우회하고 메모리로 다이렉트로 꽂아버리는 **명시적 Write-Through**를 강제하여 메모리 대역폭의 낭비를 막아낸다.

3. **그래픽 카드 MMIO (Memory Mapped I/O) 설정**
   운영체제가 GPU의 프레임 버퍼를 메인 메모리 주소처럼 매핑하여 제어할 때. OS 커널 단에서 MMIO 주소 공간은 절대로 Write-Back으로 설정하면 안 된다. 만약 CPU가 그래픽카드에 "화면 켜!"라는 명령을 썼는데 그게 CPU 캐시에만 머물러 있고 진짜 그래픽 카드로 전송되지 않는다면 화면은 영원히 켜지지 않는다. 이 특수 메모리 공간은 **Write-Through** 모드로 강제 설정되어, CPU의 명령이 0.1초의 망설임도 없이 즉시 하드웨어 핀으로 타격되도록 보장해야 한다.

### 안티패턴
- **Write Buffer가 꽉 차서 병목이 터지는 연속 쓰기**: Write-Through 캐시는 쓰기 버퍼에 기대어 연명한다. 하지만 프로그램이 메모리 쓰기를 수십 번 연속으로 날리는 무식한 반복문을 돌리면, 100ns에 하나씩 메모리로 빠져나가는 버퍼의 뒷구멍보다 1ns마다 밀려드는 앞구멍의 속도가 빨라 버퍼가 1초 만에 꽉 차버린다. 결국 CPU 전체가 멈춰버리는 무시무시한 스톨이 터진다. 최적화를 위해선 쓰기 명령어들 사이에 적당한 연산이나 읽기 명령어를 섞어 넣어 버퍼가 비워질 '숨통'을 벌어주는 코드 스케줄링이 필수다.

- **📢 섹션 요약 비유**: 쓰기 버퍼는 테이크아웃 커피점의 대기 줄입니다. 손님(CPU)이 1명씩 띄엄띄엄 오면 커피가 금방 나와 대기가 없지만, 단체 손님 10명(연속 쓰기)이 한꺼번에 들이닥치면 바리스타(메모리)가 뻗어버려 11번째 손님은 문 밖에서 꼼짝없이 서서 기다려야 합니다.

---

## Ⅴ. 기대효과 및 결론

### 기술 진화와 미래 전망
- **Write-Combining (쓰기 병합) 버퍼의 마술**: 최신 CPU는 Write-Through의 느린 속도를 개선하기 위해 쓰기 버퍼에 지능을 달았다. CPU가 주소 1번지에 1바이트, 2번지에 1바이트, 3번지에 1바이트를 따로따로 던지면, 버퍼가 이 주소들이 연속되어 있음을 눈치채고 버퍼 안에서 64바이트짜리 하나의 거대한 덩어리로 뭉쳐버린다. 그리고 메모리로 한 방에 날려버려 Write-Through의 대역폭 낭비를 획기적으로 줄인다.
- **SCM 시대의 재부상**: 메모리 자체가 전기를 꺼도 날아가지 않는 비휘발성 램으로 대체되면, 중요한 데이터 영구 보존을 위해 "무조건 캐시를 무시하고 즉시 메모리에 박아 넣어라!"라는 Write-Through 철학이 데이터베이스 아키텍처의 가장 중요한 지상 과제로 화려하게 부활하게 될 것이다.

### 결론
Write-Through(동시 쓰기)는 캐시가 탄생한 이래 가장 정직하고 우직한 하드웨어 설계의 원형이다. 비록 속도 경쟁에서 밀려 메인 캐시의 왕좌를 Write-Back에게 내어주었지만, 그 무결성 하나만큼은 절대 타협할 수 없는 무기다. 시스템이 무너져도 데이터는 살려야 하는 데이터베이스 복구 시스템, 실시간 하드웨어 I/O 통신 등에서 Write-Through는 폰 노이만 아키텍처의 가장 단단한 골조로 영원히 제자리를 지킬 것이다.

- **📢 섹션 요약 비유**: Write-Through는 매일매일 가계부를 칼같이 적는 깐깐한 경리부장입니다. 일 처리 속도는 느리고 사장님을 피곤하게 만들지만, 갑자기 세무조사(정전, 시스템 다운)가 닥쳤을 때 회사를 파산 위기에서 구해내는 유일한 방패막이가 바로 이 깐깐함입니다.

---

### 📌 관련 개념 맵

| 개념 명칭 | 관계 및 시너지 설명 |
|:---|:---|
| **Write-Back** | Write-Through의 라이벌. 메모리 트래픽을 극단적으로 줄여주지만 정전 시 데이터 손실 위험을 감수하는 현대의 메인 정책. |
| **쓰기 버퍼** | Write-Through의 치명적인 대기 시간을 가려주기 위해 CPU와 메모리 사이에 끼워 넣는 하드웨어 큐 장치. |
| **Write-Allocate** | 쓰기 미스 발생 시 캐시로 데이터를 끌어올 것인가 마느냐의 결정. Through 방식은 보통 No Write-Allocate를 택한다. |
| **Non-Temporal Store** | 멀티미디어 스트리밍 데이터가 캐시를 오염시키지 않도록, 캐시를 쿨하게 무시하고 메모리에 직접 다이렉트로 써버리는 최적화 기법. |
| **캐시 일관성** | 여러 코어가 데이터를 쓸 때 발생하는 불일치 현상으로, Write-Through를 쓰면 일관성 유지가 훨씬 직관적이고 쉬워진다. |

---

### 👶 어린이를 위한 3줄 비유 설명
1. 내가 일기장(캐시)에 연필로 비밀 글씨를 한 줄 쓸 때마다, 즉시 거실에 있는 엄마의 큰 장부(메모리)까지 뛰어가서 똑같이 적어두는 걸 '동시 쓰기'라고 해요.
2. 매번 거실까지 왔다 갔다 해야 하니까 숙제하는 시간은 엄청나게 오래 걸리고 너무 귀찮아요!
3. 하지만 도둑이 들어와서 내 일기장을 훔쳐 가도, 거실에 있는 엄마의 장부에는 내가 쓴 모든 내용이 100% 똑같이 남아있어서 절대 비밀을 잃어버릴 걱정이 없답니다!