본문 바로가기

멀티태스킹과 컨텍스트 스위칭: 하나의 CPU가 여러 프로그램을 번갈아 실행하는 기술

📑 목차

    멀티태스킹은 “동시에 실행”이 아니라 “아주 빠르게 번갈아 실행”이다

    웹브라우저로 영상을 틀어놓고, 메신저로 대화를 하면서, 문서 작업까지 동시에 하는 일은 흔하다. 많은 사람은 이 상황을 “컴퓨터가 여러 일을 동시에 처리한다”라고 말한다. 그러나 전산학 관점에서 보면, 특히 단일 CPU 코어 기준으로는 “동시에”가 아니라 “매우 짧은 시간 단위로 번갈아 실행”에 가깝다. 이 번갈아 실행을 가능하게 하는 핵심 메커니즘이 **컨텍스트 스위칭(context switching)**이며, 이를 운영체제의 프로세스(process), 스레드(thread), **스케줄링(scheduling)**이 뒷받침한다.
    이 글은 멀티태스킹이 실제로 어떻게 구현되는지, 컨텍스트 스위칭이 왜 필요하며 어떤 비용이 있는지, 그리고 사용자가 느끼는 “버벅임”이나 “렉”이 어떤 상황에서 발생하는지까지 연결해 설명한다.


    멀티태스킹과 컨텍스트 스위칭의 기본 원리

    1) 멀티태스킹이란 무엇인가: 운영체제가 “실행 순서”를 관리하는 방식이다

    멀티태스킹(multitasking)은 여러 프로그램이 동시에 실행되는 것처럼 보이게 만드는 운영체제 기능이다. 운영체제는 CPU 시간을 잘게 쪼개서 여러 작업에 나누어 준다. 이때 작업 단위를 보통 프로세스 또는 더 작은 단위인 스레드로 본다.

    • 프로세스(process): 실행 중인 프로그램의 독립된 실행 단위다. 각 프로세스는 자기만의 메모리 공간을 가진다.
    • 스레드(thread): 프로세스 내부에서 실제 CPU에서 실행되는 흐름 단위다. 한 프로세스에 여러 스레드가 있을 수 있다.

    사용자 입장에서는 “프로그램 여러 개를 켜놓았다”가 프로세스 여러 개를 의미하는 경우가 많고, “프로그램 안에서 여러 일을 동시에 한다”는 것이 스레드 여러 개로 구현되는 경우가 많다.

    2) CPU가 여러 작업을 ‘번갈아’ 실행하는 이유: 한 코어는 한 순간에 한 줄만 실행한다

    단일 CPU 코어는 한 순간에 하나의 명령 흐름만 실행한다. 그럼에도 멀티태스킹이 가능한 이유는 운영체제가 “아주 짧은 시간 동안 A를 실행하고, 다음에는 B를 실행하고, 다시 C를 실행하는” 식으로 빠르게 전환하기 때문이다. 사람이 보기에는 화면과 소리가 끊김 없이 유지되면 “동시에”처럼 느껴진다.

    이 전환 과정에서 반드시 필요한 것이 컨텍스트 스위칭이다. 작업을 바꾸려면 현재 작업의 상태를 저장하고, 다음 작업의 상태를 복원해야 한다.

    3) 컨텍스트 스위칭이란 무엇인가: “작업 상태를 저장하고 불러오는 교대 절차”다

    컨텍스트(context)는 CPU가 어떤 작업을 실행 중이었는지 나타내는 상태 정보다. 대표적으로 다음 정보가 포함된다.

    • 레지스터 값(연산 중간 결과, 주소 등)
    • 프로그램 카운터(다음에 실행할 명령 위치)
    • 스택 포인터(함수 호출과 지역 변수 상태)
    • 프로세스/스레드의 실행 상태와 우선순위 정보

    컨텍스트 스위칭(context switching)은 현재 실행 중인 스레드의 컨텍스트를 저장하고, 다음 실행할 스레드의 컨텍스트를 복원한 뒤 CPU를 넘기는 과정이다.
    이 과정은 운영체제 커널이 수행하며, 하드웨어 타이머 인터럽트 같은 이벤트가 트리거가 되는 경우가 많다.

     

    멀티태스킹과 컨텍스트 스위칭: 하나의 CPU가 여러 프로그램을 번갈아 실행하는 기술
    컨텍스트 스위칭의 핵심 구성요소(레지스터·프로그램 카운터·스택)

    4) 스케줄링이란 무엇인가: 누구에게 CPU 시간을 줄지 결정하는 규칙이다

    운영체제 스케줄러(scheduler)는 어떤 프로세스/스레드를 언제 실행할지 결정한다. 일반 사용 환경에서는 다음 목표를 동시에 만족시키려 한다.

    • 반응성(responsiveness): 마우스 클릭, 키 입력에 빨리 반응해야 한다.
    • 공정성(fairness): 특정 작업이 CPU를 독점하지 않도록 해야 한다.
    • 처리량(throughput): 전체적으로 많은 일을 처리해야 한다.

    그래서 운영체제는 대화형 작업(사용자 입력에 민감한 작업)에 우선순위를 주고, 백그라운드 작업은 비교적 덜 급하게 처리하는 전략을 사용한다. 사용자가 “게임 중에 갑자기 업데이트가 돌아서 렉이 걸린다”라고 느끼는 상황은 스케줄링과 자원 경쟁이 복합적으로 작동한 결과다.

    5) 멀티코어와의 관계: 코어가 많을수록 진짜 동시성이 늘어난다

    코어가 여러 개면 “진짜로 동시에” 실행되는 작업 수가 늘어난다. 예를 들어 4코어 CPU는 이상적으로는 4개의 스레드를 동시에 실행할 수 있다.
    다만 코어가 많아도 컨텍스트 스위칭이 사라지는 것은 아니다. 실행할 스레드가 코어 수보다 많으면, 여전히 코어마다 스레드를 번갈아 실행해야 한다. 즉, 멀티코어는 동시성을 키우지만, 멀티태스킹의 기본 원리인 스케줄링과 컨텍스트 스위칭은 여전히 중요하다.


    실제 사례로 이해하는 컨텍스트 스위칭과 문제 해결

    1) “영상 + 다운로드 + 문서 작업”에서 무슨 일이 벌어지는가

    예를 들어 다음을 동시에 한다고 가정한다.

    • 브라우저로 스트리밍 영상 재생
    • 백그라운드에서 대용량 파일 다운로드
    • 문서 편집 프로그램에서 타이핑

    영상 재생은 일정 주기로 프레임을 처리해야 하므로 지연에 민감하다. 문서 타이핑은 키 입력 반응성이 중요하다. 다운로드는 상대적으로 지연에 덜 민감하지만 네트워크 처리와 디스크 쓰기를 지속적으로 요구한다.
    운영체제는 이 작업들을 스레드 단위로 관리하면서, 각 스레드가 “조금씩 CPU를 쓰고 대기하고 다시 쓰는” 패턴을 반복하게 만든다. 영상이 끊기지 않고, 키 입력이 지연되지 않도록 우선순위를 조절한다.

    2) 컨텍스트 스위칭 비용: “공짜 교대”가 아니다

    컨텍스트 스위칭에는 비용이 있다. 대표적인 비용은 다음과 같다.

    • CPU 레지스터 저장/복원 자체의 오버헤드
    • 캐시(cache) 효율 저하: 작업이 바뀌면 CPU 캐시에 있던 데이터가 덜 쓸모 있어질 수 있다
    • TLB(주소 변환 캐시) 부담: 서로 다른 메모리 맵을 가진 프로세스 간 전환은 주소 변환 효율을 떨어뜨릴 수 있다

    즉, 스레드 수를 무작정 늘리면 “병렬 처리”가 늘어나는 것이 아니라, 오히려 전환 비용 때문에 성능이 나빠질 수 있다. 사용자가 느끼는 “버벅임”은 CPU 연산이 부족해서라기보다, 전환과 자원 경쟁이 증가해 캐시 효율이 떨어지는 상황에서 나타나기도 한다.

     

    프로그램이 많아질수록 스케줄링과 컨텍스트 스위칭이 증가하고, 캐시 미스와 디스크·메모리 경쟁이 겹치면 입력 지연이나 렉이 발생하는 과정을 단계로 정리한 다이어그램
    사용자 체감 지연이 생기는 흐름(스케줄링·컨텍스트 스위칭·자원 경쟁)

    3) 멀티태스킹이 특히 느려지는 대표 상황 3가지

    (1) RAM이 부족해 스왑(페이징)이 발생하는 경우

    RAM이 부족하면 운영체제는 일부 메모리 내용을 디스크로 밀어내고(스왑/페이지아웃), 다시 필요할 때 디스크에서 읽어온다(페이지인). 디스크는 RAM보다 훨씬 느리므로, 이 상황에서는 컨텍스트 스위칭보다 “메모리-디스크 이동”이 지연의 주범이 된다.
    증상은 “CPU 사용률은 높지 않은데도 시스템이 전체적으로 굼뜬다”로 나타날 수 있다.

    (2) 디스크 작업이 몰리는 경우

    영상 편집, 대용량 압축 해제, 백신 검사, 업데이트처럼 디스크 읽기/쓰기가 몰리면, 여러 프로그램이 디스크를 기다리느라 반응이 느려진다. 이때 CPU는 할 일이 없어 보이는데도 사용자 체감은 나쁘다. 원인은 CPU가 아니라 I/O 대기다.

    (3) CPU를 계속 점유하는 백그라운드 작업이 있는 경우

    특정 프로그램이 CPU를 지속적으로 많이 쓰면, 스케줄러가 다른 작업에 시간을 나눠주더라도 대화형 작업의 반응성이 떨어질 수 있다. 특히 게임이나 실시간 작업 중에 이런 일이 발생하면 렉으로 체감된다.

    4) 사용자가 할 수 있는 문제 해결 방법: “작업 수 줄이기”보다 “병목 찾기”가 우선이다

    멀티태스킹이 느릴 때 흔히 “프로그램을 다 끄면 된다”라고 말하지만, 더 실용적인 접근은 병목을 찾는 것이다. 다음 순서가 현실적이다.

    1. 작업 관리자(또는 시스템 모니터)에서 CPU, 메모리, 디스크 점유율을 함께 확인한다.
    2. 메모리 사용률이 지속적으로 높다면, 브라우저 탭/확장 프로그램을 줄이거나 RAM 증설을 고려한다.
    3. 디스크 점유율이 높다면, 업데이트/백신/동기화 프로그램의 실행 시간을 조정하거나 SSD 사용 여부를 점검한다.
    4. 특정 프로세스가 CPU를 과도하게 점유한다면, 해당 프로그램의 설정(백그라운드 동작, 실시간 스캔)을 조정한다.

    핵심은 “컨텍스트 스위칭이 많아서 느린지”보다, “메모리 부족과 I/O 대기가 동반되는지”를 함께 보는 것이다. 컨텍스트 스위칭은 멀티태스킹의 기본 메커니즘이지만, 실제 체감 성능은 자원 경쟁과 결합되어 나타나는 경우가 많다.

    5) 스레드와 프로세스를 늘릴 때의 주의점: 개발자 관점의 흔한 실수

    전산학 관점에서 멀티태스킹을 이해할 때 중요한 교훈이 있다. 작업을 빨리 하려고 스레드를 늘리면, 오히려 다음 문제가 생길 수 있다.

    • 락(lock) 경쟁으로 인해 대기 시간이 증가한다
    • 컨텍스트 스위칭이 늘어 캐시 효율이 떨어진다
    • 스레드 생성/관리 비용이 커진다

    따라서 “멀티스레딩 = 무조건 빠름”이 아니라, 병렬화 가능한 작업인지, 공유 자원이 많은지, I/O 중심인지 등을 고려해야 한다. 비전공자에게는 어렵게 느껴질 수 있지만, 결론은 단순하다. 컴퓨터는 동시에 일을 하는 것처럼 보이지만, 내부에서는 정교한 “교대 규칙”이 작동하고 있으며, 교대가 많아질수록 비용도 증가한다는 점이다.


    멀티태스킹의 실체는 스케줄링과 컨텍스트 스위칭이다

    멀티태스킹은 여러 프로그램을 동시에 실행하는 것처럼 보이게 만드는 운영체제 기술이며, 그 핵심은 스케줄링과 컨텍스트 스위칭이다. 단일 코어에서는 한 순간에 하나의 작업만 실행되므로, 운영체제가 짧은 시간 단위로 작업을 번갈아 실행한다. 컨텍스트 스위칭은 작업 상태를 저장·복원하는 과정이며, 전환이 많아지면 캐시 효율 저하 같은 비용이 발생한다. 실제 체감 성능 문제는 컨텍스트 스위칭 자체뿐 아니라 RAM 부족으로 인한 스왑, 디스크 I/O 대기, 백그라운드 CPU 점유 같은 병목과 결합되어 나타나는 경우가 많다.

    다음으로 이어서 보면 좋은 주제는 두 가지다. 첫째, 가상 메모리와 스왑이 실제 성능에 미치는 영향이다. 둘째, CPU 캐시와 캐시 미스가 왜 “렉”처럼 체감되는지에 대한 메모리 계층 구조 설명이다.