정부 과제 발표에서의 팁

  7년만에 다시 정부 과제를 수행할려고 발표를 했습니다. 1차 서류전형은 통과를 하고 2차 발표가 있었습니다. 예전에는 큰 강당에 발표하는 팀들을 다 모아놓고 발표 경연하듯이 하더니만 이제는 조그만 방에 큰 TV 에 파워포인터를 틀어놓고 발표하는 형식으로 바꼈습니다. 대중이 많은것을 싫어하는 분들에게는 좋은 기회일듯 합니다. 


  간만에 다시 발표를 하면서 느낀점은 '역시 열심히 설명해도 잘 모르시는구나' 라는 점입니다. 게다가 초청받은것으로 예상되는 분들의 질문도 기대 이하가 많아서 조금이라도 검색해보면 바로 나오는 내용을 어디선가 줏어 들은걸로만 판별하고 맞다고 주장하는 한심한 행동들도 서슴치 않고 하더군요. 


  이번 수행과제를 진행하면서 느꼈던 팁을 몇가지 적어볼려고 합니다. 


  1. 서류심사는 일반적으로 정부과제 수행할때 하듯이 최대한 자세하고 '양 많게' 가는 것이 좋습니다. 어려운 말을 주워 삼켜도 좋고 최대한 그럴듯 하게 만들면 좋습니다. 


  2. 투자 받는것과 비슷하겠지만 프로토 타입이 있으면 정말 정말 유리해집니다. 


  3. 1차 서류심사와 다르게 2차 발표는 이미지나 화면 위주의 작업을 하면 유리해집니다. 위원들이 특정 분야에 대해서 깊은 지식을 소유할 수가 없는 분들이라 기술 관련을 깊게 들어가면 절대 이해를 못합니다. 



  총 평을 하자면 1차는 기술 위주로 자세하게 쓰고, 2차는 일반인 상대로 설명한다 생각하시고 쉽고 이미지 위주로 발표하시면 좋은 소식이 있을 것입니다.




저작자 표시
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

VOIP 에 대한 개략 설명

Slide로 이동하기



Emacs 의 Org 모드를 이용해서 간단하게 제작한 Slide 이다. 추후에 KeyNote 버젼을 만들기 전 아이디어 정리 단계로 제작해 본 것이다.  



저작자 표시
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

클라우드 서비스의 종류

클라우드 서비스의 종류

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

그렇다면 클라우드의 종류인 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 를 추천합니다.





저작자 표시
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

[서평] 군주론 (Il principe)


니콜로 마키아벨리 지음 , 임명방 옮김


  인류사에서 회자 되는 유명한 책들, 바로 고전 이라고 합니다. 제 생각에 저는 나이대에 따라 고전을 읽을때마다 다르게 느껴졌습니다. 그런 고전중에 한가지가 바로 마키아벨리의 '군주론' 입니다. 


  군주론을 처음 접한 20대에서는 '마키아벨리즘'에 대한 선입견 때문에 공감을 하지 못했습니다. 그러나 40대에 접한 '군주론'은 남 다른 의미로 다가옵니다. 심지어 빠른 시일내에 다시 재독을 해야 겠다고 마음을 먹었습니다. 


  마키아벨리가 어떻게 해서 이런 사고방식을 하며 군주론을 쓰게 됐는지에 대한 견해를 레오폴트 폰 랑케의 말을 인용해서 쓴 역자(임명방)의 글이 인상 깊길래 서두만 가져와 봅니다. 


  "역사가 랑케는 한 시대의 역사적 사실을 받아들임에 있어, 독자가 처하고 있는 시대의 감각에서가 아니라 그 역사 현실이 발생한 그 시대의 감각, 그 시대성.정신상황.배경을 토대로 해석하고 이해해야 한다고 말했다. 이는 역사학에서뿐 만 아니라 모든 학문에 해당되는 중요한 암시라고 할 수 있다. 우리는 흔히 마키아벨리는 약육강식.권모술수.일인독재를 주장한 부정적인 면으로 접하기 쉬운데, 이런 위험성은 우리가 랑케의 말 그대로 마키아벨리가 생존했던 그 시대, 그 환경에 들어가 그를 봄으로써 극복할 수 있는 것이다."


  약해서 이리 치이고 저리 치이던 조국의 상황이 개탄스러운 상황에서 쓰여졌던 글이라는 것입니다. 


  다시 본 '군주론'은 제가 최근 팀을 운영하면서 느꼈던 점에 대한 명쾌한 해답을 주고 있어서, '역시 고전이구나' 라는 감탄을 했습니다. 그 내용은 '조언'에 관한 것입니다. 쉽게 말하자면 


  '조언이란 군주(리더)가 원할 때만 신하들 한다는 것입니다. 리더(군주)가 원하지 않을 때 하는 조언은 잔소리며 그러한 잔소리는 리더의 권위를 손상시킨다. 그렇다면 조언을 구하지 않는 리더(군주)란 모시고 있을 가치가 없는 리더(군주)란 이야기이고 그런 리더와 같이 일을 도모하기 쉽지 않다'


  전 이 글을 보고 사람들이 훌륭한 리더의 자질에 대해서 이야기들은 많이 하지만 훌륭한 동료의 자질에 대해서는 잘 이야기 하지 않는게 아닌가 라는 생각이 들었습니다. 그렇기에 그 옛날에 이런 내용을 깨달은 마키아벨리에 대한 존경심이 생겼습니다. 


  다시 읽어본 군주론은 마키아벨리에 대한 생각과 군주론 자체에 대한 이해를 달리하는 계기가 됐을 뿐 아니라 조직 문화라는게 옛날부터 내려오는 것과 아직까지 그리 많이 변하지 않는 내용을 담고 있다는 점이 놀라웠습니다. 고전은 필히 읽어봐야 한다고 생각하지만 그 중에서 회사생활을 하는 분이라면 군주론은 필독을 권합니다. 




