Forever Developer

몇가지 개발환경 자동화에 대한 테스트 조합을 해본결과에 대해서 추천을 드리겠습니다.

1. 이슈 관리 시스템
Mantis,Trac,Bugzilla,JIRA를 운용해봤습니다
결과는 JIRA가 가장 좋다는 것이 결론이고 구입 비용은 대충 120만원이면 일반 기업에서 무리 없이 사용이 가능합니다.
나머지는 오픈 소스 인데, Trac의 경우 기능은 막강하지만 인스톨과 운용이 어렵기 때문에 작은 단위나 기술력이 부족한경우에는 그다지 추천하고 싶지 않습니다.
Bugzilla의 경우 제 경우 매우 편리하게 사용을 했습니다만, 인스톨이 제법 까다롭습니다.
Matins의 경우 Instant Mantis라는 것으로 매우 쉽게 설치 및 운용이 가능합니다. 한글 지원도 잘되구요. 그러나.. 프로세스에 대한 흐름이나 UI가 좀 딸리는 느낌이 듭니다.

2. 소스 관리 도구
SVN이 널리 사용되기 때문에 다른 언급은 하지 않겠습니다.
단 SVN의 내용을 (소스나 변화 내용, 브렌치 추적) 웹에서 보여주는 도구로는 Fisheye가 제일 좋더군요. (유료입니다.) JIRA하고 연동도 쉽구요.
 무료로는 sventon이 비교적 사용도 쉽고 연동도 쉽습니다. 둘중 하나를 사용해보시는것이 좋겠습니다.

3. 빌드 스크립트
대표적으로 ANT와 MAVEN이 있습니다만, MAVEN의 경우 의존성 관리등이나 여러 기능적인 장점은 가지고 있습니다.
그러나.. 저의 경우 대부분의 작업이 엔터프라이즈 솔루션을 기반으로 하고 있는데, 이런 엔터프라이즈 개발 도구들은 MAVEN을 아직까지 지원하지 않는 경우가 많기 때문에 ANT를 사용합니다.

4. CI도구
Cruise Control, Team City, Anthill Pro, Hudson등이 있습니다.
Cruise Control은 오래된 솔루션 같구요.. 자바진영에서는 이미 좋은 솔루션들이 많아서 다른 솔루션을 사용하시는것이 좋겠습니다. Anthill pro가 많이 언급되는데 유료이고 아직 사용해본 경험은 없습니다만 널리 사용되는 만큼 추천할만 합니다.

무료로 사용될 수 있는 솔루션이 Team City Pro, Hudson이 있는데,
Hudson이 직관적이고 사용법도 매우매우 쉽습니다.
그러나 아직 개발 중인 관계로 버그가 종종 있고 자료가 적어서 다소 삽질이 많이 필요합니다. Team City는 완성도가 높지만 직관도는 Hudson에 비해서 떨어지는 것 같습니다.

5. 테스팅 도구
단위 테스트는 말할것 없이 JUnit이 추천할만합니다.
단!! JUnit은 3.X와 4.X가 코딩 스타일이 다르고 (물론 기능은 4.X가 더 좋습니다.) 특히 JUnit과 조합되는 프레임웍에서 4.X를 지원하지 않는 경우가 많기 때문에 3.X를 추천합니다.

In Container Test로는 JUnitEE와 Cactus가 있는데, 개인적으로는 Cactus를 추천합니다.
Cactus의 경우 Test Wrapper를 JUnit을 상속 받아 만들 수 있기 때문에, JUnit을 지원하는 모든 도구들과 잘 어울립니다. 특히 단위 부하 테스트를 해야하는 경우 Japex와 잘 조합이 되기 때문에 JUnitEE보다 약간 불편하긴 하지만 Cactus를 사용하는 것이 좋겠습니다.

다음으로 엔터프라이즈 시스템의 경우 DB에 대한 테스트 전후에 데이타 초기화와 개발자간의 테스트 데이타 동기, 그리고 테스트 결과 비교에 매우 유용합니다.

다음은 단위 성능 테스트인데,
JPerfUnit은 성능지표를 측정만 하는 것이기 (테스트가 어느 성능에 도달했는지 못햇는지) 때문에 단독으로는 큰효과를 얻을지는 미지수 입니다.
Japex의 경우 Junit과 조합되어 기존 JUnit에 대한 부하 테스트가 가능하고 Hudson과 통합이 매우 잘됩니다. (사용법도 간단하구요..) 이건 꼭 추천합니다. 그래프 기능도 좋구요..

6. 테스트 커버러지
다음으로는 테스트 결과에 대한 분석을 위한 커버러지 도구인데, 크게 Cobertura와 EMMA가 있습니다. EMMA는 이클립스 연동은 잘되지만 EAR이나 WAR에 대한 Instrument를 지원하지 않기 때문에, EJB등의 패키징이 많은 (JAR,WAR,EAR) JEE 시스템에는 그리 적절하지 않습니다. Cobertura의 경우 기존 패키징된 아카이브에 instrument를 할 수 있기 때문에 편리하게 사용할 수 있습니다. EMMA의 경우 runtime instrumentation을 지원하기 때문에 대안은 될 수 있겠지요. 이건 사용자의 몫에 맏깁니다.

