Skip to content
←

Split View: 컨테이너 인프라의 세대교체 — 자리를 내준 11개 프로젝트가 남긴 것

✨ Learn with Quiz
|

컨테이너 인프라의 세대교체 — 자리를 내준 11개 프로젝트가 남긴 것

들어가며 — 인프라는 성능보다 운영 부담으로 교체됩니다

프론트엔드 도구가 플랫폼 흡수로 교체된다면, 인프라 계층은 다른 이유로 교체됩니다. 운영 부담, 표준화, 그리고 그 표준을 유지할 사람의 수입니다. 아래 11개는 모두 자기 시대에 널리 쓰였고, 대부분 후속 경로가 공식 문서에 적혀 있습니다. 공식 공지, 메인테이너의 공개 성명, 저장소 보관 여부처럼 날짜가 붙은 사실을 확인한 항목만 넣었습니다.

1. rkt

  • 무엇이었나 — CoreOS가 만든 대안 런타임입니다. 데몬 없이 실행하고 pod를 일급 단위로 다뤘습니다.
  • 왜 그때 옳았나 — 컨테이너 실행이 단일 벤더의 데몬에 묶여 있다는 문제의식은 정당했습니다. 표준 없는 시장에 표준을 요구한 프로젝트였습니다.
  • 무엇이 바뀌었나 — 저장소가 2020년 2월 24일 보관되었고, README는 프로젝트가 종료되었으며 개발과 유지보수 활동이 모두 멈췄다고 밝힙니다.
  • 무엇이 그 자리에 왔나 — containerd와 CRI-O, 그리고 데몬리스 실행 모델은 Podman이 이어받았습니다.
  • 무엇을 남겼나 — 컨테이너 이미지와 실행을 표준화하라는 압력입니다. 이 압력이 OCI 표준으로 이어졌고 지금 모든 런타임이 그 위에 있습니다.
  • 지금도 쓰는 게 맞는 경우 — 없습니다. 보관된 저장소이며 후속 경로가 분명합니다.

2. dockershim

  • 무엇이었나 — 쿠버네티스가 Docker Engine과 통신하기 위해 자체적으로 들고 있던 어댑터 코드입니다.
  • 왜 그때 옳았나 — CRI가 없던 시절 쿠버네티스가 쓸 수 있는 런타임은 Docker뿐이었고, 이 코드가 없었으면 초기 채택이 불가능했습니다.
  • 무엇이 바뀌었나 — 쿠버네티스 v1.24에서 제거되었습니다. 공식 FAQ는 이 코드가 처음부터 임시 해법으로 의도되었다고 설명하며, docker build로 만든 이미지는 모든 CRI 구현에서 그대로 동작한다고 명시합니다.
  • 무엇이 그 자리에 왔나 — containerd와 CRI-O 같은 CRI 호환 런타임입니다.
  • 무엇을 남겼나 — CRI라는 인터페이스 자체입니다. 어댑터를 걷어내려면 먼저 규약을 만들어야 한다는 순서를 보여 준 사례입니다.
  • 지금도 쓰는 게 맞는 경우 — 없습니다. 다만 이미지 빌드 도구로서의 Docker는 아무 영향을 받지 않았습니다.

3. Classic Swarm

  • 무엇이었나 — 여러 도커 호스트를 하나처럼 보이게 하던 첫 오케스트레이션 프로젝트입니다.
  • 왜 그때 옳았나 — 기존 도커 API를 그대로 쓰면서 클러스터로 확장한다는 설계는 학습 비용이 거의 없었습니다.
  • 무엇이 바뀌었나 — 저장소가 2021년 2월 1일 보관되었고, README는 더 이상 활발히 개발되지 않는다고 밝히며 Docker Engine 내장 Swarm 모드나 다른 오케스트레이션 시스템을 권합니다.
  • 무엇이 그 자리에 왔나 — Docker Engine에 내장된 Swarm 모드, 그리고 쿠버네티스입니다.
  • 무엇을 남겼나 — 기존 API 호환을 유지한 채 분산으로 확장한다는 발상, 그리고 오케스트레이션은 별도 계층이어야 한다는 결론입니다.
  • 지금도 쓰는 게 맞는 경우 — Classic Swarm은 없습니다. Swarm 모드는 별개이며 여전히 동작합니다.

