본문은 요즘IT와 번역가 Chase가 함께 만든 해외 번역 콘텐츠입니다. ‘Evrone’이라는 해외 IT 아웃소싱 기업이, 쿠버네티스 공동 창립자이자 VMware 수석 엔지니어 조 베다(Joe Beda)를 인터뷰한 글로, 원작자에게 허락을 받고 번역했습니다. 2년 전인 2021년에 진행된 인터뷰임을 감안하고 읽어주시기 바랍니다. *표시된 부분은 번역가가 작성한 주석입니다.

회원가입을 하면 원하는 문장을
저장할 수 있어요!

쿠버네티스 공동 창립자 조 베다 “소프트웨어 개발은 팀 스포츠”

요즘IT의 번역글

18분

2023.12.08.

6.4K

몇

년차,

어떤 스킬

어떤 직무

의

독자들이 봤을까요?

어떤 독자들이 봤는지 궁금하다면?

로그인

최근에 VMware의 수석 엔지니어이자 쿠버네티스 및 구글 컴퓨트 엔진의 창시자 중 한 명인 조 베다를 인터뷰할 수 있는 기회가 있었습니다. 조 베다는 마이크로소프트와 구글에서 다양한 경험을 쌓은 베테랑 소프트웨어 엔지니어입니다. 더불어, 베다는 현재 VMware에 인수된 클라우드 네이티브 분야의 선두 주자인 헵티오(Heptio)를 공동 설립한 주요 인물 중 한 명입니다. 인터뷰 내용에 대한 전문은 아래에 첨부했으니 독자 여러분들의 많은 관심 부탁드립니다!

에브론: 잘 아시다시피 요즘은 가상화를 통해 소프트웨어를 하드웨어로부터 추상화하는 데 도움을 주는 애플리케이션들이 있습니다. 컨테이너를 사용하면 운영체제나 거대한 시스템 리소스 경제로부터 비교적 자유로워질 수 있죠. 또, 쿠버네티스와 같은 플랫폼을 사용하면 프로그램을 수동 제어할 필요가 없어지기 때문에 앱이 실행되는 방식과 위치에 대해 신경 쓸 필요가 없습니다. 그러면 여기서 질문드리겠습니다. 앞으로 우리는 프로그램의 제어권을 잃고 고객의 문제를 트러블슈팅하는게 더 어려워지게 될까요?

조 베다: 저는 언급하신 상황이 개발자가 운영 체제에서 분리되는(추상화되는) 것으로 이어지리라고 보지는 않습니다. 컨테이너를 사용하더라도 그 안에는 리눅스 환경이 있는 걸 알 수 있잖아요? 물론 컨테이너를 사용하는 것은 개발자가 작성한 코드가 실행 환경에 구애받지 않고 작동하는 마법 같은 결과를 만들어내는 데 상당한 도움이 된다고 생각합니다.

여기에 대한 근거는 두 가지가 있는데요, 첫 번째로 컨테이너를 가상화와 결합하는 경우 효율성 측면에서 이점이 있다는 점입니다. 동일한 하드웨어에 더 많은 것을 담을 수 있고, 파일 크기를 더 줄일 수 있으며, 더 세밀하게 오버커밋*하는 등의 장점이 있습니다.

*가상 시스템 상 결합된 작업 메모리 공간이 호스트 메모리 크기의 결합된 작업 메모리 공간을 초과하는 것

하지만 더 중요한 것은 컨테이너를 사용함으로써 훨씬 더 패키지화되고, 격리된 배포 단위를 갖게 된다는 것입니다. 따라서 우리는 이제, 적어도 서버 사이드 관점에서는, 실행 환경이 노트북이든, 클라우드이든 아니면 심지어 다른 사람이 구성한 클라우드이든 이와 상관없이 프로그램을 실행할 수 있는 방법이 생긴 겁니다. 동일한 아티팩트*를 어떤 환경이든지 상관없이 아주 적은 설정 변경만으로 실행될 수 있죠. 개발자의 입장에서 이런 훌륭한 배포 단위를 갖게 되는 건 매우 강력한 빌딩 블록이라고 생각합니다.

*배포 패키지, WAR 파일, 로그 및 보고서 등 빌드 프로세스에서 생성된 파일

보통의 상황에서는 스토리지에 네트워크가 없으면 CPU 프로세스를 실행하는 것이 크게 도움이 되지 않습니다. 여기서부터 진짜 복잡한 문제가 생기죠. 빈 패킹(bin packing) 문제를 해결하여 컨테이너가 여러 호스트에서 동작하게 하는 것도 중요하지만, 이를 유용하게 만들려면 네트워크가 잘 연결되어야 하고, 컨테이너끼리 통신할 수 있어야 하며, 특정한 저장소가 필요할 때는 필요한 시간과 장소에 정확히 위치하도록 해야 합니다. 이러한 요소들이 모여서 정말 어려운 문제가 됩니다.

