데이터 저장소와 큐의 세대교체 — 라이선스, 포크, 그리고 Attic으로 간 프로젝트들

들어가며 — 이 계층에서는 코드보다 조건이 먼저 바뀝니다
1. Redis
2. Elasticsearch와 Kibana
3. MongoDB
4. Kafka의 ZooKeeper 의존
5. Apache Sqoop
6. Apache Oozie
7. Apache Giraph
8. Apache Tajo
9. RethinkDB
10. PrestoSQL — 이름이 바뀐 경우
정리 — 데이터 계층에서 봐야 할 세 가지 신호
함께 읽기
시리즈

들어가며 — 이 계층에서는 코드보다 조건이 먼저 바뀝니다

데이터 저장소는 교체 비용이 가장 큰 계층입니다. 그래서 여기서는 기술적 우열보다 배포 조건의 변화가 더 자주 이동을 만듭니다. 라이선스가 바뀌고, 포크가 생기고, 재단이 바뀝니다.

아래 항목은 공식 발표문, 저장소 상태, Apache Attic 기록처럼 날짜가 붙은 사실만 근거로 삼았습니다. 라이선스 변경은 누가 무엇에서 무엇으로 바꿨는지 사실만 적고 동기는 추측하지 않습니다.

1. Redis

무엇이었나 — BSD 3-Clause로 배포되던 인메모리 데이터 저장소입니다.
왜 그때 옳았나 — 지금도 옳습니다. 이건 기술이 아니라 배포 조건이 바뀐 사례입니다.
무엇이 바뀌었나 — 2024년 3월 20일 발표로 Redis 7.4부터 BSD 3-Clause 대신 RSALv2와 SSPLv1의 이중 라이선스로 전환했습니다. 같은 글은 이 변경으로 Redis가 OSI 정의의 오픈소스가 아니게 됨을 명시적으로 인정하고, 기존 릴리스는 소급 적용되지 않는다고 밝힙니다. 이후 2025년 5월 1일 발표로 Redis 8부터 OSI 승인 라이선스인 AGPLv3가 선택지로 추가되었습니다.
무엇이 그 자리에 왔나 — Valkey입니다. BSD 라이선스의 고성능 키값 저장소로 소개되며 리눅스 재단이 관리합니다.
무엇을 남겼나 — Redis 프로토콜과 자료구조 모델 자체가 사실상 업계 인터페이스가 되었습니다. 포크들이 모두 이 인터페이스를 유지한다는 점이 그 증거입니다.
지금도 쓰는 게 맞는 경우 — 대부분의 사용자입니다. 2025년 발표 이후 AGPLv3 선택지가 있으므로 OSI 라이선스를 요구하는 조직도 조건을 충족할 수 있습니다.

2. Elasticsearch와 Kibana

무엇이었나 — Apache 2.0으로 배포되던 검색·분석 엔진과 시각화 도구입니다.
왜 그때 옳았나 — 역색인 기반 검색을 분산으로 운영하는 표준적인 방법을 제공했습니다.
무엇이 바뀌었나 — Elastic이 2021년 1월 14일 발표로 7.11부터 SSPL과 Elastic License의 이중 라이선스로 전환했습니다. 이후 2024년 8월 29일 발표에서 AGPL을 선택지로 추가하며, 기존 라이선스를 없애는 것이 아니라 하나를 더하는 것이라고 밝혔습니다.
무엇이 그 자리에 왔나 — OpenSearch입니다. 2021년 1월 포크가 발표되고 같은 해 7월 1.0이 Apache 2.0으로 출시되었으며, 이후 리눅스 재단 산하 OpenSearch 소프트웨어 재단으로 이관되었습니다.
무엇을 남겼나 — 쿼리 DSL과 인덱스 운영 관행이 두 갈래 모두에서 유지되어 사실상 공통 인터페이스가 되었습니다.
지금도 쓰는 게 맞는 경우 — 대부분입니다. AGPL 선택지가 생겼으므로 라이선스 요건은 대체로 해소됩니다. 벤더 중립성이 조달 요건인 조직은 포크 쪽이 맞을 수 있습니다.

3. MongoDB

