408. MOESI 프로토콜

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

1. 본질: MOESI (Modified, Owned, Exclusive, Shared, Invalid) 프로토콜은 MESI (Modified, Exclusive, Shared, Invalid)에 Owned 상태를 추가해, 더티(Dirty) 데이터를 메모리에 즉시 되돌리지 않고도 캐시 간 공유하게 만드는 캐시 일관성 (Cache Coherence) 규칙이다.
2. 가치: 수정된 데이터를 읽으려는 다른 코어가 생겼을 때 DRAM (Dynamic Random Access Memory)을 왕복하지 않고 캐시-대-캐시 전송으로 해결하므로, 메모리 대역폭 낭비와 읽기 지연을 함께 줄인다.
3. 판단 포인트: MOESI는 읽기 공유가 많은 멀티코어·멀티소켓 환경에서 강력하지만, 상태 관리가 복잡해지고 false sharing 같은 과도한 공유 쓰기 병목까지 없애 주지는 못한다.

Ⅰ. 개요 및 필요성

MOESI 프로토콜은 수정된 캐시 라인을 "메모리에 아직 안 썼지만 여러 코어가 공유할 수 있게" 만든 확장형 일관성 프로토콜이다. 멀티코어 CPU (Central Processing Unit)에서 각 코어는 같은 메모리 주소를 자기 캐시에 복제해 들고 있으므로, 누가 최신값을 갖고 있는지 계속 추적해야 한다. 문제는 MESI만으로는 수정된 값을 다른 코어가 읽고 싶을 때, 최신 데이터를 가진 캐시가 먼저 메모리에 write-back을 수행하거나 버스를 통해 메모리 반영을 강하게 의식하는 흐름이 자주 생긴다는 점이다.

이 비용은 코어 수가 적을 때는 감당 가능하지만, 코어가 늘고 읽기 공유가 잦아질수록 눈에 띄게 커진다. 예를 들어 코어 A가 어떤 캐시 라인을 수정한 뒤, 코어 B와 코어 C가 차례로 그 값을 읽는다면, "최신값은 캐시에 있는데도 메모리를 중간 기준점으로 삼는" 보수적 절차가 반복될 수 있다. MOESI는 여기서 Owned 상태를 도입해, 최신 더티 데이터의 책임자는 한 캐시가 계속 맡되 다른 캐시들은 그 값을 공유해서 읽게 만든다.

즉 MOESI의 필요성은 단순히 상태 하나를 늘리는 데 있지 않다. 핵심은 메모리 최신화 시점과 데이터 공유 시점을 분리했다는 데 있다. 메모리는 나중에 반영해도 되지만, 코어 간 읽기 공유는 지금 당장 가능하게 하자는 발상이다. 이 변화 덕분에 캐시 일관성은 "무조건 즉시 메모리 정합"에서 "최신 책임자를 명확히 한 지연 반영"으로 한 단계 진화한다.

아래 그림은 MESI와 MOESI가 수정 데이터 공유를 어떻게 다르게 처리하는지 보여준다.

┌──────────────────────────────────────────────────────────────────────┐
│                Why Owned State Matters in Shared Read                │
├──────────────────────────────┬───────────────────────────────────────┤
│ MESI 중심 사고               │ MOESI 중심 사고                      │
├──────────────────────────────┼───────────────────────────────────────┤
│ Core0 has dirty data         │ Core0 has dirty data                 │
│ Core1 reads same line        │ Core1 reads same line                │
│   └─ memory path involved    │   └─ direct cache-to-cache transfer  │
│      or early write-back     │      and Core0 keeps ownership       │
│ Memory becomes sync point    │ Memory update is deferred safely     │
└──────────────────────────────┴───────────────────────────────────────┘

이 그림의 요점은 MOESI가 메모리를 없애는 것이 아니라, 메모리를 즉시 동원해야 하는 상황을 줄인다는 데 있다. 최신 데이터의 "법적 책임자"를 캐시에 남겨 두기 때문에, 읽기 공유 요청마다 DRAM을 호출하지 않아도 된다.

