프로세스와 스레드

[eunji719]

📆 일자: 26년 9월 27일(일)

발제 의도

프로세스와 스레드는 중요한 개념이지만, "프로세스는 실행 중인 프로그램, 스레드는 프로세스 안의 실행 흐름" 정도로만 외우고 넘어가기 쉽습니다.
메모리를 어떻게 나눠 쓰는지, 컨텍스트 스위칭 비용이 왜 다른지까지 이해해야 멀티 프로세스와 멀티 스레드 중 무엇을 고를지 설명할 수 있다고 생각해 발제했습니다.
지난번 교착상태 주제와도 이어지니 함께 떠올리면서 정리해보면 좋겠습니다.

🤔 오늘의 질문

1. 프로세스와 스레드는 각각 무엇이며, 메모리 구조(Code, Data, Heap, Stack) 관점에서 어떤 차이가 있나요?

2. 프로세스 간 컨텍스트 스위칭과 스레드 간 컨텍스트 스위칭은 비용이 어떻게 다르며, 그 이유는 무엇인가요?

3. 멀티 프로세스와 멀티 스레드는 각각 어떤 장단점이 있고, 실제 서비스에서는 어떤 기준으로 선택하나요?

[k9425mino]

1. 프로세스와 스레드는 각각 무엇이며, 메모리 구조(Code, Data, Heap, Stack) 관점에서 어떤 차이가 있나요?

프로세스는 실행 중인 프로그램의 인스턴스로, OS로부터 독립된 가상 주소 공간과 파일 같은 자원을 할당받는 자원 할당의 단위이다. 각 프로세스는 독립된 가상 주소 공간(Code, Data, Heap, Stack)을 가진다. OS는 프로세스마다 PCB(Process Control Block)을 두고 PID, 상태, 레지스터 값, 메모리 정보 등을 관리한다.

스레드는 프로세스 안에서 실제로 실행되는 흐름의 단위이며, 한 프로세스에는 스레드가 하나 이상 있을 수 있다. 같은 프로세스에 속한 스레드들은 프로세스의 자원을 공유하고, 실행에 꼭 필요한 부분만 각자 따로 가진다. OS는 스레드마다 TCB(Thread Control Block)를 두고 관리한다.

메모리 영역	담기는 것	같은 프로세스의 스레드 사이
Code	실행할 명령어	공유
Data	전역 변수, 정적 변수	공유
Heap	실행 중 동적으로 할당한 데이터	공유
Stack	함수 호출 정보, 지역 변수 등	스레드마다 별도

정리하면, 서로 다른 프로세스는 원칙적으로 주소 공간이 분리되어 있다. 반면 같은 프로세스의 스레드들은 Code, Data, Heap을 공유하고 Stack은 각자 가진다. 현재 실행 위치(PC)와 레지스터 상태도 스레드마다 따로 가진다.

스레드끼리는 메모리를 공유하므로 데이터를 쉽게 주고받을 수 있다. 하지만 여러 스레드가 같은 데이터를 동시에 수정하면 문제가 생길 수 있으므로 동기화가 필요하다.

2. 프로세스 간 컨텍스트 스위칭과 스레드 간 컨텍스트 스위칭은 비용이 어떻게 다르며, 그 이유는 무엇인가요?

우선 컨텍스트 스위칭이란, CPU가 실행 중인 작업을 멈추고 다른 작업을 실행할 때, 현재 작업의 상태(Context)를 PCB/TCB에 저장하고 다음 작업의 상태를 불러오는 과정이다. 이 과정에서 CPU는 실제 작업을 하지 못하므로, 컨텍스트 스위칭은 순수한 오버헤드이다.

일반적으로 같은 프로세스 안의 스레드 전환이 서로 다른 프로세스 간 전환보다 비용이 낮다.

두 경우 모두 OS가 현재 실행 상태인 레지스터, 프로그램 카운터 등을 저장하고 다음 실행 주체의 상태를 복원해야 한다. 차이는 주소 공간에 있다.

• 스레드 간 전환: 같은 프로세스라면 Code, Data, Heap과 주소 공간을 그대로 쓰고, 스레드별 레지스터 상태와 스택 사용 위치 등을 바꾼다.
• 프로세스 간 전환: 실행 상태에 더해 주소 공간도 바꿔야 한다. 페이지 테이블 전환과 그에 따른 TLB·캐시 효율 저하가 추가 비용이 될 수 있다.

