Xamarin 과연 쓸만한가

Xamarin은 한마디로 애증의 기술입니다.

WebView를 이용하는 하이브리드앱 기술이든 중간자를 이용한 Xamarin 같은 멀티플랫폼앱 기술이든 5년 내내 개발자들과 CTO들을 갈등하게 만듭니다.

▲ Xamarin과 Blockchain 연동이라지만 그냥 Azure Blockchain WebAPI 용례입니다. 속았잖아!

Xamarin의 장점은 하이브리드앱 보다 네이티브API 연동이 더 직관적이고, 단점은 안드로이드/iOS 둘 모두 중급의 실력을 필요로 한다는 것입니다. ‘네이티브로 컴파일된다’는 기치를 걸고 있는 ReactNative, NativeScript는 Xamarin보다 복잡도가 더 높다는 생각이 듭니다. 저는 그래요.

왜냐하면 네이티브 프로그래밍에 가까운건 C# 코드와 1:1 변환 수준인 Xamarin과 HTML+JS+CSS를 동원하는 다른 것들과는 중간자의 복잡도에 있어서 시작부터 게임이 안되거든요. 아키텍처 관점에서의 논리랄까요.

JS기반 하이브리드앱 프레임워크(대표적으로 Cordova, Phonegap)들은 네이티브 연동을 위해서는 npm 모듈이 나올 때까지 멍때려야 하는 경우도 있지만 양쪽 플랫폼 모두 중급의 실력까지는 필요 없다는 점이 장점입니다. 뭐 실력이 좋으면 직접 모듈을 작성하면 되겠지만 하이브리드가 아닌 경우에는 ‘그냥’ 되는걸 굳이 왜그래야하나 싶은 생각이 들기 마련이죠. 특히 비슷한 기능의 npm이 여러개인데 뭐가 좋은지 어디까지 믿어야 하는지 고민할 때마다 ‘내가 지금 왜 하이브리드앱을 선택했다는 이유로 이런 것에 시간을 써야하나’싶죠.


저는 클라이언트 개발에 있어서 언제나 네이티브 주의자인데, 요즘은 ‘평범한 소셜 앱서비스’ 정도는 하이브리드로 최대한 버티려는 마음도 있습니다. 특히 다른 분들에게는 하이브리드를 추천합니다. 왜냐하면 저희 팀처럼 보폭을 착착 잘맞추는 팀은 많지 않기 때문입니다.

그래도 여전히 Xamarin을 눈여겨보는 이유는 양쪽 플랫폼의 발전에 꽤 빠른 속도로 따라가고 있는 점을 높이 사기 때문입니다. 예를 들어 지문인식 API 등 OS에 강하게 결합하는 API의 지원은 여느 하이브리드앱보다 빠르게 대응해왔습니다.

Xamarin의 인기가 적은 이유는 두가지라고 생각합니다.
멀티플랫폼 모두에 대한 중급 이상의 실력이 필요: Microsoft는 외계인들이 많겠지만, 평범한 회사는 둘 중 하나만 잘하거나 둘 다 못하는 개발자들이 대부분이죠.
훌륭한 설계가 필요: Microsoft는 IT 역사에서 가장 아키텍처링을 잘 하는 회사입니다. 하지만 대부분의 IT회사는 하루하루 먹고살기 바빠서 아키텍처에 쓸 시간이 부족하고 언제나 레거시에 허덕이고 있습니다.


그런데 요즘 하이브리드, 멀티플랫폼 모두 의미없게 만드는 경향이 작년부터 강하게 밀려옵니다.

다름 아닌, kotlin/swift 언어인데요. 공교롭게도 두 언어의 느낌이 비슷~합니다. 그러다보니 많은 개발자들에게 언어간 적응력이 뛰어납니다. 이제는 Android/iOS 양측의 이해도만 적당히 갖추면 두 언어를 오가며 개발하는 것도 큰 불편이 없어질거라 생각합니다.