4. Docker Machine

  • 무엇이었나 — 가상 머신과 클라우드에 도커 호스트를 만들고 관리해 주던 도구입니다.
  • 왜 그때 옳았나 — 리눅스가 아닌 노트북에서 도커를 쓰려면 VM이 필요했고, 그 관리를 자동화한 것은 실질적 가치였습니다.
  • 무엇이 바뀌었나 — 저장소가 2025년 7월 18일 보관되었고, 도커 공식 문서의 폐기 목록이 더 이상 유지보수되지 않으며 Docker Desktop이나 Docker Engine을 직접 쓰라고 안내합니다.
  • 무엇이 그 자리에 왔나 — Docker Desktop, 그리고 원격 엔드포인트를 다루는 docker context입니다.
  • 무엇을 남겼나 — 여러 도커 엔드포인트를 이름으로 전환한다는 개념이 컨텍스트 기능으로 남았습니다.
  • 지금도 쓰는 게 맞는 경우 — 없습니다. 공식 문서가 대체 경로를 지정하고 있습니다.

5. Compose V1

  • 무엇이었나 — 파이썬으로 작성된 초기 docker-compose 명령입니다.
  • 왜 그때 옳았나 — 여러 컨테이너를 파일 하나로 선언하는 방식이 로컬 개발 경험을 바꿨습니다.
  • 무엇이 바뀌었나 — 도커가 2023년 1월 31일 블로그에서 2023년 6월 이후 지원하지 않고 이후 Docker Desktop에서 제거한다고 밝혔습니다. 폐기 목록도 유지보수되지 않으니 V2로 옮기라고 안내합니다.
  • 무엇이 그 자리에 왔나 — Go로 다시 작성되어 도커 CLI에 통합된 Compose V2, 즉 docker compose입니다.
  • 무엇을 남겼나 — Compose 파일 포맷입니다. 구현은 바뀌었지만 사람들이 쓰는 선언 형식은 그대로 남았습니다.
  • 지금도 쓰는 게 맞는 경우 — 없습니다. 대부분의 경우 하이픈만 빼면 그대로 동작합니다.

6. Heapster

  • 무엇이었나 — 쿠버네티스 클러스터의 메트릭을 모으던 초기 컴포넌트입니다.
  • 왜 그때 옳았나 — 오토스케일링에 쓸 CPU와 메모리 수치를 모아야 했는데 당시엔 표준 API가 없었습니다.
  • 무엇이 바뀌었나 — 저장소가 2018년 12월 1일 보관되었고, README가 은퇴 상태임을 명시하며 변경을 하지 않겠다고 밝힙니다.
  • 무엇이 그 자리에 왔나 — 같은 README가 오토스케일링용으로 metrics-server를, 일반 모니터링으로는 프로메테우스 형식 메트릭을 수집하는 도구를 권합니다.
  • 무엇을 남겼나 — 오토스케일링용 리소스 메트릭과 일반 모니터링을 분리한다는 결론입니다. 지금의 메트릭 API 구조가 여기서 나왔습니다.
  • 지금도 쓰는 게 맞는 경우 — 없습니다. 보관된 지 오래되었습니다.

