반성문

올 한해에는 개인적으로 많은 일들이 있었습니다. 해의 시작은 이직준비로 부터 시작되었고 TL로 마무리 지어야하는 프로젝트들도 있었습니다. 현재는 새로운 직장에서 비교적 하던 일과는 다른 다양한 플랫폼을 맡으면서 일하고 있는데 병특도 시작하고 회사일도 매우 바빠서 항상 핑계대면서 또 스스로 공부해야하는 방향도 살짝 잃어서 블로깅을 게을리 했습니다.

이 블로그는 스스로 무언가 깊게 공부하거나 실험해보고 난 결과를 이야기하고 싶었지만 최근에 공부하는 RL이나 알고리즘 쪽은 내가 잘 안다고 할만한 입장이 아닌것 같아서 쓰기 좀 부끄러워 글 쓰기도 회피하게 되고 안 쓰다 보니 블로그와 거리가 멀어진것 같습니다.

그래도 원래부터 써오던 도메인도 슬슬 만료기간이 다가와서 이전부터 바꾸고 싶었던 .kr 도메인도 버렸고, 연말을 맞아서 마음을 가다듬고 이전에 작성했던 글을 정리해 올리고, 앞으로는 조금 더 가벼운 주제도 가볍게 쓸 수 있도록 하고 배우고 느꼈던것들에 대해서도 간단히 적어보도록 하려합니다. 사실 이전에 적었던 글들이 글을 처음 써보는 입장이기도 했고 번역투인것도 많고 (지금이라고 다른건 아니지만) 미숙했던 점들이 많아서 좀 수정 보완하는 작업도 진행해보고 싶지만… 이건 시간이 많이 들어서 어떻게 될지 모르겠네요. 그래도 관련 키워드로 검색하면 맞춤 검색인지 모르겠지만 상단 노출되어서 (…) 부끄러워서라도 고쳐볼까 합니다.

본문

한 CPU에 여러 코어가 있는 multi-core 형태의 프로세서가 산업 표준이 되면서 한번에 하나의 작업을 처리하지 않고 작업을 다중으로 처리하는(multitasking) 것은 아주 오래전부터 사용되었고 구현하는 방법도 매우 다양합니다. 엔지니어가 가장 쉽게 multitasking을 구현하는 방법은 적어도 저에게는 thread일 것입니다. 고전적인 방법이지만 모든 언어와 플랫폼에서 지원하는 방식의 multitasking을 처리하는 방법입니다.

하지만 multitasking을 구현하는 방법은 thread를 이용하는 것만 있는것은 아니고 다양한 패턴을 활용하여 구현할 수 있습니다. multitasking에 관련된 용어나 방법들에 대해서는 저는 경험적으로 얻었던 지식이라 스스로도 정리가 잘 안되어있습니다. 그래서 이번에 개념과 용어를 프로그래밍 언어의 런타임에서는 어떻게 구현되어 있는지도 알아보려합니다. 이 글의 시리즈에서는 Concurrent vs Parallel, Preemptive vs Non-preemptive multitasking의 개념에 대해서 알아보고 이어서 Coroutine, Generator, Thread, Async/Await, Reactive의 개념들과 Python과 Go 언어에서는 각 개념을 어떻게 런타임에 구현했는지 커널 레벨에서 동작에 대해서 설명할 예정입니다.

Concurrent와 Parallel의 동질성

우선 Concurrent의 영영사전 뜻을 확인하면 다음과 같습니다.

Concurrent

the fact of two or more events or circumstances happening or existing at the same time.

복수의 사건이나 상황이 같은 시간에 벌어지거나 존재하는 것 이라는 해석이 가능합니다. 같은 시간이라는 말이 조금 애매하지만 아래 예제를 생각해보면 이해가 쉽습니다.

그 사람은 동시에 요리 3개를 할 수 있다.

예를 들어 요리를 하는데 파스타도 하고 스테이크도 구우면서 치킨도 같이 구워 손님에게 서빙할 수 있다면 이 사람은 동시성을 갖는 요리사라고 볼 수 있습니다.

