»
S
I
D
E
B
A
R
«
iMessage는 망 사업자들과의 공생을 추구한다(?)
Jun 11th, 2011 by Wegra Lee

지난주 WWDC에서 발표된 iOS5 신기능 중 하나인 iMessage는 카카오톡, 왓츠앱, 마이피플 등과 유사하게 무료로 문자/미디어를 주고 받을 수 있는 기능을 제공한다. 이 때문에 많은 이들이 기존 망 사업자들의 주요 수익원인 메시지 서비스에 치명적인 타격을 입힐 수 있는 무기로 받아들이는 듯 하다.

하지만 꼭 그럴까? 나는 iMessage의 동작 원리를 알고나니 조금 다른 생각을 해보게 되었다.

우선 현재의 시장 상황을 살펴보자.

앞서 언급한 다양한 무료 메시지 어플들이 범람하면서 기존 SMS/MMS 서비스는 이미 존패의 기로에 놓여 있다. 국내 가입자 수만 1천만이 넘어가면서 과반수 이상이 사용할 날도 그리 멀지 않았을 것이다. 때문에 사업자의 패키지 요금제에 있는 문자 서비스 요금이 이제는 끼워팔기 논란의 대상이 되기에 이르렀고, 망 사업자는 트래픽 유발의 주범으로 무료 메시지 서비스를 언급하는 등 다소 납득하기 어려운 대응을 보이기도 했다. 심지어 요즘은 사업자들 수스로 무료 메시지 서비스 구축에 나서고 있는 실정이다.

이렇듯 iMessage가 아니더라도 기존 SMS/MMS의 앞날은 점점 어두워져 가고 있었고, 회생의 기미도 딱히 보이지 않고 있다. 그대로만 놔둬도 고사될 위기인 것이다.

다음은 iMessage의 동작 방식기존 무료 메시지 애플리케이션들과의 주요 차이를 알아보겠다.

iMessage는 전혀 새로운 애플리케이션이 아니라, 기존 Messages라는 iPhone용 SMS/MMS 애플리케이션의 업그레이드판이다. 그래서인지 초기 early adopter 중에는 iMessage를 찾지 못하겠다고 언급한 사람도 있다. 즉, 한 애플리케이션이 SMS/MMS는 물론 무료 메시지 서비스까지 다 지원한다. 인터페이스도 달라지지 않았다. 그 UI 그대로 사용하다보면 상대방에 따라 SMS/MMS, 혹은 새로운 iMessage 기능을 자동 선택된다. 즉, 상대방도 iMessage를 사용할 수 있다면 iMessage로 보내지고, 그렇지 못하다면 일반 SMS나 MMS로 보내진다.

요약해보면 다음의 두 가지가 기존 무료 메시지 애플리케이션들과의 차이점이다.

  • iOS 기반 기기(iDevice)에 기본 내장되어 있다.
  • SMS/MMS 애플리케이션과 통합된 하나의 애플리케이션이다.

이는 다시, 다음과 같은 의미를 갖게 된다.

  • iDevice를 사용하는 모든 이들이 iMessage를 사용할 것이다.
  • 제2, 제3의 메시지 애플리케이션을 설치하고, 원하는 상대가 포함된 애플리케이션을 찾아 왔다갔다할 필요가 없다.
  • iMessage 하나면 휴대폰이 있는 모든 이들과 메시지를 주고 받을 수 있다. iDevice뿐 아니라, 다른 스마트폰, 심지어 피쳐폰 사용자들과의 메시지라도 전혀 문제될 것이 없다.

그렇다면 망 사업자 입장에서의 의미는 무엇일까?

  • SMS/MMS 애플리케이션(iMessage)의 활용도를 높이고 사용자들을 묶어둘 수 있다.
  • 일단 iMessage를 실행시킨 사용자는, 상대가 무료 메시지를 받을 수 있는 상황이 아니라는 것을 인식해도, 약간의 비용을 부담하고 그냥 SMS를 쓸 확률이 높다.

끝이다. 그리고 생각하기에 따라 상당히 큰 의미를 갖는다. 카카오톡과 같이 SMS/MMS와 완전 배타적인 서비스의 필요성을 감소시키고, 일원화된 built-in 애플리케이션 사용을 유도한다. 그 사용량 중상당 비중은 SMS/MMS 일 것이므로 여전히 수익을 얻을 수 있다.