7. Apache Mesos

  • 무엇이었나 — 데이터센터 단위의 자원 격리와 공유를 담당하던 클러스터 매니저입니다.
  • 왜 그때 옳았나 — 쿠버네티스 이전에 수만 대 규모 클러스터를 실제로 운영한 소수의 시스템이었고, 자원 제안 기반 이중 스케줄링은 지금 봐도 정교합니다.
  • 무엇이 바뀌었나 — Apache Attic 페이지에 따르면 2013년 6월 최상위 프로젝트가 되었고 2025년 8월 은퇴, 2025년 10월 Attic 이관이 완료되었습니다. Attic은 개발과 릴리스 권한이 없는 읽기 전용 관리 조직입니다.
  • 무엇이 그 자리에 왔나 — 쿠버네티스입니다. 같은 페이지가 Clusterd라는 커뮤니티 포크도 함께 안내합니다.
  • 무엇을 남겼나 — 이중 스케줄링과 프레임워크 개념, 그리고 데이터센터를 하나의 자원 풀처럼 다룰 수 있다는 증명입니다.
  • 지금도 쓰는 게 맞는 경우 — 이미 운영 중인 클러스터를 유지하는 경우입니다. 새로 도입할 근거는 찾기 어렵습니다.

8. PodSecurityPolicy

  • 무엇이었나 — 파드가 요구하는 권한을 클러스터 차원에서 제한하던 쿠버네티스 내장 API입니다.
  • 왜 그때 옳았나 — 특권 컨테이너와 호스트 마운트를 막을 표준 수단이 필요했고, 정책을 API 객체로 표현한다는 방향은 옳았습니다.
  • 무엇이 바뀌었나 — 공식 블로그가 v1.21에서 폐기 예고되었고 v1.25에서 제거되었다고 밝힙니다. 같은 글이 더 쉽고 지속 가능한 대체재를 개발 중이라고 적었습니다.
  • 무엇이 그 자리에 왔나 — Pod Security Admission과 Pod Security Standards, 그리고 정책 엔진 계열 도구입니다.
  • 무엇을 남겼나 — 파드 보안 기준을 어드미션 단계에서 강제한다는 개념입니다. 대체재도 같은 위치에서 같은 일을 합니다.
  • 지금도 쓰는 게 맞는 경우 — 없습니다. API 자체가 존재하지 않습니다.

9. CoreOS Container Linux

  • 무엇이었나 — 컨테이너 실행만을 목표로 한 최소 리눅스 배포판으로, 자동 업데이트와 불변 루트 파일시스템이 특징이었습니다.
  • 왜 그때 옳았나 — 서버를 고치지 말고 통째로 교체하라는 모델을 OS 수준에서 강제한 첫 사례에 가깝습니다.
  • 무엇이 바뀌었나 — 레드햇 공식 페이지가 2020년 5월 26일 마지막 업데이트가 배포되었고 이후 발견된 버그나 보안 취약점은 고쳐지지 않는다고 밝힙니다.
  • 무엇이 그 자리에 왔나 — 같은 페이지가 Fedora CoreOS를 공식 후속으로 지목합니다.
  • 무엇을 남겼나 — 불변 OS와 자동 업데이트, 부팅 시 선언적 프로비저닝의 조합입니다. 지금의 컨테이너 최적화 배포판 대부분이 이 형태입니다.
  • 지금도 쓰는 게 맞는 경우 — 없습니다. 보안 수정이 나오지 않습니다.

10. ingress-nginx

  • 무엇이었나 — 쿠버네티스 Ingress를 구현하는 가장 널리 쓰인 컨트롤러입니다.
  • 왜 그때 옳았나 — 익숙한 nginx 설정을 그대로 쓰면서 라우팅을 붙일 수 있었고, 어노테이션으로 거의 모든 요구를 흡수했습니다.
  • 무엇이 바뀌었나 — SIG Network와 보안 대응 위원회가 2025년 11월 11일 공지로 2026년 3월 은퇴를 예고했고, 2026년 1월 29일 성명으로 이를 재확인했습니다. 저장소는 2026년 3월 24일 보관되었습니다. 공지는 수년간 한두 명이 여가 시간에 유지해 왔다는 점, 임의 설정을 허용하던 유연성이 감당할 수 없는 기술 부채가 되었다는 점을 이유로 듭니다.
  • 무엇이 그 자리에 왔나 — Gateway API 구현체들, 그리고 문서에 정리된 다른 Ingress 컨트롤러들입니다.
  • 무엇을 남겼나 — Ingress 컨트롤러가 무엇을 해야 하는지에 대한 사실상의 기준, 그리고 확장 지점을 무제한으로 열면 보안 표면도 무제한이 된다는 교훈입니다.
  • 지금도 쓰는 게 맞는 경우 — 없습니다. 성명은 은퇴 이후에도 계속 쓰는 선택이 사용자를 공격에 노출시킨다고 경고했습니다. 다만 기존 배포는 계속 동작하고 설치 자산도 남아 있습니다.

