381. COMA (Cache-Only Memory Access)

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

본질: COMA (Cache-Only Memory Access)는 각 노드의 주기억장치를 고정 주소를 가진 메모리가 아니라, 데이터가 머물다 이동하는 거대한 캐시처럼 취급하는 분산 공유 메모리 구조다.

가치: 목표는 NUMA (Non-Uniform Memory Access)의 원격 메모리 지연을 줄이기 위해, 연산이 일어나는 쪽으로 데이터를 스스로 이주(Migration)·복제(Replication)시키는 것이다.

판단 포인트: 아이디어는 데이터 지역성(Data Locality)에 매우 강하지만, 데이터 위치 추적과 일관성 유지 비용이 너무 커서 실무에서는 순수 COMA보다 ccNUMA (Cache-Coherent NUMA)와 소프트웨어 기반 페이지 이동이 현실적이다.

Ⅰ. 개요 및 필요성

COMA (Cache-Only Memory Access)는 분산 공유 메모리 시스템에서 "메모리의 집 주소를 고정하지 말자"라는 발상으로 나온 아키텍처다. 일반적인 NUMA에서는 어떤 데이터가 특정 홈 노드(Home Node)의 메모리에 자리 잡고 있고, 다른 프로세서는 필요할 때마다 그 위치까지 원격 접근을 해야 한다. 반면 COMA는 데이터를 특정 메모리 모듈의 영구 거주자로 보지 않고, 필요하면 더 자주 쓰는 노드 쪽으로 옮겨 버린다.

이 개념이 등장한 배경은 멀티프로세서가 커질수록 원격 메모리 접근 지연이 전체 성능을 심각하게 깎았기 때문이다. 로컬 메모리는 빠르지만 원격 메모리는 인터커넥트와 중간 제어기를 거치므로 수 배의 지연이 생긴다. 프로그래머가 항상 데이터 배치를 완벽하게 맞출 수 없다면, 차라리 하드웨어가 데이터를 연산 가까이 당겨오는 편이 낫다는 것이 COMA의 출발점이다.

아래 그림은 NUMA와 COMA가 같은 문제를 어떻게 다르게 보는지 보여준다.

┌──────────────────────────────────────────────────────────────────────────────┐
│              NUMA와 COMA의 핵심 차이: "누가 어디에 살아야 하는가"           │
├───────────────────────┬──────────────────────────────────────────────────────┤
│ NUMA                  │ COMA                                                 │
├───────────────────────┼──────────────────────────────────────────────────────┤
│ 주소 0x1000의 홈 노드 │ 주소 0x1000은 이름표(Tag)일 뿐, 현재 위치는 가변적   │
│ 가 미리 정해짐        │                                                      │
│                       │                                                      │
│ CPU0가 필요하면       │ CPU0가 자주 쓰면 데이터가 CPU0 쪽 메모리로 이동 가능  │
│ 원격 읽기 수행        │                                                      │
│                       │                                                      │
│ "데이터 위치 고정"    │ "데이터 위치 유동"                                   │
└───────────────────────┴──────────────────────────────────────────────────────┘

핵심은 COMA가 메모리 접근 시간을 평균화하려는 것이 아니라, 자주 쓰는 데이터의 실제 거주 위치를 바꿔서 원격 접근 자체를 줄이려 한다는 점이다. 즉 캐시가 프로세서 가까이에 복사본을 두는 수준을 넘어, 시스템 전체 주기억장치가 캐시처럼 행동하게 만들겠다는 시도다.

📢 섹션 요약 비유: NUMA가 "서류는 원래 보관실에 두고 필요할 때마다 가지러 가는 방식"이라면, COMA는 "자주 보는 서류를 내 책상 서랍으로 아예 옮겨 놓는 방식"이다.

Ⅱ. 아키텍처 및 핵심 원리

COMA에서는 각 노드의 로컬 메모리가 단순한 DRAM (Dynamic Random Access Memory) 저장소가 아니라, Attraction Memory라는 큰 캐시처럼 동작한다. 데이터 블록은 필요에 따라 한 노드에서 다른 노드로 이동하고, 읽기 위주 데이터는 여러 노드에 복제될 수 있다. 따라서 시스템은 "이 데이터가 지금 어느 노드에 있는가"를 지속적으로 추적해야 한다.

구성 요소	역할	핵심 설계 포인트
Attraction Memory	각 노드의 주기억장치를 캐시처럼 사용	고정 홈 메모리 대신 유동적 저장
디렉터리 (Directory)	데이터 현재 위치와 복제 상태 관리	검색 지연과 저장 오버헤드
Migration	자주 쓰는 데이터를 접근 노드로 이동	원격 접근 감소, 이동 비용 증가
Replication	읽기 데이터의 다중 사본 유지	읽기 성능 향상, 쓰기 일관성 부담
Coherence Control	최신 사본을 단일하게 보장	무효화·갱신 트래픽 관리

아래 그림은 COMA의 기본 동작 흐름을 압축한다.

