프로젝트 수행 - 재사용 편

객체지향, CBD(Component Based Development) 등이 보급되면서 재사용에 대한 관심이 매우 높아졌지만 관심에 비해 재사용을 제대로 활용하는 프로젝트는 많지 않았다. 재사용 프로젝트는 비용이 적게 들어가는 것으로 알고 있지만, 재사용을 전제로 한 최초 소프트웨어를 만들 때는 비용과 노력이 더 많이 필요하다. 

재사용은 소스 코드만 재사용하는 것은 아니다. 문서나 프로세스도 재사용이 가능하고 법적인 문제로 재사용 범위가 제한되기도 한다. 재사용의 일반적인 인식은 장점은 공감하지만 많은 제약 조건으로 인해 적용이 어렵다고 알려져 있다. 이 글에서는 재사용이 다시 주목받는 이유에 대해 알아보고, 재사용이 성공할 수 있는 필수 요소가 무엇인지 알아본다. 마지막으로, 최근에 인식하지 못한채 사용되고 있는 재사용 형태를 간단히 정리해본다. 

재사용이 다시 주목받는 이유 

개발팀의 가장 큰 바램은 이전에 개발했던 것을 다음 프로젝트에서 재활용하는 것이다. 개발 시간과 비용도 낮아지지만 이미 검증이 되어 개발팀의 품질 부담을 줄이는 것이 가장 큰 이유이다. 재사용을 위해 객체(Object)와 컴포넌트(Component) 개념을 기반으로 한 OO(Object Oriented), CBD(Component Based Development) 방법론 등이 많이 활용되었고, 최근에는 아키텍처와 어플리케이션까지 재사용이 확대되는 추세다. 

재사용의 필요성 

일반적인 재사용의 정의는 소프트웨어 개발의 품질과 생산성을 높이기 위한 방법으로 기존에 개발한 소프트웨어의 경험과 지식을 새로운 소프트웨어 개발이나 유지보수에 재 적용하는 것이다. 재사용이 올바르게 적용되었다면 완성된 소프트웨어를 효율적으로 분석하는 재공학(Reengineering), 역공학(Reverse Engineering), 소프트웨어를 잘 폐기하기 위한 파괴공학(Destruction Engineering) 등으로 확대될 수 있다. 재사용은 규모에 따라 분류될 수 있다(표 1 참조). 

<표 1> 재사용 규모에 따른 분류 

<표 1>을 살펴보면, 함수와 객체를 재사용하기 위해서는 경우에 따라 코딩을 다시 하거나 컴파일(Compile)이나 링크(Link) 작업을 다시 해야 하지만, 컴포넌트나 어플리케이션은 별다른 작업 없이 재사용이 가능한 경우가 많다. 재사용은 컴포넌트나 어플리케이션 단위로 만들어야 추가 공수가 필요 없지만 재사용을 위한 컴포넌트나 어플리케이션을 설계하기가 매우 어려워 시간이나 비용이 한정적인 프로젝트에서는 논의조차 어려운 경우가 일반적이다. 

재사용을 망설였던 원인 

재사용의 장점은 매우 높지만, 최근까지도 재사용은 잘 되지 않고 있다. 처음부터 재사용을 위한 개발을 해야 하기 때문에 추가적인 비용과 시간이 많이 들고 재사용 전문가가 반드시 개발에 참여해야 하기 때문이다. 재사용 소프트웨어를 만들어도 유지 보수하는데 어려움이 매우 크고, 들어간 노력 대비 재사용되는 횟수가 적은 것도 재사용을 망설이는 요인 중 하나다. 그 중에서 가장 큰 요인은 다른 사람이 개발한 것을 믿지 못하는 개발 문화이다. 

NIH 증후군 (Not invented here syndrome)은 말 그대로 '여기서 개발한 것이 아니다.'(Not invented here)라는 의미로, 제3자가 개발한 기술이나 연구 성과는 인정하지 않는 배타적 조직 문화 또는 그러한 태도를 말한다. 따라서 주어진 문제에 대한 해법을 자신 또는 조직 내부의 역량만을 고집하여 해결하려는 배타적인 현상이 나타난다. NIH 증후군은 타인이나 다른 조직에서 나온 기술이나 아이디어는 무시하거나 수용하지 않으려 한다는 점에서 소통과 협업을 어렵게 만드는 장애 요인으로 작용한다. (자료: 위키피디아)

재사용이 어렵고 적용된 사례도 많지 않지만, 반드시 필요하다는 인식은 줄어들지 않고 있다. 재사용이 널리 확산되지 못했던 이유도 재사용 자체의 문제보다는 적용의 한계가 있었기 때문이다. 적용이 어렵지만 재사용이 다시 주목 받는 이유는, 완성만 된다면 소프트웨어의 생산성 향상, 기간과 비용 단축에 높은 효과가 있고 개발팀도 체계적인 재사용 자산관리를 할 수 있다는 장점 때문이다. 

