Skip to content
←

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

✨ Learn with Quiz
|

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

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

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

아래 항목은 공식 발표문, 저장소 상태, 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에 직접 확인했습니다. 프로젝트는 다시 활발해지기도 하니 최신 상태는 직접 확인하세요.

함께 읽기

시리즈

  1. 빌드와 프론트엔드 도구
  2. 인프라와 컨테이너
  3. 데이터 저장소와 큐 (이 글)
  4. 언어와 프레임워크, 런타임
  5. 무엇이 기술을 교체시키는가

The Generational Shift in Data Stores and Queues — Licenses, Forks and the Apache Attic

Introduction — in this layer the terms change before the code does

Data stores carry the highest replacement cost of any layer. That is exactly why movement here is driven more often by changes in distribution terms than by technical merit. Licenses change, forks appear, foundations change hands.

Every entry below rests on dated facts only: official announcements, repository state, Apache Attic records. For license changes I state who moved what from where to where, and do not speculate about motive.

1. Redis

  • What it was — an in-memory data store distributed under BSD 3-Clause.
  • Why it was right at the time — it still is. This is a case of distribution terms changing, not technology.
  • What changed — an announcement on 20 March 2024 moved Redis from BSD 3-Clause to dual RSALv2 and SSPLv1 licensing beginning with Redis 7.4. The same post explicitly acknowledges that this means Redis is no longer open source under the OSI definition, and states that the change is not retroactive. Later, an announcement on 1 May 2025 added the OSI-approved AGPLv3 as an option starting with Redis 8.
  • What took its place — Valkey, presented as a BSD-licensed high-performance key/value datastore and stewarded by the Linux Foundation.
  • What it left behind — the Redis protocol and data-structure model became an effective industry interface. That every fork preserves it is the proof.
  • When it is still right — for most users. Since the 2025 announcement, AGPLv3 is available, so organisations that require an OSI license can satisfy that requirement.

2. Elasticsearch and Kibana

  • What it was — a search and analytics engine and its visualisation tool, distributed under Apache 2.0.
  • Why it was right at the time — it provided the standard way to operate inverted-index search in a distributed fashion.
  • What changed — Elastic moved to dual SSPL and Elastic License terms from 7.11 in an announcement on 14 January 2021. Later, an announcement on 29 August 2024 added AGPL as an option, stating that this adds an option rather than removing anything.
  • What took its place — OpenSearch. The fork was announced in January 2021, 1.0 shipped under Apache 2.0 that July, and the project later moved to the OpenSearch Software Foundation under the Linux Foundation.
  • What it left behind — the query DSL and index operations practices persist on both branches, making them an effective common interface.
  • When it is still right — for most users. With the AGPL option the license question is largely resolved. Organisations whose procurement requires vendor neutrality may prefer the fork.

3. MongoDB

  • What it was — a document database distributed under AGPL v3.
  • Why it was right at the time — there was a period when schema flexibility was the actual requirement, and this was the product that served it best.
  • What changed — per the official FAQ, releases on or after 16 October 2018 moved to the SSPL. The SSPL requires that if you make the program available to third parties as a service, you make the service source code available; that clause does not apply to internal-only use.
  • What took its place — no dominant fork formed in this case. Instead, document-type support in relational databases became the alternative.
  • What it left behind — the SSPL itself. Other projects subsequently adopted the same license, which turned it into a trend.
  • When it is still right — for internal use there is no issue under the FAQ. Only if you intend to offer a managed service to third parties do you need to read the clause.

4. Kafka's ZooKeeper dependency

  • What it was — a separate consensus system Kafka ran alongside itself to store broker lists and partition metadata.
  • Why it was right at the time — borrowing a proven consensus implementation instead of writing one was a reasonable initial design decision.
  • What changed — the Kafka 4.0.0 release announcement, dated 18 March 2025, states that 4.0 is the first major release to operate entirely without Apache ZooKeeper. KRaft mode is the default.
  • What took its place — KRaft. The metadata quorum moved inside the Kafka brokers.
  • What it left behind — what ZooKeeper proved is the category of a consensus-based coordination service. Many systems grew while depending on that category, and a number of them later moved to their own implementations. The ZooKeeper project itself continues to exist.
  • When it is still right — if you run Kafka 3.x there is no rush. The migration simply becomes mandatory when you move to 4.0.

