포지션 상세
■ 우리 팀
• 우리 팀은 GritDB를 설계한 아키텍트와 초기 창업 멤버이고, 지금도 엔진 코드를 직접 씁니다. 창업자는 국내 CDC 1세대 회사를 공동 창업해 CTO를 지냈고 RDBMS 엔진 레벨 연구 개발 경험이 다양합니다.
• 우리는 PostgreSQL 커널에 훅을 심고, 그 옆에 열 기반 저장소와 벡터화 실행 엔진을 처음부터 만들었습니다. 오픈소스를 포장한 제품이 아니라서, 캡처·저장·컴팩션·복구·GC·실행의 결정을 우리가 전부 내렸고, 그 결정의 결과를 매일 e2e에서 봅니다. 이 엔진의 한 축을 맡아 다음 단계를 설계할 시니어 엔지니어를 찾습니다.
■ 우리가 만드는 것
• GritDB는 PostgreSQL 호환 이중 엔진 데이터베이스입니다. 트랜잭션은 PostgreSQL 17.4 엔진이 행으로 처리하고, 분석은 우리가 만든 분석 엔진 GritSurfer가 열로 처리합니다. 응용 프로그램과 BI 도구에는 데이터베이스 하나로 보입니다. 고객은 운영 DB를 그대로 두고, 리포트와 집계 쿼리만 GritSurfer에 맡깁니다. GritSurfer는 세 부분으로 되어 있습니다.
PLUG — 트랜잭션 엔진과 분석 엔진을 잇는 부분. PostgreSQL 백엔드 프로세스가 쓰는 바로 그 시점에 변경을 잡아 공유메모리 채널로 넘기고, 분석 세션의 조회를 BURST로 넘겨 결과를 돌려줍니다. 수십 개 백엔드와 엔진 사이의 채널과 큐, 커밋 순서와 워터마크를 지키는 동기화, 분석 엔진을 다시 띄울 때 WAL의 어디서부터 이어받을지 스스로 찾는 복구가 여기 있습니다. 훅이 WAL insert lock 안에서 무엇을 해도 되고 무엇을 하면 죽는지, 우리는 코드와 장애로 배웠습니다. WAL 버퍼로 변경을 처리하는 이 기법은 등록 특허입니다.
UNIFY — 하이브리드 저장 엔진. 받은 변경은 메모리에 행 버전으로 쌓이고, 쌓이면 열 기반 파일로 구워집니다. 갱신과 삭제는 비트벡터로 따라가고, 오래된 버전은 epoch 기반 GC가 치웁니다. 분석용 열 저장소는 보통 UPDATE·DELETE를 싫어하지만, 우리 것은 복제로 들어오는 갱신과 삭제를 그대로 받아야 합니다. 파일 포맷, 존맵과 블룸필터, 인덱스 파일, 카탈로그, 체크포인트, 크래시 복구가 이 층이고, "크래시 뒤에 어느 파일이 진실인가"를 정하는 곳입니다. 조회 때는 필요한 열만 읽고, 조건에 맞지 않는 묶음은 건너뛰어 BURST에 넘깁니다.
BURST — 최적화·병렬 실행 엔진. 분석 세션의 조회를 분석용 실행 계획으로 다시 세우고, UNIFY가 읽어 온 데이터를 값 수천 개 묶음 단위로, 여러 CPU 코어에서 push 기반 병렬 파이프라인으로 처리합니다. 다음 단계는 자체 실행 코어와 JIT입니다.
• 국내 금융 고객의 실데이터 검증에서 기존 PostgreSQL보다 50배 많은 데이터를 26배 빠르게 처리했습니다. 핵심 기술은 등록 특허로 보호되고, 한국·미국 출원이 이어지고 있습니다. 중소벤처기업부 TIPS 선정 기업입니다.
■ 이 일이 어려운 이유
• HTAP의 숙제는 세 가지를 한꺼번에 얻는 것입니다. 방금 커밋된 행까지 보이는 최신성, 운영 트랜잭션을 늦추지 않는 격리, 열 저장소의 분석 속도. 둘까지는 많은 시스템이 풀었고, 셋을 함께 푼 시스템은 드뭅니다. 우리는 그 셋을 PostgreSQL 커널 안에서, 크래시·재기동·체크포인트 경계에서 행 하나도 잃지 않는다는 조건 위에서 노립니다.
• 지금 출시된 GritDB 1.1은 분석계부터 맡습니다. 분석 엔진은 열 기반 파일을 읽고, 등록한 테이블의 쓰기는 분석 엔진의 수신 확인을 기다립니다. 그다음 단계가 이 자리의 일입니다.
• 최신성: 메모리의 행 버전과 파일의 열 블록을 어떻게 하나의 일관된 스냅샷으로 읽을까
• 격리: 커밋 경로에 들어간 캡처를 운영 트랜잭션이 느끼지 못하게 하려면
• 속도: 비용 기반 최적화와 멀티코어·CPU 캐시에 맞춘 실행, 그다음 자체 실행 코어와 JIT를 어떻게 설계할까
• 무손실: 열 저장소가 싫어하는 UPDATE·DELETE를 받으면서, 크래시 뒤 어느 파일이 진실인지 어떻게 증명할까
• 이 질문들은 사람 수로 풀리지 않습니다. 동시성과 내구성과 성능을 한 번에 머릿속에 들고, 재현으로 증명하고, 글로 남기는 엔지니어 한 명이 끝까지 붙어야 풀립니다. 그래서 많이 뽑지 않고, 뛰어난 사람을 찾습니다.
■ 이 자리가 가치 있는 이유
• 데이터베이스 엔진을 만듭니다.
• 남이 만든 엔진을 튜닝하거나 오픈소스를 감싸는 자리가 아닙니다. 저장 포맷부터 실행 계획까지, 아직 정해지지 않은 자리에 당신의 설계가 들어갑니다.
• 정해진 답이 없는 문제입니다.
• "컬럼 파일을 합치면서 파일 번호를 재사용했더니 재기동 뒤 유령 행이 살아난다", "비트벡터를 내보내기 전에 지웠더니 좀비 행이 남는다", "체크포인트에 걸친 파일은 지울 수 없고 잘라내야 한다", "futex로 자기 전에 128번만 돌면 처리량이 10배 는다". 최근 우리가 실제로 풀었던 문제들입니다.
• 글로 설계하고, 끝까지 팝니다.
• 버그는 근본 원인을 밝힌 문서와 재현 테스트가 있어야 닫습니다. 테스트 서버에서 난 체크섬 오류를 쫓아, ECC 없는 메모리의 비트가 뒤집힌 것까지 찾아냈습니다. 직접 쓴 설계 문서가 리뷰를 거쳐, 코드가 따르는 기준이 됩니다.
• 고객 앞에서, 외산 제품과 1:1로 겨룹니다.
• 당신이 고친 코드가 몇 주 안에 고객사 폐쇄망에서 돌아갑니다. 상대는 당신도 아는 그 외산 분석 데이터베이스들이고, 결과는 성능 숫자와 장애 0으로 돌아옵니다.
• 한 축을 소유합니다.
• PLUG, UNIFY, BURST 중 하나가 당신 것이 됩니다. 아키텍트와 C-Level이 옆에서 같이 문제를 해결합니다.
• 운영 DB와 분석을 한곳에 모으는 쪽으로 세계 데이터 플랫폼들이 움직이고 있습니다. 2025년 Databricks는 Neon을, Snowflake는 Crunchy Data를 인수해 PostgreSQL을 자기 플랫폼에 들였습니다. 우리는 그 일을 PostgreSQL 커널 옆에서 직접 풉니다. 우리는 우리만의 방식으로 그 문제를 해결합니다.
• PLUG(PostgreSQL 훅·공유메모리 채널·동기화·복구), UNIFY(하이브리드 저장·열 기반 파일 포맷·스캔·컴팩션·GC·체크포인트·복구), BURST(쿼리 최적화·벡터화 병렬 실행·JIT) 중 한 축을 소유합니다
• 맡은 축의 다음 단계(최신성·격리·속도·무손실 중 하나)를 HLD부터 land까지 끌고 갑니다
• 설계 문서(HLD·LLD)를 쓰고 재검합니다. 다른 엔지니어의 설계와 코드를 리뷰하고, 설계·테스트·근본 원인 분석의 기준을 팀에 세웁니다
• 장애 근본 원인 분석을 주도하고, 재현 테스트를 붙여 닫습니다
• 성능을 측정하고 병목을 없앱니다. 벤치마크 재현 스크립트를 유지합니다
■ 맡는 범위
• 경력 폭이 6~15년이라, 맡는 범위는 면접에서 함께 정합니다. 한 축의 다음 단계를 이끄는 자리부터, 한 축 전체를 소유하고 팀의 설계 기준을 세우는 자리까지입니다.
■ 첫 90일
• 1~30일: 빌드·e2e·코드베이스 지도와 기존 설계 문서 숙지. 작은 수정 1건 land
• 31~60일: 버그 근본 원인 분석 2건을 주도해 수정 land, 재현 테스트 추가
• 61~90일: 맡은 축의 다음 단계 HLD를 쓰고, 그중 LLD 1개를 구현해 land
• 모던 C++로 시스템 소프트웨어를 6년 이상 만든 분. 멀티스레드, 락 없는 자료구조, 메모리 관리를 설계 수준에서 다뤄 본 분
• 데이터베이스 엔진 내부(저장·실행·트랜잭션·WAL·복구)의 모듈을 직접 설계하고 구현해 제품에 넣어 본 분
• Linux 시스템 프로그래밍(파일 I/O, mmap, 공유메모리, futex, 프로세스 간 통신)과 성능 분석 도구에 익숙한 분
• 재현이 어려운 장애를 근본 원인까지 추적해 닫아 본 분
• 설계를 글로 쓰고, 쓴 글대로 구현하고, 남의 설계를 리뷰할 수 있는 분
• 재현 없는 수정을 믿지 않는 분
■ 이런 분은 안 맞습니다
• 프레임워크 위에서만 일해 온 분
• 문서 없이 코드부터 밀어 넣는 분
• 테스트가 빨개지면 테스트를 고치는 분
• 남이 만든 엔진을 튜닝만 해 온 분
• 우리 팀은 GritDB를 설계한 아키텍트와 초기 창업 멤버이고, 지금도 엔진 코드를 직접 씁니다. 창업자는 국내 CDC 1세대 회사를 공동 창업해 CTO를 지냈고 RDBMS 엔진 레벨 연구 개발 경험이 다양합니다.
• 우리는 PostgreSQL 커널에 훅을 심고, 그 옆에 열 기반 저장소와 벡터화 실행 엔진을 처음부터 만들었습니다. 오픈소스를 포장한 제품이 아니라서, 캡처·저장·컴팩션·복구·GC·실행의 결정을 우리가 전부 내렸고, 그 결정의 결과를 매일 e2e에서 봅니다. 이 엔진의 한 축을 맡아 다음 단계를 설계할 시니어 엔지니어를 찾습니다.
■ 우리가 만드는 것
• GritDB는 PostgreSQL 호환 이중 엔진 데이터베이스입니다. 트랜잭션은 PostgreSQL 17.4 엔진이 행으로 처리하고, 분석은 우리가 만든 분석 엔진 GritSurfer가 열로 처리합니다. 응용 프로그램과 BI 도구에는 데이터베이스 하나로 보입니다. 고객은 운영 DB를 그대로 두고, 리포트와 집계 쿼리만 GritSurfer에 맡깁니다. GritSurfer는 세 부분으로 되어 있습니다.
PLUG — 트랜잭션 엔진과 분석 엔진을 잇는 부분. PostgreSQL 백엔드 프로세스가 쓰는 바로 그 시점에 변경을 잡아 공유메모리 채널로 넘기고, 분석 세션의 조회를 BURST로 넘겨 결과를 돌려줍니다. 수십 개 백엔드와 엔진 사이의 채널과 큐, 커밋 순서와 워터마크를 지키는 동기화, 분석 엔진을 다시 띄울 때 WAL의 어디서부터 이어받을지 스스로 찾는 복구가 여기 있습니다. 훅이 WAL insert lock 안에서 무엇을 해도 되고 무엇을 하면 죽는지, 우리는 코드와 장애로 배웠습니다. WAL 버퍼로 변경을 처리하는 이 기법은 등록 특허입니다.
UNIFY — 하이브리드 저장 엔진. 받은 변경은 메모리에 행 버전으로 쌓이고, 쌓이면 열 기반 파일로 구워집니다. 갱신과 삭제는 비트벡터로 따라가고, 오래된 버전은 epoch 기반 GC가 치웁니다. 분석용 열 저장소는 보통 UPDATE·DELETE를 싫어하지만, 우리 것은 복제로 들어오는 갱신과 삭제를 그대로 받아야 합니다. 파일 포맷, 존맵과 블룸필터, 인덱스 파일, 카탈로그, 체크포인트, 크래시 복구가 이 층이고, "크래시 뒤에 어느 파일이 진실인가"를 정하는 곳입니다. 조회 때는 필요한 열만 읽고, 조건에 맞지 않는 묶음은 건너뛰어 BURST에 넘깁니다.
BURST — 최적화·병렬 실행 엔진. 분석 세션의 조회를 분석용 실행 계획으로 다시 세우고, UNIFY가 읽어 온 데이터를 값 수천 개 묶음 단위로, 여러 CPU 코어에서 push 기반 병렬 파이프라인으로 처리합니다. 다음 단계는 자체 실행 코어와 JIT입니다.
• 국내 금융 고객의 실데이터 검증에서 기존 PostgreSQL보다 50배 많은 데이터를 26배 빠르게 처리했습니다. 핵심 기술은 등록 특허로 보호되고, 한국·미국 출원이 이어지고 있습니다. 중소벤처기업부 TIPS 선정 기업입니다.
■ 이 일이 어려운 이유
• HTAP의 숙제는 세 가지를 한꺼번에 얻는 것입니다. 방금 커밋된 행까지 보이는 최신성, 운영 트랜잭션을 늦추지 않는 격리, 열 저장소의 분석 속도. 둘까지는 많은 시스템이 풀었고, 셋을 함께 푼 시스템은 드뭅니다. 우리는 그 셋을 PostgreSQL 커널 안에서, 크래시·재기동·체크포인트 경계에서 행 하나도 잃지 않는다는 조건 위에서 노립니다.
• 지금 출시된 GritDB 1.1은 분석계부터 맡습니다. 분석 엔진은 열 기반 파일을 읽고, 등록한 테이블의 쓰기는 분석 엔진의 수신 확인을 기다립니다. 그다음 단계가 이 자리의 일입니다.
• 최신성: 메모리의 행 버전과 파일의 열 블록을 어떻게 하나의 일관된 스냅샷으로 읽을까
• 격리: 커밋 경로에 들어간 캡처를 운영 트랜잭션이 느끼지 못하게 하려면
• 속도: 비용 기반 최적화와 멀티코어·CPU 캐시에 맞춘 실행, 그다음 자체 실행 코어와 JIT를 어떻게 설계할까
• 무손실: 열 저장소가 싫어하는 UPDATE·DELETE를 받으면서, 크래시 뒤 어느 파일이 진실인지 어떻게 증명할까
• 이 질문들은 사람 수로 풀리지 않습니다. 동시성과 내구성과 성능을 한 번에 머릿속에 들고, 재현으로 증명하고, 글로 남기는 엔지니어 한 명이 끝까지 붙어야 풀립니다. 그래서 많이 뽑지 않고, 뛰어난 사람을 찾습니다.
■ 이 자리가 가치 있는 이유
• 데이터베이스 엔진을 만듭니다.
• 남이 만든 엔진을 튜닝하거나 오픈소스를 감싸는 자리가 아닙니다. 저장 포맷부터 실행 계획까지, 아직 정해지지 않은 자리에 당신의 설계가 들어갑니다.
• 정해진 답이 없는 문제입니다.
• "컬럼 파일을 합치면서 파일 번호를 재사용했더니 재기동 뒤 유령 행이 살아난다", "비트벡터를 내보내기 전에 지웠더니 좀비 행이 남는다", "체크포인트에 걸친 파일은 지울 수 없고 잘라내야 한다", "futex로 자기 전에 128번만 돌면 처리량이 10배 는다". 최근 우리가 실제로 풀었던 문제들입니다.
• 글로 설계하고, 끝까지 팝니다.
• 버그는 근본 원인을 밝힌 문서와 재현 테스트가 있어야 닫습니다. 테스트 서버에서 난 체크섬 오류를 쫓아, ECC 없는 메모리의 비트가 뒤집힌 것까지 찾아냈습니다. 직접 쓴 설계 문서가 리뷰를 거쳐, 코드가 따르는 기준이 됩니다.
• 고객 앞에서, 외산 제품과 1:1로 겨룹니다.
• 당신이 고친 코드가 몇 주 안에 고객사 폐쇄망에서 돌아갑니다. 상대는 당신도 아는 그 외산 분석 데이터베이스들이고, 결과는 성능 숫자와 장애 0으로 돌아옵니다.
• 한 축을 소유합니다.
• PLUG, UNIFY, BURST 중 하나가 당신 것이 됩니다. 아키텍트와 C-Level이 옆에서 같이 문제를 해결합니다.
• 운영 DB와 분석을 한곳에 모으는 쪽으로 세계 데이터 플랫폼들이 움직이고 있습니다. 2025년 Databricks는 Neon을, Snowflake는 Crunchy Data를 인수해 PostgreSQL을 자기 플랫폼에 들였습니다. 우리는 그 일을 PostgreSQL 커널 옆에서 직접 풉니다. 우리는 우리만의 방식으로 그 문제를 해결합니다.
주요업무
■ 하는 일• PLUG(PostgreSQL 훅·공유메모리 채널·동기화·복구), UNIFY(하이브리드 저장·열 기반 파일 포맷·스캔·컴팩션·GC·체크포인트·복구), BURST(쿼리 최적화·벡터화 병렬 실행·JIT) 중 한 축을 소유합니다
• 맡은 축의 다음 단계(최신성·격리·속도·무손실 중 하나)를 HLD부터 land까지 끌고 갑니다
• 설계 문서(HLD·LLD)를 쓰고 재검합니다. 다른 엔지니어의 설계와 코드를 리뷰하고, 설계·테스트·근본 원인 분석의 기준을 팀에 세웁니다
• 장애 근본 원인 분석을 주도하고, 재현 테스트를 붙여 닫습니다
• 성능을 측정하고 병목을 없앱니다. 벤치마크 재현 스크립트를 유지합니다
■ 맡는 범위
• 경력 폭이 6~15년이라, 맡는 범위는 면접에서 함께 정합니다. 한 축의 다음 단계를 이끄는 자리부터, 한 축 전체를 소유하고 팀의 설계 기준을 세우는 자리까지입니다.
■ 첫 90일
• 1~30일: 빌드·e2e·코드베이스 지도와 기존 설계 문서 숙지. 작은 수정 1건 land
• 31~60일: 버그 근본 원인 분석 2건을 주도해 수정 land, 재현 테스트 추가
• 61~90일: 맡은 축의 다음 단계 HLD를 쓰고, 그중 LLD 1개를 구현해 land
자격요건
■ 이런 분을 찾습니다• 모던 C++로 시스템 소프트웨어를 6년 이상 만든 분. 멀티스레드, 락 없는 자료구조, 메모리 관리를 설계 수준에서 다뤄 본 분
• 데이터베이스 엔진 내부(저장·실행·트랜잭션·WAL·복구)의 모듈을 직접 설계하고 구현해 제품에 넣어 본 분
• Linux 시스템 프로그래밍(파일 I/O, mmap, 공유메모리, futex, 프로세스 간 통신)과 성능 분석 도구에 익숙한 분
• 재현이 어려운 장애를 근본 원인까지 추적해 닫아 본 분
• 설계를 글로 쓰고, 쓴 글대로 구현하고, 남의 설계를 리뷰할 수 있는 분
• 재현 없는 수정을 믿지 않는 분
■ 이런 분은 안 맞습니다
• 프레임워크 위에서만 일해 온 분
• 문서 없이 코드부터 밀어 넣는 분
• 테스트가 빨개지면 테스트를 고치는 분
• 남이 만든 엔진을 튜닝만 해 온 분
