[OS] Process와 Thread

🧩 Process

현대 운영체제의 가장 거대한 마법은 ‘독점의 환상’을 만들어내는 데 있습니다. 수십 개의 앱이 동시에 돌아가고 있음에도, 각 프로그램은 마치 자신이 CPU 전체를 점유하고 무한한 메모리 공간을 홀로 사용하는 것처럼 행동합니다. 운영체제는 이 가련하고 이기적인 프로그램들에게 Process라는 추상화된 무대를 제공함으로써 이 환상을 현실로 만듭니다. 프로세스는 단순히 실행 중인 프로그램을 넘어 하드웨어 자원을 안전하게 공유하기 위해 설계된 가장 강력한 격리 단위입니다.

운영체제의 격리 설계와 주소 공간

프로세스가 생성되는 순간, 운영체제는 해당 프로세스만을 위한 가상 세계인 ‘가상 주소 공간(Virtual Address Space)’을 할당합니다. 이 공간은 크게 네 가지 영역으로 나뉩니다. 실행될 기계어 코드가 담긴 Text, 전역 변수와 정적 데이터가 위치한 Data, 동적 메모리 할당이 일어나는 Heap, 그리고 함수 호출 정보와 지역 변수를 저장하는 Stack입니다.

이 설계의 핵심은 ‘보호’에 있습니다. A 프로세스는 B 프로세스의 주소 공간을 직접 들여다볼 수 없습니다. 만약 어떤 프로세스가 자신에게 할당되지 않은 메모리 영역을 침범하려 하면, 하드웨어(MMU)와 운영체제는 즉시 이를 차단하고 ‘Segmentation Fault’라는 엄중한 경고와 함께 프로세스를 종료시킵니다. 이러한 엄격한 격리는 한 프로세스의 크래시가 시스템 전체의 붕괴로 이어지는 것을 방지하는 방화벽 역할을 합니다.

프로세스 제어 블록(PCB)의 구조와 역할

운영체제는 수많은 프로세스를 관리하기 위해 각 프로세스의 모든 정보를 기록한 일종의 ‘신분증’을 만듭니다. 이를 PCB(Process Control Block)라고 부릅니다. 커널의 메모리 영역에 저장되는 이 구조체는 프로세스가 잠시 멈췄다가 다시 실행될 때, 이전의 상태를 완벽하게 복원하기 위한 모든 단서를 담고 있습니다.

PCB에는 다음과 같은 핵심 데이터들이 포함됩니다.

• PID (Process Identifier): 시스템 내에서 프로세스를 식별하는 유일한 번호.
• Process State: 생성(New), 준비(Ready), 실행(Running), 대기(Waiting), 종료(Terminated) 중 현재 상태.
• Program Counter (PC): 이 프로세스가 다음에 실행할 명령어의 주소.
• CPU Registers: 누산기, 인덱스 레지스터 등 현재 CPU 내부의 물리적인 상태값.
• Memory Management Information: 페이지 테이블이나 세그먼트 테이블 등 메모리 매핑 정보.

프로세스의 생명 주기와 fork()  

유닉스 계열 시스템에서 새로운 프로세스는 fork() 시스템 콜을 통해 부모 프로세스를 그대로 복사하며 탄생합니다. 이는 자식 프로세스가 부모의 PCB 정보와 메모리 상태를 고스란히 물려받는다는 것을 의미합니다.

#include <stdio.h>
#include <unistd.h>
#include <sys/types.h>

int main() {
    pid_t pid;

    printf("fork() 호출 전. (부모 PID: %d)\n", getpid());

    // 새로운 프로세스 생성 (부모의 메모리 공간 복제)
    pid = fork();

    if (pid < 0) {
        // fork 실패
        fprintf(stderr, "fork failed\n");
        return 1;
    } else if (pid == 0) {
        // 자식 프로세스 코드 영역
        // 자식에게 fork의 반환값은 0입니다.
        printf("저는 자식 프로세스입니다. (PID: %d, 부모 PID: %d)\n", getpid(), getppid());
    } else {
        // 부모 프로세스 코드 영역
        // 부모에게 fork의 반환값은 생성된 자식의 PID입니다.
        printf("저는 부모 프로세스입니다. (PID: %d, 자식 PID: %d)\n", getpid(), pid);
    }

    // 부모와 자식 모두 이 코드를 실행하지만, 각자의 주소 공간에서 실행됩니다.
    printf("프로세스 종료. (PID: %d)\n", getpid());

    return 0;
}

