229. 파이프라인 스톨 (Pipeline Stall / Bubble)

핵심 인사이트 (3줄 요약)

본질: 파이프라인 스톨 (Pipeline Stall)은 다음 단계가 아직 받아들일 준비를 못 했을 때 명령어 진행을 잠시 멈추고, 필요하면 버블 (Bubble)이라는 빈 사이클을 삽입해 순서를 보존하는 제어 동작이다.

가치: 스톨은 처리량을 희생하지만 데이터 의존성과 자원 충돌을 무시해 생길 오연산을 막아, 파이프라인이 "빠르면서도 틀리지 않게" 유지되도록 만든다.

판단 포인트: 좋은 설계는 스톨을 없애는 것이 아니라, 어떤 스톨은 전방 전달 (Forwarding)·분기 예측·비순차 실행으로 숨기고 어떤 스톨은 감수해야 하는지 구분하는 데서 시작된다.

Ⅰ. 개요 및 필요성

파이프라인 스톨은 여러 단계로 나뉘어 동시에 흐르던 명령어 중 일부를 의도적으로 지연시키는 제어 메커니즘이다. 파이프라인은 명령어를 겹쳐 실행해 처리량을 높이지만, 실제 하드웨어는 모든 명령어가 항상 같은 속도로 준비되지 않는다. 어떤 명령어는 메모리 값을 기다리고, 어떤 명령어는 같은 연산기를 동시에 쓰려 하며, 어떤 명령어는 분기 결과가 확정되기 전까지 다음 위치를 정할 수 없다.

이때 스톨이 없으면 CPU (Central Processing Unit)는 아직 준비되지 않은 값을 읽거나, 잘못된 명령어를 계속 밀어 넣게 된다. 즉 스톨은 성능 저하를 만드는 장애가 아니라, 잘못된 실행을 막기 위해 시간을 사는 안전장치다. 파이프라인의 핵심은 "항상 이동"이 아니라 "의존성이 해소된 경우에만 이동"이라는 점에서, 스톨은 고성능 구조의 예외 처리가 아니라 본질적 구성요소다.

아래 그림은 왜 스톨이 필요한지를 시간축 관점에서 보여준다. 앞 명령어의 결과가 아직 도착하지 않았는데 뒤 명령어가 그 값을 읽으려 하면, 한 박자 멈춰 순서를 다시 맞춰야 한다.

┌──────────────────────────────────────────────────────────────────────────────┐
│                결과 준비 전 사용 시도 → 스톨로 시간축 보정                 │
├────────┬────────┬────────┬────────┬────────┬────────────────────────────────┤
│ Cycle  │   1    │   2    │   3    │   4    │ 의미                           │
├────────┼────────┼────────┼────────┼────────┼────────────────────────────────┤
│ I1     │ IF     │ ID     │ EX     │ MEM    │ load 결과는 MEM 끝에서 준비    │
│ I2     │        │ IF     │ ID     │ stall  │ I1 결과가 아직 없어 대기       │
│ I2     │        │        │        │ EX     │ 한 사이클 뒤에야 안전하게 실행 │
└────────┴────────┴────────┴────────┴────────┴────────────────────────────────┘

핵심은 스톨이 "느려지는 현상"이 아니라 "순서를 보존하기 위한 제어 행동"이라는 점이다. 성능은 손해 보지만, 프로그램 의미를 지키지 못하면 더 이상 프로세서라 부를 수 없기 때문이다.

📢 섹션 요약 비유: 파이프라인 스톨은 단체 줄넘기에서 앞사람 발이 꼬였을 때 한 박자 쉬고 다시 맞추는 동작과 같다. 박자를 잠깐 잃더라도 무리하게 돌리면 모두가 엉키기 때문에, 잠시 멈추는 것이 오히려 전체 흐름을 살린다.

Ⅱ. 아키텍처 및 핵심 원리

