블로그 이미지
평범하게 살고 싶은 월급쟁이 기술적인 토론 환영합니다.같이 이야기 하고 싶으시면 부담 말고 연락주세요:이메일-bwcho75골뱅이지메일 닷컴. 조대협


Archive»


 
 

IOT 개발용 센서 키트


TI에서 IOT 개발을 위한 센서키트를 제공한다는 것을 오늘 들어서 자료를 찾아봤는데, 

Simplelink라는 제품으로 성냥값 정도 크기에 13가지의 센서가 들어있다. 위치,온도,습도 등등

가격은 29$ 정도 밖에 되지 않고, 손목밴드나 LCD등을 끼울 수 있는 키트도 제공한다.





기동을 하면 바로 IBM 블루믹스 IOT 서비스에도 연결이 되고, 안드로이드, IOS 앱도 제공한다.


아마도 웹이나 앱개발용 SDK도 있을 것 같은데. 가격도 싸고 쉽게 IOT 서비스를 개발할 수 있을 것 같아서 북마크 해놓는다.

http://www.ti.com/ww/en/wireless_connectivity/sensortag2015/gettingStarted.html


'클라우드 컴퓨팅 & NoSQL > M2M & IOT' 카테고리의 다른 글

구글의 IOT 솔루션  (0) 2017.03.10
TI의 IOT 개발용 센서 키트  (0) 2016.03.17
MQTT 서버 간단 공부 노트  (2) 2014.02.13

 

트위터 모바일 SDK 서비스 패브릭에 대한 소개


