TorQ — 금융권을 떠받치는 kdb+ 운영의 모든 것을 담은 오픈소스 프레임워크

kdb+가 왜 중요한가요

금융 업계, 특히 트레이딩과 시장 데이터 분석 쪽에서 일해보신 분이라면 kdb+라는 이름을 한 번쯤 들어보셨을 거예요. 작은 용량에 어마어마한 속도를 자랑하는 컬럼 기반 시계열 데이터베이스인데, 글로벌 투자은행과 헤지펀드가 거의 표준처럼 쓰는 인프라예요. 매일 수십억 건의 틱(tick) 데이터를 받아 실시간으로 분석하고, 수년치 과거 데이터를 밀리초 단위로 쿼리할 수 있게 해줍니다.

kdb+의 쿼리 언어가 바로 q이고, 그 기반이 되는 게 앞서 소개된 K 언어예요. 강력하지만 학습 곡선이 가파르기로 악명 높고, 운영 도구나 모니터링 솔루션도 자체 생태계 안에서 알아서 구축해야 하는 어려움이 있죠.

TorQ가 뭘 해결해 주나요

DataIntellect가 공개한 TorQ는 그 어려움을 줄여주는 오픈소스 운영 프레임워크예요. 한 마디로 "kdb+ 운영 베스트 프랙티스를 통째로 박스로 묶어둔 것"이라고 보면 됩니다. 새 프로젝트를 시작할 때마다 매번 처음부터 운영 인프라를 짜는 대신, TorQ 위에서 비즈니스 로직만 작성하면 되도록 설계되어 있어요.

구체적으로 어떤 기능이 들어 있냐면, 우선 프로세스 관리 기능이 있어요. kdb+ 운영 환경은 여러 프로세스(피더, 티커플랜트, 실시간 데이터베이스, 과거 데이터베이스, 게이트웨이 등)가 메시지를 주고받는 분산 구조인데, TorQ는 이걸 일관된 방식으로 시작·중지·모니터링할 수 있게 해줘요. systemd나 Kubernetes에 익숙한 분이라면, kdb+ 세계의 그런 도구라고 생각하시면 됩니다.

또 로깅과 모니터링 표준이 내장되어 있어요. 각 프로세스의 상태, 메모리 사용량, 쿼리 응답 시간 같은 메트릭을 일관된 포맷으로 남기고, 외부 모니터링 시스템과 연동할 수 있는 인터페이스도 제공합니다. 거기에 권한 관리, 사용자 인증, 디스커버리 서비스(어떤 프로세스가 어디에 떠 있는지 자동으로 찾아주는 기능)까지 한 번에 들어 있어요.

아키텍처 살짝 들여다보기

kdb+ 기반 시스템의 전형적인 아키텍처는 이렇습니다. 거래소나 외부 데이터 소스에서 데이터를 받아오는 피더(feedhandler)가 있고, 그 데이터를 받아 메모리에 잠시 보관하면서 다른 컴포넌트로 뿌려주는 티커플랜트(tickerplant), 실시간 분석에 쓰이는 RDB(real-time database), 하루치 데이터가 쌓이면 디스크로 내려보내는 HDB(historical database), 그리고 클라이언트의 쿼리를 적절한 프로세스로 라우팅하는 게이트웨이(gateway)로 구성돼요.

TorQ는 이 모든 프로세스를 위한 표준 템플릿과 설정 파일 구조를 제공합니다. 게이트웨이가 RDB와 HDB의 쿼리 결과를 합쳐서 클라이언트에게 돌려주는 "분산 쿼리" 로직, 장애가 났을 때 자동으로 재시작하는 watchdog, 시간대별 다른 정책을 적용할 수 있는 스케줄러 같은 기능이 모두 미리 짜여 있어요. 신규 개발자가 들어와도 "이 디렉토리에 새 프로세스 추가하고 설정 한 줄 바꾸면 됩니다" 수준으로 정형화되어 있다는 거죠.

비슷한 도구들과 비교하면

kdb+ 생태계는 비교적 좁아서, TorQ와 비슷한 위치에 있는 오픈소스 프레임워크는 많지 않아요. AquaQ Analytics가 만든 "TorQ"가 사실 이걸 가리키는 거고(DataIntellect가 AquaQ의 후신이에요), 이외에 KX 본사가 직접 제공하는 KX Insights 플랫폼이 상업용으로 있어요. KX Insights가 풀스택 상용 솔루션이라면, TorQ는 가볍게 쓰면서도 운영 노하우를 그대로 가져갈 수 있는 오픈소스 대안이라고 보면 됩니다.

시계열 데이터베이스 전반으로 보면 InfluxDB, TimescaleDB, ClickHouse, QuestDB 같은 대안들이 있지만, 마이크로초 단위 트레이딩이나 거대한 틱 데이터를 다루는 영역에서는 여전히 kdb+의 성능을 따라오기 힘들어요. 가격이 매우 비싸다는 게 흠인데, 그래서 최근에는 ShaktiDB 같은 오픈소스 대안도 등장하고 있습니다.

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

한국에서 kdb+를 쓰는 곳은 주로 증권사 트레이딩 데스크, 일부 헤지펀드, 그리고 시장 데이터 벤더예요. 직접 다루실 일이 없는 분이 더 많겠지만, 그래도 TorQ 코드베이스를 한 번 훑어보는 건 의미가 있어요. 왜냐하면 고성능 데이터 인프라를 어떻게 운영하는지에 대한 교과서 같은 코드거든요.

예를 들어, 프로세스 간 디스커버리를 어떻게 설계하는지, 실시간 데이터와 과거 데이터의 쿼리를 어떻게 합치는지, 메모리에 있는 데이터를 어느 시점에 디스크로 내릴지 같은 의사결정 패턴은 어떤 시계열 시스템을 만들든 응용할 수 있어요. ClickHouse나 Druid로 비슷한 워크로드를 처리하는 팀이라면 TorQ의 운영 패턴에서 영감을 얻을 수 있습니다.

또 K/q 언어 자체를 공부해두면 데이터를 다루는 사고방식이 확장됩니다. 앞서 소개한 "Thinking in K" 튜토리얼과 함께 TorQ 코드를 읽다 보면, 짧은 코드 안에 얼마나 많은 표현력이 담길 수 있는지를 체감하게 될 거예요.