여러분이 앱개발자라면, 2019년에는 완전히 kotlin/swift로 전향하는 것을 목표로 하길 권합니다. Xamarin은 XAML Standard가 성숙한 다음에 고려하는 것이 맞겠습니다.

광고

Keras + CNTK Backend

얼마 전에 Keras로 RNN을 구현할 일이 있었습니다.
문제는 아래와 같이 LSTM을 적용하는 부분이었는데요.

model = Sequential()
model.add(LSTM(128, input_shape=(SEQUENCE_LENGTH, len(incoming_list))))
# fully connected layer with softmax activation for classification
model.add(Dense(len(incoming_list)))
model.add(Activation('softmax'))

위 코드에서 while_loop() got an unexpected keyword argument 'maximum_iterations' 에러가 발생하는데, tensorflow backend 코드를 봐도 딱히 문제를 모르겠더군요.

▲ 봐도 모르겠더라. Tensorflow도 구글스럽게 버전별 호환성은 나쁜 듯.

tensorflow backend에서 input_sharp=(...)input_dim, input_length로 나뉘는 것을 **kwargs로 퉁쳐서 입력받는 것이므로, input_dim, input_length으로 나누어 입력했더니 이번엔 IndexOutOfRange 에러가 발생했습니다. 수치적으로만 보면 에러가 날 이유는 없었는데 말이죠.

이와 같은 에러는 구글링 이곳저곳에서 찾을 수 있었는데, 표면적인 원인은 그저 TF/Keras 버전이 안맞는 문제였습니다. 저는 Keras repo의 여러. 이슈.에서 말하는 버전들로 바꿔봐도 문제가 해결되지 않았지만, 해결되었다해도 일부러 Tensorflow/Keras 둘 모두 구버전으로 쓰고 싶지도 않았습니다. 신버전 적용을 두려워하면 영원히 업데이트를 못할 수도 있거든요. (참고로 글쓴 시점 기준 최신은 keras 2.2.4, tensorflow 1.13.1 입니다)

결국 TF backend는 몇 시간동안 버전 이것저것을 맞춰보다 포기하고 CNTK backend를 시도해봤습니다. CNTK backend 적용 방법은 https://docs.microsoft.com/en-us/cognitive-toolkit/Using-CNTK-with-Keras 링크대로 keras.json을 수정하고 환경변수만 하나만 적용하면 잘 됩니다.

결과는 성공적이더군요! 별 일없이 잘 돕니다. 이래야지.

Keras RNN을 적용하다가 저와 같은 에러가 난다면 CNTK backend를 시도해보세요 🙂

▲ 지금 우리가 iteration 한두번 더 해보는게 중요하지 backend가 뭔 상관이겠어요

Azure Service Fabric Mesh는 아직 애매하다

개발자라면 누구나 마음 속에 두고 있는 신기술이 있을겁니다.

“언젠가는 꼭 써보고 싶다”

위와 같은 소망을 담고 말이죠.
저에게는 Service Fabric이 그렇습니다.

Service Fabric은 K8S+Akka+PaaS의 특징이 결합한 형태라고 생각하면 됩니다. K8S, Akka를 그대로 쓸 수 있다는 뜻은 아니고 Container Orchestration, Routing/Scaling/Healing, Infrastructure Virtualization, Actor Model 등을 도입할 수 있다는 겁니다. 좀 더 간단한 표현으로는 “MSA(Micro Service Architecture) 종합선물셋트”입니다. 아래는 Service Fabric이 막 고개를 들기 시작할 때 제가 발표했던 자료입니다.

Service Fabric을 실서비스까지 적용해보지는 못했지만, 시험적으로 사용해봤을 때 많은 매력을 느꼈습니다. 매력 중 하나는 Reliable Collections였습니다. 웹기술의 대부분은 stateless만 고려합니다. 즉, 같은 클라이언트가 요청해도 과거의 접속과 상태를 유지하는 것이 아니라 새로운 요청을 가정한 후, 클라이언트가 부수적으로 주는 쿠키 등 정보 조각을 이용하여 과거와 같도록 만든 것이지 원론적으로는 과거의 요청과 새로운 요청은 무관합니다.