에브론: 컨테이너가 리눅스 커널 위에서 실행되고 있다고 가정할 수 있다고 말씀하셨는데, 현재 마이크로소프트는 리눅스용 윈도우 서브 시스템을 집중적으로 개발하고 있습니다. 이것이 윈도우가 컨테이너를 통합하는 시대의 출발점이 될 것으로 생각하시나요?

조 베다: 솔직히 말씀드리면 저는 리눅스용 윈도우 하위 시스템(Windows Subsystem for 리눅스)에 대해 자세히 알지 못합니다. 다만, 마이크로소프트에서 함께 일했던 동료 중 일부가 언급하신 작업을 주도하고 있긴 합니다. 이런 걸 보면 이 업계가 얼마나 작은 산업인지 새삼 체감하기도 하고, 옛날 동료들과 새로운 일로 다시 만나게 되는 것을 보면 정말 재밌습니다.

질문으로 돌아가자면, 제가 이해하기로 리눅스용 윈도우 하위 시스템의 두 번째 버전은 사실 가상 머신에서 실행되는 리눅스 커널이고, 이 커널과 나머지 윈도우 파일 시스템 및 네트워킹 간에 세밀한 상호 작용이 이루어지는 것으로 알고 있습니다. 실제로 사용해 보기도 했는데, 정말 흥미로운 기술이더군요. 깊은 인상을 받았습니다. 도커와 같은 컨테이너 엔진을 바로 실행할 수 있고, 마치 데스크톱에 리눅스가 있는 것과 같이 느껴지는 경험을 할 수 있습니다. 물론 그 안에 실제로 리눅스 커널이 존재하기 때문이겠죠.

다만 사용자 인터페이스는 전통적인 리눅스 시스템과는 약간 다른 방식으로 구성되어 있습니다. 중요한 것은 이 두 번째 버전은 네이티브 윈도우 컨테이너와 완전히 다른 메커니즘이라는 것을 인지하는 것입니다. 윈도우는 컨테이너가 잘 구동되도록 설계되지 않았기 때문에 네이티브 윈도우 컨테이너를 다루기는 까다롭습니다. 일례로, 윈도우에는 글로벌 레지스트리와 글로벌 리소스가 있는데, 이 모든 것을 격리하는 것은 꽤 큰 작업입니다.

제가 알기로 네이티브 윈도우 컨테이너는 성숙도와 사용 측면에서 아직 개발 초기 단계에 있습니다. C++ 또는 다른 로우 레벨 언어를 사용하는 윈도우 개발자가 Win32 같은 걸로 윈도우를 타깃하는 경우에는 리눅스를 타깃팅하는 것과 상당한 차이를 느낄 것으로 예상됩니다. 모델 측면에서는 상당히 큰 차이가 있거든요.

하지만 더 하이 레벨 언어로 넘어가면 차이를 크게 체감하지는 않을 것 같습니다. 마이크로소프트가 크로스 플랫폼을 지원하는 .NET core로 넘어가면서 하이 레벨 환경을 위한 프로그래밍 모델을 운영 체제와 분리하는 추세입니다. 그렇긴 하지만 아직까지 .NET 표준도 상당 부분 남아 있습니다. 특히 미디어 인코딩과 같은 작업을 수행하는 경우 네이티브 윈도우 DLL에 대한 종속성이 여전히 상당한 편이죠. 그리고 사람들이 윈도우 워크로드를 실행하는 곳은 여전히 많습니다. 따라서 윈도우를 위한 컨테이너 관련 작업은 여전히 진행 중입니다. 그래도 .NET Core가 리눅스를 지원하기 때문에 이러한 작업이 생각보다 크게 필요하지는 않았을 것으로 생각됩니다.

에브론: 마이크로소프트에서 인터넷 익스플로러 브라우저를 개발했던 경력을 언급하셨는데요, 그중 가장 유용했던 경험은 어떤 게 있나요?

