프로세스·스레드·실행상태

같은 프로그램을 두 번 실행하면 왜 서로 다른 일이 되는가

같은 주문 처리 프로그램을 별도 프로세스 두 개로 실행하면 각 실행은 서로 다른 주소공간과 실행 상태를 가진다. 한 실행 안에서도 화면 처리와 네트워크 대기를 여러 흐름으로 나눌 수 있다. 정적인 프로그램, 자원을 가진 실행 인스턴스, 그 안의 실행흐름을 구분해야 장애 격리와 동시성 비용을 설명할 수 있다.

프로세스는 실행에 필요한 주소공간과 자원의 경계이고, 스레드는 그 경계 안에서 명령을 진행하는 흐름이다.

먼저 되짚기: 프로그램은 실행 규칙이다

프로그램은 입력과 상태에 따라 컴퓨터가 수행할 명령과 규칙의 표현이었다. 파일에 저장된 프로그램은 아직 실행 중인 상태가 아니다. 운영체제가 메모리와 자원을 배정하고 실행 문맥을 만들 때 프로세스가 된다.

저장된 프로그램이 실행 인스턴스가 된다

저장된 프로그램 파일에 실행 요청이 들어오면 운영체제가 주소공간·자원과 첫 스레드를 만들어 프로세스를 구성한다. 프로세스 안의 공유 자원과 각 스레드의 문맥을 구분한다.

프로세스

프로세스(process)는 독립 주소공간과 자원을 가진 실행 중 프로그램이다. 실행할 코드, 데이터와 메모리, 열린 파일과 통신 연결, 권한, 하나 이상의 실행흐름을 포함한다. 서로 다른 프로세스의 주소공간은 기본적으로 분리되어 한 프로세스의 잘못된 메모리 접근이 다른 프로세스에 곧바로 닿지 않도록 한다. 브라우저의 창·탭 개수는 프로세스 수와 일대일로 같지 않으므로, 창이 늘었다는 사실만으로 별도 자원 경계를 확인하지 않는다.

스레드 전에 프로세스의 자원 경계를 다시 잇는다

프로세스는 독립 주소공간과 운영체제 자원을 가진 실행 인스턴스다. 스레드는 이 자원 경계 안에서 서로 다른 명령 위치와 스택을 갖고 진행한다.

공유와 독립 상태를 나눈다

같은 프로세스의 스레드는 힙·파일을 공유할 수 있지만 명령 위치·레지스터·스택은 각자 가진다. 공유가 빠른 통신을 주는 대신 동기화 책임도 만든다.

힙은 이 설명에서 여러 객체를 두고 스레드들이 같은 객체를 찾을 수 있는 메모리 영역이고, 스택은 함수 호출에서 돌아갈 위치와 호출 중인 값들을 스레드별로 보관하는 영역이다. 함수 A가 함수 B를 부르면 B가 먼저 반환한 뒤 A가 이어지므로 각 호출의 복귀 정보를 구분해야 한다. 공유 주문 객체를 바꾸는 일과 각 스레드가 계산 중인 임시 값은 같은 종류의 상태가 아니다. 다만 스택을 각자 사용한다는 것이 서로 다른 주소공간으로 격리된다는 뜻은 아니다. 일반적인 운영체제 스레드의 스택도 같은 프로세스 주소공간에 놓이므로, 그 안의 값에 대한 주소를 다른 스레드에 넘기면 접근·수명·동기화 문제가 생길 수 있다. 실행 문맥의 구분과 메모리 접근 격리를 구별한다.

스레드

스레드(thread)는 프로세스 자원을 공유하며 독립 실행흐름을 갖는 단위다. 같은 프로세스의 스레드는 코드·힙 메모리·열린 자원을 공유하지만, 다음에 실행할 명령 위치와 함수 호출을 위한 스택, 계산 중 레지스터 상태는 각자 가진다. 공유 덕분에 통신은 빠르지만 경쟁조건의 위험이 생긴다.

실행 준비부터 기다림까지

상자 안의 대상과 화살표의 조건을 함께 읽으세요. 좁은 화면에서는 같은 관계를 세로로 재배치한 도식을 보여 줍니다.

같은 프로세스의 스레드 A·B는 힙·열린 파일을 공유한다. 명령 위치·레지스터·호출 스택은 각각 보관하므로 A의 R1=5를 저장했다가 복원할 때 B의 R1=100과 섞지 않는다. 공유 힙 객체의 변경은 별도 동기화가 필요하다.

