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

들어가며 — 인프라는 성능보다 운영 부담으로 교체됩니다
1. rkt
2. dockershim
3. Classic Swarm
4. Docker Machine
5. Compose V1
6. Heapster
7. Apache Mesos
8. PodSecurityPolicy
9. CoreOS Container Linux
10. ingress-nginx
11. Terraform과 Vagrant — 라이선스가 바꾼 경우
정리 — 인프라를 교체하는 것은 대개 사람 수입니다
함께 읽기
시리즈

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

프론트엔드 도구가 플랫폼 흡수로 교체된다면, 인프라 계층은 다른 이유로 교체됩니다. 운영 부담, 표준화, 그리고 그 표준을 유지할 사람의 수입니다. 아래 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에 직접 확인했습니다. 프로젝트는 다시 활발해지기도 하니 최신 상태는 직접 확인하세요.