ML 엔지니어가 쿠버네티스를 배워야 하는 이유

쿠버네티스(Kubernetes), 줄여서 K8s로 불리는 이 오픈소스 시스템은 클라우드 환경에서 컨테이너화된 애플리케이션을 배포하고 관리하는 데 쓰인다. 오늘날 점점 더 많은 웹 애플리케이션이 K8s 위에서 운영되고 있다. ML 엔지니어라면, 모델 학습·모니터링·오케스트레이션에 사용하는 인프라나 모델을 소비하는 다운스트림 애플리케이션이 K8s 기반일 가능성이 갈수록 높아지고 있다. 그러나 K8s는 복잡한 시스템이라 처음 접하면 막막하게 느껴질 수 있다.

Chip Huyen의 말처럼, 이론적으로 데이터 사이언티스트가 K8s를 굳이 배울 필요는 없다는 데 동의한다. 하지만 현실은 이렇다: 꼭 해야 할 의무는 없어도, 알아두면 정말 큰 도움이 된다! 나는 업무 중에 인프라 제약에 막히는 경우가 적지 않았고, 그 인프라는 점점 쿠버네티스 위에 구축되고 있었다.

예를 들어, 나는 클라우드 프로바이더의 콘솔 접근 권한을 받는 경우가 거의 없고, 대신 일부 데이터 툴이 미리 설치된 K8s 클러스터 접근 권한만 주어지는 경우가 많다. 무언가 문제가 생겼을 때 K8s에 대한 기본 지식이 있으면 직접 디버깅할 수 있다. 또한 기본 개념을 알고 있으면 팀과 인프라 관련 논의를 훨씬 생산적으로 이어갈 수 있다.

Vicki Boykis도 이 기술을 배우는 데 시간을 투자할 가치가 있다고 보는 듯하다¹:

아래에서는 머신러닝 엔지니어에게 K8s 학습이 유익한 이유를 몇 가지로 정리해본다².

호스팅 데이터/ML 툴이 항상 선택지가 되는 건 아니다

대형 클라우드 프로바이더들은 저마다의 방식으로 ML 인프라를 호스팅 솔루션 형태로 제공한다³. 하지만 이러한 제품들이 실제 머신러닝 팀의 요구를 모두 충족하기엔 부족한 경우가 많다. 실제로 나는 호스팅 솔루션을 보완하거나 대체하는 형태로 다음과 같은 툴들이 배포된 사례를 여러 번 목격했다:

• Metaflow
• Kubeflow
• Argo
• JupyterHub
• Dask
• 등

오픈소스만으로 부족할 때는 서드파티 벤더들이 기꺼이 자사 소프트웨어를 클라우드에 설치해준다. 다만 이를 위해서는 기본적인 인프라 역량이 필요한 경우가 많고, 그 역량은 쿠버네티스와 상당 부분 맞닿아 있다. 인프라를 직접 배포할 책임이 없더라도, 기본 동작 원리를 이해하면 간단한 디버깅과 문제 해결을 스스로 처리할 수 있다. 예를 들어, 로그나 API/HTTPS 엔드포인트를 어디서 찾아야 하는지 아는 것만으로도 많은 상황에서 막힘 없이 작업을 이어갈 수 있다.

아무도 구하러 오지 않는다

머신러닝 분야에 처음 발을 들이면 흔히 겪는 경험이 있다. 바로 일을 시작하는 데 필요한 툴이 갖춰져 있지 않다는 것이다. 제대로 된 도구 없이 성과를 내기란 쉽지 않기 때문에, 이 상황은 정말 답답하다. 그리고 대개 다음과 같은 대화로 이어진다:

---

ML 엔지니어: ACME에 합류하게 되어 정말 기대됩니다! 예측 모델로 마케팅 비용을 최적화하는 업무를 맡았는데, 문제는 효율적으로 일하기 위한 기본 인프라와 툴이 없다는 겁니다.

매니저: 잘 이해가 안 되네요. 필요한 툴은 직접 설치하면 되지 않나요? 그걸 알아서 해결하는 게 당신 역할 아닌가요?

ML 엔지니어: 아니요, 저는 인프라 구축이나 배포는 모릅니다. 그건 인프라 또는 DevOps 전담 인력이 필요한 영역입니다.

매니저: 예상 투자 대비 효과를 모르는 상황에서 추가 리소스를 요청하기는 어렵네요. ML 프로젝트를 먼저 진행해서 성과를 보여주면, 그때 인프라 투자를 검토해볼게요.

ML 엔지니어: 빠르게 실험하고 개념 증명(PoC)을 만들려면 최소한의 툴이 필요합니다. 팀과의 협업을 위해서도 갖춰야 할 도구들이 있고요…

---

내 경험상 DevOps 팀은 만성적인 인력 부족과 과중한 업무에 시달리고 있다. 보안 문제 때문에 쿠버네티스에 엔터프라이즈 소프트웨어를 직접 배포하는 건 대개 바람직하지 않지만, 기본적인 역량을 갖추면 DevOps 동료들의 부담을 크게 덜어주고, 그들이 내 요청에 실질적으로 도움을 줄 수 있는 여건을 만들 수 있다.

