핵심 키워드로 보는 성공적인 소프트웨어 개발[펌]

[플밍지기]

핵심 키워드로 보는

성공적인 소프트웨어 개발

시스템의 대규모화에 따라 소프트웨어의 신뢰성 저하, 개발비의 증대, 프로젝트 지연 등의 현상이 현저해 개발 계획의 수행을 매우 어렵게 만드는 상황을 이른다는 ‘소프트웨어 위기’라는 말이 나온 지 수십 년이 지났지만 아직도 소프트웨어 개발을 성공하기란 어렵고 힘들다. 이를 해결하기 위해 많은 방법론과 툴이 출현했고, 그 결과로 많은 발전을 가져왔다. 그럼에도 불구하고 왜 소프트웨어 개발에 성공하기란 어려운 것일까?

소프트웨어 개발 결과를 평가하기란 쉽지 않아 프로젝트의 거의 대부분이 성공했다고 한다. 우리는 성공보다는 실패에서 더 많은 것을 배울 수 있지만 거의 다 성공했다고 말하니 예전 소프트웨어 개발을 통한 경험을 배우지 못하고 있어 계속적인 실수를 반복해 ‘실패인 성공’을 계속하고 있는지도 모른다. 지금부터 소프트웨어 개발을 하면서 어렵고 중요하게 생각되었던 키워드에 대해 이야기해 보고자 한다.

개발방법론은 번거로운 일?

개발자는 개발방법론에서 규정하는 방법론을 우선 귀찮고 번거로운 것이라고 생각한다. 이는 방법론이 현재 개발자 업무에 많은 도움을 주지 못하기 때문이다. 품질과 생산성을 향상시키고 납기를 맞추기 위해 체계적인 관리를 하고자 방법론을 도입하지만 정작 개발자는 번거로운 일로 여기는 경향이 있다. 그렇다면 무엇이 번거롭다고 생각하게 하는지 따져보자.

첫째, 방법론을 유연성이 없이 적용한다. 방법론에서 제시하는 방향대로 무조건 따라야 하고 예외적인 상황이 닥칠 때는 혼란을 가중하게 된다. 예외적인 상황이 닥칠 때 어떻게 해야 할지 방법을 알 수 없어 옳지 않은 방향으로 개발이 진행되고 이로 인해 많은 시간을 소비하는 경향이 있다.

둘째, 방법론에 대한 팀원의 내재화가 부족하다. 방법론에 따라 프로젝트를 진행해야 하는데 방법론에 대한 정확한 이해가 없다 보니 방법론대로 프로젝트를 진행하지 못하고 어렵게만 느껴진다. 방법론의 적용 과정에서는 개발 참여자 모두가 방법론을 이해할 필요가 있으며 이를 활용할 수 있는 정도의 학습이 되어 있어야 한다. 팀원의 내재화는 단기간에 이루어지는 것이 아니므로 지속적인 교육과 선임자의 멘토 역할이 무엇보다도 중요하다.

셋째, 너무 복잡하다. 방법론을 만드는 사람은 여러 가지를 생각해서 복잡하게 만들지만 복잡하면 쓰기 힘들어서 사용하지 않고 자기 마음대로 해석하고 행동하게 마련이다. 방법론이 간단해야 하며 너무 복잡하다고 생각되면 방법론의 단위를 다시 나누고 단위별로 간단하게 정의해 이해하기 쉽고 적용하기 쉽게 해야 한다.

필자는 개발하거나 시스템을 관리하는 작업에서 자꾸 실수가 발생하고 다른 팀간의 명확한 업무 정의와 협의가 필요하다고 판단해 그것을 방법론화하고 합의를 받은 후 방법론을 적용해 본 경험이 있다. 그 결과, 업무가 명확해지고 체계 있게 수행됨을 확인했다.

