컴퓨터시스템 기초 9. CPU는 명령을 어떤 단계로 실행할까

[컴퓨터 시스템] 9. CPU는 명령을 어떤 단계로 실행할까

8편에서 CPU를 회로들의 계층 구조로 봤다면, 이번에는 그 CPU가 실제로 명령을 어떻게 처리하는지 봐야 합니다. 프로그램 실행을 이해하려면 결국 CPU가 한 줄의 일을 어떤 단계로 쪼개 처리하는지 알아야 합니다.

이번 글은 fetch-decode-execute 흐름을 중심으로 레지스터, 프로그램 카운터, 파이프라인의 필요성을 묶어 설명합니다. 뒤에서 어셈블리를 볼 때도 이 실행 흐름이 기준이 됩니다.

먼저 짚고 갈 용어

program counter: 다음에 읽을 명령의 위치를 가리키는 값

register: CPU 안에서 매우 빠르게 쓰는 작은 저장 공간

pipeline: 명령 처리 단계를 겹쳐 실행량을 높이는 구조

이번 글에서 다루는 것

• CPU 명령 처리의 기본 흐름 fetch-decode-execute
• 프로그램 카운터와 레지스터가 왜 필요한지
• 명령 하나를 단계로 쪼개 보는 이유
• 파이프라인이 생기는 이유와 기본적인 위험
• 간단한 명령열을 단계별로 추적하는 방법

한눈에 보는 흐름

1

CPU 명령 처리의 기본 흐름 fetch-decode-execute

2

프로그램 카운터와 레지스터가 왜 필요한지

3

명령 하나를 단계로 쪼개 보는 이유

4

파이프라인이 생기는 이유와 기본적인 위험

1. 명령 실행은 읽기-해석-실행의 반복이다

CPU는 프로그램 전체를 한 번에 이해하지 않습니다. 메모리에서 다음 명령을 가져오고(fetch), 그것이 무슨 뜻인지 해석하고(decode), 실제 연산이나 데이터 이동을 수행(execute)하는 반복 구조로 움직입니다.

이 기본 흐름을 잡아두면 뒤에서 어셈블리 한 줄을 볼 때도, 그것이 단순 문자열이 아니라 CPU에게 내리는 매우 구체적인 작업 지시라는 점이 잘 보입니다.

과정 그림

1

program counter가 가리키는 위치에서 다음 명령을 읽는다.

2

읽은 비트 패턴을 어떤 명령인지 해석한다.

3

필요한 연산이나 메모리 접근을 수행한다.

4

다음 명령 위치를 계산하고 다시 반복한다.

2. 레지스터는 CPU 안의 빠른 작업대다

CPU가 모든 중간 값을 RAM에만 두고 계산하면 너무 느립니다. 그래서 CPU 안에는 아주 작지만 매우 빠른 저장 공간인 레지스터가 있습니다.

그림으로 먼저 보기

레지스터

어떤 감각으로 보면 좋은가: CPU 안의 즉석 작업대

왜 중요한가: 가장 자주 쓰는 값을 빠르게 다룬다

RAM

어떤 감각으로 보면 좋은가: 더 큰 작업 창고

왜 중요한가: 많은 데이터를 담지만 접근은 더 느리다

레지스터를 작업대라고 생각하면 좋습니다. 당장 계산할 값과 결과를 잠시 올려두고 빠르게 처리하는 공간입니다.

자원	어떤 감각으로 보면 좋은가	왜 중요한가
레지스터	CPU 안의 즉석 작업대	가장 자주 쓰는 값을 빠르게 다룬다
RAM	더 큰 작업 창고	많은 데이터를 담지만 접근은 더 느리다

3. 프로그램 카운터는 흐름을 잃지 않게 해주는 기준점이다

CPU가 다음에 무엇을 해야 하는지 잊지 않으려면, 현재 어느 명령까지 왔는지를 계속 기억해야 합니다. 그 역할을 하는 것이 program counter입니다.

