오픈소스도 안 따지고 사용하면 낭패
오픈소스 소프트웨어는 운영체제(OS)부터 애플리케이션, 인터넷 서비스에 이르기까지 전세계 디지털 경제의 기반이다. 가장 대표적인 오픈소스인 리눅스는 세계 상위 500 대 슈퍼컴퓨터 모두에서 OS로 채택됐고, 지난 십수년 간 곳곳에서 이뤄진 디지털 혁신은 오픈소스 없이 불가능했다. 첫 등장 이래 오픈소스 소프트웨어는 한가지 큰 오해를 받아왔다. 자유롭게 사용하고, 입맛에 맞게 고칠 수 있다는 철학이 '무료로 사용하는 소프트웨어 제품'으로 받아들여진 것이다. 오픈소스 소프트웨어 사용료가 무료긴 하지만, 그 자체는 제품이 아니다. 세상 모든 선택엔 대가가 따른다. 오픈소스 소프트웨어가 세상에 나오는 이유는 다양하다. 개인의 호기심과 이타심일 수도 있다. 홀로 개발하기 힘들어 전세계에 흩어진 불특정 다수 전문가의 도움을 받기 위해 내놓기도 한다. 일반적으로 특별한 역할을 수행해야 하는 능력있는 개발자가 필요한 소프트웨어 요소를 세상에서 찾을 수 없거나 구매할 수 없을 때 직접 만든다. 그가 자신의 소스코드를 일반에 공개하고 나면, 비슷한 필요를 느꼈던 다른 개발자들이 공개된 코드를 수정해 재공개하면서 토론을 이어가고 하나의 커뮤니티를 형성한다. 이렇게 특정 커뮤니티에서 만드는 오픈소스 소프트웨어가 대중적으로 인기를 얻으면, 창조자나 사업에 뜻을 가진 사람들이 해당 오픈소스 소프트웨어로 수익을 거두는 고민을 한다. 이들은 영리법인을 세우고 그 오픈소스 소프트웨어에 기술지원 서비스를 제공하기도 하고, 외부에 공개하지 않는 특별한 기능을 포함시켜 별도의 '상용 패키지 제품'을 판매하기도 한다. 보통 이런 오픈소스 기반 상용 패키지를 '엔터프라이즈 버전'이라 하고, 오픈소스 소프트웨어 프로젝트 자체는 '커뮤니티 버전' 혹은 '업스트림 버전'이라 부른다. 오픈소스 커뮤니티 버전은 기본적으로 무료로 사용가능하다. 대부분의 경우에 충분한 성능을 내며, 소프트웨어 개발에 필요한 조건을 수월하게 제공한다. 자유자재로 코드를 요리할 능력만 있다면, 혹은 검증이나 지원을 받지 않아도 되는 상황이라면 커뮤니티 버전도 좋은 선택이다. 무료로 쓸 수 있는 커뮤니티 버전이 있음에도 엔터프라이즈 버전이 팔리는 데 그만한 이유가 있다. 오늘날 오픈소스 커뮤니티 버전은 일종의 테스트, '맛보기' 버전이다. 최신 기능이 바로바로 추가되는 커뮤니티 버전은 새로운 기능이나 향후 표준을 평가할 때, 버그의 유무를 평가할 때, 개념 증명이나 실험을 할 때 사용하기 적합하다. 오픈소스 프로젝트의 개발 프로세스 상 광범위한 테스트와 검증을 새 버전 업데이트로 수행하므로 사용자는 곧 '베타테스터' 역할을 하게 된다. 안정적이고, 사용자가 예측 가능한 건 엔터프라이즈 버전이다. 커뮤니티 버전의 안정성과 보안성을 검증하고, 호환성과 성능 테스트를 거쳐 출시하는 것이기 때문이다. 지원체계도 마찬가지다. 커뮤니티 버전은 변경사항과 패치 등 품질 관리를 보장하지 않는다. 인력 고용이나 소프트웨어 사용 교육 프로그램도 사용자 스스로 강구해야 한다. 업그레이드와 마이그레이션 시 주요 애플리케이션 호환성도 사용자 스스로 알아봐야 한다. 클라우드 등 다양한 환경에서 여러 OS를 쓰게 되는데 유지보수도 직접 해야 한다. 소프트웨어는 누가 쓰고, 어떤 환경에서 쓰이며, 얼마나 많은 사람에게 쓰이느냐 등 여러 조건 등에 따라 적응해야 하는 생명체다. 상황 변화에 대응하기 위한 패치는 반드시 지속적으로 적용돼야 한다. 작년초 세계를 떠들썩하게 했던 자바 로그4J 보안 취약점은 패치의 중요성을 단적으로 보여줬다. 최신 상태의 자바로 업데이트하지 않았던 사용자들은 로그4J란 도구에서 발견된 취약점에 제때 대응하지 못해 큰 손해를 입었다. 교육도 간과할 수 없는 부분이다. 소프트웨어를 원활히 사용하려면 일정 수준의 지식이 필요하다. 오픈소스 소프트웨어도 제대로, 안전하게 쓰려면 전문 인력을 고용해야 하고, 조직 내에 사용법을 가르치는 교육 프로그램을 마련해야 한다. 소프트웨어 버전 업데이트 때마다 교육도 함께 업데이트돼야 함은 물론이다. 엔터프라이즈 버전은 이런 커뮤니티 버전에 없지만 사업 영위에 필수적인 지원체계를 유상으로 제공한다. 이 차이를 인지하지 못하고 대규모 IT 인프라 구축을 커뮤니티 버전의 이점만 믿고 활용하면 문제에 직면할 수 있다. 커뮤니티 버전은 버전마다 버그 수정을 하지 않고, 버그 수정을 다음 버전에 적용하는 경우가 많다. 테스트베드 환경 구축의 경우 문제되지 않을 수 있지만, 지속적인 업데이트와 장기적인 활용을 한다면 적합하지 않다. 기업이나 기관용 웹애플리케이션서버( WAS)에 활용되는 오픈소스 미들웨어로 와일드플라이(WildFly)가 있다. 와일드플레이는 레드햇 제이보스(JBoss)의 커뮤티니 버전이다. 와일드플라이는 새로운 기능 출시에 초점을 맞추며, 버그나 오류 수정 등의 패치를 필요한 경우 비정기적으로 배포한다. 실험적인 프로젝트와 신속한 기능 검증이 이뤄진다. 반면, 레드햇 제이보스 EAP는 장기간 운영을 위한 안정성과 호환성에 초점을 맞춘다. 레드햇에서 먼저 검증하므로 위험성을 감소시킨다. 고객 요구 사항을 바로 반영하고, 확장성과 보안성, 안정성, 신뢰성 등을 보장한다. 편리한 사용자인터페이스와 경험(UI/UX)도 제공한다. 커뮤니티 버전을 장기간 사용하는 건 보안 측면에서 심각한 문제를 초래한다. 와일드플라이는 10만명 이상의 개발자가 참여하는 프로젝트다. 혁신성은 높지만, 용도에 따라 적합하지 않을 수 있다. 주기적으로 새로운 버전으로 업데이트할 능력만 있다면 와일드플라이로도 충분하겠지만, 대규모 IT 인프라를 매번 간단하게 업데이트하는 건 불가능에 가깝다. 국내서도 와일드플라이는 여러 곳에서 사용된다. 일부 공공기관의 경우 2015년 출시한 와일드플라이 9 버전을 지금도 쓰기도 한다. 현재 베타로 나온 최신 버전은 와일드플라이 27 버전이다. 와일드플라이9에 대응하는 엔터프라이즈 버전인 제이보스7 버전은 2016년 출시됐다. 지금까지 7.4 버전까지 나오면서 2016년부터 8천 건 이상의 보안 및 버그 수정이 이뤄졌다. 반면 와일드플라이 9의 보안 및 버그 수정은 한건도 이뤄지지 않았다. 커뮤니티 버전은 새로운 버전을 내놓으며 버그를 수정했다. 커뮤니티 버전을 처음 그대로 사용한다면 사용자나 서비스 제공업체가 일일이 수정해야 한다. 와일드플라이의 경우 2021년 말 발견된 로그4J 취약점은 한국인터넷진흥원에서 지목한 3개 보안 취약점 중 1개만 조치됐다. 로그4j 취약점 중 'CVE-2021-44228' 원격코드 실행 취약점만 조치됐고, 'CVE-2021-45046' 원격코드 실행 취약점과, CVE-2021-4104 ' JMSAppender를 통한 원격코드 실행 취약점은 조치가 이뤄지지 않았다. 와일드플라이 공식 문서에 따르면, 2021년 12월13일 와일드플라이 공식 홈페이지에서 취약점을 발표했다. 이어 16일 와일드플라이 26.0.0.베타1에서 'CVE-2021-44228' 취약점 조치가 이뤄졌다. 반면, 제이보스의 경우 와일드플라이에서 조치를 취하지 않은 취약점이 당연히 패치를 내놨다. 커뮤니티 버전은 도입을 무료로 할 수 있지만, 이후 수반되는 부대비용이 있다. 현업 시스템에 커뮤니티 버전을 사용하다가 뒤늦게 문제를 겪어 더 많은 비용을 지불하는 경우가 허다하다. 엔터프라이즈 버전은 커뮤니티 버전 활용 시 발생할 수 있는 무한한 비용을 절감하는 방안이기도 하다. 실제로 커뮤니티 버전을 테스트용도로 도입한 뒤 엔터프라이즈 버전 이용으로 전환하는 게 전세계적으로 일반화된 비즈니스의 오픈소스 활용 방식이다. 베트남의 10대 은행 중 하나로 소매 및 기업 금융서비스를 제공하는 베트남해양상업은행은 문자메시지부터 이메일, 모바일 애플리케이션, 소셜 미디어, 채팅 등 다양한 채널을 통해 고객에게 일관된 경험을 제공하기 위해 마이크로서비스 기반 IT아키텍처를 도입하고자 했다. 은행은 커뮤니티에서 제공하는 오픈소스 커뮤니티 버전으로 메시징 플랫폼을 마련하기 시작했다. 하지만, 고객 대면 서비스로 돌입하는 단계에서 안정성과 가용성을 확보하기 위해 엔터프라이즈 버전인 레드햇 엔터프라이즈 리눅스(RHEL)와 레드햇 오픈시프트를 적용했다. 이를 통해 기존보다 30% 비용을 감축하면서 자사의 310만명 이상의 고객에게 5배 더 많은 메시지를 전송할 수 있었다. 새로운 제품과 서비스를 출시하는 데 걸리는 시간을 약 50% 단축할 수 있었다. 교육 출판 기업인 스콜라스틱은 교육 출판 업계 시장의 경쟁 심화, 다양한 기술로 인해 하나의 디지털 학습 툴로 표준화하는 데 어려움을 겪었다. 이에 다른 회사처럼 민첩한 컨테이너 프레임워크의 마이크로서비스 아키텍처를 도입하고자 했다. 쿠버네티스 기반 컨테이너 기술의 커뮤니티 배포판인 OKD(옛 오픈시프트 오리진)으로 시작했지만, 구성의 어려움으로 쿠버네티스 기반 컨테이너 솔루션을 레드햇에서 찾았다. 스콜라스틱은 이를 통해 새로운 애플리케이션 출시 기간을 2개월에서 1개월 미만으로 줄였다. AWS에서 실행되는 오픈시프트 컨테이너 플랫폼을 사용해 비용 효율적 인프라를 사용하고, 레드햇의 컨테이너 기반 인프라로 관리를 더 용이하고 쉽게 만들어 개발 시간을 줄일 수 있었다. 서비스 사용량이 많지 않은 기간에도 개발팀은 매달 여러 새로운 애플리케이션을 출시해야 하는데, 이에 대응하는 안정성을 확보했고, 복원력, 중복성 또는 백업 생성을 걱정하지 않게 됐다. 스콜라틱스의 데브옵스 엔지니어인 유리 디니소프는 “개발자들은 오래 기다릴 필요가 없어졌다”며 “레드햇 오픈시프트에서 애플리케이션을 온보딩, 테스트하며 자체적으로 배포할 수 있게 되어 효율성을 높였다”고 밝혔다. 스콜라스틱의 인프라 관리자인 프라사드 는 “AWS에서 레드햇 오픈시프트를 사용하면 서비스형 재해 복구를 통해 플랫폼 수준에서 복원력을 관리할 수 있다”고 강조했다.
