🔭Aiden's Lab

최근 게시글

86건 더보기 →

Kubernetes라는 항해사의 조타기, Helm의 탄생과 미래

13 min read

Ahoy—! 이제는 우리에게 익숙한 Kubernetes가 그리스어로 ‘항해사’란 사실, 알고 계셨나요?

컨테이너 운영이라는 거친 바다 위를 나아가는 항해사에게 필요한 건 무엇일까요? 바로 배를 조종하는 조타기죠.

Kubernetes의 패키지 매니저 역할을 하는 Helm이 바로 ‘조타기’라는 뜻을 지니고 있습니다. 항해사(Kubernetes)에게 꼭 필요한 도구라니… 이름 참 잘 지었단 생각이 드네요.

300 (어때요? 이제 Helm의 로고가 배의 조타기처럼 보이시나요?)

이번 아티클에선 Helm의 탄생과 발전 과정을 살펴보고, 앞으로 Helm이 나아갈 미래도 같이 생각해보겠습니다.

Helm의 탄생

아까 Helm은 항해사(Kubernetes)의 필수 도구라는 이야기를 했었죠. 하지만 사실 Helm은 Kubernetes를 위해 개발된 툴이 아니었습니다.

2015년 Deis라는 작은 스타트업에서 개발된 Helm은, 당시 개발사 이름과 동일한 Deis란 이름으로 불리고 있었는데요. Deis는 당시 또다른 컨테이너 오케스트레이션 플랫폼이었던 Fleet 위에서 동작하도록 만들어졌습니다.

하지만 같은 해에 개발사 Deis는 자신의 툴을 Fleet 기반에서 Kubernetes 기반으로 변경하는 어려운 결정을 내립니다. Kubernetes가 더욱 유망한 플랫폼이 될 것이라는 판단 하에 이뤄진 결단이었죠.

