디렉터리 기반 프로토콜 (Directory-based Protocol)

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

1. 본질: 스누핑 프로토콜의 버스 마비 한계를 극복하기 위해, 메인 메모리나 특정 칩 구역에 '어떤 코어가 어떤 캐시 라인을 가지고 있는지' 기록하는 중앙 장부(Directory)를 두고 통신을 1:1(Unicast)로 제어하는 캐시 일관성 기법이다.
2. 가치: 무의미한 브로드캐스트(Broadcast) 트래픽을 원천 차단하여, 64코어~수백 코어에 달하는 거대 NUMA 서버 환경에서도 네트워크 병목 없이 완벽한 캐시 일관성(ccNUMA)을 보장하는 유일한 해법이다.
3. 융합: 중앙 장부를 저장하기 위한 거대한 추가 SRAM 용량(Directory Overhead)이 필요하며, 분산 데이터베이스의 메타데이터(Metadata) 관리 철학과 완벽히 융합되는 매니코어(Many-core) 시대의 핵심 아키텍처다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

디렉터리 기반 프로토콜 (Directory-based Protocol)은 "동네방네 소리 지르는(Snooping) 방식은 사람이 적을 때나 먹힌다"는 뼈저린 교훈에서 탄생한 대형 인프라 기술이다.

코어가 4개일 때는 한 코어가 데이터를 고칠 때 "나 데이터 바꿨어!!"라고 버스에 소리(Broadcast)치면 3명만 들으면 됐다. 하지만 서버가 커져 코어가 128개가 되면, 1초에 수억 번씩 127명에게 소리를 질러야 한다. 결국 버스(통신망)는 엿듣는 신호 트래픽으로 꽉 막혀, 정작 진짜 데이터를 전송해야 할 대역폭은 0이 되어버리는 대재앙(Snoop Storm)이 발생했다.

서버 엔지니어들은 소리 지르는 걸 전면 금지했다. 대신 중앙 관리실(Directory)에 장부를 하나 갖다 놓고, "누가 무슨 책(데이터)을 빌려 갔는지"를 다 적어놓기로 했다. 누군가 책을 수정하면 동네방네 소리치지 않고 장부 관리자에게만 말한다. 관리자는 장부를 쓱 보고, 예전에 책을 빌려 간 딱 그 3명한테만 조용히 귓속말로 1:1 톡(Unicast)을 보내 "야, 책 내용 바뀌었대. 네가 가진 거 버려"라고 통보한다. 이것이 디렉터리 프로토콜의 위대한 본질이다.

[스누핑의 브로드캐스트(낭비) vs 디렉터리의 유니캐스트(효율) 비교]

* 상황: 코어 128개짜리 서버. 코어 0이 변수 A를 10으로 바꿈.
  (변수 A의 복사본은 코어 5, 코어 99 두 명만 가지고 있는 상태)

(A) 구형 스누핑 (Snooping) 방식 - 무지성 확성기
- 코어 0: "아아! 마이크 테스트! 나 A 바꿨다!!!" (127명에게 쏘는 브로드캐스트 패킷 발생)
- 코어 5, 99: "내 거 지워야지" (의미 있음)
- 코어 1~4, 6~98...: "난 A 없는데 왜 자꾸 시끄럽게 해?" (엄청난 125명분의 네트워크 낭비)

(B) 현대 디렉터리 (Directory) 방식 - 핀셋 귓속말
- 코어 0 -> 중앙 디렉터리: "나 A 바꿨어. 조치 좀."
- 디렉터리 (장부 확인 중..): "음, A 빌려 간 놈이 코어 5랑 99뿐이네."
- 디렉터리 -> 코어 5, 코어 99 (딱 2명에게만 1:1 유니캐스트 전송): "너희 둘 캐시 지워라."
=> 결과: 125명은 아무 소리도 못 듣고 자기 일만 평화롭게 함. 버스 대역폭 100% 세이브!

