모바일 동작: CPU ↔ Memory ↔ OS ↔ UI Frame

Day 1) 모바일 성능의 전체 지도

• CPU 실행(명령어/파이프라인) ↔ 메모리(캐시/DRAM) ↔ OS(스케줄링/가상 메모리) ↔ UI 프레임
• 핵심 메시지: 프레임 드랍은 제한 시간 안에 작업을 끝내지 못한 결과

정리 질문

• 내 앱에서 프레임/배터리/메모리 문제는 어디에서 주로 생기는가?
• CPU, 메모리, IO 중 무엇이 주범인 상황이 많은가?

---

모바일 동작

모바일에서 화면이 전환되거나 버튼을 눌러 무언가가 동작하기를 기대할 때, 내부에서는 아래와 같은 구성 요소들이 각자 역할을 수행한다.

• CPU ↔ Memory ↔ OS ↔ UI Frame

우선, 위에 나열된 것들이 어떤 역할을 하는지 하나씩 간단하게 이해해보자.

CPU

CPU는 작은 계산기라고 생각하면 되고, 우리가 원하는 결과를 빠르게 계산해주는 역할을 한다.

• CPU 내부에는 레지스터와 캐시(L1, L2, L3)가 있다.
• 계산에 필요한 데이터가 레지스터/캐시에 있다면 빠르게 계산이 끝난다.
• 데이터가 없으면(캐시 미스) 더 하위 캐시나 DRAM(RAM)까지 내려가 데이터를 가져와야 하므로 시간이 늘어난다.
• 즉, “계산이 느리다”는 말은 종종 “계산 자체”가 아니라 “데이터가 올 때까지 기다리는 시간(메모리 대기)”이 커졌다는 뜻일 수 있다.

Memory

“메모리”는 문맥에 따라 다르게 쓰이지만, 이 글에서는 주로 성능 이슈와 연결되는 의미로 정리한다.

• 개발자들이 일상적으로 말하는 “메모리”는 보통 RAM(DRAM; RAM의 한 종류)을 의미한다.
• SSD는 보통 “메모리”라기보다 스토리지(저장장치)로 구분해서 말하는 것이 안전하다.
• RAM은 휘발성, SSD는 영구 저장이라는 특성이 있다.
• 실무에서 “메모리 압박”은 대개 RAM 여유가 줄어드는 상황을 의미하며, 이때 성능/안정성에 영향이 커진다.

OS(Operating System)

운영체제는 깊게 들어가면 끝이 없지만, 이 글에서 OS는 아래 역할을 맡는다고 보면 된다.

• 앱을 실행시키기 위해 process를 만들고, 실행 흐름인 thread를 만든다.
• 여러 스레드/프로세스에 CPU 시간을 나눠주는 스케줄링을 담당한다.
• 메모리를 안전하고 유연하게 쓰게 하는 가상 메모리(virtual memory) 체계를 관리한다.
• 파일/네트워크 같은 I/O도 OS를 통해 수행된다.

UI Frame

사용자는 CPU나 Memory, OS를 직접 볼 일은 없고, 화면(UI Frame)만 본다.

• 화면은 주사율에 따라 갱신 기회가 달라진다.
  • 60Hz: 1초에 60번 → 프레임 예산 약 16.7ms(1000/60)
  • 120Hz: 1초에 120번 → 프레임 예산 약 8.3ms(1000/120)
• 이 예산 안에 “다음 화면을 위한 준비”가 끝나지 못하면 끊김이 발생한다.

---

App 실행 Flow

위 요소를 봤으니, 사용자가 앱을 실행시키면 기기에서 어떤 흐름으로 동작하는지 최소 흐름만 잡아보자.

• 사용자가 앱을 실행하면 OS는 앱 실행을 위한 리소스(바이너리/필요 파일)를 바탕으로 실행 환경을 준비한다.
• OS는 해당 앱을 위한 Process를 만들고, 실행에 필요한 코드/데이터를 메모리에 매핑한다.
• 또한 UI 이벤트를 처리하기 위한 Main Thread를 준비하고, 메인 스레드는 RunLoop를 돌며 이벤트를 처리한다.
• Thread는 “코드”라기보다 실행을 위한 컨텍스트라고 생각하면 된다.
  • 예: Stack, 레지스터 상태(스택 포인터 등), 스케줄링 관련 메타 데이터

나중 참고: Run loops

 

(+) 가상 메모리(VM)와 주소 변환

Process는 물리 주소(Physical Address, PA)를 직접 쓰는 것이 아니라, 가상 주소(Virtual Address, VA)를 사용한다.

• 프로세스가 사용하는 주소는 VA
• CPU가 메모리에 접근할 때는 MMU(Memory Management Unit)가
  • 페이지 테이블(매핑 정보)을 참고해 VA → PA 변환을 수행한다.
• 이 구조 덕분에 OS는 물리 메모리를 유연하게 재배치/공유/회수할 수 있다.

Virtual Address를 쓰는 이유
“그냥 PA를 프로세스에 바로 주면 되는 거 아닌가?”라는 의문이 들었다.
그런데 앱은 실행하면서 메모리를 더 쓰고, 줄이고, 공유하고, 반환하고, 여러 앱이 동시에 왔다 갔다 한다.
OS는 RAM을 고정 칸막이처럼 나눠 운영하기 어렵고, RAM은 퍼즐처럼 조각나기 쉽다.
PA만 쓰는 세계에서 프로세스를 다른 RAM 위치로 옮기려면, 프로세스 내부의 수많은 “포인터(주소 값)”들을 찾아서 전부 새 주소로 수정해야 한다. 포인터는 아래처럼 매우 많다.

