»
S
I
D
E
B
A
R
«
Remove Duplications : Master Method
Nov 29th, 2009 by Wegra Lee

이번엔 널리 알려져서 누구나 다 알고 있을법한 (하지만 의외로 안지키는 사람도 많은) 방법을 소개한다.

Problems & Constraints

  1. 메서드를 오버로딩 해야한다.
  2. 입력 인자의 타입은 동일하며 그 유무만이 다르다.
    e.g.> doSomething(a, b) and doSomething(a, b, c)

Solution

가장 많은 인자를 받는 메서드를 Master Method 로 정하고, 다른 메서드에서는 부족한 인자를 default 값으로 채워 Master Method 를 호출한다. 생성자(constructor) 구현 시에도 동일한 규칙이 적용된다.

Examples

int read(byte[] buf)
{  .. // tens of lines
}

int read(byte[] buf,  int offset, int length)
{  .. // tens of lines
}

위에서 첫 번째 메서드는 두 번째 메서드의 특수한 형태로, offset 을 0으로, length 를 buf 의 size 로 해서 호출한 것과 완벽히 동일하게 동작한다. 따라서 첫 번빼 메서드는 아래와 같이 구현할 수 있다.

int read(byte[] buf)
{ return read(buf, 0, buf.size); // redirect to Master Method with appropriate parameters
}

Notes

Master Method 는 코드 중복 최소화 외에도, 오버로딩된 메서드들을 가지고 있는 클래스를 상속할 때 개발자 실수를 최소화 시킬 수 있다는 장점도 있다. 예를 들어, 오버로딩된 메서드 a, b, c 를 정의하고 있는 클래스 A 가 있다. 이 때 이를 상속한 클래스 B 에서 기능을 약간 변경하고자 할 때, Master Method 가 없다면 메서드 a’, b’, c’ 를 잊지 말고 모두 정의해줘야 한다. 실수로 무엇 하나를 빼먹었다면 의도치 않은 동작을 하게될 것이고, 그 원인을 찾기는 쉽지 않을 것이다. 하지만 만약 a 가 Master Method 였다면, a’ 만 재정의하면 문제를 미연에 예방할 수 있다. 따라서 Master Method 를 정하고, 어느 메서드가 Master 인지 명시하는 것이 좋다.

또, C++ 의 경우 Google 은 default parameter 를 흉내낼 목적으로는 사용하지 말기를 권고한다[4]. 그 단점을 아래와 같이 기술하고 있으니 참조하기 바란다.

One reason to minimize function overloading is that overloading can make it hard to tell which function is being called at a particular call site. Another one is that most people are confused by the semantics of inheritance if a deriving class overrides only some of the variants of a function. Moreover, reading client code of a library may become unnecessarily hard because of all the reasons against default function parameters.

If you want to overload a function, consider qualifying the name with some information about the arguments, e.g., AppendString(), AppendInt() rather than just Append().


References

  1. Recommended Sequence for Refactoring (wegra.org)
  2. Remove Duplications : God Method (wegra.org)
  3. Remove Duplications : Convert & Redirect (wegra.org)
  4. Google C++ Style Guide : Function Overloading (Google)
Remove Duplications : Convert & Redirect
Nov 26th, 2009 by Wegra Lee

계속해서 Recommended Sequence for Refactoring[1] 의 가장 첫 단계인 Remove duplications 에 적용할 수 있는 리펙토링 기법 하나를 더 소개한다. 먼저 소개한 God Method[2] 와는 얼핏 유사한 상황 같지만 분명한 차이가 있다.

Problems & Constraints

  1. 복수의 동일 목적 함수가 입력 인자의 타입만이 다르다.
  2. 입력 인자들 사이에선 서로 타입 변환이 가능하다. 즉 값(value)은 같으나 표현 형태만 다르다.

Solution

하나의 마스터 함수만 구현은 유지하고, 다른 함수들은 받은 입력의 타입만 변화시켜 마스터 메소드를 호출한다.

Examples

다음의 두 함수는 다른 입력을 받지만 목적은 같다.

toDate(long  timestamp)
{  .. // tens of lines
}

toDate(DateTime dateTime)
{  .. // tens of lines
}

long 타입의 timestamp 를 DateTime 으로 변환시켜 (convert) Date 용 함수를 호출한다.

toDate(long timestamp)
{  DateTime dateTime = new DateTime(timestamp); // convert
return ConvertDateTimeToServerDate(dateTime); // then, redirect
// no more duplicated lines
}

toDate(DateTime dateTime) // master method
{  .. // tens of lines (unchanged)
}


References

  1. Recommended Sequence for Refactoring (wegra.org)
  2. Remove Duplications : God Method (wegra.org)
Yet Another iPhone Application Programming Lecture
Nov 26th, 2009 by Wegra Lee

아이폰의 열풍이 계속되면서 또 다른 아이폰 프로그래밍 공개 강의[1]가 개설되었다.

이미 Stanford 의 강의[2]를 (아주 감명깊게) 들은 바 있어서 신섬함은 좀 부족하지만, 시간차가 있는만큼 새로운 정보도 얻을 수 있을 것 같아 이번 강의도  쭉 지켜보려 한다.

두 강의 모두 iTunes U [3] 를 통해 서비스되고 있다. iTunes U 에는 여러 대학들이 참여하여 품질 높은 강의/교육 컨텐츠들을 쏟아붇고 있으니 꼭 한 번 둘러보길 권한다. iPhone/iPod touch 없이도 PC 에서 iTunes 소프트웨어만 설치하면 모든 자료를 무료로 이용할 수 있다.


References

  1. [iTunes U] iPhone Application Programming – WS 2009/2010 (Prof. Jan Borchers, RWTH Aachen Univ.)
  2. [iTunes U] iPhone Application Programming (Prof. Evan Doll and Alan Cannistraro, Stanford Univ.)
  3. iTunes U
The Story of Google in China
Nov 26th, 2009 by Wegra Lee

간만에 멋진 강의[1]를 하나 듣게 되어서 공유한다.