예로 개발 시 공용으로 사용하는 데이터를 서로 바꾸어 문제가 반복된다면 서로 합의나 공유가 되지 않는 문제점을 해결하기 위한 방법론을 만들어 사용하는 작은 것부터 해보자. 방법론이 어렵고 복잡한 것이 아니라 우리가 하는 업무를 체계화해 협업과 개인의 업무 진행 방향을 제시하는 역할을 한다고 생각한다. 여러 방법론에 따라 개발하면서 느낀 점은 정답은 없다라는 사실이다. 얼마나 잘 이해하고 잘 적용하고 활용하느냐에 따라 결과에 많은 차이가 있다. 그러므로 좋은 결과를 만들어 내기 위해 많은 경험과 학습이 바탕이 되어야 한다.

다양한 방법론의 출현 및 목적

우리가 많이 듣는 방법론은 왜 이렇게 많이 출현하는 것일까? 방법론은 프로젝트를 하는 데 있어서 길잡이 역할을 해 진행 방향을 설정하고 방법론에서 정의한 방법대로 프로젝트를 진행하도록 한다. 그렇다면 왜 그렇게 다양한 방법론이 제안되는 것일까? 그것은 소프트웨어 기술의 변화와 방법론마다의 장단점이 존재하기 때문이다. RUP, CBD, TDD, PL(Product Lines) 이외에 많은 방법론이 존재하고 회사 내부에서도 자체적으로 많은 방법론을 정립해 사용하는 곳도 있다.

RUP하면 떠오르는 단어는 SoC(Separation of Concerns), Auto and Daliy Build, Unit Test, Iteration이다. 요구분석 단계에서 기능 단위를 어떻게 나눌 것인지를 고민하고, 이렇게 나누어진 단위는 구현해야 할 유스 케이스가 된다. 그리고 이 유스 케이스에 대한 중요도를 결정한다. 그렇다면 중요도가 높은 케이스를 첫 번째 Iteration 항목으로 선정한 후 개발하게 된다. 개발하면서 테스팅도 이뤄진다. 첫 번째 Iteration이 끝나면 다음 Iteration을 위한 선정과 개발, 테스트가 이뤄진다. 이렇게 반복적으로 개발하고 피드백(Feedback)을 받아 다시 설계에 반영해 나가는 방법으로 진행하게 된다. 이것은 우리가 흔히 알고 있는 폭포수 모형을 짧은 주기로 돌리는 것과 유사하다. 그러나 RUP에서는 중요한 포인트가 있다.

 이렇게 Iteration 지향으로 개발함으로써 잠재 리스크를 조기에 발견해서 해결하는 게 핵심이다. 프로젝트 진행 전반부에 리스크가 발견되면 될수록 개발 비용은 줄어들고 개발기간 또한 단축시킬 수 있기 때문이다. 개발이 완료되고 발견된 리스크는 많은 비용이 따르고 프로젝트의 성패에 영향을 줄 수 있다.

TDD(Test Driven Development) 방법론에는 아주 중요한 포인트가 숨어있다. Test Code를 작성하고 구현 Code를 테스트함으로써 테스트를 통해 리스크나 잠재 문제를 빨리 찾아낼 수 있다. 개발자가 만든 코드를 테스트하고자 할 때 자신의 코드가 작동할 수 있도록 테스트 케이스(Test Case)를 입력하게 되어 오류를 발견하지 못하게 되는 경우가 있는데 TDD에서는 먼저 테스트 케이스를 정의하고 구현하므로 구현을 고려한 테스트 케이스를 입력하지 않아 더욱 정확한 검증을 가능하게 한다.