조 베다: 확실히 경력이 길어지면 다양한 것을 배우게 되는 것 같습니다. 먼저 기술적인 관점에서 유용했던 경험을 하나 이야기해 해드리죠. 당시 저보다 연차가 높은 시니어 엔지니어와 메모리 프로파일링 시스템을 구현한 적이 있습니다. 이 프로젝트에서는 인터넷 익스플로러와 메인 렌더링 엔진에서 가능한 모든 메모리 할당(allocation)을 태깅하면서 계층 구조를 만들었고, 메모리가 어디에 사용되는지 실시간으로 시각화되도록 만들었습니다. 그리고 그 위에 디버그 모드를 추가할 수 있었죠. 이 작업을 하다 보니 너무 복잡해져서 도대체 무슨 일이 일어나고 있는지 제대로 파악조차 할 수 없고, 당황스러운 일도 많습니다. 사실 후에 경력을 쌓으면서 이런 일들은 숱하게 경험했습니다. 프로그램이 어떻게 작동한다는 가설을 세우고 나서 막상 코드를 보면서 비교하면 가설이 항상 틀리더라고요.

그래서 행동하는 게 중요합니다. 가설을 세워보는 것도 좋지만 실제로 꼭 검증해야 해요. 지금 이 지점이 진짜 병목인지, 그리고 그것이 문제가 맞는지 검증을 꼭 하고 최적화를 시도해야 합니다.

개발 전문성과 관련해서는, 오래전이긴 하지만 인터넷 익스플로러 5, 6 개발에 참여했을 때의 경험이 생각나네요. 당시 저는 작은 리더 역할을 맡기 시작했습니다.

본격적으로 얘기하게 앞서 시대 배경을 좀 말씀드리면, 당시 인터넷 익스플로러는 윈도우 9x나 NT를 타깃으로 했습니다. 다시 말해 저메모리, 저전력 컴퓨터라는 말이죠. 인터넷 익스플로러 4의 원래 버전은 48메가바이트 또는 64메가바이트 컴퓨터에서 실행되었습니다. 지금과는 완전히 다른 세상이었죠.

하지만 저는 인터넷 익스플로러 메인 렌더링 엔진의 성능을 향상하는 데 기여했고, 이는 당시 주요 경쟁자였던 넷스케이프와 경쟁에서 중요한 승리를 거둔 것이라고 할 수 있습니다. 이러한 수평적 역할들을 맡으면서 좋은 퍼포먼스를 내기 위해서는 팀 구성원 뿐만 아니라 그 외 모든 것이 복합적으로 영향으로 작용한다는 것을 깨달았습니다. 처음 리더 역할을 맡았을 때는 “이건 이렇게 하고, 저건 저렇게 해야 해”라고 권한을 행사하며 일을 처리하려고 하다가 실패하기도 했죠. 사실 돌이켜보면 제게 특별한 권한이 있던 것도 아니고요. 그러다가 나중에는 어떻게 하면 지시가 아닌 영향력으로 리딩할 수 있는지, 직접 업무를 통제하지 않아도 팀원들이 잘 일하게 하는지 등에 관해 많이 배웠습니다.

구체적으로는 사람들의 실제적인 동기를 어떻게 이해해야 하는지, 그들의 목표는 무엇인지, 그리고 권한이 없는 상황에서도 어떻게 팀원과 동조를 끌어내어 윈윈 상황을 조성할 것인지에 대한 고민이 필요합니다. 이처럼 타인과 교류하는 기술은 경력을 쌓는 동안 계속해서 익혀야 하는 스킬입니다. 저는 소프트웨어 개발이 팀 스포츠라고 생각합니다. 여러 사람이 하나의 목표를 위해 함께 일해야 하니까요.이는 핵심 기술이나 훌륭한 코드를 많이 작성하는 것만큼이나 중요합니다.

에브론: 옛날 얘기를 들으니 감상에 빠지게 되네요. 선생님은 그 당시에 인터넷 익스플로러랑 넷스케이프 내비게이터 중 어떤 것을 더 선호했나요?

조 베다: 과거에 있었던 일에 대해 더 할 이야기가 많습니다. 제가 마이크로소프트에서 구글로 옮기면서 크게 달라진 점 중 하나는 제가 입사할 당시의 초창기 구글은 경쟁보다는 “고객을 위해 더 나은 서비스를 제공하자”는 목표에 더 집중했다는 점입니다. 이때 체득한, 경쟁보다 사용자에게 집중하는 태도는 지금까지도 유지하고 있습니다. 구글이 지금도 그렇게 하고 있는지는 모르겠지만요.

반대로 커리어 초기에 입사한 마이크로소프트에는 “경쟁자를 짓눌러버리자”라는 식의 태도가 주도적이었습니다. 돌이켜보면 인터넷 익스플로러의 시장 포지션에 비추어 볼 때 이는 건전한 태도가 아니었다고 생각합니다. 하지만 기술적인 측면에서 볼 때, 특히 인터넷 익스플로러 4는 당시 내비게이터보다 훨씬 더 뛰어났습니다. 일례로 기본적으로 프로그래밍할 수 있는 페이지의 인메모리 모델이 있었습니다. 아실지 모르겠지만 브라우저의 DOM은 사실 인터넷 익스플로러 4에서 시작되었습니다. 또한, 동일한 팀이 프로그래밍 모델과 마크업을 일치시키고 마크업에서 할 수 있는 모든 것을 자바스크립트로 런타임을 조정할 수 있는 아이디어를 주도했습니다. 당시 내비게이터에는 그런 종류의 인메모리 모델이 없었죠.