📢 섹션 요약 비유: 회사에서 1명의 주소가 바뀌었을 때 전 직원 1,000명에게 단체 스팸 메일을 뿌리는 게 스누핑이라면, 인사팀(디렉터리) 장부를 확인해 그 직원과 같은 부서에 있는 3명에게만 슬쩍 카톡(유니캐스트)을 보내는 스마트한 행정이 디렉터리 프로토콜입니다.

Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)

디렉터리 아키텍처가 동작하려면 메인 메모리(RAM)나 L3 공유 캐시 옆에 거대한 '상태 저장용 장부(SRAM)'가 반드시 하드웨어적으로 추가되어야 한다.

디렉터리는 단순히 '누가 가졌냐'만 적는 게 아니라, 스누핑의 MESI 상태처럼 그 데이터가 지금 독점(Exclusive) 상태인지, 여러 명이 읽는 공유(Shared) 상태인지도 장부에 꼼꼼히 기록한다.

[디렉터리 기반 캐시 읽기/쓰기 3단계(Hop) 통신 시나리오]

* 상황: 코어 0(Local)이 데이터를 수정(Write)하려고 한다. 원본 메모리는 코어 1(Home)에 있다.

1. [요청] 코어 0 -> 홈 노드(코어 1)의 디렉터리: "나 쓰기 권한 줘!"
2. [장부 확인 및 무효화] 홈 노드 디렉터리: "장부 보니 코어 2(Remote)가 복사본을 들고 있네."
   -> 코어 1(Home) -> 코어 2(Remote): "코어 0이 쓴다니까 너네 거 파기해!(Invalidate)"
   -> 코어 2(Remote) -> 코어 1(Home): "파기 완료! (Ack)"
3. [권한 부여] 코어 1(Home) -> 코어 0(Local): "깔끔하게 정리했다. 이제 네가 독점해서(M) 써라!"

* 아키텍처 딜레마: 통신이 1:1로 깔끔해져서 대역폭은 아꼈지만, 
  Home 노드를 거쳐 가야 해서 지연시간(Latency)은 스누핑보다 오히려 1~2 Hop 더 늘어난다!

이 "지연 시간 증가"라는 치명적인 단점을 감수하면서도 디렉터리를 쓰는 이유는 오직 하나, 64코어 이상의 매니코어 시스템에서 버스가 터지는 스누핑의 파국(Scalability Wall)을 막을 수 있는 지구상 유일한 대안이기 때문이다.

📢 섹션 요약 비유: 스누핑 방식은 동네 시장에서 확성기로 "내 차 빼달라!"고 외치면 1초 만에 차 주인이 튀어나오는 빠른 방식이지만, 서울 한복판(128코어)에서 확성기를 쓰면 소음공해로 도시가 마비됩니다. 그래서 구청(디렉터리)에 전화해 차 번호를 조회하고 차주에게 문자를 보내는 방식(조금 느리지만 시스템은 쾌적함)을 쓰는 것입니다.

Ⅲ. 융합 비교 및 다각도 분석 (Comparison & Synergy)

디렉터리 아키텍처의 역사는 "이 엄청난 장부의 크기(디렉터리 오버헤드)를 어떻게 압축하고 줄일 것인가?"에 대한 하드웨어 엔지니어들의 뼈 깎는 융합적 투쟁의 역사다.

디렉터리 오버헤드 방어 아키텍처 비교

타 과목 관점의 융합 시너지

