클라우드 서비스의 종류

클라우드 서비스를 이용해서 자체 서비스를 개발하는 것은 이제 흔한 일이 됐습니다. 저는 처음 클라우드가 만들어졌을 때 대체 이걸 어떻게 상용화 할까? 라고 생각했지만 무엇인가를 팔고 이윤을 남기기 위한 인간의 욕망을 무시하면 안된다는 것을 잘 알게 됐습니다.

그렇다면 클라우드의 종류인 IaaS (Infrastructure-as-a-Service) 와 PaaS (Platform-as-a-Service) 와 SaaS (Software-as-a-Service) 는 어떻게 차이가 있는가?


(출처: blog.msdn.microsoft.com)




위 그림에서 가장 쉽게 이야기 해주고 있습니다. IaaS 는 Host에 주안을 두는 것이고, PaaS 는 build 에 주안점, SaaS 는 consume 입니다. 이보다 더 자세하고 명확하게 알아보기 위해서는 다음 그림에서 확실히 소개하고 있습니다.


(출처: blog.msdn.microsoft.com)




위 그림이 가장 클라우드의 핵심입니다.

Packaged Software

이 경우는 보통 IDC (Internet Data Center) 에 직접 서버를 두고 관리를 하는 경우에 해당합니다. 관리해야 할 내용이 많습니다. 네트워크도 설정해야 하고, 저장소 크기도 상태 확인해 가면서 키워야 하고 서버도 직접 관리 등등 모든것을 직접 관리해야 합니다. 보통 이런 경우에 전문적으로 관리하는 SE (System Engineer) 가 필요한 경우가 많습니다. 조그만 회사에서는 서버 개발자가 전부 관리를 해야 합니다.

클라우드 서비스 전의 IT 회사는 대부분 이런 형태의 서버군을 배포환경으로 구성해야 했습니다.

IaaS

이 경우에는 IDC 에서 해야할 일이 전부 사라진 경우입니다. 그 일과 함께 SE 가 해야할 일도 하드웨어 사이드의 일이 전부 사라집니다. 나쁘게 말하자면 개발자가 어느정도 서버 (보통은 리눅스)의 관리를 할 줄 알게 된다면 SE 가 전혀 필요 없는 경우가 생깁니다.

서버의 인스턴스를 마우스 클릭질 몇번으로 생성하고 내가 필요한 어플리케이션을 서버에 올려서 바로 배포가 가능합니다. 배포를 염두에 뒀을 때 하드웨어 적으로 고려할 사항이 극도적으로 적어졌습니다.

PaaS

이 경우는 IaaS 보다 더 극단적으로 쉬워진 경우입니다. 배포 세팅에 대한 고려도 거의 안합니다. 쉽게 말하면 서버가 구동하기 위한 실행 로직 (흔히들 말하길 Business Logic)만 신경쓰면 됩니다. 이쯤 되면 SE 는 필요하지 않습니다. 개발자는 개발 로직만 만들어서 PaaS 에 올리면 나머지는 클라우드가 알아서 확장이나 상태를 관리하기 쉽게 해줍니다.

SaaS

개발도 필요없는 이미 만들어진 서비스를 이용하는 경우입니다. SE 뿐만 아니라 개발자도 필요없습니다.

어떤 플랫폼이 좋았는가?

사실 이야기 하고 싶은 것은 이 주제였습니다.

만들어야 하는 사이트는 웹 소설 플랫폼이였습니다. 개발 기간을 짧게 잡고 있었기 때문에 주요 개발 언어로는 Python 을 선택했고, 웹프레임워크로는 Django 를 선택했습니다. 대략 개발에만 집중해야 하는 기간이 4개월 정도 였기 때문에 Java 언어 기반으로 하기에는 시간적 부담이 느껴졌습니다.

기본이 OpenMarket 플랫폼이기 때문에 필요한 부분이


  • CP (Contents Provider) 사이트 영역
  • Customer 영역
  • 결제 부분
  • 정산 부분


이 필요합니다. 보통 플랫폼 개발은 개발자도 많이 투입하고 개발이 오래 걸리지만 사이트의 특성상 빠르게 개발하고 빨리 오픈하고 계속해서 고쳐 나가는 방법을 정했습니다.

