0️⃣ 5줄 요약
- **프로세스(Process)**는 서로 독립된 메모리 공간을 가진 실행 단위입니다.
- **스레드(Thread)**는 같은 프로세스 안에서 메모리를 공유하는 실행 흐름입니다.
- 프로세스는 격리(안전성)가 강점, 스레드는 속도와 자원 효율이 강점입니다.
- 실무에선 보통 “프로세스 여러 개 + 스레드”를 혼합합니다.
- 장애/성능/자원 관점에서 이해하면 튜닝 포인트가 보입니다.
1️⃣ 먼저 상황부터: “왜 갑자기 서버가 전체로 죽었지?”
운영하다 보면 이런 순간이 옵니다.
- 특정 서비스 하나만 느린 게 아니라 전체가 버벅임
- 워커 하나가 죽었는데 전체 서비스가 영향을 받음
- CPU는 널널한데 응답이 밀림
이럴 때 원인을 좁히려면
“이게 프로세스 문제인가? 스레드 문제인가?”를 구분할 줄 알아야 합니다.
2️⃣ 핵심 정의 3개 (딱 필요한 만큼만)
- 프로세스: 운영체제가 관리하는 독립 실행 단위 (주소 공간 분리)
- 스레드: 하나의 프로세스 안에서 실행되는 경량 실행 단위 (메모리 공유)
- 컨텍스트 스위칭: 실행 대상을 바꿀 때 드는 전환 비용 (프로세스가 더 큼)
3️⃣ 한 장으로 보는 차이
| 구분 | 프로세스 | 스레드 |
|---|---|---|
| 메모리 | 서로 완전 분리 | 같은 공간 공유 |
| 안정성 | 하나 죽어도 영향 적음 | 한 스레드 문제 → 전체 영향 가능 |
| 생성 비용 | 비교적 큼 | 비교적 작음 |
| 통신 | IPC 필요 | 공유 메모리 |
| 장점 | 격리, 안정성 | 속도, 효율 |
4️⃣ 실무에서 가장 많이 보는 구조
예시 A) 웹서버 구조
보통 구조는 이렇습니다.
프로세스 여러 개(워커) + 각 워커 내부 스레드
이유:
- CPU 코어 활용을 위해 프로세스를 여러 개 띄움
- 각 프로세스 안에서 스레드로 동시 요청 처리
예:
- Nginx → 마스터 + 워커 프로세스 구조
- Java 서버 → 프로세스 1개 + 스레드풀 다수
- PHP-FPM → 여러 워커 프로세스
실무 포인트:
- 워커 하나 죽어도 전체는 유지 → 프로세스 격리 효과
- 워커 내부는 스레드로 효율 확보
예시 B) 배치/크롤러
CPU 집중 작업:
- 이미지 처리
- 암호화
- 압축
→ 프로세스가 유리한 경우 많음 (코어 분산 + 격리)
I/O 중심 작업:
- HTTP 요청
- DB 조회
- 파일 읽기
→ 스레드/비동기가 효율적
이 차이를 모르고 구조를 설계하면 CPU를 못 쓰거나, 메모리 폭주가 발생합니다.
예시 C) 워드프레스 + DB 장애
디스크가 꽉 찼던 사례를 보면:
- mysqld → 별도 프로세스
- PHP-FPM → 여러 프로세스
- 웹서버 → 별도 프로세스
그런데 디스크가 100% 차니 전부 오류.
여기서 중요한 교훈:
프로세스 격리는 메모리 관점이고,
디스크/CPU는 공용 자원이다.
프로세스 구조만 믿으면 안 됩니다.
자원 모니터링이 핵심입니다.
예시 D) Docker는 프로세스인가?
Docker는 VM이 아닙니다.
- 호스트 커널 공유
- 내부에서 일반 프로세스/스레드 실행
컨테이너가 죽는다는 건 보통
“그 안의 메인 프로세스가 죽었다”는 뜻입니다.
그래서 PID 1 관리가 중요합니다.
5️⃣ 리눅스에서 바로 확인하는 법
프로세스 보기
ps aux | head
스레드까지 보기
ps -eLf | head
특정 PID 스레드 수
ps -o nlwp= -p <PID>
nlwp = 스레드 수
top에서 스레드 모드
top -H
실무에서는 nlwp가 갑자기 늘어나면
스레드 폭주를 의심합니다.
6️⃣ 선택 기준 (운영 관점)
✔ 안정성이 더 중요하다 → 프로세스 비중 ↑
✔ 처리량/공유 데이터가 중요하다 → 스레드 비중 ↑
✔ 대부분은 “혼합 구조”가 정답
튜닝할 때는 이렇게 봅니다:
- 워커 수 = CPU 코어 활용
- 스레드풀 크기 = 동시성 제한
- 메모리 한계 = 프로세스 수와 직결
7️⃣ 자주 하는 오해
❌ 스레드는 무조건 빠르다
→ 동기화/락 경쟁 심하면 오히려 느려짐
❌ 프로세스면 무조건 안전하다
→ 디스크/CPU는 공유 자원
❌ 컨테이너면 완전 격리다
→ 커널은 공유
8️⃣ 장애 대응 체크리스트
- 특정 프로세스만 죽었나, 전체인가?
- 스레드 수(NLWP)가 비정상적으로 늘었나?
- CPU 코어 대비 워커 수 적절한가?
- 스레드풀 제한 설정했는가?
- 디스크/메모리 같은 공용 자원 병목은 아닌가?
9️⃣ 실무에서 얻은 교훈
프로세스 vs 스레드는 시험 문제가 아니라
“격리와 효율의 균형” 문제입니다.
장애가 났을 때:
- 메모리 격리 문제인가?
- 동기화 문제인가?
- 공용 자원 병목인가?
이 질문이 바로 나오면, 대응 속도가 훨씬 빨라집니다.
FAQ
Q1. 프로세스가 무조건 더 안전한가요?
메모리 격리는 강하지만, 디스크/CPU 병목은 같이 영향을 받습니다.
Q2. 스레드는 왜 위험하다고 하나요?
메모리를 공유하기 때문에 동기화 실수나 메모리 오염이 전체 장애로 번질 수 있습니다.
Q3. 요즘은 비동기가 대세 아닌가요?
맞습니다. 하지만 내부적으로는 여전히 스레드/이벤트 루프 구조 이해가 필요합니다.
