최근 Medium이나 LinkedIn 피드를 둘러보면 ‘Kubernetes는 이제 끝났다’, ‘오히려 운영 비용만 증가시키는 Kubernetes’라는 제목의 아티클이 꽤 여럿 보인다.
수 년간 Kubernetes를 꾸준히 공부하고 애용하던 나로서는 그런 글들을 마주할 때마다 마음이 뒤숭숭했다. ‘복잡한 YAML 문법이 오히려 생산성을 해친다’고 하거나 ‘배보다 배꼽이 더 큰 격’이라는 의견에 대해 반박할 논리를 혼자서 고민해보다가도, 앞으로 Kubernetes는 정말 지는 해가 되는 것은 아닌지 덜컥 겁이 나던 것이다.
AI 시대에 개발자는 어떻게 일해야 할 것인가를 깊게 고민하던 찰나에 마주한 Kubernetes 비관론은 나에게 더 크게 다가왔는데, 역설적이게도 그 과정에서 오히려 Kubernetes를 어떻게 바라보고 있었는지 정리하는 계기가 되었다. 더불어 이런 고민이 생길 수밖에 없었던 이유도 돌아볼 수 있었기에 여기서 공유하고자 한다.
나에게 Kubernetes는 무엇이든 해줄 것 같은 만능 도구였다
Kubernetes에 대해 처음 접한 것은 백엔드 개발자로 일하던 때였다. 당시 개발 중인 웹 서비스를 배포하기 위해 AWS의 ECS(Elastic Container Service)를 사용하고 있었는데, 이는 컨테이너 이미지를 실행하고 상태 관리 및 Auto-scaling이 가능한 관리형 서비스였다.
ECS를 공부하기 위해 웹 서치를 하면 Kubernetes라는 키워드가 꼭 함께 등장했다. 당시 재직 중이던 회사가 스타트업인지라 AWS 비용에 예민할 때였는데, ECS처럼 Auto-scaling을 제공하면서 오픈소스라고 하는 Kubernetes에 관심이 안 갈 수가 없었다.
그렇게 Kubernetes에 대해 공부하기 시작했고, 얼마 안 가서 ECS와 1:1로 비교할 수 있는 체급이 아님을 깨달았다. 오히려 온프레미스 서버에 클라우드 환경을 만들어주는 플랫폼이라고 인식하게 되면서 훨씬 더 큰 매력을 느낀 것이다.
이후 DevOps 엔지니어로 이직을 하고 나서 Kubernetes 클러스터 운영을 지원하는 업무를 맡게 되었고, 클러스터 네트워크와 스토리지 관리 같은 더 디테일한 부분도 고민할 수 있었다. 본격적으로 Kubernetes를 사용하기 시작한 것이다.
자연스레 Kubernetes에 대한 몰입이 깊어져만 갔다. 인프런에 Kubernetes의 기본 리소스만으로 로그 모니터링 시스템을 구축하는 강의를 제작하고, CNCF의 관련 자격증들을 취득해 Kubestronaut 타이틀도 획득했다. Kubernetes에 대해 궁금한 동료 개발자들을 위해 사내 강의도 진행했다.
(Aiden’s Lab 뉴스레터의 첫 아티클도 Kubernetes 업데이트 소식이었다.)
이렇다 보니 최근 Kubernetes에 대한 비관론이나 악평에 마음이 아플 수밖에 없었다. 한편으론 나도 어렴풋이 인지하고 있던 단점들이었기에 흔들리기도 했다.
그러다 문득 그런 생각이 들었다.
‘내가 Kubernetes에게 너무 많은 기대를 하고 있는 것은 아닐까?‘
Kubernetes는 스스로를 만능 해결사라고 한 적이 없었다
Kubernetes 공식 문서에서는 이렇게 명시되어 있다.
Kubernetes는 컨테이너화된 워크로드와 서비스를 관리하기 위한 이식 가능하고 확장 가능한 오픈소스 플랫폼이다.
Kubernetes는 분산 시스템을 탄력적으로 실행하기 위한 프레임워크를 제공한다. 애플리케이션의 확장과 장애 조치를 처리하고, 배포 패턴 등을 제공한다.
사실 위 문장들이 Kubernetes의 핵심이다. 그러니까, Kubernetes는 배포한 컨테이너에 문제가 생기면 스스로 다시 실행(Self-healing)하고, 트래픽이 몰리면 컨테이너를 더 많이 실행(Auto-scaling)해 서비스를 끊기지 않고 제공할 수 있도록 설계된 환경일 뿐이다.
이런 기능들을 보다 디테일하게 구현하기 위해 자연스럽게 네트워크와 스토리지 설정이 필요하게 된 것이다. 워낙 관리할 설정이 많다보니 이런 구성 과정을 자동화하기 위해 Terraform 같은 IaC 툴이 등장하고, 팀이 유일하게 신뢰할 수 있는 한 곳에 리소스 정의 파일을 모아서 편하게 관리하도록 Argo CD와 같은 GitOps 툴이 등장했을 터이다.
그러니까 핵심은, 결국 Kubernetes도 누군가 겪었던 문제를 해결하기 위해 개발된 도구일 뿐, 만능 도구는 아닌 것이다. 그리고 우리에겐 항상 새로운 문제가 등장한다. 그에 맞춰 새로운 도구도 개발된다.
도구는 도구일뿐. 과도한 몰입은 본질을 흐리게 만든다
은탄환(Silver Bullet)이란 말이 있다. 전설이나 민속학에서 괴물이나 초자연적 존재를 물리칠 수 있는 만능 무기를 말한다. 여기서 비롯되어 한 번에 모든 고질적인 문제를 해결할 수 있는 마법 같은 단 하나의 해결책이란 뜻도 지니게 되었다.
모든 기술과 툴은 각기 다른 장점과 단점을 가지고 있다. 하물며 생성형 AI도 모든 기술적, 윤리적 한계를 뛰어넘지는 못한다. 어느 한 유명 소프트웨어 엔지니어링 논문에서 말한 것처럼, 이 세상에 은탄환은 없다(No Silver Bullet).
그러니 기술에 과몰입하지 말고, 해결해야 할 문제에 집중하자. 온프레미스 환경에서 서버를 안정적으로 운영하는 것이 최우선이라면 Kubernetes를 쓸 수 있을 것이다. 반면, 클러스터 운영 비용이 너무 부담스럽거나 퍼블릭 클라우드 환경을 사용해야 한다면 서버리스와 같은 다른 접근법을 고려할 수도 있을 것이다.
나도 저지른 과오지만, 어느 한 기술이 모든 문제를 해결해줄 것이라 기대하면 위험할 수 있다. 기대가 크면 실망도 큰 법이니까. 그러니 어떤 기술을 쓸 땐 왜 쓰는지, 해결해야 할 문제가 무엇인지 먼저 정립되어야 한다.
우리가 도구와 기술을 사용하는 본질적인 이유는 우리 앞에 놓인 문제를 해결하기 위함임을 기억해야겠다.