CBD 방법론은 소프트웨어를 느슨한 결합도를 갖는 조립 가능한 컴포넌트 단위로 만들어 재사용성을 높이는 목적을 갖고 있다. 그러나 컴포넌트의 단위를 정의하는 데 있어서 비즈니스에 따라 적정한 크기로 정의하는 부분이 어려운 일이다. 너무 작게 컴포넌트를 나누면 효율성이 떨어지고 너무 크게 컴포넌트를 나누면 유연성과 변경 용이성이 떨어진다. 컴포넌트가 너무 작은 경우 한 가지 기능을 수정하려면 여러 개의 컴포넌트를 수정해야 하며 그 수정으로 인해 다른 컴포넌트가 영향을 받으면 업무에 복잡성을 가중시켜 효율성이 떨어지게 된다. 또한 컴포넌트가 너무 큰 경우는 작은 부분을 수정해야 하지만 전체를 다 릴리즈 해야 하는 경우가 발생하게 되어 유연성과 변경 용이성이 떨어진다. Layered Architecture 관점에서 볼 때 공통적인 부분이 될 수 있는 Infrastructure Layer는 요구사항의 추가나 변경에 큰 영향이 없는 경우가 많다. 그러나 Application Layer는 요구사항의 추가나 변경에 많은 영향을 받게 된다. 그렇다면 Infrastructure Layer는 유연성 및 변경 용이성보다는 효율성이 중요하고 Application Layer는 효율성보다는 유연성 및 변경 용이성이 중요하게 된다. Infrastructure는 단위를 크게 잡아 프레임워크(Framework) 단위의 재사용으로 효율성을 높이고 애플리케이션은 단위를 작게 잡아 유연성과 변경 용이성을 높이는 것이 좋다.

<그림 1> 컴포넌트 크기와 소프트웨어 특성간의 관계

최근 많이 이야기되고 있는 방법론으로는 PL(product Lines) 방법론이 있다. 이 방법론의 핵심은 재사용에 있다. 여러 모델의 소프트웨어를 하나의 소프트웨어 개발군으로 정의하고 공통적으로 사용하는 부분을 Product Line Requirements로 애플리케이션마다 다른 요구사항을 Application Requirements로 정의한다. 

<그림 2> Product Lines 프로세스 모델

그리고 Product Line Reuse Library를 만들어 공통적으로 사용하는 컴포넌트를 구현하고 저장하게 된다. 이를 기반으로 애플리케이션을 만들 때 Reuse Library와 애플리케이션에 기능을 추가해 애플리케이션을 개발한다. 이렇게 검증된 컴포넌트를 재사용함으로써 개발 기간의 단축뿐 아니라 소프트웨어 품질을 향상시킬 수 있게 된다.

Simple is the best!

개발이 다 된 소프트웨어를 어느 날 유지보수하기 위해 열어 보았더니 너무 복잡해서 개발 당사자도 한참 소스 코드를 분석하던 경험은 누구나 가지고 있을 것이다. 소프트웨어가 복잡해지면 개발뿐 아니라 유지보수시 영향도가 커져서 오류 발생률이 높아지고 결국 품질과 생산성을 떨어뜨릴 수 있다. 소프트웨어의 초기 버전은 모듈화도 하고 심플하게 개발되었을 것이다. 그러나 계속적인 요구사항 추가와 변경 작업을 통해 끊임없이 복잡해진다. 계속적인 사용자 요구사항의 증가와 요구사항 변화에 따라 변경을 지속하다 보면 소프트웨어는 계속 복잡해질 수밖에 없다.

개발 및 유지보수 시 품질 및 생산성을 향상시킬 수 있는 방안의 하나로 기능의 단순화와 소프트웨어 구조 단순화를 들 수 있다. 기능의 단순화는 요구사항 분석 단계에서 불필요한 기능을 제거하고 사용자가 원하는 기능만을 잘 정의해야 할 필요성이 있으며, 소프트웨어 구조 단순화는 설계 단계에서 독립된 모듈의 단위 크기를 적절하게 정의하는 것이 핵심이라 할 수 있다.

