포지션 상세
■ 우리 팀
• 우리 팀은 GritDB를 설계한 아키텍트와 초기 창업 멤버이고, 지금도 엔진 코드를 직접 씁니다. 창업자는 국내 CDC 1세대 회사를 공동 창업해 CTO를 지냈습니다.
• 우리는 PostgreSQL 커널에 훅을 심고, 그 옆에 열 기반 저장소와 벡터화 실행 엔진을 처음부터 만들었습니다. 이 엔진을 같이 연구하고 만들 연구원을 찾습니다. 경력은 길지 않아도 됩니다. 기본기가 단단하고, 한 문제를 끝까지 파는 분이면 됩니다.
■ 우리가 만드는 것
• GritDB는 PostgreSQL 호환 이중 엔진 데이터베이스입니다. 트랜잭션은 PostgreSQL 17.4 엔진이 행으로 처리하고, 분석은 우리가 만든 분석 엔진 GritSurfer가 열로 처리합니다. 응용 프로그램과 BI 도구에는 데이터베이스 하나로 보입니다. GritSurfer는 세 부분으로 되어 있습니다.
• PLUG — 트랜잭션 엔진과 분석 엔진을 잇는 부분. PostgreSQL이 쓰는 바로 그 시점에 변경을 잡아 공유메모리 채널로 넘기고, 분석 세션의 조회를 BURST로 넘깁니다. 이 기법은 등록 특허입니다.
• UNIFY — 하이브리드 저장 엔진. 변경은 메모리에 행 버전으로 쌓였다가 열 기반 파일로 구워지고, 갱신과 삭제는 비트벡터로 따라갑니다. 조회 때는 필요한 열만 읽고, 조건에 맞지 않는 묶음은 건너뜁니다. "크래시 뒤에 어느 파일이 진실인가"를 정하는 곳입니다.
• BURST — 최적화·병렬 실행 엔진. 분석 세션의 조회를 분석용 실행 계획으로 다시 세우고, 값 수천 개 묶음 단위로 여러 CPU 코어에서 병렬 처리합니다.
• 국내 금융 고객의 실데이터 검증에서 기존 PostgreSQL보다 50배 많은 데이터를 26배 빠르게 처리했습니다. 중소벤처기업부 TIPS 선정 기업입니다.
■ 이 일이 어려운 이유
• HTAP의 숙제는 세 가지를 한꺼번에 얻는 것입니다. 방금 커밋된 행까지 보이는 최신성, 운영 트랜잭션을 늦추지 않는 격리, 열 저장소의 분석 속도. 우리는 그 셋을 PostgreSQL 커널 안에서, 행 하나도 잃지 않는다는 조건 위에서 노립니다.
• 이 엔진에는 지름길이 없습니다. 열 기반 파일의 인코딩을 하나 바꾸면 압축률과 스캔 속도, 갱신 비용, 파일 포맷 호환이 함께 움직입니다. 비용 모델이 틀리면 같은 질의도 전혀 다른 실행 계획으로 돕니다. 그래서 우리는 추측하지 않고 재고, 재현하고, 글로 남깁니다. 이 습관과 운영체제·데이터베이스 기본기가 있는 분이면, 엔진 지식은 옆에서 같이 채웁니다.
■ 이 자리에서 얻는 것
• 데이터베이스 엔진을 처음부터 만든 사람에게 배웁니다. 설계 노트와 코드를 아키텍트가 직접 리뷰합니다. 교과서의 B-tree가 아니라, 크래시 뒤 어느 파일이 진실인지 정하는 코드를 읽고 고칩니다.
• 연구가 실험실에서 끝나지 않습니다. 열 기반 인코딩을 바꿔 압축률과 스캔 속도를 재고, 비용 모델을 측정으로 맞추고, 여러 코어가 캐시를 덜 다투도록 실행을 고칩니다. 그 결과가 다음 릴리스에 들어가 고객사 폐쇄망에서 돌아갑니다.
• 진짜 문제를 같이 풉니다. "비트벡터를 내보내기 전에 지웠더니 좀비 행이 남는다", "futex로 자기 전에 128번만 돌면 처리량이 10배 는다". 최근 석 달 동안 우리가 실제로 풀었던 문제들입니다.
• 글로 생각하는 법이 몸에 붙습니다. HLD·LLD·근본 원인 분석 문서를 쓰고, 재검받고, 그 문서가 제품의 정본이 됩니다.
• 한 축을 맡는 엔지니어로 자랍니다. 6개월이면 작은 모듈의 LLD를 직접 쓰고, 그다음은 UNIFY나 BURST의 한 영역을 맡습니다.
• 운영 DB와 분석을 한곳에 모으는 쪽으로 세계 데이터 플랫폼들이 움직이고 있습니다. 2025년 Databricks는 Neon을, Snowflake는 Crunchy Data를 인수해 PostgreSQL을 자기 플랫폼에 들였습니다. 우리는 그 일을 PostgreSQL 커널 옆에서 직접 풉니다. 우리는 우리만의 방식으로 그 문제를 해결합니다.
2. 버그는 재현 테스트부터 만들고, 근본 원인을 문서로 정리한 뒤 고칩니다
3. e2e·단위 테스트를 더하고, 벤치마크(TPC-H 등)를 통해 발생한 문제를 해결합니다.
• 운영체제·동시성·자료구조·알고리즘 기본기가 단단한 분. 데이터베이스의 트랜잭션·인덱스·로그를 설명할 수 있는 분
• 멀티스레드 코드를 gdb·perf 같은 도구로 디버깅해 본 분
• 자기가 고친 버그를 재현부터 설명할 수 있는 분
• 실험을 설계하고 결과를 글로 정리하는 분 (보고서, 논문, 기술 블로그 무엇이든)
안 맞는 분:
• 프레임워크 위에서만 일하고 싶은 분 · 문서 없이 코드부터 밀어 넣는 분 · 테스트가 빨개지면 테스트를 고치는 분
• 왜 되는지 모른 채 돌아가면 넘어가는 분
• 우리 팀은 GritDB를 설계한 아키텍트와 초기 창업 멤버이고, 지금도 엔진 코드를 직접 씁니다. 창업자는 국내 CDC 1세대 회사를 공동 창업해 CTO를 지냈습니다.
• 우리는 PostgreSQL 커널에 훅을 심고, 그 옆에 열 기반 저장소와 벡터화 실행 엔진을 처음부터 만들었습니다. 이 엔진을 같이 연구하고 만들 연구원을 찾습니다. 경력은 길지 않아도 됩니다. 기본기가 단단하고, 한 문제를 끝까지 파는 분이면 됩니다.
■ 우리가 만드는 것
• GritDB는 PostgreSQL 호환 이중 엔진 데이터베이스입니다. 트랜잭션은 PostgreSQL 17.4 엔진이 행으로 처리하고, 분석은 우리가 만든 분석 엔진 GritSurfer가 열로 처리합니다. 응용 프로그램과 BI 도구에는 데이터베이스 하나로 보입니다. GritSurfer는 세 부분으로 되어 있습니다.
• PLUG — 트랜잭션 엔진과 분석 엔진을 잇는 부분. PostgreSQL이 쓰는 바로 그 시점에 변경을 잡아 공유메모리 채널로 넘기고, 분석 세션의 조회를 BURST로 넘깁니다. 이 기법은 등록 특허입니다.
• UNIFY — 하이브리드 저장 엔진. 변경은 메모리에 행 버전으로 쌓였다가 열 기반 파일로 구워지고, 갱신과 삭제는 비트벡터로 따라갑니다. 조회 때는 필요한 열만 읽고, 조건에 맞지 않는 묶음은 건너뜁니다. "크래시 뒤에 어느 파일이 진실인가"를 정하는 곳입니다.
• BURST — 최적화·병렬 실행 엔진. 분석 세션의 조회를 분석용 실행 계획으로 다시 세우고, 값 수천 개 묶음 단위로 여러 CPU 코어에서 병렬 처리합니다.
• 국내 금융 고객의 실데이터 검증에서 기존 PostgreSQL보다 50배 많은 데이터를 26배 빠르게 처리했습니다. 중소벤처기업부 TIPS 선정 기업입니다.
■ 이 일이 어려운 이유
• HTAP의 숙제는 세 가지를 한꺼번에 얻는 것입니다. 방금 커밋된 행까지 보이는 최신성, 운영 트랜잭션을 늦추지 않는 격리, 열 저장소의 분석 속도. 우리는 그 셋을 PostgreSQL 커널 안에서, 행 하나도 잃지 않는다는 조건 위에서 노립니다.
• 이 엔진에는 지름길이 없습니다. 열 기반 파일의 인코딩을 하나 바꾸면 압축률과 스캔 속도, 갱신 비용, 파일 포맷 호환이 함께 움직입니다. 비용 모델이 틀리면 같은 질의도 전혀 다른 실행 계획으로 돕니다. 그래서 우리는 추측하지 않고 재고, 재현하고, 글로 남깁니다. 이 습관과 운영체제·데이터베이스 기본기가 있는 분이면, 엔진 지식은 옆에서 같이 채웁니다.
■ 이 자리에서 얻는 것
• 데이터베이스 엔진을 처음부터 만든 사람에게 배웁니다. 설계 노트와 코드를 아키텍트가 직접 리뷰합니다. 교과서의 B-tree가 아니라, 크래시 뒤 어느 파일이 진실인지 정하는 코드를 읽고 고칩니다.
• 연구가 실험실에서 끝나지 않습니다. 열 기반 인코딩을 바꿔 압축률과 스캔 속도를 재고, 비용 모델을 측정으로 맞추고, 여러 코어가 캐시를 덜 다투도록 실행을 고칩니다. 그 결과가 다음 릴리스에 들어가 고객사 폐쇄망에서 돌아갑니다.
• 진짜 문제를 같이 풉니다. "비트벡터를 내보내기 전에 지웠더니 좀비 행이 남는다", "futex로 자기 전에 128번만 돌면 처리량이 10배 는다". 최근 석 달 동안 우리가 실제로 풀었던 문제들입니다.
• 글로 생각하는 법이 몸에 붙습니다. HLD·LLD·근본 원인 분석 문서를 쓰고, 재검받고, 그 문서가 제품의 정본이 됩니다.
• 한 축을 맡는 엔지니어로 자랍니다. 6개월이면 작은 모듈의 LLD를 직접 쓰고, 그다음은 UNIFY나 BURST의 한 영역을 맡습니다.
• 운영 DB와 분석을 한곳에 모으는 쪽으로 세계 데이터 플랫폼들이 움직이고 있습니다. 2025년 Databricks는 Neon을, Snowflake는 Crunchy Data를 인수해 PostgreSQL을 자기 플랫폼에 들였습니다. 우리는 그 일을 PostgreSQL 커널 옆에서 직접 풉니다. 우리는 우리만의 방식으로 그 문제를 해결합니다.
주요업무
1. GritDB 엔진인 GritSurfer의 정해진 기능을 연구하고 구현해서 land합니다2. 버그는 재현 테스트부터 만들고, 근본 원인을 문서로 정리한 뒤 고칩니다
3. e2e·단위 테스트를 더하고, 벤치마크(TPC-H 등)를 통해 발생한 문제를 해결합니다.
자격요건
• C++ 또는 C로 3년 이상 개발하거나 연구한 분 (석·박사 과정의 시스템 연구 포함)• 운영체제·동시성·자료구조·알고리즘 기본기가 단단한 분. 데이터베이스의 트랜잭션·인덱스·로그를 설명할 수 있는 분
• 멀티스레드 코드를 gdb·perf 같은 도구로 디버깅해 본 분
• 자기가 고친 버그를 재현부터 설명할 수 있는 분
• 실험을 설계하고 결과를 글로 정리하는 분 (보고서, 논문, 기술 블로그 무엇이든)
안 맞는 분:
• 프레임워크 위에서만 일하고 싶은 분 · 문서 없이 코드부터 밀어 넣는 분 · 테스트가 빨개지면 테스트를 고치는 분
• 왜 되는지 모른 채 돌아가면 넘어가는 분