무엇이었나 — AGPL v3로 배포되던 문서 데이터베이스입니다.
왜 그때 옳았나 — 스키마 유연성이 실제 요구였던 시기가 있었고, 그 요구를 가장 잘 채운 제품이었습니다.
무엇이 바뀌었나 — 공식 FAQ에 따르면 2018년 10월 16일 이후 릴리스부터 SSPL로 전환했습니다. SSPL은 프로그램을 서비스로 제공하는 경우 그 서비스를 구성하는 소스 전체를 공개하도록 요구하며, 내부 전용 사용에는 이 조항이 적용되지 않습니다.
무엇이 그 자리에 왔나 — 이 경우 지배적인 포크는 형성되지 않았습니다. 대신 관계형 데이터베이스의 문서 타입 지원이 대안으로 자리 잡았습니다.
무엇을 남겼나 — SSPL이라는 라이선스 자체입니다. 이후 다른 프로젝트들이 같은 라이선스를 채택하면서 하나의 흐름이 되었습니다.
지금도 쓰는 게 맞는 경우 — 내부 사용이라면 FAQ 기준으로 문제가 없습니다. 관리형 서비스를 제3자에게 제공하려는 경우에만 조항을 확인해야 합니다.

4. Kafka의 ZooKeeper 의존

무엇이었나 — Kafka가 브로커 목록과 파티션 메타데이터를 저장하기 위해 함께 운영하던 별도 합의 시스템입니다.
왜 그때 옳았나 — 검증된 합의 구현을 새로 만드는 대신 빌려 쓰는 것은 초기 설계로는 합리적인 판단이었습니다.
무엇이 바뀌었나 — Kafka 4.0.0 릴리스 공지가 2025년 3월 18일 자로, 4.0이 ZooKeeper 없이 완전히 동작하는 첫 메이저 릴리스라고 밝힙니다. 기본이 KRaft 모드입니다.
무엇이 그 자리에 왔나 — KRaft입니다. 메타데이터 쿼럼이 Kafka 브로커 안으로 들어왔습니다.
무엇을 남겼나 — ZooKeeper가 증명한 것은 합의 기반 조정 서비스라는 범주 자체입니다. 여러 시스템이 이 범주에 의존하며 성장했고, 그중 다수가 이후 자체 구현으로 옮겨 갔습니다. ZooKeeper 프로젝트 자체는 계속 존재합니다.
지금도 쓰는 게 맞는 경우 — Kafka 3.x를 운영 중이라면 급할 것 없습니다. 다만 4.0으로 올릴 때 마이그레이션이 필수 경로가 됩니다.

5. Apache Sqoop

무엇이었나 — 관계형 데이터베이스와 Hadoop 사이의 대량 데이터 전송 도구입니다.
왜 그때 옳았나 — 배치 창에 맞춰 테이블을 통째로 옮기는 일은 실제 업무였고, 그걸 병렬화해 준 도구였습니다.
무엇이 바뀌었나 — Attic 기록에 따르면 2012년 3월 최상위 프로젝트가 되었고 2021년 6월 은퇴, 같은 해 7월 Attic 이관이 완료되었습니다.
무엇이 그 자리에 왔나 — Spark와 Flink 기반 적재 작업, 그리고 변경 데이터 캡처 방식의 파이프라인입니다.
무엇을 남겼나 — 스키마를 읽어 병렬 분할을 자동 결정한다는 접근입니다. 현대 적재 도구도 같은 문제를 같은 방식으로 풉니다.
지금도 쓰는 게 맞는 경우 — 이미 돌고 있는 배치를 유지하는 경우뿐입니다. Attic 프로젝트는 새 릴리스가 나오지 않습니다.

6. Apache Oozie

무엇이었나 — Hadoop 작업을 위한 워크플로 스케줄러입니다.
왜 그때 옳았나 — 작업 간 의존을 선언으로 표현하고 재시도와 시간 기반 실행을 붙인다는 발상은 지금 워크플로 도구의 원형입니다.
무엇이 바뀌었나 — Attic 기록에 따르면 2012년 8월 최상위 프로젝트가 되었고 2025년 2월 은퇴, 2025년 4월 이관이 완료되었습니다.
무엇이 그 자리에 왔나 — Airflow를 비롯한 코드 기반 워크플로 오케스트레이터입니다.
무엇을 남겼나 — 방향성 비순환 그래프로 배치를 표현한다는 모델입니다. XML이 파이썬으로 바뀌었을 뿐 구조는 같습니다.
지금도 쓰는 게 맞는 경우 — 기존 워크플로 유지뿐입니다.

7. Apache Giraph

무엇이었나 — 대규모 반복 그래프 처리 시스템입니다.
왜 그때 옳았나 — 정점 중심 프로그래밍 모델은 소셜 그래프 계산을 수십억 간선 규모로 끌어올렸습니다.
무엇이 바뀌었나 — Attic 기록에 따르면 2012년 5월 최상위 프로젝트가 되었고 2023년 9월 은퇴, 2024년 2월 이관이 완료되었습니다.
무엇이 그 자리에 왔나 — 범용 분산 엔진 위의 그래프 라이브러리, 그리고 전용 그래프 데이터베이스입니다.
무엇을 남겼나 — 정점 중심 계산 모델과 슈퍼스텝 개념입니다. 후속 프레임워크가 그대로 채택했습니다.
지금도 쓰는 게 맞는 경우 — 없습니다.

