Mobile Convergence

나는 전규현님의 블로그 포스팅을 관심있게 읽고 있는 독자이다. 패키지SW 개발을 7년 넘게 해보면서 느꼈던 모순과 방황에 대한 원인과 솔루션을 잘 설명해 주고있기 때문이다. 최근 지인들과 모여서 새로운 모바일 서비스를 기획하면서 어떤식으로 진행을 하고 어떤 시스템들이 필요할지 그리고 어떤 형태로 운영을 할지 고민을 하고 있다. 그 좋은 해답을 해당 블로그에서 이야기 해주고 있다. 

• 소스저장소, 이슈, 위키, 프로젝트관리 :  http://softwaredev.tistory.com/297
• 소스저장소 : Git onDemand : BitBucket
• 이슈 : Jira onDemand
• 위키 : Confluence onDemand
• 스크럼 도구: GreenHopper onDemand (추가)
• 프로젝트 관리 : Podio onDemand (추가)
• SVN or Git 어느 것을 쓸것인가 :  http://softwaredev.tistory.com/238
• 분산환경에서 일할 경우 : Git Repository

AWS의 Ubuntu 시스템에 ftpd를 설치하는 방법. 구글링하면 너무 많은 정보가 있으므로 좋은 사이트 몇개 링크함

1) 설치 기본 : sudo 설치 방법. https://help.ubuntu.com/10.04/serverguide/ftp-server.html

2) 설정 상세 : 설정에 대한 한글 상세 설명. http://community.365managed.com/10759

JBoss를 curl로 받으려고 하는데 마땅한 곳이 없다. 어디 없을까?

모바일 컨버전스 서비스를 기획하면서 가장 헤메이는 부분이 대용량 데이터에 대한 신뢰성 있는 아키텍쳐를 구축하는 일이다. 이미 대형 포털과 모바일 서비스에서 많은 아키텍쳐 연구를 통하여 최적화를 했겠지만 이를 전수받거나 아니면 뼈대를 살표보는 일은 쉽지 않다. 그러나 AOSA(The Architecture of Open Source Applications) 라는 외국 사이트에서 이에 대한 단초를 제공하고 있고, 네이버 HelloWorld에서 일부 번역한 내용이 있어서 공부를 시작해 본다.

  - AOSA : http://www.aosabook.org/en/index.html

  - Naver 번역 :  http://helloworld.naver.com/helloworld/206816

스토리는 개인, 기업(조직), 소프트웨어, 서비스 모두에 필요한 초기단계의 전략과도 같다. 스토리가 없으면 재미가 없다. 앙꼬없는 찐빵을 무슨 맛으로 먹으랴. 소프트웨어쪽으로 눈을 돌리면 처음 이 제품을 만들게 된 동기가 있어야 한다. 동기를 유발한 사건이 있고 그 사건의 해결방안을 소프트웨어적으로 아니면 컨버전스적으로 해결 할 수 있는 생각의 흐름 또는 프레임을 가지고 있다면 좋은 아이디어가 나오지 않을까?

오늘 읽은 조성문님의 "스토리가 중요한 이유"를 읽고 많은 것을 생각하게 되었고, 생각을 스토리로 만들어 표현하는 훈련이 필요함을 느낀다.

그동안 간간히 트윗되는 서비스 기업들의 아키텍쳐를 살펴보면서 향후 비슷한 서비스를 할 때 어떤 요소 기술들이 필요할까 생각해 보았다.

  - Netflix : 온라인 VOD 서비스 Netflix의 AWS로 옮겨가기 까지의 아키텍쳐 변화 (Java 기반)

  - Evernote : 자바 기반 아키텍쳐링 (Hibernate를 사용했다는 것이 흥미롭다, 참조)

  - Instagram : SytleShare와 비슷한 구조인듯 하다 그리고 좀 더 세심한 아키텍쳐링  (Python 기반)

  - StyleShare : AWS에서 어떤 서비스를 사용하는지 설명 (Python  기반)

  - Etc Search :  http://highscalability.com