구글의 중국 연구소장인 Kai-Fu Lee 가 중국에서의 Google 의 전략에 대해 소개하는 동영상으로, 미국과는 너무 다른 중국 시장의 특징, 그 안에서 살아남기 위한 적응과 차별화.. 하지만 절대 변하지 않는 성공 철학 등을 이야기한다. 수많은 좋은 이야기들 중 한 슬라이드를 밝췌해보았다.


2006 Build foundation :

  1. People first : build world-class team by attracting the very best
  2. Real R&D Center fully empowered to innovate for China & world

2007-2008 +Demonstrate growth :

  1. Best Chinese search : #1 pillar for Google with real value to users
  2. China products designed by Chinese, for Chinese users
  3. Partner extensively with complementary industry leaders
  4. Market share and profit will follow

Before 7006 (오타 아님 ^^ 동영상을 보면 이유를 알 수 있다.)

  1. Organize all of the information in China
  2. Become the most popular, successful, useful service in China

기본을 충실히 하면서 현지화를 고객을 잘 파악하면 점유율과 이윤은 자연히 따라온다는 철학을 엿볼 수 있다. 말로는 인재제일을 외치지만 1명의 훌륭한 인재가 10만 명을 먹여살린다 믿고 개발자들을 소품/노동자 취급하는 모 회사와는 대조적이다.

위 각각의 항목들에 대한 자세한 내용들이 모두 다뤄지니 강의를 꼭 들어보길 적극 추천한다.

번외로.. 강의를 들어보면 중국의 문화가 한국과 상당히 유사함을 알 수 있는데, 구글 코리아 사람들도 (아직 보지 못했다면) 한 번씩 봐둘만한 자료라 생각된다.


References

  1. [iTunes U] The Story of Google in China – Carnegie Mellon, School of Computer Science (about 1 hour)
Remove Duplications : God Method
Nov 25th, 2009 by Wegra Lee
1.1. Problems & Constraints복수의 유사 목적 함수가 존재하고 구현 로직이 거의 동일하다. 극히 일부만 다른 코드가 여러 함수에 중복되어 있어, 향후 로직/결함 수정 시 human error 를 유발시키기 쉽다.입력 인자 중 일부가 서로 베타적이어서 하나로 합쳐서 제공하거나, 하나의 함수에서 다른 함수를 직접적으로 호출할 수 없다.Public API 가 이미 고정되어 있어, 서로 다른 인자들을 묶는 공통 타입을 만들고 함수들을 하나로 통합시키는 방법을 사용할 수 없다.혹은, 공통 타입이 존재하나 그 중 일부에 대해선 아무런 지원 계획이 없어, 이를 명확히 알리기 위해 복수의 독립적인 API 를 제공하고 싶다.1.2. Solution하나의 God Method(모든 상황에 필요한 인자의 합집합 받으며, 입력 조합에 반응하여 동작함)을 ‘내부’에 두고, 공개 메서드에서는 인자를 적절히 조합하여 이 God Method 를 호출한다.1.3. CautionsGod Method 는 하나의 기능에만 특화된 메서드에 비해 로직이 복잡하므로, 일반적인 경우에는 지양해야할 어프로치다.’중복량 vs. 복잡도 증가’ 를 잘 판단하여 적용 여부를 결정해야 하며, 적용하더라도 내부(private) 메서드에 한정 것이 좋다.1.4. Example아래의 세 함수들은 입력 인자 중 하나만이 다르며, 구현에서도 총 70라인 중 단 한 라인(CreateHttpRequestN 호출부)만이 다르다.DoSomething(..){       ..requestString = CreateRequestString(.., null, null,  ..);..}DoSomething(Circle circle, ..){       ..requestString = CreateRequestString(.., null, circle,  ..);..}DoSomething(Rectangle rectangle, ..){       ..requestString = CreateRequestString(.., rectangle, null,  ..);..}CreateHttpRequestN 함수에 필요한 모든 인자를 받아들이니 God Method 를 만들어 구현을 하나로 모은다.DoSomething_God // 새로 추가된 God Method(       Rectangle rectangle, Circle circle, ..){       ..requestString = CreateRequestString(.., rectangle, circle,  ..); // 받은 인자를 bypass..}DoSomething(..){       // 전후 중복 라인 사라짐return DoSomething_God(null, null,  ..); // God Method 호출}DoSomething(Circle circle, ..) const{return DoSomething_God(null, circle,  ..);}DoSomething(Rectangle rectangle, ..) const{return DoSomething_God(rectangle, null,  ..);}God Method 를 자세히 보면, public API 와 달리, Rectangle 와 Circle 인자를 포인터로 받고 있다. 이는 Rectangle, Circle 중 아무것도 사용하지 않는 메서드를 포용하기 위해서이다.
Problems & Constraints
복수의 유사 목적 함수가 존재하고 구현 로직이 거의 동일하다. 극히 일부만 다른 코드가 여러 함수에 중복되어 있어, 향후 로직/결함 수정 시 human error 를 유발시키기 쉽다.
입력 인자 중 일부가 서로 베타적이어서 하나로 합쳐서 제공하거나, 하나의 함수에서 다른 함수를 직접적으로 호출할 수 없다.
Public API 가 이미 고정되어 있어, 서로 다른 인자들을 묶는 공통 타입을 만들고 함수들을 하나로 통합시키는 방법을 사용할 수 없다.
혹은, 공통 타입이 존재하나 그 중 일부에 대해선 아무런 지원 계획이 없어, 이를 명확히 알리기 위해 복수의 독립적인 API 를 제공하고 싶다.
Solution
하나의 God Method(모든 상황에 필요한 인자의 합집합 받으며, 입력 조합에 반응하여 동작함)을 ‘내부’에 두고, 공개 메서드에서는 인자를 적절히 조합하여 이 God Method 를 호출한다.
Cautions
God Method 는 하나의 기능에만 특화된 메서드에 비해 로직이 복잡하므로, 일반적인 경우에는 지양해야할 어프로치다.
‘중복량 vs. 복잡도 증가’ 를 잘 판단하여 적용 여부를 결정해야 하며, 적용하더라도 내부(private) 메서드에 한정 짓는 것이 좋다.
Example
아래의 세 함수들은 입력 인자 중 하나만이 다르며, 구현에서도 총 70라인 중 단 한 라인(CreateHttpRequestN 호출부)만이 다르다.
DoSomething(..)
{       ..
requestString = CreateRequestString(.., null, null,  ..);
..
}
DoSomething(Circle circle, ..)
{       ..
requestString = CreateRequestString(.., null, circle,  ..);
..
}
DoSomething(Rectangle rectangle, ..)
{       ..
requestString = CreateRequestString(.., rectangle, null,  ..);
..
}
CreateHttpRequestN 함수에 필요한 모든 인자를 받아들이니 God Method 를 만들어 구현을 하나로 모은다.
DoSomething_God // 새로 추가된 God Method
(       Rectangle rectangle, Circle circle, ..)
{       ..
requestString = CreateRequestString(.., rectangle, circle,  ..); // 받은 인자를 bypass
..
}
DoSomething(..)
{       // 전후 중복 라인 사라짐
return DoSomething_God(null, null,  ..); // God Method 호출
}
DoSomething(Circle circle, ..) const
{
return DoSomething_God(null, circle,  ..);
}
DoSomething(Rectangle rectangle, ..) const
{
return DoSomething_God(rectangle, null,  ..);
}
God Method 를 자세히 보면, public API 와 달리, Rectangle 와 Circle 인자를 포인터로 받고 있다. 이는 Rectangle, Circle 중 아무것도 사용하지 않는 메서드를 포용하기 위해서이다.

