»
S
I
D
E
B
A
R
«
[updated] Rational Team Concert 적용 실패 – 원인 분석
Jul 15th, 2011 by Wegra Lee

지난번 글(새로운 툴을 대하는 자세)에서도 언급했듯, 나는 조직에 많은 툴들을 전파해보았다(혹은 전파하려 하였다). 그 중 규모면에서나 영향력면에서나 가장 큰 툴은 바로 Rational Team Concert (RTC) 일 것이다. 내가 접해본 툴들 중 가장 마음에 드는 툴이기도 하다. 그런 이유로 수년간에 걸쳐, 다양한 방법으로 팀원들을 끌어들이려 노력해보고, 한 때 좋은 분위기로 흘러가기도 했지만.. 현 시점에서 결론을 내려보면 ‘완전 실패’다. 자.. 이제부터 내가 느낀 실패 원인을 살짝 정리해보겠다.

자잘한 원인들을 모두 나열하자면 한도 끝도 없을테고 초점도 흐려질듯하니 생략하고, 내가 생각하는 가장 근본적인 원인만 다루려 한다. 바로 (주로 유교의 영향이 컸을 듯한) ‘수직적 문화’이다.

우리 문화는 서열을 중시한다. 조직에서의 서열은 이렇게 매겨진다.

  • 주인 >> 직급 >> 연차 > 나이 > 능력

이 서열을 뛰어넘기란 여간 어려운 게 아니다. 아무리 능력이 좋아도 직급이 더 높은 사람을 부릴 수 없으며, 심지어 같은 직급과 같은 연차라도 나이가 한 살이라도 더 많은 사람을 밑에 두기란 쉽지 않다. 여러 가지 예가 있다.

  • 과제가 잘 되어 팀 규모가 커지면, (팀원을 승진시키기보다) 규모에 어울리는 높은 직급의 사람들이 합류한다. 팀을 이끌던 원조 맴버들 대부분은 새로 들어온 높은 분들 밑으로 들어가서, 기존보다 작은 역할을 맡는다.
  • 적은 나이와 연차에도 능력을 인정받아 상대적으로 큰 규모의 팀을 이끄는 자가 있다면, 그의 팀은 다른 팀보다 젊은 사람들도 구성되어 있다.

특히 직급은 우리 조직 시스템에서 너무도 중요한 축을 담당한다. 말단 사원을 제외하고는 모든 사람들을 호칭할 때 직급을 붙여준다. 대부분은 때되면 붙여주는 직급이지만, 이를 생략하고 불렀다간 관계가 소원해질 것을 각오해야 한다. ^^;

굳이 회사에서만 예를 찾으려할 필요도 없다.

  • 바른 논리를 가지고 있더라도, 나이 많은 이에게 목소리를 높이면 버릇없다는 평을 듣기 십상이다.
  • 그룹 활동을 하는 연애인들의 리더는 십중팔구 나이가 가장 많거나, 동갑일 경우엔 생일이 가장 빠른 사람이다. 누가 막내인지 알리는 것도 빼놓지 않는다.
  • 운동 선수들 간의 엄격한 선후배 관계도 잘 알려져 있다.
  • (반대 급부로 생긴 말이지만) ‘나이 먹은게 벼슬이냐?’ ‘나이가 벼슬이다’와 같은 말이 심심찮게 쓰이는 것은 나이가그 사람의 상대적 위치를 결정짓는데 적지 않은 영향을 미침을 반증하고 있다.

불행히도 이런 문화는 우리가 쓰는 언어에 의해 아주 어렸을 때부터, 거의 언어를 배우기 시작하면서부터 주입된다. 한 살이라도 많으면 형, 누나, 오빠, 언니가 되고 그들에게는 말을 높이라고 교육받는다. 윗사람을 공경하는 문화야 칭송되기도 하고, 그리 나쁘지는 않은 문화라 생각한다. 다만 아쉬운 것은 단순히 나이 많은 이에 대한 어휘와, 정말 존경이나 높은 사람에 대한 예우로써 쓰는 어휘에 차이가 없다는 점이다. 즉, 우리는 존경과 나이 많음을 명확하게 구분짓지 않기 때문에 알게모르게 이 둘을 동일시 시킨다. 언어가 인간의 사고를 지배하기 때문이다. 초등학생만 되어도 선배는 후배에게 일을 시키고, 후배는 선배의 명령을 따르는 것이 몸에 익어버린다. 갑으로써 누릴 수 있는 힘과 을로써의 자세를 사회 관계를 처음 쌓게 되면서부터 체득하게 된다. 그리고 성인이 될 때까지 단 한 번도 이에서 벗어난 문화를 경험하지 못하고 성장한다. (채벌에 관대하게 된 데에도 많은 영향을 미쳤으리라 믿는다.)

이렇게 우리는 협동과 협업보다는 명령 하달과 수행 체제에 적합하게 훈련되었다. 평등한 관계 속에서 협업이 중시되는 사회에서는 뛰어난 리더가 중심이 되지만, 명령과 수행에 의해 움직이는 사회에서는 냉철한 관리자가 더 중요해진다.

이쯤에서 RTC를 잠시 살펴보자. 툴에는 툴 설계자의 노하우와 철학이 담겨있다.그럼  RTC 설계를 주도한  에릭 감마는 어떤 생각을 가지고 이 툴을 만들었을까.  이런저런 이야기를 하고 있지만, 핵심은 효율적인 협업투명성이다. 관리와 통제가 아닌 것이다.

우리 사회도 물론 협업과 투명성을 강조하지만, 평등한 관계에서의 협업/투명성과 수직적 관계에서의 그 의미는 완전히 달라진다. 후자에서의 협업은 같은 등급의 사람들끼리 잘 협동하고, 높은 사람의 말을 잘 따르는 것이다. 투명성은 높은 위치의 사람이 낮은 위치의 사람이 땡땡이 치지 못하게 잘 감시할 수 있는 일방적인 하향 투명성을 뜻한다. 협업은 그렇다 쳐도.. 투명성에 대해서는 실무자쪽에서 더욱 방어적으로 나오는 이유가 되기도 한다. 갑은 을을 마음대로 부릴 수 있음을 어려서부터 익히 배워왔기 때문에, 을은 갑으로부터 최대한 자신을 보호하고 싶어한다. 상향 투명성은 생각하기도 힘들고, 동급의 실무자들간 투명성도 그리 환영받지 못한다. 아랫 사람은 위에서 내린 명령만 잘 수행하면 되는 것이고, 그것이 어떻게 조합되어 전체를 만드는지는 윗사람이 생각할 문제이다. 또한 피지배 계층이 너무 많은 정보를 가지고 있다면 지배하기기 쉽지 않다. 과거 평민 이하에겐 교육을 시키지 않은 이유와 같다. 예를 들어, 지금까지의 과제 진척률이 고스란히 공개된다면 단순 채찍질용 일정 단축 요청 같은 것은 의도한 효과를 발휘하기 어렵다.

