두 모델을 외워서 나열하는지, 격리·통신·전환 비용·디버깅 난도를 축으로 두고 워크로드에 맞춰 고르는지를 가른다. 후속으로 "그럼 지금 서비스에는 어느 쪽이냐"를 물을 발판이 된다.
멀티 프로세스는 OS가 별도 주소 공간을 할당해 메모리·파일 핸들·시그널을 격리한다. 한 프로세스가 죽어도 다른 프로세스로 장애가 번지지 않는 대신, 통신은 IPC를 거쳐야 해서 메모리 사본과 컨텍스트 전환 비용이 따라온다. 멀티 스레드는 한 프로세스의 힙·전역 메모리를 공유해 전환 비용이 작고 데이터 교환이 빠르지만, 공유 자원에 락·메모리 가시성·경쟁 상태 문제가 함께 들러붙는다. 즉, 격리를 살 거냐 공유 속도를 살 거냐의 비용 구조 차이다.
한 워커의 버그가 다른 사용자 요청까지 죽이는 걸 보고 프로세스로 쪼갠 경험이 있다면, 격리 비용이 어느 순간부터 정당화되는지 사례로 엮을 수 있다
스레드 풀에서 락 경합·데드락을 직접 잡아본 적 있다면, "공유 메모리의 진짜 비용"을 숫자나 디버깅 시간으로 말할 수 있다
Node 클러스터·PM2·Gunicorn worker 같은 운영 설정을 조정해봤다면, 언어 제약이 어떻게 프로세스 모델 선택을 강제하는지로 연결된다
비동기 단일 스레드와 스레드 풀을 같이 써본 경험이 있다면, 두 모델을 섞는 게 일반적임을 구체 사례로 뒷받침할 수 있다
아직 공개된 답변이 없어요. 첫 공개 답변을 남겨보세요.