멀티코어 CPU와 멀티스레드 구조를 공부하다 보면 처음에는 “작업을 많이 동시에 돌릴수록 무조건 좋은 거 아닌가?”라는 생각이 들기 쉽다. 나도 예전에는 CPU 코어와 스레드 숫자가 많아지면 컴퓨터가 그냥 계속 더 빨라지는 줄 알았다. 그런데 실제 운영체제와 CPU 구조를 조금씩 공부하다 보니까, 작업을 여러 개 동시에 처리하는 것 자체에도 꽤 큰 비용이 존재한다는 걸 알게 됐다. 그리고 그 대표적인 비용 중 하나가 바로 Context Switching이다.
처음에는 이름만 봐도 굉장히 어려워 보였다. 그런데 개념 자체는 생각보다 직관적이었다. 쉽게 말하면 CPU가 “지금 하던 작업을 잠시 멈추고 다른 작업으로 갈아타는 과정”이다. 문제는 이 작업 전환이 단순히 버튼 한 번 누르는 수준이 아니라, CPU 내부 상태 전체를 저장하고 다시 복원하는 꽤 무거운 작업이라는 점이었다.
CPU는 작업을 바꿀 때 현재 상태를 전부 기억해야 한다
CPU는 프로그램을 실행할 때 단순히 계산만 하는 게 아니다. 내부에는 현재 실행 중인 위치, 레지스터 값, 메모리 상태 같은 굉장히 많은 정보가 들어 있다.
예를 들어 어떤 프로그램이 계산 중이었다면 CPU는:
- 어디까지 실행했는지
- 현재 변수 값이 무엇인지
- 다음에 어떤 명령어를 실행해야 하는지
같은 상태를 계속 유지해야 한다.
문제는 운영체제가 다른 스레드나 프로세스를 실행시키기로 결정하는 순간 발생한다. CPU는 지금 작업 상태를 어딘가에 저장해두고, 새 작업 상태를 다시 불러와야 한다.
이 과정을 Context Switching이라고 부른다.
나도 처음에는 “저장했다 다시 불러오는 게 그렇게 큰 문제인가?” 싶었다. 그런데 CPU는 워낙 빠르게 움직이기 때문에 이런 작은 작업조차 생각보다 꽤 큰 비용이 될 수 있다는 걸 나중에 이해하게 됐다.
특히 멀티스레드 환경에서는 운영체제가 계속 작업을 바꾸면서 CPU 사용 시간을 분배하기 때문에, Context Switching 자체가 매우 자주 발생할 수 있다.
예전에 브라우저 탭 엄청 많이 띄우고 게임까지 같이 돌렸을 때 컴퓨터가 이상하게 버벅이던 적이 있었는데, 단순히 CPU 사용량 때문만이 아니라 작업 전환 비용 자체도 영향을 줄 수 있다는 걸 알고 꽤 흥미로웠다.
Context Switching은 캐시와 TLB까지 흔들 수 있다
Context Switching이 더 무서운 이유는 단순히 레지스터 저장 정도로 끝나지 않는다는 점이다. CPU는 성능을 높이기 위해 Cache와 TLB 같은 구조를 적극적으로 사용한다.
그런데 작업이 바뀌면 새 프로세스나 스레드는 이전 작업과 전혀 다른 메모리 데이터를 사용할 가능성이 높다. 결국 CPU 캐시(Cache)에 저장되어 있던 데이터 일부가 쓸모없어질 수 있다.
심지어 가상 메모리 주소 변환을 저장하던 TLB도 영향을 받을 수 있다. 즉, 새 작업은 다시 메모리 정보들을 캐시에 채워야 하고, 그 과정에서 추가 지연이 발생하게 된다.
나도 처음에는 Context Switching을 그냥 “CPU 작업 변경” 정도로만 생각했는데, 실제로는 CPU 내부 최적화 구조 전체를 흔드는 작업이라는 걸 알고 꽤 놀랐다.
특히 최신 CPU는 파이프라인, 분기 예측, Out-of-Order Execution 같은 구조를 계속 최적화하면서 최대한 쉬지 않으려고 하는데, Context Switching은 그 흐름 자체를 끊어버릴 수도 있는 것이다.
그래서 서버나 고성능 시스템에서는 “스레드를 많이 만든다”가 항상 좋은 전략은 아니라고 한다. 오히려 너무 많은 스레드는 Context Switching 비용 때문에 전체 성능을 떨어뜨릴 수도 있다는 것이다.
그걸 보고 처음으로 “동시에 처리한다”는 게 단순히 공짜 성능 향상이 아니구나라는 걸 느끼게 됐다.
그래서 운영체제는 최대한 Context Switching을 줄이려고 한다
운영체제 입장에서도 Context Switching은 가능한 줄이고 싶은 비용이다. 왜냐하면 실제 계산을 하는 시간이 아니라, 작업 전환 자체에 CPU 자원이 사용되기 때문이다.
그래서 운영체제 스케줄러는:
- 작업 우선순위 조정
- CPU affinity
- 코어별 작업 분배
같은 다양한 최적화를 사용한다.
예를 들어 가능하면 같은 코어에서 같은 작업을 계속 실행시키려는 경우도 있다. 그래야 캐시와 TLB 정보를 재활용하기 쉽기 때문이다.
나도 예전에는 운영체제가 그냥 프로그램 실행만 관리하는 줄 알았는데, 실제로는 CPU 내부 구조와 캐시 효율까지 고려하면서 굉장히 복잡하게 움직이고 있다는 걸 느끼게 됐다.
특히 현대 서버는 수천~수만 개 요청을 동시에 처리해야 하는 경우도 많기 때문에, Context Switching 비용을 얼마나 줄이느냐 자체가 성능 최적화의 핵심이 되기도 한다고 한다.
이걸 공부하면서 가장 인상 깊었던 건 현대 컴퓨터 성능은 단순히 CPU가 빠르다고 끝나는 게 아니라는 점이었다. 결국 얼마나 불필요한 대기와 전환을 줄이고, CPU가 계속 효율적으로 움직이게 만들 수 있느냐가 훨씬 중요한 시대가 된 것이다.
한 줄로 정리하면 Context Switching은 CPU가 현재 작업 상태를 저장하고 다른 작업 상태를 불러오는 과정이며, 캐시와 메모리 구조까지 영향을 주기 때문에 멀티스레드 환경에서 큰 성능 비용이 될 수 있다.