107. 프로세스 종료 (Process Termination) - exit(), wait()

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

본질: 프로세스 종료 (Process Termination)는 실행 중인 프로세스가 OS에 자원 반환을 요청하여 생명주기를 마감하는 과정으로, exit() 시스템 콜이나 Signal(시그널)을 통해 수행된다.

가치: 점유하던 메모리, 파일 디스크립터 (FD), 동기화 객체를 OS가 안전하게 회수하게 하여 자원 누수 (Resource Leak)를 막고, 부모 프로세스에 종료 상태를 보고하게 한다.

판단 포인트: 치명적 오류나 SIGKILL로 인한 비정상 종료 시 사용자 수준 정리 로직(atexit 등)이 건너뛰어져 데이터 유실이 발생할 수 있으므로, 클라우드 환경에서는 SIGTERM을 이용한 우아한 종료 (Graceful Shutdown) 파이프라인 설계가 필수적이다.

Ⅰ. 개요 및 필요성

프로세스 종료 (Process Termination)는 프로세스가 실행을 중단하고 운영체제에 할당받은 자원의 반환을 요청하는 생명주기의 마지막 단계다. 프로세스는 스스로 exit() 시스템 콜을 호출하여 끝내는 정상 종료 (Normal Termination)와, 치명적 오류(널 포인터 참조 등)나 외부의 강제 시그널(SIGKILL 등)에 의해 운영체제가 강제로 날려버리는 비정상 종료 (Abnormal Termination)로 나뉜다.

이 과정이 중요한 이유는 자원의 유한성 때문이다. 프로세스가 쓰던 메모리 페이지, 네트워크 소켓, 열려 있는 파일 디스크립터 (File Descriptor)를 제대로 회수하지 않으면 시스템 자원이 말라버려 결국 OS 전체가 패닉에 빠진다. 또한 부모 프로세스에게 성공/실패 여부를 알려주어 후속 작업이 이어지도록 동기화하는 역할도 맡는다.

📢 섹션 요약 비유: 프로세스 종료는 직장인의 퇴사와 같다. 정상 종료는 인수인계(자원 반환)를 마치고 사직서를 낸 뒤 나가는 것이고, 비정상 종료는 치명적 사고를 쳐서 짐도 못 싸고 당일 쫓겨나는 것과 같다. 어떻게 나가든 인사팀(OS)은 사번을 말소하고 자리를 회수해야 한다.

Ⅱ. 아키텍처 및 핵심 원리

정상 종료 시, 프로세스는 런타임 라이브러리의 사용자 수준 정리를 거친 후 커널로 진입하여 완전히 해체된다. 반면 비정상 종료는 앞단을 무시하고 커널이 즉각 목을 쳐버린다.

┌──────────────────────────────────────────────────────────────┐
│           프로세스 종료 파이프라인 (exit() vs SIGKILL)          │
├──────────────────────────────────────────────────────────────┤
│  [정상 종료 경로: exit(status) 호출]                             │
│       │                                                      │
│       ▼                                                      │
│  [1. 사용자 수준 정리 (C Runtime)]                              │
│   - atexit() 등록 핸들러 실행                                  │
│   - stdio 버퍼 플러시 (파일 쓰기 완료)                           │
│       │                                                      │
│       ▼  (_exit 시스템 콜로 커널 진입)                           │
│                                                              │
│  [2. 커널 수준 정리 (OS Kernel)] ◀─ (SIGKILL 비정상 종료 시 이리로 직행)│
│   - 메모리 영역 할당 해제 및 파일 디스크립터 닫기                   │
│   - 상태를 좀비 (ZOMBIE)로 변경하고 종료 상태(Exit Status) 저장     │
│   - 부모 프로세스에 SIGCHLD 시그널 전송                           │
│       │                                                      │
│       ▼                                                      │
│  [3. 부모의 수거 (wait)]                                        │
│   - 부모가 wait() 호출 시 PCB까지 최종 삭제 (완전 소멸)            │
└──────────────────────────────────────────────────────────────┘

