왜 파이프라인이 필요한가

12편에서 명령 사이클(인출→해독→실행)을 다뤘다. 이 사이클을 한 명령어가 완전히 끝나야 다음 명령어를 시작하는 방식으로 처리하면, CPU 내부의 여러 하드웨어 부품(인출 회로, 해독 회로, 실행 회로 등)이 동시에 다 같이 놀고 있는 시간이 많이 생긴다. 예를 들어 한 명령어를 해독하는 동안 인출 회로는 아무 일도 하지 않는다.

파이프라인(pipeline)은 이 낭비를 줄이기 위해, 공장의 조립 라인처럼 명령어 처리 과정을 여러 단계로 잘라 각 단계를 서로 다른 하드웨어가 동시에 처리하게 만드는 기법이다. 한 명령어가 2단계(해독)에 있는 동안, 앞선 단계(인출)는 다음 명령어를 처리하고 있을 수 있다.

쉽게 말하면: 파이프라인은 세탁기·건조기·개기를 한 사람이 순서대로 다 하는 대신, 세 사람이 각자 한 단계씩 맡아서 빨래 더미를 계속 흘려보내는 것과 같다. 한 사람이 처음부터 끝까지 다 하는 것보다 여러 벌의 빨래를 훨씬 빨리 끝낼 수 있다.

파이프라인 단계와 총 사이클 수 계산

쉽게 말하면: 파이프라인이 다 채워지기까지는 시간이 걸리지만, 일단 채워지고 나면 사이클마다 명령어 하나씩 완성품이 쏟아져 나온다.

파이프라인의 단계 수(stage)를 $k$, 처리할 명령어 개수를 $n$이라 하자. 첫 번째 명령어가 모든 단계($k$단계)를 통과하는 데 $k$사이클이 걸린다. 그 이후로는 파이프라인이 꽉 차 있어서, 사이클마다 명령어가 하나씩 완성돼 나온다. 따라서 나머지 $n-1$개의 명령어는 각각 1사이클씩만 더 필요하다.

• $k$: 파이프라인 단계 수(예: 인출-해독-실행-기록의 4단계면 $k=4$)
• $n$: 처리할 명령어 개수
• $n-1$: 첫 번째 명령어를 제외한 나머지 명령어 수(각 1사이클씩 추가로 필요)

예제: 4단계 파이프라인($k=4$)으로 명령어 10개($n=10$)를 처리할 때

1단계: 공식에 값을 대입한다.

2단계: 괄호 안을 계산한다.

3단계: 더한다.

결과 해석: 파이프라인이 없었다면(한 명령어가 4단계를 다 거친 뒤에야 다음 명령어를 시작했다면) $4 \times 10 = 40$사이클이 필요했을 것이다. 파이프라인 덕분에 13사이클 만에 끝나므로, 같은 일을 훨씬 짧은 시간에 마친다.

파이프라인 실행표로 직접 확인하기

$k=4$(단계: IF 인출, ID 해독, EX 실행, WB 기록), $n=4$인 경우를 사이클별로 표로 그려 보면 다음과 같다.

마지막 명령어(명령어4)가 WB(기록) 단계를 마치는 시점이 7사이클이다. 공식으로 확인하면 $k + (n-1) = 4 + 3 = 7$사이클로 정확히 일치한다.

속도향상(speedup) 계산

쉽게 말하면: 속도향상은 “파이프라인이 없었다면 걸렸을 시간”을 “파이프라인을 쓴 실제 시간”으로 나눈 값으로, 파이프라인이 얼마나 이득인지를 숫자 하나로 보여준다.

파이프라인을 쓰지 않으면 명령어 $n$개를 처리하는 데 $n \times k$사이클이 필요하다(각 명령어가 $k$단계를 완전히 거친 뒤에야 다음 명령어를 시작하므로). 파이프라인을 쓰면 $k + (n-1)$사이클이 필요하다. 속도향상(speedup)은 이 둘의 비율이다.

예제: $k=4$, $n=10$일 때 속도향상

1단계: 분자(파이프라인 없이 걸리는 사이클)를 계산한다.

2단계: 분모(파이프라인으로 걸리는 사이클)를 계산한다. 앞서 구한 값 13을 그대로 쓴다.

3단계: 나눈다.

결과 해석: 파이프라인을 쓰면 약 3.08배 빠르다. 명령어 개수 $n$이 아주 커지면(이론상 무한대로 커지면) 속도향상은 $k$에 가까워진다 — 이것이 “$k$단계 파이프라인의 이론적 최대 속도향상은 $k$배”라는 결론의 근거다.

해저드: 파이프라인이 흐트러지는 세 가지 상황

쉽게 말하면: 해저드(hazard)는 조립 라인에서 앞 사람의 작업이 끝나지 않아 뒷사람이 멈춰야 하는 상황처럼, 파이프라인의 각 단계가 매끄럽게 흘러가지 못하고 멈추거나 잘못된 결과를 만들 위험이다.