개발 플랫폼을 정하는 것이 개발 초기의 가장 핵심적인 결정 사항이였기 때문에 여러모로 고심을 하다가 구글 앱 엔진 으로 선택했습니다. 이를 결정한 이유는 위에서도 언급이 있지만 배포나 시스템 설정등을 고려하지 않고 개발에 집중하고 싶었기 때문입니다. 왜 레진 코믹스는 구글 앱 엔진을 선택했나 라는 슬라이드도 보고, 아는 지인도 레진 코믹스에서 개발자로 있어서 자문도 구할 수 있었기에 흔쾌히 결정을 했습니다.


PaaS(Platform as a Service)인 구글 앱 엔진은 일단 신경 쓸게 별로 없습니다. 앱 엔진용 SDK 를 받아서 그걸 이용해서 코딩을 하고 베포와 운영은 아주 쉽습니다. 다만 앱 엔진용 SDK 를 공부하고 익숙해져야 하는 단점이 존재했습니다. 빠르게 프로토타입을 만들때는 정말 좋을꺼라고 생각을 하지만 뭔가 대용량의 시스템을 만들어 갈때는 앱 엔진에 맞춰서 개발해야 하는 점이 부담이 되고 잘못됐을 때 바로잡을 레퍼런스가 부족하다는 단점도 큽니다. 개발자들은 구글 앱엔진용 SDK 가 별로라고 원성이 자자했습니다. 그리고 무엇보다 한국에 IDC 가 없기 때문에 무지하게 느렸습니다. 처음부터 멤캐쉬를 고려하고 개발을 시작해야 한다는 문제입니다. (실제로 레진 코믹스도 느린 속도때문에 고생했었나 봅니다). 그러나 무엇보다 좋은 점은 검색 엔진을 구글것을 쓸 수 있다는 점이 장점이였습니다.


초기의 개발은 문제 없이 진행됐습니다. Google App Engine - Django Skeleton 을 이용해서 장고(Django)를 이용한 서비스를 쉽게 '구글 앱 엔진'에 올릴 수가 있었습니다. 하지만 파일 업로드 기능부터 문제가 발생하기 시작했습니다. 일반적으로는 전혀 문제가 안되는 기능인데 구글 앱 엔진을 이용하면 문제가 되는 현상입니다.


결국 최종적으로 사이트가 완성이 되고 최초 공개가 됐을 때 사이트가 너무 느리다는게 문제로 작용했습니다. 웹이나 앱 서버등이 데이타를 가져오는 데 걸리는 시간이 너무 걸리는 것입니다. 너무 느려서 슬쩍 레진 코믹스 개발자에게 너무 느린게 아닌가. 자문을 했더니 뭐 보통 그정도 속도인데? 이런 반응을 보이는 것입니다. 아니 이 느린 환경에서 개발을 이뤄내고 회사를 그 정도 크기 까지 키운 레진 코믹스의 개발자들이 너무 대단스러워 보이는 것입니다. 그래서 마구 칭찬을 했더니 '니네는 투자도 받았다면서? 그냥 AWS 로 개발하는게 낫지 않겠어?' 라고 하더군요. 그래서 바로 IaaS (Infrastructure as a Service) 인 AWS 로 개발 플랫폼을 바로 바꿨습니다.


변경하는데 1주일 정도 걸리더군요. 아직 실제로 서비스 하는 중이 아니였지만 실제로 운영중이였다고 하더라도 그리 오래걸리진 않았을 것이라고 생각됩니다. 사실 편하게 바꿀 수 있었던 이유중의 한가지는 팀원중의 한명이 리눅스(Linux)를 설치하고 그 안에서 서비스 배포의 경험이 많았던 사람이라서. 마우스 클릭질 몇 번으로 서버가 생기고 그 안에서 배포하는 걸 쉽게 할 수 있었기 때문입니다. 구글 검색이 문제 였는데 이것은 엘라스틱서치 에 한글 자소분석기를 붙인것을 Docker 로 만들어서 배포한 걸 이용해서 2분도 안되서 설치해서 적용했습니다. 물론 검색 API 같은것은 따로 만들어 줘야 했지만 말입니다.