8. Apache Tajo

무엇이었나 — Hadoop 위에서 동작하는 데이터 웨어하우스 시스템입니다.
왜 그때 옳았나 — 배치 엔진을 거치지 않고 분산 SQL을 직접 실행한다는 방향은 이후 업계 전체가 간 길입니다.
무엇이 바뀌었나 — Attic 기록에 따르면 2014년 3월 최상위 프로젝트가 되었고 2020년 9월 은퇴, 2021년 4월 이관이 완료되었습니다.
무엇이 그 자리에 왔나 — Trino와 Spark SQL 계열, 그리고 클라우드 웨어하우스입니다.
무엇을 남겼나 — 분산 SQL 엔진이라는 범주가 옳았다는 확인, 그리고 한국 개발자 커뮤니티가 최상위 아파치 프로젝트를 이끈 기록입니다.
지금도 쓰는 게 맞는 경우 — 없습니다.

9. RethinkDB

무엇이었나 — 실시간 변경 구독을 일급 기능으로 제공한 문서 데이터베이스입니다.
왜 그때 옳았나 — 쿼리 결과의 변화를 애플리케이션이 구독한다는 발상은 당시로선 앞서 있었습니다.
무엇이 바뀌었나 — 2017년 2월 6일 공지에 따르면 회사는 문을 닫았지만 CNCF가 소스 코드 권리를 사들여 리눅스 재단에 기증했고, 코드는 관대한 Apache 2.0 라이선스로 재배포되었습니다. 같은 글은 프로젝트가 살아 있으며 개발이 중단 없이 이어질 수 있다고 밝혔습니다.
무엇이 그 자리에 왔나 — 변경 스트림을 제공하는 주류 데이터베이스들, 그리고 실시간 동기화를 제공하는 백엔드 서비스들입니다.
무엇을 남겼나 — 변경 구독이라는 기능 범주, 그리고 회사가 문을 닫아도 코드와 커뮤니티는 재단으로 이어질 수 있다는 선례입니다.
지금도 쓰는 게 맞는 경우 — 이미 운영 중인 시스템입니다. 새로 도입한다면 대체재가 훨씬 많습니다.

10. PrestoSQL — 이름이 바뀐 경우

무엇이었나 — 분산 SQL 쿼리 엔진의 한 갈래입니다.
왜 그때 옳았나 — 지금도 옳습니다. 이건 기술이 아니라 이름이 바뀐 사례입니다.
무엇이 바뀌었나 — 2020년 12월 27일 공지에서 원 개발자들이 프로젝트 이름을 Trino로 바꾼다고 밝혔습니다. 공지에 따르면 상표 문제가 계기였습니다.
무엇이 그 자리에 왔나 — Trino입니다. 같은 사람들이 같은 코드베이스를 이어갑니다.
무엇을 남겼나 — 프로젝트 이름과 상표가 코드와 별개의 자산이라는 사실, 그리고 그 분리가 실제 운영에 영향을 준다는 사례입니다.
지금도 쓰는 게 맞는 경우 — 이름만 바뀐 것이므로 그대로 쓰면 됩니다. 문서를 검색할 때 두 이름이 섞여 나온다는 점만 알면 됩니다.

정리 — 데이터 계층에서 봐야 할 세 가지 신호

첫째, 라이선스 조항과 그 변경 이력입니다. 이 계층에서는 코드 품질보다 이 조항이 먼저 이동을 만듭니다. 다만 Redis와 Elastic 사례가 보여 주듯 방향이 한쪽으로만 흐르지도 않습니다. 두 프로젝트 모두 이후 OSI 승인 라이선스를 선택지로 되돌려 놓았습니다.

둘째, 재단 소속입니다. RethinkDB는 회사가 사라진 뒤에도 재단 이관으로 살아남았고, Apache Attic 기록은 은퇴 날짜를 공개 문서로 남깁니다. 거버넌스가 문서화된 프로젝트는 최소한 상태를 확인할 수 있습니다.

셋째, 본체가 외부 의존을 흡수하는 흐름입니다. Kafka가 ZooKeeper를 걷어낸 것처럼, 운영 부담이 큰 외부 의존은 결국 본체로 들어오거나 걷혀 나갑니다. 지금 운영 중인 시스템에 별도로 돌리는 조정 서비스가 있다면 그 로드맵을 확인해 둘 가치가 있습니다.

상태 정보는 2026-08-12에 직접 확인했습니다. 프로젝트는 다시 활발해지기도 하니 최신 상태는 직접 확인하세요.