“운영체제를 컨테이너화한다” 프로젝트 블루핀과 운영체제의 미래

모듈형 하드웨어, 방대한 클라우드 컴퓨팅 리소스, 또는 소형 폼팩터 엣지 디바이스 등 IT의 온갖 발전에도 불구하고 IT는 여전히 규모의 문제를 겪고 있다. 물리적인 규모가 아니다(더 많은 박스, 스토리지 등의 "물건"을 추가하기는 쉬움). 규모와 관련한 어려움은 해당 수준에서 의도한 대로 운영되도록 하는 데 있고, 이를 위해서는 먼저 규모의 성장에 따라 효과적, 효율적으로 애플리케이션을 구축, 배포, 유지관리해야 한다. 이는 데브옵스(DevOps)의 기본 구성 요소인 운영체제가 빠르고 원활하고 단절 없이 확장되어야 한다는 의미다. 

결론부터 말하자면 어려운 일이다. 아주 어렵다.
 

그러나 지금 우리는 운영체제에 대한 또 다른 깨달음의 시대로 들어가는 중일지도 모른다. 대규모 운영체제의 미래를 위한 시작은 '프로젝트 블루핀(Project Bluefin)'이다. 새롭고 그다지 알려지지도 않은 이 데스크톱 리눅스 프로젝트가 어떻게 해서 차세대 엔터프라이즈 컴퓨팅 모델을 예고하는 것일까? 답은 간단하다. 컨테이너화된 운영체제다. 

간단히 말해 이 모델은 완전한 리눅스 배포판이 포함된 컨테이너 이미지다. 기본 이미지를 가져와 그 위에 빌드하고, 작업을 레지스트리 서버로 푸시하고, 다른 시스템에 끌어오고, 디스크에 내려놓고, 베어메탈 또는 가상머신에서 부팅한다. 이를 통해 사용자는 지금 컨테이너 내에서 애플리케이션을 다루는 것과 같은 방식으로 손쉽게 운영체제를 빌드, 공유, 테스트, 배포할 수 있다. 

프로젝트 블루핀이란? 

리눅스 컨테이너는 하이브리드 클라우드 애플리케이션의 클라우드 네이티브 개발과 배포 양상을 완전히 바꾸어 놓았다. 이제는 엔터프라이즈 운영체제에 대해서도 똑같은 일을 할 참이다. 확실히 해두자면, 프로젝트 블루핀은 엔터프라이즈 제품이 아니라 주로 게이머를 염두에 둔 데스크톱 플랫폼이다. 하지만 필자는 이것이 앞으로 닥칠 더 큰 현상의 전조라고 생각한다. 

블루핀을 만든 호르헤 카스트로는 작년 컨테이너데이(ContainerDays) 컨퍼런스의 화상 대담에서 "블루핀은 페도라다. 고유한 방식을 사용해서 원자적으로 쌓아 올린 특별한 조정이 적용된 컴퓨터용 리눅스로, 그동안 리눅스 데스크톱을 괴롭혀온 많은 문제를 해결해 줄 것이라고 생각한다"라고 말했다. 

실제로 모든 리눅스 환경에서 사용자는 그 환경을 자기만의 것으로 구성하기 위해 여러 가지를 손본다. 이유는 많다. 패키지를 추가 또는 변경하려는 경우도 있고, 특정 비즈니스 규칙을 준수하기 위해 변경하는 경우도 있다. 예를 들어 페도라에는 업스트림 오픈소스 콘텐츠만 통합하는 규칙이 있다. 가령 엔비디아 드라이버를 추가하려면 직접 페도라에 첨부한 다음 배포해야 한다. 프로젝트 블루핀은 이와 같은 특별한 소스를 사전에 추가해서 OS(이 경우 페도라)의 배포 용이성을 높여준다. 

블루핀의 '기본' 버전은 GNOME 데스크톱이다. 도크는 하단에, 앱 표시기는 상단에 위치하고 리눅스 앱스토어인 플랫허브(Flathub)가 기본적으로 활성화돼 있다. 카스트로는 "구성 작업은 아무것도 할 필요가 없다. 출처에 대해서도 신경을 쓸 필요가 없다. 우리가 코덱을 알아서 관리해 주고 여러 가지 하드웨어 활성화를 해서 게임 컨트롤러가 작동하도록 해준다. 기본 페도라에서 동작하지 않는 부분이 있다면 우리가 수정한다. 엔비디아 드라이버를 포함해 가능한 한 많은 것을 가져오려고 노력 중이다. 사용자가 업그레이드를 할 때마다 운영체제가 모듈을 컴파일할 이유가 이제 없다. 우리가 CI에서 다 해주기 때문이다. 크롬북을 지향하므로 데스크톱의 유지관리가 완전히 자동화된다. 좋은 클라우드 네이티브 데스크톱라면 당연히 그래야 하듯이 컨테이너 런타임이 함께 제공된다"라고 말했다. 