내비게이터에는 원본 텍스트를 다시 렌더링할 수 있는 인메모리 모델이 없었기 때문에 창을 가져와서 크기를 조정하면 페이지의 원본 텍스트를 다시 파싱해서 렌더링하는 일이 발생했습니다. 또한 창 크기를 조정하면 일부 내용을 다시 다운로드하는 경우도 있었습니다. 당시의 내비게이터는 여러 웹 페이지를 겹쳐놓고 그중 일부를 교체하는 넷스케이퍼 레이어라는 동적 특성을 준수했습니다.

저는 현재 우리가 최신 웹 브라우저라고 규정하는 기준들을 인터넷 익스플로러 4가 확립했다고 생각합니다. 인터넷 익스플로러 4에는 이전 시대의 브라우저에 비해서 많은 개선과 훌륭한 기능들이 추가되었습니다.

그 당시에는 소위 표준이라고 하는 것이 생겨나던 시점인데, 인터넷 익스플로러는 그보다 앞서있었기 때문에 표준이 인터넷 익스플로러에 따라 바뀌는 경우가 많았습니다. 당시에는 호환성과 표준 간의 트레이드오프는 항상 어려운 문제였습니다. 그런 상황을 헤쳐 나갈 수 있는 도구나 기술이 없었기도 하고요. 어찌 됐든 저는 인터넷 익스플로러를 훨씬 더 선호했습니다. 당시에는 현대적인 웹 브라우저의 표준을 만든다는 측면에서 정말 흥미로운 일을 하고 있다고 생각했거든요. 당시에는 저희의 작업물을 HTML Dynamic, 줄여서 DHTML이라고 불렀지만, 본질적으로 현대의 DOM으로 봐도 무방합니다.

에브론: 네, 그 부분은 많은 분들도 알고 있을 거로 생각합니다. 예전에 하신 연설에서 쿠버네티스가 플랫폼 중의 플랫폼이라고 언급하셨습니다. 가장 잘나가고 있는 쿠버네티스 기반 플랫폼은 무엇이라고 생각하시나요?

조 베다: 쿠버네티스가 성공한 이유 중 하나는 쿠버네티스 위에 반드시 단일 모놀리식 플랫폼을 올려야 한다는 제약이 없다는 점입니다. 이를 대조적인 비교로 설명해 보겠습니다. 메소스(Mesos)*와 같은 확장성 모델(extensibility model)을 보면, 메소스는 기본적으로 툴킷 커널이었고, 그 위에 핵심 스케줄러(core scheduler)를 사용하여 작업을 수행하는 마라톤(Marathon)이나 오로라(Aurora) 또는 크로노스(Chronos) 같은 것들을 구축할 수 있는 구조입니다. 하지만 오로라, 마라톤, 크로노스에는 각자 독자적인 API, 사용자 시스템과 모델링 방식이 있기 때문에 결국 각각의 시스템이 고립된 사일로가 되어버렸죠.

*캘리포니아 대학교 버클리에서 개발한 컴퓨터 클러스터를 관리하기 위한 오픈 소스 프로젝트

저희 팀이 쿠버네티스에서 한 일 중 하나는 공통 모델 집합에 대한 공통 CRUD API들을 만든 것입니다. 이런 특성 덕분인지 저희는 많은 사람들이 쿠버네티스를 다른 쿠버네티스 익스텐션과 상호 운용할 수 있는 방식으로 확장한다는 것을 발견했습니다. 즉, 쿠버네티스 위에 구축된 시스템들이 단절된 사일로 방식으로 실행되는 것이 아니라, 외부 생태계(ecosystem)와 상호 작용하며 시너지를 낸다는 의미로 해석할 수 있습니다. 저는 이것이 우리가 쿠버네티스를 통해 이뤄낸 큰 변화라고 생각합니다.