과거의 요청과 새로운 요청을 잇기 위해 여러 단계와 과정이 있는데, 최종적으로는 DB까지 요청해서 확인을 하곤 하죠. 즉, 어플리케이션 로직과 무관하게 DB가 사라지면 어플리케이션이 바보가 되는 형태가 흔한 웹서비스의 3-tier architecture 입니다. (과거 값 + 1) 로직에 대해 ‘과거 값’을 DB에 의존해야 하는거죠. 어느새 우리가 너무 자연스럽게 3-tier 구성을 사용하다보니 ‘DB가 없으면 어플리케이션이 바보되는건 당연한거 아냐?’라고 생각하고 있었습니다. 하지만, 어플리케이션이 충분히 견고할 때는 DB가 필요없을 수도 있다고 생각한 것이 Service Fabric의 철학입니다.

Reliable Collections는 어플리케이션의 replica에서 정보를 계속 유지해서 이 문제를 해결합니다. 그 정보는 메모리일 수도 디스크일 수도 있고요. 그래서 데이터가 어플리케이션 로직 안에 하나의 자료구조 변수처럼 존재합니다. 흔한 ORM들이 ‘DB를 마치 하나의 자료구조 변수인 것처럼’ 인식시키는 개발 경험을 주지만, DB가 사라져도 자료구조 변수와 그 값이 온전히 남아있지는 않습니다.


다시 본론으로 와서, Service Fabric Mesh는 Service Fabric을 보다 가상화해서 Serverless(?: 개인적으로 이 표현을 좋아하지 않습니다) 경험을 줍니다…라고 생각했지만, 의외로 제가 위에서 강조한 Service Fabric의 강점과 큰 상관이 없어보입니다. Mesh 관련 피드백에도 “Reliable Collections 지원이 안되면 의미없음“이라고 유저피드백이 있네요.

▲ 인프라 설정을 json/yaml로 다루는 경험은 대안이 많은데…

대신 Mesh의 의도는 MSA 다수의 어플리케이션을 WebApp 배포처럼 쉽게 올릴 수 있도록 하는 것으로 보입니다. 다만, 위 영상의 인프라 구성 파일(json)을 보면 이것만의 강점이 뾰족하지는 않아보입니다.

즉, Mesh는 아직까진 Service Fabric의 인프라(auto healing/routing 등) 취급 경험만 의미하는 것으로 보입니다. 그래도 Reliable Collections 지원이 언젠가는 이뤄질테니 그 때까지는 기다려봐야 겠습니다.

Five Things 시리즈 소개

IT 개발 기술에 대한 트렌드를 빠르게 짚어주고 영어회화 공부도 되는 YouTube 영상을 소개합니다.

▲ Five Things 시리즈

Five Things의 내용은 ‘최신 하이브리드앱 프레임워크 5개’ ‘최신 IoT 키워드 5개’ 등 Five Things 이름에 맞게 뭐든 5개로 정리해서 나눕니다. 농담따먹기가 20% 넘으니까 영어회화를 익힐 겸 봐도 좋습니다. 이 영상에 나오는 정도는 해야 기술을 주제로 영어로 편하게 대화나누는 수준일테니까요.

MSDN YouTube 공식채널 중 하나지만, 참석자들이 Google, Facebook, Netflix 등 가리지 않고 나오는 점이 좋습니다. 진행자는 Burke Holland (클릭:트위터계정) 외에 AngularJS로 유명한 John Papa 등 Javascript 분야로 활발한 활동을 하던 분들이 돌아가면서 합니다.

그래서인지 Javascript스럽게(?) 정체성 따위 없이 다양한 분야의 지식을 떠들석하고 빠르게 소개합니다. 다루는 내용도 JS 비중이 높은 편입니다.

