CPU가 바쁜데도 앱이 느린 이유: 스톨·버블로 이해하는 Instruction Flow

Day 3) CPU 실행 기초: 파이프라인과 스톨

• 파이프라인: 명령어를 단계로 나눠 겹쳐 처리해 처리량을 높임
• 스톨/버블: 데이터 의존성/자원 부족/분기 때문에 파이프라인이 멈추는 현상
• IPC/CPI: 정확한 계산보다 왜 낮아지는지 이해

정리 질문

• CPU가 “바쁘게” 도는데도 실제 진행이 느린 이유는 무엇인가?

---

Intro

앱을 만들다 보면 “왜 이렇게 느리지?”라는 순간을 피하기 어렵다.
그런데 이 현상을 단순히 “CPU가 느리다”라고만 이해하면, 실제로 무엇을 바꿔야 하는지 판단하기가 어렵다.

이 글의 목표는 CPU 성능을 클럭이나 코어 개수가 아니라,

더 실전적인 관점인 ‘명령어가 CPU 안에서 얼마나 막히지 않고 흘러가느냐(Instruction flow)’로 이해하는 것이다.

 

이를 위해 아래 질문에 답할 수 있도록 정리한다.

• 파이프라인은 무엇이고, 왜 처리량을 올릴 수 있는가?
• 그런데도 왜 스톨(stall)과 버블(bubble)이 생기며, 그 결과 IPC/CPI가 어떻게 나빠지는가?
• 현대 CPU의 캐시(cache), Out-of-Order(OOO), 추측 실행(speculation), 슈퍼스칼라(superscalar)는 각각 어떤 병목을 줄이려 했고, 왜 여전히 한계가 남는가?

마지막으로는 이 내용을 엔지니어가 실제로 적용할 수 있는 형태로 내려서,

Apple이 권장하는 “CPU 병목을 피하는 설계 원칙(프레임워크 활용, QoS, 동적 스케줄링, 성능 테스트)”과 연결해 정리한다.

---

1) Problem: 파이프라인은 빠르지만, 현실에서는 자주 멈춘다

CPU는 명령어(instruction)를 처리할 때 보통 다음처럼 여러 단계로 나눈다.

• Fetch(가져오기) → Decode(해석) → Execute(실행) → Write-back(결과 반영)

여기서 파이프라인(pipelining)은 “한 명령어를 다 끝내고 다음 명령어로 넘어가는 방식”이 아니라,
여러 명령어를 서로 다른 단계에서 겹쳐서 진행해 처리량을 올리는 방식이다.

 

예를 들어 CPU는 한 명령어를 실행(execute)하면서, 다음 명령어를 디코드(decode)할 수 있다.

문제는 파이프라인이 항상 매끈하게 흐르지 않는다는 점이다.

• Stall(스톨): 어떤 이유로 파이프라인이 기다리며 멈추는 현상
• Bubble(버블): 그 멈춤 동안 생기는 “유효 작업이 없는 빈 사이클(헛바퀴)”

그래서 “CPU가 바쁘게 돌고 있는데도” 실제 진행이 느릴 수 있다.
CPU가 계산을 못 해서가 아니라, 기다리느라 시간이 새는 것이다.

이걸 성능 지표로 번역하면 감각이 더 명확해진다.

• CPI(Cycles Per Instruction): 명령어 1개를 끝내는 데 드는 평균 사이클
  → 버블이 늘면 CPI는 커진다.
• IPC(Instructions Per Cycle): 사이클 1번에 완료되는 명령어 수
  → 버블이 늘면 IPC는 떨어진다.

즉, “CPU 사용률이 높다”는 사실만으로는 성능을 보장하지 못한다.
유효한 진행(실제 커밋되는 명령어)이 얼마나 되는지가 핵심이다.

---

2) 원인: 스톨을 만드는 3대 병목(데이터 / 분기 / 자원)

파이프라인이 멈추는 원인은 크게 세 가지로 묶이다.

(1) 데이터 병목: Load(메모리 읽기) 지연 (Data Hazard)