결론적으로 우리 회사는 AWS 를 이용한 IaaS 를 이용하는 것이 여러모로 편했습니다. 서버 이해도가 높은 개발자들이 있어서 더욱 그러했던것 같습니다. 만약 구글 앱 엔진이 그리 속도가 느리지만 않았다면 (구조적인 문제입니다. IDC 가 미국 중부나 심지어 동부에 있으니..) 계속 썼을 수도 있으나 만약 쓴다고 해도 아예 처음부터 멤캐쉬(memcache)를 이용한 방식의 아키텍쳐를 구성해야 했을 것입니다. (이 부분은 다시 잘 정리해야 할듯)


어떤 플랫폼을 쓰느냐에 대해서 정답이 없을 듯 합니다. 다만 조금이라도 복잡한 기능을 구현하려고 한다면 자유도가 높은 IaaS 를 추천합니다.





회사에서 서비스하는 digdic inuit 님에게 보여드렸더니 재밌는 개념이라고 하시고, 몇가지 추가되어야 할 사항에 대해서 지적해 주셨는데 그중 뼈 아픈 부분이
"체험하기" 였습니다. 그래서 잽싸게 체험하기 부분을 추가했습니다.


물론 회원 가입을 하면 이점이 많이 있습니다.

 - 사용자 각각의 오답 관리를 체계화 해서 자주 틀리는 단어들을 자주 노출시켜주는 기능
 - 목표를 세우고 목표를 완료할 때까지의 일정 관리
 - 익히고 있는 어휘 수준을 레벨로 표기하여 자신의 어휘수준을 알 수 있게 하기
 - 놀이방 사용시 점수쳬계를 정리해서 순위로 나타내기
 - 다양하고 더 많은 컨텐츠로 학습과 놀이가 가능함

등등이 있을 수 있겠습니다. 지금까지는 충분히 사람들이 많이 참여해 주시고 있는데, 이 여세를 계속 몰아서 가야 할텐데요... ㅎㅎ

많이 오셔서 가입도 하시고, 피드백도 남겨주세요.

digdic 서비스 바로가기
칠선벽파

칠선벽파 의 그림입니다. 순발력과 재치를 필요로 합니다.



(서울=연합비즈뉴스) 교육용 소프트웨어 전문 개발ㆍ서비스회사인 널리(대표 허원근, www.digdic.com)는 학습과 게임을 결합한 영어학습서비스 '디그딕(Digdic)'를 출시했다고 17일 밝혔다.

디그딕은 영어 학습자들이 지루한 암기방법으로 인해 영어단어 학습에 어려움을 겪는다는 점을 보완, 학습과 게임을 과감하게 결합해 매일 짧은 시간을 활용해 엄선된 시험 대비 영어단어 콘텐츠를 학습할 수 있는 영어학습서비스다.

디그딕은 학습과 게임을 통해 학습자가 본인도 모르는 사이에 같은 단어를 몇 차례 접하게 되면서 자연스럽게 반복학습이 된다. 또한 개인별로 일정관리를 제공해 학습자는 일정에 따라 목표로 하는 시험에 맞춰 단어학습을 할 수 있다.

특히 퀴즈형식 게임을 통해 쉽고 재미있게 단어를 공부할 수 있고, 순발력과 상황판단을 요구하는 짝 맞추기 형식의 치열한 대전 게임을 통해 단어를 보는 순간 뜻이 생각나는 인지적 확인 훈련도 가능하다. 순위시스템이 도입된 각 게임은 경쟁심과 함께 지속적인 도전을 자극해 학습 참여를 유도한다.

디그딕은 11만개의 수준별 영어단어 콘텐츠를 내장했고, 다양한 영어자격시험과 전문영역에 맞추어진 엄선된 어휘도 제공한다.

널리 허원근 대표이사는 “디그딕은 학습 능률을 높이는 다양한 특화 기능을 갖추고 있다”며 “학생이나 직장인이 인터넷을 통해 하루에 15분만 투자하면 속도감 있는 영어학습을 할 수 있다”고 밝혔다.