스레드는 준비·실행·대기를 오간다 · 상태 따라가기

준비 상태라도 스케줄러가 배정해야 실제 실행한다. 모든 단계에서 스레드 상태·사건·스케줄러의 위치를 유지하며 값과 허용 조건을 함께 확인합니다.

상자 안의 대상과 화살표의 조건을 함께 읽으세요. 좁은 화면에서는 같은 관계를 세로로 재배치한 도식을 보여 줍니다.

실행 가능하지만 CPU 차례를 기다리면 준비, 명령을 수행하면 실행, I/O·잠금 완료를 기다리면 대기다. 운영체제 스케줄러가 CPU를 배정하면 준비에서 실행으로, 기다림이 필요하면 대기로, 대기 조건이 해소되면 다시 준비로 간다. 실행 중 선점되거나 차례를 양보하면 준비로 돌아가며 작업 완료는 종료다. 대기 해소가 즉시 CPU 실행을 보장하지는 않는다.

이 예의 조건

• 실행 가능하지만 CPU 차례를 기다리면 준비, 명령을 수행하면 실행, I/O·잠금 완료를 기다리면 대기다. 운영체제 스케줄러가 CPU를 배정하면 준비에서 실행으로, 기다림이 필요하면 대기로, 대기 조건이 해소되면 다시 준비로 간다. 실행 중 선점되거나 차례를 양보하면 준비로 돌아가며 작업 완료는 종료다. 대기 해소가 즉시 CPU 실행을 보장하지는 않는다.
• 이 원문의 교육용 사례·조건 안에서 상태를 대조합니다. 실제 구축·실험 결과나 원문에 없는 성능 보장을 추가하지 않습니다.

관계도의 보충 설명

원그림의 모든 대상과 설명

대상	원 설명
대상준비	원 설명CPU 차례 기다림
대상실행	원 설명명령 수행
대상대기	원 설명I/O·잠금 결과 기다림
대상종료	원 설명작업 완료

원그림의 모든 관계와 조건

연결	원 라벨·방향
연결준비 → 실행	원 라벨·방향CPU 배정 / 정방향 / 실선
연결실행 → 준비	원 라벨·방향선점·양보 / 정방향 / 실선
연결실행 → 대기	원 라벨·방향대기 필요 / 정방향 / 실선
연결대기 → 준비	원 라벨·방향대기 해소 / 정방향 / 실선
연결실행 → 종료	원 라벨·방향작업 완료 / 정방향 / 실선

예의 값과 변화

관찰·상황	값·보충 정보	변화·이유
준비에서 실행 준비 상태라도 스케줄러가 배정해야 실제 실행한다.	값·보충 정보 스레드 상태: 준비→실행 사건·스케줄러: CPU 배정	변화·이유 준비 대기와 실행을 같은 상태로 세지 않는다.
사건 기다림 실행 중 대기가 필요하면 CPU를 놓고 기다림 상태로 간다.	값·보충 정보 스레드 상태: 실행→대기 사건·스케줄러: 대기 사건 발생	변화·이유 대기 중인 작업을 실행 중으로 표시하지 않는다.
완료 뒤 준비 사건이 끝나도 바로 실행하지 않고 준비로 돌아간다.	값·보충 정보 스레드 상태: 대기→준비 사건·스케줄러: 사건 완료	변화·이유 다시 실행하려면 별도의 CPU 배정이 필요하다.
CPU 재배정 뒤 실행 스케줄러가 준비 스레드에 CPU를 다시 배정한 뒤 실행한다.	값·보충 정보 스레드 상태: 준비→실행 사건·스케줄러: CPU 재배정	변화·이유 대기 해소만으로 생기지 않는 실행 전환을 배정 사건으로 확인한다.
실행 중 두 대안 재배정된 실행에서 선점·양보이면 준비, 작업 완료이면 종료로 갈라진다.	값·보충 정보 스레드 상태: 실행→준비 / 종료 사건·스케줄러: 선점·양보 / 작업 완료	변화·이유 두 대안은 같은 실행 시작점을 비교하며 준비 뒤 자동 종료하는 순서가 아니다.

스레드는 준비·실행·대기를 오간다 · 상태 따라가기

준비 상태라도 스케줄러가 배정해야 실제 실행한다. 모든 단계에서 스레드 상태·사건·스케줄러의 위치를 유지하며 값과 허용 조건을 함께 확인합니다.