지난달 포스팅한 Recommended Sequence for Refactoring[1] 의 가장 첫 단계인 Remove duplications 에 적용할 수 있는 리펙토링 기법이다.

곧 한 두개의 기법이 추가로 뒤따를 예정이다.

Problems & Constraints

  1. 복수의 유사 목적 함수가 존재하고 구현 로직이 거의 동일하다. 극히 일부만 다른 코드가 여러 함수에 중복되어 있어, 향후 로직/결함 수정 시 human error 를 유발시키기 쉽다.
  2. 입력 인자 중 일부가 서로 베타적이어서 하나로 합쳐서 제공하거나, 하나의 함수에서 다른 함수를 직접적으로 호출할 수 없다.
  3. Public API 가 이미 고정되어 있어, 서로 다른 인자들을 묶는 공통 타입을 만들고 함수들을 하나로 통합시키는 방법을 사용할 수 없다.
  4. 혹은, 공통 타입이 존재하나 그 중 일부에 대해선 아무런 지원 계획이 없어, 이를 명확히 알리기 위해 복수의 독립적인 API 를 제공하고 싶다.

Solution

하나의 God Method(모든 상황에 필요한 인자의 합집합 받으며, 입력 조합에 반응하여 동작함)을 ‘내부’에 두고, 공개 메서드에서는 인자를 적절히 조합하여 이 God Method 를 호출한다.

Cautions

God Method 는 하나의 기능에만 특화된 메서드에 비해 로직이 복잡하므로, 일반적인 경우에는 지양해야할 어프로치다.

‘중복량 vs. 복잡도 증가’ 를 잘 판단하여 적용 여부를 결정해야 하며, 적용하더라도 내부(private) 메서드에 한정 짓는 것이 좋다.

Examples

아래의 세 함수들은 입력 인자 중 하나만이 다르며, 그에 따라 달라지는 코드 라인수는 전체 코드 구현에서 비중이 작다. 혹은 중복 코드의 절대량이 많다.

public Object DoSomething(.. /* series of params */)
{  .. // tens of lines
MakeSomething(.., null, null,  ..);
.. // tens of lines
}

public Object DoSomething(Apple apple, .. /* series of params */)
{  .. // tens of lines
MakeSomething(.., apple, null,  ..);
.. // tens of lines
}

public Object DoSomething(Orange orange, .. /* series of params */)
{   .. // tens of lines
MakeSomething(.., null, orange,  ..);
.. // tens of lines
}

DoSomething 함수에 필요한 모든 인자를 받아들이니 God Method (DoAnything) 를 만들어 구현을 하나로 모은다.

private Object DoAnything(Apple apple, Orange orange, ..) // newly introduced god method
{  .. // tens of lines
MakeSomething(.., apple, orange, ..); // bypass the given params
.. // tens of lines
}

public Object DoSomething(..)
{  // no more duplicated lines
return DoAnything(null, null,  ..); // invoke the god method
}

public Object DoSomething(Apple apple, ..)
{
return DoAnything(apple, null,  ..);
}

public Object DoSomething(Orange orange, ..)
{
return DoAnything(null, orange,  ..);
}


References

  1. Recommended Sequence for Refactoring (wegra.org)
  2. Remove Duplications : Convert & Redirect (wegra.org)
Market Trends – Android & iPhone
Nov 24th, 2009 by Wegra Lee

Android 와 iPhone 의 최근 동향 중 주목할 만한 것들을 요약해 보았다.

Android & Android Market

Motorola Droid 가 불티나게 팔리고 있다. 발매 2주만에 Android 마켓의 24% 를[1]..

Verizon의 마케팅.. 그 중에서 임팩트가 큰 것 중 하나로 Google Navigation 을 뽑을 수 있는데, 이제 Android 1.6 에서도 공식 지원된다[2].

Android Market 은 잠재력은 있으나 아직 절대적 수치는 신통치 않다. 아래는 Android 게임 판매 추정치[3]

Title Name Developer Units Downloaded Current Price (USD)
Robo Defense Lupis Labs Software 7,600 $2.99
Farm Frenzy HeroCraft Ltd 4,070 $4.77
Jewellust Smartpix Games 3,856 $2.95
Devily Huntress Smartpix Games 1,920 $2.95
Baseball Superstars 2009 GameEVIL 838 $5.95
GameBoid yongzh 1,240 $3.99
BeatDown Boxing Requiem Software Labs, Inc 1,483 $2.99
Snesoid yongz 1,442 $2.99
Gang Wars – 40 Respect Points The Game Boss 983 $4.00
UNO Gameloft 1,240 $2.99