┌──────────────────────────────────────────────────────────────────────────────┐
│                    COMA 데이터 탐색 · 이동 · 갱신 흐름                      │
├──────────────────────────────────────────────────────────────────────────────┤
│ 1) CPU0가 블록 A 요청                                                      │
│        │                                                                    │
│        ▼                                                                    │
│    로컬 Attraction Memory 미스                                              │
│        │                                                                    │
│        ▼                                                                    │
│ 2) 디렉터리가 "A는 Node2에 있음" 확인                                       │
│        │                                                                    │
│        ├──────── read 위주 ────────▶ Node0에 복제                           │
│        │                                                                    │
│        └──────── write 위주 ───────▶ Node2 사본 회수 후 Node0로 이주        │
│                                                                             │
│ 3) 이후 CPU0는 로컬 접근으로 처리                                           │
└──────────────────────────────────────────────────────────────────────────────┘

이 구조의 장점은 데이터 지역성이 이동하는 워크로드에 매우 잘 맞는다는 점이다. 어떤 스레드가 계속 한 데이터를 소비하면, 결국 그 데이터는 해당 스레드 근처에 자리 잡게 된다. 그러나 단점도 분명하다. 데이터를 찾기 위한 디렉터리 탐색, 쓰기 시 복제본 무효화, 유일한 원본이 축출(Eviction)될 때 새로운 거처를 찾아야 하는 작업이 모두 하드웨어 복잡도를 급격히 키운다.

특히 COMA는 "메모리에서 쫓겨난 데이터가 사라지면 안 된다"는 점이 일반 캐시보다 훨씬 어렵다. 보통 캐시는 하위 계층 메모리에 원본이 있으니 블록을 버려도 되지만, COMA에서는 현재 사본 자체가 사실상 원본일 수 있다. 그래서 단순 교체 정책이 아니라 보존 가능한 재배치 정책이 필요해진다.

📢 섹션 요약 비유: COMA는 도서관 책을 빌려 오는 수준이 아니라, 학생이 오래 보는 책이면 그 책장을 학생 옆으로 통째로 옮겨 놓는 방식이다. 다만 누가 책장을 갖고 있는지 사서가 항상 추적해야 한다.

Ⅲ. 비교 및 연결

COMA를 이해하려면 NUMA, ccNUMA, 그리고 소프트웨어 기반 데이터 이동과의 경계를 함께 봐야 한다. NUMA는 메모리 위치를 고정해 단순성을 확보하고, ccNUMA는 그 위에 캐시 일관성을 얹어 현실적인 대규모 SMP (Symmetric Multiprocessing)를 만든다. COMA는 여기서 한 걸음 더 나아가 메모리 위치까지 동적으로 만들지만, 그 대가로 하드웨어 관리 비용이 폭증한다.

항목	NUMA	COMA	왜 차이가 중요한가
데이터 홈 위치	고정	유동적	COMA는 원격 접근을 줄이지만 위치 추적 필요
메모리 성격	주소 기반 주기억장치	캐시형 주기억장치	메모리 관리 모델 자체가 달라짐
읽기 성능	원격 접근 시 손해	복제로 완화 가능	읽기 집약 워크로드에 유리
쓰기 관리	비교적 단순	복제본 무효화 부담 큼	일관성 비용이 급증
구현 난이도	현실적	매우 높음	상용화의 갈림길

실제 산업은 순수 COMA보다 ccNUMA를 선택했다. 이유는 명확하다. 주소의 홈 노드를 유지하면 디렉터리 구조와 메모리 교체 정책을 훨씬 단순하게 만들 수 있기 때문이다. 대신 운영체제는 NUMA balancing, page migration, thread affinity 같은 기법으로 "COMA가 하고 싶었던 일"을 일부 소프트웨어로 대신 수행한다.

이 점에서 COMA는 실패한 구조라기보다, 오늘날 시스템 소프트웨어가 간접적으로 계승한 철학에 가깝다. 리눅스의 자동 NUMA 밸런싱, 하이퍼바이저의 가상 NUMA, 분산 인메모리 시스템의 핫 데이터 복제는 모두 "연산 가까이에 데이터를 두자"는 동일한 문제의식에서 나온다.

📢 섹션 요약 비유: NUMA는 집 주소를 바꾸지 않고 택배만 보내는 체계이고, COMA는 사람이 자주 가는 곳을 따라 집 자체를 옮기는 체계다. 후자는 편리할 수 있지만 행정 관리가 훨씬 어렵다.

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

실무 관점에서 순수 COMA를 직접 도입할 일은 거의 없다. 기술사 답안이나 아키텍처 판단에서는 "왜 상용 서버가 COMA 대신 ccNUMA를 택했는가"를 설명할 수 있어야 한다. 핵심 답은 데이터 이동 이점보다 위치 추적과 일관성 유지 비용이 더 컸기 때문이다.

실제 설계에서는 다음처럼 판단하는 것이 현실적이다.

읽기 편중·데이터 재사용이 매우 높다면 COMA의 철학은 여전히 유효하다. 이 경우 분산 캐시, 복제 전략, NUMA 로컬 복제 같은 방식으로 일부 효과를 얻을 수 있다.
쓰기 공유가 많다면 COMA류 접근은 오히려 해롭다. 복제본 무효화와 이동 트래픽이 늘어 인터커넥트 병목이 심해질 수 있다.
하드웨어 단순성과 예측 가능성이 중요하다면 고정 홈 메모리를 유지하는 NUMA/ccNUMA가 낫다. 장애 분석과 성능 튜닝도 훨씬 수월하다.

