필사 모드: 지금 주목받는 오픈소스 (3) 인프라와 데이터베이스

• 들어가며 — 이 판은 라이선스가 다시 짰다
• 스냅숏
• 분석 — 데이터를 옮기지 않고 묻기
• 포스트그레스를 확장하기
• 임베디드와 캐시
• 플랫폼과 IaC
• 도입 전 확인
• 링크

들어가며 — 이 판은 라이선스가 다시 짰다

인프라와 데이터베이스 영역이 지난 몇 년간 겪은 변화는 기술보다 라이선스에서 왔습니다. 널리 쓰이던 프로젝트들이 상업적 이용을 제한하는 라이선스로 옮겨 갔고, 그때마다 커뮤니티가 포크로 응답했습니다.

그래서 이 분야에서는 성능 비교보다 라이선스 확인이 먼저인 경우가 많습니다. 아래 목록은 순위가 아니라 해결하는 문제별로 묶은 지도입니다.

스냅숏

모두 2026-08-12 기준입니다.

분석 — 데이터를 옮기지 않고 묻기

duckdb/duckdb는 프로세스 안에서 도는 분석용 데이터베이스입니다. 서버가 없기 때문에 파이썬 노트북이나 CI 작업에서 파케이 파일을 그대로 질의할 수 있습니다. 예전 같으면 클러스터에 올렸을 규모의 집계가 노트북에서 끝나는 경우가 많아졌습니다. 반대로 여러 사용자가 동시에 쓰는 공용 웨어하우스 자리를 노린 물건은 아닙니다.

-- 예시: 원격 파케이 파일을 적재 없이 바로 집계
SELECT country, count(*) AS n
FROM read_parquet('s3://bucket/events/*.parquet')
GROUP BY country
ORDER BY n DESC
LIMIT 10;

ClickHouse/ClickHouse는 반대로 대규모 분석 질의를 상시로 받는 서버입니다. 컬럼 저장과 벡터화 실행으로 큰 테이블 집계를 빠르게 처리합니다. 갱신과 삭제가 잦은 워크로드나 다중 테이블 조인이 핵심인 설계에는 잘 맞지 않습니다.

risingwavelabs/risingwave는 스트림 처리 결과를 테이블처럼 유지하는 데이터베이스입니다. SQL로 실시간 집계를 정의하고 싶을 때 후보가 됩니다. 상태를 계속 들고 있어야 하는 구조라 운영 난도는 배치보다 높습니다.

포스트그레스를 확장하기

pgvector/pgvector는 포스트그레스에 벡터 타입과 유사도 검색 인덱스를 더합니다. 데이터가 이미 포스트그레스에 있다면 별도 벡터 데이터베이스를 도입하기 전에 먼저 시도해 볼 선택지입니다. 라이선스는 GitHub이 자동 분류하지 못하는데, LICENSE 파일을 열어 보면 포스트그레스 본체와 같은 계열의 허용적 라이선스 문구를 담고 있습니다.

cloudnative-pg/cloudnative-pg는 쿠버네티스에서 포스트그레스 클러스터를 운영하는 오퍼레이터입니다. 장애 조치와 백업 절차를 선언적으로 다룹니다. 다만 관리형 데이터베이스를 쓰다가 이쪽으로 옮기면, 그동안 클라우드 제공자가 대신하던 운영 책임이 팀으로 넘어옵니다.

electric-sql/pglite는 포스트그레스를 웹어셈블리로 빌드해 브라우저나 Node 안에서 돌립니다. 테스트와 로컬 우선 애플리케이션에 쓸 만합니다. 저장소가 2024년 2월에 생긴 젊은 프로젝트이므로 확장 지원 범위와 한계를 먼저 확인하세요.

임베디드와 캐시

tursodatabase/libsql은 SQLite에서 갈라져 나와 복제와 서버 모드를 더한 프로젝트입니다. 엣지 환경에서 읽기를 가깝게 두려는 설계에 맞습니다.

valkey-io/valkey는 레디스 라이선스 변경 이후 만들어진 포크이고, BSD 3조항을 유지합니다. 저장소가 2024년 3월에 생겼지만 코드베이스 자체는 오래 검증된 계보를 잇습니다. 라이선스 조건 때문에 대체재를 찾는 상황이라면 가장 직접적인 후보입니다.

nats-io/nats-server는 메시징과 스트리밍을 담당합니다. 2012년에 시작해 오래 운영된 프로젝트로, 카프카보다 가벼운 구성으로 요청과 응답, 발행과 구독을 함께 다루려 할 때 후보가 됩니다. 장기 보존과 대규모 재처리가 중심이라면 결이 다릅니다.

플랫폼과 IaC

siderolabs/talos는 쿠버네티스 노드 전용으로 설계된 리눅스 배포판입니다. SSH와 셸을 없애고 API로만 관리하게 만들어 공격 표면을 줄입니다. 익숙한 방식으로 서버에 들어가 고치는 운용을 유지하고 싶다면 맞지 않습니다.

opentofu/opentofu는 테라폼 라이선스 변경 이후 갈라져 나온 IaC 도구이고 MPL-2.0을 유지합니다. 기존 구성 자산을 두고 라이선스만 문제인 경우에 실질적인 선택지가 됩니다. 다만 상용 부가 기능과 제공자 생태계의 세부는 계속 갈라지고 있으니, 쓰는 모듈이 양쪽 모두에서 동작하는지 확인해야 합니다.

도입 전 확인

라이선스 전문을 직접 확인하고, 상업적 도입은 법무 검토를 거치세요. 이 글은 법률 자문이 아닙니다.

이 영역에서는 라이선스가 바뀐 전례가 실제로 있다는 점이 중요합니다. 지금 허용적 라이선스라는 사실이 앞으로도 그렇다는 보장은 아닙니다. 데이터베이스를 고를 때는 나갈 때의 비용을 함께 보세요. 데이터를 표준 형식으로 꺼낼 수 있는지, 프로토콜이 호환되는지, 마이그레이션 경로가 문서로 존재하는지가 라이선스 위험을 실제로 줄여 줍니다.

저장소 정보(스타 수·라이선스·최근 활동)는 2026-08-12에 GitHub에서 직접 확인한 시점 값입니다. 수치와 상태는 바뀝니다.

링크

시리즈: 이전 글 — 빌드·에디터·CLI·터미널 · 다음 글 — 관측 가능성과 보안

이 블로그의 관련 글:

• DuckDB 내부 구조 깊이 보기
• OpenTofu와 테라폼 비교
• SQLite 르네상스와 임베디드 복제
• PostgreSQL 내부 구조와 pgvector

도구: SQL 플레이그라운드