Context Switching이란? CPU가 여러 작업을 번갈아 실행할 때 생기는 비용 쉽게 이해하기

브라우저·메신저·서버·백그라운드 작업이 한꺼번에 돌아도 CPU Core 수는 한정적입니다. Core 4개에 Thread 100개면 동시에 전부 돌릴 수 없어 OS가 짧은 시간마다 실행 대상을 바꿉니다. 이때 A를 멈추고 B를 시작하는 것만으로 끝나지 않습니다. A의 진행 상태를 저장하고 B의 이전 상태를 다시 불러와야 합니다. 이처럼 CPU가 Process·Thread를 교체하며 실행 상태를 저장·복원하는 과정을 Context Switching(컨텍스트 스위칭)이라고 합니다.

하던 일을 잠시 멈추고
다른 일을 시작하기 위해
작업 상태를 바꿔 끼운다

업무를 번갈아 하는 사람

보고서·전화·엑셀을 계속 바꾸면 「어디까지 썼지?」「어느 셀이었지?」를 다시 찾습니다. 전환 자체에도 시간이 듭니다. CPU도 Register·Stack·명령 위치 같은 Context(이어서 실행하는 데 필요한 상태)를 저장한 뒤 다른 Context로 Switch합니다.

Time Slice · Concurrency · Parallelism

OS가 Thread에 잠깐씩 CPU를 주는 구간을 Time Slice(Time Quantum)라고 합니다. 전환이 매우 빠르면 사용자는 「동시에」 도는 것처럼 느낍니다. Core가 여러 개면 일부는 진짜 동시에 돌 수 있습니다. Concurrency는 겹쳐 진행하는 구조, Parallelism은 같은 시각에 여러 Core에서 실행하는 축입니다. Core가 늘어도 Runnable Thread가 Core보다 많으면 Switching은 남습니다.

왜 비용인가 · Run Queue

저장·복원·스케줄러·CPU Cache 교란까지 합치면 「업무」가 아닌 전환에 시간이 갑니다. 한 번이 짧아도 Thread가 수천·수만 개면 합산이 커집니다. Thread를 늘리면 Runnable이 늘고 대기열(Run Queue)이 길어질 수 있습니다. CPU 100%여도 「할 일 많음」과 「전환만 바쁨」은 다릅니다. Utilization과 Queue·Latency를 같이 봅니다.

Voluntary · Involuntary · Blocking I/O

Voluntary는 I/O 대기·sleep처럼 스스로 CPU를 양보할 때, Involuntary는 Time Slice 만료·선점으로 강제로 바뀔 때입니다. 후자가 늘면 CPU Contention 신호가 될 수 있습니다. Blocking I/O는 Thread가 기다리며 자리를 잡아 Thread를 많이 두게 만들고, 그만큼 Switch 후보가 늘어납니다.

Thread Pool · CPU Bound · I/O Bound

요청마다 Thread를 새로 만들면 폭증·Thread Leak 위험이 있어 Thread Pool로 상한을 둡니다. 너무 작으면 Queue·Timeout, 너무 크면 Switch·메모리·Connection 경쟁이 커집니다. CPU Bound는 Core 근처가 안전한 출발점이고, I/O Bound는 Core보다 많은 동시성이 유리할 수 있지만 Thread·Socket·메모리 비용은 남습니다. 그래서 비동기 I/O로 「기다리는 동안 Thread를 붙잡지 않기」를 택하기도 합니다.

Node.js · Main Thread · Worker

이벤트 루프는 적은 Thread로 많은 연결을 다루기 쉽지만, OS·라이브러리·Worker 쪽 Switch는 사라지지 않습니다. 브라우저·Node의 Event Loop에서는 OS Switch 대신 Long Task처럼 Main Thread를 오래 막는 문제가 두드러집니다. Web Worker로 넘길 수 있지만 Worker를 무한정 늘리면 다시 Switch·메모리 부담입니다. async/await는 「기다림」을 다루기 쉽게 할 뿐 CPU 작업을 마법처럼 늘려 주지는 않습니다.

Process · Thread · Cache Miss

Process는 주소 공간이 분리되고 Thread는 자원을 더 많이 공유합니다. Process Switch는 보통 더 무겁고, Thread Switch도 Cache를 자주 비우면 비쌀 수 있습니다. 자주 쓰던 데이터가 CPU Cache에 없어 다시 가져오면 Cache Miss가 납니다. 전환이 잦으면 Locality가 깨져 Miss가 늘고 「일」보다 「준비」가 늘 수 있습니다.

Resource Contention · Lock · Adaptive

Resource Contention으로 Runnable·대기 Thread가 늘면 Switch도 늘기 쉽고, Switch가 늘면 CPU가 실제 업무에 덜 쓰여 경합이 심해질 수 있습니다. Lock을 못 받아 잠들면 Switch가 늘 수 있고, Spin은 잠깐 CPU를 돌리며 기다립니다 — Trade-off입니다. Deadlock과는 다른 축입니다. 동시성을 무작정 키우면 Throughput이 꺾이고 Latency가 급등할 수 있어 Adaptive Concurrency·Queueing Theory·Bulkhead·HOL Blocking·Load Shedding이 이어집니다.

줄이는 방법 · 관측

불필요 Thread 축소·비동기 I/O·긴 CPU 작업의 동시성 제한·Lock 범위 축소·적절한 Batch가 대표적입니다. Batch가 너무 크면 Latency·HOL이 커집니다. Switch 수치만 보지 말고 Latency·Throughput·Run Queue·Thread 수·Lock Wait·평소 baseline을 함께 봅니다. 모니터링·로그·분산 추적·프로파일러로 CPU Time과 Wall Time을 구분합니다. 사양만 키우거나 서버만 늘려도 공유 자원·구조가 그대로면 남을 수 있습니다.

자주 묻는 질문

정리

Context Switching = CPU가 작업을 바꾸기 위해 실행 상태를 저장·복원하는 과정입니다. Time Slice로 여러 작업을 나눠 돌리게 해 주지만, 전환·Cache 교란이 쌓이면 비용이 됩니다. Thread 수·Pool·I/O 방식·Lock·동시성 한계를 Resource Contention·Adaptive Concurrency와 함께 봅니다. 자주 바꾸면 CPU Cache에 필요한 데이터가 없어지는 일이 늘 수 있습니다. 이처럼 필요한 데이터가 Cache에 없어 다시 가져오는 상황을 Cache Miss(캐시 미스)라고 합니다.