1단원 통합 요약

존스노우·2026년 1월 16일

Backend CS Java Performance architecture cpu

Computer Science / Architecture

목록 보기

5/5

0. 서론: 우리는 왜 하드웨어를 알아야 하는가?

개발자가 작성한 고상한 객체지향 코드도, 결국은 전기가 되어 실리콘 칩 위를 달린다.
"내 코드가 물리적으로 어떻게 실행되는가?"를 이해하는 것은 시니어 개발자로 가기 위한 필수 관문이다.

본 포스팅은 CPU가 속도의 한계를 극복해 온 4단계 진화 과정(구조 → 파이프라인 → 예측 → 확장)을 정리하고, 이를 Java 실무와 연결한다.

1. 구조의 한계: 폰 노이만 vs 하버드 (The BottleNeck)

가장 먼저, CPU와 메모리가 어떻게 연결되는지부터 시작한다.

1.1. 폰 노이만 구조 (Von Neumann)

특징: "프로그램 내장 방식". 명령어(Code)와 데이터(Data)가 하나의 메모리에 섞여 있고, 버스(Bus)가 하나다.
병목(Bottleneck): CPU는 명령어를 가져오는 동안 데이터를 읽을 수 없다. (1차선 도로의 비극)
현실: 유연성과 비용 문제로 메인 메모리(RAM)는 여전히 이 구조를 따른다.

1.1.1. [Deep Dive] 심화: 왜 RAM은 여전히 폰 노이만일까?

"병목 현상이 있는데도 불구하고, 왜 현대의 메인 메모리(RAM)는 여전히 폰 노이만 구조를 고집할까?"
정답은 유연성(Flexibility)과 비용(Cost)이라는 현실적인 문제 때문이다.

(1) 유연성: 주차장 이론 (The Parking Lot Theory)
RAM을 주차장에 비유해 보자.

하버드 구조 (RAM 분리): '버스 전용(명령어)'과 '승용차 전용(데이터)' 주차장이 콘크리트 벽으로 나뉘어 있다.
문제: 만약 코드는 짧은데 거대한 이미지 데이터를 처리해야 하는 프로그램(예: 포토샵)을 돌린다면? '버스 주차장'은 텅텅 비어 낭비되는데, '승용차 주차장'은 자리가 없어 Out of Memory가 발생한다.

폰 노이만 (RAM 통합): 주차장에 선만 그어놓고 상황에 따라 유동적으로 쓴다. 메모리 공간 효율(Space Efficiency)이 압도적이다.

(2) 비용: 핀 개수의 악몽 (Pin Count Nightmare)
CPU와 RAM 사이에는 데이터를 주고받는 물리적인 전선(Bus)이 존재한다.

문제: 만약 RAM을 둘로 쪼개면(하버드), CPU에서 나가는 주소 버스와 데이터 버스가 각각 2세트씩 필요해진다.
비용 폭발: CPU의 핀(Pin) 개수가 폭발적으로 늘어나고, 메인보드 회로 설계가 끔찍하게 복잡해진다. 이는 곧 소비자가 감당해야 할 가격 상승으로 직결된다.

(3) 결론: 하이브리드 전략
결국 컴퓨터 공학은 타협점을 찾았다.

외부 (RAM): 전선 비용이 비싸므로 폰 노이만(통합)으로 가성비를 챙긴다.
내부 (L1 캐시): 칩 내부라 전선 비용이 저렴하므로 하버드(분리)로 속도를 챙긴다.

"오! '간이 창고'라는 표현 좋은데? 근데 살짝 오해가 있어!"

네가 말한 "인풋 버스로 쌓고, 아웃풋 버스로 뺀다"는 개념은 하버드 구조(분리형)에 가까워.
우리가 쓰는 폰 노이만 RAM은 그것보다 더 열악해. "문이 하나밖에 없는 창고"라고 봐야 해.

램(RAM)을 가장 쉽게 이해하는 비유(작업대)와, 네가 헷갈려 하는 버스(Bus)의 정체를 딱 정리해 줄게.

1. 램(RAM)은 "작업대(Workbench)"다.

컴퓨터 전체를 '요리'에 비유하면 램의 정체가 확실해져.

HDD/SSD (스토리지): 지하 식자재 창고. 재료는 엄청 많은데, 가지러 가려면 계단 내려가야 해서 오래 걸려. (전원 꺼도 재료는 그대로 있음)
CPU (프로세서): 요리사. 손이 엄청 빠름.
RAM (메모리): 요리사 바로 앞에 있는 "도마와 작업대".

램의 역할