11. Terraform과 Vagrant — 라이선스가 바꾼 경우

  • 무엇이었나 — 인프라 정의와 개발 환경 프로비저닝의 사실상 표준 도구들입니다.
  • 왜 그때 옳았나 — 지금도 옳습니다. 이 항목은 코드 품질이 아니라 배포 조건이 바뀐 사례입니다.
  • 무엇이 바뀌었나 — HashiCorp가 2023년 8월 10일 발표로 이후 제품 릴리스를 MPL 2.0에서 BUSL 1.1로 전환했습니다. 같은 글은 경쟁 제품을 제공하는 경우를 빼면 상업적 사용도 계속 가능하며, API와 SDK 등은 MPL 2.0으로 남는다고 밝힙니다.
  • 무엇이 그 자리에 왔나 — Terraform에 대해서는 OpenTofu가 2024년 1월 10일 1.6.0으로 정식 출시되었습니다. 리눅스 재단 프로젝트이며 커뮤니티 주도 포크로 스스로를 소개합니다.
  • 무엇을 남겼나 — 도구 자체는 그대로입니다. 남은 것은 의존성을 고를 때 라이선스 조항과 그 변경 가능성도 함께 봐야 한다는 실무 감각입니다.
  • 지금도 쓰는 게 맞는 경우 — 대부분의 사용자입니다. 경쟁 제품을 제공하는 사업이 아니라면 발표문 기준으로 제약이 없습니다. 조직 정책이 OSI 승인 라이선스를 요구할 때만 포크를 검토하면 됩니다.

정리 — 인프라를 교체하는 것은 대개 사람 수입니다

이 목록에서 성능이 이유였던 항목은 거의 없습니다. dockershim과 PodSecurityPolicy는 표준화가, Classic Swarm과 Mesos는 생태계 집중이, ingress-nginx는 유지보수 인력이 원인이었습니다.

특히 마지막 사례가 시사적입니다. 공지에 따르면 클라우드 네이티브 환경의 절반가량이 쓰던 컴포넌트를 한두 명이 여가 시간에 유지하고 있었습니다. 의존성의 위험은 코드 품질이 아니라 그 코드를 유지할 수 있는 사람의 수에 있습니다. 이건 스타 수로는 보이지 않습니다.

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

함께 읽기

시리즈

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

The Generational Shift in Container Infrastructure — What Eleven Projects Left Behind

Introduction — infrastructure is replaced by operational burden, not performance

If frontend tooling is replaced by platform absorption, the infrastructure layer is replaced for different reasons: operational burden, standardisation, and the number of people available to maintain that standard. All eleven below were widely used in their day, and for most of them the successor path is written down in official documentation. Only entries where a dated fact — an official notice, a public maintainer statement, or repository archive status — was confirmed at the source made the list.

1. rkt

  • What it was — an alternative container runtime from CoreOS. It ran without a daemon and treated the pod as a first-class unit.
  • Why it was right at the time — the concern that container execution was tied to a single vendor's daemon was legitimate. It was a project that demanded a standard of a market that had none.
  • What changed — the repository was archived on 24 February 2020, and the README states that the project has ended and all development and maintenance activity has halted.
  • What took its place — containerd and CRI-O, while Podman inherited the daemonless execution model.
  • What it left behind — the pressure to standardise container images and execution. That pressure led to the OCI standards, and every runtime today sits on top of them.
  • When it is still right — never. The repository is archived and the successor path is clear.