그리고 변경은 반드시 발생하기 나름이며 이 변경에 유연하도록 소프트웨어 구조를 설계해야 하며 변경할 때도 중간 중간 효율적인 구조로 재설계하는 부분이 설계에 반영되고 소프트웨어에도 반영되어야 한다. 개발자는 복잡하게 하는 것을 좋아하는 것 같다. 개발자는 자신의 소스 코드를 하나의 작품으로 생각하고 남이 지적하면 싫어할 정도로 애착과 자부심을 갖고 있다. 그래서 자신의 작품이 남이 보기에 화려하고 심도 있게 보이길 바라는 욕구가 있는 것 같다. 그래서 조금은 더 새로운 기술로 조금은 더 복잡한 기교를 사용해 코딩하고자 하며 더욱 더 많은 기능을 넣으려고 한다. 많은 기능을 추가하면 추가할수록 소프트웨어는 복잡해지고 복잡하면 복잡할수록 그 피해는 결국 개발자의 몫이 된다.

조금은 욕심을 버리고 간단한 것이 가장 좋다는 생각으로 불필요한 것을 조금씩 버리도록 하자! 소프트웨어가 복잡해지면 소프트웨어 모듈간의 Call Depth 또한 깊어질 수 있다. Call Depth가 깊어지면 소프트웨어 분석이 어려워지고 유닛 테스트(단위 테스트) 코드를 만들기가 힘들어지게 된다. 테스트가 용이하고 유지보수가 용이한 구조를 갖기 위해서는 소프트웨어 모듈간의 Call Depth 또한 고려해야 할 사항 중의 하나이다.

테스팅 팀의 임무와 테스팅 업무의 방향

테스팅을 위한 조직은 별도의 독립된 조직으로 존재하고 그로 인해 개발과 테스팅이 독립된 각각의 단계로 인식되고 업무가 진행되어야 한다. 개발팀에서 개발한 소프트웨어가 목표치에 도달했다고 판단되면 이를 검증하기 위해 QA팀에 전달하게 되고 이를 QA팀이 테스트 하게 된다. QA팀은 출시를 위해 소프트웨어의 기능과 성능 기준에 만족하는지를 검증하는 것을 주 업무로 생각하지만 소프트웨어 품질 및 생산성 향상의 관점에서 보았을 때는 전혀 품질 및 생산성 향상을 위한 활동으로 보이지 않는다. 이유는 이렇다. 문제를 안고 있는 소프트웨어 구조로 개발하고 아무리 많은 반복 테스트를 한다 하더라도 궁극적으로 품질이 좋아지는 것은 아니기 때문이다.

품질이 좋아지는 것에는 조금의 영향을 줄 수 있지만 생산성 측면에서는 테스팅 단계에서의 수정은 너무나 많은 비용을 지불하게 되는 것이다. 소프트웨어 문제는 구조적인 문제와 소스상의 문제가 있을 수 있는데 이러한 구조적인 문제와 소스의 문제점을 빨리 발견하고 해결한다면 개발 기간의 단축과 품질 향상 효과를 얻을 수 있다. 테스팅과 유지보수는 프로젝트에서 많은 시간을 차지해 중요한 부분으로 여겨지지만, 이를 달리 생각하면 리스크를 미리 줄이도록 효과적으로 테스팅 업무를 확대해 간다면 개선의 여지가 가장 많은 부분이라고 생각할 수도 있다. 테스터가 프로젝트 전 단계에 관여해 개발자가 발견하지 못한 리스크를 발견하고 테스트 용이성을 높여 조기에 문제를 발견하고 해결하므로 개발기간 단축 효과를 얻을 수 있다.

테스트 관련 업무를 정리해보았다. 유스 케이스(요구사항)를 기준으로 테스트 케이스 작성, 테스트 케이스를 통해 누락된 시나리오나 테스트가 어려운 부분 도출, 테스트가 용이한 구조 설계, 테스트를 위한 Mock Object 설계 및 개발(테스트 코드 재사용 가능), 테스트 가이드 제시, 소프트웨어 성능 목표치 설정 및 제시, 테스팅 지원, 결함 추적까지도 해야 한다.

