🤯그게 그거 아닌가? 멀티 프로세스 vs 멀티 스레드

Intro.

지난 게시글에서 프로세스와 스레드에 대해서 알아보았다. 그중 멀티 스레드와 멀티 프로세스의 차이에 대해 살짝 언급했는데 이번 게시글에서 자세히 설명해 보도록 하겠다. 둘 다 한 프로그램에 대한 처리 방식으로서 둘 다 병렬성과 동시성을 위해 사용된다. 무엇을 사용해야 하는지 무조건적인 정답과 오답은 없다. 둘 중 하나를 상황에 맞게 사용하면 된다. (이전 게시글 필독!!)

 

2026.03.10 - [CS] - 💻프로세스? 스레드? 어디서 들어는 봤는데..

---

멀티 프로세스

IT에서 계층을 나누고 객체지향 프로그래밍을 하는 이유는 서로 독립적으로 작용하여 하나에 문제가 생겨도 다른 기능 혹은 전체가 무너지지 않도록 하기 위해서다. 멀티 프로세스를 이용하는 이유도 비슷한 결이라고 생각하면 된다.

 

객체지향의 클래스를 생각해 보자. 부모 클래스가 여러 자식 클래스에 상속해 주는 모습은 익숙할 것이다. 멀티 프로세스도 하나의 부모 프로세스가 여러 개의 자식 프로세스를 만들 수 있다. 이때, 프로세스들은 클래스명처럼 각자 아이디(PID, PPID)를 가지게 되는데, 이를 통해 프로세스끼리 소통할 수 있다.

---

왜 쓸까?

가장 큰 이유는 안정성이다. 아까 말한 이유처럼 하나 죽어도 다른 프로세스나 전체 시스템에 큰 영향을 주지 않고, 메모리끼리 완전 격리된 구조 덕분에 데이터를 주고받기 어렵다는 속박으로 자원 공유 문제로 인한 데이터 오염과 보안상에서 강점을 갖는다.

 

또한 멀티 스레드를 지원하지 않는 언어에서는 병렬성과 동시성 구현은 사실상 멀티 프로세스가 강제된다. 싱글 스레드를 사용하는 대표적인 언어가 JavaScript와 파이썬이다. 심지어 멀티 프로세스는 멀티 스레드에 비해 구현도 간단하다. 신경 써야 할 요소가 적은 것도 있고, 구현의 난이도 자체가 쉽다. 

 

안정성은 곧 신뢰성이다. 멀티 프로세스가 사용되는 예시는 웹 브라우저에서 여러 개의 탭을 사용할 때와 신뢰성이 중요한 서버엔진 (Nginx) 및 AI의 이미지, 데이터 처리에서도 멀티 프로세스 방식을 주로 사용한다. 무겁지만 안전한 느낌이라고 생각하면 쉽다.

 

단일 프로세스와 멀티 프로세스에서 메모리 점유율 차이는 어느정도일까?

사실 동일한 프로그램을 구동한다는 가정하에 메모리 점유율은 당연히 멀티 프로세스 방식이 높을 수밖에 없다. 하지만 생각보다 그렇게 크게 차이가 나지 않는 이유가 있는데, 운영체제는 자원을 효율적으로 사용하기 위해 여러 가지 마법을 부린다.

 

우선, 가상 메모리는 배로 늘어난다. 2개면 2배, 4개면 4배로 정직하게 늘어난다. 가상 메모리에 대해서는 전 프로세스와 스레드에 대한 게시글에서 설명했으니 생략하겠다. 하지만 어디까지나 가상이기 때문에 무한히 늘어나도 상관이 없다. 중요한 것은 물리적 메모리 점유율인데, 같은 프로그램이기 때문에 기본적인 실행 코드는 같기 때문에 CODE 영역은 공유한다. 프로세스끼리 어떻게 공유하나? 라는 의문이 들 수 있다. 운영체제의 페이지 테이블이라는 매핑 시스템을 사용한다.

 

가상 메모리 주소값을 페이지 테이블에서 실제 메모리 주소와 매핑하기 때문에 CODE 영역은 부모 프로세스의 물리적 메모리 주소를 가리키도록 하면 된다. 그리고 읽기만 하고 있을 때는 추가적인 물리적 메모리 공간이 필요하지 않기 때문에 쓸 때만 늘려 쓰는 방식으로 메모리 공간을 절약한다.

 

