081. 프로그램 vs 프로세스 (Program vs. Process)

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

본질: 프로그램(Program)이 하드디스크에 저장된 차갑고 수동적인 0과 1의 **정적(Static) 파일(쇳덩어리 조각)**이라면, 프로세스(Process)는 그 파일이 메인 메모리(RAM)에 올라가 CPU의 심장 박동(Clock)을 받으며 펄떡이는 동적(Dynamic) 실행 주체다.

가치: 이 분리를 통해 운영체제는 하나의 '카카오톡 프로그램'을 두 번 더블클릭하면, 디스크의 파일을 수정하지 않고도 메모리 위에 완전히 독립된 밥그릇(메모리 공간, PID)을 가진 '두 개의 카카오톡 프로세스'를 생성하여 멀티태스킹을 지원할 수 있다.

판단 포인트: 프로그램이 프로세스로 부화(Instantiate)하는 순간, 운영체제는 프로세스를 관리하기 위해 주민등록증 격인 **PCB(Process Control Block)**를 커널 메모리에 생성하며, 이 순간부터 프로세스는 OS의 가혹한 스케줄링 통제를 받는 노예가 된다.

Ⅰ. 개요 및 필요성

바탕화면에 있는 Chrome.exe 아이콘을 보자. 더블클릭하기 전의 이 파일은 아무 짓도 하지 않는다. 그냥 디스크의 공간을 차지하고 있는 죽은 문서(Program)다. 하지만 마우스로 더블클릭하는 순간, 이 죽은 문서는 메모리 위로 복사되어 멱살이 잡힌 채 CPU의 자원을 집어삼키며 화면에 웹 페이지를 렌더링하는 살아있는 생명체(Process)로 돌변한다.

컴퓨터 공학은 왜 이 둘을 분리해 부를까? "크롬이 뻗었다"고 할 때 디스크에 있는 파일(Chrome.exe)이 고장 난 것이 아니라, 메모리 위에서 실행 중인 10개의 탭(10개의 Process) 중 하나가 메모리 충돌로 죽어버린 것이기 때문이다. 운영체제(OS)의 가장 중요한 존재 이유는 이 수백 개의 '살아 숨 쉬는 프로세스'들이 한정된 CPU와 메모리를 놓고 싸우지 않도록 시분할(Time-sharing)로 다스리는 것이다. 죽은 프로그램은 OS의 관심 밖이다. OS의 지배는 오직 프로세스에게만 향한다.

📢 섹션 요약 비유: 프로그램은 넷플릭스에 저장된 '오징어 게임 대본(정적 파일)'이다. 대본은 그냥 종이일 뿐이다. 반면 프로세스는 촬영장에 배우들이 모여 대본을 들고 땀 흘리며 연기하는 '촬영 현장(동적 실행)'이다. 대본 하나로 한국판 오징어 게임도 찍고 미국판도 찍을 수 있듯, 하나의 프로그램으로 수많은 프로세스를 동시에 띄울 수 있다.

Ⅱ. 아키텍처 및 핵심 원리

로딩(Loading)과 메모리 공간의 4대 구역 창조

프로그램이 프로세스가 되는 물리적 아키텍처는 메모리 할당(Allocation)으로 시작된다.

┌────────────────────────────────────────────────────────┐
│           프로그램 ➔ 프로세스 변환의 물리적 메모리 아키텍처       │
├────────────────────────────────────────────────────────┤
│   [ 하드 디스크 (HDD/SSD) ]                             │
│      죽은 파일: `game.exe` (100MB)                       │
│        │                                               │
│        ▼ (더블클릭! ──▶ OS의 Loader 작동)                 │
│ ═══════════════════════════════════════════════════════│
│   [ 메인 메모리 (RAM) - 살아있는 프로세스 공간 생성 ]           │
│                                                        │
│     [ 프로세스 제어 블록 (PCB) ] ──▶ 커널 영역에 주민등록증 생성 │
│      - PID: 4092, 상태: Running                         │
│     ---------------------------------------------------│
│     [ Stack 영역 ] ──▶ 지역 변수, 함수 호출 기록 (위에서 ⬇) │
│          ( 빈 공간 - 동적 확장/축소)                      │
│     [ Heap 영역 ]  ──▶ 동적 메모리 할당 (malloc) (아래서 ⬆) │
│     ---------------------------------------------------│
│     [ Data 영역 ]  ──▶ 전역 변수, 정적(Static) 변수        │
│     [ Text (Code) 영역 ] ──▶ 기계어 명령어(`game.exe` 본체) │
└────────────────────────────────────────────────────────┘