하루에 몇 만, 몇 십만 단위로 판매되는 AppStore 시장과는 아직 수십~수백배 가량 격차를 보인다. 그래서인지 Gameloft 에서는 iPhone 쪽 판매량이 400배나 더 많다면서 최근 Android 투자를 줄이고 iPhone 에 더 집중하겠다는 의사를 밝혔다[4]. 그래도 위 조사기간에 따르면 10월에만 53%의 성장을 보였고, 11월에도 그 정도 성장을 이어갈 것으로 내다보고 있다. 무서울 정도의 Droid 판매 추이와 앞으로 쏟아질 수십 종의 Android 폰들이 파이를 키워줄 것이다. 이제 기기간의 차이를 얼마나 잘 극복하느냐가 관전 포인트..

아무튼 가트너가 내다본 2012년경 2위 스마트폰 플랫폼 등극을 향해 순항하고 있는 듯 보인다.

iPhone & AppStore

1.6 GB 의 어플이 등장했다[5]. 북미/캐나다 버전도 1.3 GB에 댈한다. 비대 어플리케이션의 대명사였던 Myst (727MB) 를 가뿐히 즈려밟아주고 있다. 참고로 Android 는 아직 구조적 한계로 인해 이렇게 큰 어플리케이션을 수용할 수 없다[6]. 언제쯤 이런 제약이 해제될 지는 아직 미지수. 그 때까지는 최고 수준의 어플들은 아이폰의 품질을 따라오진 못할 것이다 (물론 웹기반 어플은 예외).

시장 성장은 순조롭다. AdMob 의 통계에 따르면 이미 전세계 스마트폰 데이터 트래픽의 50%를 넘어서고 있다. [1][7]

또한 단일 사업자 모델이 종료되면서 판매 시장은 더욱 커질 것이다. 유럽 시장에서는 이미 효과를 보고 있고[8], 내년엔 Verizon 에도 iPhone 이 공급된다는 예측 기사들이 나오고 있다. 그 외로는 인도/중국 등 아직 판매가 신통치 않은 잠재 시장에서 어떻게 돌파구를 찾아내느냐가 또 하나의 큰 관건이 되겠다.

AppStore 에는 1주일에 (업데이트 포함) 10,000 개 가량의 어플리케이션이 등록된다[9]. 전문 검수자가 40 여명이라하니[10].. (비록 잡음은 많지만) 검수 프로세스가 상당히 잘 갖춰져 있음을 짐작해볼 수 있다. 하지만 검수에 소요되는 기간이 점점 늘어나는 경향을 보이는데, 무작정 검수자를 늘리는 것도 좋은 방안은 아니라고 생각했는지 효율 향상을 위해 다양한 노력을 기울이고 있다.

  1. Free App 에서도 in-app purchase 가 가능케하여 lite/full 버전을 각각 만들 필요가 없어졌다[11]. 그간 엄청난 수의 lite 버전들이 범람했음을 생각해볼 때 submit 되는 수를 제법 줄일 수 있을 것이다. (물론 이것의 주목적은 아니었다.)
  2. 정적 검사 툴을 도입하여 비공개 API 를 사용하는 어플을 “자동” 추출, reject 시킨다. 이 툴도 버그가 있다해서 잡읍이 발생하고 있다[12].
  3. Update (version up) 은 더 이상 Recent(latest?) Release 에 포함되지 않는다[13]. 너무 잦은 minor update 를 줄이려는 시도록 보이지만.. update 를 주요 마케팅 수단으로 사용하던 개발자들로부터 많은 원성을 사고 있다.

새로운 시장의 개척자로써 시행착오도 많이 겪고 있지만, 전반적으로 더 나은 방향으로 나아가고 있다고 생각된다. 개인적으로는 Phil Schiller 수석 부사장의 답변이 나름 설득력 있게 느껴진다[9].

Forecast

Android 폰은 multi vendor 에 의한 공세로.. iPhone 은 시장 확대와 배타적 계약 종결, 4세대 iPhone 발매 등에 힘입어, 2011년 하반기에는 분기당 천만대 이상을 판매할 수 있을 것이다. iPod touch 까지 포함하면 AppStore 시장은 분기당 1,500만 ~ 2,000만 규모의 신규 고객 확보도 가시권에 놓일 수 있다.

변수는 그리 많아 보이지는 않는다. Nokia 가 방어를 잘 한다고 해도, iPhone 이나 Android 폰의 시장을 빼앗기 보다는 기존 시장을 유지하면서 함께 파이를 키우는 정도가 될 것이다. RIM 은 BlackBerry OS 5.0 의 발표를 앞두고 있는데, 아직은 별다른 정보가 없어서 예측하기 어렵다. Palm의 webOS 기반 기기들은 예상외로 판매가 저조하다. 어플리케이션들도 다양상이나 기능의 강력함에서 많이 부족한 상태이고, 웹 기반이라는 한계로 당장은 급격한 개선은 어려워 보인다. 삼성의 bada[14] 는 아직 공개된 것은 없지만 시장 진입 시점이 늦다. 출시 예정인 2010년 1H 면 2Q 일 확률이 거의 100%이고, 그 쯤이면 Android 와 webOS 의 한 차례 minor 버전업도 기대해볼만 하고, 특히 차세대 iPhone 에 대한 기대와 루머가 시장에 팽배할 것이다. BlackBerry OS 5.0 도 등장했을 가능성이 높다. 소프트웨어로는 평이 좋지 않아왔던 삼성이 이들 대비 훨씬 나은 혁신을 가지고 등장할 것으로는 보이지 않는다. 자체 플랫폼에 탑재되는 것 외에 경쟁 상대의 시장을 잠식할 가능성은 낮다.


References

  1. October 2009 Mobile Metrics Report (by AdMob)
  2. Google Maps Navigation officially comes to Android 1.6 (by Engadget)
  3. Android Mobile Sales Chart – October 2009
  4. Gameloft chooses iPhone over Android (by TGDaily)
  5. TomTom Western Europe
  6. Inside Google’s Android and Apple’s iPhone OS as software markets [Page 3] (by AppleInsider)
  7. Apple iPhone eats up 50% share of all mobile data traffic globally (by AppleInsider)
  8. End of iPhone exclusivity means boosted sales in Europe (by AppleInsider)
  9. Apple’s Schiller Defends iPhone App Approval Process (by BusinessWeek)
  10. iPhone application approval process (by BugInside)
  11. Apple Announces In-App Purchases For Free iPhone Applications (by TechCrunch)
  12. Apple’s App Store approval process gets partially automated (by AppleInsider)
  13. [애플] 대략 난감한 애플의 새로운 “업데이트 앱에 대한 노출 정책” (by Alones world)
  14. Samsung bada mobile platform
