Process 전환과 Thread 전환

← 06. 실전 추적 - A B C가 번갈아 실행되는 20ms · 학습 지도 · 다음 → 08. 비용과 성능 - 왜 너무 자주 바꾸면 느릴까

핵심

Thread는 실제 명령을 따라가는 실행 흐름이다. 같은 Process의 Thread들은 주소 공간과 많은 자원을 공유하지만, 각자 PC, Register, Stack을 가진다. 그래서 Thread끼리도 Context Switching이 필요하며, 같은 Process 안의 Thread 전환은 보통 주소 공간을 바꾸지 않아 Process 간 전환보다 가벼울 수 있다.

1. Process는 자원 그릇, Thread는 실행 흐름

하나의 음악 앱 Process가 있다고 하자.

Thread 1: 화면 버튼과 사용자 입력 처리
Thread 2: 음원 데이터 내려받기
Thread 3: 음원 Decoding

세 Thread는 같은 앱의 코드와 Heap을 공유할 수 있지만, 서로 다른 일을 서로 다른 위치에서 실행한다.

Music Process
├─ 공유: Code, Data, Heap, 열린 File 등
├─ Thread 1: PC, Registers, Stack
├─ Thread 2: PC, Registers, Stack
└─ Thread 3: PC, Registers, Stack

왜 Stack은 따로 있어야 할까?

Thread 1은 buttonClicked 함수를 실행 중이고, Thread 2는 downloadChunk 함수를 실행 중일 수 있다. 함수 호출 순서와 지역 변수가 서로 다르므로 각자 Stack이 필요하다.

2. Thread마다 따로 있어야 하는 것

Thread별로 따로 필요	이유
Program Counter	각 Thread가 서로 다른 명령 위치를 실행
General Registers	각자의 계산 중간값
Stack Pointer와 Stack	각자의 함수 호출, 지역 변수, 복귀 위치
Scheduling 상태	한 Thread는 Running, 다른 Thread는 Waiting일 수 있음
식별과 Signal 관련 일부 상태	각 실행 흐름을 구분하고 제어

이러한 Thread별 관리 기록을 설명할 때 TCB, Thread Control Block이라는 개념을 쓰기도 한다. 실제 운영체제에서는 Process와 Thread의 관리 구조가 교과서처럼 완전히 따로 떨어져 있지 않을 수 있다.

3. 같은 Process의 Thread들이 공유하는 것

보통 다음을 공유한다.

Code 영역
전역 Data
Heap
가상 주소 공간
열린 File과 Process 수준 자원

공유는 빠른 통신이라는 장점이 있다. Thread 1이 Heap의 객체를 바꾸면 Thread 2도 같은 객체를 볼 수 있다.

하지만 동시에 접근하면 값이 꼬일 수 있으므로 Lock 같은 동기화가 필요할 수 있다. 이것은 Context Switching의 직접 정의는 아니지만, Thread를 여러 개 사용할 때 따라오는 중요한 문제다.

4. 세 가지 전환 비교

A Process의 Thread 1 → A Process의 Thread 2

바뀌는 대표 정보:

PC, SP, Registers
실행 중인 Thread의 Kernel 관리 상태
Thread별 Stack

대개 유지되는 대표 정보:

같은 가상 주소 공간
같은 Code, Heap
Process 수준의 열린 File

A Process의 Thread 1 → B Process의 Thread 1

바뀌는 대표 정보:

PC, SP, Registers
Thread와 Process 관리 상태
Kernel Stack
주소 공간과 Page Table 관련 Context
Memory 보호 기준

A Process의 Thread 1 → 같은 Thread 1로 복귀

System Call이나 Interrupt 처리 뒤 같은 Thread로 돌아간다면 Mode는 바뀌었어도 다른 실행 주체로의 Context Switch는 없을 수 있다.

5. 표로 한눈에 비교

항목	같은 Process 내 Thread 전환	서로 다른 Process 간 전환
PC와 Register 교체	필요	필요
Stack 교체	필요	필요
Scheduling 대상 교체	필요	필요
가상 주소 공간 교체	보통 불필요	보통 필요
Page Table 관련 전환	보통 불필요	보통 필요
TLB 영향	생길 수 있으나 보통 상대적으로 작음	더 클 수 있음
Heap과 Code	공유	분리
보호와 격리	같은 Process 내부라 약함	Process 경계로 더 강함
일반적인 비용	상대적으로 가벼울 수 있음	상대적으로 무거울 수 있음

“항상”이라고 단정하지 않기

