컨테이너의 역사 — 사내 실험에서 표준까지 12년의 검증 과정

TL;DR — 쿠버네티스는 구글이 십여 년 동안 컨테이너를 운영한 경험에서 나왔고, 2006년 사내 실험에서 2018년 CNCF 졸업까지 12년에 걸쳐 어디서나 실행되는 표준이 되었습니다.

2026년 프로덕션 운영 환경에서 쿠버네티스 도입을 검토하는 인프라 담당자와 의사결정권자가 왜 이 기술을 믿어도 되는지 판단하려면 컨테이너의 역사부터 알아야 합니다. 이 글은 컨테이너의 역사를 다룬 클라우드네이티브TV 영상, 곧 클라우드네이티브TV가 공개한 영상 ‘쿠버네티스의 뿌리는 구글 내부 시스템이었다 — 컨테이너의 시작 | 입문 2′(3분 41초)가 어떤 방식으로 구글 컨테이너 운영과 12년의 흐름, 이식성의 의미를 설명하는지 캡처 6장과 함께 주장 단위로 풀어 정리했습니다. 구글 컨테이너 이야기를 영상으로 보지 않은 담당자도 도입 보고서에 쓸 근거를 가져갈 수 있게 썼습니다.

클라우드네이티브TV의 이 영상은 3분 41초 동안 지금은 표준이 된 기술이 처음에는 한 회사의 사내 실험이었다는 이야기를 따라갑니다. 구글이 모든 서비스를 컨테이너로 돌린다는 사실에서 출발해 사내 실험이 커뮤니티로 나온 과정, 2006년부터 2018년까지의 시간순, 그리고 표준이 되면서 얻은 가장 큰 힘인 이식성으로 이어집니다.

영상에서 다루는 순서는 다음과 같습니다.

• 표준이 되면서 얻은 가장 큰 힘, 어디서나 실행된다는 점 (0:19)
• 구글은 모든 서비스를 컨테이너로 돌린다 (1:10)
• 십여 년의 운영 경험을 cgroups와 쿠버네티스로 나눈 방식 (1:48)
• 2006년부터 2018년까지 12년의 시간순 (2:23)
• 2018년 CNCF의 첫 졸업 프로젝트 (2:42)
• 한 번 정의하면 어디서나, 하이브리드와 엣지까지 (3:27)

컨테이너의 역사에 관한 영상의 설명을 질문으로 바꾸면 여섯 가지입니다. 아래 여섯 개 절이 이 순서대로 답하고, 그 뒤에 영상 밖의 보충 두 절을 덧붙였습니다.

1. 쿠버네티스의 뿌리가 구글이라고 말하는 근거는 무엇인가?
2. 구글은 어떤 방식으로 십여 년의 운영 경험을 커뮤니티에 나눴는가?
3. 컨테이너가 사내 실험에서 표준이 되기까지 12년은 어떤 흐름인가?
4. 2018년 CNCF 졸업은 도입 판단에 무엇을 뜻하는가?
5. 표준이 되면서 얻은 가장 큰 힘은 무엇인가?
6. 하이브리드와 엣지까지 같은 워크로드가 실행된다는 말은 무엇을 없애는가?

영상은 첫 주장을 한 문장으로 던집니다. 쿠버네티스의 뿌리는 구글이라는 것입니다. 이 주장은 구글이 서비스를 돌리는 방식으로 뒷받침됩니다. 구글은 지메일과 검색, 지도, 유튜브까지 모든 서비스를 컨테이너로 돌리고, 이렇게 매주 새로 만들어지는 컨테이너가 이십억 개를 넘습니다.

▲ 주당 20억 개 컨테이너 (영상 1:10)

캡처 오른쪽 위의 큰 파란 상자에는 20억+라는 숫자가 적혀 있고, 그 아래로 10+와 2008이라는 숫자가 나란히 놓여 있습니다. 왼쪽에는 구글이 업무를 처리하는 방식이 목록으로 정리돼 있습니다. 이 한 장이 말하는 것은 컨테이너가 구글에서 실험 단계의 기술이 아니라 일상의 운영 단위라는 점입니다.

영상은 이 개념을 공장에 빗댑니다. 똑같은 규격의 상자에 제품을 담아 컨베이어에 올리는 모습을 떠올리라는 것입니다. 상자 규격이 같으면 어느 라인에 올려도 그대로 흘러갑니다. 컨테이너도 애플리케이션과 그 실행 환경을 같은 규격으로 묶어 두기 때문에 어느 서버에서든 같은 방식으로 다룰 수 있습니다.