2. dockershim

  • What it was — adapter code Kubernetes carried itself in order to talk to Docker Engine.
  • Why it was right at the time — before CRI existed, Docker was the only runtime Kubernetes could actually use; without this code early adoption would have been impossible.
  • What changed — it was removed in Kubernetes v1.24. The official FAQ explains that the code was always intended as a temporary solution, and states that images produced by docker build work with all CRI implementations.
  • What took its place — CRI-compatible runtimes such as containerd and CRI-O.
  • What it left behind — the CRI interface itself. It is a case study in the correct order of operations: to remove an adapter, first define a contract.
  • When it is still right — never. Note, though, that Docker as an image-build tool was entirely unaffected.

3. Classic Swarm

  • What it was — the first Docker orchestration project, making many Docker hosts look like one.
  • Why it was right at the time — extending to a cluster while keeping the existing Docker API had almost no learning cost.
  • What changed — the repository was archived on 1 February 2021, and the README states that it is no longer actively developed, recommending the Swarm mode built into Docker Engine or another orchestration system.
  • What took its place — Swarm mode inside Docker Engine, and Kubernetes.
  • What it left behind — the idea of scaling out to a distributed system while preserving API compatibility, and the conclusion that orchestration belongs in its own layer.
  • When it is still right — not Classic Swarm. Swarm mode is a separate thing and still works.

4. Docker Machine

  • What it was — a tool that created and managed Docker hosts on virtual machines and cloud providers.
  • Why it was right at the time — using Docker on a non-Linux laptop required a VM, and automating that management was real value.
  • What changed — the repository was archived on 18 July 2025, and Docker's official retired list states that it is no longer maintained and directs users to Docker Desktop or Docker Engine directly.
  • What took its place — Docker Desktop, and docker context for handling remote endpoints.
  • What it left behind — the concept of switching between multiple Docker endpoints by name, which survives as the context feature.
  • When it is still right — never. The official documentation designates a replacement path.

5. Compose V1

  • What it was — the original docker-compose command, written in Python.
  • Why it was right at the time — declaring several containers in a single file changed the local development experience.
  • What changed — Docker stated in a blog post on 31 January 2023 that support would not be provided after June 2023 and that it would be removed from future Docker Desktop releases. The retired list likewise says it is no longer maintained and directs users to V2.
  • What took its place — Compose V2, rewritten in Go and integrated into the Docker CLI as docker compose.
  • What it left behind — the Compose file format. The implementation changed, but the declarative form people write survived intact.
  • When it is still right — never. In most cases dropping the hyphen is the whole migration.

6. Heapster

  • What it was — the early component that collected metrics for a Kubernetes cluster.
  • Why it was right at the time — CPU and memory figures for autoscaling had to be gathered somewhere, and there was no standard API at the time.
  • What changed — the repository was archived on 1 December 2018, and the README marks it as retired and states that no changes will be made.
  • What took its place — the same README recommends metrics-server for autoscaling and Prometheus-format metric collectors for general monitoring.
  • What it left behind — the conclusion that resource metrics for autoscaling and general monitoring should be separated. Today's metrics API structure came out of that.
  • When it is still right — never. It has been archived for a long time.

7. Apache Mesos

  • What it was — a cluster manager handling resource isolation and sharing at datacentre scale.
  • Why it was right at the time — it was one of very few systems that actually ran clusters of tens of thousands of machines before Kubernetes, and offer-based two-level scheduling is still an elegant design.
  • What changed — per the Apache Attic page, it became a Top Level Project in June 2013, retired in August 2025, and the move to the Attic completed in October 2025. The Attic is a read-only custodian with no authority to develop or release.
  • What took its place — Kubernetes. The same page also points to a community fork called Clusterd.
  • What it left behind — two-level scheduling and the framework concept, plus the proof that a datacentre can be treated as a single resource pool.
  • When it is still right — maintaining a cluster you already run. It is hard to find grounds for adopting it fresh.

