90. 프로세스 제어 블록 (PCB, Process Control Block) / 태스크 제어 블록 (TCB)

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

본질: PCB (Process Control Block)는 운영체제가 각 프로세스의 상태, 레지스터 값, 메모리 정보 등 모든 메타데이터를 추적하고 관리하기 위해 커널 공간에 유지하는 핵심 자료구조다.

가치: CPU 시분할 환경에서 문맥 교환 (Context Switch) 시, 현재 작업 상태를 안전하게 저장하고 다음 작업 상태를 복원할 수 있게 하여 멀티태스킹의 물리적 기반을 제공한다.

판단 포인트: 프로세스 내에서 스레드가 분화함에 따라, 공유 자원은 PCB에 남기고 개별 실행 흐름은 TCB (Task Control Block)로 분리 관리하여 스케줄링 오버헤드를 극적으로 낮추는 계층적 아키텍처로 진화했다.

Ⅰ. 개요 및 필요성

프로세스 제어 블록 (PCB, Process Control Block)은 커널이 시스템 내의 실행 중인 프로세스를 제어하기 위해 사용하는 데이터 구조체다. 리눅스에서는 task_struct로 구현되며, 프로세스의 생명 주기를 통제하는 '주민등록증'과 같다. 더 세밀한 실행 단위인 스레드가 등장하면서, 고유 상태를 담는 TCB (Task Control Block)가 PCB 내부에 계층적으로 연결되었다.

하나의 CPU 코어는 동시에 하나의 명령어만 처리할 수 있다. 시분할 (Time-Sharing) 운영체제에서 여러 프로세스가 동시에 실행되는 것처럼 보이려면, CPU가 프로세스 A에서 B로 제어권을 넘길 때 A의 정확한 중단 지점(레지스터, 프로그램 카운터)을 완벽히 기억해야 한다. 이 하드웨어 문맥을 안전한 커널 메모리에 백업해두는 공간이 바로 PCB다. PCB가 없다면 중단된 지점부터 다시 코드를 이어서 실행하는 것은 불가능하다.

📢 섹션 요약 비유: PCB는 독서광이 두꺼운 책을 읽다 잠시 덮을 때 꽂아두는 '상세한 책갈피와 메모장'과 같다. 며칠 뒤 책을 펼쳐도 정확히 몇 페이지 몇 번째 줄이었는지 즉시 몰입할 수 있게 해준다.

Ⅱ. 아키텍처 및 핵심 원리

PCB는 유저가 임의로 조작하여 권한을 탈취하는 것을 막기 위해 반드시 보안이 격리된 커널 공간 (Kernel Space)에만 적재된다.

구성 요소	역할 및 데이터	스케줄링 관점의 의미
프로세스 식별자 (PID)	고유 번호, PPID, UID 저장	커널의 해시 테이블에서 해당 프로세스를 찾는 키
상태 (State)	Ready, Running, Wait, Zombie 등	큐 정렬 및 스케줄러 선택의 기준
CPU 문맥 (Context)	PC, SP, 범용 레지스터 값 백업	다음 실행 재개 시 하드웨어에 복원할 필수 데이터
메모리 관리 정보	페이지 테이블 포인터, 세그먼트	프로세스 간 메모리 침범 방지 및 주소 공간 고립
I/O 상태 정보	할당된 자원, 열린 파일(FD) 목록	자원 반납 확인 및 교착 상태 분석에 사용

문맥 교환 (Context Switch) 시, 커널은 실행 중이던 프로세스의 CPU 레지스터 값을 자신의 PCB에 '저장(Save)'하고, 새롭게 선택된 프로세스의 PCB에서 레지스터 값을 '복원(Restore)'한다.

┌──────────────────────────────────────────────────────────────┐
│           문맥 교환 (Context Switch)과 PCB의 역할            │
├──────────────────────────────────────────────────────────────┤
│  [프로세스 A]                [OS 커널]                [프로세스 B] │
│      │                          │                          │       │
│  (실행 중) ──▶ 인터럽트 발생 ─▶│                          │       │
│      │                   ┌──────▼──────┐                   │       │
│      │                   │ A의 레지스터를 │                   │       │
│      │                   │ PCB_A에 저장  │                   │       │
│      │                   └──────┬──────┘                   │       │
│      │                   ┌──────▼──────┐                   │       │
│      │                   │ PCB_B에서 B의 │                   │       │
│      │                   │ 레지스터 복원 │                   │       │
│      │                   └──────┬──────┘                   │       │
│      │                          │──▶ 복원 완료 ────────▶ (실행 재개)│
│      │                          │                          ▼       │
│ * 핵심: 저장/복원 구간에서는 사용자 코드가 전혀 실행되지 않는 오버헤드 발생 │
└──────────────────────────────────────────────────────────────┘

이 과정에서 CPU는 실제 애플리케이션 연산이 아닌 운영체제의 상태 저장 작업만 수행하므로, 교환 횟수가 많아질수록 전체 시스템의 처리량(Throughput)은 하락한다.

📢 섹션 요약 비유: 게임을 끄기 전에 정확한 위치와 아이템 상태를 '세이브 파일(PCB)'로 만들고, 다음 날 다시 게임을 켤 때 '로드'를 해야만 어제 잡다 만 몬스터부터 이어서 싸울 수 있는 원리다.

Ⅲ. 비교 및 연결

현대 멀티스레딩 환경에서는 PCB 단일 구조의 무거운 문맥 교환 비용을 줄이기 위해, 자원 공유 영역과 실행 흐름 영역을 분리하는 TCB (Task Control Block) 구조를 채택했다.