몇 년 전, 우리의 행태를 비판하며 프로젝트 투명성에 대한 생각도 끄적여 봤었지만, 하루 아침에 변화시키엔 수직적 문화의 뿌리는 우리 사회에 너무 깊게까지 내려 있다. 나이 차이가 수십년 이상 되는 사람들이 모여 있는 거대 조직에서는 말도 안되는 이상향일 지도 모르겠다.

이런 이질적인 동서양 문화에서 파생되는 또 하나의 심각한 문제는 바로 실무자로써의 생명이 짧다는 점이다.

일반적으로 사원으로 입사했다면 8년쯤 후, 박사로 입사했다면 거의 곧바로 관리자의 역할을 맡게된다. 편차가 심하긴 하지만 평균은 대략 이와 비슷할 것이다. 심지어 대규모 플랫폼을 개발하는 팀에서조차, 능력있는 고참 실무자를 아키텍트로 키워보려 면담을 해보면 ‘저도 이제 관리를 익혀야지요’하는 반응이 많다는 이야기도 들었다.

그런데 이것이 수직적 문화와 무슨 관련이 있단 말인가? 계급이 다르다는 것은 (암묵적으로) 하는 일이 다르다는 뜻이다. 승진을 했음에도 하는 일은 과거와 똑같다면 스스로도 실망스럽고, 주변의 위로 소리가 어색하지 않게 느껴진다. 실무 능력이 아무리 뛰어나도 관리 능력이 미달되면 그는 우리 사회에서 도태되기 쉽다.

이와 달리, 수평적 사회에서는 하는 일의 차이보다는 능력의 차이가 보다 중시된다. 조직을 이끄는데 있어 관리는 물론 중요하지만, 직급이 높으면 관리를 해야한다는 인식보다는 개개인이 가장 잘 할 수 있는 일을 하는 것이 올바르다 생각한다. 관리는 직급의 구분 기준보다는 역할이 다른 것으로 인식된다.

그래서 다시.. RTC와 무슨 상관인가? 관리자 입장에서 생각해보자.

  • 현 상황을 보려면 Eclipse를 깔고 매번 실행해야 한다고? 개발도 안하는데 그 무거운 툴을 내 느린 노트북에서 실행하라니..
  • 소스 컨트롤? 빌드 상태? 그런 건 알아서 풀고, 정 문제가 되면 개선안과 함께 보고해.
  • 이슈? 버그 현황? 한 페이지로 깔끔히 정리해와.
  • 수하 직원에게 업무를 할당하는데 직접 툴에 입력하라니? 말로 시키면 알아서 잘 처리하고 결과만 제때 보고하면 되지.

기타 등등.. 관리자 입장에서는 전문 개발 툴에 통합된 RTC의 인터페이는 불필요한 기능들로 가득차있고 복잡하고 무겁다. 관리를 잘 하기 위해서는, 스스로 툴을 조작하며 이러저런 상세 정보 속에서 헤매이기보다는, 핵심 정보들만 빨리 캐취해서 적시에 올바른 의사 결정을 내리는 것이 훨씬 중요하다. 즉, RTC는 이런 문화에 속한 관리자를 위한 툴이 아니다.

그렇다면 개발자에게는 좋은가..

  • RTC에 열심히 자료를 축적해 놓아도, 상사는 항상 자신이 보고픈 것만 나오는 별도 자료를 요구한다. 어차피 보고 자료 따로 만들 거, 굳이 중복 작업 할 필요 있나!
  • 내게 할당된 일과 그 진척 상황이 거의 실시간으로 공개되니 감시받는 기분이 든다.
  • 요구사항은 별도 문서로.. 일정 관리도 마찬가지. 테스트는 다른 팀에서. 다 빼고나면 내가 쓸 건 소스 컨트롤과 빌드뿐인데.. 그 정도는 오픈 소스 공짜툴 중에도 좋은게 널리고 널렸지. 이왕이면 다른 회사로 옮기거나 집에서 혼자 쓸 때도 그대로 사용할 수 있는 오픈 소스 툴들을 써보는게 좋지 않을까?

이렇듯, 개발자 입장에서도 그리 매력적이라 보기는 힘들다는 생각에 이르렀다. 결국 우리 사회 구성원 누구에게도 딱 맞지 않은.. 먼 나라의 툴이 되어버린 것이다.

물론 우리 사회도 조금씩 변해가고 있다. 요즘의 젊은 벤쳐 기업이나 열린 마음의 사람들로 구성된 작은 팀에서는 RTC가 진정한 힘을 발휘하기에 충분한 문화를 만들 수도 있을 것이다. 그리고 점점 더 상황은 나아질 것이라 믿어 의심치 않는다. 하지만 똑같은 수준에서, 몇 년 내에 급격한 개선이 있을 것이라고는 절대 생각하지 않는다. 조직 문화를 성공적으로 혁신시키려면, 조직 구성원들 대부분이 그 필요성을 마음속 깊이 공유한 상태여야 한다. 그렇지 못한 상태에서 무리하게 추진한다면  모난 돌 취급을 받게 되거나, (추진자가 높은 사람이라면) 마지못해 하는 척만 하다가 머지 않아 원상복귀된다. 혹은 형식만 남아 안함만 못한 상태가 되어버린다.

RTC와 같이 프로젝트 개발 과정 전반을 아루르며 팀 구성원 모두가 써야하는 툴을 온전히 도입하는 것은, 팀 문화 전반을 바꾸려는 시도와 같다. 개인적으로 마음에 들더라도, 팀 차원에서의 적용을 시도하려면 분위기와 팀원들의 성향을 잘 판단해서 추진하기 바란다. 우리팀은 지금 50명 이상이 RTC를 사용하는 듯 싶지만, 에릭 감마가 의도한  방식대로 사용하는 사람도 거의 없을 뿐더러, 관리자쯤 되면 쓰는 사람을 손에 뽑고, 매뉴얼/검색/옆사람을 통해 쉽게 해결할 수 있는 사소한 것들로도 수시로 (전파자인) 나를 찾아 귀찮게 하는 상황이다. ^^;;

가볍게 소개해보고 분위기를 살펴보는 것으로 시작하는 것은 나쁘지 않은 방법일 것이다. 단, 몇 마디 긍정적인 피드백만으로 너무 쉽게 총대를 둘러매진 말길 바란다. ^^

(updated: 내가 이런 글을 적은 이유 중 하나는, 이런 문화적 차이를 미리 알고 충분히 고려해서 적용을 시도해보는 것과, 무턱대고 밀어붙이는 것에는 분명 큰 차이가 있을 거라 믿기 때문이다. 뭐든 내맘에 든다고 다른 사람 맘에도 들거란 생각은 위험하지만, 만약 이 툴이 정말 마음에 든다면, 당신은 주변 사람들과는 다른 사상을 가지고 있을 확률이 많을 것이다. ^^ 실패하더라도 남 탓하지 말고, 사회 탓도 하지 말기 바란다. 이 시스템은 또 이 시스템 만의 장점이 있다. 적응을 해보던지, 정 맞지 않다면 일찌감치 다른 조직을 찾아 모험을 떠나보는 것도..^^)