주당 20억이라는 숫자가 도입 담당자에게 주는 의미는 규모의 검증입니다. 쿠버네티스를 검토하는 조직은 대개 컨테이너 수십 개나 수백 개를 상정하지만, 이 기술의 원형이 된 운영 경험은 그보다 훨씬 큰 규모에서 쌓였습니다. 다만 영상이 말한 것은 구글의 운영 규모와 그 경험이 공개되었다는 사실이고, 그 규모가 곧바로 우리 조직의 성공을 보장한다는 뜻은 아닙니다. 규모의 검증과 우리 환경의 적합성은 따로 점검해야 합니다. 컨테이너의 역사에서 이 숫자는 규모의 증거일 뿐 적합성의 증거는 아닙니다.

두 번째 주장은 구글이 십여 년간 쌓은 운영 경험을 혼자 갖고 있지 않았다는 것입니다. 영상은 공개의 방식을 두 갈래로 말합니다. 하나는 cgroups를 리눅스 커널에 기여한 것이고, 다른 하나는 구글 내부에서 쓰던 도구를 쿠버네티스로 공개한 것입니다.

▲ cgroups 기여와 쿠버네티스 공개 (영상 1:48)

캡처에서는 10+ 년간 프로덕션 컨테이너 운영 경험 상자에 붉은 테두리가 쳐져 있고, 왼쪽 아래 ‘커뮤니티에 지식을 공유’ 목록에서 cgroups를 리눅스 커널에 기여했다는 줄과 내부 도구 설계를 오픈소스 쿠버네티스 프로젝트로 공개했다는 줄이 밑줄로 강조됩니다. 옆의 2008 상자는 cgroups가 리눅스 커널에 병합된 해를 가리킵니다.

이 두 갈래는 층이 다릅니다. cgroups는 커널 층의 기능으로, 프로세스가 쓸 수 있는 자원을 묶고 제한하는 토대입니다. 쿠버네티스는 그 위의 운영 층으로, 수많은 컨테이너를 어디에 놓고 어떻게 살려 둘지 정하는 도구입니다. 영상이 두 가지를 함께 꼽은 까닭은 구글이 기술의 밑바닥과 운영의 꼭대기를 모두 공개했다는 점을 보여 주기 위해서입니다.

공개의 방식이 중요한 이유는 도입 위험과 연결됩니다. 특정 기업만 아는 내부 도구라면 그 기업이 방향을 바꾸는 순간 사용자는 갈 곳이 없습니다. 반면 커널에 들어간 기능과 공개된 도구는 누구나 읽고 고칠 수 있어서, 이후 영상이 말하는 열린 거버넌스의 출발점이 됩니다. 컨테이너의 역사에서 이 공개의 순간이 신뢰의 출발점입니다.

영상은 그다음 장면에서 컨테이너의 역사를 연대순으로 한 줄에 세웁니다. 이 기술의 나이를 세어 보면 생각보다 오래되었다는 말로 시작합니다. 출발은 2006년, 구글 사내의 프로세스 컨테이너 실험이었습니다. 2008년에는 cgroups가 리눅스 커널에 정식으로 들어갔고, 2013년에는 도커가 나오면서 컨테이너가 널리 퍼졌습니다. 이듬해인 2014년에는 쿠버네티스의 첫 커밋이 올라갔고, 2015년에는 CNCF가 만들어지며 정식 1.0 버전이 나왔습니다. 마지막이 2018년입니다.

▲ 2006년부터 2018년까지의 타임라인 (영상 2:23)

캡처의 가로선 위쪽에는 2006년 프로세스 컨테이너(구글 사내 시작), 2013년 도커 공개, 2015년 보그 논문, 2018년 CNCF 졸업이 놓여 있고, 아래쪽에는 2008년 cgroups(리눅스 2.6.24 커널 병합), 2014년 쿠버네티스(첫 깃허브 커밋), 2015년 CNCF 결성(1.0 릴리스)이 번갈아 배치돼 있습니다. 위아래로 엇갈린 배치 덕분에 한눈에 사내 실험, 커널 기능, 도구의 대중화, 오케스트레이션의 등장, 재단의 결성, 졸업이라는 흐름이 읽힙니다. 영상은 이 흐름을 십이 년에 걸쳐 천천히 표준이 된 것이라고 요약하고, 씨앗을 심고 열매를 거두기까지 걸리는 시간에 빗댑니다.