순차 실행에서는 보통 다음 명령으로 한 칸 이동하지만, 분기나 함수 호출이 생기면 이 값이 크게 바뀝니다. 그래서 program counter는 실행 흐름 자체를 보여 주는 핵심 단서입니다.

나중에 왜 중요해질까

디버깅이나 어셈블리 읽기에서 '지금 어디를 실행 중인가'를 확인할 때 결국 이 흐름 감각이 필요합니다.

4. 파이프라인은 명령 단계를 겹쳐 성능을 높인다

명령 하나를 다 끝낸 뒤 다음 명령을 시작하면 CPU 자원이 놀게 되는 순간이 많습니다. 그래서 여러 명령이 서로 다른 단계에 동시에 올라오도록 겹치는 구조가 파이프라인입니다.

그림으로 먼저 보기

동시에 여러 명령을 서로 다른 단계에 올려 처리량을 높인다

대가: 의존성, 분기, 자원 충돌 때문에 흐름이 꼬일 수 있다

예를 들어 첫 명령이 execute 단계에 있을 때, 두 번째 명령은 decode, 세 번째는 fetch에 들어갈 수 있습니다. 이렇게 하면 처리량이 좋아집니다.

이점	대가
동시에 여러 명령을 서로 다른 단계에 올려 처리량을 높인다	의존성, 분기, 자원 충돌 때문에 흐름이 꼬일 수 있다

5. 조금만 복잡해져도 위험이 생긴다

파이프라인이 좋아 보이기만 하는 것은 아닙니다. 앞 명령 결과가 아직 안 나왔는데 뒤 명령이 그 값을 필요로 하거나, 분기 결과를 모르는 상태에서 다음 명령을 미리 가져오면 충돌이 생깁니다.

그림으로 먼저 보기

data hazard

쉬운 설명: 앞 결과가 필요한데 아직 안 나왔다

control hazard

쉬운 설명: 분기 방향을 아직 모른다

structural hazard

쉬운 설명: 같은 자원을 동시에 쓰려 한다

그래서 성능 이야기는 늘 '겹쳐서 빨라진다'와 '겹치다 보니 새 문제가 생긴다'를 함께 봐야 합니다.

위험 종류	쉬운 설명
data hazard	앞 결과가 필요한데 아직 안 나왔다
control hazard	분기 방향을 아직 모른다
structural hazard	같은 자원을 동시에 쓰려 한다

6. 직접 해볼 문제: 명령 세 줄을 단계별로 상상해 보자

아래 문제는 어셈블리를 깊게 몰라도 됩니다. 앞 명령의 결과를 뒤 명령이 바로 쓰려고 할 때 왜 파이프라인이 신경을 써야 하는지 감각만 잡으면 충분합니다.

TEXT

1) R1 = R2 + R3
2) R4 = R1 + 1
3) R5 = R4 + 1

미니 문제

2번 명령은 1번 결과를 바로 필요로 하고, 3번은 2번 결과를 바로 필요로 합니다. 이런 명령열에서 왜 data hazard를 생각해야 하는지 스스로 설명해 보세요.

이번 글에서 기억할 것

CPU는 fetch-decode-execute 같은 반복 단계로 명령을 처리한다.

레지스터와 program counter는 실행 흐름을 빠르고 안정적으로 유지하는 핵심 자원이다.

파이프라인은 처리량을 높이지만 의존성과 분기 때문에 새로운 위험도 함께 만든다.

스스로 점검

fetch, decode, execute를 각각 어떤 질문으로 이해하면 되는지 설명할 수 있는가

레지스터와 RAM의 역할 차이를 작업대 비유 없이도 말할 수 있는가

왜 파이프라인이 생기고, 왜 동시에 hazard가 문제인지 설명할 수 있는가

다음 글 예고

다음 글에서는 이 실행 흐름을 바탕으로, 어셈블리를 왜 C와 하드웨어 사이의 번역본처럼 읽을 수 있는지 정리합니다.

한 줄 정리

CPU 명령 실행의 핵심은 한 줄의 일을 가져오기, 해석하기, 실행하기로 나누고, 그 단계를 겹치며 성능과 복잡성을 함께 키운다는 데 있습니다.