전형적인 5단계 파이프라인은 IF (Instruction Fetch), ID (Instruction Decode), EX (Execute), MEM (Memory Access), WB (Write Back)로 구성된다. 스톨은 이 단계 중 특정 지점에서 "진행 금지"와 "빈 명령어 삽입"을 조합해 구현된다. 보통 프로그램 카운터 (Program Counter)와 앞단 파이프라인 레지스터는 그대로 유지하고, 뒤단으로는 NOP (No Operation)에 해당하는 제어 신호를 보내 버블을 만든다.

대표 예시는 로드-유즈 (Load-Use) 해저드다. 메모리에서 읽어 온 값은 대개 MEM 단계 끝에서 준비되는데, 바로 다음 명령어가 EX 단계 초반에 그 값을 필요로 하면 타이밍이 맞지 않는다. 전방 전달이 있어도 물리적으로 아직 값이 없으므로 최소 1사이클 스톨이 필요하다. 이때 CPI (Cycles Per Instruction)는 1에 가까운 이상 상태에서 벗어나 증가하며, 누적되면 체감 성능이 크게 떨어진다.

제어 대상	스톨 시 동작	목적
프로그램 카운터 (Program Counter)	갱신 정지	같은 명령어를 다시 유지
IF/ID 파이프라인 레지스터	쓰기 금지	해독 중 명령어 고정
ID/EX 파이프라인 레지스터	제어 신호 0 주입	EX 단계에 버블 삽입
해저드 검출기 (Hazard Detector)	의존성 판단	스톨 필요 여부 결정

아래 그림은 로드-유즈 해저드에서 스톨과 버블이 어떻게 동시에 나타나는지 보여준다. 앞단은 멈추고, 중간 단계에는 빈 슬롯이 흘러가며, 뒤 명령어는 한 사이클 늦춰진다.

┌──────────────────────────────────────────────────────────────────────────────┐
│               Load-Use Hazard에서 Stall과 Bubble이 생기는 위치             │
├───────────────┬───────────────┬───────────────┬──────────────────────────────┤
│ Cycle 1       │ Cycle 2       │ Cycle 3       │ Cycle 4                      │
├───────────────┼───────────────┼───────────────┼──────────────────────────────┤
│ I1: load      │ ID            │ EX            │ MEM                          │
│ I2: add       │ IF            │ ID            │ stall                        │
│ I3: next      │               │ IF            │ IF 유지                      │
├───────────────┴───────────────┴───────────────┴──────────────────────────────┤
│ 제어 결과: PC 정지 + IF/ID 정지 + ID/EX에 NOP 삽입                         │
│ 결과 의미: EX 자리에 빈 버블이 지나가며 I2는 한 사이클 뒤로 밀림           │
└──────────────────────────────────────────────────────────────────────────────┘

스톨은 단순히 "멈춘다"로 끝나지 않는다. 어느 레지스터를 얼리고 어느 단계에 버블을 넣을지 정확히 설계해야 파이프라인 상태가 깨지지 않는다. 그래서 스톨 제어는 데이터 경로만큼이나 제어 경로 품질에 의존하며, 잘못 구현하면 오히려 더 치명적인 오연산과 데드록에 가까운 정지 현상을 만든다.

📢 섹션 요약 비유: 공장 컨베이어벨트에서 앞 공정의 부품이 아직 안 왔는데 다음 공정이 억지로 조립을 시작할 수는 없다. 벨트를 잠깐 멈추고 빈 트레이 하나를 흘려보내는 것이 스톨과 버블의 역할이다.

Ⅲ. 비교 및 연결

스톨을 제대로 이해하려면 해저드 종류와 대응 기법을 함께 봐야 한다. 데이터 해저드 중 RAW (Read After Write)는 가장 대표적인 스톨 원인이고, 구조적 해저드 (Structural Hazard)는 동일 자원을 동시에 쓰려 할 때 발생한다. 제어 해저드 (Control Hazard)는 분기 결과가 확정되기 전의 불확실성에서 생기며, 이 경우는 스톨뿐 아니라 플러시 (Flush)와도 연결된다.

