포지션 상세
■ 이 글을 쓰는 사람
저는 데이터그릿 창업자 조오욱입니다. GritDB를 설계한 아키텍트이고, 지금도 저장 엔진 코드를 직접 씁니다. 국내 CDC 1세대 회사의 공동창업 CTO 출신입니다.
우리는 PostgreSQL 커널에 훅을 심고, 그 옆에 컬럼나 저장소와 벡터화 실행 엔진을 처음부터 만들었습니다. 오픈소스를 포장한 제품이 아니라서, 캡처·저장·컴팩션·복구·GC·실행의 결정을 우리가 전부 내렸고, 그 결정의 결과를 매일 e2e에서 봅니다. 이 엔진의 한 축을 맡을 개발자를 찾습니다.
■ 우리가 만드는 것
GritDB는 PostgreSQL 옆에 붙는 분석 엔진입니다. 고객은 쓰던 PostgreSQL을 그대로 쓰고, 애플리케이션 코드도 고치지 않습니다. 대량 분석 쿼리만 우리의 엔진 GritSurfer가 받아서 처리합니다. GritSurfer는 세 부분으로 되어 있습니다.
Plug — PostgreSQL 안에 심는 부분. 트랜잭션이 WAL을 쓰는 바로 그 경로에 훅을 넣어, 변경을 그 자리에서 잡아 엔진으로 보냅니다. 수십 개 백엔드 프로세스와 엔진 사이를 잇는 공유메모리 채널과 큐, 커밋 순서와 워터마크를 지키는 동기화, 재기동 시 WAL을 어디서부터 다시 읽을지 스스로 찾는 복구까지가 여기 있습니다. 훅이 WAL insert lock 안에서 무엇을 해도 되는지, 무엇을 하면 죽는지를 우리는 코드와 장애로 배웠습니다. 이 기법은 등록 특허입니다.
Unify — 변경을 받아 저장하는 부분. 방금 들어온 행은 메모리에 버전으로 쌓이고, 쌓이면 컬럼 파일로 구워지고, 갱신과 삭제는 비트벡터로 따라가고, 오래된 버전은 epoch 기반 GC가 치웁니다. 분석용 컬럼 저장소는 보통 UPDATE·DELETE를 싫어하지만, 우리 것은 CDC로 들어오는 갱신·삭제를 그대로 받아야 합니다. 파일 포맷, 존맵과 블룸필터, 인덱스 파일, 카탈로그, 체크포인트, 크래시 복구가 이 층입니다. "크래시 뒤에 어느 파일이 진실인가"를 정하는 곳입니다.
Burst — 질의를 실행하는 부분. 벡터화된 push 기반 병렬 파이프라인이 메모리의 최신 행과 컬럼 파일의 과거 행을 합쳐 읽으며 분석 질의를 처리합니다. 분석 세션만 이쪽으로 라우팅되고, 운영 세션은 순정 PostgreSQL 그대로 동작합니다. 다음 단계는 자체 실행 코어와 JIT입니다.
• 무손실이 첫 번째 규칙입니다. 크래시·재기동·체크포인트 경계에서 행 하나도 잃지 않는 것. 그 규칙을 검증하는 e2e 하네스가 매일 돕니다.
• 국내 금융권 검증에서 고객사 워크로드로 데이터 50배·처리 25배. 핵심 기술은 등록 특허로 보호되고, 국내·미국 출원이 이어지고 있습니다. 중소벤처기업부 TIPS 선정 기업입니다.
■ 이 자리가 재미있는 이유
1. 진짜 문제입니다.
"컬럼 파일을 합치면서 파일 번호를 재사용했더니 재기동 뒤 유령 행이 살아난다", "비트벡터를 내보내기 전에 지웠더니 좀비 행이 남는다", "체크포인트에 걸친 파일은 지울 수 없고 잘라내야 한다", "futex로 자기 전에 128번만 돌면 처리량이 10배 는다". 최근 석 달 동안 우리가 실제로 풀었던 문제들입니다. 교과서 뒤에 답이 없고, 우리는 설계 문서로 써서 풉니다.
2. 설계 문서를 먼저 씁니다.
HLD를 쓰고, LLD를 쓰고, 불변 원칙에 대조해 재검한 뒤 구현합니다. 코드 리뷰는 아키텍트가 직접 합니다. "일단 짜고 보자"는 여기서 통하지 않습니다. 대신 당신이 쓴 문서가 제품의 정본이 됩니다.
3. 장애를 끝까지 파헤칩니다.
버그는 티켓 번호를 달고, 근본 원인 분석 문서가 남고, 재현 테스트가 추가된 뒤에 닫힙니다. 커밋 하나하나에 무엇을, 왜, 어떤 결과로 바꿨는지 남깁니다. 비ECC 메모리의 비트 플립까지 잡아낸 기록이 있습니다.
4. 코드가 고객 앞에서 돌아갑니다.
당신이 고친 것이 몇 주 안에 고객사 폐쇄망에서 돌아갑니다. 성능 숫자로, 장애 0으로 돌아옵니다.
5. 한 축을 소유합니다.
Plug, Unify, Burst 중 하나가 당신 것이 됩니다. 아키텍트와 C-Level 옆에서 같이 짭니다.
• Plug(PostgreSQL 훅·공유메모리 채널·동기화·복구), Unify(컬럼 파일 포맷·컴팩션·GC·체크포인트·복구), Burst(벡터화 실행·스캔·플랜) 중 한 축을 소유
• 설계 문서(HLD·LLD) 작성과 재검. 구현. e2e·단위 테스트 추가
• 장애 근본 원인 분석과 수정. 재현 테스트 추가
• 성능 측정과 병목 제거. 벤치마크 재현 스크립트 유지
• 빌드·릴리스·배포 파이프라인 개선
■ 첫 90일
• 1~30일: 빌드·e2e·코드베이스 지도 숙지. 기존 설계 문서 읽기. 작은 수정 1건 land.
• 31~60일: 버그 근본 원인 분석 2건, 수정 land, 재현 테스트 추가.
• 61~90일: 모듈 1개의 LLD를 쓰고 구현해 land.
• 모던 C++ 실무 3년 이상. 멀티스레드, 락 없는 자료구조, 메모리 관리를 직접 다뤄본 분
• 데이터베이스 내부(저장·실행·트랜잭션·WAL·복구) 경험이 있거나, 그 코드를 읽고 고쳐본 분. PostgreSQL 확장·커널, 오픈소스 분석 엔진 등
• Linux 시스템 프로그래밍(파일 I/O, mmap, 공유메모리, futex, 프로세스 간 통신)에 익숙한 분
• 설계를 글로 쓸 수 있고, 쓴 글대로 구현하는 분
• 재현 없는 수정을 믿지 않는 분
• 우대: PostgreSQL 커널 패치 경험, 컬럼나·벡터화 실행 경험, LLVM·JIT, 분산 시스템
■ 이런 분은 안 맞습니다
• 프레임워크 위에서만 일해 온 분
• 문서 없이 코드부터 밀어 넣는 분
• 테스트가 빨개지면 테스트를 고치는 분
• 남이 만든 엔진을 튜닝만 해 온 분
저는 데이터그릿 창업자 조오욱입니다. GritDB를 설계한 아키텍트이고, 지금도 저장 엔진 코드를 직접 씁니다. 국내 CDC 1세대 회사의 공동창업 CTO 출신입니다.
우리는 PostgreSQL 커널에 훅을 심고, 그 옆에 컬럼나 저장소와 벡터화 실행 엔진을 처음부터 만들었습니다. 오픈소스를 포장한 제품이 아니라서, 캡처·저장·컴팩션·복구·GC·실행의 결정을 우리가 전부 내렸고, 그 결정의 결과를 매일 e2e에서 봅니다. 이 엔진의 한 축을 맡을 개발자를 찾습니다.
■ 우리가 만드는 것
GritDB는 PostgreSQL 옆에 붙는 분석 엔진입니다. 고객은 쓰던 PostgreSQL을 그대로 쓰고, 애플리케이션 코드도 고치지 않습니다. 대량 분석 쿼리만 우리의 엔진 GritSurfer가 받아서 처리합니다. GritSurfer는 세 부분으로 되어 있습니다.
Plug — PostgreSQL 안에 심는 부분. 트랜잭션이 WAL을 쓰는 바로 그 경로에 훅을 넣어, 변경을 그 자리에서 잡아 엔진으로 보냅니다. 수십 개 백엔드 프로세스와 엔진 사이를 잇는 공유메모리 채널과 큐, 커밋 순서와 워터마크를 지키는 동기화, 재기동 시 WAL을 어디서부터 다시 읽을지 스스로 찾는 복구까지가 여기 있습니다. 훅이 WAL insert lock 안에서 무엇을 해도 되는지, 무엇을 하면 죽는지를 우리는 코드와 장애로 배웠습니다. 이 기법은 등록 특허입니다.
Unify — 변경을 받아 저장하는 부분. 방금 들어온 행은 메모리에 버전으로 쌓이고, 쌓이면 컬럼 파일로 구워지고, 갱신과 삭제는 비트벡터로 따라가고, 오래된 버전은 epoch 기반 GC가 치웁니다. 분석용 컬럼 저장소는 보통 UPDATE·DELETE를 싫어하지만, 우리 것은 CDC로 들어오는 갱신·삭제를 그대로 받아야 합니다. 파일 포맷, 존맵과 블룸필터, 인덱스 파일, 카탈로그, 체크포인트, 크래시 복구가 이 층입니다. "크래시 뒤에 어느 파일이 진실인가"를 정하는 곳입니다.
Burst — 질의를 실행하는 부분. 벡터화된 push 기반 병렬 파이프라인이 메모리의 최신 행과 컬럼 파일의 과거 행을 합쳐 읽으며 분석 질의를 처리합니다. 분석 세션만 이쪽으로 라우팅되고, 운영 세션은 순정 PostgreSQL 그대로 동작합니다. 다음 단계는 자체 실행 코어와 JIT입니다.
• 무손실이 첫 번째 규칙입니다. 크래시·재기동·체크포인트 경계에서 행 하나도 잃지 않는 것. 그 규칙을 검증하는 e2e 하네스가 매일 돕니다.
• 국내 금융권 검증에서 고객사 워크로드로 데이터 50배·처리 25배. 핵심 기술은 등록 특허로 보호되고, 국내·미국 출원이 이어지고 있습니다. 중소벤처기업부 TIPS 선정 기업입니다.
■ 이 자리가 재미있는 이유
1. 진짜 문제입니다.
"컬럼 파일을 합치면서 파일 번호를 재사용했더니 재기동 뒤 유령 행이 살아난다", "비트벡터를 내보내기 전에 지웠더니 좀비 행이 남는다", "체크포인트에 걸친 파일은 지울 수 없고 잘라내야 한다", "futex로 자기 전에 128번만 돌면 처리량이 10배 는다". 최근 석 달 동안 우리가 실제로 풀었던 문제들입니다. 교과서 뒤에 답이 없고, 우리는 설계 문서로 써서 풉니다.
2. 설계 문서를 먼저 씁니다.
HLD를 쓰고, LLD를 쓰고, 불변 원칙에 대조해 재검한 뒤 구현합니다. 코드 리뷰는 아키텍트가 직접 합니다. "일단 짜고 보자"는 여기서 통하지 않습니다. 대신 당신이 쓴 문서가 제품의 정본이 됩니다.
3. 장애를 끝까지 파헤칩니다.
버그는 티켓 번호를 달고, 근본 원인 분석 문서가 남고, 재현 테스트가 추가된 뒤에 닫힙니다. 커밋 하나하나에 무엇을, 왜, 어떤 결과로 바꿨는지 남깁니다. 비ECC 메모리의 비트 플립까지 잡아낸 기록이 있습니다.
4. 코드가 고객 앞에서 돌아갑니다.
당신이 고친 것이 몇 주 안에 고객사 폐쇄망에서 돌아갑니다. 성능 숫자로, 장애 0으로 돌아옵니다.
5. 한 축을 소유합니다.
Plug, Unify, Burst 중 하나가 당신 것이 됩니다. 아키텍트와 C-Level 옆에서 같이 짭니다.
주요업무
■ 하는 일• Plug(PostgreSQL 훅·공유메모리 채널·동기화·복구), Unify(컬럼 파일 포맷·컴팩션·GC·체크포인트·복구), Burst(벡터화 실행·스캔·플랜) 중 한 축을 소유
• 설계 문서(HLD·LLD) 작성과 재검. 구현. e2e·단위 테스트 추가
• 장애 근본 원인 분석과 수정. 재현 테스트 추가
• 성능 측정과 병목 제거. 벤치마크 재현 스크립트 유지
• 빌드·릴리스·배포 파이프라인 개선
■ 첫 90일
• 1~30일: 빌드·e2e·코드베이스 지도 숙지. 기존 설계 문서 읽기. 작은 수정 1건 land.
• 31~60일: 버그 근본 원인 분석 2건, 수정 land, 재현 테스트 추가.
• 61~90일: 모듈 1개의 LLD를 쓰고 구현해 land.
자격요건
■ 이런 분을 찾습니다• 모던 C++ 실무 3년 이상. 멀티스레드, 락 없는 자료구조, 메모리 관리를 직접 다뤄본 분
• 데이터베이스 내부(저장·실행·트랜잭션·WAL·복구) 경험이 있거나, 그 코드를 읽고 고쳐본 분. PostgreSQL 확장·커널, 오픈소스 분석 엔진 등
• Linux 시스템 프로그래밍(파일 I/O, mmap, 공유메모리, futex, 프로세스 간 통신)에 익숙한 분
• 설계를 글로 쓸 수 있고, 쓴 글대로 구현하는 분
• 재현 없는 수정을 믿지 않는 분
• 우대: PostgreSQL 커널 패치 경험, 컬럼나·벡터화 실행 경험, LLVM·JIT, 분산 시스템
■ 이런 분은 안 맞습니다
• 프레임워크 위에서만 일해 온 분
• 문서 없이 코드부터 밀어 넣는 분
• 테스트가 빨개지면 테스트를 고치는 분
• 남이 만든 엔진을 튜닝만 해 온 분