• 분산 시스템 아키텍처 (Zookeeper / etcd): 하드웨어의 디렉터리 프로토콜은 소프트웨어 분산 아키텍처의 **메타데이터 저장소(Metadata Store)**와 완벽하게 100% 동일한 프랙탈 구조다. 하둡(Hadoop) 클러스터에서 수천 대의 노드 중 어느 노드에 어떤 파일 조각이 들어있는지 추적하기 위해 '네임 노드(NameNode)'라는 거대한 장부를 둔다. 또한 마이크로서비스(MSA)에서 어떤 서비스가 살아있는지 서비스 레지스트리(Eureka 등)에 등록하는 행위 모두 디렉터리 기반의 '중앙 장부' 철학을 소프트웨어로 융합한 것이다.
• 캐시 아키텍처의 하이브리드 (Snoop-Directory 융합): 최신 인텔/AMD 칩은 스누핑과 디렉터리를 흑백으로 나누지 않는다. 칩 한 개(Socket) 내부에 있는 8~16개의 코어끼리는 **스누핑(Snooping)**으로 광속 통신을 하고, 다른 칩(다른 소켓이나 다른 서버)으로 넘어갈 때는 칩 출구에 있는 디렉터리 컨트롤러를 거쳐 **유니캐스트(Directory)**로 통신하는 2-Tier 하이브리드 ccNUMA 아키텍처를 융합하여 속도와 확장성 모두를 잡았다.

[소프트웨어와 하드웨어의 디렉터리 관리 철학 프랙탈]

[ Hardware: 멀티코어 캐시 디렉터리 ]
주소 0xFFFF -> 코어 1, 코어 4가 복사본을 가짐 (비트 벡터: 01001000...)
* 목표: 캐시 일관성(Coherence) 유지

[ Software: 분산 DB 네임 노드 (HDFS) ]
파일 "user.csv" -> 서버 1번, 서버 4번 데이터 블록에 저장됨
* 목표: 파일 복제본 일관성 및 라우팅

=> 결론: 무언가 파편화되어(분산) 존재할 때, 확성기를 쓰지 못할 만큼 스케일이 커지면 
   결국 '중앙 장부(디렉터리/메타데이터)'를 둬야만 통신이 붕괴되지 않는다는 것은 
   컴퓨터 공학을 관통하는 절대 진리다.

📢 섹션 요약 비유: 작은 학교에서는 선생님이 "철수 어디 있니!" 하면 되지만, 전국에 수만 개의 학교가 있을 때는 교육부 중앙 서버(디렉터리)에 철수 학번을 검색해서 그 학교에만 정확히 팩스(유니캐스트)를 꽂아 넣는 하이브리드 통신 시스템이 필수적입니다.

Ⅳ. 실무 적용 및 기술사적 판단 (Strategy & Decision)

실무 클라우드 아키텍트가 대규모 NUMA 서버(예: 128코어 AMD EPYC)에 고성능 코드를 배포할 때, 이 디렉터리 지연(Directory Latency)의 늪을 피하지 못하면 1억 원짜리 장비가 100만 원짜리 데스크탑보다 버벅거리게 된다.

실무 하드웨어 한계 돌파 및 코딩 최적화 시나리오

1. NUMA 핑퐁 지연과 로컬 메모리 친화성 (Memory Affinity) 강제

   • 상황: 2소켓(64코어 x 2) 서버에서 C++ 게임 엔진의 틱 레이트(Tick rate)가 주기적으로 3배 이상 느려짐.
   • 의사결정: OS 커널 레벨에서 numactl --cpunodebind=0 --membind=0 명령어로 프로세스를 실행시켜, 스레드와 메모리를 강제로 하나의 NUMA 노드 안에 묶어버려 홈 노드(Home Node)와 로컬 노드(Local Node)를 일치시킨다.
   • 이유: 스레드가 메모리는 노드 0번에 뒀는데 코어는 노드 1번에서 돌면, 데이터 하나를 읽을 때마다 코어 1번이 -> 노드 0번 디렉터리에 질문하고 -> 허락받고 데이터를 퍼오는 3-Hop 통신(디렉터리 페널티)이 수십만 번 발생한다. 홈 노드 디렉터리를 거치는 원격 핑퐁은 스누핑보다 대기 시간이 훨씬 기므로(수백 ns 낭비), 이 물리적 거리를 S/W로 틀어막는 것이 NUMA 튜닝의 알파이자 오메가다.