이 다이어그램은 비정상 종료의 위험성을 명확히 보여준다. SIGKILL(9) 시그널을 받으면 1단계인 사용자 수준 정리(버퍼 플러시 등)를 건너뛰고 2단계로 직행한다. 메모리나 파일에 쓰려던 임시 데이터가 허공으로 증발해버리는 것이다. 따라서 프로세스 상태 전이는 자원 누수를 막는 커널의 방어 메커니즘과 직결된다.

📢 섹션 요약 비유: 비정상 종료 시 커널 직행은 마치 방을 비우기 전에 쓰레기를 치우고 편지를 남기는 시간(버퍼 플러시)조차 안 주고 강제 퇴거 용역(SIGKILL)이 문을 부수고 들어와 사람만 쫓아내는 것과 같다. 편지는 못 전하지만 방(메모리)은 확실히 비워진다.

Ⅲ. 비교 및 연결

부모 프로세스가 자식의 상태를 회수하는 wait() 호출 여부에 따라 종료 이후의 잔존 상태가 갈리며, 이는 시스템 모니터링의 중요한 경계 포인트가 된다.

상태 명칭	원인 메커니즘	자원 점유 상태	해결책 (OS 개입)
좀비 프로세스 (Zombie Process)	자식은 종료되었으나, 부모가 `wait()`를 호출하지 않음	물리 메모리나 FD는 반환됨. 단, 커널 내 PCB(프로세스 제어 블록) 1개 공간만 차지함	부모가 `wait()`를 호출하거나, 부모를 죽여 고아로 만들어 init이 수거하게 함
고아 프로세스 (Orphan Process)	자식보다 부모가 먼저 종료되어버림	자식이 고아가 됨	OS 최상단 프로세스인 `init (PID=1)`이 양자로 입양해 대신 `wait()`로 치워줌

종료라는 이벤트를 기점으로 좀비와 고아는 상반된 개념으로 전개된다. 둘 다 부모-자식 트리의 생명주기 불일치에서 오지만, 고아 프로세스는 OS가 init을 통해 알아서 안전하게 회수해 주는 반면 좀비 프로세스는 무한정 누적되면 PID 공간을 고갈시켜 새 프로세스 생성을 막는 심각한 장애를 유발한다.

📢 섹션 요약 비유: 좀비는 죽어서 무덤(PCB)만 남았는데 사망 신고를 안 한 상태이고, 고아는 아직 살아있는데 부모가 먼저 떠나서 국가(init 프로세스)가 입양해 키우다 나중에 장례를 치러주는 상태다.

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

클라우드 네이티브와 쿠버네티스 (Kubernetes) 환경에서 프로세스 종료 제어는 무중단 배포의 핵심 기술이다.

체크리스트 및 판단 기준

우아한 종료 (Graceful Shutdown) 설계: 서버 프로세스를 내릴 때 다짜고짜 kill -9(SIGKILL)를 때리면 처리 중이던 결제 트랜잭션이 증발한다. 반드시 SIGTERM(15) 시그널 핸들러를 등록해 둬야 한다. 핸들러 내부에서 새 연결은 끊고, 기존 처리 중인 작업은 끝까지 마친 뒤 버퍼 플러시하고 exit(0)를 호출하도록 설계해야 서비스 무중단이 보장된다.
부모 프로세스의 SIGCHLD 핸들링: 백그라운드 워커를 수십 개 띄우는 데몬 (Daemon) 프로그램 설계 시, 자식 프로세스가 비동기적으로 종료될 때 나오는 SIGCHLD 시그널을 잡아 즉시 waitpid()를 호출하는 로직이 없다면 서버는 며칠 내로 좀비 프로세스로 가득 차 뻗어버릴 것이다.

안티패턴

