같은 시간에 여러 일을 한다는 것

두 개의 축: 동시성과 병렬성

동시성(concurrency)은 여러 작업을 "번갈아 가며 처리해서 마치 동시에 진행되는 것처럼 보이게" 만드는 것이고, 병렬성(parallelism)은 여러 작업을 물리적으로 다른 CPU 코어에서 "실제로 동시에" 실행하는 것입니다. 둘은 다른 질문에 대한 답입니다. 동시성은 "일의 구조를 어떻게 짤 것인가"의 문제이고, 병렬성은 "하드웨어 자원을 어떻게 나눠 쓸 것인가"의 문제입니다.

이 관점에서 보면 이 자료가 다루는 네 가지 기법은 셋과 하나로 갈립니다.

즉 앞의 세 기법(멀티프로세스, Dart isolate, GIL-free 멀티스레드)은 "실제로 동시에 CPU를 쓴다"는 공통점이 있고, 마지막 코루틴/asyncio는 "동시에 도는 것처럼 보이지만 실제로는 한 스레드가 번갈아 처리한다"는 점에서 근본적으로 다릅니다. CPU 연산 자체가 겹쳐 도는 게 아니라, I/O를 기다리는 시간에 다른 작업을 끼워 넣는 것이 핵심입니다.

Multi-process병렬성

운영체제가 만들어주는 가장 기본적인 실행 단위입니다. 각 프로세스는 자신만의 독립된 주소공간(코드, 힙, 스택)을 가지고 있어서 한 프로세스가 다른 프로세스의 메모리를 직접 들여다볼 수 없습니다. OS 스케줄러가 여러 프로세스를 서로 다른 코어에 배치하면 진짜 병렬 실행이 일어납니다.

장점과 비용

• 안전성 — 한 프로세스가 죽어도 다른 프로세스는 영향받지 않습니다.
• 격리 — 메모리를 공유하지 않으므로 race condition 자체가 구조적으로 불가능합니다.
• 비용 — 프로세스 생성은 스레드보다 훨씬 무겁습니다(주소공간, 파일 디스크립터 테이블 등을 복제/재구성). 통신하려면 파이프, 소켓, 공유 메모리 같은 IPC가 필요하고, 이는 함수 호출보다 훨씬 비쌉니다.

언어별 지원

Dart Isolate병렬성

Isolate는 이름 그대로 "격리된" 실행 단위입니다. 겉보기엔 스레드처럼 가볍게 여러 개를 띄울 수 있지만, 본질은 스레드가 아니라 경량화된 프로세스에 더 가깝습니다. 스레드의 정의적 특징은 같은 힙을 공유한다는 것인데, isolate는 정반대로 각자 독립된 힙을 가지고 아무 것도 공유하지 않습니다(share-nothing). 통신은 오직 SendPort/ReceivePort를 통한 메시지 패싱으로만 이루어지며, 이 점에서 Erlang/Elixir의 프로세스나 Actor 모델과 철학적으로 가깝습니다.

왜 이런 설계를 택했는가

공유 메모리 스레드는 빠르지만 race condition과 lock 관리라는 대가를 치릅니다. Dart는 (특히 Flutter의 UI 스레드가 절대 멈추면 안 된다는 요구 때문에) 처음부터 공유 상태 동시성을 언어 차원에서 배제하고, 무거운 계산은 별도 isolate로 보내 메인 isolate(UI)를 절대 막지 않는 쪽을 택했습니다.

언어별 지원

참고: 철학적으로 가장 가까운 것은 Erlang/Elixir의 프로세스, Go의 goroutine + channel 조합입니다. 다만 이들은 이번 비교 대상 언어(C, C++, Python, Dart, Rust)에는 포함되지 않습니다.

Multi-thread병렬성