컨테이너의 역사에서 표준이 되는 데 12년이 걸렸다는 사실은 두 가지로 읽힙니다. 하나는 기술이 하루아침에 만들어진 유행이 아니라 오랜 시간 검증된 흐름이라는 점입니다. 다른 하나는 조직의 도입도 한 번에 끝나지 않는다는 점입니다. 기술이 12년에 걸쳐 자랐다면, 그 기술을 받아들이는 조직의 준비도 단계를 나눠 진행하는 편이 현실적입니다. 컨테이너의 역사가 보여 주는 가장 실용적인 교훈은 속도보다 단계입니다.

영상의 타임라인은 2018년, CNCF의 첫 졸업 프로젝트에서 끝납니다. 쿠버네티스가 재단의 프로젝트 가운데 가장 먼저 졸업했다는 뜻입니다.

▲ 2018년 CNCF 첫 졸업 프로젝트 (영상 2:42)

같은 타임라인에서 오른쪽 끝의 2018 CNCF Graduate 상자와 2015년 CNCF 결성 상자에 붉은 테두리가 쳐져 있습니다. 영상은 이 시점을 두고 사내 실험이 12년에 걸쳐 표준이 되었다는 결론을 내립니다.

도입 담당자에게 졸업은 성숙도의 표지로 읽힙니다. 재단이 프로젝트를 단계별로 나누어 관리한다면, 졸업은 그 가운데 가장 높은 단계에 올랐다는 신호입니다. 영상은 졸업의 세부 요건을 설명하지 않으므로, 그 요건은 재단의 공식 자료에서 확인해야 합니다. 이 글의 보충 절에서 확인 경로를 정리했습니다. 컨테이너의 역사에서 졸업은 마지막 단계에 해당합니다.

여기서 기억할 점은 졸업이 곧 우리 조직에 맞는다는 보증은 아니라는 사실입니다. 졸업은 프로젝트의 거버넌스와 성숙도에 관한 이야기이고, 도입 가능성은 우리 애플리케이션과 팀의 준비에 달려 있습니다.

영상은 이 장면을 가장 먼저 보여 주고, 본편에서 다시 설명합니다. 표준이 되면서 얻은 가장 큰 힘은 어디서나 돌아간다는 점입니다. 베어메탈 서버든 온프레미스든 상관없고, 퍼블릭 클라우드와 하이브리드, 그리고 엣지까지 같은 워크로드를 그대로 올립니다.

▲ 어디서나 실행된다는 표준의 힘 (영상 0:19)

캡처에는 베어메탈, 온프레미스, 퍼블릭 클라우드, 프라이빗 클라우드, 하이브리드 클라우드, 엣지·IoT라는 여섯 장의 카드가 놓여 있고, 그중 퍼블릭 클라우드 카드에 붉은 테두리가 쳐져 있습니다. 카드 속에는 쿠버네티스를 제공하는 대표적인 관리형 서비스 이름이 함께 적혀 있습니다. 맨 아래 띠는 한 번 정의한 워크로드를 모든 환경에서 동일하게 실행한다는 문장을 담고 있습니다.

영상은 이 원리를 표준 콘센트에 빗댑니다. 플러그 모양이 같으니 어느 나라에 가도 그대로 꽂힙니다. 한 번 정의해 두면 환경이 바뀌어도 다시 만들 필요가 없다는 설명입니다. 이 비유에서 콘센트는 쿠버네티스의 표준 인터페이스이고, 플러그는 우리가 정의한 워크로드입니다.

의사결정권자에게 이 장면은 도입 판단의 핵심 기준입니다. 도입 비용을 따질 때 흔히 서버 값과 인력 값만 보지만, 나중에 옮길 수 있는가도 비용입니다. 환경이 바뀌어도 다시 만들 필요가 없다면 그만큼 미래의 이전 비용이 줄어듭니다. 컨테이너의 역사가 남긴 가장 실용적인 유산이 바로 이 이식성입니다.

영상의 마지막 장면은 이식성이 가져오는 결과를 말합니다. 이렇게 옮겨 다닐 수 있다는 것이 특정 공급자에 대한 종속을 없앱니다. 그리고 그것이 바로 열린 거버넌스가 목표로 삼은 지점이라는 설명으로 맺습니다.