다만 "스레드 전환은 항상 빠르다"는 뜻은 아니다. 다른 프로세스에 속한 스레드끼리 전환하면 주소 공간 전환이 필요하고, 실제 비용은 OS와 CPU의 최적화, 캐시 상태에 따라 달라진다.

3. 멀티 프로세스와 멀티 스레드는 각각 어떤 장단점이 있고, 실제 서비스에서는 어떤 기준으로 선택하나요?

선택 기준은 작업 사이에 메모리를 얼마나 공유해야 하는지, 하나의 작업이 실패했을 때 어디까지 영향을 받아도 되는지, CPU와 I/O 중 무엇이 병목인지 이다.

방식	장점	단점
멀티 프로세스	주소 공간이 분리되어 장애 격리가 쉽고, 작업별 자원 제한과 독립적인 재시작이 가능	프로세스마다 메모리와 관리 비용이 들고, 데이터 교환에는 IPC가 필요
멀티 스레드	메모리를 공유하므로 데이터 교환이 쉽고, 같은 프로세스 내 전환 비용이 비교적 낮음	공유 데이터를 잘못 다루면 경쟁 상태·교착 상태가 생길 수 있고, 한 스레드의 심각한 오류가 프로세스 전체에 영향을 줄 수 있음

실제 서비스에서는 보통 다음처럼 판단한다.

• 서로 독립적인 요청 처리, 장애 격리, CPU를 많이 쓰는 작업이 중요하면 여러 프로세스를 고려한다.
• 같은 데이터를 자주 사용하고, 네트워크·디스크 대기 중 다른 일을 처리해야 한다면 스레드를 고려한다.
• 두 요구가 함께 있으면 여러 프로세스를 띄우고 각 프로세스 안에서 여러 스레드를 쓰는 방식도 흔하다.

예를 들어 웹 서비스는 워크 프로세스를 여러 개 두어 장애 영향을 줄이고, 각 워커에서 스레드나 비동기 I/O로 동시 요청을 처리할 수 있다. 다만 CPU 작업의 스레드 병렬 실행 가능 여부는 언어 런타임에도 좌우된다. Python의 일반적인 CPython 실행 환경에서는 GIL 때문에 CPU 중심의 Python 코드에 프로세스가 더 적합한 경우가 많다.

[eunji719]

1. 프로세스와 스레드는 각각 무엇이며, 메모리 구조(Code, Data, Heap, Stack) 관점에서 어떤 차이가 있나요?

프로세스는 실행 중인 프로그램의 독립된 인스턴스로, 운영체제로부터 메모리,CPU시간, 디스크 공간 등의 자원을 할당 받는다. 프로세스는 각각 독립된 메모리 공간을 가지며 독립적인 실행 단위로 간주된다. 스레드는 프로세스 내부의 실행 흐름 단위로, 모든 프로세스는 최소 하나의 스레드를 가진다고 볼 수 있다.

메모리 구조 관점에서 보면 프로세스는 크게 Code,Data,Heap,Stack영역으로 나뉜다. Data영역은 프로그램 시작부터 끝까지 유지되는 값이 저장되는 곳이고, Heap영역은 프로그램이 실행 중에 필요할 때 동적으로 할당하는 메모리이고, Stack영역은 함수를 호출할 때 지역변수, 매개변수, 돌아갈 위치 같은 정보가 쌓이는 곳이다.

프로세스끼리는 이 네 영역을 전부 각자 따로 가진다. 프로세스가 여러 개 있을 때, 프로세스끼리는 서로를 건드리거나 접근할 수 없다. 같은 프로세스 안의 스레드끼리는 Code,Data,Heap 메모리를 같이 쓴다. 다만 stack만은 스레드마다도 따로 가진다. 스레드마다 지금 어떤 함수를 실행 중이고 어디까지 진행했는지가 다르기 때문에, 함수 호출 기록과 지역 변수를 담는 스택은 각자 독립적이어야 하기 때문이다.

스레드는 대부분의 메모리를 공유하니까 데이터를 주고받기 아주 쉽고, 새로만들 것도 적어 가볍다. 대신 여러 스레드가 같은 데이터를 동시에 수정하면 꼬일 수 있어 락 같은 동기화 장치를 신경 써야 한다. 그에 비해 프로세스는 메모리가 완전히 분리되어 있어 안전하고 서로 영향을 주지 않지만, 데이터를 주고 받으려면 파이프나 소켓 같은 별도의 통신 방법을 거쳐야 하고, 새로 만드는 비용도 크다.