조대협 (http://bcho.tistory.com)




트위터에서는 2014년 부터, 모바일 생태계 지원을 위해서 다양한 기능을 제공하는 Fabric 서비스를 제공하고 있다. 데이타 분석 및 리포팅, 트위터 연동등 다양한 기능을 제공하고 있는데, 대략적인 프로덕트들에 대한 기능과 특징을 살펴보고자 한다.



Crashlytics - Crash Reporting (https://fabric.io/kits/android/crashlytics)


모바일앱에 대한 크래쉬 내용에 대한 수집 및 분석 기능을 제공한다.  

특이한 사항으로는 크래쉬 분석 뿐만 아니라, 베타 사용자나 테스터들에게 앱을 배포할 수 있는 기능을 제공하고 베타 테스트 사항을 추적할 수 있는 기능을 제공한다.

근래에는 게임 개발 SDK인 Unity를 지원하는 기능이 추가 되었다.

 


Answers - Mobile Analytics Kit (https://fabric.io/kits/android/answers/summary) 


Google Analytics나 Yahoo의 Flurry와 비슷한 앱 모니터링/리포팅 서비스이다. Google Analytics와는 다르게 완전 무료이다. (데이타 Limit가 없다.)

단 타 서비스와 차이점은 복잡한 형태의 분석이 불가능하다 Cohort, Funnel 분석이나 User Path등 복잡한 분석은 불가하고 DAU,MAU,Session등 단순한 분석만 가능하다.


단순하기 때문에 지표 이해가 쉬운것이 장점으로 볼 수 있고, 또 다른 장점은 타 서비스에 비해서 리얼타임이라는 것이다. 대쉬보드의 수치는 20~30초 정도의 지연이 있는 수치로, 실시간 이벤트를 하거나 PUSH에 대한 반응을 바로바로 봐야할때나 TV CF후에 반응등 실시간 반응 분석이 필요할때 유용하게 사용할 수 있다.


정확한 분석을 위해서는 Fabric 하나로만은 불가능하겠지만 실시간성을 지원하는 점을 보면, Fabric + Flurry와 같이 두개의 솔루션을 조합해서 사용하는 것을 고려하는 것이 좋다.


Answers에서 특이한 기능중에 하나는, 트위터의 사용자 정보를 기반으로, Fabric Answer 를 통해서 모니터링 되는 사용자에 대한 특성 파악이 가능하다는 것이다. 트위터는 컨텐츠 및 여러가지 종류의 계정 (스포츠, 코메디 등등)을 운영하고 있기 때문에, 트위터는 트위터 사용자의 특성이 어떤지를 알 수 있고, 이 정보를 바탕으로 Fabric이 연동된 서비스의 각 사용자들의 특성을 파악해줄 수 있기 때문에, 서비스 운영 입장에서 사용자에 대한 인사이트를 제공할 수 있다. 




Digit Kit


Digit Kit는 SMS를 이용한 인증 서비스 이다. SMS를 통해서 인증 번호를 전송해서 본인 여부를 확인하는 서비스인데, 200여개의 국가를 지원하고 있고, 가장 중요한건 무료다!!. 글로벌 서비스를 제공 하는 경우 글로벌 SMS 서비스를 고려해야 하고, 또 그에 대한 금액도 만만하지 않은데, 하나의 서비스로 글로벌 커버를 비용 부담없이 제공하는 것은 활용을 고려해볼만하다고 보다. 향후  Email Verification 서비스도 함께 제공할 예정이다. 




Twitter Kit


Twitter Kit은 트위터 기능을 사용하기 위한 모바일 SDK이다. 특이한 점은 트위터로의 공유하는 GUI등을 SDK로 제공해서 어렵지 않게 트위터로의 공유 기능을 구현할 수 가 있다. 




Curator - Twitter contents curation service


트위터 컨텐츠를 모아서 큐레이션 (기존의 컨텐츠들을 2차 가공하여 새로운 컨텐츠를 만드는 것) 해주는 서비스로, 주로 미디어 서비스나 컨텐츠 공급자, 큐레이터에게 유리한 서비스로 Curator라는 저작툴을 이용하여, 큐레이션할 컨텐츠를 골라서 특정 주제에 해당하는 피드를 만들 수 있다. 아래는 서울의 첫눈이라는 주제로 트윗을 검색한 후에, 이를 골라서 콜랙션을 만드는 저작도구 화면이다. 



다음은 큐레이트된 컨텐츠를 임베딩하기 위해서 퍼블리슁 화면이다. 



모바일 개발 트렌드

아키텍쳐 /모바일 | 2015.11.17 10:55 | Posted by 조대협


모바일 개발 트렌드에 대한 예측


조대협 (http://bcho.tistory.com)


시장 환경


2016년 모바일 개발 트렌드에 대해서 언급하기 앞서서 전체적인 모바일 비지니스 변화를 지켜볼 필요가 있다.


모바일 스타트업 중심의 개발 트랜드가 계속


여러 유니콘(실리콘 밸리에서 급속도로 성장하고 있는 스타트업)들의 실적 약화에도, 내년에도 변함없이 계속해서 스타트업 생태계는 확장이 되어갈 것이고, 그 중심에 모바일 앱이 있을 것 이라고 본다.

많은 모바일 앱들은 톡톡 튀는 아이디어와 새로운 기술들로 무장한 스타트업을 중심으로 개발이 될것이라고 보는데, 모바일 스타트업의 특성상 필요한 몇가지 요구 사항이 있고, 이 요구 사항을 채워주는 기술 위주로 내년은 기술 트랜드가 발전하지 않을까 싶다.


모바일 중심의 스타트업 비지니스에서 개발팀이 필요한 내용을 정리해보면 다음과 같다.


효율성과 스피드가 점점 중요시 됨

스타트업의 본질적인 특성상 적은 인원으로, 개발을 해야 하고, 시장에 많은 경쟁 서비스들과 우위를 점하기 위해서는 스피드가 중요하다. 적은 인원으로 스피드를 내려면, 팀의 효율성이 중요하다. 그래서 효율성을 최대로 할 수 있는 개발 프로세스가 필요하고, 빠르게 배우고 빠르게 사용할 수 있는 기술이 필요하며, 시스템 운영등을 대행해주는 서비스들이 필요하다.


고객 피드백과 실험

근래에 스타트업 아니, 비단 스타트업 뿐 아니라 대부분의 서비스 개발 방식은 “린 스타트업” 방식을 따르는데, 최소한의 기능을 가진 제품을 시장에 출시하고, 그 기능을 피드백을 기반으로 계속해서 보강해 나가는 서비스 개발 프로세스를 가지게 된다.

이 프로세스를 실현화 하려면 새로운 기능이나 UX등에 대해 사용자로 부터 피드백을 받을 필요가 있고, 다양한 옵션에 대해서 실험과 분석을할 필요가 있다. 

이런 실험과 분석을 하기 위해서는 사용자에 앱 사용 패턴을 분석할 수 있는 분석 플랫폼과, 다양한 기능을 테스트할 수 있는 테스팅 플랫폼이 필요하게 된다.


글로벌 서비스

모바일 앱 서비스의 수익 모델을 보면 인앱 결재도 많지만, 아직까지는 광고에 의존하는 모델이 상당히 많다. 이 경우, 한국 시장만 보기에는 시장 규모가 너무 작고, 애플리케이션 성의 앱들은 특별히 한국이라는 시장에 갖혀 있을 필요가 없기 때문에 글로벌로 서비스를 확장하거나 처음부터 아예 글로벌을 타케팅 하는 경우가 많은데, 개인 정보 위치에 대한 속지 주의 (개인 정보는 그 나라를 떠자니 못한다) 요건이나 각 나라의 문화나 계정 체계 (동남아는 라인 로그인을 많이 쓰고, 한국은 카톡 로그인, 미국은 페북 로그인을 많이 쓰는)나 기술적 차이 (중국에서는 구글이나 애플 푸쉬가 작동하지 않는다)로 인하여 각 국가에 맞게 애플리케이션을 수정해야 할 필요가 있다. 


개발 트랜드


그러면 이런 니즈를 맞추기 위해서 개발 트랜트는 어떻게 변화하고 있을까?


클라우드 활용의 가속화

첫번째는 클라우드 서비스 활용의 가속화이다.  클라우드 서비스의 활용은 어제 오늘일이 아닌 이미 보편화된 내용인데,  그렇다면 변화는 무엇인가? 클라우드 서비스 활용이 주로 서버등의 인프라를 활용하는 IaaS 중심이었고, 근래에는 웹서버나 데이타베이스 서버등의 미들웨어를 활용하는 PaaS 형태로 그 중심이 옮겨왔다.

예전에는  아마존의 EC2등에 직접 솔루션을 설치해서 개발을 했는데, 요즘은 그보다  아마존 Beans Talk이나 Heroku 클라우드 같은 PaaS 형태의 사용이 잦아졌고, Redis나 MongoDB등과 같은 다양한 솔루션들이 PaaS 형태로 제공되어 많은 미들웨어를 직접 설치하지 않고 managed 서비스를 사용하는 형태로 이동하고 있다. 이는 복잡한 인프라에 대한 설치 및 운영 비용을 줄이고, 빠른 개발을 할 수 있게 도와준다.

 대표적인 서비스로는 아마존 BeansTalk, IBM BlueMix, Heroku 클라우드등을 예로 들 수 있다.


여기에 한걸음 더 나가서 Fundamental 서비스의 활용이 두드러 지는데, Fundamental 서비스는 애플리케이션을 구성하는데 사용되는 기능을 제공하는 서비스로 대표적으로 푸쉬 서비스, 메세지 큐 서비스, 사용자 계정 관리 서비스등이 이에 해당한다. 특히 이러한 서비스는 여러가지 복잡한 기능들을 추상화해주기 때문에 여러가지 기능들을 동시에 지원해야 하는 경우 쉽게 개발을할 수 있게 해준다. 대표적인 예로는 푸쉬 서비스를 들 수 있는데, 푸쉬는 기본적으로 안드로이드와 iOS를 위한 GCM,APNS 푸쉬 지원뿐 아니라, 중국을 위한 바이두 푸쉬등 다양한 푸쉬를 지원해야 하며, 대량 발송, 예약 발송등 복잡한 기능들을 제공해야 하는데, 이를 일일이 개발하려면 그것만으로도 하나의 제품을 개발하는 정도의 개발 노력이 필요하다. 이러한 고급 기능들이 근래에는 클라우드로 제공되는데, 아마존의 SNS와 같이 대형 클라우드 벤더에서 Fundamental 서비스로 제공하는 기능이나 또는 OneSignal.com 과 같이 특정 도메인(기능)에 전문화된 형태로 서비스가 제공 되는 경우가 있다.


 대형 벤더에서 제공되는 Fundamental 서비스는 해당 클라우드 인프라와 같은 위치에서 서비스가 제공되고 같은 인프라를 사용하기 때문에 통합이 쉽다는 장점을 가지고 있지만 반대로 특정 도메인 기능만 제공하는 전문화된 서비스에 비해서 가격이나 기능적인 면에서 열세인 경우가 많다.


대표적인 서비스로는 앞에서 언급한 푸쉬 전문 서비스인 OneSignal.com , 동영상 인코딩 서비스 heywatch.com, zencoder.com , Redis 전문 서비스인 redislabs.com , 몽고디비 및 DBaas 서비스 전문업체인 compose.io , 검색 전문 서비스인 https://www.algolia.com/ 등을 들 수 있다. 


여담으로 나이가 많은 개발자들은 기술을 탐독하고, EC2등에 직접 깔아서 사용하는 것을 선호하는 반면, 근래에 많은 스타트업 개발자들을 만나서 개발 아키텍쳐를 검토하다보면, 오히려 잘 구성되어 있는 매니지드 서비스들을 잘 엮어서 빠른 시간내에 더 좋은 기능으로 서비스를 개발하는 것을 보면, 세대간에 기술에 대한 접근 방법이 벌써부터 차이가 나지 않는가 한다.



풀스택 개발자

풀스택 개발자란 한명의 엔지니어가 독립적으로 모든 서비스를 개발할 수 있는 수직적인 기술 능력을 가지고 있는 사람을 정의한다. 수직적인 기술 능력이란, 앱-백앤드-인프라 또는 프론트-백앤드-인프라 까지 서비스를 개발하는 데 필요한 모든 End to End  기술을 이야기 한다.

작년까지만 해도 풀스택 개발자가 바람직하다 아니다 라는 논쟁에서 부터, 풀스택 엔지니어는 불가능하다 가능하다 까지 여러 논쟁이 많았다.

결론 부터 말하자면 풀스택 개발자가 가능하고 불가능하고, 바람직하고 말고의 논쟁을 떠나서, 할 수 밖에 없다.


스타트업 인원 구조의 특성상 각 기술 계층에 해당하는 엔지니어를 따로 뽑을 수 가 없기 때문에 한명의 개발자가 앱 개발에서 부터 백앤드 개발까지 모두 맏아야 하며, 시스템을 운영하기 위한 인프라 설치 및 운영까지 모두 커버해야 한다. 


이런 것이 가능한 것은, 스타트업 인력 구성의 한계에 의한 필요성도 있지만, 이런 필요성에 의해서 기술도 그만큼 편리해졌기 때문이다. 스크립트 언어의 발전으로 루비나 node.js 의 경우 학습 비용이 매우 낮고, 생산성이 높게 개발을 할 수 있으며, 아울러, 클라우드의 발전으로 전문적인 하드웨어 전문적인 지식이 없이도 얼마든지 인프라를 운영할 수 있고 더불어 PaaS의 발전으로 하드웨어의 지식이나 미들웨어에 대한 지식이 없이도 설치 및 운영이 가능하게 되었다.


개인적으로 풀스택 개발자의 가능성에 대해서 많은 고민을 했는데, 스타트업에서 만난 엔지니어들을 보면 앱 개발에서 시작했다가 필요로 인하여 서버를 개발하게 되고, 쉬운 방법을 찾아가면서 클라우드를 활용하면서 서버 개발까지 같이 하는 개발자들을 많이 보았다. 특히나 백앤드 개발에 대한 선입관이 없기 때문에 솔루션이나 아키텍쳐 구성에 유연성이 보이고, 기존 전통적인 백앤드 아키텍쳐의 사상을 넘어서는 좀더 실용적인 아키텍쳐 디자인을 하는 것을 볼 수 있었다.


서비스 기반의 데이타 분석

근 몇년 빅데이타 분석의 중요성은 계속 강조되어 왔기 때문에 데이타 분석의 필요성등에 대해서는 별도로 언급하지는 않겠다. 그런데 이 데이타 분석이라는 것이, 많은 양의 데이타를 저장하기 위한 하드웨어 인프라가 필요함은 물론이고, 이를 분석하기 위한 소프트웨어 예를 들자면 하둡이나 스팍과 같은 기술을 도입하기 위해서는 높은 기술 수준과 자금이 필요하기 때문에 일반적인 스타트업에서는 적용이 매우 어렵다. 그래서 빅데이타라는 넘어가야 하는 영역이 있음에도 불구하고 실제로 활용하기가 어려운 영역이었다.

그런데 근래에 광고 서비스 업체나 인터넷 서비스 업체를 중심으로 데이타 수집에 대한 요구와 개발자 생태계를 자기쪽으로 끌어들이기 위한 목적으로 데이타 분석 서비스를 무료 또는 부분 무료로 오픈 하는 경우가 많다.


대표적인예로, 구글 애널러틱스 (aka. GA)나 야후의 Flurry, 트위터의 Fabric과 같은 서비스들이 대표적인 예이며, 한국의 경우 파이브락스(http://www.5rocks.io/en) 가 무료(광고를 내보내야하기는 하지만)에서 서비스를 제공하고 있다. 



< 그림. Yahoo Flurry 스크린샷 >


단순하게는 일/월 방문자수 (DAU/MAU)에서 부터, 사용자가 앱에서 어떤 경로로 돌아다니고 머무는 시간이 얼마인지, 사용자 층은 어떻게 되는지까지 분석이 가능하다.

앱을 개발해서 서비스를 한다면 반드시 사용해야 하는 서비스가 아닐까?


AB 테스팅의 도입 가속

페이스북을 사용하는 사용자라면 어느날 갑자기 앱 업데이트를 하지 않았는데도 새로운 기능이 돌다가 갑자기 그 기능이 없어진것을 확인할 수 있다. 페이스북에서는 사용자의 반응을 살피기 위해서 새로운 기능을 미리 넣어서 배포해놓고,사용자를 A/B 두 그룹 (또는 그 이상)으로 나눠서 사용자의 기능 사용에 대한 반응을 보고 그 기능을 적용할지 여부를 결정하는 방법이다.


A/B 테스팅은 개념 자체는 좋지만, 앱스토어 환경에서 이를 하려면, 

  1. 두개의 기능을 개발해야 하고
  2. 각 기능을 A/B 두개의 사용자 그룹에 별도로 보이게 해야 하며
  3. A/B 사용자에 대한 기능 사용율을 매번 수집하여 분석해야 한다.


물론 직접 코드로 만들 수 도 있지만, 배포된 애플리케이션에서 테스트 비율을 조정한다던지, 테스트 진행 상황에 대한 리포팅을 작성하려면 로그도 수집해야 하고 별도의 개발 노력이 드는게 사실이기 때문에, 막상 쉽게 접근하기는 어렵다.


이런 일반적인 AB 테스팅 개발을 제공하기 위한 클라우드 기반의 서비스가 근래에 들어서 많이 제공되고 있는데, optimizely.com apptimize.com 등 여러 서비스들이 있고, 아마존 AB 테스팅의 경우 무료로 그 기능을 제공한다.

아마존의 경우는 무료인 만큼 기능이 빈약하다. 상용 서비스의 경우에는 5만, 10만 사용자까지 무료로 기능을 제공하거나 수익을 내지 못하거나 펀딩을 받지 못한 스타트업에는 무료로 제공하는 경우도 있으니, 꼼꼼하게 살펴볼 필요가 있다. 


  

<그림. AB 테스팅 도구에서  UI를 변경하는 화면> 

출처 : https://www.leanplum.com/c/blog/page/2/


특히 상용 솔루션의 경우에는 앱이 배포된 상태에서 별도의 재 배포 없이 UI 요소 (버튼 색, 이미지, 텍스트)를 동적으로 변경해서 테스트를 진행할 수 있는 기능을 제공하기 때문에, 손쉽게 UI 개선을 해나갈 수 있고, 특히 GUI 기반의 도구를 제공하기 때문에, 개발팀의 도움 없이 디자인팀이 직접 수정을 해서 테스트가 가능하다.


개발에 대한 공수나, 적절한 플랫폼의 부재로 지금까지 쉽지 않았던 분야인데, 여러 클라우드 기반의 서비스를 기반으로해서 2016년에는 일반 앱 서비스 개발에도 사용 빈도가 꽤 높아지지 않을까 하는 예상을 조심스럽게 해본다.

오픈 소스 머신 러닝 알고리즘 및 클라우드 머신 러닝 서비스


데이타 분석의 다른 영역으로는 데이타를 분석하여, 추천이나 데이타등을 군집화 또는 분류해주는 머신러닝 (Machine Learning) 분야가 있다. 수학적인 지식과 대규모 인프라가 필요하기 때문에, 일반적인 기업이나 개발자들이 접근하기 어려운 부분이었는데, 근래에 하둡과 같은 빅데이타 인프라가 오픈소스화 되고, 또한 복잡한 ML  알고리즘이 오픈소스 패키지로 제공됨에 따라서 급격히 확산이 되기 있는데, 여전히 소규모의 앱 개발자들이 쓰기에는 복잡한 인프라를(하둡,스파크 등) 직접 설치 운영해야 하는 부담이 있었다.

 그러나 근래에 Microsoft 나 Google 등을 중심으로 이 머신 러닝 알고리즘을 클라우드 서비스 형태로 API가 제공됨으로써 개발 접근성이 매우 쉬워졌고, coursera.org 와 같은 온라인 강의를 통해서, 일반 개발자들오 머신러닝 관련된 기술을 쉽게 배울 수 있는 온라인 강좌됨에 따라, 예전에 비해서 훨씬 쉽게, 빅데이타를 활용한 머신러닝 서비스에 접근이 가능하게 되었다. 




<그림.  Microsoft Azure 클라우드의 머신러닝 로직 설계 화면 >




지금까지 짧게지만 앞으로는 모바일 서비스 개발 방향에 대해서 살펴보았다.

전체적인 흐름을 요약해보자면, 스타트업 주도의 개발이 활성화 되면서 적은 인원으로 효율적인 개발을 할 수 있는 환경이 필요함에 따라 앱 개발자가 스크립트 언어등 러닝 커브가 낮은 언어를 이용하여 서버쪽에 구현을 같이하는 풀스택 개발자 형태로 전환되는 현상이 가속화될 것이고, 이에 맞물려서 쉽게 인프라를 사용할 수 있게 하는 클라우드 컴퓨팅 환경의 활용이 플랫폼 형태로 되어 있는 PaaS를 중심으로 활용될것이다.

또한 빅데이타에 대한 활용 부분이 대기업 뿐 아니라, 저 자본에 소인원인 스타트업 앱 개발에도 사용이 되는 대중화의 국면을 맏을 것이라고 보는데, 클라우드 서비스 형태로 제공되는 빅데이타 분석등의 플랫폼을 중심으로 무료 또는 저 비용의 서비스가 활용 될것이며, AB 테스팅 서비스의 활성화로 사용자의 반응을 기반으로 하는 개발이 가속화 될것으로 보인다. 또한 고급 머신 러닝 알고리즘이 오픈소스화 되고, 서비스 API화 되면서 대중화 국면을 맞을 것이다.


2015년 개발 트랜드-조대협

IT 이야기/트렌드 | 2015.01.12 10:09 | Posted by 조대협

2015년 개발 트랜드


조대협입니다. 2015년 개발 트렌드에 대해서 간략하게 정리해봅니다. 여러 기술들을 보고 정리한 개인적인 생각이며, 앞으로 저도 집중하려고 하는 분야이기도 합니다.


애자일 및 협업 문화

애자일 과 수평 조직 기반의 개발 문화에 대한 현상은 올해에도 쭈욱 지속될 듯 합니다. 기존의 워터폴이나 경직된 조직 문화와 방법론으로는 현대의 빠른 서비스 개발을 따라갈 수 가 없져

애자일은 워낙 오래전 부터 언급되고 나온거라서 별도로 언급을 하지 않겠습니다만, 왜 이 부분을 2015년의 트랜드로 잡았느냐 하면, 국내 기업의 경우 애자일 프로세스만을 도입하는 것이 아니라, 조직의 구조나 문화 자체를 애자일 사상으로 옮겨가는 경우가 많이 보이기 때문입니다. 기존에 무늬만 애자일이었다면, 작년부터 올해까지는 애자일 문화를 적용하기 위한 직급을 없애고 직책(ROLE) 기반으로 일하기 위한 변화, 수평적 조직 구조, 그리고 스크럼 마스터와 프러덕트 오너등이 조직내에 점점 더 확실하게 자리 잡아 가는 것 같습니다.


MSA 아키텍쳐

작년 중반 부터 떠오르기 시작하더니 국내에도 많은 시스템들이 MSA 사상으로 구현되가고 있는 것들이 보입니다. 이제 시작 단계들로 보이는데, MSA를 적용을 하고 있는 조직들은 MSA가 가지고 있는 전통적인 문제들, 분산 트렌젝션에 대한 처리, 여러개의 API를 모아서 새로운 기능을 만들어내는 aggregation 개념들에서 많은 고민들을 하고 있는 것이 보입니다.

그리고 MSA를 개발하기 위한 개발환경을 셋팅하는데 많은 고민들을 하는데, MSA의 특성상 서버 컴포넌트가 많이 분산이 되고 폴리그랏(다양한 언어로 개발)현상이 조금씩 가속화 됨에 따라서, 이러한 복잡한 개발환경을 어떻게 개발자에게 전달할것인가가 새로운 키워드가 될 듯 합니다.

이에 대한 대안으로는 Docker등이 빠르게 떠오르고 있고, 사내/사외 개발용 클라우드를 구축 하는 움직임이 생기지 않을까 조심스럽게 점쳐 봅니다.

MSA를 적용함에 있어서 앞단에 api gateway (또는 proxy)역할을 하는 것들이 중요해지고 있는데, 현재는 대부분 직접 개발해서 사용하는 경우가 많습니다. 그 만큼 거기에 사용할 제대로된 제품이나 오픈소스가 없다는 것인데, (오픈소스는 현재 WSO2 api gateway, 상용 CA Layer7, 클라우드 기반 서비스 apigee) 아마 금년에는 이러한 needs 때문에 다양한 오픈소스가 나오지 않을까 조심스럽게 기대해봅니다. 2013년까지만 해도 API gateway 오픈 소스 제품들은 손에 꼽을 정도였는데, 작년말에 한번 만들어 볼까 하는 마음으로 살펴보니, 벌써 몇개의 오픈소스들이 시작되고 있더군요

그리고 MSA에 맞춰서, SpringBoot도 같이 올라가면서, 자바 진영의 개발 주류가 되지 않을까 생각해봅니다.


데이타 스트리밍 프로세스

빅데이타 영역은 하둡을 중심으로 어느정도 정리가 되었으나, 근래에 들어서 실시간 데이타 분석에 대한 니즈(needs)가 올라오면서 실시간 스트리밍 처리가 작년말부터 다시 주목 받는것 같습니다. 람다 아키텍쳐나 데이타레이크 아키텍쳐가 다시 언급되는 것도 같은 선상이라고 보는데, 금년에는 Storm,Spark 중심의 실시간 데이타 처리 기술이 다시금 부각되지 않을까 합니다.


머신 러닝의 보편화

머신 러닝은 수학 통계적인 지식이 있어야 접근할 수 있는 분야였지만, 근래에는 Apache Mahout등의 프레임웍으로, 주로 사용되는 머신 러닝 알고리즘 들은 대부분 프레임웍화 되어 있어서 접근이 매우 쉽습니다. 약간의 지식만으로도 머신러닝을 사용할 수 있다는 겁니다.

여기에, Microsoft Azure ML 서비스와, IBM의 왓슨 서비스들은 클라우드 기반으로 머신 러닝 알고리즘을 서비스하는데, 사용이 매우 쉬워서, 일반 개발자들도 쉽게 머신 러닝 알고리즘을 구현 및 운영 환경에 적용이 가능합니다.

다른 빅데이타 분석들도 이런 흐름을 따라가지 않을까 싶은데 제가 보는 관점에서는 ML쪽이 선두가 되서 서비스화되는 현상이 작년말 부터 시작되고, 금년에는 초기 활성화 단계에 들지 않을까 합니다.


폴리 그랏

작년에도 그랬지만, 금년에도 여러가지 프로그래밍 언어를 사용하는 폴리그랏 현상은 더욱 더 가속되지 않을까 합니다. Node.js등은 계속해서 약진할거 같고, Ruby,Groovy와 같은 기존의 스크립트 언어 뿐만 아니라 Google Go, MS가 이번에 Linux까지 자사의 프로그래밍 언어를 지원하겠다고 한 이마당에, 금년에 프로그래밍 언어의 흐름은 지켜볼만 합니다.


기타

자바스크립트의 약진, 자바스크립트 기반의 Pure 웹 클라이언트, 클라우드의 적용 가속화

이런것들은 워낙 뻔한 이야기이니 별도로 언급하지 않겠다. 다만 마지막으로 지켜볼것은 중국 IT 기술의 약진으로, 금년에 중국발 오픈소스나 기술들이 인터넷으로 조금씩 공개되지 않을까 기대해봅니다.


 

기존 개발 체계의 문제점

전통적인 개발 운영 체계

일반적인 개발 운영 체계는 다음과 같다. 개발팀에 의해서 개발이 끝나면, 시스템은 테스트를 거쳐서 운영팀에 이관되고, 운영팀은 해당 시스템을 배포 관리 운영한다.



일단 이관된 시스템은, 개발팀이 일체 관여하지 않고, 운영팀에 의해서 현상 유지 된다.


문제점 1. 누구의 잘못인가? 불행의 시작

시스템을 운영하다 보면, 반드시 장애가 생기기 마련인데, 문제는 여기부터 시작된다. 개발은 애플리케이션 있지만, 아랫단의 인프라 시스템 있는 능력이 없다. 반대로 운영팀은 인프라 시스템 알지만, “애플리케이션자체에 대해서는 모른다.

그러다 보니, 서로 자기 분야의 문제가 아니라고 하면서 서로 책임 미루기를 하게 되고, 문제 해결은 지연된다. 이러한 책임 미루기에 대해서 “Fingerpointyness”라는 말로 표현한 것이 있는데, 정확하게, 누가 어떤 문제를 해결해야 하는지 정의 되지 않은 상황에서, 협업이 없어지고 문제 해결이 엉뚱한 방향으로 가는 현상이다.


[1]

    Freaking out & find fault 단계 (문제 발견)

자아. 문제가 발생했다. 문제의 내용을 먼저 파악한다. 이때 협업은 없다. 단지 자기 분야에서 문제가 어떤 것인지, 한정된 지식으로 현상 자체를 인지하는 수준이 된다. 근본적인 문제에 대한 원인 파악보다는 대충 파악하는 단계 정도의 수준이 된다. 단계에서 누가 문제를 파악할지에 대한 owner ship 자체가 정해지지 않는다.

    Blaming Covering ass 단계 (욕하기)

그러다가, 어느 정도 문제의 현상 (정확한 원인이 아니라) 정도가 파악되면, 서로 미루기를 한다. “애플리케이션 문제네..”, “데이터 베이스 문제네..” 식으로, 정확한 원인 파악 없이 자기 문제가 아닌 처럼, 다른 쪽으로 미루기를 시작하면서, 상대편을 욕하는 단계가 된다. “데이터 베이스 구성을 그렇게 하니까는 그렇지.. 인덱스는 아냐?”. 내지는 애플리케이션 구조에 맞춰서 배포는 한거야?” 이러면서 문제의 근본적인 원인은 해결되지 않고 시간은 계속 간다.

    Whining, Hiding. Hurt Ego 단계 ( 상처 입기)

계속 해서 문제를 서로에게 넘기다 보면, 문제를 숨기거나 상대방을 헐뜯거나 하면서 결국은 서로 상처를 입게 되고, 점점 커뮤니케이션은 없어지고 관계는 악화되어 간다.

    Figuring it out (문제 원인 분석)

결국 문제를 해결해야 하는 시간이 가까워 오면, 문제를 풀긴 풀어야 하니,  어떻게든지 스스로 서로 모여서 문제를 같이 보게 되거나, 상위 메니져를 통해서 강제적으로 같이 모여서 문제에 대한 원인 분석을 해서 결국은 원인을 파악하게 된다.

    Fixing things (문제 해결)

그리고, 결과적으로 원인 파악 문제가 해결된다.

아주 전형적인 개발과 운영간의 장애 처리 프로세스이다. 그나마 똑똑한 팀장을 가지고 있는 조직은 장애나 문제가 발생했을때, “모두 모이세요.”해서 초기부터 문제를 같이 보고 해결하거나, 개발팀이나 운영팀 자체가 상대방의 분야를 있는 능력을 갖춰서 문제를 해결하는 경우가 많다. 예를 들어 운영팀이 애플리케이션에 대한 장애 대응 능력을 갖거나, 개발자가 OS, 데이타베이스 또는 미들웨어등에 대한 인프라 운영 능력을 갖는 경우이다.


문제점 2. 운영 이슈에 대한 전달 문제

다른 문제점을 살펴보자, 앞에서도 언급 했듯이, 개발은 운영으로 이관 후에, 서비스에 대해서 이상 관심을 갖지 않는다. 그리고, 고객과의 접점도 거의 없다. 그러나 운영은 (단순히 시스템을 운영하는 시스템 운영만이 아닌 실제 서비스 운영을 포함) 계속 해서 사용자와 interaction 하고, 사용자로부터 끊임 없이 VOC (Voice Of Customer) 받는다.



서비스를 운영하는 입장에서, 사용자의 의견을 들어서 서비스를 개선하고 싶은 것은 당연한 이치이고, 여러 VOC 모아서 개발팀에 서비스 개선 요청을 하지만, 이미 개발과 운영은 멀어져있는 상태이고, 운영은 명시적으로 개발팀에 요구 사항을 정의할 있는 권한이 없기 때문에 (이러한 권한은 일반적으로 서비스 기획팀에서 갖는다). 이러한 개선 요청 요구 사항은 개발팀 입장에서는 추가적인 일이 되고, 개발팀은 이러한 신규 요구 사항에 대해서 저항하거나 또는 거절하게 된다.


문제점 3. 변경 요건

서비스가 운영 배포된 후에도, 비즈니스 (기획팀) 의해서, 계속 해서 서비스에 대한 신규 요구 사항은 나오게 되고, 새로운 변경 요건은 신규 개발과, 테스트 배포 그리고 지속적인 운영을 요구 하게 된다.



그런데, 근래의 서비스들의 경우에는 빠른 비즈니스 환경 변화에 따라가기 위해서 많은 변경 요구하게 되고, 이는 필연적으로 잦은 변경 배포를 요구 하게 된다. 제대로 많은 변경으로 인하여 제대로 테스트 시간을 거치지 못한 애플리케이션의 경우에는 잦은 장애를 유발한다.

이런 배경으로 인해서 운영팀은 잦은 배포를 꺼려하게 되고, 조금 전통적이고 형식적인 관점에서 주기적인 릴리즈와 테스트를 요구하게 된다. 애플리케이션단에 문제가 있다 하더라도 긴급 배포가 어려운 경우가 많고, 긴급 배포를 했다 하더라도, 개발팀의 실수를 뒷처리 하는 입장으로 인식하기 때문에, 계속 해서 개발팀과 운영팀의 관계는 악화 되어 간다.


그러면 해결책은?

그렇다면 구조적으로 이렇게 개와 고양이처럼 앙숙일 밖에 없는 개발팀과 운영팀과의 관계는 어떻게 해결 것이며, 문제로 인해서 발생하는

         서비스 요구 사항의 신속한 반영의 문제

         고객의 요구 사항에 민감한 소프트웨어 개발

문제들은 어떻게 극복할 있을까?


Solution 1. 협업 하자  - 기획과 개발을 합치자.

답은 간단하다. 기획,개발,운영 모두 사이좋게 지내면 된다. 어떻게 사이좋게? 서로 대화도 많이하고 팀웍을 다지면 된다. 이런 활동의 일환으로 시작된 것이 애자일 방법이다. 기획팀과 개발팀을 하나의 팀으로 합쳐서, 요구 사항 변화에 빠르게 반응할 있는 구조로 바꾸고, Iterative 개발(반복적), Short Release 이용한 잦은 릴리즈를 통해서 비즈니스의 요구 사항을 신속하게 반영하고, 변화에 대응할 있는 구조를 갖추는 것이다.


Solution 2. 개발과 운영을 합쳐 버리자. (Devops)

첫번째 솔루션은 분명히 좋은 방법이긴 하지만, 조금 최적화 시킬 수는 없을까? 애자일 방법론을 적용해도 여전히 운영과 개발은 앙숙인 관계이다. 그렇다면? 기획과 개발을 합쳐 버렸듯이,


좋은 개념을 이제야?

간단하게 개발과 운영을 합쳐 버리면 될텐데, 이걸 이제서야 할까? 결론부터 이야기 하면, 예전에는 어려웠다. 개발과 운영은 영역 자체가 매우 상이하고, 요구 되는 기술 능력도 많이 차이가 나기 때문에, 일반적인 엔지니어가 양쪽을 모두 커버하기가 어려웠다.

또한 기술 자체에 대한 습득 경로가 교육이나 서적으로 제한 되어 있었고, 인터넷을 통해서 요즘 처럼 이렇게 쉽게 정보를 얻기가 어려웠다.


인터넷의 발전

인터넷은 더욱더 발전해서, 내가 필요한 자료는 인터넷에서 찾을 있을뿐만 아니라, 오픈소스 커뮤니티에서 남들이 만든 코드를 보고 배울 있고, YouTube에서 강의를 들을 있으며, Slideshare에서 요약된 PPT 있다. 지식을 습득할 있는 채널이 다양해지고, 쉬워졌다.


오픈 소스의 발전

인터넷이 발전되면서, IT 흐름이 크게 바뀐 것중에 하나는 이상 오라클이나 IBM 같은 대형 벤더 주도의 기술이 아니라 페이스북이나 구글과 같은 거대 B2C 서비스가 IT 흐름을 이끌기 시작했고, 이러한 업체들이 오픈소스를 적극적으로 후원 장려하기 시작했다. 오픈 소스를 통해서 전세계의 개발자들과 함께 이야기를 , 일을 있고 오픈 소스를 잘하면 이런 구글이나 페이스북과 같은 좋은 회사에도 취직할 있다. 그래서 개발자들이 오라클이나 SAP 같은 엔터프라이즈 제품을 공부하지 않고, 오픈소스를 개발하면서 논다(enjoy~)”


오픈소스 Stitching

이렇게 오픈소스가 발전하다 보니, 요즘 개발은 하나의 프로그램 언어로 하나부터 열까지 모두 개발하는 것이 아니라, 여러 오픈소스들을 모아다가 합쳐서, 하나의 서비스를 만드는 형태로 바뀌고 있다

이제 모두 내가 개발할 필요도 없이 찾아서 조합 하면 되고, 문제가 있는 오픈소스는 내가 직접 고치거나, 오픈 소스 개발자들에게 부탁해서 수정을 할 수 있다. 솔루션에 대한 선택 기회가 넓어지고,  코드 자체 개발 뿐만 아니라, 효율적으로 오픈소스 솔루션을 조합 및 구현하는 개발 형태의 중요성이 높아지고 있다.


좋은 도구들

오픈소스의 발전으로 이루어진 혜택중의 하나가, 좋은 툴이 많아 졌다는 것이다. 개발에 관련된 뿐만 아니라, 빌드,배포에 대한 툴과, 모니터링에 대한 툴도 많아졌기 때문에, 운영 업무에 해당 하는 이런 부분을 상당 부분 자동화를 있다.


클라우드의 등장

클라우드 컴퓨팅의 가장 특징 중의 하나는 사용자가 인프라 (서버 설치, 네트워크 케이블 구성) 구성할 필요가 없이, 간단하게 책상 앞에 앉아서 웹사이트를 몇번 클릭 하는 것만으로 지구 반대편의 데이터 센터에 서버, 스토리지 구성, 네트워크 구성이 가능하게 되었다는 것이다.

이상 개발자는 새로운 기술을 익히는 , 책을 뒤져가면서, 새로운 교육을 들어가면서 지식을습득할 필요가 없다. Googling 하면 개발에 대해 필요한 자료를 얻을 있다.

개발을 할때는 필요한 모듈을 오픈 소스를 조합해서 만들 있으며, 여러가지 좋은 도구들을 통해서 빌드나 배포등을 손쉽게 자동화할 있으며, 클라우드를 통해서 개발자도 네트워크, 서버등에 대한 설정들을 있다. 인프라에 대한 지식이 부족하면 이것 또한 인터넷을 검색하면 된다.  결과적으로 개발자가 있는 영역이 더욱 넓어졌다.

바꿔 말하면, 인프라에 대한 전문 지식이 없이도, 인터넷과 오픈 소스 그리고 클라우드의 도움을 받아서, “운영 겸업 있는 환경이 마련 되었다는 것이다.

2편 글 링크 - http://bcho.tistory.com/817