지금부터 재사용의 장점을 살리기 위해 필요한 것이 무엇인지 알아보도록 한다. 

더 보기 >>>

Continuous Integration (지속적인 통합)

소프트웨어 공학에서 ‘지속적인 통합(continuous integration, CI)’이라 함은, 지속적으로 퀄리티 컨트롤을 적용하는 프로세스를 실행하는 것이다. 최근에는 SW가 복잡해지고 고품질의 SW가 요구되는 반면, 개발팀 입장에서는 짧은 개발 기간과 지리적으로 멀리 떨어져 있는 등 여러 가지 도전 과제에 직면해 있다. 이러한 환경에서 주목받고있는 ‘지속적인 통합’은 초기에 작은 단위로 그리고 자주 통합해, 통합 시 발생하는 여러가지 문제점을 조기에 발견하고, 피드백사이클을 짧게 하여 SW개발의 품질과 생산성을 향상시키는 것이다. 

다시 말해,모든 개발을 완료한 뒤에 품질관리를 적용하는 고전적인 방법을 대체하는 방법으로서, 소프트웨어의 질적 향상과 소프트웨어를 배포하는데 걸리는 시간을 줄이는 것을 그 목적으로 한다. 락플레이스의 윤종민 수석을 통해 더 자세한 설명과 적용 방법에 대해 알아보았다. 

<락플레이스 윤종민 수석연구원>

● 지속적 통합이란 무엇인가?  ● 지속적 통합을 위한 솔루션 및 도구 소개  ● 지속적 통합 도입 사례 소개

Q: ‘지속적 통합’이란 구체적으로 무엇을 뜻하나요? 

소프트웨어 개발자에게 개발 방법론이란, 일종의 ‘네비게이션’과 같습니다. 원하는 결과를 얻기 위해 ‘어떤 경로를 택할 것인가’에 대한 선택이기 때문이죠. 요즘의 개발자들이 많은 관심을 가지고 있는 방법론은 XP. 즉 Extreme Programming일 것입니다. XP가 주장하는 것 중에는 정말 extreme한 내용도 있기 때문에, 이 방법론의 유효성을 두고 십 수년간 논쟁이 끊이지 않고 있는데요. 논란이 확산됨에 따라 XP의 Best Practices 중 일부는 다른 진영에서도 인정을 받게 되었습니다. 그 중, 지속적인 통합(CI)은 한 두 문장으로 설명하기에는 쉽지 않지만, 다음과 같이 정의할 수 있습니다. 

● 소프트웨어 빌드를 만들어내는 절차를 쉽게 하고 안정화 하기 위한 실천방법의 집합체  

● 팀의 구성원들이 자신들의 작업한 내용을 자주 통합하는 개발 지침  

즉, 각각의 개발자가 자신이 수정한 소스 코드를 되도록 자주, 소스 코드 저장소에 커밋하고, 다른 사람이 수정한 소스 코드는 없는지 수시로 확인하는 일련의 행동을 의미합니다. 

『소프트웨어 공학의 사실과 오해』(로버트 L 글래스) 에서 보면, “소프트웨어 개발 중 발생하는 오류의 절반이 모듈의 15%에서 발견된다”라고 나와있는데요. 이는 공동으로 소프트웨어를 개발 할 때, 모듈 전체에 개발자가 골고루 분배되지 않고, 특정 부분에 몰리게 된다는 것입니다. 하지만, 커밋할때 마다 모든 팀원에게 공지를 할 수는 없기 때문에 수시로 변경 사항을 확인하는 것이 가장 좋은 방법입니다. 그러기 위해서 이러한 과정을 도와주는 소프트웨어를 사용하게 되는데요, ‘Jenkins’가 대표적으로 활용되는 소프트웨어라고 할 수 있습니다.

이러한 젠킨스(Jenkins)를 소개하기에 앞서, 지속적인 통합을 도와 주는 소프트웨어는 어떤 기능을 가지고 있어야 하는지 먼저 말씀드리겠습니다. 

● CI 서버: 빌드 프로세스를 관리하는 서버 

→ Jenkins, Hudson, CruiseControl.NET, TeamCity 

● SCM(Source Code Management): 소스코드 형상 관리 시스템으로 소스코드의 개정과 백업 절차를 자동화 하여 수정 과정을 도와 줄 수 있으며, 여러 사람이 같은 프로젝트에서 공동 개발을 진행할 때, 각자가 수정한 부분을 팀원 전체와 동기화 할 수 있도록 도와 주는 도구

