DevOpsDays 런던 발표를 계기로, 컨테이너가 등장한 배경과 Docker의 핵심 혁신(공유 가능한 이미지, 불변 배포), Kubernetes의 배포 중심 진화와 DevOps 문화에 미친 영향, 데이터베이스·스토리지 선택의 변화, 현재 클라우드 리소스 낭비와 효율의 양극화, AI와 ‘지루한 기술’ 선택 문화, 그리고 앞으로 필요한 변화 예산에 대해 성찰한다.
2025년 10월 10일
요즘 이곳은 대략 이런 모습입니다.
최근 DevOpsDays 런던에서 발표를 했습니다. 멋진 컨퍼런스였고, 모든 주최자들의 노고에 감사드립니다.
영상은 여기 있습니다 https://www.youtube.com/watch?v=eMU2mZgo99c
아래는 발표의 대략적인 개요로, 실제로 말한 내용과는 조금 다릅니다!
몇 년 전, 저는 Broadcom의 VMware 인수와 관련해 FTC(미 연방거래위원회)의 질문에 답변하는 데 시간을 꽤 쏟았습니다. 그들은 VM과 컨테이너가 경쟁 관계인지, VMware를 둘러싼 경쟁 구도를 이해하려고 했습니다.
이는 Docker 초창기 5년을 떠올리게 했습니다. 그때는 모두가 컨테이너와 VM을 비교하길 원했죠. 컨테이너는 그저 가벼운 VM인가? 컨테이너는 불안정해서 사람들이 결국 좋은 옛날 VM으로 돌아가지 않겠는가?
제가 FTC에 들려준 이야기는 혁신이 각기 다른 성장 국면에서 나왔다는 것이었습니다. VM은 조직에 컴퓨터가 급증했을 때 이를 관리하기 위해 등장했습니다. 당시 시스템은 대부분 수작업으로 관리되어 관리가 엉망이었고, 활용률도 낮았습니다(15% 미만). 설치도 수동으로 해야 해서 시간이 많이 걸렸죠. 통합을 통해 하드웨어 비용과 Windows 서버 라이선스 비용을 절감했습니다.
리눅스 세계에서는 이런 문제가 좀 덜했습니다. 하나의 서버에서 여러 애플리케이션을 더 잘 돌렸으니까요. 그래도 많은 서버가 저활용 상태이긴 했습니다.
하지만 컨테이너는 그 다음 문제를 해결하려고 등장했습니다. 컴퓨터가 너무 많아서가 아니라, 애플리케이션이 너무 많아졌고 이를 관리할 도구가 필요했기 때문입니다. 기업들은 더 많은 개발자를 채용했고, 개발자들은 더 많은 애플리케이션을 만들었습니다. Dotcloud는 PaaS 회사였고 이런 문제를 직접 겪으면서, 자사 플랫폼에 애플리케이션을 배포하기 위해 Docker를 만들었습니다. 중요한 것은 격리가 아니라 패키징이었습니다.
어쨌든 그게 제 설명이었습니다. 엔터프라이즈 입장에서는 컨테이너가 클라우드로의 이동의 일부였고, 비효율적인 VM을 그대로 클라우드로 리프트 앤 시프트하고 싶지는 않았습니다. 초창기에는 마이크로소프트가 우리 고객들에게 전화를 걸어 데이터센터를 Azure로 바꿔도 눈치채지 못할 것이라고, 모든 VM이 그대로 Azure에서 돌아갈 것이라고 말하곤 했습니다. 클라우드와 함께 컨테이너로의 전환을 강제하는 것은 일종의 현대화를 밀어붙이는 수단이었고, 많은 경우 Windows에서 Linux로의 전환이기도 했습니다.
Docker는 소프트웨어 사용 방식을 크게 바꾸지 않았기 때문에 도입이 쉬웠습니다.
하나의 핵심 혁신이 있었는데, 바로 공유 가능한 이미지 레지스트리인 Docker Hub였습니다. 실행 가능한 GitHub 같은 것. VM에는 이런 게 사실상 없었습니다. 가장 가까운 것은 Vagrant Cloud 정도였지만, 완전히 구성된 이미지는 공유가 잘 되지 않습니다(그리고 엄청 큽니다). 많은 사람이 재사용할 수 있으려면, 특정 사용 사례에 딱 맞춘 최종 구성 상태여서는 소용이 없습니다. 덜 특화될수록 더 널리 쓰일 수 있죠. Cloud Init 같은 도구로 일부 구성을 제거하면서 VM 이미지가 약간은 더 재사용 가능해졌지만, 여전히 컨테이너 이미지 같은 더 세분화된 구성 요소에 비하면 훨씬 더 특정화되어 있습니다. 그리고 VM 이미지는 컸고, 네트워크는 더 느렸습니다. LLM은 VM 이미지보다 더 크지만 그건 또 다른 이야기죠.
혁신 한 가지와 함께 금기 한 가지도 있었습니다. Docker는 제자리에서 업데이트하는 대신 이미지를 다시 빌드하고 재배포하도록 만들었습니다. 범위가 단일 애플리케이션이었기에 관리 가능했고, 아마 우리가 프로덕션에서 업데이트할 수 있다고 아무에게도 말하지 않았기 때문일지도 모릅니다. 누군가 컨테이너에 ftp로 접속해 PHP를 고치는 도구를 만들지 않은 게 늘 신기했습니다. 불변성은 훌륭합니다. 유용한 보안 속성이 많고, 대부분은 아직 제대로 실현되지 않았지만, 어쨌든 배포를 단순화했죠. 이에 대해서는 뒤에서 더 이야기하겠습니다.
Docker는 Go를 신뢰받는 프로그래밍 언어로 만들기도 했습니다. 이제 대부분의 현대 언어는 표준 라이브러리에 TLS 스택을 포함합니다. Docker 이전에는 YouTube가 Go의 주요 사용자였는데, 이제 컨테이너 안에서는 Node, Java, Python 다음으로 네 번째로 인기 있는 언어가 되었습니다.
컨테이너 초기, Kubernetes가 나오기 전과 막 나왔을 때만 해도, 사람들은 컨테이너 오케스트레이션을 스케줄링의 문제라고 생각했습니다. 컨퍼런스에서 스케줄러 트랙만 한 줄을 채우기도 했죠. 하지만 Kubernetes 초기 사용자들과 이야기해보면, 그들은 그저 배포 스크립트를 쓰려 하고 있었을 뿐입니다.
Docker Swarm은 배포 스크립트를 작성할 수 없게 했습니다. 보안팀은 클러스터 내부에서 배포할 수 있게 하면 보안 모델이 깨진다고 판단했죠. 수년 동안 우리가 판매한 상용 제품은 상상할 수 있는 최악의 배포 경험을 제공했습니다. 웹 페이지의 텍스트 박스에 YAML 파일을 붙여넣는 방식이었으니까요. 회사 문화 전체가 배포를 사실상 무시했습니다. 하지만 오랫동안 사람들이 Kubernetes로 가장 하고 싶었던 것은 바로 배포였습니다. 결국 우리는 제대로 된 배포 도구와 GitOps 같은 배포 철학을 갖추게 되었죠.
초기에는 사람들이 컨테이너나 Kubernetes에서 데이터베이스를 돌릴까를 끊임없이 물었습니다. 그러던 어느 시점에 사람들은 왜 우리가 데이터베이스를 직접 돌리는지 스스로 묻기 시작했고, 데이터를 모두 잃을 위험을 감수하면서 조금의 비용을 아끼는 것보다, 차라리 클라우드 제공업체에게 데이터베이스 운영을 맡기는 편을 선택했습니다. 이것이 얼마나 컨테이너 스토리지가 덧없고 삭제하기 쉬워 보였기 때문인지 궁금하긴 합니다. 컨테이너를 삭제하기 쉬우면, 상태를 가진 것들의 수명주기를 관리하는 잡무가 완전히 달라집니다. 그리고 스토리지 스택의 선택지도 너무 많았습니다. NFS인지, 블록 스토리지인지, 또 다른 것인지?
배포에 대한 집중과 Kubernetes의 복잡성은 예전의 DevOps를 죽였습니다. 운영에서 개발로 돌아온 전직 운영자로서, 저는 DevOps의 커뮤니티를 잇는 면모를 늘 사랑했습니다. 하지만 시간이 흐르며 DevOps는 Kubernetes와 기타 배포 기술을 다루는 백엔드 역할과 직함으로 축소되었습니다. 사람들은 문화보다 기술과 더 쉽게 관계를 맺는 듯했고, 기술은 점점 문화를 거스르기 시작했습니다.
Docker는 개발 자체를 크게 바꾸지 않았습니다. 한동안은 로컬 개발 환경을 구성하는 데 Vagrant의 역할을 대체할 것처럼 보였지만, Docker 내부에서 개발을 쾌적하게 만들기 위해 많은 노력이 있었음에도 실제로 그렇게 개발하는 사람은 거의 없습니다. 클라우드 환경에서 어느 정도 그렇게 하는 경우가 있긴 하지만, 그것도 사실상 원격 리눅스 박스에 더 가깝죠. Python과 Ruby는 가상환경 도구를 정리했고, 정말로 재현 가능한 로컬 개발 환경이 필요하다면 Nix를 사용할 수 있습니다. 사람들이 Docker로 하는 일은 개발 또는 테스트를 위해 데이터베이스나 다른 서비스를 띄우는 것입니다.
지난 10년 동안 애플리케이션은 오픈소스 구성 요소를 조합해 만드는 방식이 지배적이 되었습니다. 하지만 이것은 대체로 언어별 패키지 관리자에 의해 지원되었고, 서로 매우 다릅니다. 우리는 보편적인 빌드 추상화로 귀결되지 못했습니다. 불변성은 무엇이 실행되고 있는지 아는 데는 훌륭했지만, 의존성과 애플리케이션의 규모가 맞물리며 우리가 생각한 만큼 유용하지는 않았습니다.
가상화는 하드웨어가 용량의 15%만 사용되던 시절에 도입되었습니다. Datadog의 2024년 Cloud Costs 보고서에 따르면 “컨테이너 비용의 83%가 유휴 리소스와 연관되어 있다”고 합니다. 우리가 구축한 기술이 낭비를 얼마나 더 정확히 측정할 수 있게 되었는지를 잘 보여줍니다.
우리가 낭비하는 컴퓨팅은 최소 10배는 더 싸졌지만, 이제는 자동화를 통해 대규모로 낭비할 수 있게 되었습니다. 컨테이너 사용의 상당 부분은 모바일 앱을 구동하기 위한 것이었고, 그 모바일 폰 CPU가 Arm 서버로 변형되어 애플리케이션을 실행하는 데 사용되고 있습니다.
우리는 곳곳에서 효율이 나는 영역을 만들었지만, 10년이 지난 지금도 여전히 긴 비효율의 꼬리가 남아 있습니다. 또, AI는 비용이 충분히 크다면 우리가 애플리케이션을 엄청나게 개선할 수 있음을 보여주었습니다. 추론 비용은 매우 빠른 속도로 떨어지고 있습니다.
‘지루한 기술을 선택하라(Choose Boring Technology)’라는 에세이는 2015년에 쓰였고, 그때 컨테이너는 확실히 지루한 기술이 아니었습니다. 다만 지루하지 않은 기술의 예로 든 것은 Consul과 MongoDB였죠. 지루한 기술은 MySQL, Postgres, PHP, Python, Memcached, Squid, Cron이었습니다. 지금은? ChatGPT는 Docker를 “대체로 지루함”, Kubernetes를 “지루해지는 중”이라고 하더군요.
이제 지루한 것을 선택하는 것이 문화의 일부가 되어가고 있습니다. 10년이 걸렸네요. 아마 AI가 모든 변화 예산을 빨아들였기 때문일 겁니다. 클라우드 네이티브와 초저금리(ZIRP) 스타트업 시대의 종말과 맞물려서요. LLM은 우리의 문화도 학습되어 있어 지루한 기술에 강합니다.
다른 무언가를 원한다면, 변화 예산을 다시 추가해야 할 것입니다.