Bad Team Culture – Lessons Learned as a Last Will
Nov 20th, 2009 by Wegra Lee

Lessons Learned

그간 이 팀 저 팀에서 발간(?)한 수많은 소위 Lessons Learned 라는 것을 봐온바 있다. 과제를 진행하면서 느끼고 배운 것을 정리하여 다음 과제 진행시 참고하거나 진행중인 다른 과제에서 참고할 만한 좋은 정보들이 적혀 있다. 자신이 걸어온 길을 되돌아보는 것은 좋은 경험이고, 그 결과를 정리해 놓는 것 역시 권장할 만한 일이다.

문제는 그 시점이 항상 과제가 뿌러지는 등 완전히 종료되는 시점에 일어난다는 것이다. 많은 경우 팀 자체가 뿔뿔이 흩어지거나 축소된다. 다음에 진행할 과제도 이전 과제와 성격이 달라지기 쉽다. 얻은 것이 있어도 그것을 적용해볼 상황이 못되는 것이다.

과연 이전 과제에서 깨우친 것들이 새로운 과제 새로운 팀에서 제대로 먹혀들 수 있을까? 시행착오를 거쳐보지 않은 새 팀 멤버들이 가슴 깊이 공감하고 따라줄 것인가? 배경이 다른 사람들에게도 똑같은 처방이 여전히 유효할까? 내가 얻은 결론은 정말 더 나은 개선책인가? 아니면 단지 ‘다음엔 이렇게 해봐야지’ 정도인가? 검증되지 않았고 경험해보지도 못한 방법을 새 팀 새 과제에서 시험해볼 용기는 있는가?

위와 같은 고민들도 어느 정도 영향력이 있는 윗사람들에게 해당하는 것이지, 중간 이하의 힘없는 관리자나 실무자들은 새로운 리더가 시키는데로 그냥 따를 수 밖에 없는 것이 또 현실이다.

결국 이런 식의 Lessons Learned 는 읽을 거리나 유언장 이상의 실질적 가치를 갖지 못한다.

Retrospective

Retrospective 는 Lessons Learned 의 Agile 식 표현 정도로 생각하면 좋을 것이다. 하지만 많은 차이를 안고 있음을 잊어서는 안된다. Agile 이 강조하는 iterative, responsive, incremental 같은 속성을 Lessons Learned 에 부여해보자. 짧은 간격으로 주기적으로 회고하며(iterative), 현 시점에 필요한 이슈에 대한 개선안 만들어 다음 개발 주기에 적용해보아 좋은 것을 취하고 잘못된 것은 버리거나 다른 안을 찾아본다(responsive). 팀은 과제가 진행될 수록 조금씩 조금씩 더 나은 방향으로 발전해 간다(incremental).

이미 끝나버린 과거에 대한 무책임한 회상록이 아닌, 지금 살아서 꿈틀대는 과제에 대한 진중한 고민을 경험해볼 수 있다. 바로 그 시점에 팀원들 스스로가 개선이 필요하다고 느끼는 이슈들이 다뤄지고 합의된 개선책을 시행한다는 점에서 참여율이 높아지고, 높은 성공 확률은 덤으로 얻게된다. 혹 실패한다면 바로 다음 회고 때 그 원인과 또 다른 개선안을 찾게될 것이다. 시행착오를 통해 더 많은 경험을 얻게되고, 미처 고려하지 못했던 요소들이 있음을 깨닫게 된다. 넓고 세심해진 시야는 다른 문제에 직면했을 때도 좀 더 빠르게 더 효과적인 개선안을 찾게 도와준다. 반면 Lessons Learned 방식에서는 실패한 처음 안만이 남겨질 가능성이 농후하다. 회고가 거듭될 수록 팀의 생산성이 향상됨을 느낄 수 있을 것이다.

Barriers and Ways to Overcome

다 좋고 완벽해 보이는 회고도 무턱대고 적용하려 하면 말처럼 쉽지 않음을 깨닫게 된다. 내가 지금까지 발견한 중요 요인은 3 가지 이다.

첫째, 일정에 쫓겨서 회고에 할애할 시간적 여유가 없다.

이런 답변을 많이 들었는데, 시간적 여유가 없는 것이 아니라 회고의 효과에 대한 믿음이 부족하거나 새로운 것을 시도하는 것을 꺼리는 보수적 마인드의 팀일 가능성이 높다. 이런 경우엔 분위기 조성을 위한 물밑 작업부터 시작해야 한다. 말이 통하고 깨어있는 사람들이라면 직접적인 대화로 돌파할 수 있겠다. 뜻이 맞는 팀원이 소수라도 존재한다면 솔선수범해서 더 나아지는 모습을 직접 보여줄 수도 있을 것이다. 상황이 다양한 만큼 방법도 다양할 터이니 숙고해서 도전해보자. 단, 상대를 공격하는 것은 확실한 실패 방법이니 절대 피하길 바란다.

참고로 회고에 필요한 시간은 보통 2~4주에 1시간 정도면 충분하다. 물론 처음 시작할 때는 좀 더 많은 시간이 필요할 것이지만 두세번만 해보면 익숙해지고 소요 시간도 줄어든다.

둘째, 팀원들의 참여가 저조하다.

기껏 회고를 해보자는 허락을 받았는데, 정작 모인 사람들이 꿀먹은 벙어리 마냥 침묵으로 일관한다. 회고를 처음 시도하는 조직에서는 대부분 겪게 되는 인기 코스일 것이다. 그들이 침묵하는데에는 여러 가지 이유가 있을 것이다. 무슨 얘길 하면 되는거지? 예제 같은 거 없나? 얘기한다고 정말 개선해 주나? 말 꺼내면 나보고 꺼낸 사람이 하라고 하겠지? 불평하면 괜시리 밉보일 거야.. 등등.