2. 프로세스 간 컨텍스트 스위칭과 스레드 간 컨텍스트 스위칭은 비용이 어떻게 다르며, 그 이유는 무엇인가요?

CPU는 한번에 하나의 일만 실행할 수 있는데, 여러 프로그램이 동시에 돌아가듯 보이는 이유는 cpu가 짧은 시간 단위로 실행 대상을 번갈아 바꾸기 때문이다. 이때 지금 하던 걸 저장해 두고 다음 상태를 불러오는 작업을 컨텍스트 스위칭이라 부르는데 프로세스는 메모리 공간을 완전히 따로쓰기 때문에 cpu가 바라보는 메모리 지도 자체를 통째로 바꿔야 한다. 또한 다른 프로세스로 넘어가면 캐시에 있던 데이터가 새 프로세스에는 쓸모가 없어 버린다. 따라서 전환 직후에는 한동안 느려져 비용이 크다. 반면 스레드 간 스위칭은 어디까지 실행했고(PC레지스터), 레지스터 값, 스택 위치 정도만 바꾸면 되기 때문에 가볍다.

3. 멀티 프로세스와 멀티 스레드는 각각 어떤 장단점이 있고, 실제 서비스에서는 어떤 기준으로 선택하나요?

멀티 프로세스는 프로그램을 여러개 프로세스로, 멀티 스레드는 하나의 프로세스 안에 스레드를 여러개 두는 방식이다.

멀티 프로세스는 메모리가 완전히 분리되어서 안정적이고 보안 면에서도 한 프로세스가 뚫려도 다른 프로세스의 메모리를 직접 볼 수 없으니 유리하다. 그치만 프로세스를 새로 만들 때마다 공간을 따로 잡아야 하므로 시간도 오래 걸리고 메모리도 많이 먹는다. 또한 앞 질문 처럼 컨텍스트 스위칭 비용도 크고, 프로세스끼리 데이터를 주고받으려면 따로 IPC를 써야 해서 복잡하고 느리다.

멀티스레드는 공유하는 메모리가 많으니깐 만드는 비용도 전환 비용도 적다. 데이터도 같은 메모리에 있어서 통신 수단 없이 바로 주고 받을 수 있어 협업이 쉽다. 그치만 여러 스레드가 같은 데이터를 동시에 수정하면 값이 꼬이는 race condition도 생기고, 이를 막으려고 락을 쓰다 보면 서로 상대를 기다리며 멈추는 데드락이 생길 수도 있다. 이런 버그는 또 가끔 터져서 재현과 디버깅이 매우 어렵고 메모리를 공유하는 만큼 스레드 하나가 심각한 오류를 내면 프로세스 전체가 같이 죽을 수 있다.

실제 서비스에선 뭐가 최우선이냐에 따라 고르면 되는데, 현실에서는 둘을 섞는 경우가 대부분이다. 예를 들어 Nginx는 여러개의 worker프로세스를 띄워 격리와 안정성을 보장하고, 프로세스 안에서는 효율적인 많은 연결을 처리한다. 프로세스로 큰 단위를 나눠 장애를 가두고, 그 안에서는 스레드로 효율을 챙기는 구조이다.

[9ga0]

1. 프로세스와 스레드는 각각 무엇이며, 메모리 구조(Code, Data, Heap, Stack) 관점에서 어떤 차이가 있나요?

프로세스는 실행 중인 프로그램으로, 운영체제로부터 독립적인 메모리 공간과 자원을 할당받습니다. 스레드는 프로세스 안에서 실제 명령을 실행하는 흐름입니다.
서로 다른 프로세스는 Code, Data, Heap, Stack을 포함한 메모리 공간이 분리되어 있습니다. 반면 같은 프로세스의 스레드들은 Code, Data, Heap을 공유하고, 함수 호출 정보와 지역 변수를 저장하는 Stack과 레지스터 상태는 각각 따로 가집니다. 따라서 스레드는 데이터를 쉽게 공유할 수 있지만, 동시에 같은 데이터를 수정하면 경쟁 상태가 발생할 수 있습니다.