스레드는 같은 프로세스 안에서 힙과 전역 상태를 공유하는 실행 단위입니다. 프로세스보다 훨씬 가볍게 생성할 수 있고, 데이터를 주고받을 때도 메모리를 그냥 같이 보면 되니 IPC보다 빠릅니다. 대신 그 대가로 여러 스레드가 같은 데이터를 동시에 건드리면 race condition이 생길 수 있고, 락을 잘못 쓰면 deadlock에 빠집니다.

Python의 GIL, 그리고 GIL-free

CPython은 오랫동안 GIL(Global Interpreter Lock) 때문에 한 순간에 하나의 스레드만 Python 바이트코드를 실행할 수 있었습니다. 이는 버그가 아니라 설계 결정이었습니다 — CPython의 레퍼런스 카운팅 기반 메모리 관리를 스레드 세이프하게 만들기 위한 트레이드오프였습니다. 그 결과 CPU-bound 작업에서는 Python 스레드를 아무리 늘려도 코어를 하나만 쓰는 것과 큰 차이가 없었습니다.

Python 3.13부터 GIL을 제거한 free-threaded 빌드(PEP 703)가 도입되었지만, 이는 아직 실험적인 opt-in 빌드입니다. 기본 배포판은 여전히 GIL이 켜져 있고, 3.14에서 "공식 지원" 단계로 올라섰을 뿐 기본값 전환은 한참 뒤의 일입니다. 즉 "Python 스레드는 이제 항상 병렬이다"라고 단정하면 안 됩니다.

python -VV
# ... "free-threading build" 문구가 있는지 확인
import sys
sys._is_gil_enabled()  # False면 이 인터프리터에선 GIL이 꺼져 있음

Rust의 fearless concurrency

Rust는 공유 메모리 스레드의 위험을 런타임이 아니라 컴파일 타임에 막습니다. ownership과 borrow checker가 "두 스레드가 같은 데이터를 동시에 변경 가능한 상태로 접근"하는 코드를 아예 컴파일되지 않게 만듭니다. 그래서 Rust는 이 모델을 "fearless concurrency"라고 부릅니다 — 안전성을 프로그래머의 주의력이 아니라 타입 시스템이 보장한다는 점에서 C/C++/Python과 접근 자체가 다릅니다.

언어별 지원

Coroutine · asyncio동시성

여기서부터는 앞의 세 기법과 완전히 다른 게임입니다. 코루틴/asyncio는 기본적으로 하나의 스레드 위에서 동작합니다. "동시에 실행"되는 게 아니라, 한 작업이 I/O(네트워크 응답, 파일 읽기, DB 쿼리 등)를 기다리는 동안 그 틈에 다른 작업을 실행시켜 번갈아 진행하는 방식입니다. CPU 연산이 겹쳐 도는 것이 전혀 아니라는 점이 핵심입니다.

event loop와 job queue

실행 구조는 대략 이렇습니다: 작업들이 큐에 쌓이고, 이벤트 루프가 큐에서 하나씩 꺼내 실행하다가 await 지점을 만나면 제어권을 루프에 돌려주고, 루프는 다음 작업을 꺼내 실행합니다. async/await는 이 상태 기계(state machine)를 사람이 읽기 쉬운 문법으로 감싼 syntactic sugar입니다.

이 모델이 강력한 이유는 context switching 비용이 거의 0에 가깝기 때문입니다. OS 스레드 전환은 커널 개입이 필요해 비싸지만, 코루틴 전환은 그냥 함수 호출 수준이라 수만 개의 동시 연결(예: 채팅 서버)도 무리 없이 처리할 수 있습니다.

언어별 지원

종합 비교

기법별 특성

언어별 지원 한눈에 보기

O = 표준/기본 지원, 부분 = 문법은 있으나 핵심 요소가 실험적이거나 외부 의존, — = 해당 개념 자체가 없음

함께 알아두면 좋은 개념

위 네 가지 기법을 실전에서 고를 때, 그리고 더 깊이 이해할 때 도움이 되는 배경 지식입니다.