컨텍스트 스위칭의 로우레벨 메커니즘

하나의 CPU 코어는 한순간에 단 하나의 명령어만 실행할 수 있습니다. 그럼에도 우리가 여러 앱을 동시에 사용하는 것처럼 느끼는 이유는 운영체제가 수 밀리초(ms) 단위로 프로세스를 갈아치우는 컨텍스트 스위칭(Context Switching)을 수행하기 때문입니다.

이 과정은 생각보다 훨씬 무겁고 정교한 안무를 필요로 합니다.

1. 인터럽트 발생: 타이머 인터럽트 등이 발생하여 현재 실행 중인 프로세스의 제어권이 커널로 넘어갑니다.
2. 상태 저장: 현재 CPU에 남아있는 레지스터 값들(PC, SP 등)을 현재 실행 중인 프로세스의 PCB에 안전하게 저장합니다.
3. 다음 프로세스 선택: 스케줄러가 다음에 실행할 프로세스를 결정합니다.
4. 상태 복원: 선택된 프로세스의 PCB에서 이전에 저장해두었던 레지스터 값들을 CPU로 다시 로드합니다.
5. 유저 모드 전환: 커널은 제어권을 프로세스에게 넘기고, 프로세스는 마치 멈춘 적 없었다는 듯이 다음 명령어를 실행합니다.

이 과정에서 CPU는 유의미한 연산을 하지 못합니다. 즉, 컨텍스트 스위칭은 멀티태스킹을 위한 필수적인 지출이지만, 동시에 시스템 성능을 갉아먹는 ‘순수 오버헤드’이기도 합니다.

🧩 Thread

프로세스가 독립된 전력과 보안 시설을 갖춘 거대한 ‘공장 부지’라면, Thread는 그 공장 안에서 바삐 움직이는 ‘숙련된 작업자’입니다. 하나의 프로세스라는 울타리 안에서 여러 스레드가 동시에 작업을 수행하며, 이들은 공장의 자재 창고(Heap)와 설계도(Text/Data)를 함께 사용합니다. 이러한 자원 공유 덕분에 스레드는 프로세스보다 훨씬 가볍고 빠르게 생성되며, 데이터 교환 또한 복잡한 통신 과정 없이 메모리를 직접 읽는 것만으로 가능해집니다.

실행 흐름의 공유와 격리

스레드의 본질은 ‘실행 흐름의 분리’에 있습니다. 모든 스레드는 소속된 프로세스의 주소 공간을 공유하지만, 각자가 ‘어디까지 코드를 읽었는지’와 ‘현재 계산 중인 임시 값’은 철저히 분리되어야 합니다.

스레드 간에 공유되는 것과 격리되는 것의 구분은 멀티태스킹의 성능과 안정성을 결정짓는 핵심 설계입니다.

• 공유 영역: 코드(Text), 전역 변수(Data), 동적 할당 메모리(Heap), 열린 파일 핸들 등 프로세스의 자원.
• 격리 영역: 각 스레드만의 독립적인 스택(Stack)과 레지스터 집합(Program Counter 등).

이러한 구조 덕분에 스레드 간의 전환은 프로세스 전환보다 비용이 훨씬 저렴합니다. 페이지 테이블을 통째로 갈아치울 필요 없이 CPU 레지스터 값만 살짝 바꿔주면 되기 때문입니다.

스레드 제어 블록(TCB)과 스택 할당

운영체제 입장에서 스레드는 ‘스케줄링의 최소 단위’입니다. 커널은 프로세스를 관리하기 위해 PCB를 두듯, 스레드를 관리하기 위해 TCB(Thread Control Block)를 유지합니다. TCB는 PCB의 자식 격인 데이터 구조로, 해당 스레드의 실행 상태, CPU 레지스터 값, 그리고 스택 포인터를 기록합니다.

여기서 가장 흥미로운 지점은 스택(Stack)의 배치입니다. 스레드가 생성될 때마다 운영체제는 해당 스레드만을 위한 전용 스택 공간을 프로세스의 주소 공간 내에 할당합니다. 이 공간은 함수 호출 시의 지역 변수와 복귀 주소를 저장하며, 스레드 간의 실행 흐름이 뒤섞이지 않도록 보장하는 최후의 보루가 됩니다.

#include <stdio.h>
#include <stdlib.h>
#include <pthread.h>

// 모든 스레드가 공유하는 전역 변수 (Data 영역)
int shared_counter = 0;

