//Build 2016 Office Dev Update
지난 //Build 2016 행사에서는 "개발 플랫폼으로서의 Office"에 대한 내용들과 많은 개선사항들이 발표 되었습니다. 이번 포스팅을 통하여, 그 내용들과 의미를 살펴 보고자 합니다.
Office Dev의 세 가지 Pillar
지난 //Build 2016 행사 이전까지는 Office Dev를 아래의 두 가지 측면으로 볼 수 있었습니다. 좌측은 Office의 기능을 확장할 수 있는 Add-in 개발을 의미합니다. 우측은 Office 365의 다양한 데이터를 REST API로 노출하여, 개발자들이 다양한 형태의 응용프로그램에서 활용할 수 있도록 하는 방법을 의미합니다.
그에 더하여 이번 //Build 행사를 통해서는 "Conversation as a Platform"이라는 메시지를 강조하며, 개발자들의 응용프로그램이나 서비스가 Office 365의 그룹대화나 Skype for Business(구. Lync)를 활용할 수 있도록 하는 새로운 모형을 제시하였습니다.
이로써 Office Dev는 세 가지 Pillar를 갖춘 형태가 되었습니다. 그럼 각각의 개발 방식에 대해 좀 더 자세히 살펴 보고, 이번 행사에서 어떠한 업데이트가 있었는지 알아보도록 하겠습니다.
1. Office Add-in
첫 번째 개발 방식은 Office Add-in 개발입니다(Add-in보다는 Plug-In이라는 용어가 더 와 닿으실지도 모르겠습니다). 개발자들이 Excel이나 PowerPoint같은, Office 클라이언트를 확장할 수 있도록 하는 방법으로, 그 구조는 아래와 같습니다.
특이점으로는 웹 기술을 사용하여 개발을 한다는 것입니다. Office 클라이언트 내에 웹 응용프로그램이 수행되는 구조이며, 이 때 웹 응용프로그램은 플랫폼 종속성을 갖지 않기에, 다양한 웹 개발 Framework(e.g. Node.js, Ruby, ASP.NET 등)을 활용하여 개발하실 수 있습니다.
이렇게 개발된 Add-in을 통해, 웹 서버로부터의 데이터를 보여주고, Office 문서 내에 삽입할 수 있을 뿐만 아니라, 반대로 Office 문서 내의 데이터를 웹 서버로 전송할 수도 있게 됩니다. 내부적으로는 이 과정에서, Add-in 프로젝트가 참조하고 있는 Office.js 파일이 Interop의 역할을 하게 됩니다. 좀 더 실질적인 사용 시나리오를 둘째날 키노트에서 스타벅스의 Outlook Add-in을 통해 살펴볼 수 있었습니다.
Office Add-in은 기본적으로 웹 응용프로그램이기 때문에, 기존의 웹 프로젝트를 활용할 수 있다면 좀 더 쉽게 Office Add-in을 개발할 수 있을 것입니다. 작년 //Build 행사에서, 웹 컨텐츠를 다양한 플랫폼의 앱으로 변경시켜주는 Bridge 기술인 manifoldjs 프로젝트가 공개된 바 있었는데요, 이를 이용하여 Office Add-in을 좀 더 쉽게 개발할 수 있게 되었습니다.
Add-in은 Office Store를 통해서 배포가 가능하며, 유료 버전이나 월간 구독 모델로 스토어에서 판매하실 수 있습니다. 스토어를 활용하지 않고 회사 내에서만 Add-in을 개발하여 사용하고 싶으신 경우에는, SharePoint나 파일 서버를 통해 배포할 수 있습니다. 나아가 좀 더 손쉬운 배포를 위해서 Office 365의 Admin Portal(Preview)에 Add-in을 업로드하고 배포할 수 있게 되었습니다.
현재 Office Add-in은 아래와 같은 다양한 플랫폼을 지원하며, 지원 범위를 계속 확장해 나가고 있습니다. 이번 행사에서는 OneNote의 Add-in의 Preview가 공개된 바 있습니다.
2. Microsoft Graph API
두 번째 개발 방식은 Office 365의 Graph API를 활용한 개발방법입니다. Office Server군으로 분류되는 Exchange Server(메일 서버), SharePoint Server나 OneDrive / OneNote 등의 서비스들은 개발자들이 활용할 수 있는 다양한 API를 제공해 왔습니다. 하지만 각각의 API의 끝점(EndPoint)이 다르고, 사용하는 ID 체계와 토큰도 달랐으며, API의 형태도 달랐기 때문에 개발자의 입장에서 사용하기가 쉽지 않은 부분이 있었습니다. 이에 Microsoft Graph라는 새로운 브랜드, 단일 API EndPoint를 통해서, Office를 사용하는 조직 및 회사가 활용할 수 있는 통합된 정보를 제공하고 있습니다. 실제로 Office 365의 Delve라는 서비스를 통해 Graph API의 활용 사례를 잘 보여주고 있습니다.
대표적인 사례로 Outlook의 일정을 변경하고, 팀 동료와의 대화내용을 불러오는 데모를 역시나 둘째날 키노트에서 보여주었습니다. Graph API는 REST API이기 때문에, 다양한 플랫폼의 응용프로그램에서 손쉽게 호출할 수 있습니다. 특히 개발자의 입장에서 간단한 테스트를 위해, Graph Explorer라는 웹 사이트를 활용하실 수도 있는데요, 이 사이트에는 Graph API를 사용하기 위해 필수적인 인증처리, 토큰관리, GET / POST 메서드가 구현되어 있기 때문에 편리합니다.
현재 Graph API는 /v1.0과 /beta Endpoint로 운영되고 있으며, 새롭게 추가되는 기능들은 /beta에 추가됩니다. 이번 행사에서는, SharePoint내에 저장된 Excel 파일의 내용을 읽어오는 Excel REST API가 발표되기도 하였는데요, 관련하여 Microsoft Graph의 공식 웹사이트를 방문하시면 좀 더 자세한 API 목록과 사용 방법을 확인하실 수 있습니다.
3. Office 365 Connectors / Skype for Business Web & Mobile SDK
세 번째는 Office 사용자간의 대화 "사이로" 개발자 분들의 서비스를 제공하는 방식입니다. 영어로는 아래 슬라이드와 같이 "Engage people through conversations"라고 되어 있습니다. 한글로도 영어로도 무슨 이야기인지 아직은 감이 잘 안 오는 듯 합니다만, 좀 더 실질적인 예를 통해 살펴보겠습니다.
Office 365에는 그룹이라는 개념이 있습니다. Office 365 그룹은 세일즈 팀, 마케팅 팀, 엔지니어링 팀 등이 대화와 일정, 파일과 원노트 등을 공유할 수 있는 공간이며, 일종의 object입니다.
Office 365 그룹은 특정 서비스를 필요로 할 수 있습니다. 가령 세일즈 팀은 지속적으로 업계 현황을 파악하기 위해 뉴스 feed 구독을 원할 수 있으며, 마케팅 팀은 트렌드파악을 위해 Twitter에서 특정 해시태그가 걸린 글들을 모아서 확인하고 싶을 수 있습니다. 이러한 부가적인 기능을 추가할 수 있는 개발 방식이 Office 365 Connector이며, 역시나 둘째날 키노트에서 데모를 통해 확인할 수 있었습니다.
현재는 60개 이상의 파트너들의 Connector가 등록되어 있으며, 개발자 분들의 서비스를 직접 등록한 후 Store를 통해 배포할 수도 있습니다. 좀 더 자세한 등록 및 테스트 방법은 링크를 통해 확인하시기 바랍니다.
마지막으로 소개된 내용은, 많은 개발자 분들이 기다려왔던 Skype Web SDK / Skype for Business App SDK입니다.
Skype Web SDK를 활용하면 웹 응용프로그램 안에서 다른 사용자와 대화를 나눌 수 있는 향상된 경험을 제공할 수 있습니다. Skype Web SDK는 Preview에서 GA(Generally Available)로 변경되었으며, 각종 샘플과 공식 문서가 공개되어 링크를 통해 확인해 보실 수 있습니다.
Skype for Business App SDK를 활용하면, iOS나 Android 응용프로그램에서도 Skype for Business의 기능을 사용할 수 있습니다. 둘째날 키노트에서, iOS앱에서의 활용 시나리오를 보여주었습니다. 
아직은 Skype for Business App SDK를 다운로드 받을 수 없지만, 링크의 페이지를 통해 사용자 등록을 하면, 추후 안내를 받으실 수 있습니다.
이로써 Office Dev의 세 가지 Pillar에 대해 간략히 살펴 보았습니다. 관련 문서와 Sample등은 모두 https://dev.office.com 에서 확인하실 수가 있으니 많은 관심 부탁 드리겠습니다. 감사합니다.