문맥 교환 (Context Switch)

핵심 인사이트 (3줄 요약)

본질: 문맥 교환 (Context Switch)은 다중 프로그래밍 환경에서 CPU가 실행 중이던 프로세스(스레드)의 상태(Context)를 레지스터에서 메모리(PCB/TCB)로 저장하고, 다음 실행할 프로세스의 상태를 메모리에서 레지스터로 복원하는 물리적 전환 작업이다.

가치: 하나의 CPU 코어가 수백 개의 프로그램을 동시에 실행하는 것처럼 보이게 만드는 시분할(Time-sharing) 마법의 핵심 동력이지만, 실행되는 그 찰나의 시간 동안 시스템은 어떠한 유효한 연산도 하지 못하므로 철저한 **'순수 오버헤드(Overhead)'**로 취급된다.

융합: 레지스터 저장/복원이라는 표면적 시간 외에도, 주소 공간(Address Space)이 바뀌며 발생하는 **TLB 플러시(Flush)와 캐시 미스(Cache Miss)의 연쇄 폭발(Cold Cache 현상)**이 성능을 깎아 먹는 가장 거대한 융합적 비용이다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

개념: CPU의 통제권이 프로세스 A에서 프로세스 B로 넘어갈 때, A가 "어디까지 덧셈을 했고, 스택은 어디까지 썼는지"에 대한 모든 CPU 내부 상태(PC, SP, 범용 레지스터 등)를 안전하게 보관(Save)하고, B의 예전 상태를 CPU에 덮어씌우는(Restore) 운영체제 디스패처(Dispatcher)의 핵심 행위다.
필요성: CPU 내부의 레지스터 세트는 오직 한 세트뿐이다. (하드웨어 스레딩 제외). 따라서 A가 쓰던 레지스터 값을 메모리에 피신시켜놓지 않고 B를 덮어씌워 버리면, 나중에 A가 다시 실행될 때 자기가 어디까지 일했는지 영원히 잃어버리게 된다. 문맥 교환은 프로세스들의 '기억상실증'을 막기 위한 필수 생존 수단이다.
💡 비유: 한 명의 요리사(CPU 코어)가 찌개(A)를 끓이다가 갑자기 피자(B) 주문을 처리해야 할 때, **'찌개 냄비를 불에서 내려 선반(PCB)에 보관해 두고, 예전에 만들다 만 피자 반죽(TCB)을 다시 도마(레지스터) 위에 올려놓는 세팅 작업'**과 완벽히 일치한다. 세팅하는 동안 요리는 1초도 진행되지 않는다.
등장 배경: 과거 일괄 처리(Batch) 시스템에서는 하나의 작업이 끝날 때까지 CPU를 독점했으므로 문맥 교환이 거의 없었다. 하지만 인간의 키보드/마우스 입력에 반응하기 위해 1초에 100번씩 강제로 프로세스를 교대시키는 시분할(Time-Sharing) 운영체제(Multics, Unix)가 등장하면서, 이 막대한 교환 비용을 어떻게 최적화할지가 커널 해커들의 최대 난제로 떠올랐다.

  [프로세스 교체 시 문맥 교환의 타임라인 및 오버헤드 발생 구간]

  프로세스 P0       [ 운영체제 커널 (OS) ]            프로세스 P1
  ── 실행 중 ──┐
             │ (인터럽트 또는 시스템 콜 발생)
             ▼
            ┌────────────────────────────────────────────────┐
            │ 1. P0의 상태(PC, 레지스터)를 PCB0에 덤프(Save) │
 순수 오버헤드 │ 2. 스케줄러 알고리즘 구동 (다음 타자 P1 선정)   │ (이 구간 동안
 (1~수십 μs) │ 3. 가상 메모리 매핑 교체 (MMU/TLB Flush)     │  사용자 코드는
            │ 4. P1의 상태를 PCB1에서 CPU로 복원(Restore)   │  단 1줄도 안 돎)
            └────────────────────────────────────────────────┘
                                                             │
                                                           ▼
                                                       ── 실행 재개 ──

[다이어그램 해설] 이 그림은 운영체제 교과서에서 가장 유명한 "X자 교차 다이어그램"이다. 사용자가 느끼는 컴퓨터의 "렉"은 대부분 저 네모 박스(커널 개입 시간)가 비정상적으로 길어지거나 빈번하게 발생할 때 나타난다. 문맥 교환은 필요악(Necessary Evil)이며, 시스템 튜닝의 목적은 이 박스의 면적(시간)을 최소화하거나 발생 횟수를 줄이는 데 있다.

