Korea Evangelist

Developer & Platform Evangelism, Microsoft Korea

  • Korea Evangelist

    Kinect 해커톤 행사 취소

    • 0 Comments

    사정상 6월말에 예정되었던 키넥트 해커톤 행사가 취소 되었음을 알립니다. 추후 개최 시에 다시 공지하겠습니다.

  • Korea Evangelist

    Universal Windows Platform 앱 개발과 앱 모델

    • 0 Comments

    들어가며

    마이크로소프트의 연례 개발자 행사인 Build 2015 에서 많은 사람들이 기대한 내용 중의 하나는 Windows 10에 대한 새로운 소식일 것이다. Build 행사 이전에 Windows 10 개발 플랫폼에 대한 내용이 일부 공개되고 개발 도구와 자료들을 볼 수 있었지만 상세한 내용이 나오지는 않았다. 예상대로 Build 2015 행사에서는 Windows 10이 설치된 다양한 디바이스에서 실행 할 수 있는 Universal Windows Platform(UWP)와 관련한 여러가지 내용을 발표했다. 여기에서는 UWP를 활용한 앱 개발과 앱 모델에 관련한 내용을 이야기 하겠다.

       

    요약

    작년 Build 2014 컨퍼런스에서는 Windows 8.1에서 Universal Windows 앱이라는 이름으로 Windows와 Windows Phone 프로젝트 소스 코드를 공유할 수 있는 프로젝트 템플릿을 제공했다. 그리고 두 플랫폼 간에 코드를 최대한 공유해서 사용 할 수 있는 여러가지 방법들에 대해서도 소개되었다. 하지만 이 방식을 이용하더라도 보여주는 부분은 플랫폼 별로 차이가 많아 UI 부분의 코드는 공유하기 어려웠다. 또한 스토어에 올리기 위해서는 여전히 두 개 플랫폼을 유지하고 별개의 패키지를 생성해야했다.

    Windows 10에서는 UWP를 통해서 디바이스 간에 Core API Layer를 공유할 수 있게 되었다. 이로 인해 다양한 디바이스에 설치 및 구동이 가능한 단일 앱 패키지를 만들 수 있다. 필요에 따라 코드 단에서 디바이스에 따라 특화된 API를 접근해서 분기하는 방식으로 구현해 같은 앱이지만 디바이스에 따라 동적으로 변하는 UI를 구성할 수 있다. 또한 Adaptive UI를 지원하는 컨트롤을 통해서 다양한 화면 크기의 대응 역시 쉬워졌다. 그리고 단일 스토어를 통해서 다양한 윈도우 디바이스에 앱을 배포하는 것이 편리해졌다.

    <그림1. Universal Windows Platform>

       

    디바이스 패밀리

    그러면 먼저 UWP를 통해 다양한 디바이스를 지원하는 앱 개발 시 알아야 할 디바이스 패밀리에 대해서 살펴보자. Windows 8.1까지는 앱을 개발 시에 OS 플랫폼을 대상으로 했던 것과 달리, Windows 10부터는 디바이스 패밀리를 대상으로 하게 된다.

    디바이스 패밀리는 이름과 버전이 포함된 API 집합이며 각 OS의 기반이다. 예를 들면 PC는 '데스크톱 디바이스 패밀리'에 기반을 한 데스크톱 OS에서 구동된다. 폰이나 태블릿은 '모바일 디바이스 패밀리'에 기반한 모바일 OS에서 구동되는 형태이다.

    <그림2. 디바이스 패밀리 계층도>

    디바이스 패밀리를 통해 사용 가능한 API와 시스템 특성 그리고 가능한 동작 방식을 구분할 수 있게 된다. 그리고 스토어에서 앱이 설치될 수 있는 디바이스를 구분할 때도 사용된다.

    유니버셜 디바이스 패밀리의 각 하위 디바이스 패밀리들은 각기 자신의 API를 추가한다. 이 API는 해당 디바이스 패밀리를 기반으로 하는 OS 에서 사용할 수 있고, 결국 그 OS를 사용하는 모든 디바이스에서 그 API를 쓸 수 있다. 이 외에도 해당 디바이스 패밀리를 통해 코드에서 동적으로 특정 기능 사용 가능 여부를 체크할 수도 있다.

    최대한 다양한 디바이스를 지원하기 위해서는 앱을 유니버셜 디바이스 패밀리를 대상으로 개발해서 배포하면, 각각의 디바이스에서 구동 시에는 자신에 맞는 디바이스 패밀리를 대상으로 하게된다. 혹은 필요에 따라 특정한 디바이스 패밀리들에서만 구동되도록 대상을 지정할 수도 있다.

       

    Adaptive UI

    UWP를 활용해서 하나의 앱이 다양한 디바이스에서 자연스러운 사용자 경험을 주기 위해서는 UI가 디바이스의 특성에 맞춰서 변경 가능해야 한다. 예를 들면 스마트폰과 같은 작은 화면 사이즈부터 태블릿, PC 그리고 대형 TV에 이르기 크기에 따라서 보여주는 UI를 최적화할 필요가 있다.

    Windows 10에는 이 같은 다양한 크기의 UI에 대응할 수 있도록 스크린 픽셀 숫자에 맞춰서 대응하는 Universal 컨트롤, 레이아웃 패널 등을 제공하고 있다. 버튼이나 슬라이더, Split View 등과 같이 Universal 컨트롤의 경우 UI가 디바이스에 맞게 자동으로 변경되게 된다. 그리고 키보드, 마우스, 터치, 펜 혹은 Xbox 컨트롤러와도 함께 잘 동작한다. 하지만 Universal 컨트롤 이외에 전체적인 앱의 사용자 경험은 앱이 구동될 디바이스의 상황을 생각해서 개발시 고려되어야 한다.

    <그림3. Universal 컨트롤>

    예를 들면 앱이 구동되는 디바이스의 스크린 해상도에 기반해서 전체적 UI 레이아웃을 조정해야할 수 있다. 예를 들면 아래와 같은 커뮤니케이션 앱이 데스크톱에서 구동될 때는 상대방의 모습을 가로로 보여주며 종료 아이콘을 마우스로 조작 하기에 편한 위치에 배치한다. 하지만 같은 애플리케이션이 폰에서 구동될 때는 한 손으로 조작하기 편한 위치에 상대방의 모습을 세로로 보여주고, 통화 종료 버튼도 크게하는 등 UI 레이아웃 배치를 변경할 수 있다.

    <그림4. Adaptive UI 적용의 예. PC(좌측)와 폰(우측)>

    위와 같은 스크린 사이즈에 기반한 UI 레이아웃이 변경 되도록 앱에 적용하기 위해서는 자식 엘리먼트 간의 관계로 레이아웃을 정의하는 Relative Panel이나 윈도우 사이즈에 따라서 변경할 수 있는 Adaptive Trigger 를 활용할 수 있다. Adaptive UI에 대한 자세한 내용은 이번 기고문 중에 반응형 UI 관련 내용을 참고하길 바란다.

       

    UWP Development

    UWP 개발은 기존 Windows 8.1 개발과 마찬가지로 C++, C#, Visual Basic, Javascript 언어를 사용해서 개발할 수 있다. C++, C#, Visual Basic은 네이티브 UI 구현을 위해 XAML을 사용할 수 있으며, C++의 경우는 XAML이 아닌 DirectX를 사용해서 UI를 구현할 수도 있다. 그리고 Javascript는 크로스 플랫폼 웹 표준인 HTML을 UI에 사용한다. 특정 디바이스 패밀리에 맞도록 코드를 동적으로 변경하거나, 특정 폼 팩터에 맞게 UI를 변경하기 위해서 adaptive 코드와 adaptive UI를 사용할 수 있다. 아래에서 Adaptive 코드 구현 방법에 대해서 알아보겠다.

    일단 어떤 API를 호출하는 경우에 해당 API가 현재 대상으로 하는 디바이스 패밀리에 구현된 API인지 여부를 확인하는 것이 필요하다. 확실치 않을 경우에는 해당 API 레퍼런스 문서를 참고해서 디바이스 패밀리가 어떤 것인지 확인하면 된다. Visual Studio 의 인텔리센스 기능이 API를 인식하지 못할 경우에는 대상 디바이스 패밀리에 구현이 안 되었거나 추가된 디바이스 패밀리와 관련된 extention SDK에도 없기 때문이다.

    만약 대상 디바이스 패밀리에 구현이 되지 않은 API를 호출하는 경우에는 adaptive 코드를 작성할 수 있다. 이렇게 하기 위해서는 먼저 대상 디바이스 패밀리의 extension SDK를 프로젝트의 참조에 추가해준다.

    <그림5. extension SDK 참조에 추가>

    그리고 Windows.Foundation.Metadata.ApiInformation 클래스를 사용해서 호출하고자 하는 API가 사용 가능한지 여부를 확인할 수 있다. 이 체크는 앱이 실행 중에 수행 되며, 상황에 따라 ApiInformation의 IsTypePresent 메소드 등을 사용해서 체크 할 수 있다.

    <그림6. 앱 구동시 API 사용여부 체크>

       

    App Model - App Lifecycle

    UWP가 다양한 디바이스에서 구동되는데 필요한 부분을 살펴보았고, 이제 UWP 앱 모델의 추가 및 변경된 부분에 대해서 살펴 보겠다. 앱 모델은 앱의 설치 방법, 상태 저장, 버전 관리와 같은 라이프사이클 관리와 OS 및 다른 앱들과의 통합과 사용자 데이터 접근 권한 등에 대한 내용을 포함한다.

    먼저 라이프사이클과 관련해서 UWP 앱은 크게 미 실행(Not Running), 실행(Running), 중지(Suspended) 세 가지 상태를 갖는다. 리소스 부족 등으로 중지 상태에서 미 실행 상태로 가는 경우를 제외하면 각각의 상태가 변할 때 마다 이벤트가 발생한다. UWP에서 추가된 부분으로 앱의 상태가 실행에서 중지 상태가 될 때 필요한 작업을 위해서 연장 실행(Extended Execution)을 요청할 수 있다. 그리고 위치 트래킹 앱과 같은 앞단에 계속 떠있지 않아도 실행이 되어야 ���는 경우는 앞단에서 사라지더라도 연장 실행을 요청할 수 있다.

    <그림7. UWP 앱의 연장실행- 중지상태에 들어갈때(좌측)와 다른 앱이 실행될때(우측)

    그리고 기존 Windows 8.1 이나 Windows Phone 8.1에서 백그라운드 태스크에 기반한 다양한 트리거가 있었던 것처럼 UWP에도 Application Trigger, Socket Trigger를 비롯 다양한 Trigger 들이 추가 되었다.

    <그림8. Windows 10 Trigger>

       

    App Model – Navigation & Windowing

    네비게이션 및 창 모양과 관련한 부분을 살펴보면 Windows 10의 경우 창모드가 가능해졌다. 실행 시에 원하는 크기를 설정할 수도 있고, 전체 화면 모드로 실행 시킬 수도 있다. 물론 실행 중에 크기를 변경할 수도 있다. 따라서 SizeChanged 이벤트를 활용해서 사이즈가 변경 될 때 적절하게 UI를 업데이트 해주는 것이 필요하다.

    <그림8. 윈도우 창 모드로 열린 UWP 앱>

    그리고 UWP 앱에서 뒤로 가기 버튼 사용이 가능해졌다. 태블릿 모드에서 뒤로 가기 버튼은 폰과 동일한 사용자 경험을 주게 되며, PC용 UWP 앱에서도 더 이상 뒤로 갈 수 없는 경우에 UI에서 없애는 것을 포함해서 항상 뒤로 가기 버튼을 지원하는 UX 가이드라인을 따르는 것이 필요하다.

     

    <그림9. Windows 태블릿의 뒤로가기 버튼(좌)과 Store 앱의 뒤로 가기 버튼 UI(우)>

       

    App Model – Tile, Notification & Action Center

    타일은 Windows 플랫폼의 가장 특징적인 UI 중의 하나이다. 기존에 향상되어 온 타일 기능에 더해서 UWP 에서는 Adaptive 타일 템플릿이 추가되었다. 이 템플릿을 사용하면 디바이스 화면 크기에 맞춰서 내용을 보여줄 수 있게 된다.

    <그림9. Adaptive 타일>

    또한 Windows Phone 8.1에서 처음 선보였던 액션 센터(Action Center)는 Windows 10에서는 PC용에서도 추가되었다. 토스트 메시지가 자동으로 액션 센터로 가며, 앱 그룹별로 삭제할 수 있으며 개별 알림을 지울 수도 있다. 액션 센터에서 트리거를 활용해서 타일과 액션 센터 간의 내용을 동기화 할 수 있다. 그리고 Adaptive 토스트 템플릿으로 바로 메시지에 대한 회신을 보낸다거나, 수락 혹은 거절을 처리할 수도 있다.

    <그림10. Adaptive 토스트>

       

    App Model – Packaging

    앱 설치와 관련해서는 새로운 부분은 Windows 10부터 앱 설치 시에 이동식(Removable) 저장소에 설치하나 혹은 이미 설치된 앱을 이동식 저장소로 옮길 수 있게 되었다. 앱은 이동식 저장소에 보안을 위해 암호화 되고 격리된다. 이동식 저장소에 설치 가능 여부는 기본적으로는 활성화 되어 있지만, 안정성 등의 이유로 이를 불가능 하도록 manifest 에서 설정 할 수도 있다. 또한 같은 퍼블리셔의 앱들 간에는 앱 데이터 저장소를 공유할 수 있다.

    <그림11. Windows 플랫폼 별로 앱 패키징 및 스토어 기능 정리>

       

    UWP Bridges

    지금까지 UWP 앱 모델에 대해서 살펴보았는데 기존 Windows 데스크톱 앱의 경우는 앱 모델이 명확하게 정의되어 있지 않았다. Win32 및 .NET Framework 등으로 개발된 Classic Windows App(CWA)의 경우는 라이프사이클 관리 부분에 대한 번거로운 부분이 있었다. 현재 CWA를 UWP 로 옮기는 Project Centennial 프로그램이 진행 중에 있다. 이를 이용하면 CWA도 윈도우 스토어 용 AppX 패키지로 배포되어 더 나은 설치, 삭제 그리고 업데이트 방법을 갖게 된다. 또한 런타임이 레지스트리나 디스크 접근을 제한하고, 앱 모델 정책을 강제함으로써 시스템 컴포넌트 접근, 관리자 권한 획득 등을 하지 못하도록 할 수 있다. 사용자 입장에서는 앱을 설치 후 삭제해도 Windows 시스템의 Registry가 덜 제거되거나, 전체 시스템에 느려지는 현상들을 막을 수 있게 되고, Windows Store를 통해 쉽게 앱을 설치할 수도 있게 된다.

    <그림12. Project Centennial>

    이 외에 UWP 앱으로 가는 Bridge 프로젝트로 진행 중인 것들이 있다. 웹사이트를 UWP 앱으로 만드는 Project Westminster, 안드로이드 코드를 Windows 10 폰 대상으로 만들 수 있게 해주는 Project Astoria, 기존 Objective-C 코드를 Visual Studio 2015로 UWP 앱을 만들수 있게 하는 Project Islandwood. 현재 제한된 개발자 프리뷰 형태로 진행 중이니 관심 있는 개발자는 신청할 수 있다.

    <그림13. UWP Bridge>

       

    지금까지 UWP 앱 개발 및 앱 모델에 대해서 간략히 알아보았다. 보다 자세한 내용은 Build 2015의 관련 세션과 윈도우 개발자 센터의 문서를 참고하길 바란다. 아무쪼록 UWP가 제공하는 플랫폼적인 완성도와 기존 개발자들을 위한 다양한 Bridge 기술 들이 활용되어 전세계 10억대의 Windows 10 디바이스를 대상으로 전 세계 수 많은 개발자들이 UWP 앱 개발을 하는 날을 기대해본다.

    (이 포스트는 마이크로소프트웨어 2015년 6월호 Build 2015 특집으로 기고된 내용과 동일하며, MSDN의 Guide to Universal Windows Platform (UWP) apps 문서를 참고하여 작성되었습니다.)

  • Korea Evangelist

    Build 2015에서 만난 Microsoft IoT

    • 0 Comments

    Build 2015에서 발표된 내용이 너무 많아서 그런지 상대적으로 눈에 띄지 않았던 부분이 바로 IoT 관련 내용이었습니다. 둘째 날 키노트에서 축산 농장에서 소의 발정기를 정확하게 파악하기 위한 용도로 센서 디바이스와 Azure를 기반으로 한 클라우드 서비스를 개발한 내용이 소개 되었습니다.

     

    <그림1>Fujitsu 의 사례로 소개된 축산 농장에서 소의 발정기를 파악하는 IoT 솔루션

    가축의 경우 제조되는 상품이 아니기 때문에 정확한 발정기를 파악하는 것은 축산 생산량에 크게 기여를 합니다. 위의 사례에서도 소의 발정기를 정확하게 파악하는 것으로 소의 임신 확률이 비약적으로 향상되었습니다. 간단한 센서를 활용한 사례이지만 데이터에 기반한 서비스의 개발은 현실에서 새로운 기회를 만들어 줄 수 있다는 것을 보여주고 있습니다.

    <그림2>센서 데이터를 분석해서 가임기를 파악할 확률을 95%까지 올렸으며 그 결과 임신 확률을 67%까지 상승 시켰다.

    IoT에서 중요한 것은 데이터이고 이 데이터를 수집하고 분석하고 분석된 결과를 효과적으로 가공해서 제공해주는 것이 핵심이라고 할 수 있다. Build 2015에서도 이런 부분을 사이사이에 설명하고 강조하고 있었는데 첫째날 키노트에서 소개된 Azure Analytic Services라고 소개된 슬라이드 안에서 잘 볼 수 있다.

    Azure Analytic Service에서 소개된 서비스들은 아래와 같다.

    • HDInsight
    • Event Hub + Stream Analytics
    • Data Factory
    • Machine Learning
    • Power BI
    • SQL Data Warehouse
    • Data Lake

    <그림3>Azure Analytic Services를 보여주는 슬라이드

    이날 소개 된 서비스 중에서 처음 공개된 것은 SQL Data WareHouse, Data Lake 등이고 나머지는 이미 서비스 되고 있던 것들을 묶어서 보여주고 있다. HDInsight는 하둡(Hadoop)을 이용하는 서비스로 주로 저장되어 있는 빅데이터를 분석할 때 사용하는 서비스라면 Event Hub + Stream Analytics의 경우는 실시간으로 들어오는 데이터를 분석하기 위한 용도로 사용된다. 이 둘의 용도는 완전히 다른데 HDInsight에서 사용되는 데이터들은 이미 저장되어 있는 데이터를 기반으로 분석하기 때문에 이미 분석 결과는 과거의 데이터(Historical Data)가 된다. 반면에 Event Hub로 수집된 방대한 데이터를 Stream Analytics를 사용해서 분석하는 경우의 데이터 결과는 실시간으로 판단하기 때문에 거의 시간차가 없는 실시간 데이터(Realtime Data)가 된다.

    <그림4>둘째 날 보여주었던 Stream Analytics 시연 모습. 실시간으로 들어오는 큐에 쿼리를 이용해서 즉각적으로 데이터를 확인할 수 있다.

     

    Build 2015에서 Keynote 세션에서는 이렇게 서비스와 데이터를 강조했다면 또 디바이스를 다루는 세션에서는 Windows 10 Core를 활용하는 디바이스 사례를 보여주었다.

    <그림5>Windows for Makers Raspberry Pi2, Arduino, and more! 이 세션은 사람이 미어터져서 못들어간 사람도 많았다.

    메이커들을 위한 세션이었지만 기본적으로 Windows 10 Core가 들어간 Raspberry Pi2에 대한 관심이 높았고 대부분의 사람들이 여기에 관심이 높아서 질문도 많았다.

    <그림6>Raspberry Pi2를 소개하는 슬라이드. Raspberry Pi 2에서는 PCIe, PCI, RS-232 인터페이스를 지원한다.

    Microsoft는 Raspberry Pi 2를 제작하는 과정에서 공식적인 스폰서로 나서기도 해서 관심을 끌었다. 이 세션에 사용된 Raspberry Pi 2에는 Windows 10 이미지가 탑재되어 있었으며 PC에는 Watcher 프로그램을 하나 띄워놓고 이를 통해서 Raspberry Pi 2와 통신하는 방법을 사용했다. 

    <그림7>간단한 블링크 예제 

    <그림8>Visual Studio 에서 C#코드로 작성된 블링크 소스. 디버깅과 인텔리센스에 의한 생산성 향상이 눈에 띈다.

    한 가지 재미있는 점은 Raspberry Pi 2에 올라간 Windows Core나 PC나 Windows Phone에 들어간 Windows Core는 같은 것이라는 점이다. 그래서 기본적인 로직은 모두 동일하게 작성할 수 있으며 GPIO와 같이 해당 디바이스에 특화된 부분만 코드가 달라진다. 그래서 일반 개발자들이 진입하기가 훨씬 쉬워졌을 뿐만 아니라 좀더 체계적이고 대규모 프로젝트에서 활용할 수 있을 만한 신뢰성을 확보 할 수 있게 되었다.

    Your Complete Maker Toolkit이라는 것을 소개했는데 Windows 10, Visual Studio와 Raspberry Pi 2와 전자 부품들 약 25종을 합쳐 놓은 것을 소개했다. 이 Toolkit은 C#으로 코딩하고 XBOX 360 컨트롤러로 컨트롤 할 수 있는 제품을 만들 수 있도록 구성된 것으로 제법 구성이 알차다. 

    Raspberry Pi 2에서 Visual Studio를 활용할 수 있게 된 것은 개발자들이 크게 환호할 정도로 뛰어난 점이지만 Raspberry Pi 2만 가지고는 완전하지 않다. 왜냐하면 Raspberry Pi 2 는 ADC(Analog Digital Converter)가 없기 때문에 주로 게이트웨이로 활용되고 있고 센서노드의 역할은 여전히 Arduino 혹은 Netduino와 같은 디바이스들로 처리하는 경우가 많기 때문이다.

    그래서 이번에 또 추가로 공개 된 것이 Project Margherita이다. 이 프로젝트는 Universal Windows Platform 에서 Arduino를 연결할 수 있게 해주는 브릿지를 제공해주는 프로젝트이다.

     


    (상) Project Margherita의 공개

    (중) Project Margherita를 사용한 Arduino 프로젝트 데모

    (하) 스마트폰으로 사진을 촬영하고 이를 Arduino에 보내서 LED 매트릭스에 사진을 출력하는 데모를 하고 있는 모습.

    그리고 이날 .NET Micro Framework을 활용하는 Netduino 3 WIFI, Netduino 3 Ethernet 버전과 Gadgeteer를 공개했다.

     

    Windows 기반의 디바이스에 관한 정보는 WindowsOnDeives.com에서 추가적인 정보를 얻을 수 있으며 Youtube 채널을 보고 있으면 영어와는 상관없이 많은 정보를 얻을 수 있다. 

     

    그리고 이 세션의 하일라이트는 원 모얼 띵스..... 이날 소개된 모든 디바이스를 세션 참석자들에게 모두 나누어 주었다. 이 발표가 나오자 마자 격한 환호성이 터져 나왔다.


    Build 2015에서 Microsoft는 IoT를 위한 각종 Azure 기반의 서비스들과 Windows 10 Core, .NET Micro Framework을 사용하는 디바이스를 소개하면서 IoT에 필요한 Microsoft의 해법을 보여주었다. 얼마 전 공개된 IoT Suite가 이번에 공개되지 않은 점은 아쉽긴 하지만 이 부분 또한 그리 멀지 않은 시기에 공개 될 것으로 기대 된다.

  • Korea Evangelist

    가장 혁신적인 크로스 플랫폼 통합 개발도구 Visual Studio 2015

    • 0 Comments

    Build 2015에서는 수많은 새롭고 혁신적인 발표와 더불어 Microsoft 최고의 개발도구인 Visual Studio의 새로운 버전에 대한 발표도 있었습니다. 새롭게 공개된 Visual Studio 2015는 기존 버전인 Visual Studio 2013에 비해 한 단계 더 발전된 모습의 통합을 제공하는 진정한 통합 개발도구의 모습을 보여주고 있습니다. 모바일 개발과 클라우드 개발을 단일 도구에서 모두 개발할 수 있다는 통합을 넘어서서 또한 Microsoft 플랫폼에 국한된 개발 도구 통합을 넘어서서 이제는 Mac OS, Linux 에서도 Visual Studio를 사용할 수 있도록 하는 완전한 개발 도구 대통합의 역사를 시작하려 하고 있습니다. 물론, 아직은 이러한 시작이 다양한 플랫폼의 개발 전문가들에게 충분히 만족스럽지는 않을 수 있겠지만, 이번 Visual Studio 2015를 기점으로 하여 대통합이 본격적인 궤도에 올랐다는 관점에서 보면 상당히 큰 사건임에는 틀림이 없습니다. 그렇기에, Build 2015 이후 많은 개발자들이 Visual Studio의 행보에도 큰 관심을 보내는 것이겠지요. 그리고, 그 움직임의 중심에는 새롭게 Visual Studio 패밀리에 포함된 Visual Studio Code가 있습니다.

    Visual Studio Code (Preview)

    아직은 미리보기(Preview) 버전으로 공개되긴 했지만 Visual Studio Code는 그 모습이 공개되자마자 전 세계를 술렁거리게 했습니다(적어도 제 마음은 술렁). 사실상 VS Code는 코드 편집기 수준의 멀티 플랫폼 에디터이지만 혹자들 사이에서는 Visual Studio IDE(통합 개발 환경, Integrated Development Environment)의 전체 기능이 Linux를 비롯한 모든 플랫폼에 무료로 제공되는 것이 아닌가 하는 오해를 불러일으킬 만 하기도 했습니다. 아무래도 제품의 명칭이 비슷하다 보니 그런 오해가 있었을 수도 있는데요, 현재 공개된 Visual Studio Code는 다양한 플랫폼(Mac OS X, Linux 등)에서 무료로 설치하여 사용할 수 있는 크로스 플랫폼 코드 편집기입니다. IDE라고 할 수는 없지만 약 20여개의 개발 언어의 구문 컬러렁 및 개발 편의성을 지원하며, 몇몇 언어의 경우는 인텔리센스 및 디버깅 기능까지 지원하는 훌륭한 편집기 입니다.

    요즘의 많은 개발자들은 2개 이상의 개발 도구를 병행하여 사용하면서 개발을 하는 편입니다. 개발 생산성을 높여주는 IDE를 주된 개발도구로 이용하기도 하고 또는 IDE는 상대적으로 무겁다보니 가벼운 코딩이나 웹 페이지 편집을 위해서 별도로 경량의 개발 편집기를 병행하여 사용하기도 합니다. 굳이 이름을 대지 않아도 여러분 또한 이미 몇몇 유명한 편집기를 하나 이상은 여러분의 머신에 설치해 두었을 것이라 생각합니다(울트라 에디트나 서브라임 텍스트, 아톰 등). 심지어는 아예 IDE는 사용하지 않고 이러한 경량의 코드 편집기와 명령줄(Command-Line) 도구들을 메인 개발 도구로 사용하는 개발자들도 많습니다. 요즘의 개발 트렌드를 보면 굳이 IDE의 복잡한 기능들을 학습하지 않아도 개발할 수 있는 가벼운(?) 개발 업무들도 많아졌기 때문입니다. 특히나 웹 UI와 관계된 작업이라면 더욱 그런 편이기도 합니다. 물론 Microsoft 플랫폼 전문 개발자들이라면 '다 필요없고 Visual Studio IDE 하나로 끝'이기는 하지만 그래도 간혹 가볍게 사용하는 편집기 하나, 둘 쯤은 있지 않습니까?

    해서, Microsoft는 이러한 트렌드에 발 맞추어 개발자들이 웹 및 클라우드 애플리케이션을 개발하는 데에 활용할 수 있도록 완전히 새로운 크로스 플랫폼 코드 편집기를 공개하였습니다. 네. 아시다시피 이 도구가 바로 Visual Studio Code 입니다. 놀랍게도 이 도구는 기존의 Microsoft 개발도구와는 달리 Mac OS X와 Linux, Windows 플랫폼 모두에 설치가 가능한 오프라인용 개발 편집기이며 별도의 비용없이 무료로 설치하여 사용할 수 있습니다.

    Visual Studio Code는 수많은 복잡한 기능으로 채워진 IDE의 형태가 아닌, 가볍고 빠르게 개발할 수 있는 에디터 중심의, 코드 개발도구로 자리 매김을 하고 있습니다. 그러면서도 나름대로는 고급스러운 개발 편의 기능도 내장을 하고 있으며 계속해서 이러한 고급 기능이 추가될 예정에 있기도 합니다. 그렇다 하더라도 기본 목표인 가볍고 빠른 코드 편집기로서의 정체성은 꾸준히 유지할 것으로 보입��다.

    image

    <그림 1. Mac OS에서 실행중인 Visual Studio Code>

    Visual Studio Code는 단지 가볍고 빠른 단순한 코드 편집기라고 하기에는 기존의 다른 편집기들과는 달리 막강한 기능들도 내장하고 있습니다. 예를 들면, 다양한 개발 언어에 대해서 구문 하이라이트, 괄호 매칭, 자동 들여쓰기 및 코드 스니펫 등의 기능을 지원하고 있으며 다양한 키보드 단축 기능들도 지원합니다. 현재 지원하고 있는 개발 언어는 다음과 같습니다만 이는 이후에 더 늘어날 예정에 있습니다.

    C++, jade, PHP, Python, XML, Batch, F#, DockerFile, Coffee Script, Java, HandleBars, R, Objective-C, PowerShell, Luna, Visual Basic, Markdown, JavaScript, JSON, HTML, CSS, LESS, SASS, C#, TypeScript

    image

    <그림 2. 다양한 키보드 단축 명령들>

    VS Code는 파일 및 폴더를 기반으로 하기에 원하는 파일을 열고 싶다면 다음과 같이 명령 창에서 Code 명령어와 함께 파일명을 기입해주면 됩니다(물론, 바탕화면의 VS Code 아이콘을 클릭해서 실행할 수도 있습니다).

    code index.html

    어떤 폴더를 기반으로 편집기를 실행시키고 싶다면 해당 폴더명을 Code 명령어와 함께 실행하면 됩니다.

    code c:\src\contents

    게다가, 최대 3개의 편집 화면을 동시에 실행할 수 있는 Side by side 기능을 제공하기에 여러 개의 파일을 동시에 편집할 수도 있습니다. 또한, VS Code는 편집기의 마지막 상태를 자체적으로 저장하기에 VS Code를 닫고 다시 시작하는 경우 마지막 열었던 폴더나 파일을 자동으로 열어주며 그 당시의 편집기 레이아웃도 그대로 유지해 주는 뛰어난 사용자 경험을 제공합니다.

    image 

    <그림 3. 동시에 3개의 편집화면 지원 및 편집환경 자동 저장>

    또한 기본적으로 Git과 통합되어 있어서 개발 소스의 형상관리 뿐만 아니라 Git 워크플로우를 그대로 활용할 수 있습니다.

    개발자가 모든 시간을 코딩하는 데에만 보낼 수 있다면 정말로 행복할 뿐만 아니라 높은 생산성도 올릴 수 있겠지만 현실은 그렇지가 않죠. 어떤 이들은 충분히 테스트를 한다면 디버깅은 필요하지 않다고도 하지만 사실 개발하면서 디버깅은 선택적이라기 보다는 필수적인 것이라 할 수 있습니다. 설령 토니 스타크(아이언맨)가 개발한다고 해도 사람이기에 실수없는 완벽한 코딩은 불가능할 것이기에 디버깅은 필요할 수 있습니다(어쩌면 토니는 코딩만 하고 디버깅은 자비스가 할는지는 모릅니다만 :p). 디버깅이 필요없다고 하시는 분들은 어쩌면 아직까지 제대로 된 디버거를 경험해 보지 못했기 때문이 아닐까 싶은데요, 어쨌든 디버깅이라는 기능은 Visual Studio가 자랑하는 가장 대중적인 기능일 뿐만 아니라 경량의 코드 편집기만을 사용하는 개발자들이 가장 원하는 기능이기도 합니다. Visual Studio Code는 이러한 여러분의 기대에 어긋나지 않도록 간결하고도 통합된 디버깅 경험을 제공하고 있습니다. 비록 통합개발 도구인 Visual Studio IDE에 비하면 약간 부족한 느낌은 있지만 가벼운 편집기에서 사용하기에는 충분할 정도로 훌륭하게 지원을 합니다.

    image

    <그림 4. 디버깅 지원>

    아쉬운 점은 현재 미리보기 버전에서는 ASP.NET 5와 Node.js에 대한 디버깅만 지원되고 있다는 것인데요. 정식 버전이 공개될 때에는 더 많은 언어를 지원할 것으로 예상이 됩니다.

    image

    <그림 5. 현재 디버깅이 가능한 언어는 ASP.NET 5와 Node.js>

    또한, 조만간 VS Code에 대한 공용 확장성 모델을 공개할 예정에 있기에, 이를 활용하여 좀 더 많은 언어들이 VS Code와 통합될 수 있을 것으로 예상하고 있습니다.

    추가적으로 Visual Studio Code가 Atom을 그대로 모방했다는 이야기들을 많이 하는데요. 엄밀히 말하자면, VS Code는 크로스 플랫폼 데스크톱 애플리케이션 쉘(Shell)인 일렉트론(Electron)을 기반으로 개발되었습니다. 예전에는 Atom Shell로 불렸던 일렉트론은 물론 그 태생은 GitHub의 Atom 편집기를 만들기 위해서 개발된 기술이지만, 현재는 Node.js, HTML, TypeScript , CSS와 같은 웹 기술을 사용하여 크로스 플랫폼 데스크톱 응용프로그램을 개발할 수 있게 하는 오픈소스 기술로서 공개되어 있습니다. 이에 대한 더욱 자세한 내용은 http://electron.atom.io를 살펴보시면 될 듯 합니다. 더불어, 일렉트론을 기반으로 하여 개발된 다른 편집기들로는 Visual Studio Code 뿐만 아니라 Atom, Slack, Spark 등이 있습니다. 그렇기에 Atom과는 형제 격이라고 볼 수 있을 듯 합니다. 하지만 과연 Visual Studio Code가 Atom이나 Spark와 같은 여타 편집기와 비슷비슷하게 취향에 따라 선택되는 하나의 편집기가 될 것인지 혹은 독보적으로 Window와 Mac, Linux를 평정하는 올스타 코드 편집기로 자리매김 하게 될 것인지 그 미래가 궁금해 집니다.

    번외로 첨언하자면, 혹시 여러분 중에 브라우저 기반의 클라우드 IDE인 Visual Studio "Monaco"를 기억하시는 분이 있다면 그 또한 Visual Studio Code와 마찬가지 기술 기반을 채택한 것이 아닌가 생각하셨을 수도 있을텐데요. 훌륭한 추측입니다. Visual Studio Code와 Visual Studio "Monaco"는 UI나 동작 방식이 거의 동일합니다. 차이가 있다면 VS Code는 오프라인 편집기이고 VS "Monaco"는 온라인 편집기라는 것이 차이죠.

    아직 미리보기 버전이기는 하지만 이래저래 다른 편집기에 비해서 갈수록 막강하게 변신할 것으로 예상되는 Visual Studio Code를 미리 체험해 보고 싶다면 다음 링크에서 다운로드 받아 보시기 바랍니다. https://code.visualstudio.com/

    Visual Studio 2015 RC

    Visual Studio 2013은 기존 버전보다 진일보한 비동기 기능을 탑재했으며, 클라우드와 연결된 IDE를 공개했을 뿐만 아니라, 코드 피킹과 같은 강력한 개발 생산성 기능까지 선보였던 획기적인 개발 도구였습니다. 아직까지도 역대에서 가장 훌륭한 개발도구로 손꼽히고 있죠(적어도 제 손에서는 말이죠). 그런데, Visual Studio 2015가 되면서 그 위에 추가적으로 윈도우 에코 시스템을 위한 완전한 지원이 포함되었으며, 크로스 플랫폼 모바일 앱 개발을 위한 혁신적인 기능도 덧붙여졌고, 클라우드 개발을 지원하기 위한 수 많은 기능 추가 및 스마트한 테스트 기능까지 더해졌습니다. 이러한 각각의 기술 분야를 지원하는 내용들은 사실상 워낙 방대하여 그 모든 내용을 이 컬럼에서 다루기는 어려울 것 같습니다. 그렇기에, 각 기술 분야에서의 Visual Studio의 활약상은 관련 컬럼에서 자세한 내용을 확인하시는 쪽을 권장합니다. 어차피 그러한 훌륭한 기술들도 여러분이 실제로 구현하기 위해서는 이렇든 저렇든 Visual Studio의 도움이 필요할 수 밖에 없으니까요. 그렇기에, 여기서는 가장 핵심이 되는 내용만 간단하게 살펴본 뒤 IDE에서 제공하는 특징적인 기능들 위주로 정리를 해보려 합니다.

    Visual Studio 2015와 함께(혹은 비슷한 시기에) 출시되는 Windows 10 덕분에 사실상 이제서야 본격적으로 유니버셜 윈도우 플랫폼이 완성되었다고 볼 수 있습니다. 그렇기에, 이제는 모든 Windows 10 디바이스에서 실행될 수 있는 유니버셜 윈도우 플랫폼 기반의 응용프로그램 및 앱을 Visual Studio로 개발할 수 있게 되었습니다. 즉, 이는 Visual Studio 2015를 사용하여 하나의 앱을 제대로 설계해서 만들면 윈도우 폰, 타블렛, ,PC, Xbox 뿐만 아니라 요즘 대세인 IoT와 홀로렌즈(HoloLens)에서도 모두 동작하는 앱을 만들 수 있다는 의미입니다.

    게다가, 완전히 새로운 UI 디버깅 도구, 향상된 XAML 디자이너, 강화된 프로파일링 및 디버깅 기능까지 더해져서 고품질을 갖는 윈도우 용 앱(App)을 개발하는 것이 이보다 더 쉬울 수 없을 정도로 간편해졌습니다.

    더욱이, 모바일 개발자의 입장에서 보면, Visual Studio 2015는 Android, iOS, Windows 등 최신의 대중적인 모바일 플랫폼 모두에서 실행되는 크로스 플랫폼 앱을 개발할 수 있는 도구들도 포함하고 있습니다. 네이티브 앱이냐 웹 앱이냐에 따라서 Visual Studio 2015에서는 Apache Cordova, Xamarin, 또는 C++을 사용하여 다양한 플랫폼을 지원하는 앱을 개발할 수 있습니다.

    image

    <그림 6. 크로스 플랫폼 모바일 개발이 가능한 Visual Studio 2015>

    앞서 언급한 것처럼 Visual Studio 2015가 제공하는 기술 분야별 멋진 기능들을 모두 나열하기에는 이 컬럼만으로는 부족하기에 또한 그것이 이번 컬럼의 주된 목적도 아니기에 여기서는 IDE 본연의 모습 그 자체에서 새롭게 지원되는 다양한 기능들, 독특한 특징들 위주로 정리를 해볼까 합니다.

    코드편집기 UI 및 코딩 경험 향상

    코딩 친구, 코딩의 길잡이. 노랑 전구

    .NET 컴파일러 플랫폼인 로즐린(Roslyn) 기술의 적용으로 인해 C#과 Visual Basic(.NET) 용 코드 편집기의 UI와 편집 경험성이 크게 향샹됩니다. 노랑 전구로 대표되는 다양한 편리 기능이 탑재되었는데요. 여러분이 코딩하는 경우 다양한 위치에서 노랑 전구가 나타나서 여러분에게 올바른 코딩 방향을 지속적으로 알려주게 됩니다.

    Visual Studio 2015부터는 노랑 전구가 일종의 코딩 길잡이라고 보시면 됩니다. 뭔가 여러분이 놓친 부분이 있거나 오류를 범한 부분을 발견하면 가차없이 노랑 전구가 나타나서 길잡이 역할을 해준다는 것이죠. 그 예 중 하나로는 다음 그림처럼 클래스의 구현 인터페이스를 지정하기만 해도 해당 인터페이스 구현에 대한 안내 및 실제 구현 코드까지 노랑 전구가 제시하는 부분을 들 수 있습니다. 그것도 적절한 패턴까지 적용된 다양한 안을 친절하게 제시해 주기까지 합니다. 그리고, 이러한 제안을 현재 문서에만 적용할지, 프로젝트로 넓혀서 적용할지, 심지어 전체 솔루션에 대해 모두 적용할지도 선택할 수 있습니다

    image

    <그림 7. 노랑 전구가 제공하는 코딩 제안>

    더불어, 여러분이 Visual Studio의 코드 검사분석(Code Analysis) 기능을 켜 두었다면 노랑 전구는 오류표시 아이콘을 통해서 지켜지지 않은 코딩 규칙들을 경고해 주기까지 합니다. 그림 7의 오류 표시 아이콘은 인터페이스 구현 제안을 따르지 않을 경우 어떤 코딩 규칙을 어기게 되는 지를 보여주고 있는데요. 이는 클래스가 Dispose() 메서드를 구현하지 않을 경우 CS0535 규칙을 어기게 된다는 것을 보여주고 있습니다(규칙을 어기면 로컬 빌드는 실패합니다). 기본적인 검사분석 집합은 Visual Studio가 제공하고 있지만 특정 기술에 대한 검사규칙이 필요한 경우에는 Nuget이나 써드파티를 통해서 적절한 검사분석 규칙들을 구해야 할 수도 있습니다. 예를 들면, Azure를 위한 코드 검사분석 규칙을 얻을 수 있는 Nuget 경로는 다음과 같습니다. https://www.nuget.org/packages/Microsoft.VisualStudio.Azure.CodeAnalysis/0.2.0-beta

    image

    <그림 8. 코드 검사분석이 적용되었을 경우의 노랑 전구 지원>

    또한, 리펙토링 관련 기능들도 모두 노랑 전구 영역으로 옮겨졌기에, Visual Studio 2015부터는 코드에서 리팩토링이 필요한 부분이 발견될 때마다 노랑 전구가 안내를 해주게 됩니다. 그림 9의 예에서는 함수 안에 직접 기입된 상수 값을 외부로 추출하는 다양한 제안을 볼 수 있으며, 각 제안의 경우 코드가 어떻게 변경될 것인지도 미리 살펴볼 수 있습니다. Visual Basic(.NET)에 대한 리팩토링도 VS 2015부터는 지원이 되며 마찬가지로 노랑 전구가 안내를 해 줍니다. 노랑 전구를 마우스로 클릭하는 것이 생각보다 간단하지 않다면 Ctrl + <마침표>를 키보드로 누르시면 됩니다.

    image

    <그림 9. 노랑 전구가 상수 값에 대한 리팩토링을 제안해 줍니다>

    더불어, 이름 바꾸기 기능도 크게 향상이 되었는데요. 그림 10에서 보이는 것과 같이 이름을 변경할 인스턴스를 선택하면 모든 관련 인스턴스들이 하이라이트되고, 여러분이 새 이름을 입력하면 한번에 모두가 변경되는 것을 볼 수 있을 것입니다

    image

    <그림 10. 이름 바꾸기 기능의 개선>

    사용자 지정 윈도우 레이아웃

    어찌 보면 이 기능은 Visual Studio 2013의 연결된 IDE 기능[주석]이 처음 제공된 이후, 많은 개발자들이 가장 원했던 기능이기도 한데요. 이제부터는 폰트나 배경색 등 편집기에 지정해 놓은 편의 설정들 외에도 윈도우 레이아웃도 여러분 마음대로 구성한 뒤 저장 및 로드할 수 있게 되었습니다. [창(Window)] 메뉴에 추가된 [창 레이아웃 저장하기], [창 레이아웃 적용하기] 등의 명령을 통해서 말이죠. 그렇기에, 여러분은 다양한 개발환경에 따라 필요한 만큼의 윈도우 레이아웃을 구성해서 각기 다른 이름으로 저장해놓고 상황에 따라 서로 다른 레이아웃을 불러서 적용할 수 있습니다. 요즘처럼 다양한 디바이스로 개발하고 멀티 모니터에 다양한 해상도로 개발하는 환경에서는 더없이 훌륭한 기능이라 할 수 있을 것입니다. 각각의 저장된 레이아웃은 키보드 단축키인 Ctrl+Alt+1부터 Ctrl+Alt+9를 사용하여 바로 적용할 수도 있습니다.

    image

    <그림 11. 윈도우 레이아웃을 마음대로 꾸밀 수 있다>

    고해상도 아이콘 및 High-DPI 디스플레이 지원

    Visual Studio 2015는 고해상도 및 high-DPI 디스플레이에서도 선명하게 보이도록 지원을 하고 있습니다. 그림 13을 보면 심지어 DPI 스케일이 400%인 경우에도 아주 선명하게 아이콘들이 보이는 것을 확인하실 수 있습니다(뭔가 차이가 없어 보인다면… 그건.. 인쇄 상태가 안 좋거나 이미지가 너무 작아서일 가능성이 큽니다) .

    image

    <그림 12. 400% 배율에서도 선명한 Visual Studio 2015 아이콘들>

    디버거 관련 기능개선

    디버깅 시 LINQ 및 람다식 지원

    많은 분들이 가장 기다렸을 소식일 듯 합니다. 드디어 디버거에서 LINQ와 람다식(lambda expressions)이 지원됩니다.

    많은 분들이 VS 2013에서 디버깅 시에 혹시나 하는 마음으로 람다식을 사용해 본 적이 있었을텐데요. 그때마다 "식에 lambda expressions을(를) 포함할 수 없습니다."와 같은 메시지를 받게 되어 암울해 했었죠. 그 동안 수 많은 개발자들이 이 부분에 대한 개선을 요청해서인지 Visual Studio 개발팀은 이를 최우선적으로 해결했고요. 그렇기에 이제는 디버깅 시에 [조사식] 창이나 [직접실행] 창에서 람다식과 LINQ를 사용할 수 있습니다. 

    image

    <그림 13. 조사식 창에서 람다식을 쓸 수 있다니>

    성능 툴팁(PerfTip) 및 중단점 옵션 윈도우

    사실, 디버거와 관련해서는 그 밖에도 많은 부분이 향상되었는데요. 자세한 내용은 별도의 컬럼이나 세미나를 통해서 다루는 것이 좋을 듯 하지만 그래도 중요한 몇 가지 기능은 언급을 하고 넘어가야 할 듯 합니다. 우선 PerfTips라는 명칭의 성능 툴팁 기능은 빼놓을 수 없는데요. 이는 Visual Studio 2015에 새롭게 추가된 일종의 성능 정보 관련 툴팁 기능이라고 할 수 있습니다. 그림 14에서 보이는 것과 같이, 이는 중단점이 걸려있는 라인의 제일 뒤 쪽에서 코드 실행에 걸린 시간을 보여주는 기능입니다. 디버깅 시 이전 단계의 코드 혹은 이전 중단점에서 현재의 코드 혹은 중단점까지 실행된 실행시간 정보를 성능 툴팁으로서 보여주기에 필요한 경우 이를 참고하여 적절히 활용할 수 있을 것입니다.

    image

    <그림 14. 디버깅 시 유용한 성능 툴팁>

    또한, 중단점에서의 다양한 중단 조건(Condition) 및 작업(Action) 설정이 이제는 그림 15와 같이 피크(Peek) 윈도우를 통해서 설정이 가능하기에 조건부 디버깅이 상당히 편리해졌다는 부분도 기억해 두시기 바랍니다.

    image

    <그림 15. 중단점에 중단 조건과 액션을 설정하는 기능이 이제 피크(Peek) 윈도우로 지원된다>

    http://blogs.msdn.com/b/visualstudioalm/archive/2014/10/06/new-breakpoint-configuration-experience.aspx

    개발 팀 협업 관련

    GitHub에 대한 지원

    실제로 요즘에는 수 많은 개발자들이 직, 간접적으로 오픈 소스 프로젝트를 수행하거나 공헌하고 있는 현실이고 가장 대중적인 오픈 소스 소셜 사이트가 GitHub임을 부인할 사람은 없을 것입니다. 물론, Microsoft는 그와 유사한 서비스를 제공하는(사실, ALM 측면에서는 그 이상의 서비스를 제공하는) Visual Studio Online(이후 VSO) 서비스를 통해서 이러한 트렌드에 어느 정도는 대응을 하고 있었습니다.

    그런데 놀랍게도 Visual Studio 2015부터는 가장 대중적인 Git 호스트이자 경쟁자인 GitHub에 대한 지원을 공식적으로 제공합니다. 단순하게 연계 기능 정도를 추가한 것이 아니라 그림 16에서 볼 수 있는 것처럼 아예 팀 탐색기 안에 GitHub와의 연결 기능을 통합시켜 버렸는데요. 이는 상당히 놀랄만한 사건입니다. 왜냐하면 Microsoft는 클라우드 ALM 서비스인 Visual Studio Online(이후 VSO)를 내놓으면서 사실상 GitHub와는 경쟁 관계에 놓여있었기 때문입니다. 즉, VSO 서비스로 GitHub와 경쟁하고 있는 와중에 공식적으로 최고의 경쟁자인 GitHub에 대한 연계 기능을 Visual Studio 안에서 공식적으로 제공한다는 것은 어찌보면 VSO의 경쟁력이 오히려 낮아질 수 있는 불리함을 감수하더라도 개발자에게 편의성을 제공하겠다는 의지이기 때문입니다. 즉, 돈에 연연하지 않고 실제로 개발자의 입장에서 가장 필요로 하는 기능이라면 그것이 무엇이든 끌어안겠다는 오픈 마인드의 예라고 볼 수 있다는 것이죠. Microsoft의 오픈 변화가 이런 세밀한 곳에까지 작용하고 있다는 사실에 새삼 놀라지 않을 수가 없습니다.

    image

    <그림 16. Git을 넘어서서 GitHub에 대한 통합까지 제공된다>

    심지어, GitHub 통합 기능은 개발자의 사용 편의성을 높이기 위해서 Microsoft와 GitHub의 개발팀이 공동으로 개발했다고 합니다. 그렇기에 그림 17과 같이 로컬 분기 및 원격 분기(로컬에서 만들지 않은 분기 포함)를 계층구조로 쉽게 살펴보고 조정할 수 있는 전용화면 뿐만 아니라 이전 분기 이력들과 병합 상황을 직관적으로 살펴볼 수 있는 그래프까지 다양한 기능들을 제공합니다.

    image

    <그림 17. 로컬 분기 및 원격 분기 화면 및 분기 및 병합 이력 그래프>

    팀 협업 및 품질 관리

    인텔리테스트(IntelliTest, Preview 시 Smart Unit Test)

    인텔리테스트는 Visual Studio 2015 Preview 버전에서는 스마트 단위 테스트라고 불리었던 단위 테스트 자동화 기술의 정식 명칭입니다.

    이는 개발자가 작성한 API 코드(.NET 코드. 관리되는 언어만 해당됨)를 분석하여 자동으로 테스트 데이터와 단위 테스트 집합을 생성하고 실제로 실행 가능한 테스트 입력들을 만들어 냅니다. 심지어는 모든 조건부 분기에 대해서까지 사례 분석을 수행하여 다양한 테스트 입력들을 만들어 내는데요. 그림 18에서는 인자로 int[] 배열을 갖는 ClassifySideLengths라는 API 메서드를 분석하여 다양한 테스트 데이터를 사용하는 테스트 사례들을 생성해내고 실제로 테스트를 수행한 것을 볼 수 있습니다. 개발자는 이러한 인텔리테스트를 통해서 실패한 테스트들을 파악하여 관련 문제 원인들을 사전에 알아내고 코드를 더욱 견고하게 보완할 수 있을 것입니다.

    이렇게 자동으로 수행된 테스트들 중에서 실제로 테스트 메서드로 저장하고 싶은 사례들을 선택하여 저장하면 이들은 매개변수화된 단위 테스트 메서드의 형태로 테스트 프로젝트에 저장되어 추후에도 반복적으로 회귀 테스트 용도로 재활용할 수가 있습니다.

    image

    Visual Studio 용 기타 도구 지원

    Apache Cordova 지원 (4.0.0 지원 포함)

    Visual Studio에서 제공하는 Apache Cordova 도구를 사용하면 단일 프로젝트로부터 Android, iOS, Windows, Windows Phone 등 거의 모든 플랫폼을 대상으로 하는 크로스 플랫폼 애플리케이션을 개발, 디버그, 테스트할 수 있습니다. Cordova를 통해 지원되는 웹 앱은 네이티브 앱에 비하면 세밀함이 살짝 부족하긴 하지만 개발 편의성이나 배포 용이성 측면에서 엄청난 이익이 있기에 많이 사용되고 있습니다. Visual Studio 2015에서 지원되는 Apache Cordova는 Android 4.4와 4.3, 그리고 jsHybugger를 이용하는 그 이전 버전들을 비롯하여, iOS 6, 7, 8 및 Windows Store 8.1까지 지원합니다. 더불어, Apache Cordova 4.0.0도 이제 사용이 가능합니다. 자세한 내용은 https://www.visualstudio.com/en-US/explore/cordova-vs를 참고해 보시기 바랍니다.

    image

    Python 및 Node.js 도구 지원

    Visual Studio는 최근 웹 응용프로그램 및 서버 개발에 사용되는 대중적인 언어인 Python과 Node.js에 대한 지원도 계속해서 제공합니다. 이 추가적인 도구는 Visual Studio 2013부터 제공되기 시작했습니다만, 2015에서도 여전히 제공됩니다.

    image

  • Korea Evangelist

    차세대 브라우저 Microsoft Edge 소개

    • 0 Comments

    image

    <Microsoft Edge>

    이번 빌드 기간 중에 그간 Project Spartan이라고 불리던 마이크로소프트의 차세대 브라우저가 'Microsoft Edge'라는 정식 명칭을 획득하고 화려하게 공개 되었습니다.

    마이크로소프트는 지난 수년간 다양한 채널을 통해서 고객들의 feedback을 적극적으로 경청하기 위한 다양한 시도들을 이어 왔습니다. 브라우저의 개선을 위해서 내부적으로 개발되고 있는 내용들을 적극적으로 외부에 알리기 위해서 status.modern.ie를 운영하고 있고, 고객들과 직접적으로 소통할 수 있는 uservoice.modern.ie를 운영하고 있으며, twitter, reddit 등을 통해서도 다양한 사용자의 의견을 수렴하고 있습니다.

    image

    <status.modern.ie 웹사이트>

    그 외에도 Internet Explorer자체에 smiley face 버튼을 배치하여, 현재 접속한 사이트의 화면 모습과 함께 바로 feedback을 제공할 수 있는 방법을 제공하고 있기도 합니다. 이와는 별도로 새로운 브라우저의 기능을 사용자의 컴퓨터에 설치해보지 않고도 즉각적으로 테스트 해 볼 수 있는 remote.modern.ie와 같은 기능을 제공하기도 합니다.

    image

    <State of the web>

    Internet Explorer이 첫 버전이 출시된 지 20년이 흘렀습니다. 그간 웹 기술은 그 시간만큼이나 많이 변했습니다. 대체로 Internet Explorer의 최초 버전이 출시된 1995년으로부터 Internet Explorer 6가 출시된 2001년까지는 HTML4, ECMAScript3, CSS2와 같은 표준화 기술들이 웹 기술의 근간이었습니다. 풍부한 기능과 편리한 사용성에 대한 끊임없는 사용자의 요청에 따라 마이크로소프트는 다양한 기술들을 Internet Explorer에 탑재하였으며, XMLHttpRequest나 VML(Vector Markup Language), ActiveX 기술 등이 당시의 요구사항을 반영하기 위한 노력의 결과로 Internet Explorer에 포함 되었습니다. 2000년 후반부터 시작된 새로운 웹 표준화의 바람을 수용하기 위해서 Internet Explorer는 기존 고객이 개발한 웹 사이트를 정상적으로 운용할 수 있도록 호환성을 유지하면서, 동시에 새롭게 등장한 HTML5, SVG, ECMAScript 5/6, CSS3 등과 같은 웹 표준 기술들을 수용하기 위해서 Internet Explorer의 신규 버전을 개선하여 출시하였습니다. 하지만 이러한 변화의 노력에도 불구하고, 비 표준 기술의 지원에 대한 비판과 신기술의 수용 속도가 더디다는 고객의 feedback이 있어왔습니다.

    또한 그 사이에 강력한 기능과 편의사양으로 무장한 Firefox, Safari, Chrome 등의 다양한 브라우저가 새롭게 출시되면서, PC와 모바일 디바이스에 이르기까지 광범위 하게 사용되기 시작되었으며, 2014년 HTML5 권고안이 완성에 이르면서 Internet Explorer에 대한 변화의 목소리는 그 정점에 이르렀습니다. 이에 웹 기술을 전폭적으로 수용하고 비 표준 기술들이 제거된 브라우저, 동시에 다른 브라우저와도 상호 운용되는 새로운 브라우저의 필요성이 대두 되었습니다.

    또 다른 이유로 Marketplace/Store와 같은 새로운 소프트웨어의 유통 방식과 앱 비즈니스의 성장으로, 앱을 개발하기 위한 좀 더 쉽고 강력한 기술로 웹 기반 기술들을 주목하기 시작하였습니다. 이에 웹 기술과 앱 기술을 접목한 다양한 시도들이 이루어졌으며, 마이크로소프트 또한 웹 기술을 확장하여 앱 개발에 활용할 수 있는 방법들을 개발하기에 이르렀습니다.

    이러한 시대적인 배경과 사용자의 요구로 마이크로소프트는 'Microsoft Edge'로 소개된 새로운 브라우저의 개발을 시작하게 됩니다.

    'Microsoft Edge' 개발팀은 크게 3가지의 주요 방향성을 가지고 브라우저 개발에 착수 하였습니다. 첫 번째 목표는 사용자에게 놀라움을 줄만한 멋진 브라우저를 개발하겠다는 것이었습니다. 새롭고 쾌적한 UX, 우수한 보안성, 다양한 입력 방식을 지원하고, 더불어 그간의 사용자의 feedback을 반영한 브라우저를 만들겠다는 것이었습니다. 둘째로 충분한 확장성을 고려하면서도 신뢰성 있는 웹 플랫폼을 제공하는 브라우저로 만들겠다는 것이었습니다. 셋째로 제품을 주기적으로 자동 업데이트 하여, 항상 최상의 사용자 경험을 유지할 수 있도록 하겠다는 것이었습니다.

    ‘Microsoft Edge'는 이러한 기본 방향성을 가지고 현재까지 45개의 새로운 웹 표준 기술을 새롭게 추가 구현 하였으며, 다른 브라우저와의 상호 운용성을 개선하기 위해서 4,200개 이상의 개선을 이루었습니다. 이 모두는 사용자의 관점에서 ‘그저 동작하는’(Just Works) 웹 브라우저에 대한 요구를 최대한 수용하기 위한 것이기도 합니다.

    image

    <New features in preview>

    image

    <Microsoft EdgeHTML 렌더링 엔진>

    'Microsoft Edge' 개발팀은 상호운용성의 개선을 위하여 Internet Explorer에서 사용하던 MSHTML(Tridgent)의 소스 코드를 새롭게 folk 하여, 220,000 라인의 코드를 삭제하고 300,000 라인의 코드를 신규로 추가하는 대규모의 수정과 개선 작업을 거쳐 EdgeHTML 이라는 새로운 렌더링 엔진을 만들어 냈습니다.

    ‘Microsoft Edge’는 구조적으로도 그간 Internet Explorer가 하위 호환성을 위해서 지나치게 복잡하게 유지 되었던 ‘Document modes’를 모두 제거하고, ActiveX, VBScript, 기타 비 표준 객체나 메서드 등에 대한 지원을 중단 하였습니다. 그 외에도 Internet Explorer 만의 고유한 기능들이 상당히 많이 삭제되거나 대체 되었습니다. 아래에 그 목록을 나타냈습니다.

    • Binary behaviors
    • Pluggable protocols
    • Shell Helper API
    • Active Documents
    • Custom Download Managers
    • Custom Security Managers
    • MIME filters
    • Custom Print and Print Preview Handlers
    • Explorer Bars
    • Edit Designers
    • Timers
    • Accelerators
    • Webslices

    또한 다른 브라우저와 차이를 보이는 수 백개의 API들을 제거하였는데, 제거된 대부분의 API들은 다른 브라우저와 함께 쓸 수 있는 API로 변경되거나 표준 API의 형태로 대체 되었습니다. 'Microsoft Edge'로부터 제거된 내용 중 특별히 주목할 만한 부분은 ms 접두어가 붙은 API 군들입니다. CSS Transform, Full screen API, Pointer Event 등이 그 예가 될 수 있는데, 이러한 벤더 프리픽스의 수를 webkit 수준으로 대폭 축소 하였습니다.

    image

    아래에 'Microsoft Edge'로부터 제거된 주요 기술들의 탄생 배경과 용도, 그리고 해당 기술들을 제거한 이유를 정리해 보았습니다.

    기술

    탄생 배경과 용도

    제거 이유

    ActiveX

    ActiveX는 1996년에 소개된 이진 확장 모델로 개발자가 네이티브 윈도우 기술(COM/OLE)을 웹페이지에 포함시킬 수 있도록 하기 위해서 만들어 졌습니다. ActiveX 콘트롤은 웹 사이트로부터 다운로드 되어서 브라우저 프로세스 내부에 로드되고 Internet Explorer 창 내에서 렌더링 되었습니다.

    HTML5가 제공해 주는 강력한 기능 덕분에 ActiveX가 반드시 필요한 경우는 상당히 많이 줄어들었습니다. 'Microsoft Edge'는 PDF 렌더링과 Flash를 외부 플러그인에 의존하지 않고 자체적으로 빌트인 하여 제공하고 있습니다.

    Browser Helper Objects (BHO)

    BHO는 1997년에 소개된 이진 확장 모델로 개발자가 브라우저 내부에 로드 될 수 있는 COM 객체를 만드는 방법이며, 주로 툴바 등을 개발하는 용도로 사용되었습니다.

    개발팀은 HTML/JavaScript를 기반으로 하는 브라우저 확장 모델에 대한 초기 작업을 진행하고 있습니다. 이러한 확장 모델은 이번 여름에 출시될 'Microsoft Edge'에는 포함되지 않을 것입니다.

    Document modes

    IE8부터 Internet Explorer는 새로운 버전이 출시될 때 마다 새로운 “Document mode”를 포함시켰습니다. 이 같은 Document Mode는 x-ua-compatible 헤더를 이용하여 지정할 수 있으며, 특정 버전의 Internet Explorer를 emulation하기 위한 용도로 사용되었습니다.

    현대적 브라우저라고 일컫는 다른 브라우저들과 마찬가지로 'Microsoft Edge'는 단일의 Document mode 만을 최신의 상태로 유지할 것입니다. 호환성의 부담을 최소화 하기 위해서 새로운 기능들은 안정화 되어 기본으로 사용되기 전까지 about:flags를 입력한 이후에만 사용할 수 있도록 구성 될 것입니다.

    Vector Markup Language (VML)

    VML은 1998년에 출시된 IE5에 최초로 추가된 XML 기반의 2차원 벡터 그래픽 기능이었습니다.

    2D 벡터 그래픽은 다른 모던 브라우저와 마찬가지로 Scalable Vector Graphic(SVC)에 의해서 지원 됩니다.

    VBScript

    VBScript는 Visual Basic 출시 이후에 모델링 된 스크립트 언어로 1996년부터 웹 스크립트 언어의 하나로 제공되었습니다.

    JavaScript가 실질적인 산업 표준 웹 스크립팅 언어로 자리매김 함으로써, 마이크로소프트는 ECMAScript 6와 그 이후 버전을 가장 신속하게 지원하고 있습니다. (브라우저별 ECMAScript 6 지원 현황)

    attachEvent/

    removeEvent

    IE8 이하 버전에서는 이벤트 버블링을 지원하는 자체적인 DOM 이벤트 모델을 이용하였으며, 이벤트를 캡쳐하여 이벤트 수신자에게 매개변수로 전달하기 보다는 전역 이벤트 객체를 사용하였습니다.

    IE8 이후부터는 DOM Level 3 이벤트 표준을 사용하므로 addEventListener/removeEventListener를 사용하도록 변경되��습니다.

    currentStyle

    currentStyle 특성을 이용하면 특정 요소의 cascade 스타일을 획득 할 수 있었습니다.

    IE9 이후부터는 DOM L2 표준의 일부로 제공되는 getComputedStyle을 통해 특정 요소에 적용된 최종 스타일을 가져올 수 있습니다.

    Conditional Comments

    Conditional comments를 사용하여 특정 버전의 Internet Explorer에서만 수행되는 코드를 지정할 수 있었습니다.

    Conditional comments 등을 이용하여 브라우저 별 코드를 지정하기 보다는 feature detection을 이용하거나 개선된 기능을 사용하는 편이 더욱 효과적입니다.

    IE8 layout quirks

    Internet Explorer 8 이상의 브라우저에서 IE8의 레이아웃 동작을 emulation하기 위한 기능입니다.

    대부분의 웹사이트들은 표준 레이아웃을 이용하도록 작성되어 있습니다. IE8 고유의 레이아웃 동작을 반드시 필요로 하는 인트라넷 사이트 등은 엔터프라이즈 모드를 사용할 수 있습니다.

    DirectX Filters and Transitions

    DX 필터와 전환 효과들을 이용하여 개발자들은 웹 페이지 내부의 개별 요소들에 다양한 비주얼 효과를 지정할 수 있었습니다.

    CSS3와 SVG와 같은 표준화된 기능을 이용해서 유사한 효과를 지정할 수 있습니다.

    <Microsoft Edge로부터 제거된 기술과 제거 이유>

    image

    <Microsoft Edge & Internet Explorer>

    구조적으로 'Microsoft Edge'는 Windows 10의 Universal Windows Platform을 기반으로 개발되었으며, 이로 인해 64 bits AppContainer 내에서 안전하게 브라우징을 할 수 있게 되었고, PC뿐 아니라 Windows Phone, Surface Hub, Xbox에도 사용 가능한 브라우저로 개발 되었습니다.

    Windows 10에는 ‘Microsoft Edge’와 함께 Internet Explorer도 함께 포함되어 있어서, 반드시 Internet Explorer를 필요로 하는 웹 페이지의 경우, ‘Microsoft Edge’에서 Internet Explorer로 손쉽게 전환할 수 있는 기능도 가지고 있습니다.

    이러한 경량화, 최적화의 노력으로 성능도 대폭 향상되었습니다. 애플의 JetStream 벤치마크나 Google의 Octane 벤치마크 결과를 보면 'Microsoft Edge'가 Internet Explorer 11 보다 2배 이상 나은 성능을 보여주었을 뿐 아니라, Chrome(43.0.2369.0), Firefox(Alpha 40.0a1) 보다 더욱 더 빠르게 동작하는 것을 확인할 수 있습니다.

    image

    <Octane 2.0 벤치마크 테스트>

    'Microsoft Edge'는 새로운 표준의 수용과 상호 운용성의 개선 이외에도 사용자의 편의를 위한 다양한 부가 기능들도 도입하였습니다. 컨텐츠 중심의 미려하고 쾌적한 UX 이외에도 Cortana와 연동하여 검색의 편리함을 도모하였고, 읽기 전용 모드를 도입하여 사용자가 웹 문서를 읽을 때 좀 더 내용에 집중 할 수 있도록 하였으며, 오프라인으로도 내용을 살펴볼 수 있는 기능을 구현하였습니다. 더불어 note-taking 기능을 이용하여 웹 페이지 위에 바로 필기를 하고 이를 공유할 수 있는 기능도 제공하고 있습니다.

    image

    <note taking 기능>

    'Microsoft Edge'는 올 여름 Windows 10와 함께 출시될 것이며, 아직까지 구현되지 않은 Extension 기능과, 다양한 Cortana 시나리오, Object RTC, Pointer Lock 등의 기능들이 신규로 구현될 예정입니다.

    빌드가 끝난 직후 Edge 개발팀은 Modern.IE 사이트를 대체하는 http://dev.modern.ie/ 사이트를 새롭게 오픈 하였습니다.

    image

    <dev.modern.ie>

    이 사이트를 통해 'Microsoft Edge'와 개발팀에 대한 이야기도 전해 들을 수 있으며 Cross Platform 사이트 테스트 도구를 사용하실 수도 있습니다. 'Microsoft Edge' 개발팀은 전세계의 수많은 사용자들로부터 @MSEdgeDev를 통해서 사용자들의 다양한 feedback을 기다리고 있습니다.

Page 1 of 129 (642 items) 12345»