디그딕 학습서비스는 홈페이지(www.digdic.com)을 통해 접속 가능하며 회원 가입 시 일정기간 무료 사용이 가능하다.

기사 원문보기: http://news.naver.com/main/read.nhn?mode=LSD&mid=sec&sid1=102&oid=001&aid=0003172862
어제 후배와 모바일 플랫폼에 관한 이야기를 하던중에 생각난 것이 있어서 정리했습니다.

후배 생각에 아이폰이니 안드로이드니 요즘 개발자들이 크게 동요를 하고 있는데, 그걸로 돈을 많이 번 개발자가 나왔다던지 하지만 왠지 실제 이득을 보는 사람들은 따로 있는것 아니냐? 라고 이야기를 합니다.

전 세상일에 그렇게 까지 비평적일 필요는 없다고 봅니다. 하지막 '목적'이 어디에 있는것인지 잘 파악을 해야 한다는 것이지요. 아이폰이나 안드로이드 플랫폼은 지금 비약적으로 성장하고 있는 신흥시장은 분명합니다. 아니 이미 주력 시장에 들었다고도 볼 수가 있겠지요. 본질을 보자면 아이폰 어플이나 안드로이드 어플이나 그 근본은  util 일 수 밖에 없습니다. 데스크탑 시장에서의 solution 개념이지요

폭발적으로 성장하던 solution 시장은 나락으로 떨어졌습니다. 버티지 못했던 solution 회사들은 사라져 갔습니다. 예전 벤쳐에서 시작해서 크게 자리를 잡은 회사들의 CTO 들이 모여서 나눈 이야기 중에

"서비스와 컨설팅 만이 살아남을 것이다" 라는 이야기를 한 적이 있습니다. '안철수 연구소'의 사업모델이 solution 판매에서 서비스와 컨설팅으로 이동하는 것이 단적인 예라고 볼 수 있다는 것입니다.

그렇다면 모바일 플랫폼을 공부하는 것이 의미가 없겠느냐? 라고 던진 후배의 질문에 철저하게 제 생각만을 말해 줬습니다. 사용자에게 인터페이스를 제공하는 측면에서는 'Yes' 다. 그렇다고 모바일 플랫폼이 모든것이 되지는 않는다고 말해줬습니다. 그 이유에 대해서는 예전부터 제가 생각한 것이 있습니다.

정보! 정보가 중요한 것은 두말하면 잔소리겠지요. 정보의 흐름이 생산되는 곳, 그리고 그 정보가 모이는 곳이 계속되는 사업으로 유지되는 경향이 있습니다. 아이폰 어플 아무리 잘 만들어도 유행기간이 사라지는 순간 다른 어플이 치고 올라오는 것은 시간문제입니다. 정보가 아이폰에만 머무르기 때문이라고 생각합니다. 오직 정보가 끊임없이 생산되고 그 정보가 모이며 유지될 수 있는 곳,

그렇습니다. 바로 '웹' (인터넷, 소셜 네트워크.. 등등) 입니다. 아이폰이나 안드로이드 플랫폼은 그 서비스에 대한 '단말'로서 동작을 하는 것이지요.

후배와 길고 긴 이야기를 나누었지만 결론은 쉬웠습니다.

"향후 모바일 디바이스로 계속해서 인터넷에 접속되는 세상이 올 수밖에 없을 것이다. 예전에도 그랬지만 앞으로도 결국 웹 서비스가 대세가 되는 분위기가 될 수밖에 없다. 모바일 플랫폼 공부도 중요하지만 그 util 의 중심에는 웹 서비스가 있어야 할 것이다. 조금 어려운 이야기 겠지만 정보의 흐름을 창출하고 정보가 모일 수 있는 웹서비스를 만들어야 한다. 만약 웹쪽 서비스 개발분야가 약하다면 제일 먼저 웹 개발부터 익혀라"


94년도에 발표되서 인기가 있었던 아티클을 이번 호에서 다시 다루고 있습니다. 많은
기간이 지났음에도 불구하고 변함없이 최고로 통한다는 것이 대단할 따름입니다.