테스팅 시 발생하는 문제는 독립적으로 발생할 수 있지만 다른 기능의 수행 이후에 이전 모듈의 문제로 발생하는 경향이 있으며 이를 찾기란 매우 힘들다. 테스트할 때 간헐적으로 발생하는 문제에 대해 재현하기란 여간 까다로운 것이 아니다. 테스트하면서 테스트 전후 상태를 명시하는 것은 도움이 될 수 있다. 테스트 케이스를 작성하고 여러 사람이 무작위로 순서 없이 테스트하지만 문제가 발생하는 정확한 순서가 있으므로 이를 항상 재현 가능하게 한다면 문제를 찾고 해결하는 데 많은 시간을 줄일 수 있다.

테스팅이 왜 어려운가?

개발이 완료되고 테스트를 무사히 마쳐서 제품이 출시되지만 실제 사용자로부터 수많은 문제점이 발견되어 돌아오게 된다. 왜 그렇게 많은 테스트를 했음에도 불구하고 오류가 발생하는 것일까? 테스터가 테스트를 잘못해서 그런 것일까? 그건 아니다. 테스터는 정해진 품질 규격에 맞을 때까지 테스트했으며 모든 테스트 케이스를 소프트웨어가 만족했기 때문에 승인을 한 것이다.

소프트웨어 테스트는 필터와 같아서 테스팅을 수행하는 동안 오류가 계속적으로 걸러지게 된다. 이 테스트라는 필터로 완벽하게 걸러내기란 불가능하다. 일정이 결정되어 있는데 계속해서 테스트만 할 수 없는 일 아닌가. 적정한 수준에서의 합의가 필요한 것이다. 그럼 테스트는 왜 어려운 것인가? 테스트가 어려운 이유를 몇 가지 생각해 보고자 한다.

1. 너무 복잡한 기능의 조합

시스템의 다양한 기능들이 존재하게 된다. 이 기능이 조합될 경우는 무수히 많은 케이스가 있는데 이 많은 케이스를 모두 테스트할 수 없으므로 테스트 되지 않은 잠재 오류를 내포하게 된다.

2. 실 환경과 동일한 테스트 환경의 부재

테스트는 가능한 한 동일한 환경에서 테스트해야만 잠재 오류를 많이 찾아낼 수 있으나 실제적으로 불가능한 경우가 많다. 고층 건물의 엘리베이터를 테스트하고자 테스트용 고층 건물을 만들 수는 없다.

3. 테스트 마인드 부재

테스트는 단순한 노동으로 생각하고 기피하는 경향이 많다. 정확하게 테스트하기 위해서는 테스팅 방법론이나 시스템에 대한 이해가 바탕이 되어야 한다. 테스트를 전문적인 업무 분야로 인정해 기피하는 업무가 아니라 선호하는 업무가 되는 환경을 만들 뿐만 아니라 테스터가 전문가로서의 자질을 겸비할 수 있도록 지원해야 한다.

4. 계속적인 요구사항 변경

개발에서도 힘들어 하지만 테스팅에서도 힘든 것 중의 하나가 계속적인 요구사항 변경이다. 요구사항이 변경되면 변경된 내용이 QA팀까지 전달되어 테스팅 오류를 줄여야 하지만, 급한 나머지 개발에서는 개발하고 이를 전달하지 않아 테스터가 잘못된 테스팅을 진행하는 경우가 있다. 이를 줄이기 위해 변경 프로세스 안에서 신속하게 개발과 테스팅에 변경사항이 반영될 수 있도록 해야 할 것이다.

5. 시간적 제약

