컨텍스트 스위칭 (Context Switch)
쉽게 풀면
한 사람이 동시에 여러 업무를 처리하는 상황을 떠올려 보세요. 보고서를 쓰다가 전화를 받으면, 하던 작업을 어디까지 했는지 메모해두고(저장) 전화 통화에 집중한 뒤, 통화가 끝나면 메모를 보고 다시 보고서 작성을 이어갑니다. CPU도 마찬가지입니다. 하나의 CPU 코어는 사실 한 번에 한 가지 작업만 처리할 수 있지만, 여러 프로그램이 동시에 실행되는 것처럼 보이게 하려고 아주 짧은 시간 단위로 작업을 번갈아 가며 처리합니다. 이때 하던 작업의 진행 상태(레지스터 값, 메모리 주소 등)를 저장하고 다음 작업의 상태를 불러오는 전환 과정을 컨텍스트 스위칭이라고 합니다.
왜 중요한가
컨텍스트 스위칭은 운영체제가 여러 작업을 동시에 처리하는 것처럼 보이게 하는 멀티태스킹·스케줄링의 근간이지만, 그 과정 자체가 CPU 사이클과 캐시 적중률을 소모하는 오버헤드이기도 합니다. 그래서 운영체제·스케줄링 연구뿐 아니라 가상화, 클라우드 컴퓨팅, 실시간 시스템, 최근에는 GPU 및 대규모 병렬 처리 환경에서도 컨텍스트 스위칭 비용을 줄이는 문제가 성능 최적화의 핵심 주제로 자주 다뤄집니다. 특히 마이크로서비스나 컨테이너처럼 작은 실행 단위가 급증하는 최신 시스템에서는 전환 빈도 자체가 늘어나기 때문에, 이를 얼마나 효율적으로 관리하느냐가 시스템 전체의 처리량과 지연 시간을 좌우합니다.
논문에서는 이렇게 쓰입니다
이 문장은 "작업을 너무 자주 전환하면 그 전환 자체에도 시간이 들어 낭비가 생기는데, 제안한 방법은 이 낭비를 줄여 전체 성능을 높였다"는 뜻입니다. 컨텍스트 스위칭은 공짜가 아니라 그 자체로 CPU 시간과 캐시 효율을 갉아먹는 오버헤드이기 때문에, 시스템 설계에서 이를 얼마나 줄이느냐가 중요한 성능 지표가 됩니다.
가상 머신(VM)을 전환할 때는 일반 프로세스 전환보다 저장하고 복원해야 할 상태가 훨씬 많기 때문에 오버헤드가 커집니다. 이 문장은 클라우드·가상화 연구에서 컨텍스트 스위칭 비용이 하드웨어 수준을 넘어 하이퍼바이저의 스케줄링 설계와도 직결되는 문제임을 보여줍니다.
실시간 시스템 분야에서는 전환에 걸리는 절대적인 시간뿐 아니라 그 시간이 얼마나 일정한지(변동성)가 더 중요할 때가 많습니다. 이 예문은 컨텍스트 스위칭이 단순히 "빠르게" 처리되는 것을 넘어 "예측 가능하게" 처리되어야 하는 맥락이 있음을 보여줍니다.
조금 더 깊게 보면
컨텍스트 스위칭의 비용은 크게 직접 비용과 간접 비용으로 나눠 볼 수 있습니다. 직접 비용은 레지스터와 프로그램 카운터 등 CPU 상태를 저장·복원하는 데 드는 시간이고, 간접 비용은 전환 이후 캐시와 TLB(주소 변환 버퍼)가 이전 작업의 데이터로 채워져 있지 않아 발생하는 캐시 미스 증가분입니다. 특히 캐시 오염(cache pollution)으로 불리는 이 간접 비용은 상황에 따라 직접 비용보다 더 클 수 있어, 스케줄링 정책을 평가할 때 단순히 전환 횟수만이 아니라 전환 시점의 캐시 지역성까지 함께 고려하는 연구가 늘고 있습니다. 또한 프로세스 간 전환은 주소 공간 자체가 바뀌므로 스레드 간 전환보다 대체로 비용이 크며, 이 차이가 스레드 기반 설계를 선호하는 이유 중 하나로 자주 언급됩니다.
주의할 점
컨텍스트 스위칭이 잦다고 무조건 나쁜 것은 아닙니다. 프로세스와 스레드를 적절히 번갈아 실행해야 여러 작업이 동시에 진행되는 것처럼 보이는 멀티태스킹이 가능해지기 때문에, 응답성과 오버헤드 사이의 균형을 맞추는 것이 스케줄러 설계의 핵심입니다.