8. PodSecurityPolicy

  • What it was — a built-in Kubernetes API that constrained the privileges a pod could request, cluster-wide.
  • Why it was right at the time — there had to be a standard way to block privileged containers and host mounts, and expressing policy as an API object was the right direction.
  • What changed — the official blog states it was deprecated in v1.21 and removed in v1.25. The same post said an easier and more sustainable replacement was in development.
  • What took its place — Pod Security Admission and the Pod Security Standards, plus policy-engine tooling.
  • What it left behind — the concept of enforcing pod security baselines at the admission stage. The replacements do the same job in the same position.
  • When it is still right — never. The API itself no longer exists.

9. CoreOS Container Linux

  • What it was — a minimal Linux distribution aimed solely at running containers, characterised by automatic updates and an immutable root filesystem.
  • Why it was right at the time — it comes close to being the first case of enforcing "replace the server, don't repair it" at the OS level.
  • What changed — Red Hat's official page states that the final updates were rolled out on 26 May 2020 and that bugs or security vulnerabilities discovered after that date will not be fixed.
  • What took its place — the same page names Fedora CoreOS as the official successor.
  • What it left behind — the combination of an immutable OS, automatic updates and declarative provisioning at boot. Most container-optimised distributions today follow that shape.
  • When it is still right — never. No security fixes are produced.

10. ingress-nginx

  • What it was — the most widely used controller implementing Kubernetes Ingress.
  • Why it was right at the time — you could attach Kubernetes routing while writing familiar nginx configuration, and annotations absorbed almost any requirement.
  • What changed — SIG Network and the Security Response Committee announced retirement for March 2026 in a notice dated 11 November 2025 and reconfirmed it in a statement on 29 January 2026. The repository was archived on 24 March 2026. The notices cite that one or two people maintained it in their spare time for years, and that the flexibility of allowing arbitrary configuration became insurmountable technical debt.
  • What took its place — Gateway API implementations, and the other Ingress controllers listed in the documentation.
  • What it left behind — a de facto standard for what an Ingress controller should do, and the lesson that opening extension points without limit makes the security surface unlimited too.
  • When it is still right — never. The statement warns that staying on it after retirement leaves you and your users vulnerable to attack. Existing deployments do keep working and installation artifacts remain available.

11. Terraform and Vagrant — the case where the license changed

  • What it was — the de facto standard tools for infrastructure definition and development-environment provisioning.
  • Why it was right at the time — they still are. This entry is about distribution terms changing, not code quality.
  • What changed — HashiCorp moved subsequent product releases from MPL 2.0 to BUSL 1.1 in an announcement on 10 August 2023. The same post states that commercial use remains possible except where providing a competitive offering, and that APIs, SDKs and most other libraries stay MPL 2.0.
  • What took its place — for Terraform, OpenTofu reached general availability as 1.6.0 on 10 January 2024. It is a Linux Foundation project and describes itself as a community-driven fork.
  • What it left behind — the tools themselves are unchanged. What remains is the practical instinct that license terms, and the possibility of them changing, belong in the dependency evaluation.
  • When it is still right — for most users. Unless you are in the business of providing a competitive offering, the announcement imposes no constraint. A fork is worth considering only when organisational policy requires an OSI-approved license.

Conclusion — what replaces infrastructure is usually headcount

Performance was almost never the reason on this list. Standardisation drove dockershim and PodSecurityPolicy; ecosystem consolidation drove Classic Swarm and Mesos; maintainer headcount drove ingress-nginx.

That last case is the instructive one. According to the notice, a component used by roughly half of cloud native environments was being maintained by one or two people in their spare time. The risk in a dependency lies not in code quality but in the number of people who can maintain that code. Star counts do not show this.

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 (this post)
  3. Data stores and queues
  4. Languages, frameworks and runtimes
  5. What replaces technology