📢 섹션 요약 비유: MESI가 수정한 문서를 공유할 때마다 중앙 문서함에 먼저 정식 등록하고 복사하게 하는 방식이라면, MOESI는 "원본 책임자는 내가 맡을 테니 필요한 사람은 내 자리에서 바로 복사해 가"라고 운영하는 팀장 방식이다.

Ⅱ. 아키텍처 및 핵심 원리

MOESI는 캐시 라인마다 다섯 가지 상태를 두고 읽기·쓰기·스누프(snoop) 이벤트에 따라 상태를 전이시킨다. 이때 핵심은 Owned가 단순한 중간 상태가 아니라, 더티 데이터의 공유 가능 상태라는 점이다. Modified는 더티 데이터가 한 캐시에만 있는 상태이고, Owned는 더티 데이터의 최신 책임자가 한 캐시에 있으면서 다른 캐시들은 공유 사본을 가질 수 있는 상태다.

실제 동작은 다음 순서로 이해하면 쉽다.

1. 코어 0이 어떤 라인을 읽어 와서 수정하면 M 상태가 된다.
2. 코어 1이 같은 라인을 읽으려 하면, 코어 0은 메모리에 먼저 반영하지 않고 데이터를 직접 전달할 수 있다.
3. 그 순간 코어 0은 M → O, 코어 1은 S가 된다.
4. 이후 추가 읽기 요청이 오면 owner가 최신 데이터를 공급한다.
5. owner가 라인을 축출(eviction)할 때 비로소 메모리에 write-back하거나, 다른 캐시에 ownership을 넘긴다.

아래 그림은 M에서 O로 바뀌는 대표 흐름을 보여준다.

┌──────────────────────────────────────────────────────────────────────┐
│                 Typical MOESI Read-Share Transition                  │
├──────────────────────────────────────────────────────────────────────┤
│ Step 1                                                               │
│   Core0 : X = 10 in cache, state = M                                 │
│   Memory: X = 5 (stale)                                               │
│                                                                      │
│ Step 2                                                               │
│   Core1 issues BusRd(X)                                               │
│                                                                      │
│ Step 3                                                               │
│   Core0 supplies data directly to Core1                               │
│   Core0 : M ───────────────▶ O                                        │
│   Core1 : I ───────────────▶ S                                        │
│   Memory: still stale, update deferred                                │
│                                                                      │
│ Step 4                                                               │
│   Core0 remains responsible for future write-back                     │
└──────────────────────────────────────────────────────────────────────┘

여기서 중요한 설계 포인트는 Owned가 "공유도 되고 더티이기도 한" 예외 상태라는 점이다. 일반적인 Shared는 메모리와 일치하는 복사본을 여러 개 두는 개념이지만, MOESI에서는 owner가 메모리보다 최신인 값을 쥐고 있고 다른 sharer는 그 owner가 배포한 값을 읽는다. 따라서 coherence controller는 "누가 최신 책임자인가"를 별도로 기억해야 한다.

이 구조는 메모리 대역폭을 절약하는 대신 상태 기계를 복잡하게 만든다. 캐시 축출 시점, 추가 쓰기 요청 시 무효화 순서, 멀티소켓 인터커넥트에서의 응답 우선순위까지 모두 세밀하게 맞춰야 한다. 그래서 MOESI는 단순한 다섯 글자 약어가 아니라, 메모리 반영을 늦추면서도 최신성 책임을 잃지 않게 하는 정교한 계약으로 이해해야 한다.

📢 섹션 요약 비유: Owned 상태는 공동 과제에서 "최종 원본은 내가 들고 있고, 너희는 복사본을 봐도 되지만 마지막 제출 책임은 나에게 있다"라고 정하는 반장 역할과 같다.

Ⅲ. 비교 및 연결

MOESI를 제대로 이해하려면 MESI, MESIF (Modified, Exclusive, Shared, Invalid, Forward), 그리고 디렉터리 기반 프로토콜과의 경계를 함께 봐야 한다. MOESI의 초점은 더티 데이터 공유 최적화이고, MESIF의 초점은 클린 공유 데이터의 응답 대표자 지정에 가깝다. 따라서 둘은 비슷해 보여도 줄이려는 병목이 다르다.