구분	스톨 중심 대응	다른 대표 대응	차이가 중요한 이유
데이터 해저드	한두 사이클 대기	전방 전달, 레지스터 리네이밍	값이 언제 준비되는지가 핵심
구조적 해저드	자원 사용 순서 조정	자원 복제, 포트 확장	하드웨어 비용과 면적이 연관
제어 해저드	분기 확정까지 대기	분기 예측, 투기 실행	잘못 추측하면 플러시 비용 발생

스톨과 플러시는 비슷해 보이지만 본질이 다르다. 스톨은 "아직 확정되지 않았으니 기다린다"에 가깝고, 플러시는 "이미 잘못 들어온 명령어를 버린다"에 가깝다. 또한 전방 전달은 스톨을 완전히 대체하는 기술이 아니라, 값이 조기에 이용 가능한 경우에만 스톨 길이를 줄이는 보조 수단이다.

현대 프로세서는 비순차 실행 (Out-of-Order Execution)과 명령어 윈도우를 통해 스톨의 체감 비용을 더 줄인다. 특정 명령어가 대기 중이어도 뒤에 있는 독립 명령어를 먼저 실행해 연산기 점유율을 유지하는 것이다. 즉 스톨은 사라진 것이 아니라, 보이는 위치가 앞단 제어에서 동적 스케줄링 영역으로 이동했다고 보는 편이 정확하다.

📢 섹션 요약 비유: 스톨은 신호등 앞에서 잠깐 멈추는 것이고, 플러시는 잘못 든 길에서 차를 빼 다시 돌아나오는 것이다. 전방 전달과 비순차 실행은 막힌 차선을 그냥 기다리지 않고 옆 차선이나 우회로를 활용해 전체 흐름을 살리는 전략에 가깝다.

Ⅳ. 실무 적용 및 기술사 판단

실무에서 중요한 질문은 "스톨이 생기느냐"가 아니라 "어떤 스톨이 구조적으로 불가피하며, 어떤 스톨은 설계 미숙 때문이냐"다. 예를 들어 단일 메모리 포트를 가진 단순 파이프라인에서 명령어 인출과 데이터 접근이 충돌하면 구조적 해저드가 빈번해진다. 이런 경우는 소프트웨어 튜닝보다 하버드 구조 (Harvard Architecture) 분리나 캐시 포트 확장이 더 효과적이다.

반대로 로드 직후 바로 사용하는 패턴이 많다면 컴파일러의 명령어 스케줄링이나 개발자의 코드 재배치가 의미 있다. 메모리 접근 뒤에 독립 연산을 끼워 넣으면 로드-유즈 스톨을 숨길 수 있기 때문이다. 더 고성능 영역에서는 OoO 코어, 분기 예측기, 비차단 캐시 (Non-Blocking Cache)까지 포함해 "스톨을 줄이는 하드웨어 투자"가 성능/Watt를 좌우한다.

설계 판단 체크리스트

스톨 원인이 데이터 준비 지연인지, 자원 충돌인지, 분기 불확실성인지 먼저 분해했는가?
전방 전달만으로 해결 가능한지, 로드-유즈처럼 물리적으로 한 사이클 대기가 필요한지 구분했는가?
스톨 빈도가 높은 구간이 메모리 계층 문제라면 캐시 정책과 대역폭부터 재검토했는가?
단순한 CPI 평균이 아니라 "어떤 해저드가 몇 사이클을 소모하는지"까지 프로파일링했는가?

안티패턴

전방 전달이 있으니 모든 데이터 해저드가 없어졌다고 오해하는 설계
자원 충돌을 소프트웨어 탓으로만 돌리고 하드웨어 병목을 방치하는 판단
분기 스톨, 데이터 스톨, 캐시 미스 지연을 한 항목으로 섞어 원인을 흐리는 성능 분석

기술사 답안 관점에서는 "스톨은 나쁜 것"이라고만 쓰면 부족하다. 스톨은 정확성 확보를 위한 필수 비용이며, 설계자는 그 비용을 구조 분리, 예측, 스케줄링, 동적 실행으로 얼마나 숨길 수 있는지를 설명해야 한다. 결국 좋은 프로세서는 스톨이 없는 프로세서가 아니라, 스톨이 발생해도 전체 처리량이 급락하지 않게 만드는 프로세서다.