📢 섹션 요약 비유: 이삿짐센터 직원이 이사(문맥 교환)를 할 때마다 짐을 싸고 푸는 시간은 필연적으로 소모됩니다. 이사가 너무 자주 일어나면(스래싱) 직원은 짐 싸고 푸느라 진이 빠져 정작 새집에서 살 시간(유효 연산)이 하나도 없게 됩니다.

Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)

문맥(Context)의 실체: 무엇을 백업하는가?

프로세스가 "살아 숨 쉰다"는 것은 메모리가 아니라 CPU **레지스터(Register)**의 상태로 정의된다.

PC (Program Counter): 다음에 실행할 명령어의 메모리 주소
SP (Stack Pointer) / BP (Base Pointer): 현재 함수 호출의 스택 위치
상태 레지스터 (EFLAGS / CPSR): 연산 결과(Zero, Overflow 등) 플래그
범용 레지스터 (GPR): AX, BX, CX, DX 등 실제 계산 데이터가 담긴 곳
MMU 레지스터 (CR3): 가상 메모리 주소 변환을 위한 페이지 테이블 시작 주소

하드웨어 vs 소프트웨어 문맥 교환

문맥을 PCB에 덤프하는 주체에 따라 역사적으로 2가지 방식이 존재했다.

분류	설명	장점	단점
하드웨어 (Hardware)	CPU 칩(예: Intel 80386의 TSS 태스크 게이트)이 JMP 명령어 한 방에 수십 개의 레지스터를 자동으로 메모리에 쓰고 읽음	코드가 간단하고 안전함	더럽게 느림. 안 써도 되는 레지스터까지 무식하게 다 백업함
소프트웨어 (Software)	OS 커널 디스패처가 어셈블리어로 필요한 레지스터만 `push` / `pop` 하여 스택이나 PCB에 수동으로 백업함	극강의 속도 최적화 가능	코딩이 매우 어렵고 CPU 아키텍처마다 일일이 다 짜야 함

결론: 현대 리눅스와 윈도우는 하드웨어가 제공하는 무거운 원클릭 스위칭(TSS)을 과감히 버리고, 100% OS 차원의 **소프트웨어 문맥 교환(어셈블리 수동 백업)**으로 진화하여 수 나노초 단위의 극한 속도를 쟁취했다.

📢 섹션 요약 비유: 방을 나갈 때 짐을 싸주는 로봇(하드웨어 방식)은 칫솔부터 책상까지 무식하게 다 싸버려서 너무 느립니다. 베테랑 여행객(소프트웨어 OS)은 딱 필요한 짐 3개만 손으로 휙 챙겨서(Push/Pop) 1초 만에 방을 나서는 극강의 효율을 발휘합니다.

Ⅲ. 융합 비교 및 다각도 분석 (Comparison & Synergy)

스레드 문맥 교환 vs 프로세스 문맥 교환 (하늘과 땅 차이)

왜 그토록 스레드(Thread)를 써야 한다고 강조할까? 문맥 교환의 비용(Cost) 차이가 하늘과 땅 차이이기 때문이다.

작업 항목	스레드(Thread) 문맥 교환	프로세스(Process) 문맥 교환
레지스터 백업/복원	함 (PC, SP, 범용 레지스터)	함 (PC, SP, 범용 레지스터)
페이지 테이블(CR3) 교체	안 함 (같은 메모리를 공유하므로)	반드시 함 (새로운 가상 주소 공간으로 변경)
TLB 무효화 (Flush)	안 함 (주소 매핑이 그대로 유효함)	전체 무효화 (모든 캐시 주소 쓰레기 됨)
캐시 온도 (Cache State)	Warm Cache (기존 데이터 재활용 가능)	Cold Cache (0부터 메모리 다시 퍼와야 함)
소요 시간 (대략)	~1 μs (마이크로초) 이내	10 μs ~ 1000 μs (수십~수백 배 느림)

프로세스가 바뀐다는 것은 "이전 놈이 쓰던 가상 주소 0x1000과 다음 놈이 쓰는 가상 주소 0x1000이 가리키는 실제 물리 주소가 완전히 다르다"는 뜻이다. 따라서 CPU 내부에 주소를 매핑해 두었던 초고속 캐시인 TLB(Translation Lookaside Buffer)를 싹 다 지워버려야(Flush) 한다. 이 TLB Flush가 유발하는 후폭풍(캐시 미스 연쇄 폭발)이 문맥 교환의 진짜 숨겨진 뼈아픈 세금이다.

  [ 프로세스 문맥 교환 이후 발생하는 '보이지 않는 지연(Invisible Latency)' ]
  
  [ P1 완료 ] ─(문맥 교환 1μs)─▶ [ P2 시작 ]
                                  │ (여기서부터 진짜 지옥 시작)
                                  │ 1. P2가 명령어 호출 ─▶ TLB Miss 발생 (수십 ns 지연)
                                  │ 2. 메모리에서 데이터 로드 ─▶ L1/L2 Cache Miss 발생 (수백 ns 지연)
                                  │ 3. P2가 정상 속도 궤도에 오를 때까지(Warm-up) 수천 ns 추가 증발