쿠버네티스의 공통 컴포넌트는 계속 발전하고 있습니다. 예를 들어 거의 모든 사용자가 사용하는 인증서 관리자(cert-manager) 익스텐션 같은 싱글톤*이 있습니다. 쿠버네티스가 제공하는 인증서 관리자가 이미 있기 때문에 직접 인증서 관리 시스템을 구축하는 사용자는 많지 않죠. 물론 쿠버네티스를 기반으로 하는 인그레스 시스템** 환경이라면 그 시스템의 기반이 엔보이(envoy)이든, 엔진엑스(Nginx)든, 에이치에이프록시(HAProxy)든, 네이티브 클라우드든 상관없이 인증서 관리 시스템을 적용할 수 있습니다. 쿠버네티스에는 플랫폼을 바닥부터 구축할 수 있지만, 여러 가지 빌딩 블록을 조합해서 플랫폼을 구성하는 방법도 있습니다.

*하나의 인스턴스(객체)를 애플리케이션 전체에서 공유하는 패턴

**클러스터 내의 서비스에 대한 외부 접근을 관리하는 API 오브젝트이며, 일반적으로 HTTP를 관리함. 인그레스는 부하 분산, SSL 종료, 명칭 기반의 가상 호스팅을 제공할 수 있음

그리고 지금 VMware에서 탄주(Tanzu)와 함께 작업하고 있는 내용을 살짝 말씀드리자면, 초기 사용자가 압도당하는 느낌을 경험할 만큼 다양한 빌딩 블록 옵션 중에서 “이것과 이것을 이런 식으로 조합하는 것부터 해보면 좋은 경험이 될 거예요!”라고 요약해 주는 것에 노력을 쏟고 있습니다. 이후에 사용자가 쿠버네티스의 시스템과 생태계에 익숙해지면 스스로 커스터마이징 해가는 거죠. 이처럼 빌딩 블록을 조합해서 플랫폼을 만들어낼 수 있는 특성을 잘 이용하면 쿠버네티스를 사용하는 개인과 조직 모두에게 더 나은 시작 경험을 제공할 수 있다고 생각합니다.

신뢰할 수 있게 안정적으로 동작 하는 프로덕션 등급(Production-Grade)의 컨테이너 스케줄링과 관리/쿠버네티스

에브론: 대부분 전문가들이 쿠버네티스의 진입 장벽이 높다고 지적합니다. 이것이 플랫폼에 좋다고 할 수 있을까요? 신규 사용자에게 진입 장벽을 낮추거나 더 간단한 버전 등을 제공해야 하지는 않을까요?

조 베다: 정말 복잡한 주제네요. 비슷한 질문을 받을 때 제가 먼저 구분해서 설명하는 게 있는데요, 복잡한 것에는 본질적인 복잡성과 의도하지 않은(우발적인) 복잡성이 있다는 겁니다. 지나치게 단순화된 시스템은 불안정하게 되어버려서 사용 범위가 상대적으로 좁아지게 될 수 있습니다. 과거의 많은 PaaS에서 이러한 현상이 발견되었죠. 그들의 시작은 좋았지만, 말로는 좋지 않았습니다. PaaS의 사용자는 처음에는 꽤 많은 일을 처리할 수 있지만 결국에는 어떤 벽에 부딪히게 되고, 그때부터는 사용 옵션이 상당히 제한적이라고 느끼게 됩니다. 결국에는 프로그램을 다른 환경으로 이관해서 다시 개발해야 하죠. 저는 이게 PaaS가 너무 단순화되어서 생긴 문제라고 생각합니다.

지나친 단순화의 또 다른 함정은, 처음 사용하는 5분 동안은 시스템이 단순하게 느껴질 수 있지만 그 아래에는 숨겨진 복잡한 부분이 너무 많다는 것입니다. 또, 일이 너무 ‘마법'처럼 쉽게 처리되면 실제로 무슨 일이 일어나고 있는지 이해하기 훨씬 더 어려워집니다. 저는 수평적인 스케일링이 가능한 분산 애플리케이션(distributed applications)을 로드 밸런서나 동적 스토리지와 같은 외부 서비스를 많이 사용하는 머신 풀에 배치하는 것은 복잡성이 높은 상당히 어려운 문제라고 생각합니다. 그리고 쿠버네티스가 제공하는 유연성의 수준을 고려하면, 이보다 더 단순화하기는 어렵습니다.

물론쿠버네티스에는 의도하지 않게 생긴 필요 이상으로 복잡해진 부분도 분명히 존재합니다. 그런데 이건 여느 시스템과 같이 어쩔 수 없는 부분이고, 해결하려면 꽤 정교한 솔루션이 필요한 어려운 문제라고 생각합니다. 저희 팀은 사실 쿠버네티스에 너무 익숙해졌기 때문에 시스템의 어느 부분이 복잡한지 정확히 인지하기 어렵기도 합니다. 마치 이런 상황입니다. 예를 들어 컴퓨터를 처음 접하는 사람에게 리눅스 같은 운영체제를 프로그래밍하고 작업하는 방법을 소개한다고 생각해 보세요. 그들이 작업에 능숙하게 다룰 수 있는 수준에 도달하기 위해서는 복잡한 일을 엄청나게 겪어야 할 것입니다. AWS와 같은 주류 클라우드도 마찬가지입니다. 사용하기 결코 간단한 제품은 아니지만 다양한 방식으로 사용할 수 있는 툴킷이기 때문에 그 복잡성이 정당하다고 느껴집니다.