개발된 소프트웨어를 테스트하는 데 충분한 시간 확보가 필요해 개발 초기에는 넉넉하게 테스팅 계획을 수립하게 된다. 그러나 프로젝트가 지연되면 테스팅 일정도 함께 지연된다. 그러면 개발 지연만큼 테스팅 일정이 뒤로 미뤄져야 맞지만 정해진 일정이 있으므로 테스팅의 일정을 줄여서라도 정해진 일정해 맞춰야 하므로 일정에 대한 압박이 있게 된다. 이렇게 되면 충분한 테스트를 하지 못하고 많은 오류를 포함한 채 출시되고 이는 고스란히 소비자의 불만으로 되돌아오게 된다.

문서 관리

프로젝트를 수행할 때 우리는 방법론에서 정의한 많은 문서를 만들어 낸다. 그것은 프로젝트의 이해당사자 간의 의사소통을 위해서 또는 CMMI 같은 인증을 받기 위해서 만들어 내기도 한다. 이러한 문서작업이 업무에 활용되지 않고 보이기 위한 목적으로 만들어져 문서화가 업무에 지장을 주는 경향이 있다. 문서화는 보여주기 위한 것이 아니고 의사소통 및 개발 수단이 되어야 함을 잊지 않아야 한다.

문서화의 중요한 포인트는 프로젝트를 진행하면서 만들어지는 문서는 단계별로 구체화되므로 문서의 추적성이 있어야 한다는 것이다. 만약 문서에 추적성이 없다면 문서 간의 내용이 다르기 때문에 혼란이 가중되어 사용되지 않는다. 또한 계속적으로 추가 및 변경되는 요구사항에 대한 반영이 정확히 이뤄져야 한다.

또한 문서를 수정하고 자신의 PC에만 저장해 놓는 경향이 있는데 그럴 경우 의사소통 및 개발 수단으로서의 문서 기능을 하지 못한다. 문서를 만들거나 수정했다면 그 문서는 모든 사람이 공유될 수 있는 장소에 보관되어 실시간으로 업데이트되는 문서를 공유할 수 있도록 해야 한다. 변경된 부분이 다른 부분과 밀접한 관련이 있다면 해당 담당자에게 통보해서 변경사항이 누락되지 않도록 해야 한다. 만약 아무런 목적 없이 보고를 위해 문서를 만든다면 문서는 개발자에게 아무런 이점을 주지 못할 것이고 오히려 방해 요소로 여겨질 것이다. 그 결과 문서는 쓰레기가 될 것이고 관리되지 않을 것이다.

UML은 Communication Tool이다

소프트웨어 분석 및 설계는 이해당사자 간에 의사소통 수단이다. UML은 그 수단으로 사용되어야 한다. UML이 의사소통의 수단으로 생각한다면 모든 이해당사자가 UML 다이어그램을 보고 이해 가능해야 하고 UML이 어떠한 툴로 그려져 있더라도 상관없게 된다. 꼭 UML 다이어그램을 그리기 위해 비싼 툴을 도입해야만 한다고 생각하고 툴이 없으니 UML 다이어그램을 그릴 수 없다고 생각할 필요가 없다. UML 툴을 이용한다면 손쉽게 그릴 수 있고 오류를 찾아 낼 수도 있으며 소스 생성도 할 수 있다. 그러나 UML의 주목적이 의사소통 수단이라고 생각하면 백지에 다이어그램을 그린다 하더라도 그 다이어그램은 의사소통 수단으로서 충분하다는 것이다. UML을 통해 이해당사자 간 생각의 차이를 좁혀갈 수 있으며 더욱 구체화시킬 수 있다. UML을 거창하고 어려운 것으로 생각하지 말고 Communcation Tool로 인식하고 접근하면 UML에 대한 느낌이 다를 것이다.

staged delivery

Staged Delivery는 소프트웨어 개발의 라이프 사이클(life cycle) 모델이다. 우리는 흔히 Waterfall 방식을 사용했으나 Waterfall 방식은 심각한 문제가 테스트 단계에서 발생되어 유지보수 비용 및 일정 지연 문제가 프로젝트 막바지에 발생하는 경향이 있다. 그래서 Iteration 방식이 출현하게 되었으며 Iteration 방식은 요구분석, 설계, 구현, 테스트의 과정을 Concern 단위로 반복해 진행하는 것으로 내포된 잠재 버그를 최대한 빨리 찾아내고자 했다.