// 스레드가 실행할 함수
void *thread_function(void *arg) {
    char *thread_name = (char *)arg;
    int i;
    // 각 스레드는 자신만의 스택에 지역 변수 i를 가집니다.
    for (i = 0; i < 1000000; i++) {
        // 공유 변수에 동시 접근 (경쟁 상태 발생 가능)
        shared_counter++;
    }
    printf("%s 작업 완료.\n", thread_name);
    return NULL;
}

int main() {
    pthread_t thread1, thread2;

    // 두 개의 스레드 생성
    // 각 스레드는 thread_function을 실행하며, 동일한 shared_counter를 공유합니다.
    pthread_create(&thread1, NULL, thread_function, "Thread 1");
    pthread_create(&thread2, NULL, thread_function, "Thread 2");

    // 스레드가 종료될 때까지 대기 (메인 스레드 블로킹)
    pthread_join(thread1, NULL);
    pthread_join(thread2, NULL);

    // 결과 출력 (동기화가 없다면 2000000이 아닐 수 있음)
    printf("최종 카운터 값: %d\n", shared_counter);

    return 0;
}

멀티스레딩의 비용과 경쟁 상태

공유의 편리함 뒤에는 ‘동기화’라는 혹독한 대가가 따릅니다. 여러 작업자가 하나의 자재 창고에서 동시에 물건을 꺼내려 할 때 충돌이 발생하듯, 멀티스레드 환경에서는 경쟁 상태(Race Condition)가 필연적으로 발생합니다.

수만 명의 사용자가 동시에 접근하는 고부하 시스템에서 데이터 정합성을 유지하는 것은 대단히 어려운 과제입니다. 한 스레드가 공유 변수를 읽고 수정하려는 찰나에 컨텍스트 스위칭이 일어나 다른 스레드가 값을 바꿔버리면, 시스템은 논리적 파국에 직면합니다.

잠금 장치와 병렬성 저하

스레드 안전성(Thread Safety)을 확보하기 위해 뮤텍스(Mutex)나 세마포어(Semaphore) 같은 잠금 장치를 사용하면, 아이러니하게도 스레드의 최대 장점인 ‘병렬성’이 훼손됩니다. 자원을 기다리는 스레드들이 줄을 서게 되면서 CPU는 놀게 되고, 전체 처리량은 급감하는 ‘잠금 경합(Lock Contention)’ 현상이 발생하기 때문입니다.

결국 엔지니어링의 핵심은 ‘얼마나 많은 스레드를 만드느냐’가 아니라, ‘공유 자원을 최소화하면서 어떻게 효율적으로 스케줄링하느냐’에 달려 있습니다.

Cache Pollution

컨텍스트 스위칭의 진짜 비용은 단순히 CPU 레지스터를 저장하고 복원하는 수 마이크로초(μs)의 시간에만 있지 않습니다. 진정으로 뼈아픈 손실은 프로세스가 교체된 직후, CPU가 한동안 ‘멍청해지는’ 현상에서 발생합니다. 이를 Cache Pollution(캐시 오염)이라 부릅니다. 이는 마치 복잡한 설계도를 책상 가득 펼쳐놓고 작업하던 엔지니어가, 강제로 자리를 비웠다 돌아왔을 때 어질러진 책상 위에서 다시 필요한 도구를 찾는 데 한참을 소모하는 것과 같습니다.

CPU 캐시 계층과 로컬리티의 붕괴

현대 CPU는 주 메모리(RAM)의 느린 속도를 극복하기 위해 L1, L2, L3로 이어지는 정교한 캐시 계층 구조를 가집니다. 프로세스가 실행되는 동안, CPU는 ‘참조 국소성(Locality of Reference)’ 원리에 따라 자주 사용하는 데이터와 명령어를 이 빠른 캐시에 가득 채워둡니다. 이 상태를 흔히 캐시가 ‘예열(Warm-up)’되었다고 표현합니다.

하지만 컨텍스트 스위칭이 일어나는 순간, 새롭게 들어온 프로세스는 기존 프로세스가 애써 쌓아둔 캐시 데이터를 밀어내고 자신의 데이터를 채우기 시작합니다. 이 과정에서 기존 프로세스의 ‘워킹 셋(Working Set)’은 파괴됩니다. 가상 메모리 기법이 데이터 복사 비용은 줄여주었을지언정 하드웨어 캐시의 물리적인 오염까지는 막지 못합니다.

컨텍스트 스위칭이 남기는 성능 부채