제 경우 관심있는 기술분야에 대해 Five Things 시리즈에 있는지 찾아보고 연관 검색어에 대한 힌트를 얻곤 합니다. 이 시리즈에 나오는 내용은 ‘어디가서 기술영업만 하는게 아니라 매일매일 코딩하는 사람들’을 대상으로 하기 때문에 거창한 홍보문구 따위가 아닌 실제로 사용하는 프레임워크나 기술 이름을 말하거든요.

YouTube 재생목록을 보면 이 글을 올린 현재까지 42개의 영상이 올라와 있네요. 여러분도 한 번 쭉 훑어보고 관심있는 주제를 재생해보세요.
– 재생목록: https://www.youtube.com/playlist?list=PLlrxD0HtieHgugDxYBujMFnvSveH4fgWN

Azure WebApp in 2018

Azure에 아무리 많은 서비스가 있지만, 그 중에서 가장 빈번히 사용되는 것 중 하나는 WebApp일겁니다. 물론 IaaS 기반의 회사들은 VM에 WAS 설치해서 쓰고 있겠지만, 평범한 웹서비스 회사는 WebApp만으로도 대부분 큰 불편없이 상용 서비스를 하고 있습니다.

Azure WebApp

WebApp은 Azure가 AWS보다 후발주자로서 AWS를 단숨에 뛰어넘을 히든카드 중 하나였습니다. 그 단숨에 뛰어넘는 전략으로 PaaS 최우선 정책을 가졌는데, WebApp은 PaaS의 핵심 제품이었기 때문입니다.

그리고 실제로 그 전략은 잘 먹혔다고 봅니다. Azure WebApp을 경험해본 사람들이 다른 유사서비스들을 써보고는 ‘이건 PaaS가 아닌데’ ‘PaaS라며 왜 이래’ ‘PaaS답게 만들었지만 PaaS라서 불안한건 싫은데’ 등등의 불평을 했거든요.

WebApp의 시작은 간단했습니다. ‘클릭하면 나오는 WAS(Web Application Server)’ 그 이상도 이하도 아니었습니다. 그러다가 웹 서비스를 둘러싼 다양한 요구사항을 받아들여서 이제는 메뉴가 정말 많아졌습니다.

Git연동으로 자동배포하는건 기본이고, Let’s Encrypt 연동도 내부 확장기능으로 지원하고 있지요. 평범한 웹서비스를 만든다면 DB/Storage 외에는 별다른게 필요 없을 정도입니다.

▲ 아직 WebApp을 써본 적 없다면 이 영상으로 감을 잡아보세요

이 글에서는 2018년 동안 WebApp의 변화로 어떤 것이 있는지 살펴보겠습니다.

My SQL in-app data import

WebApp 자체적으로 작은 MySQL DB를 운영할 수 있습니다. 이를 위한 DB import/export 기능입니다. in-app DB 사용시 주의할 점은 어디까지나 in-app에 충실하므로, 웹서비스를 중지시키면 DB도 중지된다는 사실입니다.

https://blogs.msdn.microsoft.com/appserviceteam/2017/03/06/announcing-general-availability-for-mysql-in-app/

HTTP/2 support

HTTP/2는 최신 OS와 브라우저들이 안정적으로 지원하기 시작했으며, IoT에서도 점점 수요가 일어나고 있습니다. HTTP/2의 장점은 여러가지지만, 그 중에서도 연결 유지와 TCP/IP 커넥션 하나로도 여러 요청에 대응할 수 있다는 점을 꼽습니다. WebApp도 이에 맞춰서 작년 초부터 HTTP/2를 지원하기 시작했습니다.

https://blogs.msdn.microsoft.com/appserviceteam/2018/04/13/announcing-http2-support-in-azure-app-service/

Linux, Docker, K8S support