📢 섹션 요약 비유: 주방에서 한 요리가 늦어진다고 모든 손님 주문을 멈추는 식당은 비효율적이다. 잘된 주방은 늦는 메뉴는 잠깐 기다리게 두고, 먼저 만들 수 있는 다른 메뉴를 계속 내보내며 전체 회전율을 지킨다.

Ⅴ. 기대효과 및 결론

파이프라인 스톨 개념을 정확히 이해하면 CPU 성능을 단순 클럭 속도가 아니라 "유효하게 일한 사이클 비율"로 보게 된다. 같은 3 GHz 프로세서라도 스톨이 적은 구조는 더 많은 명령어를 실제로 완료하고, 스톨이 많은 구조는 높은 주파수를 가져도 체감 성능이 떨어진다. 따라서 스톨 분석은 마이크로아키텍처 최적화, 컴파일러 스케줄링, 메모리 계층 설계가 만나는 접점이다.

또한 스톨은 파이프라인 설계의 한계를 드러내는 진단 지표이기도 하다. 데이터 준비 시점이 늦는다면 전방 전달 경로와 연산 단계 배치를 봐야 하고, 구조적 충돌이 많다면 자원 복제와 포트 구성을 봐야 하며, 분기 관련 손실이 크다면 예측 정확도를 점검해야 한다. 즉 스톨은 결과가 아니라 원인을 추적하는 성능 해석의 창이다.

결론적으로 파이프라인 스톨은 "빈 사이클"이 아니라 "정확성을 지키기 위해 시간을 재배치하는 기술"로 기억하는 것이 맞다. 현대 CPU의 경쟁력은 스톨을 완전히 제거하는 데 있지 않고, 불가피한 스톨의 길이와 노출도를 최소화하는 데 있다.

📢 섹션 요약 비유: 도로에서 잠깐 서행하는 구간 자체보다 중요한 것은 왜 거기서 차가 막히는지 아는 일이다. 병목 지점을 알면 차선을 넓히거나 신호를 바꿀 수 있듯, 스톨을 이해해야 프로세서도 진짜로 빨라진다.

📌 관련 개념 맵

개념	연결 포인트
해저드 (Hazard)	스톨이 발생하는 직접 원인으로, 데이터·구조·제어 문제를 분류하는 기준
전방 전달 (Forwarding)	결과를 조기 전달해 일부 데이터 스톨을 줄이는 대표 기법
플러시 (Flush)	잘못 인출된 명령어를 폐기하는 동작으로, 스톨과 함께 제어 해저드 분석에 등장
비순차 실행 (Out-of-Order Execution)	앞 명령어가 멈춰도 뒤 독립 명령어를 실행해 스톨 노출을 줄이는 기법

📈 관련 키워드 및 발전 흐름도

명령어 겹쳐 실행
    │
    ▼
파이프라인 해저드 (Pipeline Hazard) 인식
    │
    ├─ 데이터 해저드 (RAW) ──▶ 스톨 (Pipeline Stall)
    │                           │
    │                           └─ 전방 전달 (Forwarding)
    │
    ├─ 구조적 해저드 ─────────▶ 자원 분리 · 포트 확장
    │
    └─ 제어 해저드 ───────────▶ 분기 예측 · 플러시 (Flush)
                                │
                                ▼
비순차 실행 (Out-of-Order Execution) · 투기 실행

이 흐름은 단순 대기에서 끝나지 않고, 스톨 원인을 해저드별로 분해한 뒤 이를 줄이는 현대 마이크로아키텍처 기법으로 확장되는 과정을 보여준다.

👶 어린이를 위한 3줄 비유 설명

여러 친구가 줄지어 장난감을 만들 때 앞친구 부품이 아직 안 오면 뒷친구는 잠깐 기다려야 해요.
그 기다리는 시간이 바로 파이프라인 스톨이고, 그 사이에 빈 칸처럼 지나가는 시간이 버블이에요.
똑똑한 컴퓨터는 기다리는 동안 다른 할 일을 먼저 하거나, 부품을 더 빨리 건네줘서 멈춤 시간을 줄인답니다.