2016년 9월 5일 월요일

마이크로소프트의 개발 환경 개방



마이크로소프트는 닷넷 프레임워크, 비주얼 스튜디오와 같은 언어, 툴 등을 다른 플랫폼에서도 사용할 수 있도록 많은 개방을 하고 있다. 개발자가 윈도우를 무조건 쓸 수 밖에 없게 만드는 비주얼 스튜디오를 OSX와 우분투용으로 공개해버리기도 하고, 오피스의 API도 앞 절에서 살펴본 것처럼 공개한 상태다. 오피스에 어떤 프로그램이든 연결해서 솔루션으로 만들 수 있을 정도로 개방된 환경이다. 또한, 윈도우 플랫폼에서는 웹앱, win32, .Net 뿐만 아니라 안드로이(Android) 자바(Java)/C++, iOS Object C로 만든 앱이 손쉽게 포팅 된다고 알리고 있다. 클라우드에는 분석을 위한 DW를 넣었고, 리눅스 도커가 닷넷을 이용해 윈도우에서 구동이 가능하게 되었다. 또한, 윈도우나 오피스는 패키지 솔루션이 아닌 플랫폼으로 전환하고 있는 상황이다.

마이크로소프트가 이렇게 개방에 적극적인 이유는 패키지 솔루션에서 프레임워크와 디바이스 중심의 환경이 도래했기 때문이다. 개방형 솔루션을 통해 더 많은 플랫폼과 디바이스를 지원함으로써 수많은 사용자가 확보되고 그로 인한 새로운 서비스 창출을 기대하고 있다. 이를 위해, 마이크로소프트웨어는 윈도우와 애저를 주력으로 제공하고 있다. 모든 디바이스에서 반드시 필요한 운영체제인 윈도우와 어떠한 플랫폼에서도 서비스가 가능한 클라우드 서비스인 애저를 통해 윈도우 환경에 익숙하지만 이기종 개발 환경을 사용하는 개발자까지 확보하려 하고 있다(그림9).


<그림9> 뿌리부터 바뀌는 윈도우 “코어”

출처: 한국마이크로소프트 - 돌아보는 빌드2015



마이크로소프트의 개발팀 구성



개발팀을 구성하는 방법은 여러 가지가 있다(참고사이트). 그 중에서 민주적 팀과 칩 프로그래머 팀을 결합한 방법을 취한다. 오피스와 같은 대규모 프로젝트에서는 기술 또는 기능에 따라 팀을 세분화 한다(그림7). 오피스의 경우, 워드, 엑셀, 파워포인트 등 대형의 세부 솔루션들이 존재한다. 각 세부 솔루션 별로 리더를 선정하고 팀을 구별하여 개발을 수행한다.


<그림7> 팀 리더의 계층적 팀 구성

<그림 7>은 팀 리더로 구성되었기 때문에 기술에 관한 팀 구성으로 하나의 프로젝트는 3개의 세부 팀으로 구성되고, 합의와 의사결정은
<그림 8>과 같이 이루어진다. 각 레벨의 팀원들은 동일한 세부 팀에서는 상호 협의가 가능하지만 다른 세부 팀원과의 커뮤니케이션은 반드시 팀 리더나 프로젝트 리더를 통하게 된다.


마이크로소프트의 사업 변화에 따른 솔루션 구성 변화




마이크로소프트의 주 사업 분야는 솔루션 관련 소프트웨어로, 윈도우(Windows)를 비롯해 오피스(Office), 익스플로러(Internet Explorer) 등이 중심에 있다. 해당 솔루션들은 처음에는 단일 PC 환경에 설치되어 구동되던 것에서 다양한 플랫폼에서 구동될 수 있는 형태로 변화되었다(그림3). 그림3의 우측을 살펴보면, 사용자가 다양한 서비스가 원활히 구동되고 추가할 수 있도록 세부 솔루션이 구분되어 있다. 

<그림3> 서비스 중심의 솔루션 구성 환경

출처: Metalogis - 5 Pillars to Optimize Office 365 Readiness


그림3의 우측에는 Azure 솔루션과 O365 솔루션이 구분되어 하이브리드(Hybrid) 형태로 제공되고 있다. 그림2에서 보는 것처럼 소프트웨어 중심일 때는 해당 솔루션을 별도로 패킹되어 제공되었지만, 서비스 중심으로 변화되고 나서는 기본적으로 설치되는 아키텍처와 프레임워크는 같고 세부 솔루션을 선택하는 것에 따라 서비스가 달라지게 된다. 그림2의 디바이스 중심으로 변화하면서, 마이크로소프트의 솔루션 구성은 또 한번의 변화가 생겨나는데 “확장”과 “연결”로 정리된다(그림4). 확장은 마이크로소프트 솔루션에 새로운 기능의 앱을 만들어 마이크로소프트에서 제공하는 “Add-in”을 통해 쉽게 추가가 가능하다. 연결은 서비스하려는 웹 애플리케이션의 인프라 자체를 “SharedPoint Add-in”을 통해 연결이 가능하다.