406. 갱신 정책 (Write-Update)

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

본질: 갱신 정책 (Write-Update)은 한 코어가 공유 캐시 라인을 쓰면 다른 코어의 복사본을 무효화하지 않고, 새 데이터 자체를 전파해 모두의 캐시를 최신값으로 맞추는 일관성 정책이다.

가치: 공유 데이터를 곧바로 다시 읽을 가능성이 높다면 다음 읽기에서 캐시 미스(Cache Miss)를 줄여 지연시간을 낮출 수 있다.

판단 포인트: 읽기 중심 공유에는 유리할 수 있지만, 연속 쓰기나 공유자 수가 많아지면 데이터 방송 비용이 급격히 커져 현대 범용 다중 코어 CPU (Central Processing Unit)에서는 주류가 되지 못했다.

Ⅰ. 개요 및 필요성

갱신 정책 (Write-Update)은 공유 캐시 복사본을 지우는 대신 함께 고쳐 주는 캐시 일관성 정책이다. 멀티코어 환경에서는 여러 코어가 같은 메모리 블록을 각자 캐시에 들고 있기 때문에, 한 코어가 값을 수정하는 순간 다른 코어의 복사본은 오래된 정보가 된다. 이때 단순 무효화 정책은 나중에 다시 읽는 코어에게 추가 캐시 미스를 강제하지만, 갱신 정책은 "지금 바뀐 값을 같이 받아 두라"는 방향을 택한다.

이 방식이 등장한 이유는 공유 데이터가 짧은 시간 안에 여러 코어에서 반복적으로 읽히는 워크로드 때문이다. 예를 들어 락 상태, 생산자-소비자 플래그, 짧은 제어 변수처럼 "누군가 쓴 직후 다른 누군가 바로 읽는" 데이터라면, 무효화보다 갱신이 다음 읽기의 대기시간을 더 잘 줄일 수 있다. 즉 갱신 정책은 대역폭보다 후속 읽기 지연시간을 우선시한 설계 철학이라 볼 수 있다.

아래 그림은 왜 이 정책이 직관적으로 매력적인지 보여준다.

┌──────────────────────────────────────────────────────────────────────┐
│        Write-Update의 기본 생각: "지우지 말고 같이 최신값으로 맞춘다" │
├──────────────────────────────────────────────────────────────────────┤
│ 코어 A 캐시 : X = 5                                                  │
│ 코어 B 캐시 : X = 5                                                  │
│ 메모리      : X = 5                                                  │
│                                                                      │
│ 1) 코어 A가 X를 10으로 씀                                            │
│ 2) 인터커넥트가 "X=10" 데이터를 공유자에게 전달                      │
│ 3) 코어 B 캐시도 X = 10으로 즉시 갱신                                │
│ 4) 코어 B가 곧바로 읽으면 Cache Miss 없이 최신값 사용                │
└──────────────────────────────────────────────────────────────────────┘

핵심은 "나중에 읽을 때 다시 가져오게 하지 말고, 지금 미리 최신본을 넣어 두자"는 선제 대응이다. 따라서 갱신 정책은 읽기 지역성(Locality)이 아니라 공유 읽기 타이밍을 잘 맞출 때 효과가 난다.

📢 섹션 요약 비유: 화이트보드 내용을 바꿀 때 예전 메모를 지워 버리는 대신, 같은 회의실 사람들 노트에도 새 내용을 바로 적어 주는 방식이 Write-Update다. 곧바로 다시 볼 사람에게는 편하지만, 아무도 안 볼 노트까지 다 고쳐 주면 일이 많아진다.

Ⅱ. 아키텍처 및 핵심 원리

갱신 정책은 보통 스누핑 프로토콜 (Snooping Protocol)이나 디렉터리 기반 추적과 결합되어 동작한다. 핵심 절차는 단순하다. 어떤 코어가 공유 상태의 캐시 라인을 쓸 때, 인터커넥트는 해당 주소와 새 데이터 값을 다른 공유자에게 전달하고, 그 캐시들은 자신의 복사본을 같은 값으로 덮어쓴다. 즉 권한 이전 중심의 정책이 아니라 값 전파 중심의 정책이다.

구성 요소	역할	성능 포인트
공유자 추적기	누가 같은 라인을 갖고 있는지 파악	공유자 수가 많을수록 비용 증가
갱신 메시지	주소 + 새 데이터 전달	무효화보다 패킷이 무거움
수신 캐시	해당 라인을 최신값으로 수정	다음 읽기 히트 확률 상승
메모리 계층	필요 시 최신 데이터 반영	프로토콜별로 시점 차이 존재

아래 그림은 쓰기 한 번이 어떤 식으로 퍼지는지 보여준다.