상자 안의 대상과 화살표의 조건을 함께 읽으세요. 좁은 화면에서는 같은 관계를 세로로 재배치한 도식을 보여 줍니다.

실행 가능하지만 CPU 차례를 기다리면 준비, 명령을 수행하면 실행, I/O·잠금 완료를 기다리면 대기다. 운영체제 스케줄러가 CPU를 배정하면 준비에서 실행으로, 기다림이 필요하면 대기로, 대기 조건이 해소되면 다시 준비로 간다. 실행 중 선점되거나 차례를 양보하면 준비로 돌아가며 작업 완료는 종료다. 대기 해소가 즉시 CPU 실행을 보장하지는 않는다.

이 예의 조건

• 실행 가능하지만 CPU 차례를 기다리면 준비, 명령을 수행하면 실행, I/O·잠금 완료를 기다리면 대기다. 운영체제 스케줄러가 CPU를 배정하면 준비에서 실행으로, 기다림이 필요하면 대기로, 대기 조건이 해소되면 다시 준비로 간다. 실행 중 선점되거나 차례를 양보하면 준비로 돌아가며 작업 완료는 종료다. 대기 해소가 즉시 CPU 실행을 보장하지는 않는다.
• 이 원문의 교육용 사례·조건 안에서 상태를 대조합니다. 실제 구축·실험 결과나 원문에 없는 성능 보장을 추가하지 않습니다.

관계도의 보충 설명

원그림의 모든 대상과 설명

대상	원 설명
대상준비	원 설명CPU 차례 기다림
대상실행	원 설명명령 수행
대상대기	원 설명I/O·잠금 결과 기다림
대상종료	원 설명작업 완료

원그림의 모든 관계와 조건

연결	원 라벨·방향
연결준비 → 실행	원 라벨·방향CPU 배정 / 정방향 / 실선
연결실행 → 준비	원 라벨·방향선점·양보 / 정방향 / 실선
연결실행 → 대기	원 라벨·방향대기 필요 / 정방향 / 실선
연결대기 → 준비	원 라벨·방향대기 해소 / 정방향 / 실선
연결실행 → 종료	원 라벨·방향작업 완료 / 정방향 / 실선

예의 값과 변화

관찰·상황	값·보충 정보	변화·이유
준비에서 실행 준비 상태라도 스케줄러가 배정해야 실제 실행한다.	값·보충 정보 스레드 상태: 준비→실행 사건·스케줄러: CPU 배정	변화·이유 준비 대기와 실행을 같은 상태로 세지 않는다.
사건 기다림 실행 중 대기가 필요하면 CPU를 놓고 기다림 상태로 간다.	값·보충 정보 스레드 상태: 실행→대기 사건·스케줄러: 대기 사건 발생	변화·이유 대기 중인 작업을 실행 중으로 표시하지 않는다.
완료 뒤 준비 사건이 끝나도 바로 실행하지 않고 준비로 돌아간다.	값·보충 정보 스레드 상태: 대기→준비 사건·스케줄러: 사건 완료	변화·이유 다시 실행하려면 별도의 CPU 배정이 필요하다.
CPU 재배정 뒤 실행 스케줄러가 준비 스레드에 CPU를 다시 배정한 뒤 실행한다.	값·보충 정보 스레드 상태: 준비→실행 사건·스케줄러: CPU 재배정	변화·이유 대기 해소만으로 생기지 않는 실행 전환을 배정 사건으로 확인한다.
실행 중 두 대안 재배정된 실행에서 선점·양보이면 준비, 작업 완료이면 종료로 갈라진다.	값·보충 정보 스레드 상태: 실행→준비 / 종료 사건·스케줄러: 선점·양보 / 작업 완료	변화·이유 두 대안은 같은 실행 시작점을 비교하며 준비 뒤 자동 종료하는 순서가 아니다.

실행 가능하지만 CPU 차례를 기다리면 준비 상태, 실제 명령을 수행하면 실행 상태, 파일·네트워크·잠금 결과를 기다리면 대기 상태로 볼 수 있다. 대기 조건이 끝나면 다시 준비 상태가 된다. 운영체제는 실행할 스레드를 고르고 전환할 때 이전 스레드의 레지스터와 명령 위치를 저장하고 다음 스레드의 상태를 복원한다.

스레드 전환은 유용하지만 공짜가 아니다. 상태 저장·복원에 비용이 들고 캐시 상태도 바뀌며, 너무 많은 스레드는 실행보다 전환과 메모리 사용에 더 많은 자원을 쓸 수 있다.