MOESI는 스누핑 기반 시스템에서도 쓰일 수 있지만, 멀티소켓·ccNUMA (cache-coherent Non-Uniform Memory Access)처럼 메모리 거리가 길어진 환경에서 특히 의미가 커진다. 원격 DRAM을 거쳤다가 다시 읽는 비용은 수십~수백 ns로 커질 수 있는데, 캐시 간 직접 전달은 그보다 훨씬 짧은 경로로 끝날 수 있기 때문이다. 즉 Owned는 단순 상태 추가가 아니라, 토폴로지가 커질수록 더 가치가 커지는 지연 최적화다.

다만 MOESI가 해결하지 못하는 것도 분명하다. 여러 코어가 같은 캐시 라인을 번갈아 수정하는 write ping-pong이나 false sharing은 Owned가 있어도 여전히 비싸다. Owned는 "수정된 값을 읽으려는 공유"에는 유리하지만, "수정 권한이 자주 왕복하는 경쟁" 자체를 없애지는 못한다. 그래서 software tuning 관점에서는 프로토콜보다 공유 패턴을 먼저 바꾸는 편이 더 큰 효과를 내는 경우가 많다.

결국 비교의 핵심은 이것이다. MESI는 기본 질서를 세운 모델, MOESI는 더티 데이터 공유를 빠르게 한 모델, MESIF는 클린 데이터 응답 대표를 명확히 한 모델이다. 셋 다 coherence를 위한 상태 기계이지만, 어떤 버스 비용을 줄이고 어떤 응답 충돌을 피하려는지에서 설계 철학이 다르다.

📢 섹션 요약 비유: MESI가 "한 권의 책을 누가 빌렸는지"만 관리하는 도서관 규칙이라면, MOESI는 "아직 반납하지 않은 최신 수정본도 친구끼리 돌려볼 수 있게 한 규칙", MESIF는 "여러 복사본 중 누가 대표로 답할지 정한 규칙"에 가깝다.

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

실무에서 프로그래머가 직접 MOESI 상태를 선택할 수는 없지만, 성능 병목을 해석할 때 이 동작을 이해하면 현상이 훨씬 잘 보인다. 예를 들어 생산자-소비자 큐에서 생산 코어가 쓴 데이터를 소비 코어가 곧바로 읽는 패턴은 MOESI가 상대적으로 잘 처리하는 편이다. 반대로 여러 스레드가 하나의 카운터를 계속 증가시키는 구조는 Owned가 있어도 캐시 라인이 끊임없이 이동하므로 여전히 느리다.

설계·운영 판단 포인트

1. 읽기 공유가 많은가, 쓰기 경쟁이 많은가?
   읽기 공유가 많으면 MOESI의 cache-to-cache 전달 이점이 살아난다. 쓰기 경쟁이 많으면 coherence 프로토콜보다 데이터 분할(sharding)과 thread-local 설계가 더 중요하다.

2. NUMA 거리와 소켓 경계를 넘는가?
   멀티소켓 서버에서는 원격 메모리 접근보다 원격 캐시 전달이 더 유리할 수 있다. 이때 스레드 배치와 메모리 배치가 어긋나면 MOESI의 장점도 줄어든다.

3. 성능 도구에서 무엇을 볼 것인가?
   Linux perf c2c 같은 도구의 HITM (Hit Modified) 계열 지표는 캐시 간 데이터 이동이 잦다는 신호다. 이 수치가 높다면 하드웨어가 열심히 coherence를 지키고 있다는 뜻이지, 애플리케이션 구조가 좋다는 뜻은 아니다.

안티패턴

• 전역 카운터 하나를 모든 워커가 고빈도로 갱신하는 설계
• 구조체 필드가 같은 캐시 라인에 붙어 있어 false sharing을 유발하는 배치
• 하드웨어 coherence가 있으니 락 경합과 공유 쓰기를 무시해도 된다고 생각하는 판단