요리사(CPU)가 요리를 하려면 지하 창고(SSD)에서 재료를 꺼내와서 작업대(RAM)에 쫙 깔아놔야겠지?

작업대가 넓으면(16GB, 32GB)? 재료를 많이 꺼내놓고 이것저것 동시에 요리(멀티태스킹) 할 수 있어.
작업대가 좁으면(4GB)? 재료 하나 썰고 치우고, 다시 지하 가서 다른 거 가져와야 해. (컴퓨터가 느려짐)

2. 버스(Bus) 오해 풀기: "1차선 외나무다리"

네가 "한 개 인풋으로 쌓고, 한 개 아웃풋으로 빼냐"고 물었지?
슬프게도 폰 노이만 구조의 RAM은 입구와 출구가 따로 없어.

🚌 폰 노이만의 버스 = "양방향 1차선 도로"

데이터가 다니는 길(Data Bus)이 딱 하나야.

입력(Write): CPU가 RAM에 데이터를 저장할 때, 이 도로를 씀.
출력(Read): CPU가 RAM에서 데이터를 가져올 때도, 똑같은 이 도로를 씀.

🚨 그래서 병목이 생기는 거야

"들어오는 트럭"과 "나가는 트럭"이 같은 도로를 써야 해.

CPU: "야, 데이터 좀 가져와(Read)!"
RAM: "잠깐만! 지금 데이터 저장(Write) 중이라 길이 막혔어. 비킬 때까지 기다려!"

이게 바로 아까 말한 '폰 노이만 병목'의 실체야. 입출구 버스가 따로 있는 게 아니라, 하나의 통로를 번갈아 가며(Time Sharing) 써야 해서 밀리는 거지.

📝 3줄 요약

RAM의 정체: CPU(요리사)가 일하기 편하게 재료를 펼쳐두는 "넓은 작업대".
RAM의 버스: 입력용/출력용이 따로 있는 게 아니라, 하나의 길(Data Bus)로 들어가고 나가는 걸 다 해야 함.
결론: 그래서 RAM은 한 번에 읽기와 쓰기를 동시에 못 해. (이걸 극복하려고 DDR 기술 같은 게 나온 거야!)

1.2. 하버드 구조 (Harvard)

특징: 명령어 메모리와 데이터 메모리가 물리적으로 분리되어 있다. 버스도 2개다.
장점: 동시에 접근 가능 -> 속도 2배.
현실: 속도가 생명인 L1 캐시는 이 구조를 따른다.

💡 [Java Insight] JIT 컴파일러와 캐시 불일치
자바의 JIT 컴파일러가 런타임에 기계어를 생성(Write)하면, 이는 D-Cache(데이터)에 저장된다. 하지만 CPU는 실행할 때 I-Cache(명령어)를 본다. 이 불일치를 해결하기 위해 Flush(동기화) 작업이 필수적으로 발생한다.

2. 시간의 마법: 파이프라이닝 (Pipelining)

구조적 병목을 해결한 뒤, 엔지니어들은 "명령어 처리 시간을 겹치게 만들자"라고 생각했다.

2.1. 빨래방 이론

Non-Pipelined: 세탁(1시간) -> 건조(1시간) -> 개기(1시간) = 총 3시간/1건
Pipelined: (내가 건조할 때, 너는 세탁을 돌린다) = 매 시간마다 1건 완료!
4단계: Fetch → Decode → Execute → Writeback

2.2. 파이프라인의 적: 해저드(Hazard)

구조적 해저드: 하드웨어 자원 부족.
데이터 해저드: 앞 연산 결과가 아직 안 나옴. (해결: 전방 전달/Forwarding)
제어 해저드: if문을 만나서 다음에 뭘 실행할지 모름. (해결: 분기 예측)

3. 미래를 점치다: 분기 예측 (Branch Prediction)

파이프라인이 멈추는 것(Stall)을 막기 위해 CPU는 도박을 시작한다.

3.1. 추측 실행 (Speculative Execution)

원리: if (조건)의 결과를 기다리지 않고, 과거 기록(BHT)을 보고 찍어서 미리 실행한다.
성공 시: 대기 시간 0초. (쾌적)
실패 시: 파이프라인 플러시(Flush). 미리 하던 거 다 갖다 버리고 다시 함.

3.2. 실패의 비용 (The Cost)

고성능 CPU일수록 파이프라인이 깊어서(15~20단계), 한 번 틀리면 15~20 사이클이 공중분해된다.
슈퍼스칼라에서는 한 번에 4~8개를 처리하므로 손해가 더 막심하다.

