메모리는 남아 있는데, 왜 앱은 멈칫할까

Intro

앱이 버벅일 때 우리는 보통 이렇게 생각한다.

 

“CPU를 너무 많이 쓰고 있나?”
“메모리가 부족한가?”

 

그런데 실제로는 메모리가 남아 있어 보여도
앱이 순간적으로 멈칫하거나, 처음 진입할 때 버벅이거나,
어떤 데이터를 처음 읽는 순간 한 박자 늦는 일이 생길 수 있다.

 

이유는 앱이 메모리를 직접 물리 주소로 다루는 것이 아니라,
가상 주소를 통해 접근하기 때문이다.

 

그리고 그 과정은 생각보다 단순하지 않다.

• 먼저 가상 주소를 물리 주소로 번역해야 하고
• 필요한 데이터가 아직 RAM에 없으면 가져와야 하고
• 이 과정 자체도 비용이 든다

이번 글에서는 이 흐름을 이해하기 위해
가상 메모리, 페이지, page fault, TLB를 하나의 흐름으로 정리해보려고 한다.

---

1. 앱이 파일을 읽는다고 해서, 파일 전체가 RAM에 올라오는 것은 아니다

먼저 하나의 상황을 떠올려보자.

 

앱이 큰 JSON 파일이나 로그 파일, 혹은 실행 파일 안의 코드 일부를 읽으려고 한다고 하자.
직관적으로는 “그 파일을 메모리에 올려서 읽겠지”라고 생각할 수 있다.

 

하지만 실제로는 그렇게 단순하지 않다.

운영체제는 파일 전체를 무조건 RAM에 통째로 올려두고 시작하지 않는다.

대신 필요한 부분만, 필요한 순간에 실제 메모리에 올릴 수 있도록 관리한다.

즉 중요한 건

“이 파일이 존재하느냐”가 아니라
“지금 내가 접근하려는 그 부분이 실제 RAM에 준비되어 있느냐”

이다.

 

이걸 이해하려면 먼저 가상 메모리와 페이지라는 개념이 필요하다.

---

2. 앱은 물리 메모리가 아니라 가상 주소를 사용한다

프로세스는 보통 실제 RAM 주소를 직접 다루지 않는다.
대신 각 프로세스는 자기만의 가상 주소 공간을 가진다.

 

즉 앱 입장에서는
“내가 지금 접근하는 주소”가 있을 뿐이고,
그 주소가 실제 RAM의 어디를 가리키는지는
운영체제와 하드웨어가 관리해준다.

 

이 구조 덕분에 다음이 가능해진다.

• 프로세스끼리 서로의 메모리를 직접 침범하지 않을 수 있고
• 운영체제는 메모리를 더 유연하게 관리할 수 있고
• 실제 메모리에 없는 데이터도 “나중에 준비하는 방식”으로 다룰 수 있다

즉 앱이 어떤 메모리를 읽는다는 건 사실 가상 주소에 접근한다 는 뜻에 더 가깝다.

그리고 이 가상 주소는 나중에 실제 물리 메모리 주소로 번역된다.

---

3. 페이지는 메모리를 관리하는 기본 단위다

가상 메모리를 이해할 때 꼭 같이 나오는 개념이 페이지(page) 다.

 

페이지는 단순히 “데이터 한 조각”이라기보다,
운영체제가 메모리를 관리할 때 사용하는 기본 단위라고 보는 게 더 정확하다.

 

즉 메모리는 아무 주소나 한 바이트씩 따로따로 관리되는 것이 아니라,
일정한 크기의 덩어리 단위로 관리된다.
그 덩어리가 페이지다.

 

여기서 구분해야 할 것이 있다.

• 가상 페이지: 가상 주소 공간 안의 페이지
• 물리 프레임(page frame): 실제 RAM 안의 페이지

즉 프로세스는 가상 페이지를 사용하고, 운영체제는 그 가상 페이지가 현재 어떤 물리 프레임에 대응되는지를 관리한다.

 

여기서 중요한 것은

가상 페이지가 존재한다고 해서
그 페이지가 지금 RAM에 있다는 뜻은 아니다.

 