지속적 통합(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 빌드 스크립트는 약간 다듬어서 추후 업데이트하겠음)

IT 스터디.. 이렇게 진행해 보는 것은?
Jun 19th, 2010 by Wegra Lee

나는 작년에 마음에 맞는 사람 몇 명과 제법 참신하고 효과적인 스터디를 만들어 운영해보았다. 그 경험은 값진 기억이 되었고, 추후 여건이 다시 갖추어지면 유사한 형태로 재도전해보고 싶다. 여기 그 방식에 대해 간략히 소개해볼 터이니, 관심 있는 사람은 직접 주변인들과 시도해보길 권해본다.

내가 만들었던 스터디는 조금 특이했다.

가장 큰 특징은 참여자들이 준비해올 것이 없었다는 점. 스터디 자료로는 Google Tech Talk, iTunes U(niversity), Podcast, 인터넷상의 각종 기술 세미나, 최신 툴 데모 동영상, 유명인 인터뷰 동영상 등이었다. 세어보진 않았지만, 대략 백여 개의 흥미로운 자료들을 모을 수 있었다.

1시간 정도 동영상을 함께 보고, 30분 정도 토론한다. 부족한 정보는 그때그때 인터넷에서 검색해볼 수 있고, 더 깊은 지식을 원하거나 직접 해보고 싶은 것들은 action item으로 빼서 스터디 외 시간에 진행하기도 한다. 흥미로운 결과가 나오면 정리해서 스터디 팀 외의 사람들과도 공유했고, 실제 현업에 도움이 되는 일을 찾아 진행하기도 했다.

또한, 서로의 task plan(멤버 각자가 현업에서 실제 쓰는)을 리뷰하면서 planning 기술을 늘려가기도 하고, 코드 리뷰로부터 나온 유용한 패턴들을 공유하는 자리로도 활용했다.

별다른 준비 없이도 참여만 하면 지식과 지혜를 얻어갈 수 있는 모임이었고, 이런 특성이 스터디를 지속하는 데 큰 도움이 되었다고 믿는다.

매달 마지막 모임 때는 회고(retrospective)를 진행했다. 회고에서는 지난 한 달 동안 공부한 내용을 되짚어보고, 다음 한 달간 공부할 커리큘럼을 짠다. 스터디 진행 방식에 있어 개선이 필요한 부분을 논의해서 적용해본다. 주기적으로 동기를 부여하고, 부족한 부분을 지속 보강하여 모임의 생명력을 유지하고 발전시키는 수단이 되었다고 자평해본다.

이 모임은 매일 아침 7:30에 모여 9시까지 약 4달간 유지되었고, 일부 열성 멤버는 토요일에 모여 별도의 스터디(iPhone application programming)를 진행하기도 했다. 그러다가 내가 다른 목표가 생겨 탈퇴하면서, 아쉽게도 현재는 운영되지 않는 상태다.

운영하면서 어려웠던 점들도 정리해보았다.

- 참여자 대부분이 서로 다른 팀의 맴버였고, 같은 팀 안에서도 개개인이 독립적으로 일하는 문화 때문에 시너지를 일으키는 데 한계를 많이 느꼈다.

- 업무상 건물 간 이동이 잦은 멤버는 왔다갔다하는 불편을 겪기도 했다.

- 정식 업무가 아니라, 이른 아침 시간을 선택.. 참여하고 싶어도 나오지 못하는 사람도 있었다. 멀리 사는 사람, 아침잠 많은 사람 등. 소수 인원으로 운영하다 보니 두 명만 빠져도 스터디 진행에 영향을 미쳤다.

- 팀이 (반 강제적으로) 늦게 퇴근하는 문화로 바뀌면서 아침 스터디에 대한 부담이 점차 커졌다.

내가 이 스터디를 주창한 가장 큰 이유는 평소 동료 개발자들이 세상 돌아가는 정보에 너무 무관심하다고 느꼈기 때문이만, 진행하면 할수록 나 역시도 다른 멤버로부터 많은 정보와 깨우침을 얻게 된 값진 경험이었다.

Applying Rational Team Concert (적용 일지)
Mar 15th, 2010 by Wegra Lee

새로 옮긴 팀에 Rational Team Concert [1] (이하 RTC) 를 적용하기 위해 노력 중이다. 지난 팀에서는 이러저런 이유들로 보수적인 성향이 너무 강해 중도 포기했었지만, 지금의 팀은 가능성이 높아 보인다. 특정 툴을 적용하다는 것이 중요한 것이 아니라 적절한 인프라를 구축하여 팀의 협업 능력을 극대화시킨다는데 목적이 있고, 현 시점에서 가장 훌륭한 툴이 Rational Team Concert 라 판단되어 진행중이다[2].

최근엔 지난 팀에서 RTC 를 전파할 때 한꺼번에 너무 많은 것을 이해시키려 한 경향이 컸었다는 생각이 든다. 따라올 수 있는 사람들은 따라왔지만, 제법 많은 사람들은 너무 많은 변화에 기겁을 하고 섵불리 도전하지 못했을 수도 있다. 여기에는 RTC 의 다양한 기능뿐 아니라 방법론과 사상도 포함된다. 예를 들어, 기본적인 개발 방법론에도 익숙치 않은 사람들에게 애자일이니 스크럼이니 하는 이야기까지 짧은 시간에 전파하려 한 것은 좋지 않은 시도였던듯 싶다.

그래서 이번엔 이런 이질적인 내용을 최소화하는 방법을 채택해보기로 하였다. 팀에서 업무를 진행하며 이루어지는 실제 활동들을 use case 로 잡아, RTC 를 사용했을 때의 모습을 긴 시간에 걸쳐 조금씩 보여주려 한다. 현재 잡아놓은 use case 들은 아래와 같다.

  • MBO 관리
    • 그룹장의 MBO 에서 각 사원의 세부 task 까지 한 눈에 확인 가능.
    • 자신이 하고 있는 일이 팀의 어떤 목표와 관련되어 있는지 항시 인지할 수 있다.
  • 주간 보고 (Weekly Meeting)
    • Scrum 의 Sprint 주기를 1주로 하면 현행 주간 보고 시스템과 차이가 최소화된다.
    • 현 시스템을 대체하는 것으로 시작해 진입 장벽을 낮추고, 차차 개선시킨다.
    • 현 주간 보고 방식에 비해 context-awareness 가 월등히 높다.
  • 일일 작업 관리 (개발자 관점)
    • 개발자 관점에서 매일매일 자신의 task 를 효율적으로 관리하는 방법을 보여준다.
  • 일일 작업 관리 (리더 관점)
    • 리더 관점에서 팀의 업무 진행 상황을 빠르게 파악하여, 부하 분산, 우선 순위 조정, 이슈의 빠른 해결 등을 도와주는 방법을 보여준다.
  • 실시간 리포팅 (Work Load, Progress, Risk, Open Issues and Defects, ..)
    • 팀원과 리더뿐 아니라  모든 stake holder 들이 별도의 보고 요청 없이 실시간으로 과제의 진행사항을 파악할 수 있는 방법을 다룬다.
  • Review & Planning & Retrospective
    • RTC 활용으로 정보 공유가 원활해지므로, weekly meeting 을 현행 주단위 업무 보고 성격에서 스크럼 형태의 효율적 회의로 변화시킨다.
    • 이 과정에서 회고 (retrospective) 의 중요성을 강조한다.
  • 요구사항부터 구체적 기능 태스크, 구현, 빌드, 검증까지..
    • 태스크와 그 구현에 따른 코드 변경, 빌드, 테스트, 결함 등록, 수정 완료 에 이르는 과정을 데모를 통해 보여준다.

