C++에 async/await를 10년 먼저 심었다: FoundationDB의 비밀 병기 'Flow'

여러분, C++로 비동기 코드를 짜본 적 있으세요? 콜백 안에 콜백, 그 안에 또 콜백이 이어지면서 코드가 오른쪽으로 하염없이 밀려나는 경험, 한 번쯤 해보셨을 텐데요. 그런데 C++20에 코루틴이 공식적으로 들어오기 10년도 전에, 이미 async/await 스타일의 비동기 프로그래밍을 C++에서 구현해서 실전에 쓰고 있던 팀이 있어요. 바로 분산 데이터베이스 FoundationDB를 만든 팀이고, 그 도구의 이름이 'Flow'예요. 오늘은 이 독특한 물건이 어떻게 만들어졌고 왜 지금 봐도 배울 게 많은지 풀어볼게요.

FoundationDB, 그리고 Flow가 뭐냐면

FoundationDB는 애플이 2015년에 인수해서 2018년에 오픈소스로 공개한 분산 키-밸류 데이터베이스예요. 애플 iCloud의 뒤편에서 수억 명의 데이터를 받치고 있고, 스냅챗 같은 대규모 서비스들도 핵심 저장소로 써왔죠. 이 DB가 업계에서 유명한 이유 중 하나가 '비정상적으로 높은 안정성'인데요, 그 비결의 한가운데에 Flow가 있어요.

Flow는 C++을 확장한 일종의 미니 언어예요. ACTOR라는 키워드로 함수를 정의하면, 그 안에서 wait()를 호출해 비동기 작업의 결과를 기다릴 수 있어요. 지금 우리가 쓰는 async/await 문법과 거의 똑같은 모양새죠. 이렇게 작성한 코드는 'actor compiler'라는 전처리기가 순수한 C++11 코드로 변환해줘요. 내부적으로는 콜백 기반의 상태 머신으로 바뀌는 건데, 개발자는 그런 복잡한 속사정을 몰라도 위에서 아래로 자연스럽게 읽히는 코드를 쓰면 되는 거예요. 아직 도착하지 않은 값을 표현하는 Future와 Promise 타입으로 액터들끼리 결과를 주고받는 구조도 갖추고 있고요.

액터 모델이 뭐냐면, 쉽게 말해 '각자 자기 우편함을 가진 독립적인 일꾼들'이라고 생각하면 돼요. 일꾼(액터)들은 서로의 작업 공간을 직접 건드리지 않고, 오직 메시지를 주고받으면서만 소통해요. 여러 스레드가 같은 메모리를 동시에 만지면서 생기는 골치 아픈 락(lock) 문제나 경쟁 조건(race condition)을 구조적으로 피할 수 있는 방식이죠. Erlang이라는 언어가 이 모델로 유명한데, Flow는 그 아이디어를 C++의 성능을 포기하지 않으면서 가져온 거예요.

진짜 목적은 '시뮬레이션 테스트'

그런데 Flow의 진짜 킬러 기능은 예쁜 문법이 아니에요. 결정론적 시뮬레이션 테스트(deterministic simulation testing)를 가능하게 한다는 점이거든요.

분산 시스템의 버그는 대부분 타이밍 문제예요. 네트워크 패킷이 하필 늦게 도착하거나, 디스크가 하필 그 순간에 죽거나, 두 서버가 미묘하게 어긋난 순서로 메시지를 처리하거나 하는 식이죠. 이런 버그는 수백만 번에 한 번 나타나기 때문에 재현이 거의 불가능하고, 재현이 안 되니 고치기도 어려워요.

FoundationDB 팀은 이 문제를 정면돌파했어요. Flow로 작성된 코드는 네트워크, 디스크, 시간 같은 모든 외부 요소를 가짜(시뮬레이션)로 갈아끼울 수 있게 설계돼 있어요. 그래서 서버 여러 대로 구성된 분산 클러스터 전체를 단일 프로세스, 단일 스레드 안에서 돌리면서, 무작위로 서버를 죽이고 네트워크를 끊고 디스크를 오염시키는 극한 테스트를 수백만 번 반복할 수 있죠. 여기서 중요한 게 '결정론적'이라는 단어인데요, 같은 시드(seed) 값을 넣으면 매번 정확히 같은 순서로 상황이 재현된다는 뜻이에요. 버그가 한 번 발견되면 언제든 똑같이 다시 돌려보면서 디버깅할 수 있는 거죠. 세상에서 제일 잡기 어려운 종류의 버그를 '재현 가능한 버그'로 바꿔버린 거예요.

업계에 남긴 유산

이 접근법은 이후 업계에 꽤 큰 흔적을 남겼어요. 금융 거래 처리용 DB인 TigerBeetle은 아예 처음부터 시뮬레이션 테스트를 핵심 설계 원칙으로 삼고 만들어졌고, FoundationDB 출신들이 창업한 Antithesis라는 회사는 '어떤 소프트웨어든 결정론적으로 테스트해주는' 플랫폼을 사업으로 만들었죠. 문법 쪽으로 보면 C++20 코루틴이나 Rust의 async/await 같은 현대적 도구들이 이제는 표준으로 제공되지만, '신뢰성 테스트를 위해 언어 차원에서 결정론을 확보한다'는 발상 자체는 Flow가 원조 격이라고 할 수 있어요.

한국 개발자에게 주는 시사점

솔직히 말해서 Flow 자체를 실무에 도입할 일은 거의 없을 거예요. FoundationDB 개발이라는 특수한 목적에 맞춰진 도구니까요. 하지만 배울 점은 분명해요. 첫째, 비동기 코드를 설계할 때 '이걸 어떻게 재현 가능하게 테스트할 것인가'를 처음부터 고민하는 습관이에요. 네트워크, 시간, 난수 같은 외부 의존성을 인터페이스 뒤로 숨겨두면 나중에 시뮬레이션으로 갈아끼우기가 쉬워지거든요. 이건 어떤 언어를 쓰든 적용할 수 있는 원칙이에요. 둘째, 표준에 기능이 없으면 전처리기를 직접 만들어서라도 문제를 해결해버리는 엔지니어링 태도인데요, '언어가 지원 안 해서 못 해요'라는 말을 다시 생각해보게 만들죠.

한 줄로 정리하면, Flow는 C++에 async/await와 액터 모델을 10년 이상 앞서 이식한 언어 확장이자, FoundationDB의 전설적인 안정성을 만들어낸 시뮬레이션 테스트의 토대예요. 여러분의 팀에서는 타이밍에 따라 어쩌다 한 번 터지는 버그를 어떻게 재현하고 계신가요? 시뮬레이션 테스트나 비슷한 기법을 도입해본 경험이 있다면 댓글로 공유해주세요.