멀티스레딩을 공부하다 보면 자연스럽게 “왜 스레드를 많이 쓰면 오히려 느려질 수도 있을까?”라는 의문이 생긴다. 나도 처음에는 스레드를 많이 쓰면 무조건 빠를 거라고 생각했다. 그런데 실제로 간단한 프로그램을 만들어보면서, 스레드를 늘릴수록 오히려 속도가 떨어지는 상황을 경험했다. 그때 처음으로 ‘컨텍스트 스위칭’이라는 개념을 제대로 찾아보게 됐다.
컨텍스트 스위칭은 CPU가 작업을 바꿀 때 발생하는 비용이다
CPU는 한 번에 하나의 작업만 실행할 수 있다. 물론 멀티코어 CPU라면 여러 작업을 동시에 처리할 수 있지만, 하나의 코어 기준으로 보면 여전히 한 순간에는 하나의 스레드만 실행된다. 그런데 우리는 여러 프로그램이 동시에 실행되는 것처럼 느낀다. 이건 CPU가 아주 빠르게 작업을 번갈아가며 처리하기 때문이다.
이때 작업을 바꾸는 과정이 바로 컨텍스트 스위칭이다. 단순히 “다음 작업으로 넘어간다” 수준이 아니라, 현재 실행 중인 작업의 상태를 저장하고, 새로운 작업의 상태를 불러오는 과정이 포함된다. 예를 들어 레지스터 값, 프로그램 카운터, 스택 정보 같은 것들이 전부 포함된다.
나도 이걸 처음 알았을 때 “그냥 바꾸면 되는 거 아닌가?”라고 생각했는데, 실제로는 꽤 많은 정보가 오가고 있다는 걸 보고 생각보다 무거운 작업이라는 느낌이 들었다.
스레드가 많아질수록 컨텍스트 스위칭이 늘어나면서 성능이 떨어진다
멀티스레딩이 항상 빠르지 않은 이유는 바로 이 컨텍스트 스위칭 때문이다. 스레드가 많아질수록 CPU는 더 자주 작업을 바꿔야 한다. 그만큼 상태를 저장하고 불러오는 작업도 반복된다.
이 과정이 쌓이면, 실제로 일을 하는 시간보다 “작업을 바꾸는 시간”이 더 많아질 수도 있다. 특히 CPU 코어 수보다 훨씬 많은 스레드를 사용하는 경우에는 이 현상이 더 심해진다.
나도 간단한 테스트를 해본 적이 있는데, 스레드를 적당히 사용할 때는 성능이 좋아지다가, 일정 수준을 넘기니까 오히려 실행 시간이 길어졌다. 그때는 이유를 몰랐는데, 나중에 보니까 컨텍스트 스위칭 비용이 커진 경우였다.
이걸 경험하고 나서 “멀티스레딩은 많이 쓴다고 좋은 게 아니다”라는 걸 확실히 느꼈다.
그래서 중요한 건 ‘적절한 수’와 구조 설계다
컨텍스트 스위칭을 완전히 없앨 수는 없다. 대신 이를 최소화하는 방향으로 설계를 해야 한다. 가장 기본적인 방법은 CPU 코어 수에 맞게 스레드 수를 조절하는 것이다.
또한 불필요하게 스레드를 생성하고 종료하는 것을 줄이는 것도 중요하다. 그래서 실제 서비스에서는 스레드를 계속 생성하는 대신, 미리 만들어두고 재사용하는 방식(스레드 풀)을 많이 사용한다.
이 개념을 이해하고 나니까, 프로그램 성능을 단순히 “CPU가 빠르냐”로만 판단하면 안 된다는 생각이 들었다. 구조를 어떻게 설계하느냐에 따라 성능이 크게 달라질 수 있다는 걸 느꼈다.
한 줄로 정리하면 컨텍스트 스위칭은 CPU가 작업을 바꾸면서 상태를 저장하고 복원하는 과정에서 발생하는 비용이며, 이 과정이 많아질수록 성능 저하의 원인이 된다.