기본적인 활용에 익숙해지면 여러 동영상 자료들도 활용해 볼까 생각중이다.


References

  1. IBM Rational Team Concert (jazz.net)
  2. Choose Right Tools for Efficient Collaboration (wegra.org)
명시적 공정 제어 모델과 경험주의적 공정 제어 모델
Mar 8th, 2010 by Wegra Lee

거의 아무런 정보도 없이 이제 시작하는 프로젝트에 대해 일정을 내놓으라는 이야기를 너무 많이 들어왔고, 그 때마다 신뢰 구간 -50% ~ + 300% 의 일정이 그렇게 중요하냐고 묻으며 항의해보았다. 돌아오는 답변은, ‘그래도 일정은 필요하지 않느냐?’ 정도.. -_-a 결국 ‘일정을 위한 일정’ 만들기를 하게 된다.

어쩔 수 없이 일정을 내어주며, ‘이것은 신뢰성 10% 에요’ 라고 강조해보지만 절대 귀담아 듣지 않는다. 그 일정을 기준으로 종속된 모듈/기능 등을 고려한 전체 일정이 산출되고 임원들에게까지 보고된다. 그리고 기획과 마케팅 부서 역시 이를 기준으로 상품화 일정과 마케팅 일정을 등을 잡아 놓는다.

조금만 지나면 ‘신뢰성 10%’ 일정은 부메랑이 되어 개발자들을 옭아매기 시작한다. 진행중 (예외 없이) 예상치 못했던 문제들이 붉어져 나와도 ‘이미 윗선에 보고가 되어 있고 다른 부서들이 그에 맞춰 움직이고 있기 때문에 어쩔 수 없다. 무슨 수를 써서라도 이 때 끝내야 한다’는 식이다.

중간 관리자 몇 명만 설득해서 될 일은 아니다. 그들 대부분도 스스로를 피해자라 생각하고 있다. (틀린 말은 아니지만, 그들 중 윗사람들의 인식을 바꿔보려고 노력하는 사람은 단 한 명도 만나보지 못했다. 아쉽다.) 그래서 적어도 임원들까지는 제대로된 소프트웨어 개발 모델을 이해시킬 필요가 있다.

하지만 권위도 없고 직급도 낮은 사람들이 아무리 떠들어봐야 먹힐리 만무하다 (당장 바로 윗사람도 귀담아 듣지 않는데 -_-a). 책 좀 보라고 던져 주는 것도 아닌 듯 싶고.. 이런저런 생각을 해보다 우선 참조하기 좋은 블로그에 괜찮은 글을 하나 발췌해 놓기로 했다.

이 글은 스크럼 : 팀의 생산성을 극대화시키는 애자일 방법론 [1] (원서: Agile Software Development with Scrum [2]) 에서 발췌한 내용이다. 2장 ‘스크럼 준비 – 스크럼은 다르다’ 중 프로세스 제어 모델에 대한 블록으로, 저자가 왜 전통적인 프로세스들이 계속 실패하는지에 대한 통찰을 얻게된 계기를 이야기한 부분이다.

나는 1990년대 초반에 MATE라고 불리는 프로세스 관리 제품을 개발하고 라이선스하던 소프트웨어 업체를 운영했다. 우리의 최대 고객은 쿠퍼스 & 라이브랜드와 IBM 이었는데, 그들은 우리가 그들의 방법론을 사용해서 MATE를 개발하기를 원했다. 몇 차례 시도하긴 했으나 그 결과는 전적으로 불만족스러웠다. 당시, 우리 회사의 요구사항은 끊임없이 변하고 있었고 우리는 계속 신기술들을 도입하로 있었는데, 그 방법론은 우리를 도와주기는커녕 오히려 장애물을 만들고 유연성을 떨어뜨리는 등 마치 우리의 발목을 잡는 것과 같았다.

나는 왜 우리 고객들의 방법론이 우리 회사에는 효과가 없는지를 알고 싶었다. 그래서 1995년, 듀폰 연구소의 공정 제어 이론 전문가에게 시스템 개발 방법론에 대한 자문을 구했다. 바바툰데 ‘툰데’ 오거나이케(Babatunde ‘Tunde’ Ogannaike) 박사가 이끄는 전문가들은 산업 공정 제어 분야(industrial process control)에서 가장 존경 받는 이론가들이었다. 그들은 공정 제어에 대해 속속들이 알고 있었다. 심지어 연구자들의 일부는 유명 대학들에서 해당 주제에 대한 강연을 하기도 했다. 그들 모두가 시장 예측에서부터 제품 주문과 배달에 이르기까지 듀폰의 제품 생산 전 공정을 자동화하는데 관여하고 있었다.

듀폰의 연구자들에게 우리의 시스템 개발 프로세들을 살펴보도록 한 것은 듀폰의 연구자들에게 엄청난 우스갯거리를 선사한 거나 마찬가지였다. 그들은 우리 시스템 개발 산업이 전적으로 부적절한 공정 제어 모델에 따라 개발을 하고 있다는 사실에 깜짝 놀랐고 매우 의아해 했다. 듀폰의 연구자들은 시스템 개발이 너무 복잡하고 예측하기 힘들기 때문에, ‘경험주의적’이라고 부르는 다른 공정 제어 모델을 사용해야 한다고 말했다. 그들은 내가 왜 올바르지 못한 길로 가고 있는지를 이해시키기 위해서, “프로세스 역학, 모델링과 제어(Process Dynamics, Modeling and Control)” 라는 산업 공정 제어 이론의 필독서를 권했다.