비교 항목	프로세스 간 문맥 교환 (PCB 교체)	스레드 간 문맥 교환 (TCB 교체)
전환 대상	PCB 전체와 고유 주소 공간 맵핑	동일 PCB 내의 TCB만 전환
메모리 처리	페이지 테이블 교체 발생	기존 페이지 테이블 유지 (공유)
캐시 (Cache)	TLB (Translation Lookaside Buffer) 플러시	TLB 내용 유지 (캐시 히트 상승)
성능 오버헤드	매우 무거움	비교적 가벼움

같은 프로세스 내에서 스레드만 교체할 경우, 메모리 맵핑(페이지 테이블)이 동일하므로 캐시 초기화나 주소 변환 캐시(TLB)의 플러시가 발생하지 않는다. 이것이 스레드 문맥 교환이 프로세스 교환보다 압도적으로 빠른 구조적 이유다.

📢 섹션 요약 비유: 이사를 갈 때 살림살이를 다 싸서 아예 다른 동네로 떠나는 것(PCB 교체)과, 같은 집 안에서 거실에 있다가 안방으로 자리만 옮기는 것(TCB 교체)만큼이나 소모되는 비용이 다르다.

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

실무 환경에서 PCB는 커널 메모 공간과 시스템 안정성을 결정짓는 핵심 지표로 다뤄진다.

체크리스트 및 실무 판단 포인트

좀비 프로세스 (Zombie Process) 적체 방어: 시스템 모니터링 시 'Z' 상태의 프로세스가 수백 개 쌓이는 현상. 프로세스가 메모리를 반납하고 종료되었음에도, 부모 프로세스가 wait() 시스템 콜을 호출하지 않아 커널이 PCB 뼈대와 식별자(PID)를 지우지 못해 발생한다. 이는 가용 PID를 고갈시켜 신규 프로세스 생성을 막으므로, 부모 프로세스를 수정하거나 종료시켜 Init 프로세스가 회수(Reaping)하도록 조치해야 한다.
포크 폭탄 (Fork Bomb) 공격 통제: 악의적인 스크립트가 무한정 자식 프로세스를 생성하면, 각 PCB가 차지하는 커널 메모리가 고갈되어 OOM (Out of Memory) 패닉이 발생한다. 엔지니어는 ulimit -u 설정을 통해 사용자당 생성 가능한 최대 프로세스 수를 제한해야 한다.

안티패턴

멀티스레드 애플리케이션에서 스레드 종료 시 자원을 적절히 detach 또는 join하지 않아 TCB가 커널에 누수(Leak)되도록 방치하는 설계.
📢 섹션 요약 비유: 직원이 퇴사할 때 노트북은 반납했지만, 인사팀이 퇴사 결재(wait)를 안 해줘서 직원 명부(PCB)에 빈 이름표가 남아 신규 채용(PID 할당)을 못 하는 행정 마비 상태와 같다.

Ⅴ. 기대효과 및 결론

PCB와 TCB의 정교한 관리 구조는 단일 CPU에서도 수천 개의 작업이 부드럽게 돌아가는 현대 멀티태스킹의 기적을 가능케 했다.

초기에는 무거운 상태 정보를 모두 엎어 쓰는 방식이었으나, 점차 메모리 영역은 묶어두고 실행 흐름만 가볍게 스위칭하는 TCB 계층 구조로 진화하며 성능을 극대화했다. 미래에는 eBPF 기술을 통해 커널 모듈 수정 없이도 PCB의 상태 변화를 실시간으로 추적하거나, 사용자 공간(User Space)에서 커널 개입 없이 수만 개의 가상 스레드(Virtual Thread)를 직접 스케줄링하는 방식으로 아키텍처가 발전하고 있다.

📢 섹션 요약 비유: 두꺼운 종이 서류철(초기 PCB) 하나로 모든 걸 관리하다가, 이제는 가벼운 포스트잇(TCB)을 서류철 안에 여러 장 붙여 빠르게 넘겨가며 일하는 고효율 시스템으로 진화한 것이다.

📌 관련 개념 맵

개념	연결 포인트
문맥 교환 (Context Switch)	CPU 점유가 넘어갈 때 이전 상태를 PCB에 저장하고 새 PCB를 읽어오는 멈춤 현상
TLB (Translation Lookaside Buffer)	PCB 교체 시 메모리 맵핑이 달라져 플러시가 발생하며 시스템 성능을 떨어뜨리는 주범
스레드 (Thread)	단일 PCB를 공유하며 독자적인 TCB만 들고 실행되는 가벼운 작업 단위
좀비 프로세스 (Zombie)	몸(메모리)은 죽었으나 부모가 상태를 확인해주지 않아 커널에 영혼(PCB)이 묶여있는 상태

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

일괄 처리 (Batch Processing)
    │
    ▼
PCB (Process Control Block) 도입 · 멀티태스킹 (시분할) 구현
    │
    ▼
문맥 교환 (Context Switch) 오버헤드 최소화 요구
    │
    ▼
TCB (Task Control Block) 분리 · 가벼운 멀티스레딩
    │
    ▼
경량 사용자 스레드 (Goroutine, Virtual Thread)의 등장

이 흐름도는 프로세스 관리 아키텍처가 무거운 통합 구조에서 가볍고 세분화된 계층 구조로 진화하여 응답 속도를 극대화하는 과정을 보여준다.

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

PCB는 컴퓨터 안의 여러 프로그램들이 각자 자기가 어디까지 일했는지 꼼꼼히 적어두는 비밀 일기장이에요.
이 일기장은 너무 중요해서 아무나 볼 수 없는 '커널 공간'이라는 튼튼한 금고 안에 안전하게 보관되어 있어요.
컴퓨터가 게임을 하다가 유튜브로 넘어갈 때, 게임 일기장에 상황을 적어두고 유튜브 일기장을 꺼내오기 때문에 다시 게임을 켜도 끊김 없이 이어서 할 수 있답니다!