이런 우려를 해소하고 적극적인 참여를 유도하려면 맛을 보여줘야 한다. 사소한 것부터라도 정말 개선되는 모습을 보여주는 것이다. 첫 회의에서 아무런 아이디어가 없을 것을 대비해 문제점과 개선안까지 몇 가지를 준비해둔다. 뜻이 맞는 사람이 한 명이라도 있다면 역할극을 해보는 것도 좋다. 혼자 북치고 장구치는 것보다 훨씬 효과적으로 분위기를 이끌어 갈 수 있을 것이다. 그리고 개선안이 없더라도 불편한 사항을 자유롭게 이야기하도록 하고, 그에 대해 반박을 하거나 방어적인 모습을 보여서는 안된다. Brain storming 방식으로  문제들을 나열하고 중요도와 시급성, 파급 효과 등을 생각해 이슈를 선별해서 개선안을 모색해보자.

셋째, 팀에 부여된 권한이 너무 작다.

열심히 분위기 잡고 멋진 개선안들도 마련했다. 그런데 그 개선안들이 우리힘으로 할 수 있는 일들이 아니라면? 운영부서는 돈 들어가는 일은 절대 허락을 안해주고, 보안 부서는 개발자 편의성은 절대악으로 규정짓고, 프로세스 팀은 표준 프로세스에 어긋난 어떠한 시도도 용납하지 않고, 기획/마케팅 부서는 자신들이 바라는 모든 기능을 역시 자신들이 정한 시한까지 완수해야 한다고 못박고, 책상 앞에 앉아 있는 시간과 개발진도는 정비례한다고 철석같이 믿고 있는 임원이 군림하고 있다면?

회고는 불평불만을 토로하고 남들 뒷담화가 남무하는 장이 되던가, 소꼽장난하듯 사소한 문제들만 다뤄지는 비중없는 시간으로 전락할 것이다. 물론 작은 개선들이 차곡히 쌓여 큰 도움을 줄 수도 있을 것이고, 공동의 적을 향한 불평불만과 뒷담화는 팀원들을 단합시켜주는 효과도 있기는 하다. ^^

모든 것을 통틀어 가장 큰 장벽으로, 딱히 뾰족한 해결책도 없다. 때마침 임원 인사가 단행되어 깨어 있는 사람으로 교체되던가, 무슨 바람이 불어서 아주 권위 있는 컨설턴트의 도움을 받을 수 있다면 큰 힘이 될 것이다. 하지만 모두 다 운에 기대는 것이고.. 리더나 팀원들이 몸소 나서서 설득하고 싸우는 적극적 쟁취 방법도 물론 있다. 하지만 생태계에서 식물 급으로 취급되는 힘없는 개발팀이 얻어낼 수 있는 것은 많지 않을 것이다.


References

  1. Retrospectives by RTC dev. teams
  2. Agile Retrospective – Lessons Learned
Bad Team Culture – Incremental Delay
Nov 19th, 2009 by Wegra Lee

Incremental Delay 란 아주 짧은 간격으로 릴리스 날짜를 조금씩 미루는 행태를 뜻한다. 일단 릴리스를 시도해보고, 안되면 조금  (보통 1~3일) 미룬 후 다시 시도한다. 역시 잘 안되면 또 다시 미룬 후 시도한다. 이렇게 릴리스가 될 때까지 무한 반복하는 릴리스 관리 방식이다.

사례

내가 경험해본 최악의 상황은 이러했다. 원래의 릴리스 목표일은 금요일이다. 금요일이 되어서 시도를 해보았으나, 도저히 릴리스할 만큼의 품질이 나오지 않는다. 그래서 월요일로 목표를 바꾼다. 월요일에도 역시 원하는 품질에 도달하지 못했다. 다음날 다시 한 번 시도해보기로 한다. 마찬가지로 실패했다. 이와 늦은거 금요일로 다시 미룬다. 금요일도 여전히 실패.. 토요일.. 월요일.. 수요일.. 금요일.. 월요일.. 화요일.. 토요일.. ..

이런 식으로 가장 길게는 6주간 계속 릴리스만 한 경우도 있었다. 릴리스가 이렇게 한달 가량 지연되면 당연히 다음 릴리스에 일정에 지장을 주게 된다. 새로운 기능을 추가하는데 필요한 최소 시간이 있으므로 차례차례로 전체 일정이 연기된다. 하지만 다음 릴리스 시점에 와서도 크게 다르지 않다. 역시 또 몇 주의 지연이 발생한다. 그래서 ‘릴리스가 끝나면 (다음) 릴리스 일정이 바뀐다’, ‘릴리스가 되는 날이 릴리스 날이다 (역: 릴리스 날에 릴리스를 한다)’ 라는 말까지 하게 되었다.

위의 경우는 continuous integration (CI) 도 도입되지 않은 열악한 환경에서의 상황이었고(도입을 요구했지만 관심 갖는 사람이 없었음), 그 후 CI 가 도입되면서 상황은 많이 호전되었다. 하지만 여전히 제 때 릴리스 되는 경우는 전무했고.. 심한 경우 3주가 밀리기도 했다. 금요일 릴리스를 (주말을 열심히 일해서) 그 다음주 월요일 저녁에 할 수 있다면 대단히 이례적인 성공이 케이스가 될 정도였다.

악효과

Incremental Delay 가 팀 문화처럼 정착되면서 다음과 같은 부작용들이 나타나기 시작했다.

팀원들은 윗선에서 정한 릴리스 날짜(deadline)에 큰 의미를 부여하지 않게 되었다. 한 차례도 성공적으로 릴리스한 경험이 없으며, 릴리스가 연기되어도 아무 일도 발생하지 않음이 학습되었기 때문이다. 꼭 지켜져야하는 중요한 릴리스라 강조해도 마음속으론 ‘어짜피 안될걸..’이란 생각을 자연스레 하게된다.

