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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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)을 사용할 때도 그대로 적용/응용할 수 있다.

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

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의 빌드 서버는 이 정의를 바탕으로 빌드 엔진에 빌드를 요청한다. 아래의 그림은 내가 구축하기 원하는 빌드 전략이다.

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

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

[u] Story 의 naming convention 을 Story 방식으로 변경함.

팀 내 Rational Team Concert 적용을 위한 가이드 제작 중 유용한 팁이 있어 공유한다.

RTC 에서 Scrum 템플릿을 사용할 경우, 플래닝에 사용되는 work item 타입은 기본적으로 (범위가 큰 것부터 차례로) Epic, Story, Task, 이렇게 세 가지이다. Scrum에 문외한인 사람들뿐 아니라, Scrum 에 나름 익숙한 사람들도 계획을 잡기에 익숙해지기까지는 제법 많은 난관에 부딪힌다. 이에 내 경험을 바탕으로 나름의 노하우를 정리해보았다. 이 방식을 잘 익히고 따른다면 계획을 잡는데 많은 도움이 되리라 확신한다.

Work Item Hierarchy vs. Iteration Hierarchy

• Epic 은 Release Backlog 이상 레벨에만 존재한다. Product Backlog 는 당연히 이에 해당되며, Sprint(Iteration) Backlog 에 나타나면 안된다.
• Story 는 Sprint Backlog 에 할당된다.
• Story 가 한 Sprint 에 끝낼 수 없을만큼 크다면 타입을 Epic 으로 변경한다.
• 반대로, Epic 이 한 Sprint 에 끝날 수 있을만큼 작다면 Story 로 변경한다.
• Task 는 당연히 Sprint Backlog 에 할당된다.

덤으로..

• Epic/Story 에는 owner 를 할당하지 않는다. (Task 에만 owner 를 할당하라.)
• Task 의 크기는 4시간 이내가 적당하다. (이를 초과하면 두 개 이상의 더 작은 Task 로 분할하라.)
• Task 밑에 하위 Task 가 존재할 수 없다.

Work Item Hierarchy and Progress

• Backlog 진척도 = Backlog 안의 모든 Story 들의 Story Point 총합.
• Epic 진척도 = 모든 하위 Story 들의 Story Point 총합.
• Story 진척도 = 모든 하위 Task 들의 작업 시간 총합.

추가로..

• Story Point 는 Release Burndown 차트 생성의 기초 자료가 된다.
• 작업 시간은 Sprint Burndown 차트 생성의 기초 자료가 된다.

Work Item Naming Conventions

• Epic: 고수준 요구사항 – ‘명사’ 혹은 ‘명사구’.
• Story: 저수준 요구사항 – ‘주어 + { MUST | SHOULD | MAY } + be able to..’.
• Task: 명령문 – ‘동사 + 목적어’.

스크럼이나 유사 Agile 방식에 익숙하지 않다면 Story 의 naming 이 생소할 수 있다. 생각해보면 간단하다. ‘고객/사용자가 이 제품(Product)으로 무엇을 할 수 있다.’ 의 형태이다. Story 를 이렇게 작성할 때 얻게되는 대표적인 이점은 아래와 같다.

1. 사용자와 고객의 관점에서 요구사항이 정리되므로, 커뮤니케이션 로드와 오해를 최소화시킨다.
2. 개발자에게는 구현 목적을 명확히 해준다. (이 기능이 고객에게 어떤 가치를 제공하는지 쉽게 알 수 있다.)
3. 고객에게 불필요한 요구사항이 포함되는 것을 최소화시킨다. (주로 엔지니어의 흥미나 욕심이 반영될 경우 발생한다.)
4. Story 그대로 사용자 테스트 항목이 되고 데모 시나리오가 된다.

혹 스크럼 형태의 Story 네이밍에 익숙하지 않다면 아래와 같은 방식도 시도해볼 수 있다. 하지만 처음 러닝 커브는 작을 지라도, 경험상 정통 스토리 방식이 더욱 효과적이다.

• Story: 저수준 요구사항 – ‘주어 + { MUST | SHOULD | MAY } + 동사 + 목적어’.

새로 옮긴 팀에 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)

몇달 전에 프로젝트 투명성(Project Transparency)에 대한 글[1]을 올린 적이 있다. 당시에는 프로젝트에 투명성을 부여함으로써 얻을 수 있는 장점을 중심으로 설명하면서, 이를 읽은 프로젝트 팀들에서 투명성 확보를 위해 노력해주길 바라며 글을 적었다. 하지만 최근에 들어서는 관리자들이 일부러 과제를 불투명하게 만들고 있는 것이 아닌가 하는 의구심이 들기 시작했다. 아니! 감시 받는게 아니냐는 느낌을 떨치기 어려운 실무자들도 아니고, 오히려 현 상황을 정확히 알고 싶어할 듯한 관리자들이 도대체 왜? 지금부터 천천히 이야기 해보기로 하자.