CPU 연산은 빠르지만, 메모리(RAM) 접근은 상대적으로 느리다.
필요한 값이 아직 도착하지 않았는데 그 값으로 연산을 해야 하면, 파이프라인은 멈출 수밖에 없다.

• 특히 Load → 바로 사용(load-use) 패턴은 스톨을 만들기 쉬운 대표 케이스이다.
• 캐시 미스가 나서 DRAM까지 갔다 오면 지연이 크게 튀고, 그만큼 버블이 커진다.

(2) 분기 병목: if 같은 조건 분기 (Control Hazard)

분기(if)가 나오면 “다음에 어느 쪽 명령어를 실행할지(다음 PC)”가 확정될 때까지 흐름이 흔들린다.

여기서 사용자가 느끼기 쉬운 포인트가 하나 있다.

• 분기 조건을 판단할 데이터가 아직 없어서 기다린다 → 본질적으로 “데이터 대기” 성격이 강함.
• 조건은 알겠는데, 어느 쪽으로 갈지 예측했다가 틀린다 → 이게 컨트롤 해저드의 고유 손실(플러시로 인해 이미 한 일을 버림).

(3) 자원 병목: 유닛/포트/폭 한계 (Structure Hazard)

동시에 처리하고 싶어도 실행 유닛이나 포트가 부족하면 줄을 서야 한다.
이건 “구조적 자원 경합”으로 생기는 병목이다.

---

3) CPU의 대응: 그래서 현대 CPU는 “흐름을 살리는 장치”를 쌓아왔다 

현대 CPU는 이 병목을 없애기보다는 병목이 생겼을 때 손실을 줄이기 위한 장치를 겹겹이 쌓아왔다.

Apple도 현대 프로세서가 명령어 흐름을 개선하기 위해 다음 같은 장치들을 갖춘다고 설명한다.

• Pipelining
• Out-of-order execution
• Speculative execution
• Superscalar architecture
• Memory caches

이제 이걸 “각 발전이 무엇을 해결하려고 했는가?”로 매핑해보면 이해가 정리된다.

Article: Addressing CPU bottlenecks

---

4) 각 발전은 “무슨 병목”을 해결하려고 했나?

(1) Cache = “메모리 지연을 줄여 데이터 스톨을 줄이기”

타깃: Load 지연으로 생기는 데이터 스톨

 

캐시(cache)는 CPU 가까운 곳에 명령어/데이터를 복제해 두고 반복 접근을 빠르게 한다.
핵심은 “해저드를 제거”가 아니라, 데이터가 더 빨리 도착하게 만들어 스톨 시간을 줄이는 것이다.

• 히트(hit)면 빠르고
• 미스(miss)면 느리다(그리고 이 차이가 스톨을 만든다)

(2) Out-of-Order(OoO) = “데이터 기다림 스톨을 숨기기”

타깃: 데이터(특히 Load) 대기로 생기는 스톨

 

OoO는 스톨을 “없애는” 기술이 아니다.
앞 명령어가 데이터가 올 때까지 멈춰 있으면, 그 사이에 의존성 없는(독립적인) 뒤 명령어를 먼저 실행해서 CPU가 놀지 않게 만든다.

즉, OoO는 스톨을 제거하기보다 스톨 시간을 가려버리는(hide) 접근이다.

(3) Speculative execution(추측 실행) = “분기(컨트롤) 스톨/버블을 줄이기”

타깃: 분기(if)로 생기는 컨트롤 해저드

 

분기에서는 다음 PC(Program Counter)가 확정될 때까지 파이프라인이 흔들린다.
그래서 CPU는 예측을 하고, 그 경로의 명령어를 미리 실행해 둔다.

여기서 포인트는 이것이다.

• 추측 실행은 “할 일이 없어서”가 아니라
• 원래라면 분기 결과를 기다리느라 멈출 상황을 피하기 위해 미리 가는 것

대가(실패 비용)
예측이 틀리면 미리 실행한 걸 버리고(플러시) 다시 해야 한다.
그래서 분기 예측 실패가 잦으면 IPC(Instructions Per Cycle)가 크게 떨어질 수 있다.