7. Code Inspection
코딩에서 에러 발생 가능성이 있는 부분이나 코딩 스타일의 문제를 지적하는 것인데, FindBug나 PMD같은 도구들이 있고 상용으로는 Klockworks등이 있습니다만 이건 팀의 기술과 프로세스 운용 수준이 높지 않은 이상 도입에 무리가 있다고 봅니다.

그래서 제가 추천하는 조합은

SVN+JIRA+FISHEYE+HUDSON+JUnit 3.8x+DBUnit+Cactus+Cobertura+Japex

입니다. 여기에 확장으로 Confluence Wiki를 통한 팀내의 지식 공유 기반을 마련하는 것이 좋을것으로 생각됩니다.

요즘 Goverance 이야기 많이 하는데.. 뜬 구름 잡는 Governance보다는 이런 환경들이 진정한 Goverance로 가는 지름길이 아닌가 싶네요.

출처 http://bcho.tistory.com 조대협의 블로그

[박서기 칼럼] `니콜라스 카` 논쟁과 BPMㆍSOA
박서기 논설위원

2003년 5월 하버드비즈니스리뷰에 실린 한 편의 논문이 전 세계 IT업계와 경영학계를 발칵 뒤집어 놓은 적이 있었다. 니콜라스 카(Nicolas Carr)라는 경영 컨설턴트가 쓴 `IT Doesn't Matter'(IT는 중요하지 않다)라는 제하의 논문에 대해 빌 게이츠, 마이클 델 등 IT업계 유명 인사를 비롯해 전 세계 각 분야의 전문가들이 대대적인 논쟁을 벌였다. 아마 이 사건은 경영학계와 IT업계에서 동시에 벌어졌던, 가장 획기적인 논쟁이 아니었나 싶다. 그것도 단 한 편의 논문을 두고 말이다.

니콜라스 카의 주장을 요약하면 이렇다. "IT는 점차 철도나 전기 같은 일용품으로 바뀌고 있다. IT가 보편화되고 저렴한 비용으로 IT인프라를 구축할 수 있는 만큼, 더 이상 IT는 매력적이지 않다. 이제 IT는 어떠한 경쟁우위도 제공하지 않는다."

몇 주간의 논쟁을 거치면서 외형적으로는 반박 진영의 캐치프레이즈였던 `IT Does Matter'(IT는 중요하다)가 승리했다. 하지만 니콜라스 카의 주장은 최고정보책임자(CIO)들에게 큰 충격과 함께 반성의 계기를 제공했다. `우리 회사의 IT는 경쟁우위와 차별화에 얼마나 기여하고 있는가'라는 물음에, 과연 얼마나 많은 CIO가 `예'라고 답할 수 있겠는가.

아쉬운 점은, 당시 국내에서는 전문가 논쟁은커녕 해외에서 벌어진 논란조차 제대로 소개되지 않았다. 일부 기사나 기고문에서 니콜라스 카의 이름과 논문 제목이 언급된 정도였다.

이후 몇 년간 이 논쟁을 잊고 있었는데, 최근 IT업계의 핫이슈로 부상한 업무프로세스관리(BPM)와 서비스지향아키텍처(SOA)가 니콜라스 카를 다시 떠올리게 하고 있다. 두 개념은 사뭇 다른 내용이지만, `IT가 비즈니스의 요구를 신속하게 반영할 수 있어야 한다'는 지향점과, 이를 위해 `업무 프로세스'를 고민의 중심에 두고 있다는 점에서 공통점이 있다. 니콜라스 카의 주장을 선의로만 본다면, 그가 하고 싶었던 얘기는 바로 `IT는 경쟁우위에 기여해야 한다'는 것이다. 마이클 해머의 `리엔지니어링'을 송두리째 뒤집어 버렸다는 BPM 개념과, 엔터프라이즈 IT 역사상 가장 획기적인 사상이라는 SOA 개념이 아이러니하게도 니콜라스 카의 고민과 일맥상통하는 것이다.

올 들어 국내에서도 BPM이 전 산업 분야로 본격적으로 확대되고 있다. 특히 일부 선진적인 기업은 단순한 자동화 수준이 아니라 `프로세스=자산'이라는 관점에서 프로젝트를 추진하고 있다. SOA도 더디기는 하지만 올해, 내년을 거치면서 작은 규모나마 시장을 형성할 것으로 보인다.

그런데 이상한 점이 있다. 이미 전 세계적으로 BPM과 SOA는 뗄 레야 뗄 수 없는 개념으로 받아들여지고 있으며, 특히 SOA에 BPM을 어떻게 접목할 것인가 하는 점에서 논의가 활발하다. 하지만 국내 논의 수준이나 프로젝트 현장의 분위기는 다르다. BPM은 좋은데, SOA는 아직 더 두고 보자는 게 대세다. 사실 SOA관련 논의 자체가 아직 초보적인 단계다.

이런 불균형을 보면서 니콜라스 카 논쟁조차 소화하지 못한 우리 현실이 오버랩되는 이유는 무엇일까. 부정하고 싶지만 이것이 바로 IT 강국, 한국의 슬픈 자화상이다. 심하게 표현하면 냄비근성 같은 것 말이다. BPM과 SOA는 IT와 비즈니스의 관계 측면에서 기존의 질서와 관행을 근본적으로 부정한다. 단순히 툴 도입으로 해결될 일이 아니라는 뜻이다. 과연 근본에 천착하고 있는지, 아니면 유행을 좇고 있는 것인지 근본적인 고민이 필요한 때다.
<박서기기자 skpark@>