나는 Rational Team Concert (RTC) [2] 라는 Application Lifecycle Management 시스템은 팀 내에 소개/교육/운영하고, 몇 차례에 걸처 그 결과를 공유한 적이 있다. 당시 (지금까지도) 우리 팀은  과제 시작 후 크고 작은 릴리스 중 단 한 번도 목표일을 지켜본 적이 없었고, 지연 기간도 들쑥날쑥 예측이 어려웠다.  릴리스가 끝나고 나서야 비로서 ‘아! 이번엔 이만큼 지연됐구나’를 알 정도였다[3].

수 개월 동안 몇 차례의 릴리스 기간을 거치면서 RTC 가 보여주는 정보는 항시 일관적이고 명확했다. ‘현 상태로는 일정을 맞출  확률은 0% 이다.’ ‘당신의 팀은 task를 끝내기도 전에 끊임없이 새로운 task들을 더 추가한다.’ ‘당신 팀의 업무 수행 능력은 이 정도이다.’ ‘따라서 목표를 다 이루려면 x 일 정도 지연될 것이다.’ ‘일정에 맞추려면 a, b, c 등의 task 를 뒤로 미뤄야 한다.’ 이런 정보들을 한 눈에 확인할 수 있는 실시간으로 그래프를 제시해준다. 대표적인 그래프인 burndown chart 의 예[4]는 아래와 같다.그림과 같이 프로젝트의 현 상황과 진행 추이, 예상 완료 시점 등을 바로 확인할 수 있는 그래프를 전체 팀은 물론 서브팀별로 만들어주고, 누구나 보고 싶으면 언제든 웹을 통해 접근할 수 있다.

(Note: 위 그림은 우리 과제에서 얻은 실제 데이터 도, RTC 가 생성한 그래프도 아니다. 이해를 돕기 위한 단순 참고용이다. 또한 burndown chart 의 개념은 RTC 라는 특정 툴에 종속적이지 않다. Agile/Scrum 쪽에서 널리 활용하는 프로젝트 관리 기법으로 툴 없이도 쉽게 만들어 활용할 수 있다. RTC는 단지 이를 지원할 뿐..)

자! 어떤 결과가 예상되는가? 실무자들 중에는 사용해보고 싶다는 사람들이 조금씩 늘어났다. 반면 관리자들 중에서 관심을 가지는 사람은  거의 전무했다(그나마 계정만 만들고 실제 사용은 안함). RTC 라는 새로운 환경에 적응하기 위해 가장 많은 변화와 노력을 기울여야 하는 실무자들이 관심을 더 보이는 이유는 무엇일까? 역으로, 프로젝트의 목표와 일정을 세우고, 우선 순위를 조정하고, 업무 부하를 관리해야 하는 관리자들은 도데체 무엇 때문에 관심 자체를 보이지 않았던 것일까?

실무자들이 쓰는 이유는 주로 이러했다.

• 자신에게 할당된 task 들을 효율적으로 관리/진행/보고하기 위해
• 상사의 말도 안되는 업무 요청에 대한 방어/협상 자료로 활용키 위해
  • 내가 놀고 있나요? 그 일을 하길 원한다면, 여기 쌓여 있는 현 일들 중 어떤 것을 미룰까요?

관리자들이 쓰는 이유는 알 수 없다. 쓰는 사람이 없으니 -_-a

그렇다면 관리자들이 외면하는 이유는? 물론 수많은 요인들이 복합적으로 작용했고, 사람들마나 차이도 많다. (Note: 설문조사를 한 것은 아니고.. 대부분은 이런저런 주변 정황과 평소의 대화들을 토대로 유추해본 것 뿐이다.)

• 현 상태에 만족해서 (여러 사람과 이야기해보았는데, 우리팀에는 해당되지 않는다. 모두가 불만이다.)
• 단지, 새로운 것을 익힐 심적/시간적 여유가 없어서 (제법 많다. 위에서 시키지 않은 일에 에너지를 할애하길 꺼려한다.)
• 다년간 체득한 ‘나서서 좋을 것 없다’ 는 경험 때문에 (조금 있다. 정말 좋으면 남들이 써보고 전파해주겠지 하는 생각.)
• 귀찮아서 (역시 제법 되어 보인다. 새로운 것은 익히기 보단 다소 불편하더라도 익숙한 것에 머무르려 한다. 시도조차 안해본다.)
• 투명해지면 안된다고 생각한다. (조금 있어 보인다. 이 글의 주제이므로 바로 뒤에 별도로 설명하겠다.)
• 기타.. (여러가지 더 떠오르지만 주제와 큰 관련이 없으므로 생략)