(4) Superscalar = “한 사이클 처리 폭(width)을 키워 처리량/경합을 완화”

타깃: 처리량 한계 + 일부 구조적 경합

 

슈퍼스칼라는 CPU 내부에 병렬 구성요소를 둬서 한 사이클에 여러 명령어를 처리할 기회를 늘린다.
(예: 여러 명령어를 동시에 fetch 하거나, 여러 실행 유닛을 둬서 병렬 실행)

여기서 표현을 정확히 하면:

• 구조 해저드를 “없앤다”가 아니라
• 자원 경합을 완화하고 처리량 한계를 높이는 기회를 제공한다.

단, 데이터 의존성이 강하거나 특정 유닛/포트/메모리 경로가 병목이면, 폭이 넓어도 실제 활용은 제한된다.

 

---

(+) CPU 내부 구조(Deep Dive): register / queue / ROB는 왜 필요할까?

위의 장치들(OoO/추측 실행/슈퍼스칼라)은 공통적으로 “동시에 여러 명령어를 진행”시키려 한다.
그러려면 CPU는 진행 중인 명령어와 중간 결과를 잘 보관하고 정리해야 합니다. 여기서 다음 구조들이 등장한다.

(1) Register(레지스터): “CPU 안의 초고속 메모장”

레지스터는 연산 입력/출력, 주소 계산, 중간 결과를 담는 초고속 저장소이다.

여기서 중요한 의미는 이것이다.

• 아키텍처 레지스터: ISA(Instruction Set Architecture)가 “있다고 약속한” 레지스터(컴파일러/코드가 기준으로 삼는 집합)
• 물리 레지스터: CPU 구현이 실제로 가진 더 많은 레지스터(동시에 여러 명령을 진행하려면 저장 공간이 더 필요)

즉, 코드가 보는 레지스터 수보다 CPU 내부는 더 많은 저장 공간을 두고 “동시 진행”을 가능하게 한다.

(2) Queue(큐): “단계 사이 완충지대(줄)”

파이프라인 단계는 속도가 항상 같지 않다. 특히 메모리 쪽은 변동이 크다.
그래서 CPU는 단계 사이에 “줄(큐)”을 두고 완충한다.

• 디코드 대기열
• 실행 대기열
• 로드/스토어 대기 구조 등

큐가 길어진다는 건 그 지점이 병목이라는 신호가 될 수도 있다.

(3) ROB(Reorder Buffer): “OoO/추측 실행의 정리 담당”

OoO와 추측 실행을 하면 실행 순서는 뒤죽박죽이 될 수 있다.
그런데 프로그램은 겉보기로 “순서대로 실행된 것처럼” 일관된 결과가 나와야 안전하다.

ROB의 핵심 역할은 다음과 같다.

1. 완료(커밋/retire)를 프로그램 순서대로 정리
2. 분기 예측 실패 시, 잘못된 경로에서 만든 결과를 한 번에 폐기(롤백)
3. 예외/오류가 발생해도 “정확한 지점에서 멈춘 것처럼” 보이게 정리

---

6) 그런데 왜 아직도 느리나? (해결책이 있어도 병목이 남는 이유)

여기서 결론이 한 단계 더 정교해진다.

현대 CPU는 병목을 줄이기 위한 장치를 갖고 있지만,
그 장치들이 항상 장점만 있는 건 아니다. (Trade-Off)

 

각 장치에는 전제조건과 실패 비용이 있습니다.

• Cache: 접근 패턴이 나쁘면 캐시 미스가 빈번해지고, RAM 지연은 여전히 크다.
• OoO: 독립 작업(ILP)이 부족하면 숨길 스톨이 그대로 드러난다.
• Speculation: 분기 예측 실패가 잦으면 플러시 비용으로 IPC가 크게 떨어진다.
• Superscalar: 폭을 늘려도 의존성/특정 포트 병목 때문에 실제 활용이 제한된다.