블루핀에서 보는 엔터프라이즈의 잠재력

프로젝트 블루핀이 구축된 방법과 이유에 대한 카스트로의 설명은 개발자, 아키텍트, 시스템 관리자, 그리고 엔터프라이즈 운영체제를 소비하는 그 외의 모든 사람들이 코어 빌드를 만드는 이유와 놀랍도록 비슷하다. 그리고 이 부분에 엔터프라이즈의 잠재력이 있다. 다만 대부분 사람은 블루핀이 해결하는 문제가 현재 엔터프라이즈의 비즈니스 문제와 동일하다는 사실을 인지하지 못한다. 

모든 것은 카스트로가 언급한 "특별한 조정"에서 시작된다. 

예를 들어, 대형 은행을 생각해 보자. 은행은 운영체제 벤더가 제공하는 것을 받아 그 위에 특별한 조정을 적용해 비즈니스 규칙을 기반으로 각자의 환경에서 용도에 맞게 만든다. 이런 조정이 계속 누적되면 상당히 복잡해질 수 있다. 보안 강화, 라이브러리, 압축 코덱, 암호화 알고리즘, 보안 키, LDAP 구성, 특수하게 라이선스된 소프트웨어 또는 드라이버 등이 추가된다. 복잡한 요구사항이 있는 대형 기업에는 수백 가지의 맞춤 구성이 존재할 수 있다. 실제로 두 기업 사이에서 복잡한 소프트웨어가 이관될 때는 거의 항상 특별한 조정이 필요하다. 대규모 엔터프라이즈 컴퓨팅의 특성이다. 

한 조직 내에서도 복잡하긴 마찬가지다. 보안 엔지니어, 네트워크 관리자, 시스템 관리자, 아키텍트, 데이터베이스 관리자, 개발자와 같은 개별적인 내부 전문가가 특정 기업의 규칙과 가이드라인 내에서 용도에 맞는 하나의 소프트웨어 스택을 구축하기 위해 협업(또는 협업하려고 노력)한다. 특히 기반 OS 구성에서 개발자의 역할이 상대적으로 큰 엣지 또는 AI의 OS에서는 이런 현상이 더욱 두드러진다. 하나의 워크로드를 제대로 처리하기 위해 위의 모든 전문가들이 50~100회 상호작용해야 할 수 있다. 각 상호작용마다 시간이 소비되고 비용이 늘어나고 오류의 여지가 커진다. 

여기에 외부 파트너와 컨설턴트를 더하면 상황은 더 어려워진다. 

지금 이런 모든 전문가들은 서로 통하지 않는 언어를 사용한다. 구성 관리와 킥스타트(Kickstart)와 같은 툴이 도움이 되지만, 복잡하고 때로는 적대적이기도 한 조직 간, 그리고 조직 내 협업에는 잘 맞지 않는다. 그러나 컨테이너를 운영체제 개발과 배포를 위한 네이티브 언어로 사용할 수 있다면 어떨까? 그렇게 된다면 애플리케이션 컨테이너로 해결했던 모든 문제(특히 사람의 문제)를 OS로 가져와 해결할 수 있을 것이다. 

AI/ML은 컨테이너화된 OS에 적합하다

AI/ML은 하이브리드 속성을 갖고 있으므로 컨테이너화된 운영체제에서 특히 흥미로운 사용례다. 많은 경우 기본 모델은 품질 엔지니어에 의해 챗봇 애플리케이션 내에서 학습, 미세 조정, 테스트된다(모두 다른 장소에서). 그런 다음 뒤로 돌아가서 추가 미세 조정을 거치거나 최종적으로 다른 환경의 프로덕션에 배포될 수 있다. 모두 컨테이너를 사용하기에 적합한 형태지만, 개발 단계에서도 추론 속도를 높이고 골칫거리를 줄이기 위해 하드웨어 가속 역시 필요하다. 애플리케이션 실행 속도가 빠를수록 내부 개발 루프는 단축되고 개발자와 품질 엔지니어링 담당자의 만족도는 높아진다. 

가령 개발자 노트북에 로컬로, 아마도 VM으로 배포되었을 AI 워크로드에 대해 생각해 보자. 워크로드에는 사전 학습된 모델과 챗봇이 포함된다. 더 빠른 추론과 챗봇 응답을 위해 하드웨어 가속을 적용해 실행한다면 좋지 않을까? 