간단히 말하자면 공정 제어에는 두 가지 주요 접근법이 있다. 하나는 ‘명시적인(defined)’ 공정 제어 모델로서 작업자들이 작업의 모든 부분을 완전히 이해해야 하는 것이다. 사전에 잘 정의된 일련의 입력들이 주어지면 매번 동일한 결과물이 산출된다. 명시적인 프로세는 완료 시점마다 매번 동일한 결과물을 내놓는 경우에 적용 가능하다. 툰데 박사는 내가 그에게 보여준 방법론들이 앞서 설명한 명시적인 프로세스를 사용하려고 했지만, 어느 프로세스나 태스크도 반복 가능하며 예측 가능할 정도로 충분히 명시되어 있지 않다고 말했다. 또한 그는 우리 산업이 명시적인 접근법을 쓰기에는 너무 많은 사고와 창조성을 요구하는 지식 집약적인 사업이라고 했다 툰데 박사는 우리 산업이 명시적인 방법론을 사용할 경우, 통제력 상실과 불완전한(혹은 잘못된) 제품 생산을 초래할 것이라는 사실을 이론적으로 증명해 보였다. 그럼에도 우리 분야의 여러 태스크들이 마치 시작과 종료가 예측 가능하기라도 한 듯이 명시적인 공법 프로세스처럼 서로 종속적으로 연결되어 있다는 점을 놀라워했다.

한편, 툰데 박사는 불확실성을 기반으로 하는 경험주의적인 공정 제어 모델에 대해서도 설명해 주었다. 경험주의 모델은 불완전하게 정의되어 예상 못한 결과를 만들어내는 프로세스를 빈번하게 검사하고 적응하는 방식을 통해 프로젝트를 제어하는 방법을 제공한다. 그는 내게 이 모델을 연구해서 시스템 개발 프로세스에 적용해볼 것을 권유했다.

듀폰 연구소 방문 기간 동안 나는 이 문제에 대한 진정한 통찰을 얻었다. 갑자기 내 안의 무엇인가가 번뜩이더니, 왜 우리 산업의 모든 사람이 시스템을 구축하는 데 그런 문제를 겪는지를 알게 되었다. 즉, 왜 우리 산업이 그런 곤경에 처했고, 형편없는 명성을 갖게 되었는지를 깨달은 것이다. 우리에게 필요한 것은 빈번하고 직접적인 테스트와 그에 뒤이은 즉각적인 수정임에도 불구하고 우리는 마치 조립 라인에서 일하는 것처럼 업무를 처리하는데 시간을 낭비하고 있었던 것이다.

경험주의적 공정 제어 모델은 애자일 측에서 목에 핏대가 서도록 강조하는 것들이다. 빈번한 검사와 즉각적인 적응 과정. 이를 위해 항시 동작 가능한 제품을 만들고 고객과 직접 ‘이것이 원하는 것이 맞는가?’를 확인하고 조정하는 것이다.

전통적인 프로세스에서도 이를 간과하고 있지는 않다. 다만 그 중요성을 제대로 인지하지 못하고 충분히 강조하지 못하고 있었다고 말할 수 있겠다. 그리고 안타깝게도 내가 만나본 SE 전공자들 대부분은 스스로도 깨닫지 못하고 있어 잘못된 사상과 프로세스를 전파하고 강요하고 있었다.


References

  1. 스크럼: 팀의 생산성을 극대화시키는 애자일 방법론 (켄 슈와버, 바이클 비들 | 박일, 김기웅 | 인사이트)
  2. Agile Software Development with Scrum (Ken Schwaber, Mike Beedle | Pearson Education, Inc)
Choose Right Tools for Efficient Collaboration
Mar 7th, 2010 by Wegra Lee

팀 내의 커뮤니케이션이 제대로 이루어지지 않으면 팀의 생산성에 치명적인 영향을 미침은 모두가 잘 인지하고 있는 사실이다.

제때 피드백을 받지 못해 엉뚱한 일을 하거나, 잘못 (혹은 부족하게) 전달된 정보로 인해 엉뚱한 방향으로 진행되어 낭비하는 시간은 오히려 가볍게 여겨진다.

조직이 커질 수록 다른 문제들이 더 크게 부각되는데, 얘를 들면 이러하다. 관리자는 자신의 역할(관리)를 충실히 하기 위해 수시로 현황 보고를 요청하고, 개발자들은 산재한 정보들을 취합해 보고용 자료를 만드느라 일할 시간일 뺏긴다. 작성해 놓은 정보가 검색이 안되어 사람들이 매번 물어본다. 메일 공지로도 뿌리고 직접 설명해주지만, 당장 필요한 사람이 아니면 귀담아 듣지 않아 같은 일이 무한 반복된다.

이런 문제들을 미연에 방지하기 위해 우리는 다양한 협업 툴들을 활용한다. 하지만 이 툴들을 잘못 선택하면 득보다 해가 되는 경우도 심심치 않으니 많이 알아보고 신중히 정하는 것이 좋다. 당장 사용할 인프라가 급하다면 할 수 없지만, 지속적으로 시장을 모니터링하여 더 나은 솔루션을 발견하면 언제든 변경할 수 있다는 자세를 유지하는 것이 좋다.

툴 선택을 잘못했을 시 발생할 수 있는 문제를 실례를 바탕으로 살펴보자.

다음 표는 A Team 에서 선택해 사용하던 툴들과 Rational Team Concert (RTC) [1] 사용을 고려중인 팀의 상황을 비교하고 있다.

Team A RTC Express-C RTC Commercial
Release & Iterations Planning no tools (oneday, MS Project) RTC RTC
Requirements Excel RTC RTC
Tasks no tools RTC RTC
Task Risk Assessment no tools RTC RTC
Defects ClearQuest, Email RTC RTC
Issues Wiki, Email RTC RTC
Source Control Perforce #1 RTC RTC
Static Analysis Prevent, Cloak (seperated tools) RTC (Eclipse Plugins – FindBugs, PMD, ..) RTC (Eclipse Plugins – FindBugs, PMD, ..)
Documents Perforce #2 SVN + Web UI RTC
Continuous Integration QuickBuild RTC RTC
Dashboard Wiki (manual) RTC (auto) RTC (auto)
Status Reports (charts) no tools RTC RTC
Team Organization no tools RTC RTC
Human Resources (absences and work load) no tools RTC RTC
Development (IDE) Eclipse RTC (on Eclipse) – maximum 10 developers RTC (on Eclipse)
Other Information Wiki Wiki Wiki

* 파란색은 비교 우위, 적색은 반대를 의미한다. (by feature/usability)

보다시피 A 팀은 제대로 연동되지 않는 10여개의 툴들을 사용하고 있고, 더욱이 각각의 툴의 사용성 또한 좋지 않은 경우가 많다.

여기서 쉽게 예상되는 사태는 ‘정보 분산’ 과 ‘분산된 정보를 취합하기 위한 엄청난 노력’ 이다. 그 노력의 대부분은 당연히 실무자들의 몫이다. 관리자들은 ‘상황을 정리해서 보고하라’ 는 말 한 마디로 보기 좋게 정리된 보고서를 받아볼 수 있다. 관리자의 의욕이 불탈수록 실무자들은 보고를 위해 정작 중요한 업무 진도는 못나가는 사태가 벌어진다.