작년에 WebApp의 가장 큰 변화를 꼽으라면 바로 이것이죠. 제 기준으로는 기존 WebApp은 Python에 대해 WebApp Extension으로 지원해서 셋팅부터 구동까지 좀 불편했는데, Python으로 만든 Docker를 WebApp에 그대로 불러와서 올리게 되었기 때문에 정말 좋아졌습니다.

Kubernetes Pod Definitions, Docker Compose yaml 파일을 WebApp에 적용할 수 있다고 하네요. 저는 안써봤는데, Docker는 어떻게 되는건지 감이 잡히는데 K8S을 불러왔을 때는 어떤 형태로 동작하는지 공부를 해야할 것 같습니다.
https://docs.microsoft.com/ko-kr/azure/app-service/containers/app-service-linux-intro
https://blogs.msdn.microsoft.com/appserviceteam/2018/05/07/multi-container/

Undelete, Bring your own Storage

Undelete는 예상하시는대로, 실수로 WebApp을 지웠을 때 복구시키는 기능입니다. 30일 내로 삭제한 WebApp에 대해 url, 콘텐츠, 설정 등 (거의) 모든 것을 복구할 수 있다고 하네요.

https://azure.microsoft.com/ko-kr/updates/announcing-webapps-undelete-preview/?ref=msdn

Bring your own Storage는 Azure Storage를 직접 WebApp에 마운트할 수 있는 기능입니다. 현재 Linux/Container WebApp만 지원되고 Windows는 아직 안된다네요. 이 기능은 꽤 호응이 좋을거 같네요. 전통적인 웹서비스들은 파일업로드에 대해 파일 기록을 하는 경우도 많으니까요.

https://blogs.msdn.microsoft.com/appserviceteam/2018/09/24/announcing-bring-your-own-storage-to-app-service/

저는 클라우드로 기존 서비스에서 옮기는 분들에게 클라우드에 맞춰 소프트웨어를 강하게 개선하는게 맞다고 말합니다. 대표적인 예가
Bring your own Storage 기능처럼, 전통적인 서비스들은 서버 하드디스크에 바로 기록하는 형태가 많은데 이런 경우 모두 Azure Storage로 재설계해야 하는게 낫다고 말해왔습니다.

하지만, 그건 너무 제가 편하게 생각하기 때문이고 Azure는 오래된 엔터프라이즈 환경(≒레거시)에 대응하는 기능 또한 충실히 잘 구축해야 더 많은 유저를 수용하는 거겠죠?

Azure WebApp은 제가 참 좋아하는 서비스입니다. 참고로 아래는 2017년의 제 발표자료입니다.

이상입니다.

요즘 IoT: Azure Device Twin, Digital Twins

여러분이 평범한 웹서비스를 개발하다가 문득 지루함을 느꼈다면 IoT 개발 경험을 해보는 것도 좋습니다. IoT(Internet of Things)는 기존 임베디드 시스템에 인터넷 연결성을 더하면 IoT라고들 말합니다.

10만원 정도의 돈으로 취미로 흔히 쓰이는 Arduino 또는 Raspberry Pi를 이용하면 인터넷에 접속해서 http 프로토콜로 서버에 센서 정보를 업로드하거나, 반대로 서버에서 작은 json 정보를 읽어서 조잡한 LED 매트릭스에 표현하는 등의 취미를 할 수 있습니다. 서버 만드는 것조차 귀찮으면 클라우드나 Twitter를 이용할 수도 있습니다.

산업계에서도 지난 10년 간 임베디드 보드에 인터넷 연결성을 넣는 것이 가장 많은 요구 중 하나였습니다. 원하는건 고작 인터넷 서버에 몇 KB 아스키 문자를 넣고쓰는건데, http 프로토콜이 멍텅구리 RS232/485보다는 복잡한 편이고 마이컴(MCU)에서 처리하기엔 부담스럽다보니 리얼텍(Realtec) TCP/IP 칩을 추가해야 하는 등 여전히 IoT가 길거리 사은품 뿌리듯 막 쓰기에는 가격이 혁신적으로 낮아지지는 않았습니다.