이제 개발자가 챗봇을 살펴보다가 문제를 발견했다고 가정해 보자. 개발자는 문제를 해결하기 위해 새 레이블이 지정된 사용자 상호작용(질문과 대답 문서)을 생성하고 부가적인 미세 조정을 위해 엔비디아 카드가 있는 클러스터로 보내고자 한다. 추가 학습이 완료되면 개발자는 일부 추론을 수행하는, 엣지에 위치한 더 작은 디바이스에 모델을 배포하고자 한다. 각 환경마다 하드웨어와 드라이버가 서로 다르지만, 개발자는 동일한 아티팩트(가능한 경우 컨테이너 이미지)로 작업하는 편리함을 원한다. 

이는 어디에나 동일한 방식으로 약간의 조정만 거쳐 워크로드를 배포한다는 개념이다. 운영체제 이미지를 가져와 윈도우 또는 리눅스 노트북에서 공유한다. 개발-테스트 환경으로 옮겨 CI/CD에서 추가로 학습하거나, 다른 특수한 하드웨어로 모델을 다듬는 학습 클러스터로 옮길 수도 있다. 그런 다음 데이터 센터의 프로덕션 또는 클라우드의 가상 데이터 센터나 엣지에 배포한다. 

전망과 현실 

위에서 언급한 부분을 지금 달성하기는 어렵다. 대규모 기업에서는 코어 빌드에만 6개월 정도 걸릴 수 있다. 그 이후에는 분기별 업데이트가 있는데, 이를 준비하는 데도 3개월이 걸린다. 관련된 작업의 복잡함으로 인해 '단순한' 업데이트는 말할 것도 없고 새 제품을 출시하기까지 걸리는 시간도 늘어난다. 사실 업데이트는 컨테이너화된 OS 모델의 가장 큰 가치 제안일 수 있다. 코어 빌드가 완성되면 한 번의 명령으로 업데이트가 가능하기 때문이다. 더 이상 업데이트에서 yum을 실행하지 않는다. 포인트 A에서 포인트 B로 굴리면 된다. 또한 업데이트가 실패하면 롤백하면 된다. 이 모델은 대역폭과 안정성이 주 관심사인 엣지에서 특히 매력적이다. 

컨테이너화된 OS 모델은 어떤 이유로든 조직에서 컨테이너화하지 않기로 결정한 앱에 대해서도 새로운 가능성을 열어줄 수 있다. 애플리케이션을 OS 이미지에 그냥 넣고 베어메탈 또는 가상머신에 배포할 수 있다. 이 시나리오에서 애플리케이션은 컨테이너의 장점을 전부는 아니더라도 일부 얻게 된다. 예를 들어 주제별 전문가 간의 더 원활한 협업, 화물(OCI 컨테이너 이미지와 레지스트리) 전달을 위한 표준화된 고속도로, 프로덕션의 업데이트와 롤백 간소화 등이 있다. 

또한 컨테이너화된 OS는 이론적으로 거버넌스와 출처 정보 측면의 혜택도 제공한다. 컨테이너화된 앱과 마찬가지로 컨테이너화된 OS 내의 모든 요소는 깃허브에 커밋된다. 새로 이미지를 빌드할 때 그 내용물을 정확히 파악한 다음 정확히 이 이미지의 OS를 배포할 수 있다. 또한 CI/CD의 자동화를 포함해서 테스트, 린트, 스캔 인프라를 그대로 사용할 수 있다. 

물론 극복해야 할 장애물도 있을 것이다. 예를 들어, 운영체제를 컨테이너화된 이미지로 배포하는 경우 민감 정보에 대한 생각을 바꿔야 한다. 더 이상 OS에 비밀번호를 내장할 수 없다. 컨테이너화된 앱에도 같은 문제가 있다. 쿠버네티스는 비밀 정보 관리 서비스를 통해 이 문제를 해결하지만, 운영체제가 이미지로 배포된다면 운영체제의 비밀 정보에 대한 대책이 확실히 필요할 것이다. 

컨테이너화된 OS가 엔터프라이즈에서 현실이 되려면 많은 질문에 대한 답을 찾고 많은 시나리오를 고민해야 한다. 그러나 프로젝트 블루핀은 컨테이너화된 OS의 미래를 예견할 수 있게 해준다. 실현되지 않기에는 장점이 너무 많다. 업계가 이 새로운 패러다임을 받아들일지, 그리고 어떤 방식으로 받아들일지 관심을 갖고 지켜볼 일이다.
editor@itworld.co.kr