캐시 오염은 프로세스가 다시 실행될 때 ‘캐시 미스(Cache Miss)’의 폭발적인 증가로 이어집니다. CPU는 데이터를 찾기 위해 캐시보다 수백 배 느린 RAM까지 직접 찾아가야 하며, 이 기간 동안 프로세스의 연산 속도는 평소의 수분의 일 수준으로 곤두박질칩니다.

특히 고부하 환경에서는 미세한 레이턴시 증가가 전체 처리량의 급격한 저하로 이어집니다.

• TLB(Translation Lookaside Buffer) Flush: 주소 변환 정보를 담은 TLB 또한 스위칭 시점에 무효화되거나 교체되어 메모리 접근 효율을 떨어뜨립니다.
• 상태 복구 비용: 캐시가 다시 유의미한 히트율(Hit Rate)을 기록할 때까지 걸리는 ‘콜드 캐시(Cold Cache)’ 구간은 시스템 전체에 보이지 않는 성능 부채를 축적합니다.

과도한 스레드 생성이 위험한 이유  

CPU 코어 수보다 훨씬 많은 스레드를 생성하면 컨텍스트 스위칭 빈도가 잦아지고, 캐시 오염이 만성화됩니다. 결국 CPU는 실제 연산보다 ‘캐시를 채우고 비우는’ 무의미한 작업에 더 많은 전력을 소모하게 됩니다. 이를 ‘쓰레싱(Thrashing)’ 현상의 하드웨어적 관점으로 이해할 수 있습니다.

결국 엔지니어는 소프트웨어의 논리적 격리뿐만 아니라, 하드웨어 캐시라는 물리적 자원이 겪는 ‘마찰’을 최소화하는 방향으로 아키텍처를 설계해야 합니다.

Copy-on-Write

새로운 프로세스를 만드는 fork() 시스템 콜이 호출될 때, 운영체제가 부모 프로세스의 거대한 메모리 공간을 즉시 통째로 복사한다면 시스템은 어떻게 될까요? 수 기가바이트의 메모리를 사용하는 데이터베이스 프로세스가 자식 프로세스를 생성할 때마다 그만큼의 물리 메모리를 추가로 점유하고 복사하는 데 시간을 보낸다면, 현대 컴퓨팅의 기민함은 사라질 것입니다. 운영체제는 이 문제를 해결하기 위해 Copy-on-Write(쓰기 시 복사, 이하 COW)라는 고도의 지연 전략을 사용합니다.

fork() 호출과 가상 메모리의 영리한 관리

COW의 핵심은 “꼭 필요할 때까지 일을 미루는 것”입니다. fork()가 실행되는 순간 운영체제는 물리 메모리를 복사하는 대신 부모 프로세스의 페이지 테이블(Page Table)만을 복제합니다.

결과적으로 부모와 자식 프로세스는 동일한 물리 메모리 페이지를 동시에 가리키게 됩니다. 겉으로는 두 개의 독립된 프로세스가 존재하지만, 실제 하드웨어 레벨에서는 하나의 자원을 공유하고 있는 셈입니다. 이 덕분에 프로세스 생성은 메모리 크기와 상관없이 순식간에 완료됩니다.

페이지 테이블 복제와 쓰기 시점의 물리적 분리

공유는 효율적이지만 위험합니다. 자식 프로세스가 공유 중인 메모리 값을 수정했는데 부모 프로세스의 값까지 바뀌어 버린다면 ‘격리’라는 프로세스의 대전제가 무너집니다. 운영체제는 이를 막기 위해 공유되는 모든 페이지를 ‘읽기 전용(Read-Only)’으로 설정합니다.

진정한 마법은 누군가 데이터를 쓰려고 시도할 때 일어납니다.

1. 페이지 폴트(Page Fault) 발생: 프로세스가 읽기 전용 페이지에 쓰기를 시도하면 하드웨어가 이를 감지하고 예외를 발생시킵니다.
2. 커널 개입: 제어권을 받은 운영체제는 “아, 이 페이지는 COW 설정이 되어 있구나”라고 판단합니다.
3. 지연된 복사: 그제야 운영체제는 해당 페이지만을 물리 메모리의 새로운 영역으로 복사합니다.
4. 페이지 테이블 업데이트: 쓰기를 시도한 프로세스의 페이지 테이블이 새로 복사된 물리 주소를 가리키도록 업데이트하고, 권한을 ‘읽기/쓰기’로 변경합니다.

Redis는 어떻게 중단 없이 스냅샷을 찍을까?