기술사 답안에서는 "MOESI가 메모리 write-back 비용을 완화한다"는 장점만 쓰면 부족하다. 반드시 "상태 기계 복잡도 증가", "공유 쓰기 경쟁에는 한계", "토폴로지와 접근 패턴에 따라 효과 차이"까지 함께 언급해야 균형 잡힌 설명이 된다. 채택 관점에서는 많은 읽기 공유와 긴 메모리 경로가 있을수록 유리하고, 회피 관점에서는 지나친 구현 복잡도나 간단한 소규모 시스템에서는 과한 선택이 될 수 있다.

📢 섹션 요약 비유: MOESI는 옆 팀에 자료를 바로 전달하는 빠른 사내 메신저지만, 모두가 같은 파일을 동시에 수정하려 들면 메신저가 빨라도 문서 충돌 자체는 계속 난다.

Ⅴ. 기대효과 및 결론

MOESI의 가장 큰 효과는 캐시 일관성을 유지하면서도 메모리를 매번 동기화 지점으로 삼지 않아도 된다는 점이다. 그 결과 읽기 공유가 많은 워크로드에서는 메모리 대역폭 소비가 줄고, 원격 읽기 지연도 낮아질 수 있다. 특히 코어 수가 많고 소켓 간 거리가 긴 시스템일수록 Owned 상태의 가치가 커진다.

하지만 이 이득은 공짜가 아니다. 구현 측면에서는 상태 전이가 복잡해지고, coherence controller와 인터커넥트가 처리해야 할 예외 경로가 늘어난다. 또한 데이터 공유 패턴이 나쁘면 MOESI가 있어도 캐시 라인 이동 폭풍은 막지 못한다. 즉 MOESI는 "나쁜 공유 구조를 고쳐 주는 마법"이 아니라, 불가피한 공유를 더 효율적으로 처리하는 하드웨어 최적화다.

앞으로 many-core와 chiplet 구조가 더 확산될수록, 단순 브로드캐스트보다 정교한 상태 추적과 로컬 전달의 중요성은 커질 가능성이 높다. 동시에 하드웨어 복잡도를 낮추기 위해 디렉터리 최적화, 계층형 coherence, 소프트웨어 힌트 기반 제어가 함께 발전할 것이다. 따라서 MOESI는 "Owned라는 상태 하나를 더한 프로토콜"이 아니라, 메모리 반영 시점을 늦추고도 책임을 잃지 않는 공유 전략으로 기억하는 것이 가장 정확하다.

📢 섹션 요약 비유: MOESI는 모든 보고서를 본사 서버에 즉시 올리지 않아도, 담당자 한 명이 최신본 책임을 지고 팀원들에게 빠르게 돌려볼 수 있게 만든 운영 방식이다. 다만 팀원들이 한 문서를 동시에 고쳐 대면 그때는 여전히 충돌 관리가 필요하다.

📌 관련 개념 맵

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

MSI (Modified, Shared, Invalid)
    │
    ▼
MESI (Modified, Exclusive, Shared, Invalid)
    │
    ├─▶ 단독 수정 최적화
    │
    ▼
MOESI (Modified, Owned, Exclusive, Shared, Invalid)
    │
    ├─▶ dirty data cache-to-cache transfer
    ├─▶ 멀티소켓 · ccNUMA 최적화
    │
    ▼
MESIF / Directory-based Coherence / many-core 확장

이 흐름은 기본 상태 관리에서 출발해, 단독 수정 최적화, 더티 공유 최적화, 그리고 대규모 시스템 확장으로 이어지는 진화를 보여준다.

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

1. MOESI는 친구 한 명이 고쳐 쓴 숙제 답을 선생님 책상에 바로 놓지 않아도, 다른 친구들에게 먼저 보여줄 수 있게 한 규칙이에요.
2. 대신 "최신 답은 내가 책임질게" 하고 한 친구가 꼭 원본 담당자를 맡아요.
3. 그래서 매번 선생님 책상까지 뛰어가지 않아도 빨리 같이 볼 수 있지만, 모두가 동시에 고치면 여전히 복잡해져요.