동시성 프로그래밍은 어렵다. 하지만 동시성 프로그래밍은 멀티코어 시대와 클라우드의 시대에 더욱 중요해지고 있다. 점점 증가하는 동시성 프로그래밍의 요구사항을 충족시키는 데 있어 동시성 프로그래밍의 복잡성은 프로그래머들에게 최대의 적으로 부각되었다. (뭐 여기까지는 다들 아시는 내용이리라 짐작한다)

보통 프로그래머들은 동시성 프로그래밍을 할 때 보통 운영체제에서 제공하는 스레드를 사용한다. 운영체제에서 제공하기 때문에 특히 커널 스레드라고 부른다. 그런데 문제는 이 커널 스레드가 상당히 무겁다는 것이다. 해서 중량 스레드라고 부르기도 한다. 동시성 프로그래밍이 복잡한 이유는 바로 이 커널 스레드가 중량 스레드이기 때문인데, 위에서 언급한 그 고약한 문제란 이 중량 스레드가 야기하는 문제이다. 즉 멀티코어와 클라우드의 시대에 중량 스레드가 야기하는 문제는 매우 심각했고, 결국 이를 해결하기 위해 나온 것이 Fiber, Greenlet, goroutine, Actor(혹은 재발견?) 등이었다. (이들은 중량 스레드와 비교해서 가벼워서 경량 스레드라고 부른다)

스레드, 즉 중량 스레드의 문제는 그 이름이 말해주듯이, 그것이 어플리케이션에서 사용하기에는 지나치게 무겁다는 것이다.

무겁다는 표현은 3가지 의미가 있는데, 이것이 중량 스레드의 특성이다.

하나씩 순서대로 좀 더 자세히 알아보자.

첫째로 스레드는 리소스를 많이 차지하는데, 그래서 서버당 수천 개 정도만 생성할 수 있다. 반면 소켓은 수백만 개 생성할 수 있다. 이는 거의 몇 승수(order of magnitude)라는 매우 심각한 차이다. 실제로 웹서버는 하나의 스레드가 하나의 Request를 처리하기 때문에 동시에 처리할 수 있는 Request는 스레드 생성 개수에 제한받아서 수 천 개 정도이다. 또한 스레드 간 문맥 전환에 드는 비용도 만만치 않다.

둘째는, 사실 이는 첫째 때문에 생기는 것인데, 스레드가 리소스를 많이 차지하기(또 관리가 어렵기) 때문에, 작은 단위의 작업을 처리하기 위해 가볍게 쓰고 버리는 식으로 쓰기보다는, 큰 단위의 작업을 처리하고 Pooling 한 후 재사용하는 식으로 이용하게 된다는 것이다. 하지만 어플리케이션은 그 특성에 따라 동시성의 작업 단위가 각각 다르다. 비디오 레코딩 프로그램과 웹서버의 동시성 요구 사항의 수준이 같을 수 없다. 또한 어플리케이션 수준에서는 작은 단위의 동시성 작업이 많다. 유저 단위 작업, 트랜잭션 단위 작업, 심지어 단일 연산 작업이라도 동시성 처리가 필요한 경우가 많지만, 이때마다 스레드 만들어 처리하기에는 너무 비용이 크기 때문에, 꼭 필요한 경우를 제외하고는 대부분 세션같이 큰 단위의 작업에 스레드를 사용한다.

셋째는, 정말 이것이야말로 개인적으로는 가장 치명적 요소라고 보는데, 스레드, 그러니까 OS가 제공하는 커널 스레드는 선점형 스케줄러에 의해 처리된다는 사실이다. 선점형이라는 말은 한 스레드에서 다른 스레드로 제어(CPU 할당)가 넘어가는 문맥전환(Context Switch)이 전적으로 OS 담당이라는 의미이다. 이로 인해, 어플리케이션 수준에서 작업하는 프로그래머는 스레드에 맡긴 작업이 어느 순간에 중단될지를 알 수가 없다. 더욱이 그 중단되는 분절이 프로그래머가 작성한 코드 레벨이 아니라 컴파일된 코드(바이트 코드나 기계어 코드) 레벨이기 때문에, 프로그래머에게는 비가시성 영역에서의 중단이라는 점에서, 프로그래머는 전혀 예측할 수 없는 암흑 상태에 빠지게 된다. 이 암흑 상태는 더욱 심각한 문제를 야기하는데, 이런 암흑 상태에서 실행되는 작업이 처리하는 데이터들이 엉망이 될 수 있다는 사실이다. 마치 컴컴한 한밤중에 여러 대의 드론을 운전하면서 골목길을 통과하고 피자를 배달하는 것과 마찬가지 상황이 되는 것이다. 그래서 드론들이 주변과 충돌하지 않도록 골목길에 칠 가드레일과 교차로에서 서로 충돌하지 않도록 하는(데드락) 신호등이 필요하게 되는데, 그게 바로 멀티 스레드 프로그래밍 시에 반드시 사용하게 되는 세마포어, 뮤텍스, 아톰, 크리티컬 섹션이다. 하지만 이들로 인해 바로 그만큼 멀티 스레드 프로그래밍의 복잡성이 더욱 증폭된다.

사실 스레드(커널 스레드)는 모든 어플리케이션의 동시성 요구에 맞추기 위한 일반 목적으로 만들어진 것이다. 즉 스레드는 가장 최악의 경우에도 대처할 수 있도록 만들어야 했는데, 예를 들어 하나의 스레드가 엄청난 계산으로 CPU를 독점하고 있는 상황에 대처할 필요가 있었다. 그러나 개개의 어플리케이션들은 각자 자신만의 특수한 동시성 수준이 갖고 있을 뿐이다. 프로그래머들은 자신이 만들고 있는 어플리케이션이 요구하는 동시성 수준에 대해 잘 알고 있으며, 사실 그 특수한(일반적이지 않은) 요구사항의 수준에 맞는 정도의 동시성 작업 자체만 할 수 있다면 매우 간단하게 해결할 수 있다. 프로그래머들은 결코 스레드와 같은 일반성 수준의 동시성 작업을 만나지 않는다. 웹 어플리케이션을 만들면서 동시에 비디오 레코딩의 동시성에 대해 고민하지 않는다. 그런데 스레드는 개개의 어플리케이션의 특수한 동시성을 해결하기에는 너무 일반적인 도구이며, 위의 3가지 이유로 인해서 매우 불편한 도구인 것이다.

해결책의 방향은 이것이다. 만일 프로그래머들이 해당 어플리케이션의 요구사항에 대응하는 동시성 수준의 특수성에 대해 잘 알고 있다면, 더 이상 커널이 강제한 일반적인 방식이 아닌, 해당 어플리케이션의 동시성 수준의 방식으로 스스로 동시성 작업을 관리할 수 있도록 자유를 주는 것이다. (한마디로 동시성 프로그래밍에 있어서 커널 독재 시대에서 어플리케이션의 자유 시대로 바뀌는 것인데, 이를 위해 때론 Callback이나 Promise 그리고 심지어 Monad까지 동원되는 다양한 시도들이 있었지만, 근본적인 변화를 위해서는 일급시민(First Class)이 된 Continuation이 필요했다)

그래서 위에서 언급한 중량 스레드의 특성과는 반대되는 특성을 가진 경량 스레드가 주목받게 된 것이다.

경량 스레드는 다음과 같은 특성이 있다:

자바는 경량 스레드 중에서 Fiber를 채택하게 되었다. 사실 Fiber와 Continuation이라면 다른 경량 스레드를 다 만들어낼 수 있다. 보다 근본적이기 때문이다.