ClickHouse가 공개한 Silk: C++로 만든 협력형 파이버 스케줄러는 왜 필요했을까

들어가며: 왜 또 새로운 스케줄러인가요?

요즘 백엔드 엔지니어라면 한 번쯤 "비동기", "코루틴", "async/await" 같은 단어를 들어보셨을 거예요. 우리가 흔히 쓰는 운영체제의 스레드(thread)는 강력하지만 무겁거든요. 스레드 하나를 만들 때마다 메모리도 꽤 잡아먹고, 스레드끼리 전환할 때마다 CPU가 컨텍스트 스위칭이라는 작업을 해야 해서 비용이 들어요. 그래서 동시에 수십만, 수백만 개의 작업을 처리해야 하는 데이터베이스나 네트워크 서버에서는 스레드만으로는 한계가 있죠.

이 문제를 풀기 위해 등장한 게 바로 파이버(fiber) 또는 코루틴(coroutine) 이라는 개념인데요. 운영체제가 관리하는 무거운 스레드 대신, 사용자 프로그램이 직접 가볍게 만들고 전환할 수 있는 "가짜 스레드" 같은 거예요. Go 언어의 고루틴(goroutine)이 대표적인 예시고, 최근에는 자바도 Project Loom으로 가상 스레드를 도입했죠. ClickHouse가 이번에 공개한 Silk 도 바로 이 계열의 도구인데, C++ 환경을 위한 협력형(cooperative) 파이버 스케줄러예요.

Silk의 핵심: 협력형 멀티태스킹

여기서 "협력형(cooperative)"이라는 단어가 중요해요. 이게 뭐냐면, 일반적인 운영체제 스레드는 "선점형(preemptive)" 방식이라 OS가 강제로 "너 잠깐 쉬어, 다른 애 차례야" 하고 끼어들어요. 반면 협력형은 각 작업이 "나 이제 좀 기다려야 하니까 다른 친구한테 양보할게" 하고 스스로 양보(yield)하는 방식이에요. 마치 회의실에서 한 명이 발언을 마치고 "다음 분 하세요" 하는 것과 비슷하죠.

이 방식의 장점은 컨텍스트 스위칭 비용이 훨씬 적다는 거예요. OS가 끼어들지 않으니까 커널 모드로 진입할 필요도 없고, 레지스터를 통째로 저장할 필요도 없거든요. 대신 단점도 있어요. 어떤 파이버 하나가 양보하지 않고 계속 CPU를 붙잡고 있으면, 같은 스레드에서 도는 다른 파이버들은 굶어 죽어요. 그래서 개발자가 "여기서는 양보해야 한다" 하는 지점을 잘 설계해야 합니다.

ClickHouse가 Silk를 만든 이유도 여기서 나와요. ClickHouse는 초당 수십억 행을 처리하는 컬럼형 OLAP 데이터베이스인데, 쿼리 하나를 처리할 때 디스크 I/O, 네트워크 호출, CPU 연산이 복잡하게 얽히거든요. 이걸 모두 OS 스레드로 처리하면 스레드 풀이 폭발해버려요. 그래서 가볍게 수만 개를 띄울 수 있는 파이버가 필요했던 거죠.

비슷한 프로젝트들과 뭐가 다를까

C++ 진영에는 이미 비슷한 도구들이 꽤 있어요. Boost.Fiber 가 가장 유명하고, Boost.Coroutine2, 페이스북이 만든 Folly Fibers, Intel의 TBB(Threading Building Blocks) 같은 것들이 있죠. C++20부터는 언어 표준에 코루틴이 들어가서 co_await, co_yield 같은 키워드도 쓸 수 있게 됐고요.

Silk의 차별점은 ClickHouse의 워크로드에 특화된 최적화라는 점이에요. 범용 라이브러리는 모든 상황을 고려해야 해서 어쩔 수 없이 오버헤드가 생기는데, Silk는 OLAP 쿼리 실행처럼 "수많은 작은 작업을 병렬로 돌리고, I/O 대기 중에 다른 작업으로 넘어가는" 패턴에 맞춰 설계됐어요. 또한 ClickHouse 같은 대규모 프로덕션 환경에서 이미 검증된 코드를 오픈소스로 풀었다는 의미도 크죠.

다른 언어 진영을 보면, Go의 고루틴은 런타임이 알아서 다 해주니까 편하지만 C++만큼의 저수준 제어는 어렵고, Rust의 tokio는 async/await로 비슷한 걸 하지만 학습 곡선이 가파른 편이에요. Silk는 C++ 개발자가 기존 코드베이스에 큰 변경 없이 도입할 수 있는 실용적인 선택지가 될 수 있어요.

한국 개발자에게는 어떤 의미일까

사실 대부분의 한국 개발자들은 자바, 코틀린, 파이썬, 자바스크립트로 일하니까 Silk를 직접 쓸 일은 많지 않을 거예요. 하지만 이 프로젝트를 살펴보는 건 의미가 있어요. 왜냐하면 "왜 비동기/코루틴이 필요한가" 라는 본질적인 질문에 대한 답이 여기 담겨 있거든요.

예를 들어 코틀린 코루틴을 쓰면서 "왜 굳이 suspend 함수를 만들어야 하지?", "Dispatchers.IO랑 Default는 뭐가 다르지?" 같은 의문이 들었다면, Silk 같은 저수준 구현체를 들여다보면 "아, 이래서 이렇게 설계된 거구나" 하고 무릎을 칠 수 있어요. 또한 ClickHouse를 데이터 분석 인프라로 쓰고 있는 팀이라면, 내부 동작을 이해하는 데도 도움이 되겠죠.

C++로 고성능 서버나 데이터베이스, 게임 서버를 만드는 분들에게는 직접적으로 유용한 도구예요. Boost.Fiber보다 더 가볍고 특화된 옵션을 찾고 있다면 한 번 검토해볼 만하고, 라이선스가 오픈소스인 만큼 학습용으로 코드를 뜯어보기에도 좋은 자료입니다.

마무리

핵심 정리: Silk는 ClickHouse가 자사 OLAP 엔진의 동시성 처리 경험을 녹여낸 C++ 협력형 파이버 스케줄러로, 대규모 병렬 워크로드에 특화된 가벼운 코루틴 런타임이에요.

여러분은 어떤 언어에서 비동기 처리를 가장 자주 다루시나요? 그리고 협력형 스케줄링과 선점형 스케줄링 중 어느 쪽이 더 마음에 드시는지, 그 이유는 무엇인지 의견 들어보고 싶어요.