아래 체크리스트는 COMA 철학을 실무에 적용할 때의 판단 기준이다.

체크리스트

데이터가 읽기 위주인지, 쓰기 위주인지 구분했는가?
노드 간 인터커넥트 대역폭이 데이터 이동 비용을 감당할 수 있는가?
데이터 위치를 추적하는 메타데이터 오버헤드가 허용 범위인가?
소프트웨어적 페이지 이동이나 복제가 더 싼 대안은 아닌가?

안티패턴

"원격 접근이 느리니 데이터를 계속 옮기면 되겠지"라고 단순화하는 설계
쓰기 공유가 많은 객체를 여러 노드에 과도하게 복제하는 설계
하드웨어가 모든 지역성 문제를 해결해 줄 것이라고 기대하는 설계

시험에서는 COMA를 이론적으로는 데이터 지역성 극대화 구조, 실무적으로는 복잡도 때문에 제한된 구조로 정리하면 좋다. 즉 원격 메모리 병목을 해결하려는 이상적 접근이지만, 현실 시스템은 그 철학만 부분적으로 채택했다는 관점이 중요하다.

📢 섹션 요약 비유: 서류를 필요한 사람 옆으로 계속 옮기면 처음엔 빨라 보이지만, 수정본·사본·보관 위치를 관리하는 총무팀이 감당 못 하면 회사 전체가 더 느려진다.

Ⅴ. 기대효과 및 결론

COMA의 기대효과는 분명하다. 잘 맞는 워크로드에서는 데이터가 연산 가까이 자리 잡으므로 평균 메모리 접근 지연을 줄이고, 프로그래머가 직접 데이터 배치를 세밀하게 맞추지 않아도 지역성을 어느 정도 하드웨어가 흡수해 줄 수 있다. 특히 읽기 재사용이 크고 접근 중심이 시간에 따라 이동하는 환경에서는 매력적인 발상이다.

하지만 한계도 명확하다. 데이터 위치 검색, 복제본 관리, 쓰기 무효화, 축출 시 재배치 같은 문제가 모두 결합되면 메모리 계층 전체가 지나치게 복잡해진다. 그래서 COMA는 "메모리도 캐시처럼 만들자"는 통찰을 남겼지만, 상용 구조는 결국 더 예측 가능한 절충안인 ccNUMA와 운영체제 기반 튜닝으로 수렴했다.

앞으로 CXL (Compute Express Link) 기반 메모리 풀링, 계층형 메모리, 지능형 페이지 이동이 발전할수록 COMA의 철학은 다른 형태로 다시 등장할 가능성이 있다. 따라서 COMA는 사라진 구조로 외우기보다, 데이터의 주소보다 데이터의 위치 최적화가 더 중요해지는 순간을 보여 준 선행 개념으로 기억하는 것이 맞다.

📢 섹션 요약 비유: COMA는 "사람이 서류를 찾아가는 대신 서류가 사람을 찾아오게 하자"는 멋진 아이디어였다. 다만 그 서류 이동 체계를 운영하는 비용이 너무 커서, 현실은 더 단순한 절충안을 택했다.

📌 관련 개념 맵

개념	연결 포인트
NUMA (Non-Uniform Memory Access)	COMA가 해결하려 한 직접적 출발점으로, 원격 메모리 지연 문제를 드러낸다
ccNUMA (Cache-Coherent NUMA)	COMA보다 현실적인 상용 대안으로, 고정 홈 메모리와 캐시 일관성을 결합한다
Directory-Based Coherence	COMA에서 데이터 위치와 최신 사본을 추적하는 핵심 메커니즘이다
Page Migration	운영체제가 COMA 철학을 소프트웨어 수준에서 구현하는 대표 기법이다
Data Locality	COMA 전체를 관통하는 목표로, 연산과 데이터의 물리적 거리를 줄이는 개념이다

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

공유 메모리 확장 문제
    │
    ▼
NUMA (Non-Uniform Memory Access)
    │
    ├─ 원격 메모리 지연 최소화 시도
    ▼
COMA (Cache-Only Memory Access)
    │
    ├─ 데이터 이주(Migration) · 복제(Replication)
    ├─ 디렉터리 기반 위치 추적
    ▼
ccNUMA (Cache-Coherent NUMA) 중심의 현실적 절충
    │
    ▼
OS 기반 Page Migration · NUMA Balancing · CXL Memory Pooling

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

COMA는 책이 멀리 있는 책장에 가만히 있는 대신, 내가 자주 읽으면 내 옆 책상으로 옮겨 오는 도서관 같은 거예요.
그래서 책을 찾으러 멀리 안 가도 되어 빨라질 수 있어요.
하지만 누가 어떤 책을 갖고 있는지 계속 확인해야 해서, 관리가 너무 어려우면 오히려 더 복잡해질 수 있어요.