마찬가지의 정당화가 쿠버네티스에도 적용될 거라고 예상하는데, 지금 쿠버네티스가 지나치게 복잡하다는 질타를 받는 것은 그것이 아직 신기술이기 때문이라고 생각합니다. 이 기술에 대한 이해가 업계에 많이 퍼지고 나면 사람들도 쿠버네티스의 복잡성보다는 이점에 주목하게 되겠죠. 지금 막 업계에 발을 들인 개발자에게 물어보세요. 사실 소프트웨어 산업계에서 단순하고 쉬운 건 거의 없습니다. 다만 우리가 기술들을 마스터했기 때문에 어렵지 않게 느껴지는 거죠.

에브론: 2주 전쯤에 저희 팀은 가장 큰 테크 이벤트 중 하나에 참석했습니다. 컨퍼런스에서 뜨거운 주제 중 하나는 “개발자가 실제로 쿠버네티스 기본 사항을 배우는 데 주의를 기울여야 하는가, 아니면 시스템 관리자나 데브옵스에게 맡기고 좋은 코드를 작성하는 데만 집중해야 하는가?”였습니다. 선생님의 의견이 궁금합니다.

조 베다: 그 문제에 대한 견해는 개발자를 어떻게 정의하느냐에 따라 다르다고 생각합니다. 종종 개발자를 하나의 통합된 그룹으로 지칭할 때 많은데, 실제로는 매우 다양한 유형의 개발자가 존재하며, 유형에 따라 각기 다른 관심사와 배워야 할 것이 있다는 것을 기억해야 합니다.

게임 엔진을 예로 들어보겠습니다. 제 고등학교 친구 중에는 마이크로 최적화(micro-optimizations)를 통해 AAA급 게임*을 만드는 사람이 있습니다. 이 친구가 하는 일은 지금 저의 개발 분야와는 완전히 다른 세계입니다. 이 상황에 언급하신 질문을 적용해 볼까요? 게임 개발자라면 언리얼 엔진 같은 게임 엔진을 사용만 하고 그 기반이 되는 렌더링 기술에 대해서는 신경을 쓰지 말아야 할까요? 아니면 GPU가 처리하는 일들에 대해 알아야 할까요? 답변은 화자가 어떤 전문성을 가진 개발자이냐에 따라 다를 겁니다.

*게임 업계에서 편의상 부르는 비디오 게임의 분류. 대형 게임사가 대량의 제작비를 투입하여 양질의 게임을 만들어 수백만 장의 판매량을 목표로 하는 게임을 말한다. 즉, 게임계의 블록버스터

미래에는 런타임 배포 시스템에 관여하는 개발자들이 쿠버네티스에 대해 더 많이 알아야 할 것이며, 이들이 플랫폼을 개발하는 사람들이 되리라 생각합니다. 이런 분들은 애플리케이션과 그 실행 환경 사이의 인터페이스에 관여하는 분들이며, 혼합형 데브옵스 역할에 매력을 느끼는 분들이라고 할 수 있겠네요. 반대로 비즈니스 로직을 작성하지 않는 개발자도 여전히 존재할 것입니다.

결론적으로 저는 어떤 개발자냐에 따라서 쿠버네티스를 잘 다룰 수 있어야 할 수도 있고, 알지 못해도 괜찮을 수 있다고 생각합니다. “데브옵스”나 “클라우드 네이티브"가 정확히 어떤 걸 의미하는지에 대한 용어를 규정하는 권위자가 없는 상황이기는 합니다만, 저는 개인적으로 클라우드 네이티브는“클라우드 같은 플랫폼(cloud-like platform)"의 장점을 극대화하는 거라고 정의하고 있습니다. “클라우드 같은 플랫폼”이란 쿠버네티스처럼 탄력적이며(elastic), API를 기반으로 하는 셀프서비스입니다. 클라우드 네이티브의 장점은 플랫폼을 만들고 배포하는 개발자들과 사람들이 있고, 그 플랫폼을 기반으로 프로덕트를 구축하는 개발자가 따로 있는 겁니다.