여기서는 운영체제가 직접 스케줄하는 스레드 두 개가 한 논리 프로세서의 실행 차례를 나눈다고 가정한다. 레지스터 R1은 계산 중인 임시 값을 담는 CPU 저장소의 교육용 이름이다. 여러 논리 프로세서가 있으면 둘이 동시에 실행될 수도 있지만, 다음 예는 한 곳에서 문맥을 바꾸는 과정을 본다. 스레드 A가 R1=5인 상태로 파일 응답을 기다리면 운영체제는 A의 명령 위치와 R1=5를 저장하고 A를 대기로 둔다. 준비된 B의 문맥을 복원해 R1=100으로 B를 실행한다. 파일 응답이 오면 A는 준비가 되고 차례를 얻었을 때 A의 저장값 R1=5와 명령 위치를 복원해 이어간다. B의 100이 A의 임시 계산값을 덮어쓰는 것은 아니지만 두 스레드가 같은 힙 객체를 바꿀 때는 앞 절의 경쟁조건 통제가 필요하다.

PT-1: 격리와 공유 요구로 프로세스·스레드를 고른다

세 작업을 비교한다.

스레드를 많이 만들수록 항상 빨라지는 것은 아니다. 스택 메모리·문맥전환·공유상태 경쟁이 늘 수 있다. 반대로 프로세스를 분리하면 모든 상호영향이 사라지는 것도 아니며 파일·네트워크·DB 같은 공유자원은 남는다.

작업풀은 정한 수의 실행 담당(worker)을 만들어 여러 요청에 재사용하고 남은 요청은 대기열에서 차례를 기다리게 하는 구성이다. 비동기 방식은 외부 응답을 기다리는 동안 실행 흐름을 붙잡아 두지 않고 다른 작업을 진행하다 완료 통지 뒤 이어가는 방식이며 구체 구현은 뒤에서 배운다. 둘은 무제한 요청을 안전하게 수용한다는 뜻이 아니므로 실행과 대기 용량을 함께 제한한다.

교육용 구성에서는 주 서비스의 I/O 작업 담당을 8개, 대기열을 20건, 신뢰하지 않는 플러그인 프로세스를 최대 2개로 제한한다고 가정한다. 이 수용량 계산에서는 요청 1건이 블로킹 I/O 작업 담당 1개를 완료까지 차지하며 처음에는 대기열이 비어 있고 계산 도중 완료되는 요청이 없다고 둔다. 8건 진행은 8개 스레드가 동시에 CPU에서 실행된다는 뜻이 아니다. 일부는 I/O 대기 상태일 수 있다. 비동기 I/O로 요청을 여러 개 진행시키는 구성이라면 스레드 수 8개만으로 요청 한도를 계산하지 않고 진행 중 요청 수를 따로 제한한다. 플러그인 최대 2개는 이 I/O 요청 28건 수용 한도와 별도로 적용한다. I/O 요청 10건이 들어오면 8건이 처리·대기 중이고 2건은 대기열에서 기다린다. 28건이 모두 수용된 상태에서 29번째 요청은 혼잡 응답을 보내며 새 스레드를 만들지 않는다. 플러그인이 종료되면 해당 프로세스만 복구하되 주 서비스의 객체 상태는 직접 공유시키지 않는다. 외부 DB가 허용한 동시 요청은 별도 제한하며 프로세스를 나누었다는 이유로 DB 한도를 넘기지 않는다. 운영 담당은 완료시간·대기열·실행/준비/대기시간·메모리·전환을 함께 측정해 이 교육용 제한값을 조정한다.

상태 추적과 수용량을 따로 계산한다

풀이를 열기 전에 다음을 답해 보자.

1. 논리 프로세서가 한 개인 실행 예에서 A가 파일 응답을 기다리고 B가 CPU 차례를 사용한다. 파일 응답이 왔지만 B가 계속 실행 중이면 A는 준비·실행·대기 중 무엇인가?
2. 앞의 블로킹 I/O 가정에서 요청 18건이 동시에 들어오고 한 건도 완료되지 않았다. 작업 담당이 맡은 수, 대기열 수, 추가로 수용할 수를 계산하라.
3. 별도 플러그인 프로세스가 DB 연결 한도를 모두 사용했다. 주 서비스는 다른 프로세스라는 이유만으로 같은 DB에 추가 연결해도 되는가?

CPU 차례·요청 한도·공유 자원을 구분하기

1번의 A는 준비다. 파일 기다림은 끝났지만 실행하려면 스케줄러의 CPU 배정이 더 필요하다.