┌──────────────────────────────────────────────────────────────────────┐
│              Write-Update의 데이터 전파 경로                         │
├──────────────────────────────────────────────────────────────────────┤
│  코어 A                인터커넥트                 코어 B / 코어 C     │
│  ┌─────────┐           ┌──────────────┐           ┌──────────────┐    │
│  │ write X │ ───────▶ │ Update(X=10) │ ───────▶ │ line X := 10  │    │
│  └─────────┘           └──────────────┘           └──────────────┘    │
│         │                         └────────────────▶ line X := 10      │
│         └─────────────────────────────────────────────────────────────▶ │
│                                                                      │
│ 결과: 다른 코어는 invalid가 아니라 "최신 공유본"을 계속 유지          │
└──────────────────────────────────────────────────────────────────────┘

문제는 쓰기가 한 번으로 끝나지 않는 경우다. X=1 → X=2 → X=3처럼 같은 라인을 연속 수정하면 매번 새 데이터가 전파된다. 무효화 정책은 첫 한 번만 다른 복사본을 끊어 놓으면 이후 쓰기를 조용히 이어 갈 수 있지만, 갱신 정책은 모든 쓰기마다 통신 비용이 발생한다.

이 특성 때문에 갱신 정책은 "읽기 지연을 줄이는 대신 쓰기 대역폭을 소비하는 구조"로 이해해야 한다. 특히 캐시 라인 크기가 64바이트이고 실제 바뀌는 필드는 몇 바이트뿐이라면, 부분 갱신 처리조차 인터커넥트 설계를 복잡하게 만든다.

📢 섹션 요약 비유: 단체 채팅방에서 규칙이 바뀔 때 "예전 공지 폐기"만 보내는 것이 무효화라면, Write-Update는 새 공지 전문을 매번 다시 올리는 방식이다. 당장 읽을 사람은 편하지만, 수정이 잦으면 채팅방이 공지로 도배된다.

Ⅲ. 비교 및 연결

갱신 정책을 이해하려면 무효화 정책 (Write-Invalidate)과의 경계를 분명히 봐야 한다. 두 정책 모두 캐시 일관성(Cache Coherence)을 지키려는 목적은 같지만, 어떤 비용을 먼저 치를지가 다르다.

항목	갱신 정책 (Write-Update)	무효화 정책 (Write-Invalidate)
쓰기 시 동작	새 값을 다른 캐시에 전달	다른 복사본을 무효화
다음 읽기 비용	낮을 수 있음	다시 읽을 때 miss 가능
반복 쓰기 비용	매 쓰기마다 전파 비용 발생	첫 무효화 후 조용한 쓰기 가능
적합한 패턴	읽기 비율 높고 재공유가 빠름	쓰기 집중, 공유자 많음
현대 채택	제한적, 특수 프로토콜 위주	범용 CPU의 주류

예를 들어 Dragon 프로토콜 (Dragon Protocol)은 대표적인 write-update 계열로 알려져 있다. 반면 MESI 프로토콜 (Modified, Exclusive, Shared, Invalid)과 MOESI 프로토콜 (Modified, Owned, Exclusive, Shared, Invalid)의 주류 구현은 대체로 무효화 철학을 따른다. 이는 현대 시스템에서 코어 수 증가와 인터커넥트 병목이 더 치명적이기 때문이다.

연결해서 보면, 갱신 정책은 단순히 "옛날 방식"이 아니라 트래픽과 지연시간 사이의 선택지다. 작은 공유자 집합, 읽기 우세, 빠른 재사용이 맞물리면 이론적으로 여전히 매력적이다. 하지만 범용 서버처럼 코어 수가 많고 쓰기 패턴이 예측 불가능하면, 버스나 메시에 쏟아지는 update 메시지가 전체 확장성을 갉아먹는다.

📢 섹션 요약 비유: Write-Update는 새 교재가 나오면 반 친구 전원에게 새 페이지를 바로 배포하는 방식이고, Write-Invalidate는 "옛 페이지는 버려"라고 먼저 알리는 방식이다. 자주 다시 읽는 수업이면 전자 쪽이 편하지만, 교재 수정이 계속되면 후자가 훨씬 덜 시끄럽다.

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

실무 판단의 핵심은 "공유 데이터가 정말 곧바로 재사용되는가, 아니면 쓰기만 많이 일어나는가"다. 현대 범용 프로세서가 write-update를 널리 채택하지 않는 이유는 명확하다. 코어 수가 늘수록 공유자 추적과 데이터 전파 비용이 커지고, 고빈도 쓰기 구간에서는 캐시 미스를 줄인 이득보다 인터커넥트 혼잡이 더 큰 손해로 바뀌기 때문이다.

따라서 다음 조건이 맞을 때만 update 철학을 검토할 가치가 있다.