💡 [Optimization] 개발자의 대처

정렬된 배열: 예측 가능성(Pattern)을 높여 Flush를 방지한다.

Branchless Programming: 비트 연산 등을 사용해 if문 자체를 제거한다.

4. 공간의 확장: 슈퍼스칼라 (Superscalar) & OoO

시간(파이프라인)을 쪼개는 것도 한계에 다다르자, 이제는 공간(도로)을 넓히기 시작했다.

4.1. 슈퍼스칼라 (Superscalar)

개념: CPU 안에 실행 유닛(ALU)을 여러 개 배치하여, 한 클럭에 명령어 4~8개를 동시에 처리한다. (IPC 증가)
핵심: 스칼라(1차선) → 슈퍼스칼라(8차선 고속도로).

4.2. 비순차 실행 (Out-of-Order Execution)

문제: 8차선인데 맨 앞차가 막히면?
해결: 순서 상관없이 "재료 준비된 놈"부터 먼저 실행한다.
정리: 실행은 뒤죽박죽(OoO)으로 하고, 결과는 재정렬 버퍼(ROB)에서 순서대로 맞춘다.

4.3. 한계 (Limitation)

데이터 의존성(Dependency): a = b + c, d = a + 1 처럼 꼬리에 꼬리를 무는 코드는 병렬 처리가 불가능하다. (도로가 넓어도 차가 한 줄로 가야 함)

5. 요약: 성능의 절대 공식

CPU 아키텍처의 발전사는 결국 이 공식을 만족시키기 위한 투쟁이었다.

파이프라이닝: 클럭 스피드(Hz)를 높이기 위한 기술.
슈퍼스칼라: 한 번에 많이 처리해서 IPC를 높이기 위한 기술.
분기 예측 & OoO: 파이프라인과 슈퍼스칼라가 멈추지 않게 돕는 윤활유.

이제 공장(CPU)은 완벽하게 이해했다. 다음 챕터에서는 이 고속 공장에 재료를 공급하는 거대한 창고, [메모리 계층 구조]로 떠나본다.

📝 Velog 포스팅: [CS Deep Dive] 부록

[CS Deep Dive] 1단원 통합 요약 포스팅의 마지막에, 독자들이 가장 궁금해할 만한 심화 질문 두 가지를 명쾌하게 정리한 [Q&A] 섹션입니다. 이 내용을 추가하면 포스팅의 전문성이 한층 높아질 것입니다.

6. [Q&A] 심화 질문: JIT 플러시와 DDR 기술

본문에서 다룬 내용 중, 실무 개발자들이 가장 헷갈려 하거나 궁금해하는 두 가지 핵심 질문에 대해 깊이 있게 답변합니다.

Q1. CPU가 데이터를 읽는 행위(Read)가 곧 JIT 플러시(Flush)인가요?

A. 아닙니다. JIT 상황에서 '읽기'를 수행하기 위한 사전 작업이 '플러시'입니다.

일반적인 데이터 읽기와 JIT가 생성한 코드를 읽는 과정은 완전히 다릅니다.

일반적인 읽기 (Normal Read):

int a = 10;과 같은 변수 데이터를 읽을 때는 메모리에서 CPU로 데이터를 가져오는 단순한 물류 이동만 발생합니다. 플러시 과정은 필요하지 않습니다.

JIT 코드 읽기 (Instruction Fetch & Flush): 🚨

JIT 컴파일러가 런타임에 새로운 기계어 코드를 생성(Write)하면, 이는 D-Cache(데이터)에 저장됩니다.
하지만 CPU가 이 코드를 실행하려면 I-Cache(명령어)에서 읽어와야 합니다. 이때 두 캐시 간의 내용 불일치가 발생합니다.
이를 해결하기 위해 '플러시(Flush)'라는 대청소 작업이 선행되어야 합니다.

Data Cache Flush: D-Cache에 있는 새 코드를 메인 메모리(RAM)로 기록합니다.
Instruction Cache Invalidate: I-Cache의 기존 내용을 무효화(삭제)합니다.
Refetch: 그제야 CPU는 메모리에서 새로운 코드를 안전하게 읽어옵니다(Read).

결론: JIT 플러시는 코드를 읽기 위해 수행되는 비싼 동기화 작업이며, 단순 읽기(Read)와는 구별해야 합니다.

Q2. DDR(Double Data Rate) 메모리는 무엇이고, 왜 빠른가요?

A. 폰 노이만 구조의 좁은 도로(버스)를 효율적으로 사용하기 위한 '타이밍 기술'입니다.