📢 섹션 요약 비유: 스레드 교환이 같은 집 안에서 '형과 동생이 의자만 바꿔 앉는 것(주소 공간 공유)'이라면, 프로세스 교환은 '아예 짐을 빼서 다른 동네의 새집으로 이사를 가는 것(TLB 플러시)'입니다. 새집에서 물건(캐시) 어딨는지 찾느라 며칠을 허비하는 시간이 진짜 무서운 이사 비용입니다.

Ⅳ. 실무 적용 및 기술사적 판단 (Strategy & Decision)

실무 시나리오

Nginx vs Apache (문맥 교환의 나비효과): 과거 Apache 웹 서버는 1만 명의 유저가 들어오면 프로세스나 스레드를 1만 개 띄웠다(Thread-per-request). 결과는 처참했다. CPU는 1만 개의 문맥을 초당 수십만 번 교환하느라 로드율 100%를 찍고 장렬히 전사했다(C10K Problem).
- 아키텍처 혁명: Nginx나 Node.js는 이 무식한 문맥 교환을 없애기 위해, 코어 수만큼(예: 8개) 워커 프로세스를 띄워놓고 이벤트 루프(Event Loop, epoll / kqueue)를 통해 1개의 스레드가 1만 명의 소켓을 비동기(Non-blocking)로 빙빙 돌며 처리한다. OS가 개입하는 무거운 컨텍스트 스위칭을 유저 스페이스의 가벼운 함수 호출로 대체하여 수백 배의 처리량(Throughput)을 달성했다.
ASID (Address Space ID) 하드웨어 지원 튜닝: 최신 ARM 코어나 Intel CPU는 프로세스가 바뀔 때마다 무식하게 TLB를 다 날려버리지 않는다. TLB 엔트리에 PID와 같은 개념인 ASID (주소 공간 ID) 태그를 붙여둔다.
- 실무 효과: 문맥 교환 시 커널은 "이제부터 ASID 2번 쓴다!"라고 레지스터 숫자 하나만 띡 바꾼다. 예전 P1(ASID 1)이 쓰던 캐시 데이터는 삭제되지 않고 TLB에 안전하게 보존된다. 나중에 P1이 다시 돌아왔을 때 플러시 없이 기존 TLB를 그대로 쓸 수 있어 프로세스 문맥 교환 속도가 스레드 급으로 비약적으로 빨라지는 하드웨어의 기적이 일어났다.

  ┌──────────────────────────────────────────────────────────────────────┐
  │     부하(Load) 급증 시 아키텍트의 문맥 교환 병목 진단 트리           │
  ├──────────────────────────────────────────────────────────────────────┤
  │                                                                      │
  │   [ 리눅스 쉘(Shell)에 `vmstat 1` 또는 `top` 입력 ]                  │
  │                │                                                     │
  │                ▼ 'cs (Context Switch)' 수치와 'sy (System)' 수치 확인│
  │      [ cs가 초당 10만 이상 찍히고, sy(커널)가 us(유저)보다 높다 ]    │
  │       ├─▶ 진단: 전형적인 문맥 교환 스래싱(Thrashing) 상태.           │
  │       │         (스레드가 너무 많거나 락(Lock) 경합이 극심함)        │
  │       ├─▶ 처방: 스레드 풀(Thread Pool) 크기를 CPU 코어 수의          │
  │                 2~3배 이내로 대폭 축소하여 쟁탈전을 소멸시킴.        │
  │       │                                                              │
  │      [ cs는 낮은데, us(유저타임)가 99%를 치고 있다 ]                 │
  │       ├─▶ 진단: 건강한 100% 부하 (순수 애플리케이션 연산 한계).      │
  │       └─▶ 처방: 로직 최적화, 캐시 레이어(Redis) 도입, 스케일 아웃    │
  └──────────────────────────────────────────────────────────────────────┘