실제 비용은 CPU, 운영체제, Core 이동, Cache 상태, 보안 기능에 따라 달라진다. 같은 Process의 Thread 전환도 Cache가 크게 흐트러지거나 다른 Core로 이동하면 비쌀 수 있다.

6. 같은 Process의 Thread Switch도 왜 저장이 필요한가?

Thread 1과 Thread 2가 주소 공간을 공유하니 Register도 공유한다고 착각하기 쉽다. 하지만 한 CPU Core의 물리 Register는 지금 실행 중인 하나의 실행 흐름 값만 담는다.

예를 들어:

Thread 1
PC = 화면 처리 코드 120번
R1 = 클릭 좌표 300
SP = Thread 1 Stack

Thread 2
PC = 다운로드 코드 880번
R1 = 받은 Byte 수 4096
SP = Thread 2 Stack

Thread 1에서 Thread 2로 바꾸면 CPU의 PC, R1, SP를 Thread 2의 값으로 바꿔야 한다. 따라서 CPU Context Switching은 여전히 필요하다.

7. Kernel Thread와 User-level Thread

Kernel이 Scheduling하는 Thread

운영체제가 각 Thread를 실행 대상으로 알고 Scheduling한다.

한 Thread가 Blocking되어도 같은 Process의 다른 Thread를 실행할 수 있다.
Kernel 진입과 Scheduling 비용이 따른다.

User-level Thread 또는 Fiber

사용자 공간의 Runtime이나 Library가 여러 실행 흐름을 관리할 수 있다.

같은 Kernel Thread 위에서 전환한다면 Kernel Scheduler를 거치지 않고 Register와 Stack 등을 바꿀 수 있어 더 가벼울 수 있다.
Runtime이 어떤 작업이 Block되는지 잘 관리해야 한다.
언어 Runtime과 구현에 따라 동작이 크게 달라진다.

처음 공부할 때 “Context Switch”라고 하면 Kernel이 관리하는 Process 또는 Thread 사이 전환을 주로 떠올리고, 나중에 User-level Scheduling을 별도 층으로 추가하면 된다.

8. PCB와 TCB는 실제로 어떻게 연결될까?

교과서 모델:

PCB: Process 전체 자원과 상태
 ├─ TCB 1: Thread 1 실행 상태
 ├─ TCB 2: Thread 2 실행 상태
 └─ TCB 3: Thread 3 실행 상태

이 모델은 이해하기 좋다. 다만 Linux처럼 Process와 Thread를 공통 Task 개념으로 다루고, 공유하는 자원 구조를 서로 가리키게 만드는 운영체제도 있다.

따라서 시험에서는 교재 용어를 따르되, 실제 구현에서는 다음 원칙을 기억한다.

Scheduling되는 실행 흐름마다 독립적으로 보존해야 할 CPU Context가 있고, 같은 Process의 실행 흐름들은 주소 공간과 여러 자원을 공유할 수 있다.

9. 어떤 선택이 더 좋을까?

Thread가 항상 좋고 Process가 항상 나쁜 것은 아니다.

Thread의 장점

공유 Memory로 빠르게 협력 가능
같은 Process 안에서 전환 비용이 비교적 작을 수 있음
자원 공유가 쉬움

Thread의 위험

한 Thread의 잘못된 Memory 접근이 Process 전체를 망가뜨릴 수 있음
공유 Data 경쟁과 Deadlock 가능
복잡한 동기화 필요

Process의 장점

주소 공간 분리로 격리와 보호가 강함
한 Process 장애가 다른 Process에 직접 퍼지는 것을 줄일 수 있음

Process의 비용

Memory와 자원 분리가 더 큼
통신에 IPC 같은 별도 방법이 필요
전환과 생성이 더 무거울 수 있음

스스로 설명하기

같은 Process의 Thread들이 Heap을 공유해도 Stack은 따로 가져야 하는 이유는?
같은 Process의 Thread Switch에서도 PC와 Register를 바꿔야 하는 이유는?
Process 간 Switch가 더 무거울 수 있는 가장 큰 추가 요소는?

정답 확인

각 Thread의 함수 호출 순서, 지역 변수, 복귀 위치가 다르기 때문이다.
CPU Core의 Register는 현재 실행 흐름 하나의 값만 담고, 각 Thread의 실행 위치와 중간값이 다르기 때문이다.
서로 다른 가상 주소 공간과 Page Table 관련 Memory Context까지 전환해야 하고 Cache와 TLB 영향도 더 클 수 있기 때문이다.

다음 문서: 08. 비용과 성능 - 왜 너무 자주 바꾸면 느릴까