사업을 한다는 것

사업을 한다는 것

사업을 한다는 것

레이 크록 저/야나이 다다시, 손정의 해설/이영래

소프트뱅크회장 손정의와 유니클로 회장 야나이 다다시가 인생바이블로 선언한 책손정의 VS 야나이 다다시 대담 수록소프트뱅크 손정의와 야나이 다다시 유니클로 회장이 ‘인생 바이블’로 꼽는 책이 있다. 일본 산업계의 두 거물은 입을 모아 그 책의 주인공을 동경하는 마음으로 각자의 사업을 일으킬 꿈을 꾸었다고 말…

페이스북에 이 책을 추천한다는 글을 몇 번 보고 그대로 구매했다.

1과를 읽기 전까지는 맥도날드 창업자의 자서전이라는 것조차 몰랐다. 책 표지 어디에도 맥도날드 글자가 없다. 나는 유명인들이 사업가의 마음가짐에 대해서 모아놓은 책인 줄 알았다.

책 읽으면서 드는 생각은 조 지라드의 자서전 ‘판매에 불가능은 없다‘를 읽을 때와 비슷한 감성이 느껴진다는 점이었다. 뭐랄까, 직관과 임기응변과 수십년 전 아메리칸드림에 편승한 고집센 사람의 성공스토리랄까.

지독하게 독단적인 사람의 성공스토리. 하지만 성공하면 이런 책을 써도 될거다.
자신이 구단주인 야구장에서 마이크를 잡고 고래고래 소리지르고 그에 대해 떳떳하다고 책에 쓸 정도로 아무도 토 달지 못하는 성격의 소유자가 될 수도 있지만 말이다.

이 책에서 도움 받은건 인재 채용에 대한 내용들이다.
책에서는 우연히 만난 사람들과 그 사람들과 일하는 에피소드의 연속이지만, 각자의 특징에 대해 꽤 자세히 묘사하고 있다. 좋은 사람을 끌어당기는 한편, 맞지 않는 사람을 내보내거나 싸운 내용도 많이 있다.

이 책의 1과를 읽고 ‘뭐야, 자서전이었네’라며 내 기대와 엇나갔음에도 다시 읽게 한 동기이기도 하다. 내가 채용에 대해서 근심할 때 우연히 책상 위에 있던 이 책에서 펼친 페이지가 나름의 의미를 줬기 때문이다.

나는 그가 우리와 맞는 사람이 아니라는 것을 직감적으로 알았다. (…) 문제의 인물은 계속해서 살아남았다. 몇 번이나 해고될 위험에 처했지만 자리를 옮기거나 새로운 상사를 만나는 식으로 위기를 넘겼다. 예의 바른 사람이다보니 새로운 상사는 매번 그를 바꿔놓을 수 있다고 생각했고 그렇게 하기 위해 공을 들였다. 수년이 흐른 뒤 그는 결국 해고되었다. (…) 중요한 것은 그에게 들인 우리의 시간과 노력이 낭비되었다는 점이며, 더 중요한 것은 그가 결국 막다른 길로 판명난 일에 인생의 소중한 몇 년을 보냈다는 사실이다. 차라리 일찍 해고를 당해서 적성에 더 맞는 다른 일을 찾았더라면 경력에 훨씬 도움이 되었을 것이다. 양쪽 모두에게 불행한 결과였다. 이 일을 통해 알 수 있는 한 가지는, 아무리 기민한 판단을 내릴지라도 다른 사람들에게는 그것이 독단으로 비칠 수 있다는 것이다.

page 182-183

실제 맥도날드 본사의 직원 수가 얼마나 빠르게 증가했는지는 모른다. 다만 꽤 적은 수의 직원들이 아주 오랫동안 일해온 것으로 읽힌다. (프랜차이즈 업은 본사 직원이 규모에 비해 적다고도 써있다)

언제나 경영을 할 때 고민하는게 하나 있다 – ‘나 자신의 직감을 얼마나 믿어야 하는가?’

어릴 때 직감만으로 성공한 사례들만 접하다가 시간이 흐를 수록 실패한 경우를 너무 많이 봐왔기 때문에 직감을 믿는 것에 겁이 나는 것도 사실이다. 그래서 이성적으로 보이기 위해 데이터를 (사실은 자기 직관에 맞게 요리해서) 논거랍시고 활용하는 것이 요즈음 대부분의 직장인들이다.

이 책은 한편으로 이런 고민에 대해 ‘괜찮아. 직감 믿어도 괜찮아’라고 풍선을 불어주는 것만 같다. 다가오는 새 해에는 보다 직감에 많이 귀기울여볼까 한다.

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도 끼얹을 수 있고 여러모로 취미생활로 괜찮습니다. 참고로 임베디드 쪽의 지마켓 같은 곳으로 디바이스마트가 있습니다.