디스크에 있던 코드는 그대로 메모리의 Text 구역에 복사된다. 하지만 프로세스가 되면서 새로 생기는 가장 중요한 공간은 Stack과 Heap이다. 이 공간이 있어야 비로소 데이터를 저장하고 함수를 호출하며 생명 활동(실행)을 할 수 있다.

📢 섹션 요약 비유: 프로그램은 '요리책(레시피)'이고 프로세스는 '요리사가 부엌에서 요리하는 행위'다. 레시피(Text 영역)를 부엌 벽에 붙이고, 도마 위에 재료(Data 영역)를 올리고, 요리 중 생기는 쓰레기를 임시 봉투(Stack/Heap)에 버려가며 완성된 볶음밥(결과물)을 만들어내는 동적인 전체 주방의 상태가 프로세스다.

Ⅲ. 비교 및 연결

수동적 상태(Program) vs 능동적 개체(Process)

컴퓨터 아키텍처에서 정적 자산과 동적 자원을 엄격히 구분하는 표다.

비교 항목	프로그램 (Program)	프로세스 (Process)
상태 / 본질	정적(Static) / 파일(File)	동적(Dynamic) / 실행 중인 프로그램
저장 위치	보조기억장치 (HDD, SSD)	메인 메모리 (RAM)
자원 할당 (OS)	파일 시스템의 디스크 용량만 차지	CPU 시간, 메모리 공간(Stack/Heap), PID 등
라이프사이클	지우지 않는 한 영원히 존재	생성(New) ➔ 실행(Running) ➔ 종료(Terminated)
개수 관계	1개 (예: 워드프로세서 설치 파일 1개)	N개 (워드 창을 3개 띄우면 프로세스는 3개)

OS 커널 입장에서 디스크에 있는 프로그램은 단순히 관리해야 할 '짐(Block Data)'에 불과하다. 그러나 더블클릭으로 프로세스가 되는 순간, OS는 프로세스 제어 블록(PCB)이라는 서류를 만들어 CPU 스케줄러 큐에 줄을 세우고, 메모리를 감시하고, 죽으면 시체(좀비 프로세스)를 치워야 하는 피곤한 '상전'으로 모시게 된다.

📢 섹션 요약 비유: 프로그램은 박물관에 박제된 '호랑이 표본'이다. 밥도 안 먹고 움직이지도 않는다. 더블클릭(실행)을 하면 이 표본에 마법이 걸려 밀림을 뛰어다니는 '살아있는 호랑이(프로세스)'가 된다. 이 호랑이는 배가 고파 밥(메모리)을 먹어야 하고, 달리기 위해 체력(CPU)을 소비한다.

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

실무 시나리오

OOM (Out Of Memory) 킬러의 프로세스 처형: 리눅스 서버에서 자바 프로그램(java -jar app.jar)을 실행했다. 디스크의 app.jar는 겨우 50MB지만, 이놈이 램(RAM)에 올라가 프로세스가 된 후 트래픽을 받아 Heap 영역에 객체를 미친 듯이 생성(메모리 누수)하여 8GB를 집어삼켰다. 시스템 전체가 멈추려 하자, 리눅스 커널의 OOM Killer는 디스크의 프로그램을 건드리지 않고, 메모리 위에서 가장 뚱뚱해진 이 Java '프로세스'의 멱살을 잡아 즉각 처형(SIGKILL)하여 서버의 생명을 연장한다.
Copy-on-Write (COW) 기반의 포크(Fork) 최적화: 웹 서버(Nginx)는 들어오는 요청을 처리하기 위해 자신(프로세스)과 똑같이 생긴 자식 프로세스를 복제(fork())하여 띄운다. 만약 크기가 100MB인 프로세스 10개를 띄울 때마다 메모리를 100MB씩 새로 복사(통째로 로딩)한다면 메모리가 남아나지 않는다. 천재 아키텍트들은 부모와 자식 프로세스가 Text(코드)와 Data 영역을 공유(Sharing)하게 놔두고, 누군가 값을 수정하려고 할 때만(Write) 메모리를 복사(Copy)해 주는 COW 기법을 도입해 프로세스 생성 속도를 빛의 속도로 올렸다.

안티패턴

