PCB - 프로세스의 보관함
PCB - 프로세스의 보관함
← 02. 프로세스와 CPU 상태 - 멈춘 실행을 되살리는 정보 · 학습 지도 · 다음 → 04. Context Switching - 실제 전환 12단계
PCB, Process Control Block은 운영체제가 각 프로세스를 생성부터 종료까지 관리하기 위해 유지하는 프로세스별 기록이다. 실행을 재개할 CPU 상태뿐 아니라 식별자, 현재 상태, 스케줄링, 메모리, 파일과 I/O, 권한 같은 정보도 담거나 관련 구조를 가리킨다.
1. 왜 PCB가 필요한가
한 반에 학생이 한 명뿐이라면 선생님이 학생 정보를 굳이 카드로 정리하지 않아도 된다. 하지만 학생이 30명이라면 다음을 기억해야 한다.
- 누구인지
- 지금 상담 중인지, 줄에서 기다리는지, 준비물을 가지러 갔는지
- 어디까지 이야기했는지
- 우선 상담이 필요한지
- 어떤 책과 준비물을 빌렸는지
운영체제도 수십, 수백 개의 Process를 관리한다. 각 Process의 정보를 한데 묶어 구분할 관리 단위가 필요하다. 그 대표적인 개념이 PCB다.
운영체제의 관리 대상
PCB A ── Process A에 관한 기록
PCB B ── Process B에 관한 기록
PCB C ── Process C에 관한 기록
Process가 생성되면 운영체제는 그 Process를 위한 관리 정보를 만들고, Process가 종료되면 자원을 정리한 뒤 그 기록도 회수한다.
2. PCB에 들어가는 대표 정보
교과서에서 PCB 항목을 외울 때는 목록만 외우지 말고, “운영체제가 왜 알아야 하는가?”를 함께 연결하자.
| 범주 | 대표 정보 | 필요한 이유 |
|---|---|---|
| 식별 정보 | PID, 부모 Process, 사용자 | 여러 Process를 구분하고 관계·권한을 판단 |
| Process 상태 | New, Ready, Running, Waiting, Terminated | 지금 CPU 후보인지, 사건을 기다리는지 판단 |
| CPU 실행 상태 | PC, SP, Register, Flags와 관련된 저장 정보 | 멈춘 위치에서 정확히 재개 |
| Scheduling 정보 | 우선순위, Queue 연결, 사용한 CPU 시간 | 다음 CPU 차례를 결정 |
| Memory 관리 정보 | 주소 공간, Page Table 관련 정보, 메모리 영역 | 올바른 가상 주소 공간과 보호 규칙 적용 |
| I/O와 File 정보 | 열린 파일, 장치 요청, File Descriptor 관련 정보 | Process가 사용하던 자원과 대기를 관리 |
| Accounting 정보 | 실행 시간, 시작 시각, 자원 사용량 | 제한, 통계, 과금, 진단 |
| 보안과 제어 정보 | 사용자·그룹, 권한, Signal 관련 상태 | 접근 통제와 Process 제어 |
교과서의 PCB는 개념적 이름이다. 실제 운영체제는 거대한 한 덩어리 안에 모든 값을 직접 넣기보다, 핵심 구조체가 메모리·파일·권한 같은 다른 커널 구조를 가리키도록 나눌 수 있다.
3. 한 항목씩 실제 사건과 연결하기
PID: “누구의 상태인가?”
PID, Process ID는 Process를 구분하는 번호다.
Process A의 Register를 Process B의 것으로 잘못 복원하면 실행이 망가진다. 운영체제는 각 Process를 정확히 식별해야 한다.
Process State: “지금 실행 후보인가?”
Timer로 멈춘 A는 보통 Ready가 된다. 파일을 기다리며 멈춘 A는 Waiting이 된다.
- Ready라면 Scheduler의 선택 후보가 된다.
- Waiting이라면 사건이 끝나기 전에는 Ready Queue에 넣으면 안 된다.
PC와 Register: “어디서 어떤 값으로 이어 갈까?”
실행을 재개하는 직접적인 책갈피다. 다만 실제로는 일부 CPU 상태가 Process의 Kernel Stack에 저장되는 등 위치가 나뉠 수 있다.
Scheduling 정보: “언제 다시 차례를 줄까?”
우선순위, 최근 CPU 사용량, Queue의 위치 같은 정보가 다음 선택에 영향을 준다.
Memory 정보: “같은 주소를 누구의 메모리로 해석할까?”
A와 B는 둘 다 가상 주소 0x1000을 쓸 수 있지만 실제로는 서로 다른 메모리를 가리킬 수 있다. Process가 바뀔 때는 B의 주소 공간을 사용하도록 주소 변환 기준을 맞춰야 한다.
File과 I/O 정보: “어떤 자원을 쓰고 있었나?”
A가 파일 번호 3을 읽고 있었다면, 운영체제는 그 번호가 어떤 열린 파일을 뜻하는지 알아야 한다. Process가 잠깐 CPU를 빼앗겼다고 파일이 닫혀서는 안 된다.
4. 개념적인 PCB 한 장
아래는 실제 특정 운영체제 코드를 복사한 것이 아니라, 이해를 위한 단순한 예시다.
PCB of Process A
────────────────────────────────
PID : 101
State : READY
Saved PC : 0x004012A0
Saved Stack Pointer : 0x7FFF1000
Saved Registers : R1=11, R2=55, ...
Priority : 5
CPU Time Used : 124 ms
Address Space : A의 Page Table 관련 정보
Open Files : keyboard, report.txt
Waiting Event : 없음
Owner : user 501
────────────────────────────────
이 정보가 있으므로 운영체제는 나중에 다음과 같이 판단할 수 있다.
- A는 Waiting이 아니라 Ready다.
- 우선순위와 Scheduling 규칙상 A를 선택할 수 있다.
- A의 주소 공간을 활성화한다.
- 저장된 CPU 상태를 복원한다.
- PC가 가리키는 명령부터 실행한다.
5. PCB는 어디에 있을까?
PCB에 해당하는 정보는 Kernel이 보호하는 메모리 영역에 있다. 일반 Process가 마음대로 고칠 수 없어야 한다.
만약 A가 자기 PCB를 직접 바꿀 수 있다면 다음과 같은 거짓말이 가능해질 수 있다.
- “내 우선순위는 최고야.”
- “나는 관리자 권한이 있어.”
- “B의 메모리도 내 메모리야.”
- “CPU 사용 시간은 0이야.”
그래서 사용자 프로그램은 보통 System Call이라는 통제된 입구를 통해 운영체제에 요청한다. 운영체제는 권한과 조건을 검사한 뒤 관리 정보를 바꾼다.
6. PCB는 Queue와 연결된다
운영체제는 PCB 자체나 PCB를 가리키는 항목을 Queue에 연결해 관리할 수 있다.
Ready Queue
front → [PCB B] → [PCB A] → [PCB D]
Disk Waiting Queue
front → [PCB C] → [PCB E]
- CPU가 비면 Scheduler는 Ready Queue의 후보를 살펴본다.
- C의 디스크 읽기가 끝나면 C는 Disk Waiting Queue에서 빠져 Ready 상태가 된다.
실제 현대 운영체제의 Queue 구조와 Scheduling 자료구조는 더 복잡할 수 있지만, 큰 흐름은 “상태별로 실행 가능성과 대기를 관리한다”이다.
7. PCB의 생애
Process 생성
- 운영체제가 Process 식별자를 정한다.
- 주소 공간과 Kernel 관리 구조를 준비한다.
- 처음 실행할 PC와 Stack을 준비한다.
- 상태를 Ready로 만들고 Scheduling 대상에 넣는다.
Process 실행 중
- Running, Ready, Waiting 상태가 바뀐다.
- CPU 사용 시간이 기록된다.
- 파일을 열고 닫으면 관련 정보가 바뀐다.
- Context Switch가 필요할 때 실행 상태가 보존된다.
Process 종료
- 종료 상태와 결과를 기록한다.
- 열린 파일과 메모리 같은 자원을 정리한다.
- 부모가 종료 정보를 확인하는 절차가 있을 수 있다.
- 더 이상 필요 없을 때 PCB에 해당하는 관리 정보도 회수한다.
8. PCB와 Context는 같은 말이 아니다
두 개념의 관계를 정확히 정리하자.
| 질문 | PCB | Context |
|---|---|---|
| 무엇인가? | Process를 관리하는 Kernel의 기록 | 실행을 이어 가는 데 필요한 상태 |
| 범위 | 식별, 상태, Scheduling, Memory, File, 권한 등 넓음 | 문맥에 따라 CPU 상태 중심 또는 관련 실행 환경까지 포함 |
| 언제 존재하나? | Process 생애 동안 유지됨 | 실행 중 계속 변하며 Switch 때 필요한 부분을 보존·복원 |
| Switch 때 전부 복사하나? | 아니다 | 필요한 CPU 및 관련 상태를 저장·복원 |
따라서 다음 문장은 좋은 출발점이다.
운영체제는 Process별 PCB와 관련 Kernel 구조를 유지하며, Context Switching 때 현재 실행을 재개하는 데 필요한 Context를 저장하고 다음 Process의 Context를 복원한다.
9. 실제 운영체제에서는
Linux 같은 실제 운영체제에서는 교과서의 PCB와 비슷한 역할을 하나의 단순한 이름으로만 구현하지 않는다. Process와 Thread를 공통된 Task로 다루는 핵심 구조, Kernel Stack, Memory 구조, File 구조 등이 서로 연결되어 있다.
이 사실이 중요한 이유는 하나다.
“PCB라는 상자에 모든 Register가 항상 들어 있다”는 그림은 이해를 위한 모델이지, 모든 CPU와 운영체제의 물리적 배치를 그대로 나타낸 그림은 아니다.
처음 공부할 때는 교과서 모델로 흐름을 잡고, 운영체제 구현을 배울 때 저장 위치와 저수준 전환 코드를 구체화하면 된다.
스스로 설명하기
- PCB에 PID만 있으면 왜 부족할까?
- 열린 파일 정보는 왜 Process가 CPU를 쓰지 않는 동안에도 남아 있어야 할까?
- PCB가 사용자 Process의 일반 메모리에 있으면 왜 위험할까?
- “Context Switching은 PCB 전체 복사다”가 틀린 이유는?
정답 확인
- Process를 이어 실행하고 관리하려면 현재 상태, CPU 상태, Scheduling, Memory, File, 권한 등도 알아야 한다.
- CPU 차례를 잠깐 잃은 것일 뿐 Process의 작업과 자원 사용은 계속 유효하기 때문이다.
- Process가 우선순위, 권한, 메모리 정보 등을 위조할 수 있기 때문이다.
- PCB의 많은 관리 정보는 계속 유지되며, Switch에서는 재개에 필요한 CPU 및 관련 상태를 저장·복원하기 때문이다.