---

멀티 스레드

멀티 스레드는 하나의 프로세스 안에서 여러 개의 스레드가 동작하는 것을 말한다. 당연히 멀티 프로세스와 비교했을 때 단일 프로세스 안에서 멀티 스레드가 구현되기 때문에 메모리 공간도 적게 차지하고 컨텍스트 스위칭에서 전환 속도가 빠르다는 장점이 있지만, 여러가지 문제 상황이 발생하기도 한다.

 

---

자원 공유로 인한 문제

여러 스레드가 한 프로세스 안에서 같은 자원들을 공유하며 동작을 할 때, 발생할 수 있는 문제들이 많다.

1. 데드락(Deadlock): 서로가 가진 자원을 기다리며 무한 루프에 빠진다.
2. 경쟁 상태: 동기화 문제라고 생각하면 된다. (실행 순서에 따라 결과가 매번 달라짐)
3. 기아 현상: 특정 스레드가 우선순위에 밀려 영원히 자원을 할당받지 못하는 것이다.

 

우선순위 밀린 스레드는 안 쓰면 그만 아닌가?

우선순위가 밀린 스레드가 소프트웨어 서비스의 중요한 기능을 맡고 있다면, 큰 오류가 발생하게 된다. 게다가 스레드가 생긴 시점부터 이미 메모리를 차지하고 있다. 즉, 메모리가 낭비되고 있다는 뜻이다. 가장 무서운 것은 예측 불가능성이다. 남겨진 이 스레드로 인해 무슨 오류가 발생할지 모르고, 특정 기능이 나중에 동작하게 되어 오류를 발생시킬 수도 있다. 예를 들면 응답을 요청받은 스레드가 기아 상태에 빠지면, 제때 응답을 해 주지 못하면, 상대방은 이 기능이 정상적으로 작동하지 않는다고 판단할 수 있다.

 

물론 이런 문제들에 대한 해결 방법들은 이미 존재한다. 시간이 지날수록 우선순위를 높인다든지 뮤텍스, 세마포어 같은 기법들을 통해서 이런 문제들을 미리 예방하고 있기 때문에 해당 문제점들이 멀티 스레드의 단점이 되진 않는다.

 

이러한 문제들은 다음 게시글인 '멀티 스레딩과 성능'에서 더 자세히 다루겠다.

---

왜 쓸까?

우선 자원 공유로 인해 컨텍스트 스위칭은 빠르다는 장점이 있다. 다른 건물로 이사하는 것보다 같은 아파트에서 호수만 바꿔서 이사하는 것이 빠르다는 것을 생각하면 쉽다. 더 빠르고 더 향상된 응답성을 제공한다는 점이 멀티 스레드의 가장 큰 장점이다. 

 

개발자들은 데드락처럼 신경써야 할 문제점들이 많아서 개발자들한테 비용이 큰 것은 멀티 스레드이지만, 반면 운영체제나 하드웨어 입장에서 보면 비용이 적게 드는 것이 멀티 스레드 방식이다. 우선 메모리 공간의 절감은 말할 것도 없고, 프로세스를 생성하거나 삭제하는 속도보다 스레드를 생성하고 삭제하는 속도가 훨씬 빠르다. 또한 단일 프로세스 안에서 여러 스레드가 동작하기 때문에 자원 간 통신 속도도 빠르다. 

 

 OTT 서비스나 유튜브 등 실시간성이 중요한 스트리밍 서비스, 배달 어플, 게임 등에서 멀티 스레드 방식이 자주 쓰인다.

 

---

멀티 프로세스와 멀티 스레드

사실 둘 중 하나의 방식을 선택해야 할 때도 있지만, 최근에는 두 개 모두의 방식을 합쳐서 사용하는 하이브리드 방식도 많다. 뭐가 맞고 틀리고는 없고 각자의 장단점이 확실하기 때문에 서로 단점을 보완하는 방식으로 두 방식 모두 사용하는 것이다.

 

앞서 웹 브라우저와 서버 등을 멀티 프로세스의 방식에서 예로 들었지만, 사실 이 서비스들은 두 방식을 모두 사용하는 하이브리드 방식이다.