(Helm의 전신인 Deis의 다이어그램. 이미지 하단에 Fleet이 보입니다. 출처: https://pythonhosted.org/deis/understanding_deis/architecture)

이렇게 무대를 Kubernetes로 옮긴 Helm v1은 같은 해 전세계 최초로 개최된 대규모 Kubernetes 컨퍼런스 ‘KubeCon’에서 정식으로 공개됩니다. 빠른 결정으로 대상 플랫폼을 Fleet에서 Kubernetes로 옮긴 Deis의 전략은 Kubernetes 생태계 내에서 Helm이 빠르게 자리잡는 데에 큰 역할을 했다고 볼 수 있습니다.

Helm은 어떻게 진화해왔는가

사실 Helm v1에는 문제가 꽤 있었습니다. 동작하는 플랫폼을 바꾸는 데 너무 서둘러서였을까요. 리소스를 Kubernetes 클러스터에 배포할 때 하드코딩된 매니페스트 파일이 필요하는 등, 개선해야 할 부분이 명확했거든요.

마침 Helm과 비슷한 툴을 개발하고 있던 Google의 한 개발 팀이 2015년 말에 Helm 팀에게 연락을 합니다. 자신들도 Helm과 유사한 기능을 수행하는 툴을 만들고 있는데, 도움을 줄 수 있겠다고 말이죠. 그렇게 Google 개발팀과 Helm 팀은 미국 시애틀에서 만나 Helm에 대해 논의를 합니다.

결과는 어땠을까요? 놀랍게도 두 팀이 각자 개발하고 있던 툴을 합쳐 Helm v2를 제작하기로 했습니다. 이 과정에서 Helm의 Kubernetes 리소스 배포를 도와주는 Tiller라는 컴포넌트를 새로 추가합니다. 이렇게 Google에서도 문제 개선을 적극 도와줄 정도로 Helm이 인정받고 있던 것이죠.

Helm v2에 새로 추가된 컴포넌트 Tiller에 대해서 좀 더 이야기해볼까요? Helm이 Kubernetes 리소스를 하나의 묶음(릴리즈)으로 배포하는 걸 도와주는 Tiller는 Kubernetes 클러스터 내에서 동작하는 Helm의 구성요소였습니다. Kubernetes 클러스터를 구성하는 내부 컴포넌트들이 Helm 릴리즈와 정상적으로 상호작용할 수 있도록 중간 다리 역할을 수행했죠. 참고로 Tiller란 ‘배의 방향을 조종하는 손잡이’란 뜻입니다. Helm부터 배와 관련된 컨셉이 계속 이어지는 게 인상적이죠?

(실제 배의 Tiller 이미지. 출처: https://smallboatsmonthly.com/article/simple-tiller-tender)

하지만 Helm v2의 Tiller 컴포넌트는 등장한 지 1년이 되자마자 사라질 위기에 처합니다. 2017년 릴리즈된 Kubernetes v1.6부터 역할 기반 접근 제어 방식(RBAC)이 기본값으로 적용된 것이 그 이유인데요.

Tiller가 Kubernetes 클러스터 내부에서 다른 컴포넌트들과 상호작용하려면 넓은 범위의 권한을 가지고 있어야 하는데, 이는 외부 공격에 노출되면 치명적인 피해가 발생하는 원인으로 작용할 수 있기 때문입니다.

이런 문제를 해결하기 위해 Helm 팀은 커뮤니티의 다양한 사례를 연구했고, Helm 릴리즈를 관리할 때 Tiller을 사용하는 대신 Kubernetes API 서버의 Fetch 정보를 활용하자는 결론에 도달합니다. 즉, Helm을 Kubernetes 클러스터 외부에서 클라이언트로만 동작시켜 Kubernetes 클러스터 보안 위험을 줄이고자 한 것입니다. 이렇게 Tiller는 Helm v3부터 완전히 사라지게 됩니다.

여담으로, Helm을 개발한 Deis는 2017년 Microsoft에 인수됩니다. MS는 당시 컨테이너 오케스트레이션 시스템 Azure Container Service를 개발하고 있었는데요. Kubernetes 플랫폼의 사용성을 크게 높여준 Deis의 전문성을 인정하고, Azure Container Service를 발전시키고자 인수를 진행한 것입니다. Deis는 MS에 인수된 이후에도 계속해서 Helm을 관리 및 지원하고 있습니다.

앞으로 Helm이 나아갈 다음 목적지는?

현재 Helm은 v4 릴리즈를 준비하고 있습니다. 활발한 커뮤니티 개발을 위해 활동량이 적은 기존 기여자들과 논의를 나누고, 새로운 PR에 대해서는 리뷰와 피드백을 빠르게 제공하려 노력했다고 하는데요. Helm v4는 2025 KubeCon North America에서 공개될 예정입니다.

하지만 이런 Helm 팀의 노력에도 불구하고, Helm의 미래를 부정적으로 보는 의견도 있습니다. Helm과 같은 템플릿 기반의 인프라 관리 방식은 AI를 통해 자동화하기 어렵다는 것인데요. 그 근거는 아래와 같습니다.

  • 의미론적 이해 불가

    • Helm에서 사용되는 템플릿 언어와 파편화된 YAML 파일들의 관계를 AI가 제대로 이해하지 못할 수 있음

  • 프로그래밍 인터페이스 부족

    • AI는 메소드 호출이나 오브젝트 상태 확인, API를 통한 설정 변경 등 프로그래밍 인터페이스와 적절하게 상호작용해야 하지만, Helm은 이런 프로그래밍 인터페이스가 부족함

  • 피드백 루프 실현 불가

    • AI가 계속해서 학습 및 개선되려면 지속적인 피드백이 필요하지만, Helm으로 일어난 변경사항의 영향을 AI가 인지하거나 변경으로 인한 결과를 가지고 AI가 학습하는 메커니즘이 없음

그리고 AI와의 협업은 객체지향 인프라 관리 방식이 더 유리하다는 의견이 있습니다. 대표적인 객체지향 인프라 관리 툴로는 Pulumi나 cdk8s가 있는데요. 프로그래밍 언어로 인프라 관리 코드를 작성하는 도구들이죠. 특히 Pulumi는 지난 아티클에서 다룬 적이 있습니다. (Pulumi 실습 아티클)

객체지향 인프라 관리 방식이 AI로 자동화하기 좋은 이유를 정리하면 아래와 같습니다.

  • 구조화된 데이터 모델

    • 타입이 정해진 오프젝트와 사전 정의된 관계를 가지고 인프라를 구성하기 때문에 AI가 분석하고 의사결정하기 쉬움

  • 프로그래밍 API 존재

    • 메소드 호출, 프로퍼티 검토, 코드 수정 등 AI가 인프라 오브젝트와 직접 상호작용이 가능

  • 디버깅 가능

    • AI가 인프라 코드를 라인별로 실행해나가며 변수 상태를 검토하고 디버깅 가능

물론 지금 당장 Helm이 구식 기술이 되었다는 뜻은 아닙니다. Helm은 여전히 Kubernetes 리소스를 배포하고 관리할 때 많이 사용되는 툴이니까요.

하지만 AI와의 협업이 점점 더 보편화되어가는 지금, 템플릿 기반의 Helm이 어떻게 AI 친화적으로 개선해나가야 할지에 대한 고민도 필요할 듯합니다.

마무리

Helm은 개발 초기부터 공격적인 전략으로 일찍이 Kubernetes 생태계에 자리를 잡아 발전해왔습니다. 하지만 AI가 보편화된 시대가 되자, 그런 Helm에게도 현상 유지를 넘어 AI의 힘을 활용할 수 있는 방향으로 개선해야 한다는 의견이 나오고 있는데요.

오히려 후발주자였던 Pulumi나 cdk8s가 AI와 시너지가 더 좋을 것이라는 평가도 있는 걸 보면, 시대의 흐름이란 파도 속에서 제자리를 지키는 건 참 어려운 일인 것 같습니다.

이렇게 Helm의 탄생과 발전 과정, 앞으로 나아갈 미래까지 함께 살펴봤는데요. 다음 아티클에선 또 다른 흥미로운 주제로 찾아뵙겠습니다.

오늘도 읽어주셔서 감사합니다.

참고 자료

✨이번 아티클은 어떠셨나요?

이번 글의 주제에 대해 어떻게 생각하는지 알려주세요! 더 나은 아티클을 전달해드리기 위해 아래 폼에서 짧은 피드백을 받고 있어요.

👉 피드백 보내기 (1~2분 소요)

여러분들의 소중한 의견은 Aiden’s Lab에 큰 힘이 됩니다!

최근 게시글

87건 더보기 →