도입
초기 컴퓨터는 한 번에 하나의 작업만 수행할 수 있었습니다.
하나의 프로그램을 실행하면 작업이 끝날 때까지 다른 작업을 할 수 없었고, 그 결과 자원 비효율과 긴 대기 시간이 발생했습니다.
이 문제를 해결하기 위해 운영체제는 여러 프로그램을 메모리에 올려두고, CPU 시간을 잘게 쪼개 번갈아 실행하는 메커니즘을 도입했습니다. 사용자는 “동시에 실행되는 것처럼” 느끼게 되고, 시스템은 제한된 자원을 더 효율적으로 활용할 수 있게 됩니다.
💡 TIP / “동시에 실행”의 실체
대부분의 환경에서 CPU는 한 순간에 하나의 흐름만 실행합니다. “동시에” 보이는 이유는 스케줄링(프로세스 교체) + 문맥 교환(Context Switch)을 매우 빠르게 수행하기 때문입니다.
정의
프로그램은 디스크에 저장된 정적 파일이지만, 프로세스는 메모리에 적재되어 CPU 자원을 배정받아 실행되는 “인스턴스”입니다. 같은 프로그램을 두 번 실행하면 프로세스는 두 개가 됩니다.
운영체제는 프로세스 단위로 PID(식별자), 주소 공간(가상 메모리), 열린 파일/소켓(FD), 권한/환경 변수 등을 관리합니다. 그래서 백엔드 장애/성능 이슈도 결국 “프로세스가 어떤 자원을 얼마나 점유하고 있는가”로 귀결되는 경우가 많습니다.
“프로세스는 단지 ‘실행 중’이 아니라,
자원과 권한을 가진 운영 단위이며, 운영체제는 이 단위를 중심으로 시스템을 통제한다.”
메모리 구조
운영체제는 프로세스마다 독립된 주소 공간을 제공하고, 그 안에서 메모리 영역을 논리적으로 분리합니다. 백엔드 개발자는 이 구조를 이해해야 OOM, StackOverflow, 메모리 누수 같은 문제를 “원인 단위”로 추적할 수 있습니다.

유형
서버 개발에서는 특히 “백그라운드 프로세스(데몬/서비스)”가 핵심입니다. 배치, 로그 수집, 모니터링 에이전트, 메시지 컨슈머 같은 구성 요소들이 대표적이고, 중단 없이 운영되도록 설계하는 것이 중요합니다.
상태
백엔드 성능 이슈에서 가장 중요한 포인트는 Running 자체가 느린지보다, Ready/Blocked에서 대기가 누적되는지입니다. (예: 락 대기, DB I/O 대기, 커넥션 풀 대기, 외부 API 대기)

통제
프로세스 관리는 단순 이론이 아니라 운영과 직결됩니다. 예를 들어 트래픽이 몰릴 때 Ready 대기가 길어지면 지연이 증가하고, 외부 의존성이 느려지면 Blocked 대기가 길어져 전체 처리량이 무너집니다.
프로세스 스케줄링
프로세스 동기화
프로세스 간 통신 (IPC)
생성과 종료 (fork/exec/exit)
✅ 핵심 요약
- ✔️ 프로세스는 실행 중인 프로그램이며, OS의 핵심 관리 단위입니다.
- ✔️ 메모리 구조(Code/Data/Heap/Stack)를 알면 OOM·StackOverflow 원인을 빠르게 좁힐 수 있습니다.
- ✔️ 성능 문제는 Running보다 Ready/Blocked “대기 누적”에서 터지는 경우가 많습니다.
- ✔️ 스케줄링·동기화·IPC·생성/종료는 운영 안정성과 직결됩니다.
- ✔️ 백엔드 개발자는 코드뿐 아니라 “프로세스 자원 상태(메모리/FD/스레드)”를 관측해야 합니다.