동시라는 말은 애초에 단어의 한자 뜻에서 나타나 듯 (concurrent라는 영어도 마찬가지로) 같은 시간에 복수의 일을 처리하는 경우 붙일 수 있습니다. 위의 문장을 CS에서 사용하는 용어로 살짝 바꾸면.. 아래와 같습니다.

워커 하나가 동시에 요청 100개를 처리한다.

하나의 워커가 동시에 요청을 100개 처리하면 동시성을 갖는 워커라고 볼 수 있습니다. 일반적인 자바 서버로 보면 풀에 워커 프로세서가 있을것이고 워커마다 사용가능한 스레드 풀이 따로 있기에, 하나의 워커는 항상 동시에 복수의 요청을 처리할 수 있습니다. 따라서 하나의 워커는 항상 동시성을 갖고 있다 말할 수 있습니다.

다수의 작업을 동시에 처리하는 것을 두가지 방법이 있습니다. 작업자가 해야할 일을 나눠서 동시에 작업하는 방법이 있고 애초에 복수의 작업자가 동시에 처리하는 방법이 있을것 입니다.

아까 예를 들었던 요리의 예를 들자면 해야하는 요리는 총 3개라면 한명의 요리사가 가스렌지가 갖고 있는 가용성을 충분히 끌어내서 스테이크와 파스타를 적절한 타이밍을 맞춰가면서 만들어내고 그와 동시에 오븐에 치킨도 굽는다면 동시에 일을 동시에 처리했다고 볼 수 있습니다. 하지만 이런 방법 말고 3개의 요리를 애초에 서로 다른 3개의 주방에서 서로 다른 3명의 요리사가 각각 한명씩 자신만의 요리를 진행한다면? 이 또한 동시에 요리를 만들었다고 볼 수 있습니다.

위의 예제에서 후자는 동시성을 갖기 위해서 병렬적으로 일을 처리했다고 볼 수 있습니다. 두 개념을 비교하면 동시성은(concurrency)는 항시 다른 작업을 위해서 양보할 수 있는 상태(interruptability)를 말합니다. 병렬성(parallelism)은 다른 작업들이 모두 독립적으로 처리되고 있는 상태(independentability)를 일컫습니다.

마치 한명의 요리사가 동시 작업을 하면 스테이크를 뒤집고 나면 파스타를 살펴보며 소스를 넣어주고 그 다음에는 오븐의 예열이 끝난 알람을 듣고 치킨을 오븐에 넣는것 같이 말입니다. 하지만 병렬성을 갖는 방법인 후자의 방법은 모든 작업 즉 요리가 각자 독립성을 갖고 각각의 요리사가 요리하게 됩니다.

이를 CS에서 바라보면 다수 프로세서 (multiprocessor, 흔하게는 멀티 코어)를 이용해서 다수의 일을 처리하면 병렬적으로 동시성 있게 일을 처리하는 방법입니다. 만약 하나의 프로세서(이는 싱글코어)에서 다수의 일을 처리한다면 이는 동시성이 있다고 이야기할 수는 있지만 각 작업이 독립되어서 처리되지는 않기 때문에 병렬적이라고 이야기할 수 없습니다.

그러면 병렬적으로 일을 처리하면 항상 동시성을 갖을까요? 꼭 그렇지만은 않습니다.

병렬적이나 동시적이지 않을때

병렬로 일을 처리해도 항상 동시적이진 않습니다. 위의 요리예를 다시 한번 더 인용하면 3명의 요리사가 요리하는데 만약 가스레인지가 하나라면 (…) 서로 번갈아 가면서 사용하면서 요리해야하기 때문에 동시성을 갖기 힘듭니다. 이는 CS에서는 critical section이라고 이야기합니다. 공유 변수등의 문제로 인해서 병렬적으로 일은 처리하지만 다른 일이 처리가 끝나기를 mutex를 이용해서 기다리고 처리되야합니다. 이는 병렬적으로 일을 처리하고는 있으나 동시에 처리되는것은 아니게 됩니다. 따라서 동시성과 병렬성이 꼭 subset관계에 있다고 볼 수는 없습니다.