이 차이를 이해해야
뒤에서 나오는 map, resident, page fault가 자연스럽게 이어진다.

---

4. map은 연결이고, resident는 실제로 RAM에 있는 상태다

map과 resident를 비슷하게 느끼기 쉽다.
하지만 둘은 전혀 다른 개념이다.

- map

map은 어떤 파일 구간이나 메모리 구간을
프로세스의 가상 주소 범위와 연결해 두는 것이다.

 

쉽게 말하면

“이 가상 주소를 읽으면, 이 파일의 이 부분을 보게 하자”

라는 관계를 만들어 두는 것이다.

 

즉 map은 주소 공간상의 연결이다.

- resident

resident는 그 페이지가 지금 실제 RAM에 올라와 있는 상태를 뜻한다.

즉 resident는 현재 물리 메모리에 존재하는 상태다.

 

둘의 차이를 정리하면 이렇게 된다.

• map = 연결되어 있음
• resident = 실제 RAM에 있음

이 둘은 같은 말이 아니다.

 

예를 들어 100MB짜리 로그 파일을 map 했다고 해보자.
그렇다고 100MB 전체가 RAM에 올라와 있다는 뜻은 아니다.

앞부분 1MB만 읽었다면, 앞부분 근처의 페이지들만 resident일 수 있다.
즉 파일은 이미 map 되어 있어도, 필요한 페이지는 아직 resident가 아닐 수 있다.

 

이 차이를 이해하면
왜 어떤 데이터를 “처음 읽는 순간” 느려질 수 있는지가 설명된다.

---

5. 파일을 메모리에 매핑한다는 건, 파일 전체를 미리 올린다는 뜻이 아니다

“파일을 메모리에 매핑한다”는 표현은 처음 들으면
파일 전체를 RAM에 다 올려놓는 것처럼 느껴질 수 있다.

 

하지만 실제로는
파일 내용의 일부를 가상 주소와 연결해 두는 것에 가깝다.

 

즉 운영체제는

• 파일을 디스크 같은 영구 저장소에 두고
• 그 파일의 일부 구간을 가상 주소 공간과 연결하고
• 앱이 그 주소를 메모리처럼 읽을 수 있게 만든다

다만 여기서 중요한 건,
이 연결 자체가 곧바로 “RAM 적재 완료”를 의미하지는 않는다는 점이다.

 

즉

• map = 이 주소로 이 파일 구간을 보게 해둠
• load = 실제 필요한 페이지를 RAM에 올림

 

이 둘을 구분해야
“파일은 이미 연결돼 있는데 왜 나중에 멈추지?”라는 의문이 풀린다.

 

5-1. mappedIfSafe는 무엇을 의미할까

Foundation에서 보이는 mappedIfSafe 는
이 파일을 가능하고 안전하면 virtual memory에 매핑하라는 힌트다.

 

여기서 중요한 건 두 가지다.

 

첫째, 이건 “무조건 매핑”을 뜻하지 않는다.
둘째, “매핑이 안전하지 않다 = 무조건 파일 전체를 한 번에 RAM에 올린다”는 뜻도 아니다.

 

핵심은

매핑이 가능하고 안전하면 매핑 경로를 선호하되,
안전하지 않으면 그 방식을 쓰지 않을 수 있다

는 점이다.

 

이 개념은 외장 저장소나 네트워크 드라이브처럼
파일이 갑자기 사라질 수 있는 환경을 떠올리면 이해하기 쉽다.

 

즉 mappedIfSafe 는 지연 적재의 장점을 활용할 수 있으면 활용하되,
파일 시스템 특성상 매핑이 위험할 수 있으면 조심하라는 의미에 가깝다.

---

6. page fault는 ‘잘못된 접근’만 뜻하는 것이 아니다

이제 실제 접근 시 어떤 일이 생기는지 보자.

CPU가 어떤 가상 주소를 읽으려고 하면
하드웨어는 그 주소를 실제 물리 주소로 번역하려고 한다.

 

이때 만약 해당 페이지가 이미 RAM에 있다면
정상적으로 접근이 진행된다.

 

하지만 그 페이지가 아직 RAM에 없다면
page fault 가 발생한다.

 

