멀티프로세스는 독립된 주소 공간을 가진 여러 프로세스로 작업을 나누고, 멀티스레드는 한 프로세스의 자원을 공유하는 여러 스레드로 작업을 나눕니다. 선택의 핵심은 장애 격리와 자원 공유의 필요성입니다.
| 구분 | 멀티프로세스 | 멀티스레드 |
|---|---|---|
| 메모리·통신 | 주소 공간이 분리되며 IPC로 통신 | 주소 공간을 공유하며 직접 데이터 교환 |
| 장점 | 프로세스별 장애 격리와 독립 관리에 유리 | 자원 공유가 쉽고 생성·통신 비용이 대체로 작음 |
| 단점 | 생성·메모리·IPC 비용이 대체로 큼 | 공유 데이터의 경쟁 상태와 동기화 비용 발생 |
| 장애 영향 | 한 프로세스의 종료가 다른 프로세스를 직접 종료시키지는 않음 | 치명적인 메모리 오류 등이 프로세스 전체에 영향을 줄 수 있음 |
작업 간 격리가 중요하면 멀티프로세스가, 같은 데이터를 자주 공유하면 멀티스레드가 적합합니다. 두 방식 모두 실행 환경이 지원하면 여러 CPU 코어에서 병렬 실행할 수 있습니다.
왜 스레드가 프로세스보다 가볍나요?
프로세스는 각각 독립된 가상 주소 공간과 OS 관리 자원을 가져야 하지만, 스레드는 같은 프로세스의 주소 공간과 코드·힙 등의 자원을 공유하고 스택과 레지스터 같은 실행 상태만 독립적으로 가집니다. 따라서 생성과 메모리 사용, 데이터 교환 비용이 상대적으로 작아 프로세스보다 가볍다고 표현합니다.
CPU를 많이 쓰는 작업에는 항상 멀티프로세스가 더 좋은가요?
아닙니다. 스레드도 런타임이 허용하면 여러 코어에서 병렬 실행할 수 있으므로, 언어·런타임의 제약과 데이터 공유 비용, 장애 격리 요구를 함께 판단해야 합니다.
예를 들어, Java의 Platform Thread는 일반적으로 OS Thread와 대응되므로, 여러 스레드가 여러 CPU 코어에서 실제 병렬 실행될 수 있습니다. 따라서 CPU-bound 작업이라고 해서 반드시 멀티프로세스를 선택할 필요는 없습니다.
스레드 수를 늘리면 성능이 계속 좋아지나요?
아닙니다. CPU 중심 작업은 코어 수를 지나치게 초과하면 컨텍스트 스위칭과 경쟁 비용이 커질 수 있습니다. I/O 중심 작업은 대기 시간을 겹칠 수 있지만 메모리와 외부 시스템의 처리 한도도 고려해야 합니다.
fork()는 부모의 메모리를 모두 즉시 복사하나요?
Linux의 fork()는 일반적으로 Copy-on-Write를 사용합니다. 처음에는 물리 페이지를 공유하고 쓰기가 발생한 페이지를 복사하므로, 생성 시 전체 메모리를 복사하는 비용을 줄입니다.
멀티프로세스도 서로 통신할 수 있는데, 멀티스레드를 사용하는 이유는 무엇인가요?
스레드는 같은 주소 공간의 객체와 캐시, 열린 파일 같은 자원을 직접 공유하므로 IPC 경계를 넘는 복사·직렬화·시스템 콜을 줄일 수 있고 생성과 전환 비용도 대체로 작습니다. 같은 상태를 자주 공유하는 작업에는 효율적이지만, 잘못된 메모리 접근이나 동기화 오류가 프로세스 전체에 영향을 줄 수 있다는 비용을 감수해야 합니다.
웹 서버가 멀티스레드 방식을 선택하는 이유는 무엇인가요?
모든 웹 서버가 멀티스레드인 것은 아니지만, Tomcat처럼 요청별 스레드 모델을 사용하는 서버는 각 요청을 순차적인 코드로 처리하면서 여러 요청을 동시에 다루기 쉽고, 같은 프로세스의 애플리케이션 상태·캐시·커넥션 풀을 공유할 수 있습니다. 프로세스별 요청 처리보다 자원 비용도 대체로 작습니다. 반면 NGINX처럼 적은 워커 프로세스와 Non-blocking 이벤트 루프를 선택하는 서버도 있으므로, “표준 웹 서버는 멀티스레드”라고 일반화할 수는 없습니다.