그래서 “CPU가 발전했는데도 느리다”는 말은 모순이 아니다.
CPU는 손실을 줄이기 위해 최선을 다하지만, 입력 패턴(메모리/분기/의존성)이 나쁘면 버블은 다시 커진다.

---

7) 엔지니어는 무엇을 해야 하나?

CPU 내부 구현을 앱에서 직접 바꿀 수는 없다.
하지만 “CPU 병목을 피하도록 앱을 설계”하는 것은 엔지니어가 할 수 있고, Apple도 이를 명확히 권장한다.

Design your app to avoid CPU bottlenecks

(1) 시스템 프레임워크를 우선 사용하라

시스템 프레임워크는 디바이스 자원을 효율적으로 쓰도록 최적화돼 있는 경우가 많다.
같은 일을 직접 구현하기보다 프레임워크 경로를 타는 게 CPU 병목을 줄이는 빠른 길이 된다.

(2) 정적 스레드 풀보다 동적 할당을 선호하라

기기는 코어 구성과 현재 부하에 따라 작업 처리율이 달라진다.
고정 풀은 어떤 스레드는 놀고 어떤 스레드는 밀리는 식의 비효율을 만들 수 있다.

(3) QoS(Quality-of-Service)를 정확히 표시하라

백그라운드 작업의 중요도를 QoS로 알려주면 시스템이 효율적으로 스케줄링할 수 있다.

 

특히 Apple silicon처럼 성능 코어(P-core, Performance core)와 효율 코어(E-core, Efficiency core)가 함께 있는 환경에서는,

QoS가 작업이 어느 코어에서 실행될지에도 영향을 줄 수 있다.

그래서 QoS를 비워두거나 잘못 지정하면 체감 성능(응답성)과 전력 효율이 동시에 나빠질 수 있다.

Tuning your code’s performance for Apple silicon

(4) 가능하면 BGTasks로 시스템이 스케줄하게 하라

백그라운드에서 “언젠가 해도 되는 작업”은 시스템이 자원 여유에 맞춰 실행하도록 맡기는 전략이 유리할 수 있다.

(5) 목표를 세우고, 성능 테스트로 회귀를 막아라

Apple은 성능 목표 수립과 성능 테스트 작성을 권장하며, CPU 활동과 경과 시간을 측정할 메트릭도 제공한다.

 

WWDC25: Optimize CPU performance with Instruments

Analyzing CPU usage with the Processor Trace instrument

---

마무리

여기까지 CPU가 명령어를 어떻게 흘려보내는지, 그리고 그 흐름이 스톨/버블 때문에 어떻게 무너질 수 있는지를 살펴봤다.

 

캐시, Out-of-Order, 추측 실행, 슈퍼스칼라 같은 장치들도 결국은 한 가지 목적을 향한다.
CPU가 놀지 않게 하고, 막히는 시간을 최대한 줄이려는 것.

 

지금까지 “어떻게 하면 CPU를 더 잘 쓸까?”를 중심으로 정리했지만, 여기서 한 가지 주의할 점이 있다.

Apple이 말하듯 현대 CPU는 이미 명령어 흐름을 극대화하기 위해 많은 최적화를 내부에서 수행한다.
그럼에도 문제가 생길 수 있기 때문에, 우리는 CPU가 어떻게 돌아가고 어디에서 병목이 발생할 수 있는지 미리 알고 학습하는 것이다.

 

다만 실전에서 더 자주, 더 크게 발목을 잡는 건 CPU “내부”가 아니라 우리 코드가 만든 오버헤드인 경우가 많다.
비효율적인 알고리즘, 중복 연산, 불필요한 메모리 할당과 복사 같은 것들은 CPU가 아무리 똑똑해도 대신 해결해주지 못한다.
그래서 CPU 병목을 깊게 파고드는 건, 이런 낭비를 먼저 제거한 뒤에 해도 늦지 않다.

 

결국 가장 확실한 최적화는 이 한 줄로 정리된다.
“내 코드가 CPU에게 쓸데없는 일을 시키고 있지 않은지”부터 정리하자.

---

---

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

Chat GPT