2번은 담당 8건, 대기열 10건, 추가 수용 가능 10건이다. 수용 한도 28건에서 이미 받은 18건을 뺀다. 담당 8건의 운영체제 상태가 모두 실행일 필요는 없다. 추가 11건을 한꺼번에 받으면 10건까지 수용하고 마지막 1건은 혼잡 응답으로 거절한다.

3번은 허용되지 않는다. 프로세스 주소공간을 나누어도 같은 외부 DB의 연결·요청 용량은 공유한다. 플러그인과 주 서비스의 외부 사용량을 합쳐 한도를 지켜야 한다.

프로그램·프로세스·스레드를 구분한다

실패 격리가 중요하고 서로 신뢰하지 않는 작업이면 별도 프로세스가 자연스럽다. 같은 상태를 자주 공유하며 가벼운 동시 실행이 필요하면 스레드가 유리할 수 있다. 단, 스레드 수를 요청 수와 그대로 같게 늘리기보다 실제 CPU 수, 대기 비율, 메모리와 전환 비용을 본다.

실패조건과 방어

프로그램과 프로세스 혼동은 파일이 하나이므로 실행 상태도 하나라고 생각하는 경우다. 프로세스별 주소공간·식별자·자원을 관찰한다.

스레드별 메모리가 독립적이라고 가정하면 공유 힙 상태를 동기화 없이 바꾸기 쉽다. 공유 대상과 소유자, 보호 규칙을 명시한다.

과도한 스레드 생성은 처리량보다 문맥 전환·스택 메모리·경쟁을 늘린다. 제한된 작업 풀과 대기열로 유입을 조절한다.

대기를 CPU 부족으로 오판하면 외부 응답을 기다리는 스레드의 문제를 CPU 증설로 해결하려 한다. 실행·준비·대기 시간과 대기 원인을 나눠 측정한다.

프로세스 격리를 완전한 안전으로 오해하면 파일·네트워크·공유 저장소를 통한 상호영향을 놓친다. 모든 공유 자원 경계를 함께 본다.

자체 10점 문제

프로세스와 스레드를 비교하고 실행상태 및 선택기준을 설명하시오.

요구어는 비교, 설명이다. 주소공간·자원 공유·실행흐름·준비/실행/대기와 선택기준을 연결한다.

10점 풀이 방향과 모범답안 보기

10점 답안 목차

1. 프로그램·프로세스
2. 스레드
3. 주소공간·자원 공유
4. 준비·실행·대기
5. 격리·통신·전환 비용

10점 답안 도식

프로세스 공유 경계와 스레드 상태 전이를 재사용한다. 힙·파일 공유와 스레드별 문맥을 비교하고, CPU 차례의 준비와 외부 결과의 대기를 구분한다.

모범답안 축약본: 격리와 공유의 비용을 함께 본다

문제: 프로세스와 스레드를 비교하고 실행상태 및 선택기준을 설명하시오. 프로세스는 독립 주소공간과 운영체제 자원을 가진 프로그램의 실행 인스턴스이고, 스레드는 한 프로세스 안에서 코드·힙·파일 자원을 공유하되 명령 위치·레지스터·스택을 따로 갖는 실행흐름이다. 스레드는 생성·통신 비용이 작지만 공유 상태의 경쟁과 한 결함의 전파 위험이 크고, 프로세스는 격리와 독립 복구에 유리하지만 통신·메모리 비용이 더 든다. 작업은 실행 가능하나 차례를 기다리는 준비, 명령을 수행하는 실행, 파일·네트워크·잠금을 기다리는 대기 상태를 오간다. 선택은 실패 격리, 신뢰경계, 상태 공유 빈도, 통신량과 복구단위로 한다. 요청 수만큼 스레드를 만들지 말고 CPU 수, 대기 비율, 스택 메모리와 문맥 전환을 측정해 작업 풀과 대기열을 제한한다.

자체 25점 문제

플러그인 실행과 대량 I/O 요청을 함께 처리하는 프로세스·스레드 실행구조를 설계하시오.

요구어는 설계다. 신뢰경계와 공유비용, 작업풀·대기열, 관측지표를 구분한다.

25점 풀이 방향과 모범답안 보기

25점 답안 목차

1. 신뢰·장애 격리
2. 프로세스 경계
3. 프로세스 내부 작업풀
4. CPU/IO 대기 비율
5. 공유상태 보호
6. 대기열·동시성 제한
7. 장애 복구단위
8. 전환·메모리·처리량 측정