여기서 중요한 건
page fault를 무조건 “에러”로만 보면 안 된다는 점이다.

 

page fault는 경우에 따라

“이 주소는 유효하지만,
지금 당장 접근하려면 먼저 페이지를 RAM에 올려야 한다”

는 뜻일 수도 있다.

 

즉 흐름은 이런 식이다.

1. CPU가 가상 주소에 접근한다
2. 주소 번역이 시도된다
3. 해당 페이지가 이미 resident라면 바로 접근한다
4. resident가 아니라면 page fault가 발생한다
5. 운영체제가 필요한 페이지를 RAM으로 가져온다(page-in)
6. 다시 실행을 이어간다

즉 page fault는 무조건 “잘못된 접근”만을 뜻하지 않는다.
경우에 따라서는 “이 주소는 유효하지만, 아직 필요한 페이지가 RAM에 준비되지 않았다”는 뜻일 수도 있다.

---

7. 왜 앱은 순간적으로 멈춘 것처럼 느껴질까

이제 이 개념이 체감 성능과 어떻게 이어지는지 볼 수 있다.

 

겉으로 보기에는 메모리가 아직 많이 남아 있는 것처럼 보일 수 있다.

그런데도 앱이 멈칫할 수 있다.

 

왜냐하면 중요한 건
총 메모리 양이 아니라, 지금 접근하려는 페이지가 이미 resident인지 이기 때문이다.

 

예를 들어

1. 앱이 큰 JSON 파일을 처음 읽거나
2. 큰 로그 파일의 뒷부분으로 갑자기 점프하거나
3. 처음 진입한 화면에서 무거운 로컬 리소스를 한꺼번에 건드리면
   그 순간 필요한 페이지가 아직 RAM에 없을 수 있다.

이런 경우에는
그 순간 필요한 페이지가 아직 RAM에 없을 수 있다.

 

그러면 page fault가 발생하고,
운영체제가 그 페이지를 page-in 하는 비용을 치르게 된다.

 

이 작업이 메인 스레드에서 일어나면
사용자는 그 순간을

• 버벅임
• 멈칫함
• 첫 진입 지연
• 스크롤 hitch

같은 체감으로 느끼게 된다.

 

즉 “메모리가 충분해 보여도 느릴 수 있는 이유”는
메모리 총량이 아니라 첫 접근 비용이 지금 발생했기 때문이다.

---

8. 지금까지는 ‘페이지가 RAM에 있느냐’의 문제였다

여기까지는
“내가 필요한 페이지가 RAM에 있느냐 없느냐”의 이야기였다.

 

그런데 페이지가 이미 RAM에 있다고 해서
모든 비용이 사라지는 건 아니다.

 

왜냐하면 CPU는 여전히
가상 주소를 물리 주소로 번역해야 하기 때문이다.

 

즉 이번에는

“페이지가 있느냐”가 아니라 “주소 변환도 비용이 드느냐”

를 봐야 한다.

 

여기서 등장하는 것이 TLB 다.

---

9. TLB는 주소 변환 결과를 저장하는 캐시다

CPU가 어떤 가상 주소에 접근할 때마다
매번 처음부터 페이지 테이블을 따라가며 번역하면 비효율적이다.

 

그래서 최근에 사용한 주소 변환 결과를 작고 빠른 캐시에 저장해두는데,
이게 TLB(Translation Lookaside Buffer) 다.

 

쉽게 말하면 TLB는 주소 변환 결과 전용 캐시 라고 보면 된다.

 

흐름은 보통 이렇게 이해하면 된다.

1. CPU가 가상 주소에 접근한다
2. 먼저 TLB에 이미 번역된 결과가 있는지 본다
3. 있으면 바로 물리 주소를 사용한다
4. 없으면 페이지 테이블을 따라가며 번역 정보를 찾는다
5. 이 과정을 page table walk라고 부른다

즉 TLB는 RAM에 있는 데이터를 캐시하는 게 아니라,
가상 주소 → 물리 주소 변환 결과를 캐시한다.

 

이 때문에 주소 변환도 성능에 영향을 줄 수 있다.

---

10. 왜 코드와 데이터가 커지면 cache miss와 TLB miss가 늘 수 있을까

