ARMv8-A 캐시 시스템 심층 분석: L1 분리부터 분기 예측까지
현대 프로세서의 성능을 좌우하는 진짜 주인공은 화려한 코어 클럭이 아니라 캐시(Cache) 설계다. ARMv8-A 아키텍처를 레퍼런스로, L1 캐시가 명령어와 데이터로 갈라지는 이유부터 Set-associative의 의미, 64바이트 캐시 라인의 비밀, 쓰기 정책, 캐시 일관성(MESI/MOESI), 그리고 분기 예측이 어떻게 병목을 숨기는지까지 한 번에 정리한다.
🧠 모든 이야기의 출발점은 메모리 월(Memory Wall)이다. CPU 코어 클럭은 비약적으로 빨라졌지만 메인 메모리(DRAM) 접근 속도는 그 속도를 따라가지 못했다. 그 결과 CPU는 데이터를 기다리며 노는 시간이 생긴다. 이 간극을 메우려고 CPU와 DRAM 사이에 작고 빠른 SRAM 캐시를 끼워 넣고, 시간적 지역성(한 번 쓴 데이터는 또 쓸 확률이 높다)과 공간적 지역성(쓴 데이터 근처도 곧 쓴다)을 활용한다.
📏 메모리 월: 얼마나 느린가
캐시 계층을 한 단계 내려갈수록 접근 지연은 기하급수적으로 늘어난다. 아래는 코어 입장에서 데이터를 받기까지 걸리는 대략적인 CPU 클럭 사이클 수다. L1을 한 번 놓쳐 DRAM까지 다녀오면 수백 사이클을 통째로 날린다.
※ 사이클 수치는 마이크로아키텍처마다 다른 대략적 값으로, 계층 간 상대 격차의 직관을 위한 참고치다.
✂️ L1 캐시가 I와 D로 나뉘는 이유
ARMv8-A의 Cortex-A 시리즈는 L1을 명령어 캐시(L1-I)와 데이터 캐시(L1-D)로 물리적으로 쪼개는 하버드 아키텍처(Harvard Architecture)를 쓴다. 반면 L2·L3는 명령어·데이터를 한 공간에 담는 통합(Unified) 캐시다.
분리의 핵심 — 대역폭과 구조적 해저드 방지. 파이프라인은 매 클럭 명령어를 인출(Fetch)하면서 동시에 Load/Store 데이터도 읽고 써야 한다. 단일 통합 캐시라면 같은 사이클에 두 요청이 하나의 포트로 몰려 구조적 해저드(Structural Hazard)가 터진다. I/D를 나누면 명령어 인출과 데이터 접근을 매 사이클 100% 병렬로 처리할 수 있다.
둘은 같은 ‘L1’이지만 성격이 미묘하게 다르다.
| 구분 | 📜 L1-I (명령어) | 🗂️ L1-D (데이터) |
|---|---|---|
| 성격 | 본질적으로 읽기 전용 (코드는 실행 중 불변) | 읽기·쓰기 모두 빈번 |
| 접근 패턴 | 순차적(Sequential) 최적화 | 랜덤 액세스, 다양한 크기·비정렬 접근 지원 |
| 부가 회로 | 분기 예측 메타데이터를 라인에 함께 보관하기도 함 | 멀티코어 일관성 유지용 코히어런시 회로 |
Arm 공식 TRM 기준 Cortex-A78과 Neoverse N1은 L1-I·L1-D 모두 4-way set-associative이며, VIPT(Virtually Indexed, Physically Tagged) 설계를 채택한다.
🗄️ Set-Associative(Way)의 의미
4-way, 8-way는 메인 메모리의 특정 주소가 캐시의 어느 자리에 들어갈 수 있는지를 정하는 매핑 방식이다. 세 가지 갈래로 정리하면 다음과 같다.
Direct Mapped (1-way) — 주소당 들어갈 자리가 단 1개. 빠르지만 서로 다른 주소가 같은 자리를 두고 계속 밀어내는 충돌 미스(Conflict Miss)에 취약하다.
Fully Associative — 빈 곳 아무 데나 저장 가능. 공간 효율은 최고지만 찾을 때 전체를 다 뒤져야 해 비교기 회로가 복잡하고 전력 소모가 크다.
Set-Associative (타협점) — 캐시를 여러 Set으로 나누고, 한 Set 안에 여러 칸(Way)을 둔다. “4-way”는 한 Set 안에 데이터가 들어갈 칸이 4개라는 뜻으로, 같은 Set에 배정된 데이터가 최대 4개까지 충돌 없이 공존한다. Way를 늘리면(8·16-way) 충돌 미스는 줄지만 비교 회로가 복잡해져 접근 지연과 전력이 소폭 증가한다.
흔히 ‘ARM Cortex-A의 L1은 보통 2~4-way를 쓴다’고 일반화하지만, Arm 공식 TRM을 펴 보면 Cortex-A78·Neoverse N1은 구체적으로 4-way로 명시돼 있다. 두 설명은 서로 충돌하지 않으며, 공식 매뉴얼 쪽이 더 정밀한 근거다.
🧱 캐시 라인 용량은 왜 64바이트인가
캐시는 1바이트씩 가져오지 않고 한 덩어리, 즉 캐시 라인(Cache Line) 단위로 가져온다. 라인 크기는 줄다리기의 산물이다.
▶ 공간적 지역성 측면에서, 배열 [0]을 읽으면 [1], [2]도 곧 읽으니 주변을 묶어 한 번에 가져오면 메모리 접근 횟수가 급감한다.
▶ 그러나 라인을 256B·512B로 키우면 캐시 용량 낭비와 버스 전송 지연이 커지고, 너무 작으면(16B) 메모리 접근이 잦아진다. 그 균형점이 바로 64바이트다.
과거에는 16B·32B도 썼으나 오늘날 ARMv8-A 기반 Cortex-A 시리즈(A53·A72·A78 등)의 표준 L1/L2 라인은 64바이트다. 다만 아키텍처 스펙은 서버용·커스텀 칩에서 128바이트도 허용하므로, OS는 부팅 시 레지스터를 읽어 크기를 동적으로 파악한다. 그 레지스터가 CTR_EL0(Cache Type Register)다.
🔢 CTR_EL0가 64바이트를 도출하는 법
이 레지스터는 라인 크기를 바이트로 직접 담지 않고 4바이트 워드 단위의 로그 인코딩으로 저장한다. 데이터 캐시는 DminLine(비트 [19:16]), 명령어 캐시는 IminLine(비트 [3:0]). 필드 값이 4(0b0100)이면 → 2⁴ = 16 words → 16 × 4byte = 64 bytes가 도출된다.
✍️ 쓰기 정책과 동작 모드
CPU가 연산 결과를 저장할 때 DRAM으로 즉시 보내지 않는다. DRAM 직접 쓰기는 코어 클럭 대비 수백 배 느려, 매번 다녀오면 치명적 병목이 되기 때문이다.
Write-Back (WB) — 변경분을 캐시에만 쓰고 라인에 ‘수정됨(Dirty)’ 표시만 둔다. 이후 그 라인이 축출(Eviction)될 때 비로소 메모리에 일괄 기록한다. 현대 CPU의 기본 모드.
Write-Through (WT) — 캐시와 메모리에 동시에 쓴다. 일관성이 극도로 중요한 특수 영역에서 제한적으로만 사용한다.
Write-Allocate (WA) / No-Write-Allocate (NWA) — 쓰려는 데이터가 캐시에 없을 때(write miss)의 정책. WA는 블록을 캐시로 가져온 뒤 쓰며 Write-Back과 짝을 이루고, NWA는 캐시를 거치지 않고 메모리에 바로 쓴다.
🔗 캐시 일관성(Coherence)과 ACP
멀티코어 시대에는 각 코어가 자기 L1/L2를 가진다. 코어1이 변수 A를 캐시에서 수정하고 아직 메모리에 안 보냈는데 코어2가 A를 읽으면 구형 데이터를 읽는 오류가 난다. 이 캐시 일관성(Coherence)을 위해 라인마다 상태를 부여한다.
MESI 프로토콜의 네 상태
| 상태 | 의미 |
|---|---|
| M (Modified) | 수정됨, 메모리와 다름, 나만 보유 |
| E (Exclusive) | 메모리와 동일, 나만 보유 (바로 M으로 전환 가능) |
| S (Shared) | 메모리와 동일, 다른 코어에도 존재 가능 (수정하려면 Invalidate 방송 필요) |
| I (Invalid) | 다른 코어가 수정해 무효화된 데이터 |
MOESI 프로토콜은 MESI에 O(Owned) 상태를 추가한 최적화 버전이다. Owned는 라인이 dirty(메모리와 다름)이면서 동시에 다른 캐시와 Shared로 공유되는 상태다. MESI에서는 다른 코어가 요청하면 “수정된 라인을 먼저 메모리에 써야 하는” 오버헤드가 있는데, MOESI는 메모리를 거치지 않고 변경 데이터를 캐시 간 직접 공유해 버스 트래픽과 지연을 크게 줄인다.
시스템 수준 코히어런시 — ACE vs CHI
| 프로토콜 | 특징과 용처 |
|---|---|
| AMBA ACE (AXI Coherency Extensions) |
AMBA 4에서 도입. 기존 AXI에 하드웨어 캐시 일관성 신호 채널을 확장한 형태로, 모바일 같은 소규모 클러스터에 적합. |
| AMBA CHI (Coherent Hub Interface) |
AMBA 5에서 도입. ACE의 확장성 한계를 넘기 위한 패킷 기반·계층형 아키텍처로, 데이터센터·네트워킹의 대규모 고성능 SoC에서 크레딧 기반 패킷 통신으로 확장성을 확보. |
ACP(Accelerator Coherency Port)는 GPU·NPU·DMA 같은 외부 가속기가 메모리에 접근할 때 메인 메모리로 직행하지 않고 CPU의 Snoop Control Unit(SCU)을 통해 캐시 코히어런시 영역(주로 L2 버스)에 직접 접근하게 하는 전용 포트다. ACP가 없으면 가속기가 데이터를 가져가기 전에 CPU가 캐시를 강제로 비우는(Flush/Invalidate) 소프트웨어 오버헤드가 발생한다. ACP를 쓰면 가속기가 CPU 캐시의 최신 데이터를 바로 읽고, 캐시 유지보수 연산 오버헤드가 사라진다.
🔮 분기 예측이 캐시 병목을 줄이는 원리
“분기 예측 고도화가 캐시 병목을 줄인다”는 말은 주로 L1-I(명령어 캐시) 미스를 줄이는 것을 의미한다.
▶ 문제 — if/else·for 같은 분기문을 만나면 CPU는 어느 쪽 코드를 실행할지 조건 연산이 끝날 때까지 모른다. 그때까지 인출을 멈추면 파이프라인이 텅 빈다(Pipeline Bubble).
▶ 예측 원리 — 분기 예측기는 과거 실행 패턴(Branch History Table)을 하드웨어로 기억해, 연산이 끝나기 전에 ‘아마 이쪽’이라고 확률적으로 예측한다.
▶ 병목 완화(Prefetch 효과) — 예측이 서면 CPU는 그 타겟 주소의 명령어를 L2나 메모리에서 미리 L1-I로 당겨온다(Prefetch). 실제로 명령어가 필요한 시점엔 이미 초고속 L1-I에 대기 중이므로, I-cache 미스로 수백 클럭 멈추는 최악의 병목을 하드웨어적으로 은닉한다.
🔁 다이어그램 요약: 분기 명령어를 만나면 예측기가 실행 방향을 먼저 추측한다 — 예측이 맞으면 타겟 명령어를 L1-I로 미리 당겨 놓아 멈춤 없이 실행하고, 틀리면 파이프라인을 비우고(Flush) 처음부터 다시 인출한다. 그래서 예측 정확도가 곧 I-cache 병목의 빈도를 좌우한다.
물론 공짜는 아니다. 예측이 틀리면 미리 가져온 라인과 파이프라인을 모두 비우고 다시 가져와야 하므로 오예측 패널티는 크다. 그래서 현대 코어는 TAGE·perceptron 같은 정교한 예측기에 막대한 트랜지스터를 투자한다.
🧩 정리: 캐시는 정교한 공학적 타협의 집합
ARMv8-A의 캐시 시스템은 단순히 빠른 메모리를 끼워 넣는 수준을 넘어, 유한한 하드웨어 자원(대역폭·전력) 안에서 구조적 해저드와 데이터 오염을 막기 위한 정교한 공학적 타협의 집합이다.
✓ L1의 I/D 분리 → 파이프라인 병렬성
✓ 64바이트 라인과 N-way set-associativity → 지역성과 충돌 미스의 균형
✓ Write-Back과 MESI/MOESI → 성능과 일관성의 균형
✓ ACP·ACE·CHI → 이기종(GPU·NPU) 코히어런시 통합
✓ 분기 예측 기반 I-cache 프리패칭 → 메모리 월의 능동적 은닉
결국 이 모든 장치는 하드웨어가 메모리 월을 넘기 위해 데이터 흐름을 능동적으로 예측·제어하는 단계로 진화했음을 보여준다. 지금까지 살펴본 어떤 지점에서도 서로 충돌하는 설명은 없었다. 일반론은 Arm 공식 TRM·AArch64 매뉴얼의 구체 수치(4-way, CTR_EL0의 64바이트 도출, MOESI의 Owned, ACE/CHI 구분)로 더 정밀해질 뿐이다.
다만 한 가지는 기억해 둘 만하다. 실제 칩별 way 수와 라인 크기는 코어마다 다를 수 있다. 따라서 특정 SoC를 깊이 다룰 때는 해당 코어의 TRM과 부팅 시점의 CTR_EL0 값을 직접 확인하는 것이 가장 정확하다. 캐시는 ‘대략 이렇다’가 아니라 ‘이 칩에서는 정확히 이렇다’를 읽어내는 순간 비로소 손에 잡힌다.
본 글은 ARMv8-A 아키텍처의 일반 동작 원리를 정리한 기술 해설이며, 구체적인 수치(way 수·라인 크기·사이클 지연)는 마이크로아키텍처와 구현에 따라 달라질 수 있습니다. 실제 개발 시에는 대상 코어의 공식 Technical Reference Manual을 우선 참조하시기 바랍니다.
본 글은 공개된 데이터와 출처를 바탕으로 작성했습니다. 최종 업데이트: 2026-06-15