앞서 RAM은 비용 문제로 데이터 버스(도로)가 하나뿐인 폰 노이만 구조를 사용한다고 했습니다. 엔지니어들은 도로를 넓히는 대신, 통행 방식을 개선하여 속도를 높였습니다.

SDR (Single Data Rate) - 옛날 방식:

컴퓨터의 심장 박동인 클럭(Clock) 신호가 올라갈 때(Rising Edge)만 데이터를 전송했습니다. 비효율적이었죠.
(박자 ↑) 데이터 전송 📦 → (박자 ↓) 쉼 💤

DDR (Double Data Rate) - 현대 방식:

클럭 신호가 올라갈 때(Rising) 한 번, 내려갈 때(Falling) 한 번, 총 두 번 데이터를 전송합니다.
(박자 ↑) 데이터 전송 📦 → (박자 ↓) 데이터 전송 📦
결과: 도로는 그대로 1차선이지만, 데이터 전송량(대역폭)은 2배로 증가합니다.

결론: DDR은 물리적인 한계(버스 대역폭)를 타이밍의 마법으로 극복한 공학적 성과입니다. 우리가 사용하는 DDR4, DDR5는 이 기본 원리에 클럭 속도 자체를 엄청나게 높인 것입니다.

[부록] I-Cache vs D-Cache vs RAM: 코드는 어떻게 실행되는가?

우리가 작성한 프로그램이 실행될 때, CPU 주변의 메모리 삼총사(RAM, I-Cache, D-Cache)는 각자 철저하게 분업화된 역할을 수행합니다. 이를 '셰프의 주방'에 비유하여 실제 코드 작동 원리와 연결해 보겠습니다.

1. 비유: CPU 셰프의 주방 시스템

CPU를 손이 엄청나게 빠른 '셰프(요리사)'라고 상상해 봅시다. 셰프가 요리를 하려면 두 가지가 필요합니다.

레시피 (Instruction): "양파를 볶으세요", "소금을 넣으세요" 같은 지시사항.
재료 (Data): 양파, 소금, 고기 같은 실제 재료들.

구성 요소	비유 (주방)	역할 및 특징
RAM (메인 메모리)	지하 대형 창고	모든 레시피북과 식자재가 뒤섞여 보관된 곳. 용량은 크지만 셰프(CPU)가 가지러 가기엔 너무 멀고 멉니다(느림).
L1 I-Cache (명령어)	레시피 전용 거치대	셰프 눈앞에 펼쳐진 코팅된 레시피 카드. 셰프는 이곳을 보며 "다음에 뭘 할지" 결정합니다. 절대 수정 금지(Read Only) 구역입니다.
L1 D-Cache (데이터)	도마와 조리대	실제 재료를 올려두고 썰고, 볶고, 결과물을 잠시 담아두는 그릇. 자유롭게 읽고 쓰기(Read/Write)가 가능한 작업 공간입니다.

2. 실제 코드의 작동 메커니즘

이제 아주 간단한 자바 코드가 실행될 때, 이 세 녀석이 어떻게 움직이는지 추적해 보겠습니다.

// 상황: 이미 컴파일된 기계어 코드가 실행되는 중
int a = 10;
int b = 20;
int sum = a + b; // 이 라인이 실행될 때!

Step 1. 준비 단계 (Loading: 창고에서 주방으로)
프로그램이 실행되면, OS는 지하 창고(RAM)에 있는 내용물들을 셰프가 일하기 편하도록 주방 선반(L1 캐시)으로 미리 옮겨옵니다. 이때 하버드 구조에 따라 철저히 분리합니다.

a + b를 수행하라는 기계어 명령(레시피) -> I-Cache에 꽂아둡니다.
변수 a의 값(10)과 b의 값(20)이라는 실제 데이터(재료) -> D-Cache 도마 위에 올려둡니다.

Step 2. 실행 단계 (Execution: 요리 시작)
이제 CPU(셰프)가 요리를 시작합니다.

Fetch (레시피 확인): CPU는 I-Cache를 봅니다. "다음 할 일은? 아, '더하기(ADD)' 명령이구나."
Decode & Read (재료 준비): "더하려면 재료가 필요하지." CPU는 D-Cache에서 a(10)와 b(20) 값을 읽어옵니다.
Execute (조리): CPU 내부의 연산 장치(ALU)가 10과 20을 더해서 결과값 30을 만듭니다.
Writeback (결과 담기): 만들어진 결과물 30(sum)을 다시 D-Cache의 빈 그릇 영역에 저장합니다.

✨ 핵심 요약

