이제 마이크로소프트 내부에 오픈소스가 확실히 자리 잡았다는 사실만큼은 누구도 부정할 수 없을 듯하다. 현재 마이크로소프트의 엔지니어가 참여하는 오픈소스 프로젝트 수는 2,000개가 넘는 것으로 알려졌다. 

이미지 출처 : Shutterstock

최근에는 마이크로소프트 브라우저 팀이 샤크라 자바스크립트(Chakra JavaScript)를 오픈소스로 공개한다고 발표하기도 했다. 엣지(Edge)와 인터넷 익스플로러를 구동하는 솔루션이다.

그러나 마이크로소프트가 이것을 오픈소스로 배포한 데는 매우 실용적인 이유가 있다. 인기 자바스크립트 런타임인 노드(Node)는 현재 구글의 V8 자바스크립트 엔진에서만 한정적으로 작동한다. 따라서 샤크라를 오픈소스화하면 기존 노드 사용자를 샤크라 환경으로 끌어들여 생태계를 성장시킬 수 있다. 즉 노드를 이용하는 개발자에게 크롬뿐 아니라 엣지 브라우저에도 적용할 수 있는 선택권을 제공해 자사 브라우저 테크놀로지 시장을 확대하려는 계획인 것이다.

오픈소스에 대한 마이크로소프트의 태도 변화는 닷넷, ASP.NET에서도 찾을 수 있다. 기본적으로 이러한 전략엔 커뮤니티의 참여를 끌어내 그들의 아이디어와 전문지식을 이용하려는 의도가 반영돼 있다. 포그 크릭(Fog Creek)이나 자마린(Xamarin) 등 독자적인 닷넷 컴파일러를 개발해 온 소프트웨어 기업이 기존 것을 마이크로소프트의 오픈소스 로슬린(Roslyn) 닷넷 컴파일러로 교체한 것이 단적인 성공 사례다.

이제 마이크로소프트는 이러한 전략을 리눅스까지 넓히려 하고 있다. 큰 계기가 있다. 애저(Azure)다. 마이크로소프트는 클라우드 플랫폼을 운영하면서 그동안 오픈소스로 기여해 온 것 이상으로 리눅스와 깊은 이해 관계를 갖게 됐다. 하이퍼-V 하이퍼바이저에서 구동되는 버추얼 머신이 바로 그것이다. 2015년 9월 이후 애저의 IaaS에서 구동되는 버추얼 머신 중 20% 이상이 리눅스다. 레드햇을 설득해 클라우드폼(CloudForms) 클라우드 관리 플랫폼이 애저를 지원하게 할만큼 리눅스는 점점 중요해지고 있다.

윈도우 서버 기획자 제프리 스노버는 “우리의 클라우드와 패브릭에 대한 비전을 추구하면서 윈도우 워크로드를 지원하는 것만큼이나 리눅스 워크로드를 중요하게 지원하고 있다. 그동안은 윈도우 서버 팀 내의 그룹이 하이퍼-V 리눅스 지원을 맡았지만, 이제는 마이크로소프트의 모든 팀에 리눅스 팀이 따로 있다. 덕분에 테크니컬 프리뷰4(Technical Preview 4)에서는 파워셸 DSC(PowerShell Desired State Configuration) 툴의 리눅스 버전 같은 훌륭한 네트워크 지원을 확보했다”고 말했다.

마찬가지로 닷넷 팀 역시 리눅스에서 닷넷을 사용할 수 있도록 지원을 확대하고 있다. 이는 버라이즌 같은 기업의 요구와도 일치하는 것이다. 현재 버라이즌의 FiOS팀은 가상화 솔루션 '메소스(Mesos)'가 적용된 도커 컨테이너용 리눅스 클러스터에서 닷넷과 ASP.NET5를 운용하고 있다. 마이크로소프트 입장에서는 단순히 비주얼 스튜디오(Visual Studio) 같은 툴 판매 외에 개발 플랫폼을 확장하기 위해 버라이즌을 고객으로 유지할 필요가 있다. 앞으로 윈도우 서버 2016이 도커와 컨테이너 그리고 더 가벼워진 나노 서버를 지원할 예정인데, 리눅스에서라도 닷넷을 유지하도록 해야 다시 고객으로 찾아올 가능성이 있다

스노버는 "버라이즌과 같은 기업이 컨테이너에서 닷넷을 운용하려는 것을 보면 리눅스 그 자체 때문에 이전하는 것이 아니라는 걸 알 수 있다. 이는 윈도우 서버로서는 결정적인 기회다. 사실 이 기업이 정말로 원하는 것은 매우 가벼운 컴퓨트 환경과 애자일한 운용이다. 과거 윈도우 서버 스택과 풀 닷넷 스택에서는 이런 것들이 불가능했지만 이제는 나노 서버와 컨테이너 덕분에 윈도우 서버에서도 가능해졌다”고 말했다.

