#CS#Architecture#Von Neumann#Bottleneck#History
폰 노이만 구조: 현대 컴퓨터의 설계 원리
왜 CPU는 빠른데 컴퓨터는 느릴까? 80년 전 고안된 폰 노이만 구조의 혁명적인 아이디어와, 그것이 남긴 치명적인 병목현상에 대해 정리했습니다.
2025년 1월 21일
Codemapo
왜 CPU는 빠른데 컴퓨터는 느릴까? 80년 전 고안된 폰 노이만 구조의 혁명적인 아이디어와, 그것이 남긴 치명적인 병목현상에 대해 정리했습니다.
내 서버는 왜 걸핏하면 뻗을까? OS가 한정된 메모리를 쪼개 쓰는 처절한 사투. 단편화(Fragmentation)와의 전쟁.
미로를 탈출하는 두 가지 방법. 넓게 퍼져나갈 것인가(BFS), 한 우물만 팔 것인가(DFS). 최단 경로는 누가 찾을까?
이름부터 빠릅니다. 피벗(Pivot)을 기준으로 나누고 또 나누는 분할 정복 알고리즘. 왜 최악엔 느린데도 가장 많이 쓰일까요?
매번 3-Way Handshake 하느라 지쳤나요? 한 번 맺은 인연(TCP 연결)을 소중히 유지하는 법. HTTP 최적화의 기본.
최근에 M3 칩이 탑재된 최신형 맥북 에어를 샀습니다. "이제 발열도 없고 엄청 빠르겠지?"라고 기대했지만, 크롬 탭을 수십 개 띄우고 도커(Docker) 컨테이너를 몇 개 돌리니 여지없이 바닥이 따뜻해지더군요.
"아니, CPU가 이렇게 빠르고 공정이 미세화됐다는데 도대체 왜 열이 나는 거야?"
단순히 작업량이 많아서라고 생각했습니다. 하지만 컴퓨터 구조를 공부하면서 충격적인 사실을 알게 되었습니다. CPU가 일을 열심히 해서 뜨거운 게 아니었습니다. CPU가 메모리에서 데이터를 가져오는 '길'이 막혀서, 기다리느라 열이 나는 것에 가까웠습니다.
우리가 쓰는 모든 컴퓨터(스마트폰, 노트북, 슈퍼컴퓨터)는 1945년에 고안된 '폰 노이만 구조'라는 설계도 위에서 만들어집니다. 그리고 이 설계도에는 태생적인, 아주 치명적인 약점이 숨어 있었습니다.
오늘은 천재 수학자 존 폰 노이만(John von Neumann)이 컴퓨터에 불어넣은 영혼과, 그가 남긴 숙제인 병목 현상(Bottleneck)에 대해 정리해봅니다.
폰 노이만 구조가 나오기 전, 초기 컴퓨터(에니악 등)는 그야말로 '하드(Hard)'웨어 그 자체였습니다.
만약 에니악에게 "1 더하기 1을 해"라고 시키려면, 엔지니어가 덧셈 회로에 물리적인 전선을 연결해야 했습니다. 그러다가 "이제 뺄셈을 해"라고 바꾸려면? 하루 종일 전선을 다 뽑고, 뺄셈 회로에 맞춰 다시 배선을 깔아야 했습니다.
지금으로 치면 앱 하나 실행하려고 아이폰을 뜯어서 기판 납땜을 다시 하는 꼴입니다. 프로그램 자체가 하드웨어에 고정(Hard-wired)되어 있었기 때문입니다.
이 비효율적인 상황을 본 폰 노이만은 획기적인 아이디어를 떠올립니다.
"배선을 일일이 바꾸지 말고, 명령어(프로그램)를 숫자 코드로 바꿔서 메모리에 넣어두면 안 되나?"
폰 노이만의 생각은 단순하지만 강력했습니다.
이것이 현대 컴퓨터의 시초입니다. 이제 우리는 계산을 바꾸기 위해 전선을 뽑을 필요가 없습니다. 그냥 메모리에 있는 파일(코드)만 덮어쓰면 됩니다. 소프트웨어(Software)라는 개념이 하드웨어에서 완전히 독립하는 순간이었습니다.
폰 노이만 구조는 크게 세 가지 부품으로 나뉩니다. 제가 어릴 때 조립 컴퓨터 맞출 때 견적서에 적던 것들과 똑같습니다.
graph TD
subgraph CPU
CU[제어장치 Control Unit]
ALU[산술논리장치 ALU]
Reg[레지스터 Registers]
end
Memory[메모리 Memory\n(프로그램 + 데이터)]
Bus[버스 System Bus]
CPU <==> Bus
Bus <==> Memory
너무나 완벽해 보입니다. 부품을 모듈화해서 갈아 끼우기도 쉽고, 소프트웨어만 바꾸면 되니 범용성도 최고입니다. 하지만 여기에 함정이 있었습니다.
현대 기술의 발전 속도는 불균형합니다. CPU의 처리 속도는 지난 수십 년간 수천 배, 수만 배 빨라졌습니다. 하지만 메모리(DRAM)의 속도는 그만큼 빨라지지 않았습니다.
비유하자면 이렇습니다.
CPU가 아무리 1초에 50억 번 계산(5GHz)을 할 수 있어도, 버스라는 도로가 좁아서 데이터가 1초에 1억 개밖에 못 넘어온다면? CPU는 나머지 시간 동안 그냥 놉니다(Idle).
"데이터 언제 와? 나 할 거 없는데? 아, 심심해."
이때 CPU는 멍하니 기다리는 게 아니라, 전기를 소모하며 대기합니다. 이것이 바로 컴퓨터 성능 저하와 발열의 주범, 폰 노이만 병목현상(Von Neumann Bottleneck)입니다.
명령어(Program)와 데이터(Data)가 단 하나의 버스를 통해 지나가야 하기 때문에 항상 교통 체증이 발생합니다.
이 구조적 한계를 공부하다 보니, 제가 백엔드 개발을 하면서 겪었던 성능 문제와 너무나 닮아있다는 걸 깨달았습니다.
웹 서버(CPU)는 로직 처리가 엄청 빠릅니다. 하지만 항상 어디서 느려지나요? DB(메모리)에서 데이터를 가져오는 네트워크 구간(버스)에서 느려집니다.
// 전형적인 병목 코드 (N+1 문제)
const users = await db.query('SELECT * FROM users'); // 1. 유저 목록 가져옴 (버스 이용)
for (const user of users) {
// 2. 각 유저마다 또 버스를 타고 DB에 다녀옴
const orders = await db.query('SELECT * FROM orders WHERE user_id = ?', [user.id]);
process(orders);
}
이 코드가 느린 이유는 자바스크립트 엔진이 느려서가 아닙니다. 버스를 너무 많이 타서 그렇습니다. 한 번 데이터를 가지러 갔다 오는 비용(Latency)이 비싸기 때문입니다.
하드웨어(폰 노이만 구조)의 병목이나, 소프트웨어(웹 아키텍처)의 병목이나 원리는 똑같았습니다. "처리하는 놈보다 가져오는 길이 좁다."
이 사실을 이해했을 때, 결국 이거였다는 깨달음이 와닿았습니다. 모든 성능 문제의 본질은 "데이터 전달 경로"에 있었던 겁니다.
병목을 조금이라도 줄이기 위해 CPU는 자체적으로 엄청난 최적화를 합니다. 그 중 하나가 명령어 파이프라인(Instruction Pipeline)입니다.
CPU가 명령어를 처리하는 과정은 대략 이렇게 나뉩니다.
전통적인 방식은 이 4단계를 순차적으로 처리했습니다. 명령어 A를 Fetch → Decode → Execute → Write 하고 나서야, 다음 명령어 B를 처리하기 시작하는 겁니다.
하지만 잘 생각해보면 이건 너무 비효율적입니다. A를 Decode하는 동안 Fetch 유닛은 놀고 있잖아요?
그래서 현대 CPU는 공장 생산 라인처럼 단계를 겹쳐서 처리합니다.
시간 1 2 3 4 5 6 7
────────────────────────────────────────
명령A F D E W
명령B F D E W
명령C F D E W
명령D F D E W
명령어 A가 Decode 단계에 들어가면, 곧바로 명령어 B를 Fetch하기 시작합니다. 각 유닛이 쉬지 않고 계속 일하게 만드는 거죠.
이 덕분에 이론상으로는 매 사이클마다 하나의 명령어가 완료될 수 있습니다. 하지만 여기에도 문제가 있습니다. 데이터 의존성(Data Dependency)입니다.
ADD R1, R2, R3 ; R1 = R2 + R3
SUB R4, R1, R5 ; R4 = R1 - R5 (앗! R1이 아직 안 나왔는데?)
두 번째 명령어가 첫 번째 명령어의 결과(R1)를 필요로 합니다. 이 경우 파이프라인이 멈춰야(Stall) 합니다. 결국 병목은 여전히 발생합니다.
그래도 이 파이프라인 개념을 받아들였을 때, 왜 CPU가 클럭 속도만으론 성능을 판단할 수 없는지 이해했습니다. "얼마나 멈추지 않고 연속으로 처리하느냐"가 더 중요했던 겁니다.
이 태생적인 한계를 극복하기 위해 컴퓨터 공학자들은 온갖 꼼수를 다 씁니다.
"메모리까지 가기 너무 머니까, 자주 쓰는 건 그냥 내 주머니(CPU 내부)에 넣어두자." L1, L2, L3 캐시가 바로 이것입니다. 램(RAM)까지 안 가고 CPU 내부에서 해결하려고 만든 초고속 임시 창고입니다.
개발자인 우리가 Redis나 Memcached를 쓰는 이유와 정확히 일치합니다.
"길이 하나라서 막히는 거면, 길을 두 개로 뚫으면 되잖아?" 명령어 전용 버스와, 데이터 전용 버스를 물리적으로 분리한 구조입니다. 초기엔 비싸서 잘 안 썼지만, 요즘엔 CPU 내부의 캐시 레벨에서 이 구조를 차용해서 씁니다.
아두이노나 AVR 같은 임베디드 시스템에서 하버드 구조를 순수하게 쓰는 경우가 많습니다. 프로그램 메모리(Flash)와 데이터 메모리(SRAM)를 아예 물리적으로 분리해버리는 거죠.
폰 노이만 구조에서 모든 데이터는 CPU를 거쳐야 합니다. 키보드 입력을 받아도, 디스크에서 파일을 읽어도, 네트워크 패킷을 받아도 CPU가 일일이 데이터를 옮겨줘야 합니다.
"왜 나(CPU)한테 다 시키는 거야? 하드디스크에서 메모리로 파일 복사하는 건 네들끼리 알아서 못 하냐?"
그래서 나온 게 DMA 컨트롤러입니다. CPU 없이도 주변장치(Peripheral)가 직접 메모리에 데이터를 읽고 쓸 수 있게 해주는 회로입니다.
예를 들어 1GB 영상 파일을 SSD에서 RAM으로 복사할 때, DMA가 없으면:
SSD → CPU 레지스터 → RAM (CPU가 1GB를 다 나르며 고생함)
DMA가 있으면:
SSD → (DMA 컨트롤러) → RAM (CPU는 그동안 딴 일 함)
이 사실을 받아들였을 때, 왜 서버에서 파일 전송 같은 작업이 CPU를 많이 안 먹는지 이해됐습니다. DMA가 버스를 직접 쓰고 있었던 겁니다.
최근 애플이 자랑하는 'Unified Memory Architecture'도 이 병목을 줄이기 위한 시도입니다. CPU와 GPU가 메모리를 따로 쓰지 않고 한 통에 담아서, 서로 데이터를 복사해서 옮기는(버스를 타는) 비용을 없애버린 것이죠.
제 M3 맥북으로 테스트를 해봤습니다. 똑같은 영상 인코딩 작업을 Intel MacBook Pro (16GB DDR4)와 M3 MacBook Air (16GB Unified Memory)로 돌려봤더니:
성능 차이의 비밀은 클럭이 아니었습니다. "GPU가 CPU 메모리에 접근하느라 데이터를 복사할 필요가 없다"는 구조적 우위였습니다. 이 통합 메모리 설계 덕분에 그래픽 작업, 머신러닝 같은 병목에 민감한 작업에서 애플 실리콘이 압도적인 겁니다.
이걸 정리해본다면: 하드웨어 설계자들이 80년 묵은 병목과 싸우기 위해 온갖 우회로를 뚫어놓은 결과물이 지금 내 손에 들린 맥북인 셈입니다.
처음엔 "폰 노이만 구조? 옛날 사람 이름인가?" 하고 넘겼습니다. 하지만 이 구조를 이해하고 나니, 왜 내 컴퓨터가 느린지, 왜 내 서버가 느린지 근본적인 원인이 보이기 시작했습니다.
우리가 작성하는 모든 코드는 결국 '데이터를 가져와서(Fetch), 처리하고(Process), 다시 저장하는(Store)' 작업의 반복입니다. 그리고 대부분의 성능 문제는 '처리'가 아니라 '가져오는 과정'에서 발생합니다.
80년 전 천재가 만들어둔 이 설계도 위에서, 우리는 여전히 그가 남긴 숙제(병목현상)를 풀기 위해 매일 씨름하고 있는 셈입니다. 여러분의 코드는 지금 데이터를 기다리느라 멍때리고(Idle) 있지는 않나요? 한 번 점검해 보시기 바랍니다.
폰 노이만 구조를 공부하면서 처음 마주쳤던 낯선 용어들을 정리해봅니다.
프로그램(명령어)과 데이터를 같은 메모리 공간에 함께 저장하는 방식. 이 개념 덕분에 우리는 하드웨어를 건드리지 않고 소프트웨어만 바꿔서 다른 작업을 할 수 있습니다. 폰 노이만 구조의 핵심 아이디어입니다.
CPU와 메모리, 주변장치를 연결하는 '데이터 도로'. 주소 버스(Address Bus), 데이터 버스(Data Bus), 제어 버스(Control Bus)로 나뉩니다. 폰 노이만 병목의 주범이기도 합니다.
명령어와 데이터가 하나의 버스를 공유하기 때문에 발생하는 전송 속도의 한계. CPU가 아무리 빨라도 메모리-버스 구간이 느리면 전체 성능이 떨어지는 현상을 말합니다.
명령어 처리 단계(Fetch-Decode-Execute-Write)를 겹쳐서 동시에 여러 명령어를 처리하는 기법. 공장 생산 라인처럼 작업을 병렬화해서 처리량을 늘립니다.
CPU 내부 또는 근처에 위치한 초고속 메모리. 자주 쓰는 데이터를 미리 복사해둬서 메인 메모리까지 가는 시간을 절약합니다. L1, L2, L3로 계층화되어 있습니다.
명령어 메모리와 데이터 메모리를 물리적으로 분리한 구조. 명령어와 데이터를 동시에 읽을 수 있어서 폰 노이만 병목을 일부 해결합니다. 임베디드 시스템에서 주로 쓰입니다.
CPU를 거치지 않고 주변장치가 직접 메모리에 접근할 수 있게 하는 기술. 대용량 데이터 전송 시 CPU 부하를 크게 줄여줍니다.
CPU와 GPU가 같은 물리적 메모리 공간을 공유하는 구조. 애플 실리콘(M1/M2/M3)이 대표적이며, 데이터 복사 오버헤드를 제거해서 성능을 높입니다.
실무에서 자주 나오는 질문들과, 제가 공부하면서 궁금했던 것들을 정리해봅니다.
폰 노이만: 명령어와 데이터가 같은 버스, 같은 메모리를 씁니다. 구조가 간단하고 유연하지만, 둘이 경쟁하느라 병목이 생깁니다.
하버드: 명령어용 메모리/버스와 데이터용 메모리/버스를 분리합니다. 동시 접근이 가능해서 빠르지만, 비용이 높고 복잡합니다.
적용: 요즘 CPU는 외부 메모리는 폰 노이만 방식이지만, 내부 캐시 레벨에서는 하버드 구조를 섞어 씁니다 (Modified Harvard Architecture).
바로 폰 노이만 병목 때문입니다. CPU가 5GHz에서 10GHz로 2배 빨라져도, 메모리에서 데이터 가져오는 속도가 그대로라면 CPU는 그냥 더 많이 기다릴 뿐입니다. 실제로 2000년대 중반 이후 CPU 클럭이 정체된 이유도 "전력 대비 효율"이 떨어지기 때문입니다. 대신 코어를 여러 개 넣거나, 캐시를 키우는 방향으로 발전했습니다.
캐시는 완화일 뿐 해결은 아닙니다. 캐시는 "자주 쓰는 데이터"를 미리 복사해두는 거라서, 캐시에 없는 데이터를 요청하면 (Cache Miss) 결국 메인 메모리까지 가야 합니다. 특히 랜덤 액세스가 많은 작업(포인터 체이싱, 해시맵 순회 등)에서는 캐시 효율이 떨어져서 병목이 여전히 발생합니다.
그 전에는 프로그램을 바꾸려면 하드웨어를 바꿔야 했습니다. 에니악 시절에는 전선을 뽑고 꽂아야 했고, 프로그램 하나 수정하는 데 며칠씩 걸렸습니다. 프로그램을 메모리에 저장하는 순간, 소프트웨어와 하드웨어가 분리되었고, "범용 컴퓨터"가 탄생했습니다. 지금 우리가 앱 스토어에서 앱 다운받아서 쓸 수 있는 것도 다 이 개념 덕분입니다.
일반 PC에서는 CPU 메모리(DDR RAM)와 GPU 메모리(VRAM)가 따로입니다. 그래픽 작업을 할 때:
CPU 메모리 → (PCIe 버스) → GPU 메모리 (데이터 복사 비용 발생)
애플 실리콘은 CPU/GPU가 같은 메모리를 봅니다. 복사 과정이 없으니:
CPU/GPU 모두 → 통합 메모리 (Zero-copy)
영상 편집, 3D 렌더링, AI 학습처럼 CPU-GPU 협업이 많은 작업에서 엄청난 이득을 봅니다.
꼭 그래야 합니다. 특히:
결국 하드웨어 병목과 소프트웨어 병목의 해결 원리는 같습니다. "데이터 전송 횟수를 줄여라."