멀티프로세스와 멀티스레드, 면접에서 고르는 기준

면접에서 멀티프로세스 멀티스레드 중 하나를 고르라면 공유 메모리와 장애 격리부터 말하면 됩니다. 데이터를 같은 주소 공간에서 자주 함께 다루면 스레드를, 한 작업의 실패가 다른 작업까지 손상시키면 안 되면 프로세스를 우선 검토한다고 답하는 흐름을 잡습니다.

이 글은 면접에서 동시성 모델을 고르는 기준을 정리한 일반 안내이며, 운영체제·언어 런타임·커널 버전에 따라 세부 동작은 달라질 수 있습니다.

멀티프로세스와 멀티스레드는 언제 고르나?

한 줄 답: 같은 주소 공간에서 데이터를 자주 나눠 써야 하면 스레드를, 실패 범위를 분리해야 하면 프로세스를 우선 검토합니다.

선택 기준은 작업을 나누는 방식보다 데이터가 얼마나 자주 공유되는지와 실패를 어디까지 가둘지에서 시작합니다. 한 프로세스의 POSIX threads는 전역 메모리와 힙을 공유하므로, 자주 함께 읽고 쓰는 데이터를 같은 주소 공간에서 다뤄야 할 때 스레드를 우선 검토합니다. 이 공유 범위는 pthreads(7)에서 확인할 수 있습니다.

한 작업의 오류가 다른 작업의 주소 공간까지 영향을 주면 안 되는 경우에는 프로세스 경계를 우선 검토합니다. 다만 프로세스를 선택해도 IPC, 파일, 공유 메모리처럼 별도로 연결한 자원까지 자동으로 격리되는 것은 아니므로, 실제 선택에서는 공유 자원을 함께 확인합니다.

메모리와 장애 격리는 어떻게 다른가?

한 줄 답: 스레드는 같은 주소 공간의 공유 데이터를 다루기 쉽고, fork로 만든 부모와 자식은 별도 메모리 공간에서 실행되어 한쪽의 쓰기가 다른 쪽에 직접 영향을 주지 않습니다.

fork(2)에 따르면 fork로 만든 부모와 자식은 별도의 메모리 공간에서 실행되며, 한쪽의 쓰기·mmap·munmap은 다른 쪽에 영향을 주지 않습니다. 이 특성은 한 작업의 실패가 다른 작업의 메모리까지 바로 훼손되는 범위를 줄이는 근거가 됩니다. Linux의 fork는 copy-on-write를 사용하므로, 프로세스 선택을 설명할 때 생성 비용을 단정하지 않고 실제 생성 시점과 작업 특성을 함께 살핍니다.

Linux에서는 clone(2)의 플래그로 메모리와 스레드 그룹의 공유 범위를 나눕니다. CLONE_VM을 사용하면 같은 메모리 공간을 공유하고, 사용하지 않으면 fork와 같은 방식의 복사본으로 동작합니다. CLONE_THREAD는 같은 스레드 그룹을 정하므로, 메모리 공유 여부와 스레드 그룹 소속을 같은 의미로 설명하지 않습니다.

공유 메모리, 장애 격리, IPC는 서로 대체되는 단어가 아니라 선택에서 확인할 조건입니다. 다음 표는 특정 회사의 실제 면접 질문이나 평가 기준이 아니라, 동시성 모델을 고를 때 사용하는 일반 기준입니다.

기준	스레드를 우선 검토하는 경우	프로세스를 우선 검토하는 경우
공유 메모리	같은 주소 공간에서 데이터를 자주 나눠 쓰며 동기화를 설계합니다.	직접 공유를 줄이고 IPC나 명시적 전달을 설계합니다.
장애 격리	실패가 같은 프로세스 범위에서 관리되는지 확인합니다.	작업별 실패 범위를 분리해야 하는지 확인합니다.
IPC	직접 공유의 동기화 책임을 감당할 수 있는지 확인합니다.	pipe 같은 IPC 경로와 블로킹 가능성을 함께 확인합니다.

IPC와 컨텍스트 스위칭 비용은 왜 선택에 들어가나?

한 줄 답: 프로세스 간 협력에는 pipe 같은 IPC 경로가 필요할 수 있고, 스레드의 직접 공유에는 동기화가 필요하므로 비용의 종류를 함께 말해야 합니다.

프로세스 사이에서 데이터를 주고받을 때는 pipe(7)처럼 커널을 경유하는 단방향 채널을 사용할 수 있습니다. 빈 파이프를 읽거나 가득 찬 파이프에 쓰는 동작은 블록될 수 있으므로, IPC를 선택 기준으로 설명할 때는 전달 경로와 대기 가능성을 함께 말합니다. 스레드는 공유 힙을 바로 사용할 수 있지만, 여러 실행 흐름이 같은 데이터를 다룰 때 동기화 설계가 필요합니다.

