지난번 글(새로운 툴을 대하는 자세)에서도 언급했듯, 나는 조직에 많은 툴들을 전파해보았다(혹은 전파하려 하였다). 그 중 규모면에서나 영향력면에서나 가장 큰 툴은 바로 Rational Team Concert (RTC) 일 것이다. 내가 접해본 툴들 중 가장 마음에 드는 툴이기도 하다. 그런 이유로 수년간에 걸쳐, 다양한 방법으로 팀원들을 끌어들이려 노력해보고, 한 때 좋은 분위기로 흘러가기도 했지만.. 현 시점에서 결론을 내려보면 ‘완전 실패’다. 자.. 이제부터 내가 느낀 실패 원인을 살짝 정리해보겠다.
자잘한 원인들을 모두 나열하자면 한도 끝도 없을테고 초점도 흐려질듯하니 생략하고, 내가 생각하는 가장 근본적인 원인만 다루려 한다. 바로 (주로 유교의 영향이 컸을 듯한) ‘수직적 문화’이다.
우리 문화는 서열을 중시한다. 조직에서의 서열은 이렇게 매겨진다.
이 서열을 뛰어넘기란 여간 어려운 게 아니다. 아무리 능력이 좋아도 직급이 더 높은 사람을 부릴 수 없으며, 심지어 같은 직급과 같은 연차라도 나이가 한 살이라도 더 많은 사람을 밑에 두기란 쉽지 않다. 여러 가지 예가 있다.
특히 직급은 우리 조직 시스템에서 너무도 중요한 축을 담당한다. 말단 사원을 제외하고는 모든 사람들을 호칭할 때 직급을 붙여준다. 대부분은 때되면 붙여주는 직급이지만, 이를 생략하고 불렀다간 관계가 소원해질 것을 각오해야 한다. ^^;
굳이 회사에서만 예를 찾으려할 필요도 없다.
불행히도 이런 문화는 우리가 쓰는 언어에 의해 아주 어렸을 때부터, 거의 언어를 배우기 시작하면서부터 주입된다. 한 살이라도 많으면 형, 누나, 오빠, 언니가 되고 그들에게는 말을 높이라고 교육받는다. 윗사람을 공경하는 문화야 칭송되기도 하고, 그리 나쁘지는 않은 문화라 생각한다. 다만 아쉬운 것은 단순히 나이 많은 이에 대한 어휘와, 정말 존경이나 높은 사람에 대한 예우로써 쓰는 어휘에 차이가 없다는 점이다. 즉, 우리는 존경과 나이 많음을 명확하게 구분짓지 않기 때문에 알게모르게 이 둘을 동일시 시킨다. 언어가 인간의 사고를 지배하기 때문이다. 초등학생만 되어도 선배는 후배에게 일을 시키고, 후배는 선배의 명령을 따르는 것이 몸에 익어버린다. 갑으로써 누릴 수 있는 힘과 을로써의 자세를 사회 관계를 처음 쌓게 되면서부터 체득하게 된다. 그리고 성인이 될 때까지 단 한 번도 이에서 벗어난 문화를 경험하지 못하고 성장한다. (채벌에 관대하게 된 데에도 많은 영향을 미쳤으리라 믿는다.)
이렇게 우리는 협동과 협업보다는 명령 하달과 수행 체제에 적합하게 훈련되었다. 평등한 관계 속에서 협업이 중시되는 사회에서는 뛰어난 리더가 중심이 되지만, 명령과 수행에 의해 움직이는 사회에서는 냉철한 관리자가 더 중요해진다.
이쯤에서 RTC를 잠시 살펴보자. 툴에는 툴 설계자의 노하우와 철학이 담겨있다.그럼 RTC 설계를 주도한 에릭 감마는 어떤 생각을 가지고 이 툴을 만들었을까. 이런저런 이야기를 하고 있지만, 핵심은 효율적인 협업과 투명성이다. 관리와 통제가 아닌 것이다.
우리 사회도 물론 협업과 투명성을 강조하지만, 평등한 관계에서의 협업/투명성과 수직적 관계에서의 그 의미는 완전히 달라진다. 후자에서의 협업은 같은 등급의 사람들끼리 잘 협동하고, 높은 사람의 말을 잘 따르는 것이다. 투명성은 높은 위치의 사람이 낮은 위치의 사람이 땡땡이 치지 못하게 잘 감시할 수 있는 일방적인 하향 투명성을 뜻한다. 협업은 그렇다 쳐도.. 투명성에 대해서는 실무자쪽에서 더욱 방어적으로 나오는 이유가 되기도 한다. 갑은 을을 마음대로 부릴 수 있음을 어려서부터 익히 배워왔기 때문에, 을은 갑으로부터 최대한 자신을 보호하고 싶어한다. 상향 투명성은 생각하기도 힘들고, 동급의 실무자들간 투명성도 그리 환영받지 못한다. 아랫 사람은 위에서 내린 명령만 잘 수행하면 되는 것이고, 그것이 어떻게 조합되어 전체를 만드는지는 윗사람이 생각할 문제이다. 또한 피지배 계층이 너무 많은 정보를 가지고 있다면 지배하기기 쉽지 않다. 과거 평민 이하에겐 교육을 시키지 않은 이유와 같다. 예를 들어, 지금까지의 과제 진척률이 고스란히 공개된다면 단순 채찍질용 일정 단축 요청 같은 것은 의도한 효과를 발휘하기 어렵다.
몇 년 전, 우리의 행태를 비판하며 프로젝트 투명성에 대한 생각도 끄적여 봤었지만, 하루 아침에 변화시키엔 수직적 문화의 뿌리는 우리 사회에 너무 깊게까지 내려 있다. 나이 차이가 수십년 이상 되는 사람들이 모여 있는 거대 조직에서는 말도 안되는 이상향일 지도 모르겠다.
이런 이질적인 동서양 문화에서 파생되는 또 하나의 심각한 문제는 바로 실무자로써의 생명이 짧다는 점이다.
일반적으로 사원으로 입사했다면 8년쯤 후, 박사로 입사했다면 거의 곧바로 관리자의 역할을 맡게된다. 편차가 심하긴 하지만 평균은 대략 이와 비슷할 것이다. 심지어 대규모 플랫폼을 개발하는 팀에서조차, 능력있는 고참 실무자를 아키텍트로 키워보려 면담을 해보면 ‘저도 이제 관리를 익혀야지요’하는 반응이 많다는 이야기도 들었다.
그런데 이것이 수직적 문화와 무슨 관련이 있단 말인가? 계급이 다르다는 것은 (암묵적으로) 하는 일이 다르다는 뜻이다. 승진을 했음에도 하는 일은 과거와 똑같다면 스스로도 실망스럽고, 주변의 위로 소리가 어색하지 않게 느껴진다. 실무 능력이 아무리 뛰어나도 관리 능력이 미달되면 그는 우리 사회에서 도태되기 쉽다.
이와 달리, 수평적 사회에서는 하는 일의 차이보다는 능력의 차이가 보다 중시된다. 조직을 이끄는데 있어 관리는 물론 중요하지만, 직급이 높으면 관리를 해야한다는 인식보다는 개개인이 가장 잘 할 수 있는 일을 하는 것이 올바르다 생각한다. 관리는 직급의 구분 기준보다는 역할이 다른 것으로 인식된다.
그래서 다시.. RTC와 무슨 상관인가? 관리자 입장에서 생각해보자.
기타 등등.. 관리자 입장에서는 전문 개발 툴에 통합된 RTC의 인터페이는 불필요한 기능들로 가득차있고 복잡하고 무겁다. 관리를 잘 하기 위해서는, 스스로 툴을 조작하며 이러저런 상세 정보 속에서 헤매이기보다는, 핵심 정보들만 빨리 캐취해서 적시에 올바른 의사 결정을 내리는 것이 훨씬 중요하다. 즉, RTC는 이런 문화에 속한 관리자를 위한 툴이 아니다.
그렇다면 개발자에게는 좋은가..
이렇듯, 개발자 입장에서도 그리 매력적이라 보기는 힘들다는 생각에 이르렀다. 결국 우리 사회 구성원 누구에게도 딱 맞지 않은.. 먼 나라의 툴이 되어버린 것이다.
물론 우리 사회도 조금씩 변해가고 있다. 요즘의 젊은 벤쳐 기업이나 열린 마음의 사람들로 구성된 작은 팀에서는 RTC가 진정한 힘을 발휘하기에 충분한 문화를 만들 수도 있을 것이다. 그리고 점점 더 상황은 나아질 것이라 믿어 의심치 않는다. 하지만 똑같은 수준에서, 몇 년 내에 급격한 개선이 있을 것이라고는 절대 생각하지 않는다. 조직 문화를 성공적으로 혁신시키려면, 조직 구성원들 대부분이 그 필요성을 마음속 깊이 공유한 상태여야 한다. 그렇지 못한 상태에서 무리하게 추진한다면 모난 돌 취급을 받게 되거나, (추진자가 높은 사람이라면) 마지못해 하는 척만 하다가 머지 않아 원상복귀된다. 혹은 형식만 남아 안함만 못한 상태가 되어버린다.
RTC와 같이 프로젝트 개발 과정 전반을 아루르며 팀 구성원 모두가 써야하는 툴을 온전히 도입하는 것은, 팀 문화 전반을 바꾸려는 시도와 같다. 개인적으로 마음에 들더라도, 팀 차원에서의 적용을 시도하려면 분위기와 팀원들의 성향을 잘 판단해서 추진하기 바란다. 우리팀은 지금 50명 이상이 RTC를 사용하는 듯 싶지만, 에릭 감마가 의도한 방식대로 사용하는 사람도 거의 없을 뿐더러, 관리자쯤 되면 쓰는 사람을 손에 뽑고, 매뉴얼/검색/옆사람을 통해 쉽게 해결할 수 있는 사소한 것들로도 수시로 (전파자인) 나를 찾아 귀찮게 하는 상황이다. ^^;;
가볍게 소개해보고 분위기를 살펴보는 것으로 시작하는 것은 나쁘지 않은 방법일 것이다. 단, 몇 마디 긍정적인 피드백만으로 너무 쉽게 총대를 둘러매진 말길 바란다. ^^
(updated: 내가 이런 글을 적은 이유 중 하나는, 이런 문화적 차이를 미리 알고 충분히 고려해서 적용을 시도해보는 것과, 무턱대고 밀어붙이는 것에는 분명 큰 차이가 있을 거라 믿기 때문이다. 뭐든 내맘에 든다고 다른 사람 맘에도 들거란 생각은 위험하지만, 만약 이 툴이 정말 마음에 든다면, 당신은 주변 사람들과는 다른 사상을 가지고 있을 확률이 많을 것이다. ^^ 실패하더라도 남 탓하지 말고, 사회 탓도 하지 말기 바란다. 이 시스템은 또 이 시스템 만의 장점이 있다. 적응을 해보던지, 정 맞지 않다면 일찌감치 다른 조직을 찾아 모험을 떠나보는 것도..^^)
JUnit in Action 책 출간 기념으로 짤막한 글 하나 번역해본다.
원문: JUnit 4 in 60 Seconds
이번 주말에 JUnit 4 라이브러리를 살펴보고 간단히 정리해보았다.
테스트 케이스임을 명시하기 위해 사용한다. “test”와 같은 접두어를 붙일 필요가 없어졌다. 또한 테스트 클래스 역시 더 이상 “TestCase” 클래스를 확장할 필요가 없어졌다.
@Before와 @After 애너테이션을 사용하여 “setup”과 “testDown” 메서드 명시한다. 이 메서드들은 각각의 테스트 전후로 실행된다.
@BeforeClass와 @AfterClass는 클래스 단위의 “setup”과 “teadDown” 메서드에 붙인다. 1회성 setup, tearDown 메서드라 생각하자. 클래스고 파홈한 모든 테스트케이스들의 전후로 단 1회만 실행된다.
예외 발생이 예상되는 테스트 케이스에는 @Test 애너테이션에 “expected” 파라미터를 사용한다. 발생해야할 예외의 클래스 명을 적어두면 된다.
무시하고자 하는 테스트 케이스에는 @Ignore 애너테이션을 붙인다. 무시하는 이유도 기입해 넣어주면 좋다.
제한 시간이 필요하면 “timeout” 파라미터를 이용한다. 단위는 밀리초이다. 테스트가 제한시간 내에 완료되지 못하면 실패 처리된다.
배열 비교에 쓰일 수 있는 새 단언 메서드들이 추가되었다. 배열의 길이가 같고, 각 원소들이 대상 배열의 대응되는 원소들과 같아야(equal) 한다.
JUnit 3에서 JUnit 4용 테스트를 실행하려면 JUnit4Adapter를 사용한다.
자! 그럼 모두 즐코딩~ ^^
이번엔 지속적 통합 사례를 하나 정리해보겠다. (지속적 통합의 개념 설명은 이곳에..)
이번에 구성해본 지속적 통합(CI) 환경의 구성 요소는 다음과 같다.
비록 RTC라는 상용 툴을 사용하고는 있지만, 이 글에서 다루는 대부분의 내용은 개념적인 것이라, 다른 툴(예: Hudson, TeamCity, CruiseControl)을 사용할 때도 그대로 적용/응용할 수 있다.
전체 시스템을 그림으로 나타내면 대략 다음과 같다.
RTC 서버의 다양한 기능 중, 여기에서는 소스 관리와 빌드 관리, 그리고 웹 UI 정도이다. 거시적인 작업 흐름은 다음과 같다.
개발자나 프로젝트 관련자들은 이런 모든 과정/결과를 언제든 전용 Eclipse UI나 Web UI를 통해 확인할 수 있다.
또한, 어떤 빌드 엔진을 사용할 지, 어떤 스크립트를 사용한 지 등은 모두 configuration 가능하다.
여러 팀, 다양한 과제에 걸쳐 일을 효율적으로 진행하려면 프로젝트 구성부터 일관적으로 유지하는 것이 좋다.
Ant는 비록 산업 표준 빌드 툴이지만, 프로젝트 구성에 대한 표준 규약은 제공하지 않는다. 때문에 담당자 취향만큼이나 다양한 구성이 존재하며, 그 구성을 정하고 관리하는데에만 상당한 고뇌와 노력이 소요된다. 그리고 재활용도 쉽지 않다. 바로 이 문제를 타파하고자 나온 오픈소스 프로젝트로 Maven이란 것이 존재한다. Maven 개발자들은 프로젝트의 구성에 관련된 모범 사례(best practice)들을 집대성하고자 하였다. 무분별한 컨피규레이션 허용보다는 잘 정의된 모범 사례를 따른는 것을 원칙으로 삼은 것이다(Convention over Configuration). 물론 그 결과가 이상적으로 완벽하진 않지만, 상당수의 프로젝트에 적용하는데 큰 무리가 없을 것이다.
어쨌든, 본 예제에서는 Ant를 사용하지만 Maven의 이상과 결과를 상당부분 따르고 참조할 것이다. 물론 Ant이기 때문에 언제든 어렵지 않게 수정 가능하다.
그래서 내가 구성한 기본 구성은 다음과 같다.
참조함 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와 완전히 독립적이어서 어떤 환경에서건 그대로 재활용할 수 있다.
스크립트의 속 내용은 조금 후에 살펴보기로 하고, 빌드 과정에서 생성되는 디렉터리 레이아웃에 대해서 먼저 살펴보자.
특별한 설명은 필요 없으리라 본다. 그렇다면 이제 Ant 빌드 스크립트의 내용과 빌드 단계에 대해 알아보기로 하자.
Ant 빌드 스크립트는 빌드 타깃(target)과 타깃간 종속성(선행 타깃 정의)과 타깃에서 실행해야할 실제 작업을 정의한다. 빌드 라이프사이클 역시 Maven의 그것을 기반으로 간소화한 후 약간 보강하였다. 다음은 build.xml에 정의된 타깃들을 라이프사이클에 따라 설명한 것이다.
몇 가지만 살펴보겠다.
먼저, code-analysis가 Maven에 없는 새로 추가된 단계이다. 이 단계에서는 FindBugs, CheckStyle 등의 정적 코드 분석 툴을 이용하여 제품 소스 코드의 잠재적 결함과 코딩 규약 부합 여부를 검사한다. code-analysis 단계 외에는, 실패 시 다음 단계를 계속 진행할 수 없다.
unit-test 단계에서는 수행시간이 짧은 단위 테스트들을 실행한다. 통합 테스트 케이스와 시간이 오래 걸리는 테스트 등은 뒷쪽의 integration-test 단계에서 수행시킨다.
마지막 deploy 단계에서는 완성된 바이너리를 개발 서버로, 최신 API 문서를 API 서버로 배포한다.
변경 가능한 사용자 속성으로는 다음과 같은 것들이 있다.
보는 바와 같이 소스 코드 디렉터리 구조, 산출물 파일 이름과 같은 정보는 따로 설정할 수 없도록 제안하고 있다. 이유는 초반에 언급한 Maven의 설계 원칙(Convention over Configuration)을 좀 더 강요하기 위함이다.
물론 build.xml의 내용을 보면 관련 정보를 속성으로 제공하여, 꼭 필요한 경우 쉽게 변경할 수 있다.
마지막으로 build-jazz.xml 파일을 살펴보자.
이 파일은 build.xml 을 확장하여 RTC/Jazz 빌드 서버에서 사용할 특화 타깃을 정의하고 있다. RTC/Jazz 빌드 기능에 특화된 만큼, 이 스크립트를 개발자 IDE에서 실행하려 하면 필요한 파일이 없다면서 에러를 발생시킬 것이다. 물론 몇 가지 설치/설정으로 가능케할 수 있지만, 별다른 이점은 없으니 Jazz 빌드 서버에 맡기기로 하자.
기본적으로는 다음의 네 가지 타깃이 제공된다.
특별히 위와 같은 네 단계만 정의한 이유는 잠시 후 Build Definitions 절에서 확인할 수 있다. 그 전에 정적 코드 분석(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 Definition)는 빌드에 필요한 각종 정보와 수행 조건 등을 담는다. 예를 들어, 빌드에 사용할 파일(build-jazz.xml)명, 타깃, 빌드 스케줄 등이 그것으로, 프로젝트 특성에 맞는 다양한 전략을 수립할 수 있다. 상세 내용은 본 글의 주제와 크게 관련 없으니 지나치도록 하겠다.
어쨌든 Jazz의 빌드 서버는 이 정의를 바탕으로 빌드 엔진에 빌드를 요청한다. 아래의 그림은 내가 구축하기 원하는 빌드 전략이다.
그리고 위의 전략을 구현하기 위해 다음과 같은 네 가지의 빌드 정의를 작성하였다.
Jazz 빌드 서버는 위의 네 가지 빌드 정의에 기반해, 자동으로 빌드/테스트/배포를 수행하며, 그 결과를 개발자에게 알려주게 된다.
이상으로 빌드 시스템의 거시적인 구성부터 빌드 단계 정의, 빌드 정의를 통한 지속적 빌드 전략 수립까지 구성해 보았다.
다소 이론적인 면에 집중하여 설명하였지만, 상세 내용으로 들어가면 내용이 너무 길고 장황해지니 양해 바란다.
(관련 Ant 빌드 스크립트는 약간 다듬어서 추후 업데이트하겠음)
오랫만에 글을 적는 계기는, 얼마전 팀에 배포된 100페이지짜리 자바 코딩 가이드라인 때문이다.
나는 이미 약 9년 전에 나만의 코딩 가이드라인 문서를 만들어 다수 프로젝트에 적용했었다. 당시엔 나름 자부심을 주는 산출물 중 하나였지만, 얼마 지나지 않아 이것은 구시대적 산물이 되었음을 깨닫게 되었다.
코딩 규약 자체는 분명 필요하다. 이것이 없는 조직은 아직 굉장히 미숙한 개발 문화를 갖고 있을 확률이 높다. 문제는 이를 정적인 문서(워드나 파워포인트 형태)로 작성/관리한다는데 있다. 문서 방식의 대표적인 한계는 이러하다.
과거 시절에는 저런 한계를 안고서라도 문서가 필요했지만, 더이상은 아니다. 개발 도구들이 이미 충분히, 아니 비교할 수 없을 만큼 성숙되어 있기 때문이다.
가장 대표적인 자바 IDE 중 하나인 Eclipse를 보자. Eclipse의 Preferences > Java > Code Style 메뉴를 보면 다음의 메뉴들을 볼 수 있다.
위의 기능들은 개발 중 언제나 간단한 메뉴 조작이나 단축키로 바로바로 적용할 수 있다. 즉, 새로 합류한 팀원이 아무리 대충 짜놓은 코드라도, 즉시 베테랑 선임 개발자가 짠 코드처럼 바꿀 수 있다는 것이다. (기본 로직이나 단어 선택 등은 논외)
C/C++ 언어의 유사 툴을 사용해본 사람이라면 시큰둥할 수도 있다. 하지만 직접 저 메뉴들을 찾아들어가 잠시만 살펴본다면 그 막강한 표현력에 혀를 내두르고, 실제 프로젝트에 적용해보면 그 정확성에 감탄을 금치 못할 것이다.
더욱이 편집한 설정을 import/export 할 수 있으니, 기본 설정이 맘에 들지 않는다면 수정하여 팀 전체가 쉽게 공유할 수 있다. 소스 컨트롤 툴에 저장/관리한다면 금상첨화일 것이다.
하지만 코딩 규약은 단순 문법만 다루는 것은 아니다. 잠재적 결함을 예방하기 위한 올바른 코딩 패턴과 개발자들아 자수 실수하는 잘못된 패턴에 대한 예방 차원의 항목도 다수 포함된다. 위의 설정만으론 분명 부족함이 있다. 이에 대한 해결책으로는 두 가지 툴을 추천한다.
FindBugs라는 이름에서부터 너무도 명백하게 자신의 용도를 광고중인 이 툴은, 자바 코드에서 문제의 소지가 있는 다양한 버그 패턴을 찾고 그 이유를 설명해준다. 자신이 짠 코드에서 직접 짚어준다는 점에서 초간단 예제 몇 개만 달랑 던져주는 문서와는 천지차이다.
IDE와 통합은 기본이고 무료다. 또한 이 툴이 헛짚은 경우는 아직까지 겪어보지 못했을 정도의 정확성을 뽑낸다. 물론 ‘우리의 사용 환경에서는 절대 이런 일이 발생할 수 없어’라며 무시할 수는 있지만, 사용 환경이 언제까지건 변함 없고, 그 코드가 다른 프로젝트에 가져다 쓰일 확률이 zero 라고 확신하지 않는다면, 툴이 제안하는 예방 조치를 따라두는 것이 나쁠 것 없다.
과거에는 PMD나 CheckStyle을 추천하며 CodePro Analytix는 소개 정도만 시켜주었는데, 이제는 상황이 바뀌었다. 구글이 이 툴을 사더니 무료로 뿌려버린 것이다. 더이상 상용 툴을 아쉬워하면 꿩 대신 닥으로 PMD나 CheckStyle을 사용할 필요가 없어졌다. 물론 이 둘을 무시하는 것은 아니지만, 개인적으로는 CodePro Analytix를 훨씬 높게 평가한다.
유사 코드 찾기와 종속성 분석 등 다른 기능도 많지만, 이번 주제와 밀접한 관련이 있는 기능은 바로 코드 검사 기능이다. CodePro Analytix는 Effective Java, Security, Internal API 등등 업계에서 많이 통용되고 있는 다수의 가이드라인에 맞는 수백가지의 검사 규칙을 제공한다. 각 규칙들은 세밀한 설정도 가능하고, 원하는 항목만 조합하여 팀만의 룰셋을 정의할 수도 있다. 이렇게 정한 규칙은 당연히 import/export 하여 공유할 수 있다.
Eclipse에 설치하려면 다음 주소를 참고하자.
http://code.google.com/intl/ko-KR/javadevtools/download-codepro.html
CodePro Analytix로 천하통일할 수 있을 줄 알았으나, 확인 결과 CodePro는 Ant 태스크나 Maven 플러그인을 제공하지 않아, 지속적 통합 시스템에 넣기에 적합하지 않다. 하여 PMD와 CheckStyle 중 하나를 여전히 추천하지 않을 수 없는 상황이다. 둘 중 하나를 고르자면, 나는 CheckStyle을 추천한다. 이유는 간단하다. PMD가 2009년 이후 업데이트가 이뤄지지 않고 있는데 반해, CheckStyle은 지속적으로 업데이트 중이기 때문이다.
툴의 기능은 CodePro Analytix와 유사하나 지속적 통합 시스템에 바로 적용할 수 있도록 Ant 태스크와 Maven 플로그인을 제공한다. 물론 Eclipse와 같은 IDE용 플러그인 품질도 뛰어나 개발자 편의성도 좋다.
지금까지 살펴본 바와 같이, 자바 코딩 규약에 대해서는 이미 훌륭한 툴들이 갖추어져 있다. 문서로 힘들게 정리하고 교육하는 것보다는 이들을 활용하는 것이 백배는 효율적이다. 그 이유는 이들 툴 모두는 다음과 같은 장점을 제공한다.
이 글을 읽는 사람이 자바 개발팀에 속해 있고 팀 내에 코딩 규약이 없거나 문서로만 관리되고 있다면, 지금이라도 늦지 않았으니 새로운 세상을 경험해보길 바란다.
회사 생활을 하면서 나는 참 많은 툴들을 팀에 전파하려 노력하였고 또 전파한 편이다. 테스트 자동화, 분산 컴파일, 테스트 커버리지 측정, 프로파일링, 정적 코드 분석, 컨티뉴어스 빌드, 애플리케이션 라이프 사이클 관리 등 그 분야도 소프트웨어 개발 전반에 걸쳐있다.
매번 새로운 툴을 도입하려 할 때마다 사람들의 반응은 제각각이다. 툴이 제공하는 기능 리스트(무엇을 할 수 있다)만 보는 사람, 자신에게 당장 필요한 핵심 기능 몇 가지에만 관심을 갖는 사람, 이전에 사용해본 유사한 툴과 똑같은 취급하는 사람 등 많은 부류가 있다. 하지만 아쉬운 점은 정작 그 툴의 진정한 가치에 관심을 보이는 사람은 찾기 힘들다는 점이었다.
좋은 툴들엔 그 툴이 현재의 모습을 갖추기까지 거친 수많은 시행 착오로부터 얻어진 노하우와 설계자의 철학이 담겨 있다. 고객들로부터 받은 엄청난 양의 피드백 역시 툴의 기능과 동작 방식에 지대한 영향을 미친다.
툴을 제대로 익힌다는 것은 이러한 경험과 노하우를 함께 습득한다는 의미를 갖는다.
툴 제작자들은 고객이 별다른 교육 없이도 최대한 쉽게 사용하게 만들기 위해 많은 노력을 기울이지만, 여기엔 분명한 한계가 있다. 아무것도 없는 야구공 하나도 잘 던지라면 제대로 쥐는법부터 시작해 많은 학습과 연습이 필요하다. 하물며 복잡한 소프트웨어 개발을 위해 수많은 사람들이 함께 사용해야할 툴이라면 오죽하랴.
툴을 제대로 활용할 줄 모르는 사람에게는 어떤 툴을 제공하건 생산성에 큰 변화가 없다. 이들은 대부분 기본적인 기능만 사용하게 되는데, 기본 기능만 놓고 본다면 이름 있는 유사 툴들 사이에 큰 차이를 찾아보긴 어렵기 때문이다. 병목 현상이 발생하던 부분에서 성능이 대폭 개선되는 경우(분산 컴파일, 저장소 프락시 등)나, 개발자가 할 일을 대신해주는 경우(자동 빌드, 정적 코드 분석)와 같이 한정된 상황에서만 그나마 효과를 얻게 된다.
여기까지는 양호한 편이다. 심한 경우 툴이 만들어진 의도와 다르게 활용되는 경우도 많다. 툴의 설계자는 일반적인 사람들의 잘못된 습관을 바로잡기 위해 기능과 인터페이스를 설계했는데, 바로 그 잘못된 습관대로 일을 진행하면서 오히려 툴이 잘 맞지 않는다고 불만을 토로하기도 한다. 방법을 바꾸면 더 큰 효과를 얻을 수 있음에도, 왜 툴이 내 마음과 맞지 않는지는 깊게 생각하지 않는다.
이전보다 훨씬 다양하고 강력한 기능을 갖춘 툴을 보여줘도, 기존에 사용해본 유사 툴의 틀에 갖혀 장점을 보지 못하는 경우도 많다. ‘이 툴은 이런 거야’라고 일찌감치 단정짓고 더 이상 파고들려 하지 않는다.
이러한 태도를 버리지 못한다면 새로운 툴 도입이란 똑같은 일을 하기 위한 방법을 하나 더 익히는 것 이상도 이하도 아니게 된다. 결국 아무리 좋은 툴이 새로 나오더라도 도입에 보수적이게 되는 원인 중 하나가 된다.
팀원 전체가 그렇지는 못하다면, 개인적으로라도 툴에 녹아있는 사상을 공부하고, 제대로된 활용법을 익히려 노력해보자.
과거의 유사 툴이나 시장의 경쟁 툴들과 어떻게 다른지, 왜 다른지 파헤쳐보라. 같은 일이라도 다양한 접근법이 존재함을 배우고, 각각의 장단점을 깨달아 내가 처한 상황에서 최선의 방법을 찾을 수 있는 눈을 갖게 될 것이다.
내가 생각한 것과 다르게 동작한다면 왜 그렇게 만들었졌지 알아보라. 내가 하던 방식에서 많은 문제점을 발견하고 더 나은 방식을 배우는 계기가 될 것이다.
설계자가 그 툴을 만든 목적과 배경은 무엇인지, 어디에 주안점을 두었는지 알아보라. 내가 속한 팀, 나의 환경이 그들이 해결하고자 하던 문제를 그대로 앉고 있는가? 그렇다면 툴 도입이 해당 문제에 대한 확실한 해결책이 되도록 노력해보자. 문제를 인식/공유하고 툴 도입의 목적을 명확히 하자. 그리고 툴을 제대로 활용하고 있는지, 문제는 잘 개선되고 있는지 정기적으로 평가해보자.
툴 제작자가 권장하는 활용 방법(Best Practice)은 절대 빼먹어서는 안된다. 가이드라인을 잘 숙지하고 최대한 맞춰보려 노력해보자. 충분히 익숙해진다면 내가 생각하는 방식이 곧 툴이 동작하는 방식이 된다. 머리 따로 몸 따로 움직이던 시절을 떠올리며 여유 가득한 미소를 짓게될 것이다.
이러한 과정을 거치면서 툴 도입 효과가 극대화됨은 물론, 자신의 역량도 함께 성장한다. 제대로 활용할 줄 아는 툴이 많은 것은 좋은 개발자가 갖춰야할 덕목 중 하나이기도 하다.
[u] Story 의 naming convention 을 Story 방식으로 변경함.
팀 내 Rational Team Concert 적용을 위한 가이드 제작 중 유용한 팁이 있어 공유한다.
RTC 에서 Scrum 템플릿을 사용할 경우, 플래닝에 사용되는 work item 타입은 기본적으로 (범위가 큰 것부터 차례로) Epic, Story, Task, 이렇게 세 가지이다. Scrum에 문외한인 사람들뿐 아니라, Scrum 에 나름 익숙한 사람들도 계획을 잡기에 익숙해지기까지는 제법 많은 난관에 부딪힌다. 이에 내 경험을 바탕으로 나름의 노하우를 정리해보았다. 이 방식을 잘 익히고 따른다면 계획을 잡는데 많은 도움이 되리라 확신한다.
덤으로..
추가로..
스크럼이나 유사 Agile 방식에 익숙하지 않다면 Story 의 naming 이 생소할 수 있다. 생각해보면 간단하다. ‘고객/사용자가 이 제품(Product)으로 무엇을 할 수 있다.’ 의 형태이다. Story 를 이렇게 작성할 때 얻게되는 대표적인 이점은 아래와 같다.
혹 스크럼 형태의 Story 네이밍에 익숙하지 않다면 아래와 같은 방식도 시도해볼 수 있다. 하지만 처음 러닝 커브는 작을 지라도, 경험상 정통 스토리 방식이 더욱 효과적이다.
새로 옮긴 팀에 Rational Team Concert [1] (이하 RTC) 를 적용하기 위해 노력 중이다. 지난 팀에서는 이러저런 이유들로 보수적인 성향이 너무 강해 중도 포기했었지만, 지금의 팀은 가능성이 높아 보인다. 특정 툴을 적용하다는 것이 중요한 것이 아니라 적절한 인프라를 구축하여 팀의 협업 능력을 극대화시킨다는데 목적이 있고, 현 시점에서 가장 훌륭한 툴이 Rational Team Concert 라 판단되어 진행중이다[2].
최근엔 지난 팀에서 RTC 를 전파할 때 한꺼번에 너무 많은 것을 이해시키려 한 경향이 컸었다는 생각이 든다. 따라올 수 있는 사람들은 따라왔지만, 제법 많은 사람들은 너무 많은 변화에 기겁을 하고 섵불리 도전하지 못했을 수도 있다. 여기에는 RTC 의 다양한 기능뿐 아니라 방법론과 사상도 포함된다. 예를 들어, 기본적인 개발 방법론에도 익숙치 않은 사람들에게 애자일이니 스크럼이니 하는 이야기까지 짧은 시간에 전파하려 한 것은 좋지 않은 시도였던듯 싶다.
그래서 이번엔 이런 이질적인 내용을 최소화하는 방법을 채택해보기로 하였다. 팀에서 업무를 진행하며 이루어지는 실제 활동들을 use case 로 잡아, RTC 를 사용했을 때의 모습을 긴 시간에 걸쳐 조금씩 보여주려 한다. 현재 잡아놓은 use case 들은 아래와 같다.
기본적인 활용에 익숙해지면 여러 동영상 자료들도 활용해 볼까 생각중이다.
나는 대기업에서도 상당히 큰 규모의 과제에 몸담고 있다. 연관된 내/외부 팀원만 하더라도 족히 5백은 넘을 듯 하고, 그 중 직간접적으로 내 영향력이 미치는 범위는 백여명 정도 될 듯 싶다. 이런 규모의 과제를 진행하다보니 프로젝트 투명성의 중요성이 더욱 크게 느껴진다.
여기서의 프로젝트 투명성이란 프로젝트 계획, 세부 태스크, 진척도, 히스토리, 위험 요소, 가용 자원 현황 등 프로젝트 진행과 관련된 중요 정보들에 관련자들이 실시간으로 얼마나 쉽고 정확하게 접근할 수 있는가를 말한다.
우리팀의 수직적 계층을 대략적으로 구분해보면 ‘개발자, 중간 관리자, 상위 관리자, 경영진’ 정도로 나뉘는 듯 하다. 수평적으로는 협력 팀과 경쟁 팀이 있고, 경쟁 팀들의 수직적 구조는 우리 팀과 대동소이하다. 이러한 거대 조직에서 프로젝트 투명성을 제대로 지원해주는 어떠한 인프라도 갖춰져 있지 않다면 어떤 현상이 벌어질까? 우리의 예를 일반화시켜 적어보겠다.
실시간 정보 공유가 어려우므로, 개발자는 중간 관리자에게 한 주 정도 간격으로 진행 상황을 보고한다. 하지만 이 때 기입되는 태스크들의 의미를 전체 프로젝트의 관점과 연관시켜주는 인프라가 없다. 무언가 많은 일들이 진행되고 있는 것은 같으나 그것의 의미는 잡아내기 쉽지 않다. 중요하지 않거나 계획에도 없던 일에 과도한 시간을 투자하거나, 반대로 아주 시급한 일과 직결된 이슈 사항이 주목 받지 못하고 묻혀버리는 일이 허다하다. 진도가 계획 대비 얼마나 충실히 나아가고 있는지, 그래서 예정된 마일스톤에 납기가 가능할 지와 같은 정작 중요한 정보는 거의 포함되지 못한다.
중간 관리자와 상위 관리자도 보통 주 단위의 미팅을 갖는다. 개발자들로부터 받은 보고를 정리해서 공유하고 전체 일정 대비 점검하거나 큰 이슈들에 대한 논의가 주로 이루어진다. 개발자의 보고 내용이 필터링 되는 것은 오히려 작은 문제이고.. 더 큰 우려 사항은 앞서 이야기한 ‘중요한 정보를 얼마나 잘 캐취해 냈는가’이다. 중간 관리자가 이 일을 제대로 처리하지 못한다면, 중요치 않은 일이 부각되고 그 후속 조치로써 더 중요한 일에 투입할 시간마져 갉아먹게 된다.
이 단계에서의 또 하나의 심각한 문제는, 가용 리소스와 각 태스크별 요구되는 리소스량에 대한 신뢰할 만한 데이터 없이 매니저들의 감과 욕심(혹은 바람)에 의존해 일이 계획된다는 점이다. 실무자가 보기엔 현재 할당된 일만으로도 일정 지연이 뻔한 상황에서도 새로운 태스크들이 추가된다. 요구 일정에 맞추려면 실무자는 결국 대충 진행할 수 밖에 없다. 그 때 그 때 지뢰를 하나씩 매설해놓고, 제품은 점차 건드리기조처 겁이 나는 지뢰밭이 되어 간다. 심지어 기존 기능을 변경할 시에도 감히 현 코드를 수정하지 못하고 편접적인 방법으로 살짝 덧씌운다.
상위 관리자는 협력 팀이나 경영진들과 미팅을 갖고, 그 주기나 형태는 어떤 주제로 누구와 맞나느냐에 따라 달라진다. 이전까지의 논의가 주로 기술과 일정에 대한 것이었다면, 이제부터는 기술은 쏙 빠지고 비즈니스 임팩트와 내/외부 경쟁에 대한 것들에 초점이 맞춰진다. 빠르게 변하는 시장 상황에 따라 과제 방향이 확 틀어질 수도 있고, 경쟁에서 너무 밀릴 것 같으면 생존 자체가 위협을 받는다. 이런 상황이 상급 관리자들을 방어적으로 만든다. 거짓말이 되지 않도록 신경쓰면서 문제를 최대한 숨기고, 작은 장점을 크게 부풀리고, 묘한 가정을 설정하거나 자신들에게 유리한 데이터를 추려 인용한다. 예를 들면, 여러가지 임시 방편과 제한된 시나리오로 간신히 데모 정도 돌리는 수준에서 마치 다 마무리 되어가는 듯 보고가 되고, 그 결과 추가적인 일거리가 생기고 과제 규모도 커져버리는 식이다. 추가된 업무에 허락된 리소스는 당연히 지금까지 잘 된(것처럼 보고된) 생산성에 맞춰져 있다. 일을 받는 입장에서 현실적인 리소스를 요구할 수 없는 것이, 앞으로는 자신의 팀원들의 생산성이 훨씬 떨어질 것이라는 납득하기 어려운 주장을 펴거나 현재의 상황을 인실직고해야하기 때문이다. 더욱이 현 문제에 대해 상급 관리자가 파악하고 있는 수준 역시 현실과는 꾀 거리가 있게 마련이다.
결과적으로 부정확한 데이터에 기반해 엄청난 예산을 낭비하고 기회를 놓치게 된다. 그리고 이런 체제에서는 개발자들의 실력도 늘지 않아 경쟁에서 점차 뒤쳐질 수 밖에 없다. 좋은 개발자들은 기회가 되면 조직에서 벗어나려 할 것이다. 그 외의 악순환 얘기까지는 굳이 꺼내지 않아도 될 것 같다.
투명한 프로젝트의 장점 중 가장 중요한 것은 다음 두 가지라고 생각된다.
첫 째, 여러 단계에 걸친 보고 과정에서 낭비되는 고급 인력의 시간을 실무적인 문제 해결로 돌릴 수 있다. 어떤 정보를 공개할 지, 어느 정도로 포장을 해야할 지, 유리한 데이터는 무엇이 있을 지, 경쟁자보다 우월해 보이려면 다소 무리해서라도 어떤 기능을 더 넣어야 할 지 등을 찾고 고심하는대는 생각보다 많은 시간과 노력이 필요하다. 한 구글 직원의 블로그에서는 자신들의 리더는 약 20% 의 리소스만을 관리에 쓰고 나머지는 같이 개발을 한다고 하였다. 반면 비효율적인 기업은 상위 20%의 인력은 관리만 하고 있는 것이 아닌가 싶을 정도이다. 고급 인력 한 사람의 적극적인 참여는 저급 인력 몇 명을 투입하는 것보다 훨씬 나은 효과를 낳는 경우가 많다. 이런 효과는 팀 규모가 커지고 과제가 장기화될 수록 더욱 뚜렷해진다. 과제가 진행되면서 노하우가 전파되고 개발인력들의 역량이 향상된다. 이 문제는 굉장히 심각한 것이.. 실무에서 몇 년을 일한 프로 개발자들 중 아직껏 대학생 수준의 코드를 작성하고 있는 경우가 너무 많이 목격되기 때문이다. 투명성 부여 하나만으로 해결될 일은 아니지만 문제를 부각시키는데 분명 큰 효과를 발휘한다.
둘 째, 조직이 스스로의 역량을 정확히 파악함으로써, 현실성 있는 비전과 전략을 수립하여 그에 집중할 수 있게 해준다. 어느 시점에 어떤 역량을 더 키워야 하는지도 판단할 수 있고, 이는 조직이 경쟁에서 살아남기 위해 꼭 필요한 정보 중 하나이다.
하지만 위와 같은 경직된 조직에서 과제에 투명성을 부여하기란 결코 쉽지 않다. 깨어 있는 사람에 의해 위에서부터 도입되는 시나리오가 가장 현실적이나, 정보가 차단된 문화에서 그럴 필요성을 느낄 수나 있는가가 첫 난관이다. 반대로 아래로부터의 개선은 변화를 시도하는 팀에게 상당한 모험이 될 것이다. 모든 정보를 투명하게 공개한 과제는 여러 겹 포장된 과제에 비해 생산성이 떨어지고 각종 문제들로 정신이 없는 것처럼 비춰지기 쉽다. 이런 현상의 진실을 경영진들에게 잘 납득시켜 결과가 나올 때까지 과제를 유지해 나가는 것이 가장 큰 난관이 될 것이다.
개발자들에게 오픈 마인드를 심어주는 것 역시 큰 장애가 될 수 있다. 자신들이 하는 일이 실시간으로 공개가 된다는 것은 자칫 일거수 일투족이 감시받는다는 오해를 불러 일으키기 쉽다. 실제 비공식적으로 도입해본 결과도 아랫사람들이 훨씬 적극적이며, 주로 위로부터의 말도 안되는 압박에 대한 방어효과 때문으로 보인다. 그리고 윗사람들이 하는 일도 다 같이 공개된다는 점을 잊지 말자.
마지막으로 그리고 절대 간과해서는 안되는 것이 있다. 정보 공개를 위해 귀찮은 추가 작업을 수행해야 한다면 업무 집중도가 떨어지고 정보 누락이 발생한다. 부정확한 정보를 얻기 위해 생상성을 떨어뜨리는 것은 바보짓이다. 따라서 충분한 논의와 교육으로 가능한 많은 이들과 공감대를 형성하고, 좋은 자동화 인프라를 갖춘 후에 시행에 옮겨야 한다. 의욕만 앞서 무리하게 추진하면 부정적 인식만 남겨 도입 시기를 더 늦춰버리는 역효과가 나기 쉽다. 지금까지 자칭 SE 라는 조직에서 수없이 반복해온 실수들이 아닌가!
하루라도 빨리 제대로된 개발을 해볼 수 있는 날이 오기를 바라며, 답답한 마음에 두서 없이 적어본 프로젝트 투명성에 대한 이야기를 마친다.
참고로, 인프라 관점에서는 본격적으로 제품이 나오기 시작한지는 아직 몇 년 되지 않아 제대로된 솔루션 중에는 선택의 폭이 넓지 않다. 현 시점에서는 IBM Rational 의 Jazz/RTC 와 MS 의 Visual Studio Team System 2010 정도가 눈에 들어온다. 통합 환경에 비해 사용법을 익히고 관리하는데 더욱 많은 노력이 드는 것은 어쩔 수 없지만, 별개의 여러 툴들을 조합해 사용할 수도 있다. 조직의 규모가 커질수록 투자할 만한 가치가 있을 것이다. 나라면 개발 인력 5명에 3개월 과제만 되어도 이런 류의 인프라를 도입할 것이다.