이 부분도 자주 헷갈린다.

코드나 데이터가 커진다고 해서 캐시나 TLB 자체가 작아지는 것은 아니다.

 

문제는 내가 동시에 다루는 범위가 커져서 작은 캐시와 TLB 안에 다 담기지 못하게 된다는 점이다.

 

예를 들어

• 코드 경로가 너무 넓고
• 데이터 접근 위치가 흩어져 있고
• 한 번에 많은 페이지를 건드리면

기존에 캐시해 둔 정보가 더 빨리 밀려난다.

 

그 결과

• 데이터 캐시는 cache miss가 늘고
• 주소 변환 캐시는 TLB miss가 늘고
• 전체 접근 비용이 커질 수 있다

즉 불리한 이유는 “용량이 커서”라기보다
작은 캐시 구조가 감당해야 할 작업 범위가 넓어지기 때문이다.

---

11. Apple은 이 흐름을 이렇게 설명한다

Apple은 메모리를 볼 때 할당된 양(allocation) 과 실제로 사용 중인 양(actual memory use) 을 구분한다.

allocation은 앱이 virtual memory address space 에 확보한 메모리이고,

actual memory use는 그중 실제로 physical memory 사용으로 이어진 부분이다.

 

즉 메모리를 할당했다고 해서, 그 크기만큼의 RAM을 곧바로 다 쓰는 것은 아니다.

 

또 Apple은 실제 메모리 동작이 page 단위로 일어난다고 설명한다.
그래서 allocation이 먼저 잡히고, 이후 실제로 사용된 page들이 physical memory를 차지하면서 메모리 사용량이 만들어진다.

이 관점으로 보면 앞에서 정리한 map 과 resident 의 차이도 자연스럽게 이어진다.

 

Apple이 실제 메모리 사용을 볼 때 중요하게 보는 값이 memory footprint 다.
쉽게 말하면, 앱이 시스템에 실제로 부담시키고 있는 메모리 양에 가까운 값이다.

WWDC22에서는 footprint를 앱의 actual memory use 를 이해하는 대표 지표로 설명하고,

여기에 dirty, compressed, swapped pages 가 포함된다고 말한다.

 

즉 단순히 “얼마나 많이 할당했는가”보다, 시스템이 실제로 앱에 얼마나 메모리를 부담시키고 있는지가 더 중요하다는 뜻이다. 

 

도구 관점에서도 같은 흐름으로 설명한다.
Apple은 Xcode의 Memory Report 로 현재와 최근 메모리 사용을 확인하고,

더 자세한 분석은 Instruments와 memory graph 같은 도구로 이어서 보도록 안내한다.

 

또 iOS는 최근 접근하지 않은 메모리 페이지를 compress 할 수 있다고 설명한다.

 

정리하면 Apple은 이 흐름을
allocation → used pages → actual memory use → footprint 라는 관점으로 설명하고 있다.

---

12. 이번 글의 핵심 정리

이번 글에서 가장 중요하게 가져가야 할 것은
메모리를 단순히 “RAM 용량”만으로 보면 안 된다는 점이다.

 

앱은

• 가상 주소를 사용하고
• 그 주소는 실제 물리 주소로 번역되어야 하고
• 필요한 페이지가 아직 RAM에 없으면 page fault가 발생하고
• 그 페이지를 page-in 하는 비용이 들고
• 주소 변환 결과 자체도 TLB가 캐시한다

따라서 성능은 단순히 “메모리가 많냐 적냐”만으로 결정되지 않는다.

 

실제로는

• 지금 필요한 페이지가 resident인지
• 처음 접근하는 비용이 발생하는지
• 주소 변환 캐시가 잘 맞는지
• 접근 패턴의 locality가 좋은지

같은 요소들이 함께 작용한다.

---

마무리

결국 가상 메모리를 이해한다는 건 메모리 총량만 보는 것이 아니라,
지금 필요한 페이지가 실제로 준비되어 있는지와 그 준비 비용이 언제 드러나는지를 이해하는 것이다.
그래서 메모리가 남아 있어 보여도 앱은 순간적으로 멈출 수 있다.