Linux의 fork(2)는 copy-on-write를 사용하며, 이때의 부담은 부모 페이지 테이블 복제와 자식 task 구조체 생성으로 설명됩니다. CLONE_VM을 사용하는 스레드는 주소 공간을 공유하므로 그 복제를 하지 않습니다.

이 차이는 선택 방향을 보여주지만, 컨텍스트 스위칭 시간을 임의의 시간 수치로 제시하거나 IPC 대역폭을 단정할 근거가 되지 않습니다. 실제 판단은 워크로드와 측정 환경에 따라 달라지므로, 면접 답변에서는 수치보다 비용의 종류와 확인할 조건을 말합니다.

임베디드나 드라이버 맥락에서는 무엇이 달라지나?

한 줄 답: 사용자 공간의 프로세스·스레드 선택과 커널의 인터럽트·워크큐 선택은 층이 다르며, 잠들 수 있는 컨텍스트인지가 먼저입니다.

임베디드나 드라이버 맥락에서는 사용자 공간의 동시성 모델과 커널 실행 컨텍스트를 먼저 분리해서 말합니다. Linux kernel hacking guide는 인터럽트 컨텍스트에서는 잠들 수 없고, 사용자 컨텍스트에서는 잠들 수 있는 작업인지 구분해야 한다고 설명합니다.

워크큐를 예로 들면 Linux kernel workqueue는 BH 작업은 sleep할 수 없다고 설명하며, 일반 워크큐 작업은 프로세스 컨텍스트의 kworker에서 함수를 실행합니다. 따라서 이 맥락의 선택에서는 프로세스냐 스레드냐만 말하지 않고, 작업이 인터럽트 컨텍스트인지 BH 워크큐인지 일반 워크큐인지와 sleep 필요 여부를 연결해 설명합니다.

MMU가 없는 시스템에서는 fork(2)가 ENOSYS를 반환할 수 있으므로, 플랫폼 제약을 확인하지 않고 프로세스를 기본값으로 두면 안 됩니다. 특정 임베디드 제품이나 드라이버 경험으로 확대하지 않고, 운영체제와 플랫폼이 제공하는 실행 조건을 확인하는 기준으로 제시합니다.

면접에서 자주 나오는 함정은 무엇인가?

한 줄 답: 스레드는 항상 빠르고 프로세스는 항상 안전하다고 단정하거나, 공유 메모리의 동기화 책임을 빼면 선택 근거가 약해집니다.

스레드가 항상 빠르다고 말하면 락 경합, 캐시 공유, 언어 런타임 제약을 빠뜨리게 됩니다. 반대로 프로세스가 항상 안전하다고 말해도 fork 뒤 파일 디스크립터가 같은 open file description을 가리킬 수 있고 파일 오프셋을 공유할 수 있다는 조건을 놓치게 됩니다. fork(2)는 이 파일 디스크립터 관계를 설명하므로, 프로세스 격리를 말할 때 공유 파일의 영향도 함께 확인합니다.

멀티스레드 프로그램에서 fork한 뒤에는 자식에 호출 스레드만 남으며, execve 전까지는 async-signal-safe 함수만 안전합니다. 따라서 공유 메모리에는 동기화가 필요 없거나 fork하면 모든 자원이 완전히 분리된다고 단정하지 않고, 어떤 자원을 공유하는지와 실패·대기 범위를 구체적으로 말합니다.

언어 런타임 제약은 해당 언어가 실제 선택 조건일 때만 짧게 언급합니다. Python 면접 맥락이라면 GIL 때문에 CPython은 한 번에 한 스레드만 Python 바이트코드를 실행한다는 제약을 Python glossary — Global Interpreter Lock에 따라 덧붙이며, 이를 다른 언어에 일반화하지 않습니다.

FAQ에서 고르는 기준은 무엇을 보면 되나?

한 줄 답: 데이터 공유 빈도, 장애 격리 필요성, IPC·동기화 비용, 런타임과 플랫폼 제약을 같은 순서로 확인합니다.

FAQ는 특정 회사나 공고의 실제 질문을 재현하는 목록이 아니라, 선택 기준을 빠르게 확인하는 일반 정리입니다. 다음 표에서는 공유 데이터, 장애 격리, IPC, 런타임·플랫폼 제약을 짧게 구분합니다.

질문	일반적인 답
공유 데이터가 잦으면 무엇을 우선 보나?	같은 주소 공간에서 직접 다룰 필요와 동기화 책임을 함께 보고 스레드를 우선 검토합니다.
장애 격리가 필요하면 무엇을 말하나?	작업별 실패 범위를 분리해야 한다면 프로세스를 우선 검토하되, 공유 메모리·파일 사용 여부를 확인합니다.
IPC가 있으면 어떤 비용을 확인하나?	pipe 같은 경로의 단방향 전달과 블로킹 가능성, 스레드의 동기화 필요성을 함께 확인합니다.
GIL·MMU 같은 제약은 언제 언급하나?	Python·CPython 또는 MMU가 없는 플랫폼처럼 해당 조건이 실제 선택을 제한할 때만 언급합니다.