그럼에도 불구하고 세상이 원하는 기술은 임베디드와 인터넷이 결합된 형태이니, 시간이 갈 수록 더 저렴하지만 통신성능을 온전히 커버할 수 있는 칩셋이 많이 나오는 것은 당연한 수순입니다.

서론이 길었네요. 이 글에서는 Azure IoT의 DeviceTwin이라는 기능에 대해서 알아보겠습니다.

‘디바이스 쌍둥이?’ – 기술에서 Twin이라고 하면 보통 싱크되고 클론된 형태의 복제본을 의미합니다. Azure DeviceTwin은, 임베디드 기기의 설정값과 동일한 값을 Azure에서 가질 수 있다는 뜻입니다.
– 기술문서: https://docs.microsoft.com/ko-kr/azure/iot-hub/iot-hub-devguide-device-twins

원리는 간단합니다. Azure에서 기록한 json 정보는 기기에 덮어써지고, 반대로 기기에서 업데이트한 정보는 Azure에 기록됩니다.
하나의 프로퍼티에 대해 Azure → 기기에 쓰는 것을 DesiredProperty, 기기 → Azure로 업데이트하는 값을 ReportedProperty라고 부릅니다. 이 둘 사이의 값을 같도록 만드는 것이 IoT에서의 DeviceTwin 모델입니다. 별거 아니죠?

실제로, Azure 뿐만 아닌 모든 IoT 관련 퍼블릭 클라우드 회사는 비슷한 개념의 서비스를 제공하고 있습니다. 임베디드 회사들도 각 클라우드 회사의 소소하게 다른 프로토콜을 대부분 지원하고 있지요. 대표적으로는
Espressif의 ESP32 시리즈가 있겠습니다.

Azure는 DeviceTwin에서 한 발 더 나아가서 Digital Twins라는 것을 만들었습니다. 실세계의 공간과 자산을 그래프화하고, 각 IoT 보드에서 오는 정보를 이에 맞추어 저장하고 가공할 수 있게 만든 솔루션입니다. 저도 7~9Ghz UWB 센서로 실내위치인식 기술에 몸담았기에 개념 이해는 잘 되었습니다.

꽤 거창한 산업용 시스템이라 Digital Twins까지 동원하는 사례가 많지는 않을거 같네요. 하지만, 만일 비슷한 것을 만들려거든 그저 만들어진 것을 가져다 쓰는게 낫습니다.

IoT는 최근에 중국 칩셋 회사들의 발전으로 급격히 시장도 커지고 개발 경험도 좋아지고 있습니다. 과거의 PIC나 ATMEL처럼 C코드와 불안정한 컴파일러로 고생할 필요도 적고요. C컴파일러 쓸 바엔 어셈블리 코딩이 더 믿음직한 시절도 불과 10년 전 입니다.

기술의 성장속도가 눈부시니 오늘부터 꼼지락꼼지락 시도해보는건 어떨까요? 내가 직접 쏘아올린 센서 정보에 AI도 끼얹을 수 있고 여러모로 취미생활로 괜찮습니다. 참고로 임베디드 쪽의 지마켓 같은 곳으로 디바이스마트가 있습니다.

Azure Blockchain

Azure Blockchain은 Mark Russinovich CTO가 굉장히 신경쓰고있는 제품입니다. 이 바쁜 분이 몇 번이나 1시간 내내 직접 발표하기도 했지요. 다른 제품에서는 거의 볼 수 없는 분인데 말이죠.


C#에 .NET Framework이 있는 것처럼, Azure Blockchain은 CoCo Framework이 있습니다. C# Corner의 소개글에 따르면, 기존 블록체인 프로토콜을 일원화하여 연동을 쉽게 만들고 일원화된 관리/개발 경험을 주는 기술입니다.