두 분류에는 각자 운영과 개발 관련 역할이 있습니다. 플랫폼에 전문성을 가지고 큐레이팅과 개발하는 직군은 쿠버네티스를 잘 알아야 할 겁니다. 그리고 개발에 집중하는 개발자들은 세부 역할에 따라 다르겠죠. 비교적 단순한 3계층 웹 어플리케이션을 개발하는 분들은 쿠버네티스에 관해 자세히 알 필요는 없을 겁니다.

그리고 머신 러닝처럼 고동적 분산 시스템(high-dynamic distributed system) 관련 작업을 하는 분들은 작업 환경에 대해 조금 더 깊이 파야 할 필요가 있을 수 있습니다. 이 경우는 아키텍처가 조금 더 작업에 특화된 형태니까요.

다시 게임 엔진 예시에 비유하자면, 간단한 게임을 개발하는 경우 엔진을 건드릴 필요는 없습니다. 하지만 조금 더 고급 작업을 하는 사람들은 실제로 C++과 같은 언어로 게임 엔진에 접근할 필요가 있습니다. 정리하자면“개발자”는 획일적으로 정의할 수 없는 직군이기 때문에 “쿠버네티스를 익혀야 하냐”에 대한 의견은 정말 다양하게 나올 수 있습니다.

에브론: 클라우드 네이티브는 노트북에서 실행하거나 디버깅할 수 없다는 우스갯소리에 대해서는 어떻게 생각하시나요?

조 베다: 하하 재밌는 말이네요. 어느 지점 이상부터는 사용자가 직접 디버깅할 수 없는 건 사실입니다. 역설적으로 사용자에게는 좋은 일이기도 하죠. 그 일들은 서비스 제공자가 해결해야 하는 문제니까요. 이 상황에 대한 의견도 조금 전에 언급했던 것처럼 개발자의 유형에 따라 다를 겁니다. 클라우드에서 디버깅은 제한적일 수 있어서 반도체 레벨까지 아주 깊게 파고드는 걸 좋아하는 개발자들은 답답하게 느낄 수 있죠.

에브론: 요즘에는 마이크로서비스 아키텍처로 전환하는 추세가 두드러집니다. 전문가의 관점에서 컨테이너 오케스트레이션이 마이크로서비스를 위한 유일한 방법인가요?

조 베다: 아니요. 컨테이너 없이 마이크로서비스를 하는 분들은 많습니다. 세분된 서비스 지향 작업과 IaaS는 초기 넷플릭스가 많이 했었습니다. 조금 더 말씀드리죠. 초기 넷플릭스 작업의 대부분은 AMI(Amazon Machine Image)* 등을 사용하여 EC2에서 수행되었기 때문에 컨테이너 없이도 작동할 수 있었습니다. 저는 개인적으로 마이크로서비스가 아니더라도 컨테이너를 사용할 수 있다고 생각하지만, 보통 사람들은 마이크로서비스와 컨테이너의 조합을 생각하더군요. 물론 이 모든 것 중에 정답은 없습니다. 단지 작업을 수행하기 위해 사용할 수 있는 도구와 기술, 그리고 패턴이 있을 뿐이고, 그중 몇 가지 도구와 패턴의 궁합이 조금 더 나을 수는 있는 겁니다.

*인스턴스를 시작하는 데 필요한 정보를 제공하는 AWS에서 지원되고 유지 관리되는 이미지

에브론: 특히 컨퍼런스에서 컨테이너 오케스트레이션 시스템의 장점에 대해 자주 이야기하는데, 오케스트레이션의 단점이나 마음에 들지 않는 점, 바꾸고 싶은 점이 있나요?

조 베다: 일이 많아지는 거죠. 그래서 간단한 작업을 할 때는 쿠버네티스나 컨테이너가 적합하지 않을 수 있습니다. 정말 간단한 작업을 하는 경우에는 가상 머신을 실행하고 도커를 설치한 다음에 컨테이너 하나만 실행하면 아무 문제 없이 작동하는 상황도 있습니다. 쿠버네티스와 컨테이너가 모든 사람의 모든 문제를 해결해 줄 수는 없지만 오케스트레이션을 잘 활용하면 일을 더 쉽게 만들 수 있다고 생각합니다.

제가 바꾸고 싶은 게 있느냐에 대한 답변은 제가 프로젝트 관계자인 만큼 아직 모르겠다고 해야겠네요. 저희는 지금도 개선을 위해 노력하고 있는 부분이 있습니다. 관리적인 측면인데요, 쿠버네티스의 생애 주기 관리나 클러스터 관리나 같은 부분입니다. 이 부분들은 저희 팀이 프로젝트 초기에 예상한 것보다 훨씬 더 어렵더군요. 쿠버네티스 컨트롤러 패턴을 사용하여 클러스터 자체를 관리하기 위해서 업스트림에서 많은 작업을 하고 있습니다.