서브팀별 개발 일정이 꼬이기 시작한다. 팀별로 이터레이션(iteration) 주어진 일의 양이나 생산성, 예측 정확성 등의 차이가 생겨 발생하는 현상으로.. 일부 팀은 일정에 맞춰 일을 끝내놓고 다음 릴리스를 위해 할 일을 준비하고 있다. 하지만 곧 될 듯 말 듯 하면서 릴리스는 기약없이 지연된다. 처음엔 2~3일 후면 될 거라 기대하고 잠시 쉬던 것이 하루 이틀씩 밀리면서 결국 이 주 삼 주 동안 제대로 진행할 수 없게 된다. 이런 경험이 잦아지면서 일부에선 중간중간에 변경된 코드를 밀어 넣는다. 다음 릴리스를 위한 개발 코드 브랜치와 (지연중인) 릴리스 브랜치 간에 코드 격차가 심해져, 개발 브랜치에서 해결된 문제를 릴리스 브랜치에 반영하는데 한참을 씨름하기도 한다.

윗선도 계속되는 릴리스 관련회의로 시간을 낭비하기는 마찬가지다. 현황을 파악하고, 얼마나 더 지연시킬 지 정하고, 지연이 미치는 영향을 분석하고, 이왕 지연된 것 미리 구현된 간단한 기능을 포함시킬 지 논의하고.. 자료를 준비해 더 윗선이나 마케팅, 기획, 운영(예산) 팀 등과도 계속 조율을 해야 한다.
야근과 주말 근무가 늘어난다. 일주일 단위로만 지연시켜도 호흡 조절과 재충전이 가능하겠으나, 지연 단위가 보통 1~3일 정도이고, 특히나 금요일 일정은 반드시 토/일/월로 지연된다.

고찰

무엇하나 좋을 게 없는 이런 비합리적 문화가 왜 개선되지 않는 것일까?

이런 현상이 반복되고 있음은 윗선에서 과제가 어떻게 돌아가고 있는지 전혀 파악하지 못하고 있다는 확실한 반증이다. 릴리스를 하기 위해 해야할 일이 얼마만큼 남아 있는지 도통 감이 없다. 개발자들의 생산성과 문제 해결능력에 대한 어떠한 정량적/경험적 데이터도 갖춰져 있지 못하다. 개발자 각각이 지금 무슨 일들로 얼만큼의 로드가 걸려있는지도 잘 파악이 안되고 있다. 해결해야할 문제들이 얼마만큼의 노력이 들어가야 하는지도 역시 감이 없다. 아직 드러나지 않은 문제들은 또 얼마나 될 지 역시 예상하기 어렵다. 결국 위에서 할 수 있는 말은 보통 ‘언제까지 이 문제들을 해결해라’ 정도에서 그친다.

제품의 설계나 코드의 품질이 크게 떨어지거나, 다뤄야할 대상을 개발자들의 완벽하게 이해하지 못하고 있을 경우 사태는 더 심각해진다. 분석하고 수정하는데 필요한 시간을 예측하기 힘들고, 수정시 부작용(side-effect)이 따를 가능성이 높다. 동작 여부만이 아니라 코드의 품질을 챙기는 개발 문화를 조성해야 하고, 서로 간의 잦은 리뷰를 통해 다른 팀원들과 개발 패턴, 노하우 등을 공유해야 한다.

관련 개발팀간 커뮤니케이션 효율성도 큰 영향을 미친다. 심한 경우는 핵심 모듈을 전혀 다른 팀에서 관리하고 있고, 우리 과제를 지원하는 것은 그 팀의 최우선 역할이 아닐 때이다(실제로 자주 접해보았다). 유관 팀들이 지리적으로 멀리 떨어져 있고, 원격지에선 문제를 재현하기 어려울 때도 마찬가지.. 어떠한 경우건 커뮤니케이션 지연은 일의 진행 속도를 현저히 떨어뜨리는 주요 원인이 된다. 과제를 기획하고 팀을 조직할 때 그 과제와 팀이 적시에 충분한 지원을 받을 수 있도록 고려해야 한다. 필요하다면 조직 구성을 바꿔 같은 명령 계통 내로 흡수할 필요도 있다.

미흡한 인프라에 의한 불확실성도 크다. 기본적인 테스트 자동화 시스템도 갖추지 못해 매번 개발자들이 수동으로 테스트하는 것도 많이 보아왔다. 나름 도입한 continuous integration 이 기껏 빌드만 해주고 기본적인 unit test 도 수행하지 못한는 경우를 상상해보자. 내가 경험한 어떤 팀은 unit test 를 CI 에 통합해달라는 요청을 한 지 1년이 넘도록 반영하지 못했다. 다른 자동화는 물론 말할 것도 없었다. 과제 규모가 커질 수록 그에 걸맞게 인프라 효율성에도 투자를 해야한다. 발등에 떨어진 일정에만 쫒겨 제때 투자를 못하면 일을 해야할 정작 개발자들의 시간을 어먼 곳에 낭비하게 만든다.

개발 문화와 생산성 향상, 효율성, 팀웍에 대한 인식이 부족하다. 위에서 가장 중요시 하는 것은 언제 릴리스 되는가이다. 어떤 때는 그것 외에는 전혀 관심이 없는 것 같다는 인상을 받곤 한다. 일벌레인 사람들이 지배하는 조직에서 더 심한 경향이 있는 것 같다. 종종 일찍 퇴근하고 싶어하는 사람을 이해하지 못하는 듯한 발언을 듣기도 한다. 아무래도 사람은 자신의 기준에서 남을 이해하는 성향이 있으니, 어찌보면 당연한 것일 수 있다. 하지만 사람(뿐 아니라 모든 생물)은 기계와 달리 충분한 휴식 없이는 높은 집중력과 생산성을 유지할 수 없음을 주지시켜야 한다.

The Go Programming Language
Nov 12th, 2009 by Wegra Lee

Noop 에 이어 구글이 또 하나의 프로그래밍 언어를 소개했다. Go 라는 이름의 언어로, 벌써 제법 성숙한 상태라, 과거 Turbo C 나 초창기 UltraEdit 로 Java 코딩하던 추억을 떠올리면 충분히 직접 사용해볼 수 있는 수준이다.

Go 언어는 크게 두 가지 관점에서 아주 마음에 든다.

처음부터 다시 시작했다.

현재의 것에 계속해서 군더더기를  붙여 나가다 보면 점차 비대해져 관리를 어렵게 하고 혁신을 가로막는다. 때문에 종종 처읍부터 다시 시작하는 것이 필요하다.

