컴퓨터 구조 전체상 — 메인보드·버스·캐시 계층
CPU·메모리·SSD·버스·L1~L3 캐시 — 현대 컴퓨터의 큰 그림과 '왜 특정 구간이 느린가' 감각.
"메모리가 충분한데도 왜 느릴까?" 답은 캐시 미스에 있다. 데이터가 CPU에 가까울수록 빠르지만 작다. 이 계층 감각이 있어야 AI가 만든 코드의 성능 결함을 직감한다.
메인보드는 모든 부품이 꽂히는 판이다. CPU·RAM·SSD·GPU가 각자 슬롯에 꽂히고, 버스(전선 다발)로 서로 데이터를 주고받는다. 대표 버스: PCIe(GPU·NVMe SSD), DDR5(RAM), USB.
| 저장 계층 | 크기 | 접근 시간 | 비유 |
|---|---|---|---|
| CPU 레지스터 | 수백 byte | < 1ns | 손에 쥔 공 |
| L1 캐시 | 32~64 KB | ~1ns | 책상 위 |
| L2 캐시 | 256 KB ~ 1 MB | ~3ns | 책상 서랍 |
| L3 캐시 | 8~64 MB | ~10ns | 옆 책장 |
| RAM | 16~128 GB | ~100ns | 방 저편 선반 |
| NVMe SSD | 512 GB~ | ~50,000ns | 지하 창고 |
| HDD | 1 TB~ | ~5,000,000ns | 외부 창고 |
| 네트워크 (같은 지역) | 무한 | ~1,000,000ns | 바다 건너 |
RAM이 SSD보다 500배 빠르고, L1 캐시는 RAM보다 또 100배 빠르다. 즉 프로그램 성능의 본질은 "얼마나 데이터가 CPU 가까이에 이미 있느냐". '캐시 친화적' 코드가 "충분한 RAM" 코드보다 빠른 이유.
캐시 미스(cache miss) — CPU가 데이터를 요청했는데 L1·L2·L3에 없으면 RAM까지 내려가야 하고, 그 동안 CPU는 논다. 이걸 줄이는 것이 현대 성능 최적화의 핵심. 배열이 해시맵보다 작은 n에서 빠른 것도 캐시 라인을 통째로 담기 때문.
// 왜 배열 순회가 링크드리스트보다 빠른가?
배열: [A][B][C][D][E][F] ← RAM에 연속 배치
CPU가 A 읽으면 B~F도 캐시에 자동 딸려옴
→ 다음 접근은 L1 히트 (1ns)
링크드리스트:
[A]→ ... 멀리 ...→[B]→ ... 멀리 ...→[C]
각 노드가 RAM 이곳저곳 → 매번 캐시 미스 → 매번 100nsBig O가 같아도 실제 속도는 수십 배 차이날 수 있다. AI가 자료구조를 권할 때 'n이 작으면 배열이 더 빠를 수 있다'는 판단은 이 계층에서 온다.
네트워크 ≒ 디스크의 수백 배 느림. 같은 지역 내 API 호출은 ~1ms = 100만 ns = RAM 접근의 1만 배. "DB 쿼리 한 번으로 끝날 걸 for 루프로 100번 호출"이 치명적인 이유. N+1 쿼리 문제(ch22에서 재등장)의 물리적 근거.
OS 맛보기(ch14와 연결). 이 모든 하드웨어 위에 운영체제(OS)가 얹혀 모든 프로그램이 공평하게 CPU·RAM·디스크를 쓰도록 중재한다. macOS/Linux/Windows는 뿌리가 유닉스(1969)에서 갈라진 사촌 관계 — 상세는 ch14-1에서.
CPU에 가까운 순서로 저장 계층 4가지를 나열하시오 (레지스터 제외).
시간복잡도(Big O)가 같으면 실제 실행 속도도 항상 비슷하다.
네트워크 API 호출은 RAM 접근보다 대략 1만 배 느리다.