마이크로서비스로의 이전
최근 닷넷 코어 5는 닷넷 코어 1.0으로, ASP.NET 5는 ASP.NET 코어 1.0으로 각각 명칭이 변경됐다. 오픈소스 버전의 명칭이 바뀐 것처럼 닷넷 자체도 변화하고 있다. 닷넷 코어의 커버리지는 풀 닷넷 4.6 프레임워크에 미치지 못한다(서버-사이드 그래픽스 라이브러리 등을 갖추고 있지 못하기 때문이다). ASP.NET 4.6과 ASP.NET 5(이는 웹 API는 갖추고 있지만, 시그널R(SignalR), VB, F#에 대한 지원은 아직이다)도 마찬가지다.

앞으로 부족한 부분을 채워갈 수는 있겠지만, 새 버전이 언제나 현재의 버전을 대체하는 것은 아니다. 또 새 버전은 더 빠른 릴리즈와 전향성, 그리고 브레이킹 체인지(breaking change)를 피하는 데 중점을 두는 등 새로운 방식을 채택했다.

마이크로소프트 전반에서도 이러한 변화를 볼 수 있다. 마이크로소프트는 지난 10여 년간 애저를 운영하면서 획일적이고 거대한 애플리케이션과 대비되는, 마이크로서비스의 장점을 확실히 깨달았다. 처음에는 전 세계에 서비스를 제공하는 컴퓨트, 스토리지, 네트워킹 및 코어 인프라스트럭처 요소 등의 리소스를 하나의 앱으로 관리했다. 당연히 코드베이스는 난해하고 복잡했고, 하나의 단일한 데이터 센터에서 운용됐다. 업데이트를 테스트하고 릴리즈하는 데만 한 달이 걸렸다. 분기에 한 번 정도밖에 릴리즈가 이루어지지 않은 것도 이 때문이다. 게다가 각 요소의 매니지먼트 툴 역시 하나의 보증서로 관리가 이루어졌다.

이렇게 거대했던 것을 25개의 각기 다른 마이크로서비스로 잘게 나누자 새로운 업데이트를 개발, 테스트, 릴리즈하기 훨씬 쉬워졌다. 새로운 기능이나 업데이트는 테스트 시스템으로 보내 잘 구동 되는지 확인하고, 업데이트 릴리즈 역시 3일 이상 걸리지 않게 됐다. 컴퓨트, 스토리지, 네트워킹 등의 리소스 관리 역시 개별 데이터 센터에서 이루어지고 있다.

이럴 경우 성능이 크게 향상된다. 호주에 있는 애저 데이터 센터에서 사용한 컴퓨트가 텍사스 데이터 센터에 있는 리소스 제공자에 의해 관리되는 것보다는 같은 데이터 센터의 제공자가 관리하는 편이 지연 속도(latency)를 줄이기 때문이다. 컴퓨트와 데이터에 근접하게 배치해 속도만 빨라진 것이 아니라 데이터 센터 간 네트워크에 의지할 필요가 없어져 안정성도 더욱 높아졌다. 각 마이크로서비스를 각자의 구역에서만 운용하도록 제한하면서 보안도 향상됐다.

바로 이런 점이 마이크로서비스의 장점이다. 마이크로소프트는 기업이 이를 손쉽게 애저 서비스 패브릭(Azure Service Fabric)과 사용할 수 있는 방법을 제시하려고 한다. 애저 서비스 패브릭은 닷넷 기반의 마이크로서비스 플랫폼으로(실제 또는 버추얼 머신에서 구동된다) 마이크로소프트가 2003년부터 윈도우 패브릭으로 개발해 왔다.

이 플랫폼에서 처음 제작된 서비스가 애저 SQL 데이터베이스(Azure SQL Database)였다. 현재 애저 도큐먼트DB(Azure Document DB), 이벤트 허브(Event Hubs), 코타나(Cortana), 인튠(Intune), 파워BI(Power BI), 스카이프 포 비즈니스(Skype for Business), 애저 IoT 수트(Azure IoT Suite), 그리고 애저 코어 인프라스트럭처 상의 모든 버추얼 머신이 서비스 패브릭으로 제작되었다. 서비스 패브릭은 앞으로 리눅스, 도커, 자바 등도 지원할 예정이다. 현재 애저에서 사용 가능하며 (2016년 말까지는 완성될) 애저 스택 테크니컬 프리뷰의 일환으로써 각 서버에서(혹은 다른 클라우드 제공자의 서버에서) 구동할 수 있다.

버라이즌 같은 기업이 조금 앞서나간 것일 수는 있으나 클라우드 테크놀로지, 컨테이너, 마이크로서비스 등의 장점을 갖춘 새 애플리케이션의 경우 더 빠르고 민첩한 개발이 핵심이 될 것이다. 스노버는 “모두가 같은 것을 뒤쫓고 있다. 가능한 한 작고, 리소스 효율적인 앱을 만들기 위해 노력하고 있다. 작다는 것은 필연적으로 더 애자일하고, 안전하고, 빠르다는 것을 의미하기 때문이다”고 말했다. 

원문보기: 
http://www.ciokorea.com/news/28326#csidx7ed095e5d82632a95036bc062b341d0