5. Apache Sqoop

  • What it was — a bulk data transfer tool between relational databases and Hadoop.
  • Why it was right at the time — moving whole tables inside a batch window was real work, and this parallelised it.
  • What changed — per the Attic record, it became a Top Level Project in March 2012, retired in June 2021, and completed the move to the Attic in July 2021.
  • What took its place — Spark and Flink based ingestion jobs, and change-data-capture pipelines.
  • What it left behind — the approach of reading the schema to decide parallel splits automatically. Modern ingestion tools solve the same problem the same way.
  • When it is still right — only to keep an existing batch running. Attic projects produce no new releases.

6. Apache Oozie

  • What it was — a workflow scheduler for Hadoop jobs.
  • Why it was right at the time — expressing dependencies between jobs declaratively and attaching retries and time-based execution is the archetype of today's workflow tooling.
  • What changed — per the Attic record, it became a Top Level Project in August 2012, retired in February 2025, and completed the move in April 2025.
  • What took its place — code-driven workflow orchestrators such as Airflow.
  • What it left behind — the model of expressing batches as a directed acyclic graph. XML became Python; the structure is the same.
  • When it is still right — only to maintain existing workflows.

7. Apache Giraph

  • What it was — a system for large-scale iterative graph processing.
  • Why it was right at the time — the vertex-centric programming model pushed social graph computation to billions of edges.
  • What changed — per the Attic record, it became a Top Level Project in May 2012, retired in September 2023, and completed the move in February 2024.
  • What took its place — graph libraries on general-purpose distributed engines, and dedicated graph databases.
  • What it left behind — the vertex-centric computation model and the superstep concept, adopted directly by later frameworks.
  • When it is still right — never.

8. Apache Tajo

  • What it was — a data warehouse system running on Hadoop.
  • Why it was right at the time — executing distributed SQL directly rather than going through a batch engine is the direction the whole industry later took.
  • What changed — per the Attic record, it became a Top Level Project in March 2014, retired in September 2020, and completed the move in April 2021.
  • What took its place — the Trino and Spark SQL families, and cloud warehouses.
  • What it left behind — confirmation that the distributed SQL engine category was the right one, and a record of a Korean developer community leading an Apache Top Level Project.
  • When it is still right — never.

9. RethinkDB

  • What it was — a document database that offered real-time change subscriptions as a first-class feature.
  • Why it was right at the time — the idea that an application subscribes to changes in a query result was ahead of its time.
  • What changed — per the announcement of 6 February 2017, the company shut down, but the CNCF purchased the source code rights and contributed them to the Linux Foundation, with the code redistributed under the permissive Apache 2.0 license. The same post states that the project is alive and that development can continue without disruption.
  • What took its place — mainstream databases offering change streams, and backend services offering real-time sync.
  • What it left behind — the change-subscription feature category, plus a precedent that code and community can continue through a foundation even when the company closes.
  • When it is still right — systems already in production. For something new there are far more alternatives.

10. PrestoSQL — the case where the name changed

  • What it was — one branch of a distributed SQL query engine.
  • Why it was right at the time — it still is. This is a case of a name changing, not technology.
  • What changed — in an announcement on 27 December 2020, the original developers stated that the project was being renamed Trino. According to the announcement, a trademark issue was the trigger.
  • What took its place — Trino. The same people continue with the same codebase.
  • What it left behind — the fact that a project name and its trademark are assets separate from the code, and a case study showing that separation has real operational consequences.
  • When it is still right — only the name changed, so carry on. You just need to know that both names appear when you search the documentation.

Conclusion — three signals to watch in the data layer

First, the license terms and their history of change. In this layer those terms move people before code quality does. But as Redis and Elastic show, the direction is not one-way: both later restored an OSI-approved license as an option.

Second, foundation affiliation. RethinkDB survived the company's closure through a foundation transfer, and Apache Attic records leave retirement dates as public documents. A project with documented governance at least lets you check its state.

Third, the trend of the core absorbing external dependencies. As Kafka removed ZooKeeper, external dependencies with a heavy operational burden eventually get pulled into the core or stripped out. If you run a separate coordination service today, its roadmap is worth checking.

Status information was verified directly on 2026-08-12. Projects sometimes become active again, so check the current state yourself.

Related reading

Series

  1. Build and frontend tooling
  2. Infrastructure and containers
  3. Data stores and queues (this post)
  4. Languages, frameworks and runtimes
  5. What replaces technology