이 coco framework를 기반으로 Microsoft는 분산원장 비즈니스 업계에서 세계 2위의 점유율 (링크:IBM)을 가지고 있다고 하네요. 세계 2위라고는 하는데, 실제로 이 시장이 얼마나 실체적이고 큰지는 모르겠습니다. 다만 Microsoft는 기술회사로서 Blockchain 보다 DLT(Distributed Ledger Technology)라는 용어를 더 자주 사용합니다.

Blockchain의 소비자 욕구를 좀 쉽게 말하자면 코인 밖에 더 있ㄴ “너도 못믿겠고 나도 못믿겠으니 다 열고 보자”는 겁니다. 소프트웨어 구현레벨로 내려오면 FSM(Finite State Machine)에 분산/암호화/변조방지 기능을 더한 정도로 저는 이해하고 있습니다. (제 상식선에서의 이해일 뿐입니다)

Blockchain을 데이터베이스 유형 중 하나라고 말하는 경우도 있는데, 현실적으로는 통상의 데이터베이스처럼 데이터 자체를 저장하는 것이 아닌 데이터의 해시를 저장하기 때문에 데이터베이스라고만 말하기에는 무리가 있다고 생각합니다. 이론적/기술적으로는 원본데이터도 저장할 수 있지만, 현실적으로는 그렇지 않으니까요. (이론적으로는 안되는게 뭐 있겠어요)

현재는 그 이상으로 생각을 안하는 것이 기술을 솔직히 바라보는데 도움이 된다고 생각합니다. 저도 이게 왜 필요한지 여전히 살펴보는 중이고, LINE 블록체인 팀에서도 여전히 ‘이게 과연 필요한가’에 대해서 긍정부정 사이를 두들기며 가고 있습니다.

순식간에 유명해진 짤방
https://me.me/i/do-i-need-a-blockchain-no-22170051

Azure 얘기로 돌아와서, Azure에서 Blockchain 서비스를 만들면 뭔가 엄청 새로운 것이 만들어지는게 아니라 기존 리소스를 엮은 하나의 거대한 시스템이 Azure에 생성됩니다. 아래 그림에 보이는 것이 한 번에 만들어집니다. (원본영상: https://youtu.be/gwrYspdaOx8)

▲ 다 아는 것들이구만…
▲ 실제 생성된 Azure 리소스

개발 편의성을 최우선으로 하는 Azure에서는 Blockchain Workbench이라는 관리툴을 만들어서 제공합니다. 이 글 마지막의 두 YouTube 링크는 Azure Blockchain Workbench가 어떤 것인지 데모를 보여주니까 한 번 보셔도 좋겠습니다.

처음에 Workbench는 비즈니스 요구사항에 따라 개발자가 만든 solidity 파일과 json 설정 파일을 import해서 생성하며, 프로젝트 생성 후에는 정해진 시나리오에 따라 관리자/참여자를 제어하고 간단히 테스트할 수 있는 관리 화면이 나타납니다. API 또한 swagger로 즉시 나옵니다.

▲ swagger API 문서까지 다 만들어짐

아하, Azure Blockchain의 장점을 한마디로 요약하면 ‘믿고 쓸 수 있는 분산 원장 API가 즉시 나온다’는 점이겠네요. 저는 당장에 분산 원장 관련된 서비스를 개발할 일은 없다보니 아직은 한 발 물러나서 구경하고 있습니다. 하지만 비즈니스 워크플로우를 새로 만들 일이 있는 분들이라면 매력적인 솔루션으로 보이네요.

Azure Blockchain Workbench 관련 영상은 아래 링크를 참고하세요.
– Introduction to Azure Blockchain Workbench: https://youtu.be/4j1iHGsTlq8
– Building your first Azure Blockchain Workbench application: https://youtu.be/UkRvg-1c7o0

관련 샘플 코드는 아래 링크를 참고 하세요.
https://github.com/Azure-Samples/blockchain/tree/master/blockchain-workbench/application-and-smart-contract-samples

끝으로, 저는 백서에 별로 관심없지만 coco framework 백서는 아래 링크에 있습니다.

https://github.com/Azure/coco-framework/tree/master/docs