이론상의 계산($k+n-1$)은 파이프라인이 한 치의 걸림 없이 흘러갈 때의 이상적인 값이다. 실제로는 세 가지 해저드(hazard)가 이 흐름을 방해한다.

1. 구조적 해저드(structural hazard)

구조적 해저드는 두 단계가 동시에 같은 하드웨어 자원을 쓰려고 할 때 발생한다. 예를 들어 명령어와 데이터를 하나의 기억장치(메모리)에서 함께 가져오는 구조라면, 한 명령어의 인출(IF) 단계와 다른 명령어의 실행(EX) 단계에서 데이터 접근이 동시에 메모리를 요구할 수 있다. 이 경우 하드웨어(메모리 포트)가 하나뿐이면 둘 중 하나는 기다려야 한다.

• 해결 방법: 명령어용 메모리와 데이터용 메모리를 분리하는 등 하드웨어 자원을 늘린다.

2. 데이터 해저드(data hazard)

데이터 해저드는 한 명령어가 아직 계산을 끝내지 않은 값을, 뒤따르는 명령어가 그 값을 필요로 할 때 발생한다. 예를 들어 다음과 같은 두 명령어를 생각해 보자(의사코드).

명령어1: R1 = R2 + R3
명령어2: R4 = R1 + R5

명령어1이 R1(레지스터1)에 값을 완전히 써넣기(WB 단계) 전에, 명령어2가 이미 해독(ID) 단계에서 R1 값을 읽어 가려 하면 아직 갱신되지 않은 옛날 값을 가져가는 문제가 생긴다.

• 해결 방법: 포워딩(forwarding, 데이터 전달)으로 계산 결과(EX 단계 출력)를 WB 단계까지 기다리지 않고 바로 다음 명령어의 EX 단계로 전달하거나, 파이프라인을 잠시 멈추는 스톨(stall, 지연)을 넣는다.

3. 제어 해저드(control hazard)

제어 해저드는 분기 명령어(branch, 조건에 따라 실행 순서가 바뀌는 명령어) 때문에 발생한다. 분기 명령어가 “조건을 만족하면 저 멀리로 뛰어라”라는 뜻이라면, 그 분기 여부가 실행(EX) 단계쯤에서야 확정되는데, 그 전까지 파이프라인은 이미 분기 다음에 오는 명령어들을 인출해서 처리를 시작해 버린 상태다. 만약 분기 결과가 “뛰어라”였다면 이미 처리하던 명령어들은 전부 버려야 한다.

• 해결 방법: 분기 예측(branch prediction, 분기 결과를 미리 추측해 그쪽 명령어를 먼저 처리)을 쓰거나, 분기 결과가 확정될 때까지 파이프라인을 지연시킨다.

해저드 비교표

자주 틀리는 점

• 속도향상 공식에서 분모를 $n \times k$로, 분자를 $k+(n-1)$로 뒤바꿔 계산하는 실수가 잦다. 속도향상은 “느린 것(파이프라인 없음) 나누기 빠른 것(파이프라인 있음)“이므로 분자가 항상 더 커야 한다.
• 데이터 해저드를 해결하는 포워딩과 스톨을 같은 것으로 혼동하기 쉽다. 포워딩은 “결과를 미리 넘겨줘서 기다림 자체를 없애는” 방법이고, 스톨은 “값이 준비될 때까지 파이프라인을 잠시 멈추는” 방법으로 서로 다른 접근이다.
• 제어 해저드가 “잘못된 계산 결과”를 낳는다고 착각하기 쉽지만, 분기 예측이 틀렸을 때는 잘못 인출된 명령어들을 파이프라인에서 지우고(flush) 다시 시작하므로 실행 시간은 늘어나도 최종 계산 결과 자체는 틀리지 않는다.

핵심 정리

• $k$단계 파이프라인으로 $n$개의 명령어를 처리하는 총 사이클 수는 $k + (n-1)$이다.
• 속도향상 $= \dfrac{n \times k}{k+(n-1)}$이며, $n$이 커질수록 이론적 최대값인 $k$에 가까워진다.
• 구조적 해저드는 하드웨어 자원 충돌, 데이터 해저드는 값의 의존 관계, 제어 해저드는 분기의 불확실성 때문에 발생한다.
• 데이터 해저드는 포워딩이나 스톨로, 제어 해저드는 분기 예측이나 지연으로 완화한다.
• 이 편의 파이프라인·해저드 논의는 시험 출제 범위 내 기초 수준까지만 다루며, 슈퍼스칼라·비순차 실행 같은 고급 주제는 이 과목의 범위 밖이다.

마무리 복습

참고 자료

• 공개된 컴퓨터구조/컴퓨터조직 교과서형 강의노트 
• 국가평생교육진흥원 독학학위제 - 출제방향/수준