[다이어그램 해설] 초보 개발자는 서버가 느려지면 무조건 스레드를 더 찍어낸다(MaxThread 상향). 하지만 이것은 불난 집에 기름을 붓는 격이다. 스레드가 많아지면 문맥 교환 오버헤드(cs)가 기하급수적으로 폭증하여 CPU가 사용자 코드를 단 한 줄도 처리하지 못하고 자리 바꾸는 일만 반복하다 죽는다. 베테랑 아키텍트는 오히려 스레드를 줄여서 컨텍스트 스위칭을 억제함으로써 전체 처리량(TPS)을 방어한다.

📢 섹션 요약 비유: 좁은 주방에 주문이 밀린다고 요리사를 100명 집어넣으면(스레드 폭증), 요리사끼리 자리 비켜주고 도마 비켜주느라(문맥 교환) 음식은 하나도 안 나옵니다. 차라리 정예 요리사 4명만 남기고 문을 걸어 잠근 뒤, 각자 하나씩 처음부터 끝까지 집중해서 요리하게 놔두는 것이 식당을 살리는 길입니다.

Ⅴ. 기대효과 및 결론 (Future & Standard)

기대효과

문맥 교환이라는 메커니즘 덕분에, 인간은 1개의 CPU로 음악을 들으며 웹서핑을 하고 컴파일을 돌리는 완벽한 가짜(Illusion) 멀티태스킹의 축복을 누리게 되었다. 이를 시스템적으로 이해하고 최적화하면, 수천만 원짜리 서버의 CPU 이용률을 '순수 연산'으로만 꽉꽉 채워 막대한 클라우드 비용을 절감할 수 있다.

결론 및 미래 전망

문맥 교환은 OS 스케줄러가 존재하는 한 피할 수 없는 '죽음과 세금' 같은 존재다. 지난 30년간 인류는 이 세금을 줄이기 위해 프로세스에서 스레드로, 스레드에서 다시 유저 레벨의 코루틴(Coroutine, Goroutine)으로 실행 단위를 쪼개며 커널 개입을 배제(Kernel Bypass)하는 방향으로 도망쳐 왔다. 미래의 멀티코어 환경에서는 코어 수가 수백 개를 넘어가면서, 아예 프로세스를 교체하지 않고 각 코어에 태스크를 1:1로 영구 박제(Pinning)시킨 뒤 네트워크로 데이터를 쏴주는 유니커널(Unikernel)이나 DPDK(Data Plane Development Kit) 같은 "제로 문맥 교환 (Zero Context Switch)" 아키텍처가 초고속 데이터센터의 핵심 표준으로 정착하고 있다.

📢 섹션 요약 비유: 교대 근무(문맥 교환) 시간을 어떻게든 줄이려고 훈련을 거듭하던 공장은, 이제 아예 직원 한 명을 기계 한 대에 평생 묶어두고(코어 핀 고정) 자리를 바꿀 일 자체를 0으로 만들어버리는 궁극의 자동화 공장(제로 스위치)으로 진화했습니다.

📌 관련 개념 맵 (Knowledge Graph)

개념 명칭	관계 및 시너지 설명
디스패처 (Dispatcher)	스케줄러가 결정을 내리면, 이 문맥 교환(레지스터 저장/복원)을 실제로 행동에 옮기는 커널의 하청 노동자다.
TLB 플러시 (TLB Flush)	프로세스 단위의 문맥 교환 시 발생하는 가장 끔찍한 오버헤드로, 주소 공간 변경에 따른 캐시 초기화 재앙이다.
PCB (Process Control Block)	문맥 교환 시 CPU에서 쫓겨나는 프로세스의 레지스터 상태와 영혼(Context)이 고스란히 저장되는 커널 내부의 일기장이다.
타임 퀀텀 (Time Quantum)	라운드 로빈에서 이 시간이 너무 짧아지면, 연산은 못 하고 문맥 교환만 미친 듯이 일어나 시스템이 죽는 스래싱(Thrashing)이 유발된다.
코루틴 (Coroutine / Goroutine)	커널 모드로 진입하는 문맥 교환이 너무 무거워서, 사용자 영역에서 프로그래머가 직접 `yield`하며 가볍게 교체하려고 만든 현대적 탈출구다.

👶 어린이를 위한 3줄 비유 설명

내가 레고를 만들고 있는데 엄마가 잠깐 동생 수학 문제를 봐주라고 불렀어요.
내가 만들던 레고가 어디까지 조립됐는지 사진을 찍어두고(저장), 동생 수학 책을 펴서 며칠 전에 풀다 만 페이지를 찾는(복원) 작업이 문맥 교환이에요.
이 사진 찍고 책을 펴는 시간 동안에는 레고도 못 만들고 수학도 못 푸는 낭비되는 시간이라서, 너무 자주 왔다 갔다 하면 하루 종일 아무것도 못 끝내게 된답니다!