2. 읽기 전용 객체(Read-only)의 활용 (디렉터리 무효화 폭풍 방어)

   • 상황: 멀티스레드 기반 Java 마이크로서비스에서 유저 설정 정보 객체를 100개의 스레드가 수시로 읽음. 그런데 가끔 1개의 스레드가 업데이트할 때마다 전체 성능 스톨(Stall)이 터짐.
   • 의사결정: 객체를 수정 가능한(Mutable) 상태로 두는 대신, 수정 시 기존 객체를 고치지 않고 아예 100% 새로운 불변(Immutable) 객체를 새로 만들어 참조 포인터만 스와핑(Copy-on-Write)하도록 리팩토링한다.
   • 이유: 하나의 낡은 변수를 계속 고치면, 칩 밑바닥의 디렉터리 장부는 100개의 코어에게 일일이 무효화(Invalidate) 패킷을 날리느라 QPI/UPI 인터커넥트 버스를 마비시킨다. 차라리 메모리를 조금 낭비하더라도 불변 객체를 새로 띄우면, 디렉터리 갱신 폭풍(Invalidation Storm) 자체가 터지지 않아 코어 100개가 각자의 로컬 캐시 히트(Cache Hit)를 달달하게 100% 누리며 폭주할 수 있다.

[대규모 서버의 성능 병목을 잡는 캐시 프로파일링 트리]

[현상] 코어 수가 많을수록 CPU %sys(커널 락 대기)가 비정상적으로 높아진다.
 ├─ `perf c2c` (Cache-to-Cache) 모니터링 시 디렉터리 원격 접근(Remote HITM) 횟수가 높은가?
 │   ├─ Yes ──> (디렉터리 오버헤드 지뢰 폭발!)
 │   │          스레드들이 서로 다른 소켓(CPU)에 걸쳐 있으면서 하나의 공유 락(Global Lock) 
 │   │          변수를 미친 듯이 갱신(Write)하고 있음. 디렉터리 컨트롤러가 마비됨.
 │   │          => 해결: 스레드마다 Thread-Local 변수로 쪼개거나 락프리 링버퍼 사용 필수.
 │   │
 │   └─ No ───> 캐시 충돌 문제는 아님. 디스크 I/O 슬립 상태(iowait)를 점검할 것.

운영 및 아키텍처 도입 체크리스트

• 퍼블릭 클라우드 컴퓨팅 최적화 인스턴스(C5/C6)를 빌릴 때, 클라우드 공급자가 하이퍼바이저를 통해 vNUMA 토폴로지를 내 게스트 OS(VM)에 정확히 맵핑시켜 주었는지 확인했는가? (안 해주면 게스트 OS가 디렉터리 페널티를 무시하고 스레드를 미친 듯이 이주시킴)
• 데이터베이스 서버를 세팅할 때, 메모리 대역폭을 극대화하기 위해 NUMA 인터리빙(Interleaving) 정책을 켜버리면 디렉터리 통신(Remote Access)이 50% 확률로 무조건 발생한다는 사실을 인지하고 속도 지연(Latency)과 용량 균형(Capacity) 중 후자를 챙기기로 합의했는가?

안티패턴: 자바스립트 생태계의 단순한 싱글 스레드 멘탈 모델에 갇혀, 64코어짜리 비싼 NUMA 서버에 수십 기가바이트짜리 공유 캐시(전역 변수 맵)를 띄워놓고 100개의 PM2 워커(프로세스)가 사정없이 읽고 쓰게 놔두는 것. 하드웨어의 스누핑과 디렉터리가 무효화 패킷을 나르다 과로사하여 서버가 그냥 멈춰버린다.

📢 섹션 요약 비유: 서류를 볼 사람이 100명이면, 서류 원본 1장을 구청(디렉터리)에 놓고 볼 때마다 찾아와서 도장(무효화/수정) 찍게 만들면 구청 업무가 마비됩니다. 진정한 튜닝 고수는 구청을 아예 가지 않도록 "서류를 100장 복사(불변 객체화)해서 각자 평생 보게 만드는" 극단적 격리 설계를 하는 사람입니다.