K8s가 모든 인프라 문제를 해결해주는 만능 해법은 아니다. 조직의 제약과 기존 소프트웨어 스택 안에서 움직여야 한다.⁴ 그러나 K8s의 활용 범위가 계속 넓어지는 만큼, 이 기술을 익혀두면 도움이 되는 상황은 점점 더 많아질 것이다.

ML 연구는 레드오션이다. 소프트웨어 엔지니어링 역량으로 차별화하라.

데이터 사이언티스트로서 두각을 나타내는 가장 효과적인 방법 중 하나는 역량 차별화다. 기존 교육 과정은 최신 ML 기법을 익히는 데 치중하는 경향이 있다. 그런데 최첨단 ML 연구는 경쟁이 매우 치열하고, 이미 수많은 사람들이 뛰어들어 있는 분야다.

내 경험상, 많은 팀이 맞닥뜨리는 병목은 최신 ML 기법에 대한 지식 부족이 아니라 소프트웨어 엔지니어링 역량과 모델 실용화를 도울 파트너의 부재다. 툴과 인프라를 직접 구축하는 방법을 익혀두면, 팀 안에서 없어서는 안 될 존재가 된다.

더 나아가, 모델을 서비스와 애플리케이션에 배포하고 통합하는 것은 ML을 비즈니스 문제에 연결하는 핵심 과정이다. K8s를 배우면 바로 이 일을 해낼 수 있다.

당신의 회사는 이미 K8s를 쓰고 있을 가능성이 높다

파이썬이 데이터 사이언스의 공통 언어가 된 것처럼, K8s는 클라우드 인프라의 공통 언어로 자리 잡아가고 있다. CNCF의 2021년 설문조사에 따르면 96%의 조직이 쿠버네티스를 이미 사용하거나 도입을 검토 중이다. 또한 Stack Overflow의 2022 개발자 설문조사에서는 Docker와 Kubernetes가 각각 가장 선호하는 툴 1위와 2위를 차지했다. K8s가 이제 단순한 유행이 아닌 기술 표준으로 굳어지고 있다는 강력한 신호다.

K8s에 대한 기본 역량을 갖추면 많은 조직에서 원하는 툴에 대한 지지를 이끌어낼 가능성이 크게 높아진다. 구체적으로 다음과 같은 상황이 가능해진다:

• DevOps 동료들이 내가 배포하려는 툴에 대해 거부감 없이 협조해준다
• 애플리케이션 관리자와 같은 언어로 소통할 수 있다
• 인프라 작업을 함께 도와줄 사람을 찾기가 훨씬 쉬워진다 ⁵

이런 요소들이 갖춰지면, 데이터 사이언스 경험이 없는 소프트웨어 엔지니어가 임의로 결정해버리는 상황(실제로 자주 목격했다!) 대신, 내 실제 필요에 맞는 툴을 확보할 가능성이 훨씬 높아진다.

과한 것 아닐까?

빠르게 뭔가를 올리거나 프로토타입을 만들 때는 K8s가 분명 과하다. 내가 말하는 건 그런 상황이 아니라, 실제 많은 기업 환경 안에서 일할 때 K8s 지식이 유용하다는 것이다. 예를 들어, 운영 환경에 소프트웨어를 배포하려면 단일 VM에 호스팅하는 방식만으로는 부족한 경우가 많다. 심지어 어떤 기업은 쿠버네티스만을 허용하는 정해진 경로(paved path)만 제공해, 그 외의 방식으로는 배포 자체가 막혀 있기도 하다.

운영 소프트웨어를 직접 배포하지 않더라도, K8s는 필요한 툴을 구축하는 데 큰 힘이 된다. 많은 경우 K8s를 활용하면 오히려 작업이 더 수월해지기도 한다. 기업들은 비용과 보안을 통제하기 위해 가드레일을 구축해왔고, 그 가드레일은 점점 K8s 패턴을 중심으로 설계되고 있다⁶. 이 개념들을 이해하면 회사의 클라우드 스택 안에서 훨씬 더 자유롭게 움직일 수 있다.

전문가가 될 필요는 없다

K8s는 복잡한 기술이지만, 데이터 사이언티스트로서 실질적인 가치를 얻기 위해 전문가 수준이 될 필요는 없다. 데이터 사이언티스트가 K8s 관리자가 되어야 한다는 말이 아니다. K8s 관리(Administration)는 그 자체로 깊이 있는 전문 영역이며 별도의 역할이 필요하다. 문제는, 현존하는 K8s 교육 자료의 대부분이 관리자를 대상으로 하고 있다는 점이다. 이는 대다수 데이터 사이언티스트에게 필요한 수준을 훨씬 넘어선다.

강좌를 만든다면?

데이터 사이언티스트처럼 관리자가 아닌 사람을 위해, 불필요한 내용 없이 쿠버네티스를 배울 수 있는 좋은 자료를 아직 찾지 못했다. 그래서 동료들과 함께 데이터 사이언티스트를 위한 무료 강좌 제작을 검토 중이다. 관심이 있다면 여기서 신청할 수 있다.