→ Git, Subversion, Mercurial 등 

● Build Tool: 컴파일, 테스트, 정적 분석 등을 실시해 동작 가능한 소프트웨어를 생성하는 도구로 개발하는 언어에 맞는 빌드 툴

→ Ant, Maven, MSBuild, Make, Gradle 등 

● Test Tool: 작성된 테스트 코드에 따라 자동으로 테스트를 수행해주는 도구로 빌드 툴의 스크립트에서 실행한다. 일반적으로 테스트란 단위 테스트를 이야기하며, 단위 테스트는 테스트 대상이 되는 코드 기능의 아주 작은 특정 영역을 실행해 보는 것으로, 개발자가 작성한 코드로 특정 기능을 테스트 해 보는 것이 일반적이다. 

→ Junit, CppUnit, CppTest, MSTest, Selenuim 등 

● Test Coverage Tool: 테스트 코드가 대상 소스에 대해 어느 정로를 커버하는지 분석하는 도구로, 코드 라인과 백운율을 통해 리포팅한다. 단위 테스트를 수행할 때, 테스트 커버리지를 분석하기 위해 부가적으로 사용하는 툴이다. 

→ Emma, Coberura, TestCocoon 등 

● Inspection Tool: 프로그램을 실행하지 않고, 소스코드 자체로 품질을 판단할 수 있는 정적 분석 도구로, 코딩 표준 준수, 코드 메트릭, 중복 코드, 코드 인스펙션등을 확인한다. 

→ CheckStyle, FindBugs, Cppcheck, Valgrind 

<그림 1> 지속적인 통합 절차

 

자료: http://www.nextree.co.kr/p3452

더 보기 >>>

프로젝트 협업 소프트웨어 사용 현황

PM Software는 팀원 간의 노력을 조직화 시키고 해결할 과제를 지시할 수 있도록 고안되었다. 가장 핵심적인 특징이라 할 수 있는 것은, 프로젝트 스케쥴과 진행상황을 시각화(Visualizaiton) 시켜 보여준다는 것과 함께 수행할 과제를 구성하고 배정하는 것을 수월하게 한다는 점이다.

협업을 위한 프로젝트 관리 소프트웨어를 사용할 때의 장점 ● 팀원을 체계적으로 구성할 수 있고, 복잡한 일정관리를 세밀하게 진행할 수 있다  ● 프로젝트 계획수립과 실행에서 팀웍과 협업을 향상 시킨다  ● 진척도를 모니터링하고 현실적이고 정확한 기준들을 세팅함으로써 팀원들의 역할과 책임을 유지할 수 있다  ● 팀 커뮤니케이션, 팀 의식, 팀 효율성을 향상 시킨다

Wrike에서 조사한 바에 따르면, 설문 참여 기업의 77%가 PM Software를 사용하고 있으며 특히, 고성과 기업의 경우에는 87%가 PM Software를 사용하고 있다. 그리고, 76%는 사용 중인 PM Software에 대해 매우 만족 혹은 만족하고 있다. 

 

협업을 지원하는 PM Software는 종류가 매우 다양하기 때문에 비즈니스와 프로젝트의 특성을 고려하여 선택해야 한다. 모든 팀원이 프로젝트 관리 소프트웨어(시스템)을 효과적으로 활용하고 성과에 기여할 수 있도록 도와주는 10가지 팁을 제시한다.

1. 조직 특성과 규모, 그리고 예산에 적합한 프로젝트 관리 시스템을 찾는다  2. 팀원이 장소에 상관없이 접근할 수 있도록 모바일에 최적화될 플랫폼을 생각한다  3. 사용하는 중요한 다른 애플리케이션과 통합할 수 있는지도 알아본다  4. 프로젝트 관리 프로세스 전체를 대체해주는 것은 아니므로 PM Software 도입시에는 데이타 획득과 관리, 의사결정 지원, 보고와 그래픽 지원 이라는 현실적인 효과를 생각한다  5. 소프트웨어 도입, 팀원 대상 교육, 구매 결정할 의사결정권자 설득 등을 지원해 줄 후원자를 찾는다  6. 점진적으로 도입하고 사용 대상자 모두에게는 적절한 교육을 한다  7. 프로젝트 관리 프로세스를 사전에 규정한다  8. 일단 도입을 결정하면 모두가 해당 PM Software만을 사용하도록 강하게 관리한다  9. PM Software를 이용해서 비용과 생산성을 추적한다  10. 벤더와 자주 연락하고 성공사례 조사 등을 하면서 관계자들의 도움을 적극적으로 이끌어낸다.

더 보기 >>>