인메모리 데이터베이스인 Redis가 서비스를 중단하지 않고 수십 GB의 데이터를 디스크에 저장(BGSAVE)할 수 있는 비결이 바로 여기에 있습니다. fork()를 통해 자식 프로세스를 만들면 COW 덕분에 메모리 추가 점유 없이 그 시점의 데이터 상태를 고스란히 ‘스냅샷’으로 찍어낼 수 있기 때문입니다.

#include <stdio.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/wait.h>

int main() {
    // 초기 데이터를 가진 변수
    int data = 100;
    pid_t pid;

    printf("fork() 전: data = %d, 주소 = %p\n", data, &data);

    pid = fork();

    if (pid < 0) {
        fprintf(stderr, "fork error\n");
        return 1;
    } else if (pid == 0) {
        // [자식 프로세스]
        // 이 시점까지는 COW에 의해 부모와 동일한 물리 페이지를 공유합니다.
        printf("[자식] 쓰기 전: data = %d, 주소 = %p (부모와 가상 주소 동일)\n", data, &data);
        
        // 자식 프로세스가 값을 수정하는 순간, 페이지 복사(COW)가 발생합니다.
        data = 200;
        printf("[자식] 쓰기 후: data = %d, 주소 = %p (값 변경됨, 새로운 물리 페이지)\n", data, &data);
    } else {
        // [부모 프로세스]
        // 자식이 종료될 때까지 대기하여 출력이 섞이지 않게 합니다.
        wait(NULL); 
        // 부모의 데이터는 자식의 수정에 영향을 받지 않습니다 (격리 보장).
        printf("[부모] 자식 종료 후: data = %d, 주소 = %p (값 유지됨)\n", data, &data);
    }

    return 0;
}

이러한 COW 방식은 프로세스 생성 비용을 획기적으로 낮추었을 뿐만 아니라, 시스템 전체의 메모리 사용 효율을 극대화했습니다. 운영체제는 이처럼 ‘필요할 때만 비용을 지불하는’ 방식을 통해 제한된 하드웨어 자원 위에서 수천 개의 프로세스를 능숙하게 요리합니다.

M:N Scheduling

운영체제가 관리하는 커널 스레드(Kernel Thread)는 강력하지만 비쌉니다. 스레드 하나를 생성할 때마다 약 1MB의 스택 메모리가 할당되고, 컨텍스트 스위칭 때마다 커널 모드 진입이라는 통행료를 내야 합니다. 수만 개의 동시 접속을 처리해야 하는 현대의 백엔드 시스템에서, 접속자마다 커널 스레드를 하나씩 붙여주는 방식은 자원 고갈의 지름길입니다. 이를 해결하기 위해 등장한 것이 바로 유저 레벨 스레드와 커널 스레드를 영리하게 매핑하는 M:N 스케줄링입니다.

커널 스레드와 유저 스레드의 매핑 전략

스레드 모델은 크게 세 가지로 진화해 왔습니다.

1. 1:1 모델: 우리가 흔히 아는 Java(전통적 버전)나 C++의 모델입니다. 유저 스레드 하나가 정확히 커널 스레드 하나에 매핑됩니다. 구현이 단순하고 멀티코어를 활용하기 좋지만, 스레드 생성과 스위칭 비용이 높습니다.
2. N:1 모델: 여러 유저 스레드가 단 하나의 커널 스레드 위에서 돌아갑니다. 스위칭은 매우 빠르지만, 단 하나의 스레드만 블로킹 시스템 콜을 호출해도 모든 스레드가 멈춰버리는 치명적인 단점이 있습니다.
3. M:N 모델: 다수의 유저 스레드를 그보다 적은 수의 커널 스레드에 동적으로 매핑합니다. Go 언어의 Goroutine이나 Java 21의 Virtual Thread가 채택한 방식입니다.

이 모델에서 ‘유저 스레드’는 더 이상 운영체제가 관리하는 대상이 아닙니다. 대신 프로그래밍 언어의 런타임이 스케줄러를 직접 구현하여, 어떤 유저 스레드를 어떤 커널 스레드(워커)에 올릴지 결정합니다.

고루틴과 가상 스레드의 런타임 최적화

M:N 모델의 정수는 ‘Work Stealing’ 알고리즘에 있습니다. 특정 커널 스레드가 할당받은 유저 스레드들을 모두 처리하여 할 일이 없어지면, 바쁘게 돌아가는 다른 커널 스레드의 큐에서 작업을 ‘훔쳐’ 옵니다. 이를 통해 모든 CPU 코어가 놀지 않고 최대한의 효율을 내도록 만듭니다.