심각한 문제가 하나 더 있다. Excel 에 정리되어 있는 요구사항은 몇 달에 한 번 꼴로 꺼내어 보고, 태스크는 체계적으로 관리되고 있지 못하다. 업무 부하량도 측정할 길이 없으니 위에서는 생각나는데로 새로운 일을 꽂아준다. 이렇게 일이 진행되다 보면 내가 이 일을 왜 하고 있는지, 옆 사람은 지금 저 일을 왜 하고 있는지 점점 오리무중이 되어간다. 실무자들은 context-unaware 상태에서 수명 업무만을 처리하는 수동적인 자세로 변해간다.

반면 RTC 를 사용하려는 팀은 2~3 개 정도의 툴만으로 훨씬 많은 요소들을 커버하고 있다. 대부분의 데이터는 하나의 DB 에 통합 관리되며사용성 또한 월등히 뛰어나다. 실무자들은 보고에 신경쓰지 않고 열심히 일에 집중한다. 관리자들은 개발자를 방해할 필요 없이 언제건 툴에서 실시간으로 자동 생성해주는 비주얼한 리포트들을 볼 수 있다.

나아가 내가 작업하고 있는 태스크는 어떤 요구사항에서 나왔는지, 관련된 일은 무엇무엇이 있고, 진척률은 어느 정도이고, 우선 순위는 어떻게 되는지 등 자신이 하고 있는 일의 위치를 항시 정확하게 파악할 수 있다. 어떤 요구사항에 결함이 몇 개 있고, 어떤 빌드에 수정본이 반영되어 있는지까지 쉽게 쉽게 추적이 가능하다.

케이스 별로 자세한 work flow 들을 비교해볼까 하다가 너무 길어져서 생락한다.


References

  1. Rational Team Concert (IBM Rational)
Small but meaningful turning point..
Feb 17th, 2010 by Wegra Lee

From bad team cultures to good team cultures, the transition begins now.

At last I successfully moved to other department about 8 months after I had decided to do it.

It’s a new challenge for me. I’ll be in charge of leading one small development group. The size of it is not decided yet, but expected less than 4 at the beginning. That is perfect to make a robust and productive self-organized team. I’m very excited at the fact that I finally get a chance to do the things what I believe right.

Hopefully, I wanna meet talented and open-minded persons. If not, I must spend much more time to share the visions, philosophy, values, etc. I have plan to overcome it and I can do that, anyway.

Vision is also very important. At that time I led the Mobile SecondLife project around one and half years ago, the situation was really terrible. No developer believed the project has any reasons to keep going. We could say for sure that if we would unveil the product to the public, everyone will laugh, and no one will use it. What if I had the right to decide? Definitely I would cancel it as soon as possible, and dispatch those talented engineers to other valuable projects. Even with the talented members, the project ended up with nothing. Nothing at all. Except some lessons. : )

I learned many lessons from the project. The most important one among them is that a leader must fulfill at least one desire that every members can share and agree on. Here are some examples.

  • The project must be fun. It’s the thumb of the rules.
  • The project must be successful at least from the technical perspective.
  • The product must be meaningful, so members can write its name to their resume with proud.
  • Member’s capabilities must got improved continuously.

I’ll do my best to gift my coworkers an unforgettable experience in a good way.

수용하기.. 혁신을 이끌어 내는 방법
Feb 9th, 2010 by Wegra Lee

쉬어가기[1]는 창의력을 끌어내는데 주안점을 두고 있고, 직접보기[2]는 생각을 현실화시켜 진정 원하는 것을 찾아가는데 초점을 맞추고 있다.

그리고 이제부터 살펴볼 수용하기는 변화를 권하고 받아들임으로써 개발자들에게 능동적 에너지를 불어 넣으려는 자세이다. 따라서 조직에서 권한을 쥐고 있는 윗사람들에게 크게 요구되는 자세이다.

조직에 변화를 불러 일으키려 할 때, 윗사람이 주도하는 하향식(top-down) 시도는 좋은 결과를 낳기 어렵다[3][4]. 특히나 한국처럼 수직적 위계질서가 철저한 문화에서는 윗사람의 지나가는 말 한 마디가 수십, 수백명을 고생하게 만들 만큼 파급이 크다. 심지어 조직 운명이 뒤바뀌기도 한다. 때문에 설사 올바른 말을 하더라도 확대 해석되고 준비도 없이 무조건적으로 즉시 수행하려해서 한 바탕 소동이 벌어지곤 한다.

효과적이고 지속적인 변화를 위해 윗사람에게 필요한 자세는, 변화를 겸허히 수용하고, 그런 분위기를 조성하고 문화를 만들어가는 것이다.

잠시 아쉬운 경험담을 하나 떠올려보겠다. 얼마전 수백명에 달하는 조직 구성원 전체가 모여 이것 저것을 공유하는 자리가 있었다. 그 중 임원들에게 궁금한 것을 여쭐 수 있는 시간이 주어졌고, 이런저런 이야기를 하다가 한 임원께서 조직의 변화에 대해 잠시 언급하셨다.

“조직은 쉽게 변하지 않는다. 조직이 변하길 기대하기보단 각자의 위치에서 스스로 변화시킬 수 있는 것을 찾아보아라.”

다소 차이가 있을 수 있으나 내가 이해한 의미는 이렇다. 현실의 모습을 있는 그대로 솔직히 이야기한 것이고, 남에게 바라기 앞서 스스로 변화를 시도하라는 좋은 이야기였다.

하지만 난 이 말에 적잖이 실망할 수 밖에 없었다. 왜일까? 만약 이렇게 이야기했다면 어땠을까?

“조직은 쉽게 변하지 않는다. 하지만 좋은 의견을 주면 내가 힘이 닿는데까지 그렇게 변화시킬 수 있도록 도와주겠다. 중간층에 있는 분들도 팀원들이 좋은 아이디어를 주면 최대한 반영할 수 있도록 힘써달라. 만약 내 힘이 필요하다면 누구든 도움을 요청하라. 다함께 힘이 닿는데까지 일할 맛 나는 팀을 만들어보자.”

조직은 쉽게 변하지 않는다는 사실엔 변함이 없다. 하지만 전자는 개인의 변화 의지를 크게 억누르는데 반해, 후자는 의욕을 한층 불살라줄 것이다.

중요한 것은.. 말과 격려에서 끝나면 안된다는 것이다. 불편사항을 누구든 편하게 개진할 수 있고, 개선 방법을 논의할 수 있는 장을 마련해 주어야 한다. 사람들이 쉽게 나서지 못한다면, 익명이 보장되는 토론장을 만들어주는 것이 큰 도움이 될 것이다. 애자일 회고(Retrospective) 제도[5]를 도입해 보는 것도 적극 권장한다. 그리고 이렇게해서 나온 좋은 아이디어들을 작은 것부터라도 하나씩 수용해가며 차근차근 개선되는 모습을 보여줘야 한다.

그럼 윗사람들이 주의해야할 점 몇 가지 집어보자.