▲ 하이브리드와 엣지까지 같은 워크로드 (영상 3:27)

이번 캡처는 같은 카드 화면에서 하이브리드 클라우드와 엣지·IoT 카드가 함께 강조된 장면입니다. 아래 띠에는 이식성이 특정 공급자에 대한 종속을 제거한다는 문장이 적혀 있습니다. 앞 장면이 퍼블릭 클라우드를 보여 주었다면, 이번 장면은 한 곳에 묶이지 않는다는 결론을 보여 줍니다.

연결은 이렇게 이어집니다. 구글이 경험을 커널과 오픈소스로 공개했기 때문에 쿠버네티스는 특정 기업의 제품이 아니게 되었고, 재단이 거버넌스를 맡기 때문에 방향이 한 회사에 좌우되지 않으며, 그 결과 어느 환경에서도 같은 방식으로 실행됩니다. 영상은 컨테이너의 역사를 개방, 거버넌스, 이식성, 종속 제거의 순서로 한 줄에 꿰었습니다. 컨테이너의 역사를 도입 판단에 쓸 때 가장 실용적인 대목이 여기이며, 컨테이너의 역사 전체가 이 결론을 향해 흘러왔다고 볼 수 있습니다.

영상은 2006년 구글 사내의 프로세스 컨테이너를 출발점으로 잡지만, 격리 기술의 흐름은 그보다 앞에서 시작됩니다. 아래 표는 공개된 기술 문서와 쿠버네티스 공식 문서가 다루는 배경을 시간순으로 정리한 것입니다.

표에서 보듯 컨테이너의 역사는 한 번에 만들어진 것이 아니라 격리, 자원 제한, 이미지 배포, 오케스트레이션이라는 층이 하나씩 쌓인 결과입니다. 영상이 2008년 cgroups와 2013년 도커, 2014년 쿠버네티스를 한 줄에 놓은 것도 이 층의 순서를 보여 주는 장치로 읽을 수 있습니다.

쿠버네티스의 선행 시스템으로는 구글의 클러스터 관리 시스템 보그(Borg)가 널리 알려져 있습니다. 보그의 설계와 운영 교훈은 구글의 논문과 쿠버네티스 공식 블로그에 정리돼 있으며, 쿠버네티스가 그 경험을 이어받은 오픈소스라는 점을 확인할 수 있습니다. 자세한 내용은 쿠버네티스 블로그: 보그, 쿠버네티스의 전신과 구글 논문: 보그를 이용한 대규모 클러스터 관리에서 볼 수 있습니다.

CNCF가 쿠버네티스를 첫 졸업 프로젝트로 발표한 소식은 CNCF 졸업 발표에 있고, 쿠버네티스가 무엇을 제공하는지에 대한 공식 개요는 쿠버네티스 공식 문서: Overview에 있습니다. 구글 데이터센터에서 시작된 컨테이너 혁명의 맥락은 쿠버네티스가 필요한 이유 — 구글 데이터센터에서 시작된 컨테이너 혁명에서 더 읽을 수 있습니다.

컨테이너의 역사를 안다는 것이 곧바로 도입 결정이 되지는 않습니다. 다만 영상이 제시한 네 가지 사실을 점검 질문으로 바꾸면 도입 회의에서 쓸 기준이 됩니다. 아래 표는 영상의 주장을 질문으로 옮긴 것입니다.

세 번째 줄이 특히 중요합니다. 기술이 12년에 걸쳐 자랐다는 사실은 조직의 준비도 단계별로 점검해야 한다는 뜻으로 읽을 수 있습니다. 애플리케이션을 컨테이너로 만들고, 배포 설정을 코드로 관리하고, 권한을 역할별로 나누는 일은 도구를 바꾸는 일과 별개로 진행됩니다. 도입 전후의 변화는 쿠버네티스 도입 전후 비교에, 도입을 망설이게 하는 오해는 쿠버네티스 도입을 막는 오해와 장벽 12가지에 정리돼 있습니다.

종속을 피한다는 목표도 점검이 필요합니다. 쿠버네티스가 이식성을 주더라도 관리형 서비스의 고유 기능이나 저장소, 네트워크 설정에 깊이 기대면 옮기기 어려워집니다. 영상이 말한 이식성은 표준 인터페이스 위에서 정의했을 때의 이야기이므로, 설계 단계에서 표준 기능과 공급자 고유 기능을 나눠 두어야 합니다. 클러스터의 구성 요소를 먼저 이해하려면 쿠버네티스 아키텍처 완벽 정리를, 도커와의 관계는 쿠버네티스 vs 도커 차이 정리를 참고할 수 있습니다.