그러나 이 방법 또한 전체 도메인을 이해하지 못하면서 Concern을 나눈다면 위험성이 높은 Concern을 먼저 개발하기 위해 선택하는 일이 힘들어지게 된다. 이를 보완하기 위해 하이브리드 방식인 Staged Delivery 방식을 사용할 수 있는데 Staged Delivery 방식은 분석 및 설계까지는 Waterfall 방식을 사용하고 구현 및 테스트는 Iteration 방식을 사용하는 것이다. 이렇게 하면 요구분석, 설계를 통해 전체 시스템 개발 중 위험성과 중요성이 가장 높은 Concern을 분류할 수 있을 것이고 우선순위가 가장 높게 도출된 Concern부터 Iteration 형태로 개발하는 것이다. Iteration 방법으로 개발을 못한다면 Staged Delivery 방식을 채택하길 권한다.

Non-Functional Features간의 상관관계

아래와 같이 많은 Non-Functional Features가 존재한다.

- Availability

- Performance

- Security

- Scalability

- Manageability

- Flexibility

- Portability

- Maintainability

소프트웨어 설계 시 이 Features간의 균형을 맞추는 것이 어려운 과제 중의 하나이다. <그림 3>에서 보는 것과 같이 모든 Features를 향상시킬 수 없다. 예를 들어 시스템의 Main tainability를 높이기 위해 로그를 많이 남긴다면 상대적으로 성능에는 좋지 않은 영향을 미치게 된다. Features 간의 트레이드 오프(trade off)가 있게 된다. 그러므로 분석 및 설계 시점에 현재 개발하는 시스템에서 확보해야 할 Non-Functional Features를 선택하고 이를 향상시키기 위한 아키텍처로 설계되어야 한다. 이를 고려하지 않고 기능 중심으로 개발하고 릴리즈되는 시점에 검토된다면 이로 인해 소프트웨어가 많이 수정되어야 해서 릴리즈가 불가능할 수도 있다. Non-Functional Features 간의 상관관계를 이해하고 프로젝트 성격에 맞는 Non-Functional Features를 미리 선정해 이를 확보하기 위한 노력을 해야 할 것이다.

<그림 3> Non-Functional Features 간의 상관관계

내재화의 필요성

많은 프로세스와 툴에 투자해 프로세스와 툴에서 원하는 결과를 얻을 수 있을 것이라 생각하지만 현실은 다르다. 팀의 모든 구성원이 프로세스와 툴에 대한 내재화가 부족하다면 정상적으로 프로젝트가 진행되지 않고 오히려 혼란만 가중될 뿐이다. 프로세스를 프로젝트에 정확히 적용시키며 툴에 대한 활용을 극대화하기 위해서는 모든 구성원이 프로젝트를 진행하는 데 있어 마치 한 몸처럼 움직일 때 기대하는 성과를 얻을 수 있다.

모든 팀원의 내재화 없는 프로세스와 툴은 의사소통의 혼란을 초래할 뿐만 아니라 프로세스나 툴 자체가 하나의 업무로 여겨지게 된다. 그로 인해 프로세스와 툴이 오히려 프로젝트 지연의 원인이 되기도 한다. 그래서 새로운 프로세스와 툴을 도입하기 위해서는 반드시 교육이 선행되어야 하며 모든 구성원들의 수준을 동일하게 끌어 올려야 효과 또한 끌어 올릴 수 있다.

프로젝트 성격에 따른 프로세스와 툴의 선정이 중요하며 선정된 프로세스와 툴에 대한 팀원의 내재화는 더욱 중요하며 반드시 필요하다.

한국 마이크로 소프트웨어 [2009년 9월호]