저작자 표시
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

[서평] 아마존, 세상의 모든 것을 팝니다.

  브래드 스톤 지음, 야나 마키에이라 옮김 


  부제는 아마존의 캐치 프레이즈인 (the everythin store) 입니다. 표지는 부담스럽게 웃고 있는 제프 베조스의 정면 사진입니다. 사실 이런 류의 책을 좋아하지는 않습니다. 자서전에 관한 책들은 하나같이 비슷하기 때문입니다. 




  '비범한 사람이 비범한 생각을 해서 비범한 성공을 했다.' 


  제 생각은 사실 조금 다릅니다. '비범한 성공'을 했기 때문에 이런 책이 팔린다는 것이죠. 위키드(Wicked) 뮤지컬에서 유명한 넘버인 파퓰러(Popular) 노래 가사중에 '셀러브레이트 나 각국의 지도자들이 진짜 아는게 많고 영리한 거라고 생각하느냐? 웃기는 소리 단지 그들은 유명하기 때문이다' 라는 가사가 주는 여운을 좋아하기 때문인지 이런 분야에 대해서는 좀 시니컬 해지기 마련입니다. 


  책을 읽다보면 제프 베조스 스타일의 경영법은 많이 익숙한 방법일 것입니다. 어디선가 많이 봤죠! 바로 한국에서 입니다. 한국의 이사라는 직함을 달고 계신분들의 사고와 완전히 일치한다고 봅니다. 일정을 줄이고, 시끄럽고 내말이 맞고, 감정적으로 움직이고, 아끼지 말아야 할 부분에서 아끼고, 그런데 성공했잖아요? 그러니까 유명한게 된게 아닌가 하는겁니다. 보면서 느낀 생각은 우리나라 이사 (특히 영업 이사 스타일)들이 실리콘 밸리에 진출해서 과감하게 움직인다면 성공 가능성이 높은게 아닌가? 라는 생각을 하게 됩니다.


  처음 추천하신 분은 각각의 모든 이슈에 부딛혔을 때 제프가 어떻게 그 일을 해결했느냐에 대한 내용이 잘 쓰여져 있다고 했는데, 그런 내용보다 제프의 기행에 촛점이 맞춰진듯한 흐름이 보여집니다. 이런 악평에도 불구하고 제프의 장점은 있습니다. 


  - 결정된 것에 대한 과감한 진행

  - 각각의 상황에 맞게 알맞은 목표 수정 

  - 집중할 것에 대해서는 다른 모든 것을 제쳐두고 하는 집중도 


  정도가 눈에 띄는 군요. 보통 책이 아무리 두꺼워도 한 달을 넘긴적이 거의 없는데, 이 책은 완독하는데 무료 6개월이 걸렸습니다. 그 만큼 제 취향과는 동 떨어졌습니다. 추천하신 분과의 인연이 아니였으면 중간에 내던지고 싶은 적이 한 두번이 아니였습니다. 그래도 이제 끝을 냈기에 서평이라도 남깁니다. 




저작자 표시
신고
크리에이티브 커먼즈 라이선스
Creative Commons License