쉬운 비유
- 프로세스: 독립된 하나의 회사
- 스레드: 회사 안에서 일하는 직원
- Code: 업무 규칙
- Data·Heap: 직원들이 함께 사용하는 자료실
- Stack: 각 직원의 개인 업무 노트
다른 회사끼리는 자료실을 직접 공유하기 어렵지만, 같은 회사의 직원들은 공동 자료실을 사용할 수 있습니다. 다만 동시에 같은 자료를 수정하면 문제가 생길 수 있습니다.

2. 프로세스 간 컨텍스트 스위칭과 스레드 간 컨텍스트 스위칭은 비용이 어떻게 다르며, 그 이유는 무엇인가요?

컨텍스트 스위칭은 CPU가 실행 중인 작업의 상태를 저장하고 다른 작업의 상태를 불러오는 과정입니다. 일반적으로 프로세스 간 컨텍스트 스위칭이 같은 프로세스의 스레드 간 전환보다 비용이 큽니다.
프로세스가 바뀌면 독립된 메모리 주소 공간과 페이지 테이블을 전환해야 하고, TLB나 CPU 캐시의 효율도 낮아질 수 있기 때문입니다. 반면 같은 프로세스의 스레드는 주소 공간을 공유하므로 주로 레지스터와 Stack 등의 실행 상태를 교체하면 됩니다. 다만 스레드 전환도 실행 상태 저장과 캐시 손실이 발생하므로 비용이 전혀 없는 것은 아닙니다.

쉬운 비유
- 프로세스 전환: 다른 회사로 출근해 새로운 사무실과 자료를 준비하는 것
- 스레드 전환: 같은 회사에서 담당 직원만 바꾸는 것
담당 직원만 바꾸는 편이 일반적으로 준비해야 할 것이 적습니다.

3. 멀티 프로세스와 멀티 스레드는 각각 어떤 장단점이 있고, 실제 서비스에서는 어떤 기준으로 선택하나요?

멀티 프로세스는 메모리가 분리되어 있어 안정성과 장애 격리에 유리하지만, 메모리 사용량과 컨텍스트 스위칭 및 프로세스 간 통신 비용이 큽니다. 멀티 스레드는 메모리를 공유하므로 통신이 빠르고 자원을 효율적으로 사용할 수 있지만, 경쟁 상태와 교착상태 같은 동기화 문제가 발생할 수 있습니다.
실제 서비스에서는 장애 격리와 보안이 중요하면 멀티 프로세스를 우선 고려하고, 데이터를 자주 공유하거나 I/O 요청을 효율적으로 처리해야 한다면 멀티 스레드를 고려합니다. 또한 CPU 작업인지 I/O 작업인지, 사용하는 언어와 운영 환경이 어떤지도 확인해야 합니다. 실제 시스템에서는 두 방식을 함께 사용하는 경우도 많습니다.

---

멀티 프로세스와 멀티 스레드의 장단점)

기준	멀티 프로세스	멀티 스레드
메모리	각각 독립	Code·Data·Heap 공유
안정성	비교적 높음	한 스레드 오류가 전체에 영향 가능
데이터 공유	IPC 필요	공유 메모리로 쉬움
전환 비용	비교적 큼	비교적 작음
메모리 사용량	많음	비교적 적음
동기화 문제	상대적으로 적음	경쟁 상태·교착상태 주의
장애 격리	유리함	불리함

실제 서비스의 선택 기준)

멀티 프로세스가 적합한 경우

• 작업 간 장애를 격리해야 할 때
• 보안상 메모리와 권한을 분리해야 할 때
• 독립적인 작업이 많을 때
• CPU 연산이 많고 여러 코어를 활용해야 할 때
• 한 작업의 오류가 전체 서비스로 퍼지면 안 될 때
  예를 들어 웹 브라우저는 탭이나 기능을 여러 프로세스로 분리하여 특정 탭에 문제가 생겨도 브라우저 전체가 종료될 가능성을 줄입니다.

멀티 스레드가 적합한 경우

• 작업들이 같은 데이터를 자주 공유할 때
• 메모리를 효율적으로 사용해야 할 때
• 네트워크나 파일 입출력 대기가 많을 때
• 빠른 작업 전환이 필요한 경우
• 공유 데이터의 동기화를 안전하게 관리할 수 있을 때
  예를 들어 웹 서버는 여러 사용자의 요청을 여러 스레드로 나누어 처리할 수 있습니다.