이러한 추상화 덕분에 개발자는 ‘스레드 개수’에 대한 공포에서 벗어날 수 있습니다. 고루틴(Goroutine)은 고작 수 KB의 메모리만으로 시작하며, 필요에 따라 스택 크기를 동적으로 늘립니다. Java 21의 가상 스레드(Virtual Thread) 또한 기존의 블로킹 I/O 코드를 그대로 유지하면서도, 내부적으로는 커널 스레드를 점유하지 않고 ‘양보(Yield)’하는 방식으로 수백만 개의 동시 실행 흐름을 가능케 합니다.

M:N 모델의 모니터링 비용

M:N 모델은 성능 면에서 압도적이지만, 문제가 발생했을 때 추적하기 어렵다는 트레이드오프가 있습니다. 특정 유저 스레드에서 발생한 에러가 어떤 커널 스레드의 문맥에서 터진 것인지 파악하기 위해 더 복잡한 모니터링 도구가 필요하기 때문입니다.

// M:N 스케줄링의 효율성을 보여주기 위해, 기존 커널 스레드 방식으로는 불가능한 규모의 동시성을 구현합니다.
// (Java 21 이상 필요)
import java.time.Duration;
import java.time.Instant;
import java.util.concurrent.Executors;
import java.util.stream.IntStream;

public class VirtualThreadDemo {
    public static void main(String[] args) {
        // 10만 개의 동시 작업 수행. 기존 플랫폼 스레드(1:1 모델)로는 메모리 부족(OOM)이 발생할 수 있는 규모입니다.
        int numTasks = 100_000;

        System.out.printf("%d개의 가상 스레드 작업 생성을 시작합니다...\n", numTasks);
        Instant start = Instant.now();

        // Executors.newVirtualThreadPerTaskExecutor()는 각 작업마다 새로운 가상 스레드를 생성합니다.
        // try-with-resources 구문을 사용하면 블록을 빠져나갈 때 executor.close()가 호출되어
        // 제출된 모든 작업이 완료될 때까지 메인 스레드가 대기합니다 (Structured Concurrency).
        try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
            IntStream.range(0, numTasks).forEach(i -> {
                executor.submit(() -> {
                    try {
                        // 각 스레드는 I/O 작업을 시뮬레이션하기 위해 잠시 대기합니다.
                        // 가상 스레드는 블로킹 시 캐리어 스레드(커널 스레드)를 점유하지 않고 '양보(Yield)'합니다.
                        Thread.sleep(Duration.ofMillis(100));
                    } catch (InterruptedException e) {
                        Thread.currentThread().interrupt();
                    }
                });
            });
        } // 여기서 모든 가상 스레드의 작업이 끝날 때까지 기다립니다.

        Instant end = Instant.now();
        System.out.printf("모든 작업이 완료되었습니다. 소요 시간: %d ms\n", Duration.between(start, end).toMillis());
        // 결과적으로 소수의 커널 스레드만으로 10만 개의 논리적 실행 흐름을 효율적으로 처리해냅니다.
    }
}

결국 현대의 실행 모델은 ‘운영체제의 격리(Process)’ 위에서 ‘언어 런타임의 효율(M:N Thread)’을 쌓아 올리는 방향으로 완성되었습니다. 엔지니어는 이제 하드웨어의 제약을 직접 고민하기보다, 자신의 애플리케이션에 어떤 스케줄링 모델이 적합한지를 선택하는 안목을 갖추어야 합니다.

Summary

현대 컴퓨팅은 프로세스가 제공하는 ‘격리’와 스레드가 제공하는 ‘공유’ 사이의 정교한 줄타기입니다. 운영체제는 가상 주소 공간과 PCB를 통해 시스템의 안정성을 확보하는 동시에, Copy-on-Write와 M:N 스케줄링 같은 영리한 전략을 통해 하드웨어 자원을 극단적으로 아껴 씁니다. 하지만 컨텍스트 스위칭이 남기는 캐시 오염과 멀티스레딩의 잠금 경합은 여전히 엔지니어가 극복해야 할 물리적 마찰로 남아 있습니다. 결국 훌륭한 소프트웨어 설계란 추상화 이면의 하드웨어 비용을 정확히 이해하고, 서비스의 부하 특성에 가장 적합한 실행 모델을 선택하는 안목에서 결정됩니다.

References

• [PlanetScale] Processes and Threads
• [OSTEP] Operating Systems: Three Easy Pieces
• [AWS Builders’ Library] Timeouts, retries and backoff with jitter