쿠버네티스 컨트롤러 패턴을 사용하여 쿠버네티스 클러스터 자체를 관리하기 위해 업스트림*에서 클러스터 API 같은 많은 작업을 하고 있습니다.

*주로 보편 생태계, 다른 코드, 서드파티 도구에 의존하는 '코어 쿠버네티스 코드베이스'를 의미

YAML을 관리하고 다루며 소프트웨어를 설치하는 방식은 여전히 매우 불안정하고 필요 이상으로 어렵다고 생각합니다. 저는 사실 쿠버네티스를 도입한 지 꽤 지난 지금도 여전히 YAML을 직접 다루는 사람들이 있다는 사실에 놀랐습니다. 저는 이에 대한 몇 가지 세부적인 내용을 “YAML에 대해서는 유감입니다(I'm Sorry About the YAML)”라는 제목의 강연에서 다룬 적 있습니다. 지금까지의 문제는 모두 해결할 수 있습니다. 저희 팀이 하는 일 중에 근본적으로 바꾸고 싶은 게 있는지는 모르겠네요. 어떤 문제든 시간이 주어지면 해결할 수 있다고 생각합니다. 사용자의 말에 귀 기울이고 이터레이션을 계속하면서 개선하면 됩니다.

에브론: 마지막으로 저희가 모든 분께 여쭤보는 “일과 삶의 균형” 질문입니다. 선생님의 삶은 엄청난 양의 대형 프로젝트로 가득 차 있을 것입니다. 바쁜 업무 속에서 효율성을 유지하며 더 나은 세상을 만들기 위해 노력하는 동료 개발자들에게 어떤 조언을 해주시겠어요?

조 베다: 저에게는 더 효과적이고 효율적으로 일할 수 있는 여러 가지 방법이 있습니다. 어떤 방법을 택할지는 여러분이 어떤 유형의 개발자가 되고 싶은지, 자기 기술과 열정이 어디에 있는지에 따라 달라집니다. 저는 소위 “10x 개발자”들을 신뢰하지 않습니다. 인터뷰 초반에 말씀드렸듯이 개발은 근본적으로 팀 스포츠입니다. “빨리 가고 싶으면 혼자 가고, 멀리 가고 싶으면 함께 가라”는 옛말이 있는데요, 팀에 10x 개발자들이 있으면 일을 빨리 마칠 수는 있겠죠. 하지만 단기적인 성공에 그치고 장기적으로는 더 많은 부채를 떠안게 되는 경우가 많습니다. 따라서 진정한 “10배 나은 개발자*”는 주변 사람들의 발전을 돕고, 다른 모든 이의 효율성을 높이는 데 도움을 주는 사람이라고 생각합니다.

*다른 개발자에 비해 10배의 생산성을 보여주는 개발자

10명으로 구성된 팀에서 모든 사람의 업무 효율을 20% 높인다면, 이는 업무 전반의 생산성에 걸쳐 엄청난 승수(multiplier)가 될 것입니다. 그리고 영향받은 이들이 또 다른 이들의 생산성에 긍정적인 영향을 준다면 효과는 이루 말할 수 없겠죠.

일과 삶의 균형에 대한 제 조언은, 혼자서 모든 것을 감당하지 않도록 다른 사람들을 신뢰하고 그들의 퍼포먼스를 높이는 방법을 찾으라는 것입니다. 사람들은 자신이 할 수 있는 수준을 훨씬 뛰어넘는 책임감을 느낄 때 정말 큰 곤경에 빠지게 됩니다. 사람들은 본인이 깊은 책임감을 느끼는 어떤 문제를 해결할 방법이 없을 때 번아웃에 빠지더라고요. 업무 종료시간이 되었을 때 오늘 처리하지 못한 일이 산더미라는 생각이 들면 “일”적으로 번아웃이 오고, 결과적으로 “삶”의 질에도 영향을 미치게 됩니다.

하지만 여러분이 해결하려하는 문제가 혼자 처리할 수 있는 범위에 있는 건지 체크하고, 범위를 벗어나는 일은 팀원들과 협력하여서 솔루션을 만들어내는 게 훨씬 더 지속 가능한 방향이라고 생각합니다.

에브론: 감사합니다 선생님! 그리고 개발자 커뮤니티를 대표해서 쿠버네티스에도 감사 인사드립니다. 이 인터뷰를 통해 개발자들이 조금 더 나은 환경에서 일하게 되고, 세상이 조금 더 살기 좋은 곳이 될 수 있기를 바랍니다.