공유자 수가 작다: 2~4개 수준의 제한된 공유라면 전파 범위가 통제 가능하다.
읽기 재사용이 즉시 발생한다: 쓰고 난 직후 다른 코어가 거의 곧바로 읽는 패턴이어야 한다.
반복 쓰기가 길지 않다: 같은 데이터에 연속 갱신이 길면 update의 장점이 빠르게 사라진다.

반대로 아래 상황이면 무효화 정책이 더 합리적이다.

카운터 증가처럼 짧은 쓰기가 매우 자주 반복되는 경우
공유자 수가 많아 브로드캐스트나 멀티캐스트 비용이 커지는 경우
거짓 공유(False Sharing)처럼 실제로는 독립 데이터인데 같은 캐시 라인을 건드리는 경우

소프트웨어 아키텍처에서도 같은 판단이 반복된다. 분산 캐시나 데이터 복제에서 새 값을 적극 push할지, 키를 invalidation만 할지 결정할 때도 결국 즉시 읽기 보장 vs 네트워크 절약의 선택으로 환원된다. 하드웨어의 write-update는 오늘날 주류는 아니지만, 설계 판단 프레임은 여전히 살아 있다.

📢 섹션 요약 비유: 식당에서 메뉴가 바뀔 때 손님이 바로 다시 주문할 테이블에만 새 메뉴판을 돌리면 효율적이다. 하지만 모든 테이블에 매번 새 메뉴판을 뿌리면, 정작 서빙보다 메뉴판 배달이 더 바빠지는 상황이 생긴다.

Ⅴ. 기대효과 및 결론

갱신 정책의 가장 큰 장점은 공유 읽기의 체감 지연시간을 줄인다는 점이다. 다른 코어가 이미 최신값을 받아 둔 상태라면, 다음 읽기에서 캐시 미스를 거치지 않고 곧바로 작업을 이어 갈 수 있다. 이는 소규모 공유, 제어 데이터, 빠른 hand-off 패턴에서 의미 있는 효과를 낼 수 있다.

그러나 이 정책이 널리 쓰이지 않는 이유도 분명하다. 쓰기가 연속되면 update 메시지가 누적되고, 공유자가 많아질수록 통신량이 선형적으로 증가하며, 결과적으로 시스템 전체 확장성이 나빠진다. 그래서 현대 설계에서는 "가능하면 invalidate를 기본으로 하고, 정말 필요한 곳에만 update적 사고를 국소 적용"하는 방향이 더 현실적이다.

결국 Write-Update는 일관성을 맞추는 방법 중 하나이지, 항상 더 친절한 해답은 아니다. 이 개념은 "최신값을 미리 배포하면 읽기는 빨라지지만, 그 친절함의 비용은 결국 통신이 낸다"는 관점으로 기억하는 것이 가장 정확하다.

📢 섹션 요약 비유: 모두에게 최신 소식을 미리 알려 주면 질문이 줄어드는 장점이 있다. 하지만 소식이 너무 자주 바뀌면, 소식을 전하는 일 자체가 본업이 되어 버린다.

📌 관련 개념 맵

개념	연결 포인트
캐시 일관성 (Cache Coherence)	여러 캐시 복사본의 값이 충돌하지 않게 유지하는 상위 문제
무효화 정책 (Write-Invalidate)	Write-Update와 대비되는 주류 정책
스누핑 프로토콜 (Snooping Protocol)	공유 버스에서 update 메시지를 감시·반영하는 구현 방식
Dragon 프로토콜 (Dragon Protocol)	write-update 계열의 대표 사례
거짓 공유 (False Sharing)	update/invalidate 모두에서 불필요한 통신을 키우는 병목

📈 관련 키워드 및 발전 흐름도

공유 데이터 읽기 문제
    │
    ▼
캐시 일관성 (Cache Coherence)
    │
    ├──▶ 갱신 정책 (Write-Update)
    │         │
    │         ├──▶ Dragon 프로토콜 (Dragon Protocol)
    │         └──▶ 읽기 지연 최소화 지향
    │
    └──▶ 무효화 정책 (Write-Invalidate)
              │
              ├──▶ MESI 프로토콜 (Modified, Exclusive, Shared, Invalid)
              └──▶ 대역폭·확장성 중심 진화

이 흐름은 캐시 일관성 설계가 "최신값을 미리 보내는 길"과 "필요할 때 다시 가져오게 하는 길"로 갈라졌음을 보여준다.

👶 어린이를 위한 3줄 비유 설명

친구 한 명이 답을 고치면, Write-Update는 다른 친구 공책에도 새 답을 바로 적어 주는 거예요.
그래서 다른 친구가 곧바로 보면 헷갈리지 않고 바로 읽을 수 있어요.
하지만 답이 계속 바뀌면 모두 공책을 매번 다시 적어야 해서 오히려 더 바빠져요.