25점 답안 도식

상자 안의 대상과 화살표의 조건을 함께 읽으세요. 좁은 화면에서는 같은 관계를 세로로 재배치한 도식을 보여 줍니다.

주 서비스는 I/O 작업 담당 8개와 대기열 20건을 두고 플러그인은 별도 프로세스 최대 2개로 제한한다. 10건 입력은 8건 진행·2건 대기, 28건 수용 중 29번째는 혼잡 거절이다. 플러그인은 주 서비스 객체를 직접 공유하지 않지만 DB·네트워크의 외부 동시 요청 한도는 별도로 지켜야 한다.

25점 모범답안

신뢰하지 않는 플러그인은 주소공간과 복구단위를 나누기 위해 별도 프로세스로 두고, 허용 파일·통신·외부 DB 권한도 별도로 제한한다. 같은 계정의 권한을 그대로 물려받으면 프로세스만 나누어도 같은 외부 자료에 접근할 수 있으므로, 주소공간 분리와 권한 제한을 같은 보장으로 쓰지 않는다. 서비스 내부의 I/O 작업은 요청마다 무제한 스레드를 만들지 않고 실제 CPU 수·대기비율·스택 비용을 기준으로 제한된 작업풀과 대기열을 둔다.

같은 프로세스의 스레드가 공유하는 객체는 소유자와 동기화 규칙을 명시한다. PT-1처럼 프로세스 격리 뒤에도 DB·파일·네트워크 공유가 남으므로 별도 용량·오류 전파를 통제한다.

실행·준비·대기 시간, 문맥전환, 메모리, 처리량을 측정해 풀 크기를 조정하고 플러그인 장애가 주 서비스 프로세스를 종료시키지 않는지 검증한다.

앞의 가정에서는 I/O 작업 담당 8개와 대기열 20건, 플러그인 별도 프로세스 최대 2개를 채택한다. 10건 입력에서 8건 진행·2건 대기, 28건 수용 중 29번째 혼잡 거절을 확인하며 플러그인 강제 종료에도 주 서비스가 유지되는지 시험한다. 공유 주문 변경은 한 소유자와 보호 경계로 제한하고 외부 DB 동시 요청은 별도 한도로 통제한다. 요청마다 새 스레드를 만드는 대안은 스택·전환·공유 경쟁과 무제한 유입 때문에 제외하며, 제한 뒤에도 목표 완료시간을 못 맞추면 실제 대기 원인을 측정해 풀과 외부 용량을 다시 판단한다.

출처와 적용 경계

본문은 안정된 운영체제 프로세스·스레드 기초와 자체 작업선택 예를 사용한다. 창·탭과 프로세스 공유 및 별도 접근 제한은 Chromium 공식 Multi-process Architecture의 Sharing·Sandboxing 절, 자식 프로세스가 사용자·그룹 ID를 물려받는 구체 예는 Linux credentials(7)에서 확인할 수 있다. 같은 프로세스의 스레드가 주소공간을 공유하면서 레지스터·스택 문맥을 따로 갖는 구체 운영체제 예는 Microsoft Learn의 About Processes and Threads, 준비된 스레드의 선택과 선점은 Scheduling Priorities에서 확인할 수 있다. 이는 Windows 구현의 예이며 본문의 준비·실행·대기 그림은 학습용으로 단순화한 모델이다. 이 자료만으로 자체 플러그인의 격리 설정이 검증된 것은 아니다. 실제 스케줄러·스레드 모델·비동기 런타임은 운영체제와 언어 구현에 따라 다르다.

30초 정리

1. 프로그램은 저장된 규칙, 프로세스는 주소공간과 자원을 가진 실행 인스턴스다.
2. 스레드는 프로세스 자원을 공유하지만 명령 위치·레지스터·스택을 각자 가진 실행흐름이다.
3. 프로세스는 격리, 스레드는 가벼운 공유에 강점이 있으며 전환·메모리·동기화 비용을 함께 판단한다.

자기교정과 조건 변경

플러그인이 완전히 신뢰된다면? 격리비용과 공유빈도를 다시 비교해 같은 프로세스 구성도 검토할 수 있다.

작업이 순수 CPU 연산이라면? CPU 코어 수를 넘는 worker 증가의 이익과 전환비용을 측정한다.

외부대기가 거의 0이면? 많은 I/O worker를 둘 이유가 줄어들므로 풀 크기를 다시 산정한다.