‘이봐들! 개선 아이디어를 가져와봐!’ 라고 강압하는 것은 좋지 않다. 이런 명령은 실무자들이 스스로 불편사항을 찾고 자율적으로 개선해나가는 분위기에 찬물을 끼얻을 우려가 있다. 단, 익명 보장 등 조치를 취해 주었는데도 아무도 의견 개진 없이 시간만 흐른다면 한 번쯤 발동을 걸어주는 것은 필요할 수 있다.

‘얼마나 개선되었는지 보고해봐!’ 와 같은 요청은 더 큰 위험을 안고 있다. CMMI 나 SPICE 등 개발 역량 평가 모델의 더 높은 등급을 받기 위해 벌어지는 상황이 재현될 가능성이 높다. 다시 말해 수치적으로 측정 가능하고, 형식적인 변화에 치중될 우려가 생긴다. 심할 경우, 개발자들은 변화에 회의를 느끼고 더 이상 적극적으로 참여하지 않게 될 것이다.

가만히 놓아 두어도 개발자들은 알아서 쓸데 없는 일과 꼭 필요하지만 귀찮은 일 그리고 수작업 등을 줄이고 생산성을 높이는 방향으로 변화시킨다. 더 효율적인 솔루션을 찾아 시도해보고 적용한다. 물론 시행착오를 거친다. 그래서 더 안좋아지는 부분이 생기면 되돌아가거나 다른 안을 시도해보며 결국 생각할 수 있는 최선의 방식으로 수렴해간다. 제도와 권위로 가둬놓지만 않으면 팀은 좋은 방향으로 진화해 나갈 수 있다.

정리해보자.

  • 윗사람은 변화를 주도하기 보다는, 변화 에너지를 불어 넣고 변화를 돕고 그 모습을 수용하자.
  • 아랫사람은 능동적으로 변화에 참여하고 장단점을 몸소 체험하며 배우자.
  • 상향식도 하향식도 아니다. 함께 만들어가는 변화이다.

References

  1. 쉬어가기.. 혁신을 이끌어 내는 방법 (wegra.org)
  2. 직접보기.. 혁신을 이끌어 내는 방법 (wegra.org)
  3. 하향식 변화 도입에 대한 환상 (김창준, 애자일 컨설팅)
  4. Bad Team Culture – 변화의 시작.. 상향식? 하향식? (wegra.org)
  5. Bad Team Culture – Lessons Learned as a Last Will (wegra.org)
애자일 도입 실패 이유?
Feb 3rd, 2010 by Wegra Lee

STEN [1] 에서 재미난 설문을 하고 있다. 아직 진행중이지만 상황을 대략 파악할 정도는 나온 듯 싶다.

“국내 프로젝트에서 애자일을 도입했다가 실패했다면 그 이유는 무엇인가?”

1. 국내의 전반적인 소프트웨어 개발 프로세스 성숙도가 낮기 때문 (19.0%)
2. 과도한 애자일 프랙티스를 경험이 부족한 상태에서 여러가지를 동시에 적용하려 하기 때문 (25.4%)
3. 애자일한 개바 프로젝트에서 테스팅을 어떻게 해야할지 잘 모르기 때문 (9.5%)
4. 애자일 개발의 사상이나 이의 도입에 따른 개발 문화의 변화에 대한 고려없이 테크닉만으로 접근하기 때문 (44.4%)
5. 기타 (1.6%)

나는 4번을 찍었다. 물론 다른 이유들도 많다. 예를 들어 팀원 & 조직 전체가 변화의 필요성에 대해 공감한 상태에서 진행하느냐도 포함될 수 있다. 그리고 어느 하나의 이유보다는 여러 가지가 복합적이다.

나도 애자일 도입을 외치지만, 수많은 경험을 통해 아주 신중하게 접근해야 함은 뼈저리게 느끼고 있다. 어설프게 접근했다가는 ‘해봤는데.. 별 효과 없더라.’라는 부정적 인식만 남기기 쉽기 때문이다. 그리고 이는 소위 heavyweight 개발 프로세스 등 SE 가 지금껏 저질러왔던 과오이다. 애자일에서도 똑같은 일이 반복된다면 개발 문화를 개선할 수 있는 기회가 언제 다시 올 지 예측하기 어렵다.


References

  1. STEN (Software Test Engineer Network)
[updated] 직접보기.. 혁신을 이끌어내는 방법
Feb 2nd, 2010 by Wegra Lee

쉬어가기.. 혁신을 이끌어내는 방법 [1]‘ 에서는 개발자들에게 쉬어갈 수 있는 시간을 제공함으로써 창의와 혁신을 이끌어는내는 이야기를 해보았다. 이번에는 ‘직접보기’라는 주제로 비슷한 이야기를 해보려 한다.

‘직접보기’ 가 필요한 이유는 아래의 그림을 보고 생각해보자. 이 그림이 말하고자 하는 원목적은 완전히 동일하진 않지만, 실물을 보지 않고 커뮤니케이션 했을 때의 문제를 효과적으로 말해주고 있다.

정리하면 고객이 원하는 것을 각 사람/조직마다 다르게 이해하고 있으며 심지어 고객 스스로도 자신이 무엇을 필요로 하는지 알지 못한다 것이다.

시장 조사를 토대로 고객의 needs 를 모두 만족시킨 제품의 출시 후 반응이 그리 좋지 않은 수많은 사례들을 잘 설명할 수 있는 논리이기도 하다.

혁신적인 제품을 잘 만들어내기로 유명한 애플(Apple)사의 경우, 신제품을 만들 때 시장 조사를 아얘 하지 않는 것으로도 유명하다(You Can’t Innovate Like Apple [2]). 시장에 존재하지 않는 제품에 대해 물어봐야 가치 있는 대답을 구하기 어렵기 때문이다. 대신 스스로 계속해서 실제품 수준의 프로토타입을 수없이 만들어보면서 직접 만져보고 써보며 자신들이 정말 이 제품을 원하는가를 판단한다. 그 결과 애플의 제품들은 종종 시장에서 당연히 필요하다고 생각하는 기능이 빠지기도 하고 이미 더 나은 제품들이 수두룩한데~ 라고 평가절하되곤 한다.

이미 만들어진 제품에 대해서는 다르다. 직접 사용해본 사용자들의 피드백은 소중하다. 애플 리테일 스토어가 중요한 역할을 수행하는데, 리테일 스토어의 직원들은 고객이 와서 들려준 이야기들을 놓치지 않고 본사로 보고하게 되어 있다. 그래서 스티브 잡스는 아이디어 도둑(유명 마케터 이해선 대표의 메시지 [3])이라는 말이 나오기까지 했다.

고객의 소리를 듣는 방식에 있어 두 경우가 다르다고 이야기했지만, 사실 그 원리는 동일하다. 바로 제품을 직접 만져보고 사용해본 사람들의 소리를 듣는다는 것이다.