Ⅴ. 기대효과 및 결론 (Future & Standard)

디렉터리 기반 프로토콜은 트랜지스터 면적을 희생하여 "통신 버스의 붕괴"라는 물리학적 한계를 극복해 낸 엔터프라이즈 서버 아키텍처의 구원자다.

미래 전망: 칩 내부에 수백 개의 코어가 들어가는 시대가 오면서, 거대한 하나의 중앙 디렉터리 장부를 유지하는 것조차 병목(Central Bottleneck)이 되고 있다. 미래의 아키텍처는 디렉터리를 단일 지점이 아닌 칩셋 내부의 캐시 슬라이스 뱅크(Mesh 구조) 곳곳에 수십 개로 분산(Distributed Directory)시켜 해시 라우팅으로 분배하는 형태로 진화하고 있다. 궁극적으로는 광학 스위칭(Silicon Photonics)과 융합하여 장부 확인과 데이터 전송 지연을 '0(Zero)'에 수렴시키는 궁극의 캐시 일관성 망이 도래할 것이다.

📢 섹션 요약 비유: 확성기(스누핑)의 시대가 지고, 장부(디렉터리)의 시대가 데이터센터를 평정했습니다. 이제 미래에는 이 거대한 중앙 장부마저 너무 무거워서, 수백 명의 비서가 장부를 찢어 들고 빛의 속도(광학 칩)로 분산 처리하여 일관성 지연이라는 개념 자체를 역사 속으로 지워버릴 것입니다.

📌 관련 개념 맵 (Knowledge Graph)

• 캐시 일관성 (Cache Coherence) | 여러 코어가 복사해 간 캐시 데이터가 서로 다르게 변하는 걸 막는 전체 패러다임
• 스누핑 프로토콜 (Snooping) | 디렉터리와 대척점에 있는 구형/소형 아키텍처로, 장부 없이 모든 코어가 1개의 버스에서 확성기 방송을 듣고 캐시를 일치시키는 방식
• NUMA (Non-Uniform Memory Access) | 메모리가 CPU 곁에 쪼개져 있는 구조로, 디렉터리 프로토콜이 반드시 융합되어야만(ccNUMA) 이 거대한 분산 메모리 간의 캐시 통신이 가능한 뼈대
• MESI 프로토콜 | 캐시의 상태를 수정, 독점, 공유, 무효로 나누는 4대 천왕으로, 스누핑이든 디렉터리든 이 상태 기계 룰을 기반으로 동작함
• 거짓 공유 (False Sharing) | 물리적으로 같은 64바이트 캐시 블록에 들어온 죄 없는 변수들이, 디렉터리 통신망을 미친 듯이 왕복하게 만들어 성능을 파괴하는 최악의 병목 현상

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

1. 개념: 디렉터리 프로토콜은 친구 1,000명이 똑같은 일기장을 돌려 쓸 때, 누가 일기를 고쳤는지 동네방네 소리 지르면(스누핑) 너무 시끄러우니까, 가운데 '일기장 관리 선생님(디렉터리)'을 두는 거예요.
2. 원리: 내가 일기장을 고치고 싶으면 선생님한테 조용히 말해요. 그럼 선생님이 장부를 쓱 보고, "아, 방금 전까지 일기장 복사본을 가져간 애가 5반 철수랑 7반 영희구나?" 하고 딱 그 2명한테만 귓속말을 해서 지우게 하는 거죠.
3. 효과: 이렇게 하면 998명의 친구들은 시끄러운 소음 없이 자기 공부에 집중할 수 있어서, 아무리 컴퓨터 두뇌가 수백 개로 늘어나도 조용하고 빠르게 척척 돌아갈 수 있답니다.