물론 과거처럼 모든 이들이 SMS/MMS를 써야했던 시절만큼의 수익 보존은 불가능하다. 하지만 iMessage가 아니더라도 어차피 불가능한 상황으로 시장은 흘러가고 있었다. iDevice 사용자들의 비중이 너무 높을 경우 iMessage가 사업자에게 큰 타격을 입히겠지만, 애플이 현재와 같은 독자 전략을 계속 유지한다면 시장을 지배하기 힘들다. 지금처럼 일정 비율의 계속 유지하기만 하면 큰 성공인 셈이다. (참조: http://www.wegra.org/blog/?p=860)

사용자 입장에서도, 하나의 애플리케이션만으로 저렴한 비용만 부담하면서 세상 모든 사람과 메시지를 주고 받을 수 있게 된다.

카카오톡이 완전 무료라 해도 피처폰 사용자나 카카오톡이 없는 사람과는 기존 SMS/MMS를 쓸 수 밖에 없으므로, 아직까지는 반쪽짜리 서비스이다. 공정한 비용 비교를 하려면 ‘iMessage vs. 카카오톡 + SMS/MMS’가 되어야 한다. 안드로이드 등 멀티 플랫폼 지원이라는 이점 때문에 후자의 비용이 더 적게들 가능성이 농후하지만, 부담을 느낄 정도의 차이가 나는 사람의 비중은 많지 않을 것이고, 편의성면에서는 아무래도 통합 애플리케이션이 유리하기 때문에 호불호가 나뉠 것으로 보인다.

정리해보자.

iMessage는 퇴출 위기에 몰린 SMS/MMS 서비스와, 이를 몰아내고 새로운 주도권을 쟁취하려는 무료 메시지 서비스의 장점을 모은 혼합형의 모델을 제시하고 있다. 하나의 애플리케이션, 비교적 저렴한 비용에 가장 넓은 폭의 사용자들과 메시지를 주고 받을 수 있게 되었다. 극단적인 전쟁이 아니라 사용자와 망 사업자 모두에게 충분한 이점을 제공하여 공생할 수 있는 타협적인 방식이 아닐까 생각한다.

(물론 정확한 손익 계산은 다양한 시나리오 하에서 열심히 주판알을 굴려보아야 알겠지만.. ^^)

지속적 통합(Continuous Integration) 구성 사례
Jun 7th, 2011 by Wegra Lee

이번엔 지속적 통합 사례를 하나 정리해보겠다. (지속적 통합의 개념 설명은 이곳에..)

Components and Basic Workflows

이번에 구성해본 지속적 통합(CI) 환경의 구성 요소는 다음과 같다.

  • CI (Continuous Integration) 툴: IBM Rational Team Concert (RTC)
  • 소스 관리: IBM Rational Team Concert
  • 빌드 스크립트: Apache Ant
  • (참조) Apache Maven

비록 RTC라는 상용 툴을 사용하고는 있지만, 이 글에서 다루는 대부분의 내용은 개념적인 것이라, 다른 툴(예: Hudson, TeamCity, CruiseControl)을 사용할 때도 그대로 적용/응용할 수 있다.

전체 시스템을 그림으로 나타내면 대략 다음과 같다.

ci

RTC 서버의 다양한 기능 중, 여기에서는 소스 관리와 빌드 관리, 그리고 웹 UI 정도이다. 거시적인 작업 흐름은 다음과 같다.

  1. 개발자가 변경 내용(change-set)을 소스 저장소에 전달한다.
  2. RTC 서버의 빌드 모듈이 이를 인식해 적당한 빌드 엔진에 할당한다.
  3. 빌드 엔진은 소스 저장소로부터 빌드에 필요한 데이터를 내려 받아 Ant 빌드 스크립트를 수행한다.
  4. Ant 빌드 스크립트는 빌드를 수행하고 산출물을 개발 서버 및 API 서버에 배포한다.
  5. 빌드 엔진은 빌드 결과 및 과정은 빌드 서버에 알리고, 서버는 개발자 PC에 푸시한다.

개발자나 프로젝트 관련자들은 이런 모든 과정/결과를 언제든 전용 Eclipse UI나 Web UI를 통해 확인할 수 있다.

또한, 어떤 빌드 엔진을 사용할 지, 어떤 스크립트를 사용한 지 등은 모두 configuration 가능하다.

Project Directory Layout

여러 팀, 다양한 과제에 걸쳐 일을 효율적으로 진행하려면 프로젝트 구성부터 일관적으로 유지하는 것이 좋다.

Ant는 비록 산업 표준 빌드 툴이지만, 프로젝트 구성에 대한 표준 규약은 제공하지 않는다. 때문에 담당자 취향만큼이나 다양한 구성이 존재하며, 그 구성을 정하고 관리하는데에만 상당한 고뇌와 노력이 소요된다. 그리고 재활용도 쉽지 않다. 바로 이 문제를 타파하고자 나온 오픈소스 프로젝트로 Maven이란 것이 존재한다. Maven 개발자들은 프로젝트의 구성에 관련된 모범 사례(best practice)들을 집대성하고자 하였다. 무분별한 컨피규레이션 허용보다는 잘 정의된 모범 사례를 따른는 것을 원칙으로 삼은 것이다(Convention over Configuration). 물론 그 결과가 이상적으로 완벽하진 않지만, 상당수의 프로젝트에 적용하는데 큰 무리가 없을 것이다.

어쨌든, 본 예제에서는 Ant를 사용하지만 Maven의 이상과 결과를 상당부분 따르고 참조할 것이다. 물론 Ant이기 때문에 언제든 어렵지 않게 수정 가능하다.

그래서 내가 구성한 기본 구성은 다음과 같다.

  • src/main/java – 제품 소스 코드
  • src/main/resources – 제품에 포함될 리소스
  • src/main/config – 제품 설정 정보
  • src/main/webapp – 웹 애플리케이션 소스
  • src/test/java – 테스트 소스 코드
  • src/test/resources – 테스트에 필요한 리소스
  • lib/main – 제품 수행에 필요한 라이브러리
  • lib/test – 테스트에 필요한 라이브러리 (junit, mokito  등)
  • tools – 팀내 공용 툴 (예: FindBugs, CheckStyle, Code Pro Analytix 등)
  • build.xml – Ant 빌드 스크립트
  • build.properties – Ant 빌드 스크립트용 커스텀 프로퍼티 파일
  • build-jazz.xml – RTC/Jazz용 빌드 스크립트(build.xml을 확장함)
  • LICENSE.txt – 제품 라이선스 정보
  • README.txt – readme 파일

참조함 Maven의 표준 디렉터리 구성과 크게 다르지 않다. 간소화를 위해, 크게 필요 없다고 생각되는 filters, assembly, site, NOTICE.txt 를 제거하였고, lib과 tools가 추가되었다.

lib이 추가된 이유는 Maven이 종속성 자동 관리 기능이 포함된데 비해 Ant는 직접 필요할 라이브러리를 관리해야 하기 때문이며, tools 는 개발팀 내 함께 쓰는 유용한 도구와 그 설정 정보를 공유하기 위함이다.

빌드 스크립트는 총 3개의 파일로 구성된다. build.xml 은 메인 빌드 스크립트이며, build.properties에는 그 중 사용자 정의 속성을 담아, 상황에 맞게 설정하여 빌드할 수 있게 하였다. 마지막의 build-jazz.xml 은 build.xml을 확장(import)하여 RTC/Jazz에 종속된 기능을 추가로 수행하기 위해 추가하였다. 즉, build-jazz.xml를 제외한 두 파일은 RTC/Jazz와 완전히 독립적이어서 어떤 환경에서건 그대로 재활용할 수 있다.

스크립트의 속 내용은 조금 후에 살펴보기로 하고, 빌드 과정에서 생성되는 디렉터리 레이아웃에 대해서 먼저 살펴보자.

  • target/classes – 제품 소스를 컴파일한 클래스 파일들 & 리소스
  • target/test-classes – 테스트 소스를 컴파일한 클래스 파일들 & 리소스
  • target/reports/unit-test – 단위 테스트 결과 리포트 (XML 포맷)
  • target/reports/unit-test/html – 단위 테스트 결과 리포트 (HTML 포맷)
  • target/reports/integration-test – 통합 테스트 결과 리포트 (XML 포맷)
  • target/reports/integration-test/html – 통합 테스트 결과 리포트 (HTML 포맷)
  • target/reports/findbugs – FindBugs 수행 결과 보고서
  • target/reports/checkstyle – CheckStyle 수행 결과 보고서
  • target – 빌드 산출물 루트 겸, package 된 제품 바이너리 등 최종 산출물

특별한 설명은 필요 없으리라 본다. 그렇다면 이제 Ant 빌드 스크립트의 내용과 빌드 단계에 대해 알아보기로 하자.

Ant Build Script and Build Lifecycle

Ant 빌드 스크립트는 빌드 타깃(target)과 타깃간 종속성(선행 타깃 정의)과 타깃에서 실행해야할 실제 작업을 정의한다. 빌드 라이프사이클 역시 Maven의 그것을 기반으로 간소화한 후 약간 보강하였다. 다음은 build.xml에 정의된 타깃들을 라이프사이클에 따라 설명한 것이다.

  1. compile – 제품 소스 코드를 컴파일한다.
  2. test-compile – 테스트 코드를 컴파일한다.
  3. unit-test – 단위 테스트를 수행한다.
  4. package – 제품 컴파일 결과를 배포 형태로 패키징한다.
  5. integration-test – 통합 테스트를 수행한다.
  6. code-analysis – 정적 코드 분석을 수행한다. (FindBugs, CheckStyle)
  7. deploy – 패키징한 결과를 개발 서버 및 API 서버로 배포한다.

몇 가지만 살펴보겠다.

먼저, code-analysis가 Maven에 없는 새로 추가된 단계이다. 이 단계에서는 FindBugs, CheckStyle 등의 정적 코드 분석 툴을 이용하여 제품 소스 코드의 잠재적 결함과 코딩 규약 부합 여부를 검사한다. code-analysis 단계 외에는, 실패 시 다음 단계를 계속 진행할 수 없다.

unit-test 단계에서는 수행시간이 짧은 단위 테스트들을 실행한다. 통합 테스트 케이스와 시간이 오래 걸리는 테스트 등은 뒷쪽의 integration-test 단계에서 수행시킨다.

마지막 deploy 단계에서는 완성된 바이너리를 개발 서버로, 최신 API 문서를 API 서버로 배포한다.

변경 가능한 사용자 속성으로는 다음과 같은 것들이 있다.

  • product.name  - 제품명
  • product.version – 제품 버전
  • main.class – 실행 클래스명: jar 파일의 Manifest 파일에 추가됨
  • compile.deprecation – javac 컴파일 옵션
  • compile.debug – javac 컴파일 옵션
  • compile.optimize – javac 컴파일 옵션
  • compile.source – javac 컴파일 옵션
  • compile.target – javac 컴파일 옵션
  • proxy.host – 프락시 주소 (프락시 안에 갖힌 네트워크에서 수행될 때)
  • proxy.port – 프락시 포트 (프락시 안에 갖힌 네트워크에서 수행될 때)
  • deploy.binary.host – 패키징된 바이너리를 배포할 호스트 주소
  • deploy.binary.user – 호스트 로그인 계정
  • deploy.binary.passwd – 호스트 로그인 패스워드
  • deploy.binary.keyfile – 호스트 로그인에 필요한 key 파일 위치 (xxx.pem)
  • deploy.binary.dir – 바이너리를 복사해 넣을 호스트 내의 디렉터리 경로
  • deploy.api.host – 최신 API를 배포할 호스트 주소
  • deploy.api.user – 호스트 로그인 계정
  • deploy.api.passwd – 호스트 로그인 패스워드
  • deploy.api.keyfile – 호스트 로그인에 필요한 key 파일 위치 (xxx.pem)
  • deploy.api.dir – 바이너리를 복사해 넣을 호스트 내의 디렉터리 경로 (웹 서버 혹은 파일 서버)

보는 바와 같이 소스 코드 디렉터리 구조, 산출물 파일 이름과 같은 정보는 따로 설정할 수 없도록 제안하고 있다. 이유는 초반에 언급한 Maven의 설계 원칙(Convention over Configuration)을 좀 더 강요하기 위함이다.

물론 build.xml의 내용을 보면 관련 정보를 속성으로 제공하여, 꼭 필요한 경우 쉽게 변경할 수 있다.

마지막으로 build-jazz.xml 파일을 살펴보자.

이 파일은 build.xml 을 확장하여 RTC/Jazz 빌드 서버에서 사용할 특화 타깃을 정의하고 있다. RTC/Jazz 빌드 기능에 특화된 만큼, 이 스크립트를 개발자 IDE에서 실행하려 하면 필요한 파일이 없다면서 에러를 발생시킬 것이다. 물론 몇 가지 설치/설정으로 가능케할 수 있지만, 별다른 이점은 없으니 Jazz 빌드 서버에 맡기기로 하자.

기본적으로는 다음의 네 가지 타깃이 제공된다.

  • package-jazz – build.xml의 package 단계까지 수행한 후, 산출물과 보고서를 RTC/Jazz에 등록한다. 단위 테스트 보고서와 패키징된 바이너리가 이에 포함된다.
  • integration-test-jazz – build.xml의 integration-test 단계까지 수행한 후, 산출물과 보고서를 RTC/Jazz에 등록한다. 위 결과에 통합 테스트 결과가 추가된다.
  • code-analysis-jazz – build.xml의 code-analysis 단계까지 수행한 후, 산출물과 보고서를 RTC/Jazz에 등록한다. 위 결과에 정적 코드 분석 보고서가 차가된다.
  • deploy-jazz – 최종 단계인 deploy까지 수행한 후, 산출물과 보고서를 RTC/Jazz에 등록한다.

특별히 위와 같은 네 단계만 정의한 이유는 잠시 후 Build Definitions 절에서 확인할 수 있다. 그 전에 정적 코드 분석(static code analysis) 단계에서 무엇을 하는지 살짝 알아보고 가기로 하자.

Static Code Analysis

앞서 살펴본바와 같이, unit-test와 package 단계 사이에 code-analysis 라는 단계가 추가되었다. 이는 Maven에도 정의되어 있지 않은 단계이다. 이 단계에서는 제품의 소스 코드를 분석하여 잠재적인 결함과, 코딩 규약 준수 여부를 확인한다.

쉽게 활용할 수 있는 오픈 소스 툴들로는 FindBugs와 CheckStyle, PMD 등이 있다. (기능면에서 CodePro Analytix가 가장 마음에 드나, 아쉽게도 Ant용 task를 제공하지 않아 여기서는 제외하였다.)

FindBugs는 버그 패턴 위주로 거의 100% 적중률로 문제를 분석해주며, CheckStyle과 PMD는 그 외에도 코딩 규약, 유사 코드 검색 등 다양한 기능을 제공한다. CheckStyle과 PMD 는 기능면에서 상당히 겹치기 때무에 둘 다 사용할 필요는 없다. 나는 PMD를 더 선호하였지만, 최근에 업그레이드가 이루어지지 않고 있어 CheckStyle로 선회하였다.

참고로, 이들 툴을 지속적 통합 프로세스의 일부로 등록해놓는 것은 좋은 생각이긴 하지만 IDE에 통합하여 개발자들이 수시로 확인해보는 것에 비할 바가 못된다. 다행히 CodePro Analytix를 포함하여 위의 모든 툴들은 Eclipse 플러그인을 제공하고 있다.

관련하여 Java 코딩 규약 관리 방법 역시 참고가 될 것이다.

Build Definitions

빌드 정의(Build Definition)는 빌드에 필요한 각종 정보와 수행 조건 등을 담는다. 예를 들어, 빌드에 사용할 파일(build-jazz.xml)명, 타깃, 빌드 스케줄 등이 그것으로, 프로젝트 특성에 맞는 다양한 전략을 수립할 수 있다. 상세 내용은 본 글의 주제와 크게 관련 없으니  지나치도록 하겠다.

어쨌든 Jazz의 빌드 서버는 이 정의를 바탕으로 빌드 엔진에 빌드를 요청한다. 아래의 그림은 내가 구축하기 원하는 빌드 전략이다.

schedule

그리고 위의 전략을 구현하기 위해 다음과 같은 네 가지의 빌드 정의를 작성하였다.

  1. Continuous: 변경 사항에 대한 빠른 피드백을 목적으로, 컴파일/단위 테스트/패키징 성공 여부까지 확인한다.
    1. 빌드 주기: 매 5분
    2. 빌드 타깃: package-jazz
  2. Integration: 더 많은 시간이 소요되며 다양한 테스트를 수행하는 통합 테스트까지 수행한다.
    1. 빌드 주기: 매 1시간
    2. 빌드 타깃: integration-test-jazz
  3. Nightly: 일별 snapshot을 만들어, 매일 아침 baseline을 생성한다.
    1. 빌드 주기: 월~토요일 3:00 AM
    2. 빌드 타깃: code-analysis-jazz
  4. Weekly: 주간 변경 내용을 종합 검증하여 baseline을 생성하고, 개발 서버에 배포한다.
    1. 빌드 주기: 매주 일요일 3:00 AM
    2. 빌드 타깃: deploy-jazz

Jazz 빌드 서버는 위의 네 가지 빌드 정의에 기반해, 자동으로 빌드/테스트/배포를 수행하며, 그 결과를 개발자에게 알려주게 된다.

Summary

이상으로 빌드 시스템의 거시적인 구성부터 빌드 단계 정의, 빌드 정의를 통한 지속적 빌드 전략 수립까지 구성해 보았다.

다소 이론적인 면에 집중하여 설명하였지만, 상세 내용으로 들어가면 내용이 너무 길고 장황해지니 양해 바란다.

(관련 Ant 빌드 스크립트는 약간 다듬어서 추후 업데이트하겠음)

»  Substance: WordPress   »  Style: Ahren Ahimsa