번외로.. 구글이나 애플과 같은 회사가 이런 일을 참 잘하는데, 최근 40살 된 e-mail 을 대체하겠다며 큰 기대를 받고 있는 Google Wave 나 이미 성숙할 대로 성숙한 핸드폰의 개념을 바꿔버린 iPhone 같은 것이 좋은 예이다.

덕분에 더 이상 필요 없거나 폐해가 더 큰 기능들을 과감히 없애 날렵해짐과 동시에 병렬 프로그래밍과 같이 새시대에 필요한 기능들을 실장하고 있다.

C/C++ 를 경량화시켰다.

내가 가장 혐오하는 프로그래밍 언어인 C++. C++ 는 기능 확장이 아니라 축소를 먼저 해야 한다고 내가 몇 년 전부터 얘기하고 다녔는지 모른다. 물론 Go 가 C++ 의 직접적인 축소판은 아니지만, 같은 C 계열 (호환이 아니라 파생의 의미로) 언어로써 정말 최소한부터 다시 시작하는 언어이다. 홈페이지에서 언급한 몇몇 설계상의 결정 사항들은 정말 내 가슴을 후련하게 해준다. 포인터 연산, exception, assertion, 오버로딩 등에 대한 설명은 나의 그간 경험에 비춰 특히 공감이 된다. 수많은 개발자들.. 아무리 설명을 해줘도 계속 교체되고, 새로온 사람들에게 또 설명하고.. 그러다 지쳐 포기했던 기억이.. ^^

Go 가 잘 발전해서 C++ 의 영향력이 감소하는데 한 몫 해주길 바래본다.


References

  1. Official Site
  2. Tech Talk (YouTube Video, 1 hour)
  3. PDF for the above Tech Talk

잡설.

소프트웨어 플랫폼 경쟁에 있어 우리 나라 기업들은 도저히 상대가 안되는게.. 애플이나 구글같은 회사는 핵심 소프트웨어 개발 역량이 정말 대단하다. 우리처럼 API 겉만 감싸는 수준이 아니라, 필요하면 언어 자체를 수정하거나(최근 GCD 를 위해 C 언어를 확장함) 심지어 만들어버리기까지 한다(Go, Objective-C). 애플은 LLVM/CLang 이라는 GCC 대체 프로젝트를 진행해 큰 성취를 보이고 있고, 구글 가상 머신을 뜯어 고쳤다(Dalvik VM). 소프트웨어 설계 자체도 참 대단하다. 이미 25년의 OS 개발 경험을 축적하고 있는 애플의 OS X 는 전신인 NextStep 시절부터 소프트웨어 설계의 바이블 격인 Design Patterns 책 저술에 지대한 영향을 미쳤다. 현재의 플랫폼도 깊이 들여다보면 ‘우와!’ 하는 감탄사가 절로 나오는 멋진 구조를 어렵지 않게 찾아볼 수 있다.

핵심 기술이 없으면 오픈 소스/커뮤니티에라도 적극 참여해 그들의 노하우를 최대한 빨리 흡수하며 기반을 쌓는 것이 큰 도움이 된다. 모토롤라의 이번 Droid 출시가 좋은 예이다. 작년, 큰 위기를 느낀 모토롤라는 진행중이던 프로젝트들을 대다수 취소하고 회사 전체를 환골탈퇴하는 모험을 감행했다. 덕분에 신규 제품이 나오지 않아 시장 점유율을 급격하게 떨어졌지만, 구글과의 밀접한 협력으로 Android 2.0 폰을 타 기업들보다 몇 개월 앞서 출시할 수 있었다. 결과는 더 지켜봐야겠지만, 구글과의 돈독한 관계뿐 아니라, Android 시장에서 적어도 당분간은 타 업체들을 선도할 수 있는 충분한 노하우를 얻었을 것이다.

허나 안타깝게도 우리 나라 기업들은 이런 방향으로의 가시적인 움직임은 보이질 않는다. 티맥스 윈도우나 삼성 바다의 예에서 보듯이, 오히려 독자적인 플랫폼을 시도하고 있다. 아직은 실체가 드러나지 않아 확언할 수는 없지만, 중학생들에게 ACM 이나 IEEE 논문을 쓰라는 격으로 보인다. 유사하거나 오히려 더 참신한 아이디어가 나올 수는 있으나, 그 깊이와 완성도는 비교할 수 없을 것이다. 유수의 석학들과 경쟁해 진정 그들을 뛰어 넘고자 한다면, 조급함을 억누르고 차근히 기초를 닦는 인내의 기간이 필요하다.

Samsung bada 에 대한 해외 반응..
Nov 11th, 2009 by Wegra Lee

어제 삼성이 오픈한 bada 에 대한 해외의 반응들을 살펴보았다.

예상했지만.. 그리 긍정적이지는 않다.

기사 ‘본문’ 중 공개된 정보와 다른 부분

  • ‘B’ada 라 칭하는 곳이 ‘많이’ 있다. 애교로 봐주고.. (정식 이름은 ‘소문자’ bada)
  • 제품 출시일.. (정식 발표는 first half. IT 용어로 first half 는 2분기이다.)
    • Early 2010 에 ‘제품’이 출시된다.
    • (반대로) second half 2010 에 출시된다 고도 함.

기대 혹은 바람

  • 오픈 소스
  • 리눅스 기반
  • Evolution on LiMo

이름에 대한 커맨트 (발음에 대한 홍보가 더 필요할 듯..)

  • Bad (유아 용어.. dad, mom 같은..)
  • Bada(ss)
  • Bada Bing.. Bada Boom (MS 와 협력해서 기본 검색 엔진을 Bing 으로 해달란다.)
  • 힌디어로 bada = big

커맨트들에 대한 전반적인 반응

  • 약 9:1 정도로 부정적인 커맨트가 우세하다.

블로거들의 반응

  • 부정적, 혹은 중립. 부정적 쪽이 많음. 긍정은 전무.
  • 주로 플랫폼 너무 많다는 불평.

References

  1. Samsung bada official website
  2. Lots of news and blogs
»  Substance: WordPress   »  Style: Ahren Ahimsa