아티클의 골자는 '기업의 환경을 고객과 직원을 만족시키는 방향으로 개선해야 한다'
것입니다. 직원의 만족이 곧 능률향상으로 이어지고 이런 능률향상이 고객의 만족으로
이어져서 고객이 그 기업의 서비스를 애용하는 충성도 높은 고객으로 변한다는
것입니다.

사실 너무도 당연한 이야기라서 반론도 거의 없었습니다. 대신 어느부분에 역량을 집중할
것인가에 대한 이야기에 대해서는 분분한 이야기가 있었지만, 여러 사람들의 공통된
의견은 기업이란 고객에게 제공할 '가치' 가 선행되고 그 다음에 나머지 역량들을 키우는
것이 많다는 데 의견이 모아졌습니다.

다만 이미 '가치'가 만들어 졌으면 그 다음에는 어찌할 것인가에 대한 것이 저의
의문입니다. 지속적으로 더 좋은 '가치'를 만들어 내기 위해서는 기업 내부의 '가치'를
생산하는 조직의 만족도를 높여가야 하는데 이것은 자금이 들어가는 문제이지요. 참으로
어려운 문제입니다.

아티클이 서비스 기업을 대상으로 하고 있다는 점 , 그래서 모든 기업에 다 적용하기가
어렵다는 점이 있지만, 그럼에도 글 자체는 반론의 여지가 없을 만큼 좋고도
명백합니다. 심술적으로 트집을 잡을 거리가 없을만큼 말이죠 .




세미나 발제 자료는 아래에 첨부하며 인위적으로 어떠한 수정을 가하지 않았습니다. 또한 문제가 될시 자진 삭제하겠습니다. - 그래서 줄이 안맞거나 하지만 이해해주세요 ~


How to Sell Services More Profitably

원문 :
http://harvardbusinessonline.hbsp.harvard.edu/hbsp/hbr/articles/article.jsp?ml_action=get-article&articleID=R0805F&ml_issueid=BR0805&ml_subscriber=true&pageNumber=1&_requestid=2435

저자 : Werner Reinartz and Wolfgang Ulaga

"제품을 파는 수많은 기업들은 특별한 서비스를 제공함으로서 다른 회사와
차별화를 시도하곤 합니다. 서비스를 이용해서 돈을 벌려고 많은 노력들을
합니다."

제품이 일용품화 되어갈때 , 많은 제조회사들은 부가가치 서비스로 차별점을
추구합니다. 하지만 불행하게도 들이는 노력에 비해서 별반 재미는 못보고
있는 상황입니다.

그래서 저자들은 서비스로 수입을 벌어들이는 데 성공한 기업들의 경우를
살펴보고 이익을 가져다 주는 서비스 영역을 개발하기 위한 4가지 단계를
발견했습니다.

Recognize that you already have a service company

보통의 사람들은 간단한 서비스들에 대해서는 그것들을 돈을 내야 하는
서비스로 인식을 하고 , 요금을 냅니다. - Merck 라는 회사가 무료로 선적
요금을 내주는 것을 중단했던 경우처처럼

'실제 예로 보면 Merck 는 기존에 무료로 제공하던 선적요금을 부과할
거라고 약관을 슬쩍 고쳤습니다. 이는 무작위로 고객 100명을 선별해서
행한 테스트베드 였습니다. 이때 90명의 사람들은 약관이 바뀐 것도 모르고
금액을 지불하고, 10명은 약관이 바뀐 것을 알아챘는데 , 5명은 그냥
약관에 동의하고, 나머지 5명은 항의를 해서 바꿨다고 합니다. 그래서
Merck 는 선적에대한 요금을 서비스 항목으로 부과해서 많은 수입을
올렸습니다.'

무료서비스에서 유료로 전환하는 것이 고객과 회사의 경영자들에게 서비스의
가치를 명확하게 해줍니다. - 부언해서 말하자면 양질의 서비스를
제공할테니 그 가치를 인정해달라는(돈으로 달라는) 것은 고객과 기업에게
그 서비스의 가치를 명확히 한다는 것입니다.

Industrialize the back office

서비스를 제공해서 얻어 들이는 수익을 배달비용 (delivery cost)을 다
먹어치우는 것을 막기위해서는

