컨텍스트 스위칭은 무엇이며 비용이 발생하는 이유는 무엇인가요?

컨텍스트 스위칭은 CPU가 실행 중인 작업을 멈추고 다른 프로세스나 스레드로 전환하기 위해 현재 실행 상태를 저장하고 다음 작업의 상태를 복원하는 과정입니다. 이 전환 자체는 유용하지만, 실제 일을 하지 않는 오버헤드가 발생합니다.

핵심 개념

• 저장/복원해야 하는 상태에는 레지스터, 프로그램 카운터, 스택 포인터, 메모리 매핑 정보 등이 포함됩니다.
• 프로세스 전환은 주소 공간 전환과 TLB/cache 영향 때문에 스레드 전환보다 더 비쌀 수 있습니다.
• 전환이 잦으면 CPU cache locality가 깨지고 스케줄링 비용이 증가합니다.

동작 방식 또는 판단 기준

이 주제를 이해할 때는 다음 순서로 보면 실무 적용이 쉬워집니다.

1. 무엇을 해결하려는가: 성능, 표현력, 안정성, 접근성 중 어떤 문제를 줄이려는지 확인합니다.
2. 전제 조건은 무엇인가: 정렬 여부, 브라우저 지원, 네트워크 특성, 동시성 조건처럼 성립해야 하는 조건을 점검합니다.
3. 비용은 어디서 발생하는가: 시간 복잡도, 메모리, 캐시, 재시도, 렌더링 비용처럼 병목 지점을 나눠 봅니다.
4. 실패 시 어떤 문제가 생기는가: 잘못 적용했을 때의 버그나 운영 리스크를 함께 고려합니다.

실제 예시

1. Thread A 실행 중 timer interrupt 발생
2. 커널이 A의 레지스터/실행 위치 저장
3. 스케줄러가 Thread B 선택
4. B의 상태 복원
5. CPU가 B 코드 실행 재개

결과: 공정성과 응답성은 좋아지지만, 전환 시간 동안 사용자 코드는 실행되지 않음

실무에서 주의할 점

• 스레드 수를 무작정 늘리면 병렬성이 늘기보다 context switching 비용이 커질 수 있습니다.
• lock 경합이 심하면 스레드가 자주 block/wakeup 되어 전환 비용이 증가합니다.
• I/O 대기와 CPU 사용률을 구분하지 않으면 병목 원인을 잘못 판단할 수 있습니다.

실무 적용 가이드

• CPU-bound 작업은 코어 수에 맞춰 worker 수를 제한합니다.
• 비동기 I/O, event loop, thread pool 크기 조정으로 불필요한 전환을 줄입니다.
• profiling 도구로 runnable thread 수, voluntary/involuntary context switch, CPU cache miss를 관찰합니다.

함께 연결해서 보면 좋은 키워드

Context Switching, Scheduler, Thread, CPU, Performance

정리

컨텍스트 스위칭은 CPU가 실행 중인 작업을 멈추고 다른 프로세스나 스레드로 전환하기 위해 현재 실행 상태를 저장하고 다음 작업의 상태를 복원하는 과정입니다. 다만 개념 자체보다 중요한 것은 적용 조건과 한계를 함께 이해하는 것입니다. 작은 예제에서는 단순해 보여도 실제 서비스에서는 성능, 보안, 유지보수성, 접근성 요구사항이 함께 얽히므로, 문제의 성격을 먼저 파악한 뒤 적절한 도구로 선택하는 것이 좋습니다.