CPU는 "무엇을 할지" 알기 위해 오직 I-Cache만 봅니다.

CPU는 "무엇을 가지고" 할지 알기 위해 D-Cache를 뒤적거립니다.

RAM은 이 모든 것을 공급하는 느리고 거대한 뒷방 늙은이입니다.

3. (심화 복습) JIT 컴파일러가 주방을 어지럽히는 이유

평소엔 이렇게 평화롭지만, JIT 컴파일러가 실행 중에 코드를 만들면 혼란이 발생합니다.

상황: 셰프가 요리 도중, 더 빠른 새로운 레시피를 창조해서 도마(D-Cache) 위에 막 써내려갑니다(Write).
문제: 셰프는 레시피를 볼 때 레시피 거치대(I-Cache)만 봅니다. 도마 위에 쓴 레시피는 보지 못합니다.
해결 (플러시): 도마(D-Cache) 위에 쓴 새 레시피를 코팅해서 재빨리 레시피 거치대(I-Cache)로 옮겨야 합니다. 이 대청소 과정이 바로 앞서 배운 'JIT 플러시'입니다.

❓ [Q&A 심화] RAM에서 캐시로, 데이터는 누가 옮길까? (OS의 오해)

많은 개발자가 혼동하는 부분입니다. "RAM에 있는 코드와 데이터를 적절하게 I-Cache나 D-Cache로 넣어주는 주체는 누구일까요? 운영체제(OS)일까요?"

정답은 "아니요, OS는 손도 대지 않습니다!"입니다.
이 과정은 100% 하드웨어(캐시 컨트롤러)가 자동으로 처리합니다.

1. 역할 분담: OS vs 하드웨어

👮‍♂️ OS (운영체제)의 역할: "창고지기"
OS의 역할은 SSD(스토리지)에서 프로그램을 읽어와 RAM(메인 메모리)에 배치하는 것까지입니다.
"카카오톡 프로그램은 RAM 100번지부터 200번지까지 쓰세요"라고 자리를 잡아주고 나면, OS의 역할은 끝납니다.

🤖 캐시 컨트롤러 (하드웨어)의 역할: "배달 전문 러너"
RAM에서 L1/L2/L3 캐시로 데이터를 퍼 나르는 건, CPU 옆에 붙어 있는 '캐시 컨트롤러(Cache Controller)'라는 특수 하드웨어가 담당합니다.
이 녀석의 원칙은 단순합니다: "CPU가 찾는데 캐시에 없다(Cache Miss)? 그럼 무조건 RAM으로 뛰어가서 가져온다!"

2. I-Cache와 D-Cache로 나뉘어 들어가는 원리

그렇다면 RAM에 섞여 있는 0과 1의 덩어리들이 어떻게 I-Cache와 D-Cache로 구분되어 들어갈까요?
그 기준은 "CPU가 지금 그 데이터를 무엇으로 쓰려고 하느냐(의도)"에 달려 있습니다.

🅰️ 시나리오 A: 명령어 가져오기 (Instruction Fetch)

CPU의 의도: "이제 실행해야 하니까, PC(프로그램 카운터)가 가리키는 주소의 명령어를 가져와!"
캐시 컨트롤러: "주인이 '명령어'를 찾으시네? I-Cache에 없으니 RAM에서 가져오자."
배치: 가져온 데이터를 I-Cache에 저장합니다.

🅱️ 시나리오 B: 데이터 읽기/쓰기 (Data Load/Store)

CPU의 의도: "연산을 해야 하니, 200번지 주소에 있는 데이터 값이 필요해!"
캐시 컨트롤러: "주인이 '연산 재료'를 찾으시네? D-Cache에 없으니 RAM에서 가져오자."
배치: 가져온 데이터를 D-Cache에 저장합니다.

💡 핵심 요약

RAM에 있을 때는 그냥 다 같은 데이터 덩어리일 뿐입니다.

CPU가 그것을 "실행 목적"으로 요청하면 캐시 컨트롤러가 I-Cache에 넣습니다.

CPU가 그것을 "연산 재료 목적"으로 요청하면 캐시 컨트롤러가 D-Cache에 넣습니다.

이 모든 과정에서 OS는 개입하지 않습니다. 캐시는 철저히 하드웨어의 영역입니다.

📚 참고 자료

[Module 1-1] 폰 노이만과 하버드 구조
[Module 1-2] 파이프라이닝의 이해
[Module 1-3] 분기 예측과 성능 최적화
[Module 1-4] 슈퍼스칼라와 비순차 실행

존스노우

어제의 나보다 한걸음 더

이전 포스트