이는 사실 애자일, 전통 할 것 없이 거의 모든 소프트웨어 개발 방법론에 중요하게 다루는 주제이고, 결론 또한 항시 동일하다. 짧은 반복 주기로 매 주기마다 동작 가능한 제품을 내놓고, 이를 고객에게 보여주고 피드백을 받는다. ‘당신이 말한 것을 우리는 이렇게 이해했는데, 이것이 정말 당신이 원했던 것이오?’ 를 확인하는 가장 중요한 절차인 것이다. 진정 공존을 원한다면 이 과정에서 쓸데없는 과장과 화려한 프리젠테이션은 없어져야 한다. 그리고 프로젝트 진행에 관련된 주요 인력들이 다 참석하는 것이 좋다. 고객, 프로젝트 리더, 영업 담당자, 주요 개발자들 등이 포함된다. 이들이 자주 모여 현실을 냉정하게 보고 허물없는 이야기를 하다보면 다음과 같은 반응들을 심심치 않게 목격할 수 있을 것이다.

  1. 내가 말했던 건 이게 아니었어요. 이러저런 모습을 상상했었는데요. 다음 릴리즈땐 이렇게 고쳐봐주세요.
  2. 내가 의도했던게 이게 맞긴 한데.. 직접 써보니 좀 이상하군요. 다른 아이디어가 있을까요?
  3. 이 부분은 제 생각과 다르긴 하지만.. 솔직히 지금이 더 좋아 보이는군요. 이대로 갑시다.

직접 보기는 서로의 생각을 확인하고 공유할 수 있는 가장 좋은 방법이며, 다음 방향을 결정짓기 위한 논의를 시작하기 위한 믿음직한 베이스가 되어준다.

또한 개발자들에게는 자신들의 창의력과 열정을 어필할 수 있는 절호의 기회가 되기도 한다. 직접 구현하면서 가장 먼저 써보게 되는 개발자들은 가장 빠르게 피드백을 줄 수 있는 훌륭한 고객인 셈이다. 이해한 요구사항대로 구현했을 시 불편한 부분이 있거나 더 나은 안이 떠오르면 릴리즈 전에 그 아이디어를 정리해두자. 가능하다면 직접 구현해서 보여주는 것이 가장 좋다. 직접 사용해본 고객과 말이나 문서 정도로만 본 고객은 확연히 다른 반응을 보인다.

이런식으로 개발자들의 능력을 인정받고 발언권을 강화해두는 것이 조직 전체의 커뮤니케이션과 생산성 향상, 제품 혁신에 긍정적인 영향을 줄 것이다. 개발자들은 기본적으로 창의적인 인력들이며, 이에 더해 현실적이다. Sci-fi 영화에나 나올 법한 허무 맹랑한 꿈을 꾸지도 않고, 일부러 과장하려는 경향도 적다. 먼 과거와 달리 골방의 괴짜들이 모여 있는 집단도 아니다. 윗사람들보다 신세대이며 소비의 주체라는 장점도 있다.

결론?

조직은 제품을 직접 보고 함께 이야기하는 문화를 정착시킴으로써 많은 것을 얻을 수 있다. 단, 어설프게 릴리즈 압박용으로만 오용하지 않도록 주의하자. 상향식 변화는 실패할 것이며, 하향식 변화는 성공한 것 처럼 보일 것이다. ^^ [4]

[updated]

사례를 몇 가지 추가해보기로 하였다.

  • Developing Torchlight [5] – Runic Games 사에서 Torchlight 라는 게임을 제작하는 방식을 이야기한다. 그들은 짧은 주기로 항시 play 가능한 게임을 만들어 개발자, QA 팀, 심지어 그드의 가족, 친구들까지 초대해서 게임을 즐기게 했다고 한다. 시장에서의 성공 여부는 아직 판가름하기 이르지만 기대를 가지고 지켜보고 있다.
  • 와우 성공 요인은? [6] – 초창기 와우 개발을 이끌었던 블리자드의 수석 PD 인 셰인 다비리 를 인터뷰한 내용이다. 초창기 가장 어려웠던 점 중 하나는 블라지드로써는 낯선 장르였던 MMORPG 의 비전을 경영진에 설득하는 것이었다고 한다. 직접 만들어 알파 버전을 보여주니, 절대 성공할 수 없다고 말하던 사람마저 하루 아침에 자신의 편이 되었다 한다.
  • Eclipse [7] 와 Jazz/RTC [8] – 오픈소스 개발 환경 프로젝트 중 역사상 가장 성공적인 프로젝트 중 하나인 Eclipse 와 그 개발 과정에서 얻은 노하우까지 툴에 녹이고 있는 Jazz/RTC 프로젝트도 좋은 예가 될 수 있다. 이들은 1년 주기의 정식 릴리스 사이에 6주 정도의 간격으로 다수의 안정적인 Milestone 버전을 내놓는다. 그리고 이전 릴리스 대비 어떤 기능이 개선되었는지 알기 쉽게 보여주는 New & Noteworthy 를 함께 알려주어서 사용자들이 정식 릴리스를 기다리지 않고도 새로운 기능들을 빠르게 접해볼 수 있다. Milestone 버전은 충분히 안정적이기 때문에 critical 한 프로젝트가 아니면 큰 부담 없이 새 milestone 을 테스트해본다. 이런 방식으로 사용자 커뮤니트의 빠른 피드백을 유도해 지속적으로 다음 릴리스에 반영해나간다.
  • Mobile SecondLife [9] – 내가 참여해 진행하다 중단된 프로젝트다. 과제 초창기부터 개발진에서는 도저히 성공 가능성이 없다고, 이걸 누가 쓰겠냐며 과제의 의미를 찾지 못하고 있었다. 링크의 데모는 연구 성격의 개념적 시연이어서 상당히 제한적인 환경에서만 동작 가능했다. 이를 바로 상품화하려 하니 현실적인 제약들 때문에 흥미로운 개념들의 거의 모두를 다 들어낼 수 밖에 없었다. 남은 것만으로는 정말 시도할 가치가 없는 과제였다. 하지만 그 목소리가 경영진에까지 전파되지는 못했다. 수개월간의 고생 끝에 만들어진 베타 버전을 임원에게 시연한 바로 다음날 과제는 바로 중단되었다.

References

  1. 쉬어가기.. 혁신을 이끌어내는 방법 (wegra.org)
  2. You Can’t Innovate Like Apple (Pragmatic Marketing)
  3. 유명 마케터 이해선 대표의 메시지 (제레미의 TV 2.0 이야기기)
  4. Bad Team Culture – 변화의 시작.. 상향식? 하향식? (wegra.org)
  5. Agile Approach in Game Development (wegra.org)
  6. 와우 성공 요인은? 전 수석 PD 셰인 다비리 인터뷰 (Inven Communications)
  7. Eclipse (Eclipse Foundation)
  8. Jazz/RTC (IBM Rational)
  9. Mobile SecondLife (Samsung)
»  Substance: WordPress   »  Style: Ahren Ahimsa