1. 유연한 서비스 기준을 구축해야 합니다.
2. 지속적으로 서비스 프로세스 비용에 관한 근접 모니터링을 행해야
   합니다. (비용이 얼마나 나가는지 어떤 프로세스가 많이 나가는지 등등 )
3. 프로세스 혁신을 가능케 하기위한 새로운 기반기술을 적용해야
   합니다.

한 예로, 스웨덴의 베어링 제조업체인 SKF는 고객의 기계에서 잠정적으로
발생할 수 있는 오류를 외부에서 (사업장이 아닌 다른 곳) 온라인으로
모니터링 할 수 있는 툴을 제공합니다.

Create a service-savvy sales force

서비스들은 더욱 긴 판매 사이클을 필요로 하고 (일반적인 제품 판매보다 -
걍 물건은 팔면 끝이지만 서비스는 기간이 길다
) 종종 고객의 서열상
높은곳에 위치한 결정권자들의 결정을 필요로 합니다. (B2B 를 생각하시면
고객은 회사가 될테고, 그 회사의 서열상 결정권자에 가깝다는
이야깁니다
.)

거기다가 제품을 판매하는 영업직들은 서비스 판매로 변화하는데 부정적 일
수가 있습니다. ( 제품 판매해서 벌어들이는 수익이 서비스 판매에서
벌어들이는 수익보다 차이가 크기 때문에 발생합니다.- 영업직은 대부분
수익베이스로 인센티브를 받습니다.
)

Schneider-Electric (독일의 전기회사) 같은 경우에는 영업조직을 철저하게
조사해서 , 그 영업사원들을 cost-plus 가격정책 에서 value-based
가격정책으로 바뀌게 훈련시켰습니다. - 가장 쉽게 설명한 cost-plus
pricing 과 value-based pricing 의 차이는 가격을 책정하는
방식입니다. cost-plus 는 제품과 서비스 가치의 합산을 통해서 가격을
결정짓는 방식이며 , value-based 방식은 고객이 지불할려는 의지를 가지는
가격에 따른 책정방식입니다. 더우 쉽게 말하자면 원가에 따르는 가격 결정과
고객이 가치에 따라서 기꺼이 지불하려고 드는 가격결정이라고 보시면 됩니다.

http://www.businesslink.gov.uk/bdotg/action/detail?type=RESOURCES&itemId=1073790697」에
cost-plus 와 value-based 의 차이점이 나와 있습니다.

Focus on customers processes and the opportunities they afford for new
service offerings.

기업들은 새로운 이익을 취할 수 있는 기회를 활용할 수 있는 능력을
키워야 합니다. 다음 예에서 그것을 살펴볼 수가 있습니다.

산업 코팅의 특화된 기업인 PPG 는 Fiat의 Torino 자동화 공장에 있는
페인트 가게를 인수하고 도색 공정에서 벌어들이는 수입의 극대화를 위해
자동화된 페인팅 로봇의 기능성을 알아야만 했습니다. Fiat 은 페인팅을
위해서 들어가는 산업도료의 양보다는 무결점으로 칠해진 차의 갯수에
따라서 지불을 했기 때문이다.

정리하자면 서비스는 고객을 (제품에) 묶여있게하고 새로운 거래의 가능성을
열어줍니다. 따라서 서비스는 매우 주의깊고 조심스럽게 개발되어야 할
것입니다.

필자들은 제조업관련 기업들의 서비스 개발 사례를 들어서 설명하고
있습니다. IT 쪽하고는 산업이 다르기 때문에 어떻게 적용해야 할지 막막할
수도 있지만, 결국 어떠한 제품 (Product) 이 있고 거기에 연관된 서비스
(Service) 를 제공하는 것은 산업을 불문하고 기업의 기본적인 능력에
속하기 때문에 '어떤식으로 서비스를 개발해야 하는가?' 하는 것은 기업의
중요한 이슈가 될 수가 있어서 그런 의미로 검토하기엔 의미가 있는
기사입니다.

 결국 어떤 산업이 됐던 이익을 내기 위해서는 기업-고객 - B2C 가 됐던
B2B 가 됐던지 간에 - 의 관계문제 이기 때문에 서비스는 필히 고려되어야
할 사항이라고 여겨집니다.

+ Recent posts