투명해지면 안된다고 생각하는 사람들은 상위 지배층과 외부 사람들(stakeholder, customer 등)을 대하는 사람들일 경우가 많다. 이들에게 투명한 과제가 장점을 발휘하려면, 그 과제가 정말 잘 진행되고 있어야 한다는 전제가 깔린다. 이러저러한 문제들이 산적한 상태에서 잘못 공개되면 지원이 줄어들고 대기 수요가 빠져나간다. 이들에게는 안좋은 것을 숨기고 희망찬 메시지만 전달해주어야 한다. 단번에 ‘3달쯤 지연될 겁니다’라고 얘기하면 ‘그렇게까지는 못 기다립니다’라고 하지만, ‘1주일만 더 기다려주세요’를 여러차례 반복하면 ‘이왕 기다린 거, 이번엔 꼭 된다니깐 조금만 더 기다려보지.  등 돌리기도 늦은 것 같고..’ 하는 반응을 이끌어낼 수 있다.

위와 같은 이유로 의도적으로 투명성을 제한하려는 사람들이 있다고 믿는 근거는.. ‘팀 리더로써 가장 중요한 것은 프로젝트를 부러뜨리지 않는 것’ 이라거나, ‘이런 건 누구누구가 알면 안되는데’ 라며 정보 공개를 불편해하는 발언 등을 하는 윗 사람들을 종종 보았기 때문이다. 프로젝트를 계속 유지하는 것은 물론 중요하다. 하지만 외부에 알려진 것 대비 심각하게 안좋은 상황에서도 무리하게 정보를 숨기는 것은 과연 어떨까? 상황을 만회하기 위해 뒤에서 열심히 고생하는 개발자들과 이를 믿고 투자하는 사람, 제품을 기다리는 고객 모두에게 악영향을 미치게 된다. 투자자가 개발팀이 속한 회사 자체라면(내부 프로젝트), 그 팀은 프로젝트를 유지할 수록 회사의 경쟁력을 떨어뜨리게 된다.

다른 관점에서도 불투명한 과제가 (부정적인 의미에서) 도움이 될 때가 있다. 우리 팀의 모습을 앞서의 그림에 맞춰 비유해보면, 윗사람은 day 10 에 ‘자! 내일이 드디어 릴리스 날입니다. 오늘 저녁까지 남은 일들을 모두 완료해 주시고, 검증이 완료될 때까지 자리를 지켜주세요.’ 라고 당당히 요구하고, 또 그것이 개발자들에게 먹힌다. ‘얼마나 걸릴까요?’ 라는 질문은 없다. ‘반드시 끝내세요.’ 라는 요청이 전부이다. 실무자들은 불만이 있어도 드러내놓고 표출하지도 못하고, 밤 늦게나 자정을 넘어서까지 일을 한다. 당연히 기적은 일어나지 않는다. 만약 위와 같은 정보가 다 공개되어 있다면? 윗사람이 앞서와 같은 요구 자체도 할 수 없겠지만, 만약 그런 요구를 한다면 ‘당신은 눈이 없소?’ 라고 반박해도 할 말이 없을 것이다. 즉 과제가 투명해지면 지금까지와 같은 무리한 명령을 내릴 수 없다.

이상의 이유들로, 수단 방법을 가리지 않고 과제를 살리려 한다거나 전통적(?) 지배체제를 유지하고자 한다면, 프로젝트가 투명해지는 것은 커다란 위험요소가 될 수 있다. 이에 해당하는 사람들은 의도적으로 진행상태를 숨길 수 있다.

만약 이런 현상이 정말로 의도적으로 이루어진 것이라면 개선하기란 정말 쉽지 않다. 앞서 언급했듯, 팀을 이렇게 만든 사람들은 대부분 프로젝트 방향을 좌지우지할 수 있는 힘있는 사람들이기 때문이다. 자료를 아무리 제시해도, 개선의 움직임이 보이긴 커녕 거들떠도 보지 않는다면 실무자들도 제풀에 지쳐 변화를 포기한다. 힘있는 자들의 마인드가 바뀌지 않으면 조직의 문화를 바꾸는 것은 거의 불가능하다.

정리: 관리자들 대부분이 이와 같다는 의미는 절대 아니지만, 그 중 일부가 이런 생각을 어느 정도 가지고 있는 것은 분명한 것 같다. 따지고 보면 비단 특정 팀이나 회사, 소프트웨어 개발에만 국한된 현상도 아니다. 정보를 통제하는 언론, 기업의 홍보 부서, 조직의 대변인, 심지어 모든 사람 개개인이 외부로부터 자신을 지키기 위해 어느 정도는 이런 성향을 가지고 있다. 하지만 숨기는 대상에 외부 경쟁자들뿐 아니라 자신들을 믿고 따르는 조직원들까지 포함시켜 그들에게까지 희생을 강요하는 상황에 이른다면 문제는 심각하다. 이런 조직에서 과연 얼마나 많은 사람들이 진심으로 자신의 역량을 모두 쏟아 부어줄까? 하나의 팀이라고 말하기조차 부끄럽다.

---

References

1. 프로젝트 투명성 (wegra.org)
2. Rational Team Concert (IBM Rational)
3. [나쁜 팀 문화] 점진적 지연 (wegra.org)
4. Burndown chart (wikipedia)