[CS] 5. 주기억 장치
안녕하세요, 루피입니다!
오늘은 주기억 장치에 대해 정리해 보는 시간을 가져보겠습니다. 특히 메모리에 관한 지식은 개발자에게 필수적인 요소라고 생각하는데 이번 기회에 잘 정리해 봐야 할거 같습니다.
바로 시작합니다.
1. 메모리 계층 구조
컴퓨터는 모든 데이터를 하나의 거대한 저장소에 보관하지 않습니다. 마치 우리가 일할 때, 가장 급한 서류는 책상 위에, 덜 급한 건 서랍에, 나중에 볼 건 창고에 두는 것처럼 말이죠. 컴퓨터 메모리도 속도, 비용, 용량을 고려해 계층 구조를 이룹니다.
- 레지스터 : CPU 내부에 있는 매우 빠른 메모리로 CPU가 현재 수행 중인 연산에 필요한 데이터를 저장합니다.
- 캐시 메모리 : CPU가 자주 사용할 것 같은 데이터를 미리 가져다 놓는 고속 메모리입니다. 레지스터보단 느리지만, 주기억장치보다는 훨씬 빠릅니다. (L1, L2, L3 캐시가 있으며 L1이 가장 빠릅니다.)
- 주기억장치(RAM): 실행 중인 앱의 코드와 데이터가 잠시 머무는 공간입니다. 전원이 꺼지면 내용이 사라지는 휘발성 메모리죠.
- 보조기억장치 (Secondary Storage): SSD, HDD 등이 여기에 해당합니다. 전원이 꺼져도 데이터가 영구적으로 보관되는 비휘발성 메모리입니다.
우리 앱이 실행될 때, 앱의 코드와 데이터는
보조기억장치(SSD)에서주기억장치(RAM)로 올라옵니다. 그리고 CPU는 이 RAM에 있는 데이터를 캐시와 레지스터로 가져와 작업을 처리하죠.
이 흐름을 이해하면 내 앱의 성능을 어떻게 최적화할 수 있을지 힌트를 얻을 수 있습니다.
2. 주기억장치란?
CPU는 필요한 데이터가 캐시에 없으면(Cache Miss) 주기억장치에서 직접 데이터를 가져옵니다. 그리고 동시에 캐시 메모리에 적재시킵니다. 이처럼 주기억장치는 CPU가 직접 접근하여 데이터를 읽고 쓰는 '실행의 무대'입니다. 주기억장치는 주로 DRAM과 SRAM으로 나뉘는데, 특성이 명확해 용도가 다릅니다.
| 구분 | SRAM (Static RAM) | DRAM (Dynamic RAM) |
|---|---|---|
| 데이터 유지 | 전원이 공급되는 동안 데이터 유지 (새로고침 불필요) | 주기적인 데이터 새로고침(Refresh) 필요 |
| 속도 | 매우 빠름 | SRAM보다 느림 |
| 비용/구조 | 비싸고 구조가 복잡함 | 저렴하고 구조가 단순함 |
| 주 사용처 | 캐시 메모리 (빠른 속도가 중요) | 주기억장치 (RAM) (대용량이 중요) |
쉽게 말해, SRAM은 비싸고 빠른 '전문가'라서 소량의 데이터를 빠르게 처리하는 캐시 메모리에, DRAM은 가성비 좋은 '일꾼'이라서 대용량의 데이터를 다루는 주기억장치에 사용된다고 기억하면 쉽습니다.
3. 속도를 높이는 비결, 메모리 인터리빙 (Memory Interleaving)
메모리 인터리빙은 CPU의 빠른 처리 속도와 상대적으로 느린 주기억장치(특히 DRAM)의 속도 차이로 인한 병목 현상을 줄여, CPU가 메모리 대기 시간 없이 효율적으로 데이터를 가져올 수 있도록 합니다.
은행에 ATM 기기가 한 대만 있다면 줄이 길어지겠죠? 여러 대를 두면 동시에 여러 사람이 돈을 뽑을 수 있어 효율이 오릅니다. 메모리 인터리빙도 이와 비슷합니다.
하나의 통로가 아닌, 여러 개의 통로로 동시에 접근하는 모습
- 동작 방식: 메모리를 여러 개의 독립적인 모듈(뱅크)로 나눕니다. 그리고 연속된 데이터를
뱅크1,뱅크2,뱅크3,뱅크4에 번갈아 가며 저장합니다. - 효과: CPU가
뱅크1에서 데이터를 읽는 동안, 동시에뱅크2에 다음 데이터를 요청할 수 있습니다. 이렇게 여러 모듈이 동시에 일하기 때문에 실질적인 데이터 처리 속도가 증가할 뿐만 아니라 한 메모리 모듈이 데이터를 처리하는 동안 다른 모듈은 다음 요청을 준비할 수 있어서 지연 시간이 줄어듭니다. - 단점 : 하드웨어 설계가 더 복잡해질 수 있습니다.
4. 논리 주소와 물리 주소
이제 조금 더 깊이 들어가 볼까요? 우리 앱이 실행될 때 "내 데이터는 메모리 100번지에 있어!"라고 생각합니다. 하지만 실제 메모리(RAM) 칩의 100번지에 그 데이터가 있다는 보장은 없습니다.
- 논리 주소 (Logical Address): 프로세스(앱)의 관점. 각 프로세스가 독립적으로 가지는 가상의 주소 공간입니다.
- 물리 주소 (Physical Address): 실제 메모리의 관점. 하드웨어적인 실제 메모리 주소입니다.
이 둘 사이의 번역은 누가, 어떻게 할까요?
4.1.) MMU (Memory Management Unit)
MMU는 CPU 안에 위치한 하드웨어로, 논리 주소를 물리 주소로 번역해 주는 '전문 번역가'입니다. MMU는 페이지 테이블(Page Table)이라는 '주소 번역표'를 참조하여 이 작업을 수행합니다.
MMU는 단순히 주소 변환만 하지 않습니다. 아주 중요한 두 가지 역할을 더 합니다.
역할 1: 메모리 보호
여러 앱이 동시에 실행될 때, A 앱이 B 앱의 메모리 영역을 침범하면 어떻게 될까요? B 앱이 갑자기 죽거나 시스템 전체가 불안정해질 겁니다. iOS에서 여러 앱을 켜둬도 서로 영향을 주지 않는 이유가 바로 MMU의 메모리 보호 기능 덕분입니다.
MMU는 각 프로세스가 접근할 수 있는 메모리 영역의 시작 주소(Base Address)와 크기(Limit)를 기억하고 있습니다. 어떤 프로세스가 메모리 접근을 요청할 때, 그 주소가 허용된 범위 안에 있는지 검사합니다. 만약 범위를 벗어나면 접근을 막아버리죠. 이를 통해 소중한 내 앱과 운영체제를 보호합니다.
역할 2: 주소 변환 속도 향상 (with TLB)
주소를 변환할 때마다 MMU가 매번 페이지 테이블(주기억장치에 있음)을 찾아보는 건 비효율적입니다. 그래서 MMU는 내부에 TLB(Translation Lookaside Buffer)라는 초고속 캐시를 둡니다.
TLB는 '최근에 번역했던 주소들의 목록'을 저장하는 작은 메모장과 같습니다.
- CPU가 논리 주소를 요청하면, MMU는 먼저 TLB를 확인합니다.
- (TLB Hit) 만약 TLB에 정보가 있다면? 바로 물리 주소로 변환! (매우 빠름)
- (TLB Miss) TLB에 정보가 없다면? 페이지 테이블을 조회하여 주소를 변환하고, 그 결과를 TLB에 새로 기록합니다. (상대적으로 느림)
자주 사용하는 코드나 데이터는 지역성(Locality) 원리에 따라 계속 참조될 가능성이 높기 때문에, TLB는 주소 변환 속도를 획기적으로 높여줍니다.
오늘도 화이팅입니다!