향후 만들어갈 Mobile Service에 대해 Netflix 모델과 더불어 기업문화까지 본받을 필요가 있겠다. 자신의 성숙한 기술을 OSS로 공개하고 공유하는 정신을 높게 사고 싶다.

 모바일 컨버젼스 서비스를 만들기 위하여 어떤 단계를 거쳐가야 하는지 생각해 본다. 

  - Big Picture : 서버(미들웨어) 아키텍쳐를 서비스의 요구조건에 맞게 고려한다

  - Framework Picture : 어플리케이션 레벨의 구현에 필요한 Framework들을 고려한다 

  - Project Picture : 프로젝트를 어떻게 진행할 것인지 고려한다.

  - 클라우드 서비스 이용하기 : AWS Pacific zone 이용하기 (각 서비스에 대한 이해와 사용경험을 가져야 한다)

  - 미들웨어 선정 : 현재는 Virgo 위에 Tomcat + SpringDM 사용 예상 (OSGi Bundle 이용)

  - 메모리 캐싱 : Redis를 고려해 보고 있다. 역시 설치와 테스트가 필요하고 어느 부분에 쓰일지도 검토해야 한다)

  - 프레임워크 : 

    + 통신용 프레임워크는 Vert.x 를 Bundle로 올려서 NIO 처리 (apache 대체로 생각하지만 각 필요한 요구조건에 대한 테스트가 필요하다)

    + 도메인 업무처리용 프레임워크는 Spring Roo를 통해 빠르게 개발을 진행하고 싶다 

  - 데이터베이스 : RDBMS를 고려한다면 MySQL, NoSQL을 본다면 Cassandra와 MongoDB를 사용하려 한다. 

  - 상호 연결 : Apache Trift를 통하여 서로 틀린 부분에 대한 Communication을 해소하려 한다 (ESB와 비슷하게 이용 가능할까?)

  - 클라이언트 Push : Vert.x의 Socket.io를 이용한다

  - 모니터링 : Netflix의 오픈소스를 이용하거나 필요시 별도로 만든다

  - 개발, 테스트, 배포 : 운영서버와 유사한 AWS 클라우드 기반으로 가져가며 AMI(Amazone Machine Image)를 이용하여 만들고, 개발, 테스트, 배포 각각 별개의 인스턴스를 가져간다

    + 개발 : 운영과 동일 환경구성

    + 테스트 : JUnit 단위 테스트는 개발단계에서 수행하고, FitNeese 통하여 인수테스트 수행등 종합적인 테스트 방안을 마련한다

  - UI Layer : 하이브리드 웹앱으로 가고, 성능향상이 필요한 부분이 있다면 고객 확보시점에 따라 네이티브로 간다. Rapid Development를 위하여 선택

  - UI Framework : Sencha Touch, JQuery Mobile, PhoneGap등을 사용, PC 버전은 Sencha의 ExtJS를 사용한다. Unit Test와 개발환경때문에 GWT를 고려해 보았으나, 기초장벽을 어느 정도 해소하면 ExtJS로 하는 것이 좋겠다는 판단임 (요즘 열심히 JavaScript 파고 있다)

  - Server Framework : Vert.x, Spring, Spring roo 등을 사용할 예정

  - Test Framework : JUnit, FitNeese

  - Deploy : Maven 또는 Gradle 고려중, Jenkins + HuBot (GTalk 통하여 deploy 명령) 사용

  - Open API 지향 설계 : Restful 서비스 

- Issue, Wiki 는 Atlassian의 Jira와 Confluence를 SaaS로 이용

  - Scrum 방식 개발위해 Atlassian GreenHopper 이용

  - 소스서버는 DVC로 GitHub private 신청하여 이용

  - 오프라인 정기 모임

  - 온라인 협업 도구 최대하 활용 : Atlassian 제품, Podio, CaCao Agit, GMail 등