컨테이너의 역사를 한 줄로 줄이면 구글의 사내 실험이 12년에 걸쳐 열린 표준이 되었다는 것입니다.

쿠버네티스의 뿌리는 어디인가요?

구글입니다. 구글이 모든 서비스를 컨테이너로 운영하며 쌓은 경험이 쿠버네티스로 공개되었습니다. 영상은 구글이 지메일, 검색, 지도, 유튜브까지 컨테이너로 돌리고 매주 20억 개가 넘는 컨테이너를 만든다고 설명하며, 십여 년의 운영 경험이 cgroups와 쿠버네티스로 나뉘었다고 말합니다.

컨테이너의 역사는 언제부터 시작되나요?

영상은 2006년 구글 사내의 프로세스 컨테이너 실험을 출발점으로 봅니다. 2008년 cgroups가 리눅스 커널에 들어가고, 2013년 도커가 컨테이너를 대중화했으며, 2014년 쿠버네티스의 첫 커밋, 2015년 CNCF 결성과 1.0 릴리스, 2018년 CNCF 첫 졸업으로 이어집니다.

쿠버네티스가 표준이 되기까지 얼마나 걸렸나요?

영상의 타임라인으로 2006년부터 2018년까지 12년이 걸렸습니다. 영상은 사내 실험이 12년에 걸쳐 천천히 표준이 되었다고 요약하며, 씨앗을 심고 열매를 거두기까지의 시간에 빗댑니다.

cgroups와 쿠버네티스는 무엇이 다른가요?

cgroups는 자원을 묶고 제한하는 커널 기능이고, 쿠버네티스는 그 위에서 컨테이너를 배치하고 살려 두는 운영 도구입니다. 영상은 구글이 이 두 가지를 모두 공개해 기술의 밑바닥과 운영 층을 함께 나눴다고 설명합니다.

표준이 되면서 얻은 가장 큰 힘은 무엇인가요?

베어메탈부터 엣지까지 어디서나 같은 워크로드를 실행할 수 있는 이식성입니다. 영상은 표준 콘센트에 빗대어, 한 번 정의해 두면 환경이 바뀌어도 다시 만들 필요가 없다고 설명합니다.

이식성이 특정 공급자 종속을 없앤다는 것은 무슨 뜻인가요?

워크로드를 다른 환경으로 옮길 수 있으므로 한 공급자에 묶이지 않는다는 뜻이며, 열린 거버넌스의 목표이기도 합니다. 다만 관리형 서비스의 고유 기능에 깊이 기대면 옮기기 어려워지므로 표준 기능 위에서 설계해야 합니다.

컨테이너의 역사를 더 깊이 살펴볼 때 볼 원 영상과 이어서 읽을 글, 공식 문서를 모았습니다.

• 쿠버네티스(Kubernetes)란 무엇인가 — 개념과 도입 이유
• 쿠버네티스가 필요한 이유 — 구글 데이터센터에서 시작된 컨테이너 혁명
• 쿠버네티스 아키텍처 완벽 정리 — 컨트롤 플레인부터 워커 노드까지
• 쿠버네티스 vs 도커 차이 완벽 정리 — 관계와 언제 무엇을 쓸까
• 컨테이너와 쿠버네티스 — 각각의 역할과 함께 쓰는 이유
• 쿠버네티스 도입 전후 비교 — 운영자가 알아야 할 변화
• 쿠버네티스 도입을 막는 오해와 장벽 12가지
• 쿠버네티스 운영 자동화 — 이해해야 신뢰할 수 있는 이유
• 쿠버네티스의 뿌리는 구글 내부 시스템이었다 — 컨테이너의 시작 | 입문 2 — 클라우드네이티브TV, 이 글이 정리한 원 영상
• 쿠버네티스 공식 문서: Overview — 쿠버네티스가 제공하는 기능의 전체 개요
• 쿠버네티스 블로그: 보그, 쿠버네티스의 전신 — 구글 내부 시스템과 쿠버네티스의 관계
• 구글 논문: 보그를 이용한 대규모 클러스터 관리 — 구글의 클러스터 운영 경험
• CNCF 졸업 발표 — 쿠버네티스의 첫 졸업