좀비(Zombie) 프로세스와 고아(Orphan) 프로세스 방치 (거버넌스 붕괴): 개발자가 짠 C 프로그램이 자식 프로세스를 무수히 생성(fork)한 뒤, 자식이 임무를 다하고 죽었을 때(exit) 부모가 자식의 사망 신고(wait())를 거두지 않고 무시해 버리는 C코드 안티패턴. 메모리는 반환되었지만, OS의 PCB(프로세스 관리 장부)에는 이 죽은 자식들의 시체(Zombie Process) 기록이 삭제되지 않고 수만 개씩 쌓이게 된다. 결국 OS는 더 이상 새로운 프로세스(PID)를 발급할 빈칸이 없어져 시스템 전체가 셧다운되는 치명적 파국을 맞는다.
📢 섹션 요약 비유: 좀비 프로세스 방치는 식당(서버)에서 손님(프로세스)이 밥을 다 먹고 떠났는데, 사장(부모 프로세스)이 테이블 장부(PCB)에서 예약 취소 줄을 긋지 않은 것이다. 나중에는 장부상으로 모든 테이블이 꽉 차 있어서, 실제로는 빈자리가 엄청 많은데도 새로운 손님을 한 명도 받지 못하고 가게 문을 닫게 된다.

Ⅴ. 기대효과 및 결론

프로그램과 프로세스의 분리는, 컴퓨터를 '단순한 전자 문서 보관함'에서 '동시에 수백 개의 생명체가 살아 움직이는 거대한 생태계(운영체제)'로 진화시킨 결정적 추상화(Abstraction)다.

우리가 스마트폰에서 카카오톡을 하다가 유튜브로 앱을 전환할 때 화면이 멈추지 않는 이유는, 디스크에 있는 두 개의 죽은 앱(프로그램)이 아니라, 메모리 위에서 OS의 완벽한 스케줄링 지휘를 받으며 0.001초 단위로 CPU를 나눠 쓰는 살아있는 두 개의 프로세스(Process)가 존재하기 때문이다. 결론적으로 프로그램은 개발자가 남긴 정적인 흔적이고, 프로세스는 그 흔적이 운영체제의 숨결을 만나 폭발적으로 작동하는 동적인 엔진이다.

📢 섹션 요약 비유: 프로그램은 마법사가 쓴 '주문서(스크롤)' 파일이다. 프로세스는 그 스크롤을 찢어 마법을 시전했을 때 허공에 소환되어 불을 뿜는 '드래곤'이다. 스크롤 1장으로 드래곤 10마리를 동시에 소환(멀티 프로세스)할 수 있으며, OS는 이 드래곤들이 서로 싸우지 않고 일하도록 통제하는 절대적인 마법통제국이다.

📌 관련 개념 맵

개념	연결 포인트
스레드 (Thread)	프로세스라는 무거운 밥그릇(메모리 공간) 안에서, 밥은 같이 먹으면서 숟가락만 여러 개 얹어 동시에 일하는 프로세스 내부의 '더 가벼운 실행 단위'
PCB (Process Control Block)	프로그램이 프로세스가 될 때 커널이 발급하는 주민등록증. 프로세스 ID(PID), 현재 상태, CPU 레지스터 값 등을 모두 꼼꼼하게 기록해 두는 쇳덩어리 장부
문맥 교환 (Context Switching)	CPU가 A 프로세스를 실행하다 멈추고 B 프로세스로 넘어갈 때, A의 하던 일(레지스터)을 PCB에 백업하고 B의 일을 복원하는 무겁고 피곤한 OS의 쇳덩어리 전환 작업

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

초창기 일괄 처리 시스템 (Batch Processing) ──▶ 한 번에 하나의 프로그램만 순차 실행
    │
    ▼
다중 프로그래밍 (Multiprogramming) 필요성 대두 (CPU가 노는 시간을 줄이자!)
    │
    ▼
디스크의 프로그램과 메모리 위의 실행 상태를 분리 ──▶ '프로세스(Process)' 개념 탄생
    │
    ▼
프로세스 관리를 위한 PCB 도입 및 시분할(Time-Sharing) 스케줄링 알고리즘 발전
    │
    ▼
프로세스 생성의 무거움 극복 ──▶ 메모리를 공유하는 경량 프로세스인 '스레드(Thread)'로 진화

이 흐름도는 "정적 코드의 순차 실행 → 동적 생명체(프로세스)로의 추상화 및 다중 제어 → 시스템 자원 절약을 위한 스레드 분할"이라는 운영체제 실행 단위의 역사적 진화를 보여준다.

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

'프로그램'은 서점에 꽂혀있는 새 요리책이에요. 아직 아무 요리도 만들어지지 않은 종이 묶음이죠.
하지만 요리사가 이 책을 사서 주방(메모리)에 펼치고 재료를 지글지글 볶기 시작하면, 이 살아 움직이는 요리 현장을 '프로세스'라고 불러요.
책(프로그램)은 1권이지만, 그 책을 보고 주방 10곳에서 똑같은 요리를 동시에 만들 수 있어요. 이때 요리 현장(프로세스)은 10개가 되는 거랍니다!