운영 중 kill -9 남용: 로그가 멈췄다고 무조건 kill -9부터 날리면 공유 메모리 락 (Mutex)이 해제되지 않아, 다음에 프로세스를 띄울 때 데드락 (Deadlock)이 걸리는 참사가 빚어진다. kill -15를 먼저 날리고, 일정 시간(예: 30초) 뒤에도 안 죽으면 그때 최후 수단으로 kill -9를 쓰는 투스텝 파이프라인을 강제해야 한다.
📢 섹션 요약 비유: 건물을 부술 때 다짜고짜 다이너마이트(SIGKILL)부터 터트리면 안에 있는 귀중품(작업 중 데이터)까지 날아간다. 반드시 대피 방송(SIGTERM)을 먼저 해서 물건을 뺄 시간을 넉넉히 준 뒤에 건물을 날려야 한다.

Ⅴ. 기대효과 및 결론

프로세스 종료 아키텍처는 유한한 하드웨어 자원을 수많은 프로그램이 번갈아 쓸 수 있게 보장하는 가장 강력한 쓰레기 수거 및 동기화 메커니즘이다. 올바른 종료 파이프라인의 구축은 단순한 소멸을 넘어 데이터 무결성을 보장하고 시스템 업타임 (Uptime)을 극대화한다.

나아가 컨테이너 환경에서는 프로세스가 1번 PID를 꿰차기 때문에, 우아한 종료 처리를 구현하지 않으면 파드 (Pod) 교체 시마다 고객 에러가 폭주하게 된다. 즉, "끝맺음을 어떻게 안전하게 제어하는가"가 현대 백엔드 애플리케이션 성숙도를 가르는 최고 잣대다.

📢 섹션 요약 비유: 무대 위 연극 배우가 죽는 연기(종료)를 할 때 훌륭한 배우는 관객에게 의미(Exit Status)를 남기고 소품(자원)을 무대 밖으로 잘 치우고 내려가지만, 최악의 배우는 세트를 부수고 관객(OS)에게 민폐를 끼치며 질질 끌려 나가는 것과 같다.

📌 관련 개념 맵

개념	연결 포인트
시그널 (Signal)	프로세스에게 "죽어라!" 혹은 "멈춰라!" 등 비동기적 명령을 전달하는 OS의 메시지 체계
wait() / waitpid() 시스템 콜	부모가 자식의 종료(exit)까지 대기하며, 좀비를 방지하는 필수 동기화 수단
PCB (Process Control Block)	프로세스가 끝난 뒤 메모리가 다 털려도, 부모가 확인할 때까지 끝까지 살아남는 최소한의 진료 기록부
쿠버네티스 preStop 훅	프로세스가 컨테이너에서 강제 종료되기 전에 애플리케이션 단의 클린업 스크립트를 꽂아 넣는 클라우드 확장판

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

프로세스 수명 마감
    │
    ▼
exit() 시스템 콜 · 시그널 (Signal) 종료
    │
    ▼
상태 반환 및 자원 회수 대기
    │
    ▼
좀비/고아 프로세스 발생 방지 · wait() 동기화
    │
    ▼
우아한 종료 (Graceful Shutdown)
    │
    ▼
클라우드 컨테이너의 파드 라이프사이클 융합 (SIGTERM/SIGKILL 파이프라인)

이 흐름도는 단순한 개별 프로그램의 종료 메커니즘이 대규모 분산 클라우드 시스템의 무중단 배포 관리 기능으로 스케일업되는 과정을 보여준다.

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

장난감 놀이를 마친 친구가 "끝났어!"라고 선생님께 알리고 장난감을 제자리에 치우는 것이 프로세스의 '정상 종료'예요.
하지만 갑자기 급한 일이 생겨서 장난감을 내팽개치고 밖으로 끌려나가는 건 '비정상 종료(SIGKILL)'랍니다.
가장 중요한 건, 친구가 떠난 뒤에도 선생님(운영체제)이 빈자리와 사물함을 깨끗하게 확인해 줘야 다음 친구가 와서 놀 수 있다는 거예요!