• 힙 객체 포인터
• 배열/버퍼 포인터
• 링크드 리스트 next 포인터
• 딕셔너리 내부 포인터
• 런타임 메타데이터 포인터
• 스택에 저장된 리턴 주소/참조 등
  
  반면 VA를 쓰면 OS는 “VA가 실제로 가리키는 PA”만 페이지 테이블에서 바꾸면 된다. 프로세스는 VA를 그대로 쓰면서도, OS는 물리 메모리를 유연하게 관리할 수 있다.

이렇게 프로세스가 만들어지면 앱은 동작한다. 사용자가 버튼을 누르거나 특정 동작으로 계산이 필요해지면,
해당 실행 흐름(스레드)이 CPU 시간을 받아 로직을 수행한다. 그리고 그 결과로 상태가 바뀌면, 화면이 갱신된다.

 

나중 참고:
About the Virtual Memory System

Investigating memory access crashes

---

Problem

앱을 사용할 때 화면이 버벅이거나 멈추는 현상을 한 번쯤은 경험해봤을 것이다. 모든 것이 최적의 상태로 동작하면 이런 일은 적겠지만, 현실에서는 다양한 이유로 끊김이 발생한다.

- Frame Drop

• 60Hz 기준 프레임 예산은 약 16.7ms다.
• 만약 UI 갱신에 필요한 작업이 이 시간보다 오래 걸리면, 새 프레임을 제때 준비하지 못한다.
• 그 결과 “이전 프레임이 한 번 더 보이는” 현상이 발생하며 이를 Frame Drop이라고 부른다.

- Hitch

• 스크롤 중 “툭 끊기는” 체감 사건을 흔히 Hitch라고 부른다. (미세한 끊김)
• Hitch는 대부분 “프레임 예산 초과”가 원인이며, 결과적으로 dropped frame을 동반하는 경우가 많다.

나중 참고: Hitch

---

원인 계층: 왜 데드라인을 못 지키는가

아래는 프레임 드랍/히치가 발생할 수 있는 대표적인 원인들이다.

1. CPU 과부하
   • 계산량이 너무 크면 프레임 예산 안에 끝내지 못한다.
   • 예: 매우 큰 JSON 디코딩, 대량 데이터 처리, 복잡한 레이아웃 계산 등
2. I/O 블로킹
   • 파일/네트워크/DB 등 “기다림이 본질”인 작업을 UI 흐름에서 동기로 수행하면 끊김이 발생하기 쉽다.
   • 예: 큰 파일 읽기 + 파싱을 메인 스레드에서 처리
3. 메모리 계층 병목(캐시 미스/메모리 대기)
   • 데이터가 캐시에 없으면 DRAM까지 내려가며 지연이 커진다.
   • 이때 CPU는 “계산”보다 “데이터 도착”을 기다리느라 느려질 수 있다.
4. 동기화 경합
   • 병렬 작업에서 같은 데이터를 동시에 접근하면 레이스를 막기 위해 락/세마포어 등이 필요해진다.
   • 락 경합이 크면 스레드가 대기(block) 상태로 지연되고, 결과적으로 데드라인을 놓칠 수 있다.
   • (락의 종류에 따라 CPU를 소모하며 대기하는 경우도 있어 상황에 따라 영향이 다르다.)

---

정리 질문에 대한 내 답

- 내 앱에서 프레임/배터리/메모리 문제는 어디에서 주로 생기는가?

• 프레임 문제
  • UI 갱신에 필요한 작업이 프레임 예산 안에 끝나지 않을 때
  • 원인: 메인 스레드 과부하, 동기 I/O, 대량 UI 반영 등
• 배터리 문제
  • 불필요한 CPU 웨이크업/과도한 반복 작업이 많을 때
  • 예: 폴링, 짧은 주기 타이머, 과도한 백그라운드 루프
• 메모리 문제
  • 큰 객체 유지, 과도한 할당/해제 반복, 캐시 정책 실패로 RAM 압박이 커질 때
  • 메모리 압박이 심해지면 시스템이 정리(강한 메모리 회수/앱 종료)로 대응할 수 있다

- CPU, 메모리, I/O 중 무엇이 주범인 상황이 많은가?

• 체감 문제는 종종 “CPU”처럼 보이지만 실제로는 I/O 대기나 메모리 계층 병목(캐시 미스), 동기화 대기가 원인인 경우도 많다.
• 다만 실무적으로는 아래처럼 생각하면 진단이 쉬워진다.
  • 계산이 많으면 CPU 의심
  • 기다림이 본질이면 I/O 의심
  • 랜덤 접근/대용량 데이터/캐시 붕괴면 메모리 계층 병목 의심
  • 락/공유 자원 경쟁이면 동기화 경합 의심
• UI와 관련된 메인 스레드는 가능한 가볍게 유지하고, 무거운 작업은 분리하되 동기화 비용까지 함께 고려해야 한다.

---

결론

우리는 CPU/메모리/I/O 문제를 항상 완벽하게 예방할 수는 없다. 그래서 중요한 건 “감”이 아니라, 어떤 계층이 원인인지 가설을 세우고 측정하는 것이다. 결국엔 Instruments 같은 도구로 확인해야 한다. 적어도 이 글의 결론은 하나다.

• 프레임 드랍은 데드라인 실패다.
• 그래서 성능 문제는 “어느 계층이 시간을 잡아먹었는가”로 분해해서 봐야 한다.

나중 참고:
Measure Energy Impact with Instruments

Improving your app’s performance

Improving app responsiveness

 

 

---

아래는 내가 해당 내용을 학습하기 위해 GPT와 열심히 씨름한 내용이다. 

Chat GPT