크리에이티브 커먼즈 라이선스
Creative Commons License

다른 산업과 달리 SW 산업은 제품을 만들어내는 기간을 정확하게 예측하기 어렵다는 것이다. 지금 진행되고 있는 프로젝트들을 포함해서 그동안 수많은 프로젝트들은 일정 관리라는 고유의 영역에서 전체 SW 개발 주기를 항목 단위별로 매일, 매주, 매월로 개발 상태를 관리하지만, 정해진 시간 내에 SW를 완성시키기란 상당히 힘들다는 것을 늘 느낀다.


만일, 개발 속도(velocity)를 수치로 표현할 수만 있다면, SW 제품을 만드는데 걸리는 시간을 계산할 수 있을 것이다. 따라서, 모든 프로젝트에서는 개발 속도, 즉 개발 생산성을 그 어느 것보다도 더 중요하게 생각하고 이를 매일 관리하도 한다. 개발 속도는 당연히 그 이면에 개발 범위(scope)라는 제약 변수가 있지만, 개발 범위는 늘 애매모호한 형태로 식별/분석되어서 기능이라는 단어로 포장되어 일정을 예측하게 만든다. 즉, 개발 속도(생산성)라는 단어로 늘 범위나 비즈니스 영역은 그 우선순위가 밀려나게 된다. 범위에 일정을 조정하거나 조율하는 형태가 아니라, 변화(증가)하는 범위는 고정된 일정에 맞추는 형태가 된다.


SW 개발에 있어서 문제는 허용된 고정 일정 내에 증가하는 범위의 기능을 구현한다는 것이다. 개발 속도는 늘 강력한 압박 속에서 경쟁적으로 몰아치지만, 비즈니스 관점의 요구사항이나 분석 수준은 초반의 문서들이 파일서버에 한 구석에만 틀혀박혀서 아무도 참고하지도 않은채 고이 모셔두고 있다는 것이다. 실용주의 입장에서는 소스 코드와 (설계) 문서의 간격을 최대한 줄이려는 노력들을 하고는 있지만, 소스 코드의 분량이 늘어나면 늘어날수록 점점 더 관리해야 하는 부가적인 (설계) 문서들이 늘어만 간다. (혹은 문서들은 점점 오래되어 현시점의 구현 내용을 반영하지 못한채 버리지도 변경하지도 못한채 흉물처럼 방치해 놓는다)


프로젝트 일정 산정, 과연 합리적일까?


프로젝트 초반, 수많은 사람들이 프로젝트를 착수하기 위한 다양한 활동들을 수행하는데, 그중에서 일정 산정은 가장 중요한 활동 중에 하나이다. 전체 범위를 구획화시키고 그 구획화된 업무들을 다시 중소규모의 업무로 나누어서 최소 단위의 업무로 구분하여 각 업무의 일정들을 산정하는 방식이 WBS(Work Breakdown Structure) 방식이다. MS에서 만든 MS Project가 대표적인 WBS 도구이며, 대부분의 프로젝트는 어느새 이 WBS 기반의 일정을 만들게 된다.


WBS는 나뉘어진 업무들이 상호 배타적(mutually exclusive)이어야 하며, 전체의 합이 100이 되도록 구성해야 한다. 물론, WBS가 일정을 체계적으로 관리하기 위한 하나의 기법으로 채택하는 것은 프로젝트의 수행자들의 선택이겠지만, 모든 프로젝트가 오로지 WBS 하나에만 의존하는 형태는 결코 바람직하지 못하다. 프로젝트에서 늘 문제가 되는 부분은 WBS 상에 표기된 기능이 과연 WBS로 관리할 수 있는 성격인 것인가이다.


요즘의 SW가 기능 체계도(functional decomposition)나 Top-Down 방식의 분해로 만들어지는 성격들이 아니기 때문이다. 그리고, 이와 같은 기법으로 기능을 명확하게 분류하기란 여간 까다롭고 시간이 걸리는 작업이기 때문에 짧은 프로젝트 기간에 이와 같은 기능 분류를 한다는 것은 거의 현실적이지 못하다. 예를 들어, A라는 기능이 해당 내용을 저장하는 기능이라면, 그 기능 속에는 다양한 업무와 다양한 제어 로직들이 포함할 수 있어서 단순한 저장이 아닌 조회/수정/삭제가 같이 발생하는 기능이 될 수도 있다. 이는 비즈니스 환경의 변화나 기술의 발전과도 무관하지 않은 것으로 높은 사양의 PC나 클라이언트가 나타나면서 한번에 더 많은 기능을 경쟁적으로 추가하기도 하며, 비즈니스 환경(고객의 요구)이 되도록이며 더 많은 자동화 요소를 요구하기 때문이다.


현실적인 관점에서 트리 형태의 기능 분류는 비즈니스 모델링의 상위 레벨 수준의 분류 정도만 가능하며, 시스템 레벨에서의 기능 분류를 모두 식별하기란 만만치 않은 작업이다. 그리고, 이러한 작업을 단순히 몇사람만(혹은 한명만) 작업해서 전체 일정을 결정한다는 것은 지금의 현실은 전혀 받아들이기 힘든 상황이다. (받아들이기 힘든 상황이 이루어지는게 현실이긴 하지만)


결론적으로, 프로젝트 일정 산정은 결코 신뢰해서도 안되며 신뢰될 수 있는 예측치에 불과하다. 그렇다고 계획을 세우는게 의미없는 활동이라는 의미가 아니다. 계획은 계획을 수립하는 활동 그 자체로 의미가 있다. 계획을 세우는 동안 수많은 연결고리들을 생각해볼 수 있으며. 특히 이러한 수립 활동을 단지 혼자나 몇몇이 아닌 전체가 공유한다고 하면 전반적인 프로젝트 범위를 사전에 미리 공유할 수도 있을 것이다. 산정된 프로젝트 일정은 결코 맹신하거나 꼭 지켜야 하는 마일스톤과는 다르다. 진척율이라는 개발 활동 결과 역시 수치적으로는 아무런 의미가 없을 수도 있다. 20%의 진척율이 의미하는 것이 기능의 중요한 부분이라면 이는 전체 개발 범위의 80%에 해당할 수도 있기 때문에 겉으로 드러난 수치에 대해서 민감하게 반응할 필요는 더더욱 없다. 이러한 수치가 과연 합리적이고 과학적으로 산정이 되었다면 어느 정도 현실의 진척율에 근접할 수도 있겠지만, 눈대중으로 엑셀에 수치를 적어서 관리하는 형태는 결코 프로젝트 일정 관리에 전혀 도움이 되지 못한다.


프로젝트 일정 산정 방식은 지금의 방식과는 다른 접근 방식을 취할 필요가 있으며, 이에 맞추어서 프로젝트가 진행되어야 한다.


범위는 과연 고정될 수 있는가?


프로젝트 관리자의 가장 훌륭한 역할 중에 하나를 꼽는 것이 고객의 끝없는 요구사항들을 쳐내거나 막는 행위로 보는 사람들도 많다. 즉, 요구사항이 변경되는 것이 가장 위험하며 이를 얼마나 효과적으로 통제할 수 있을 것인가가 PM의 중요한 역량으로 바라보는 것이다. 하지만, 요구사항이라는 단어 만큼 수많은 의미와 혼돈을 담고 있는 단어도 없다. 고객 입장에서는 단순한 기능이라고 하더라도 시스템 입장에서는 수많은 내부 설계를 바꾸어야 하는 것들이 있는가 하면, 고객은 엄청난 변화라고 생각하지만, 시스템에서는 단순히 데이터만 변경하면 되는 경우도 많다. 범위가 고정될 수 없는 속성을 가진다는 것은 고객이나 프로젝트를 수행하는 사람들에게는 모두 잘 알고 있고, 그러기에 중요한 위험 요소로 관리하고 있다.


SW 프로젝트에서는 이러한 동적인 범위를 관리할 수 있을 만한 효과적인 방법을 찾아내지 못하면 분석/설계 과정에서 모든 요구사항을 도출하고 여기에 꼬리표를 붙여서 관리하려는 욕구를 가진다. 결국 분석/설계 단계에서 고정된 범위는 개발이나 인도 단계까지에도 영향을 미치며 방향을 움직이지 못하는 차를 운전하는 것과 같은 현상을 만들어낸다. 예를 들어, 특정 구간이 차가 밀려 우회하여 다른 길로 돌아가도 큰 지장이 없고 오히려 효과적임에도 불구하고 방향을 움직이지 못하는 핸들로 인해서 앞에 밀려있는 차가 다 빠져나갈때까지 한없이 기다려야만 하는 현상이 나타나기도 한다.


범위(scope)라는 단어가 갖는 늬앙스로 인해서 촘촘한 식별작업이 SW를 구현할 범위를 결정짓는다는 환상을 갖게 만든다. 통상 범위는 하나의 뷰(view)로 정리되기 어려운 성질을 가지고 있다. 이해관계자의 관점(perspective)에 따라서 동일한 단어라 하더라도 이해하는 정도의 차가 존재하기 마련이며, 이를 고정한다는 것 자체가 SW의 본질적인 목적을 희석시키는 결과를 만든다. 때로는 추정(estimation)이라는 단어로 범위를 다른 해석을 바라보게 만드는 경우도 있다. 추정은 기반이 되는 여러 방향성들 중에서 최적의 방향을 결정짓는 방식으로 최소한 이전에 시도했던 방향을 이미 가지고 있어야 한다. 하지만, 범위 확정과 같은 의미로 추정을 사용함으로써 추정된 결정은 고착화된 결론으로 받아들여 추정을 잘못한다는 비난을 만들어내기도 한다. 추정은 말 그대로 잘못될 수 있음의 여지를 포함하는 단어로 추정이 잘못되었다고 하더라도 방향을 잘 유지한다면 그 자체가 비난받을 일은 아니다. (이는 마치 잘못된 골목길로 차를 모는 것과 같은 현상으로 제대로 된 길을 가기 위한 수많은 시도들 중에 하나이며, 그러한 시도가 전체 범위를 알아가는 노력으로 의미가 있을 수 있다.)


지도를 펼쳐놓고 (SW 개발에서 확정된 지도를 가지기란 불가능하다. 듬성 듬성 목표 지점만을 가지고 있으며, 이러한 목표 지점을 표시한 지도를 가지는 것 자체 역시 상당히 어렵다) 정해진 경로를 통해서 진행하는 방식을 SW 개발이라고 보면, 그러한 지도 역시 바뀐다는게 큰 특징 중에 하나이다. 지도 위에서 높은 등고선을 가진 산으로 표시되었던 내용은 시간이 지남에 따라 낮은 언덕이 되기도 하며, 앝은 개울가로만 보였던 내용은 깊고 넓은 호수로 변하는게 비일비재한 현상이다. SW 개발에 있어서 범위라는 제약사항은 결코 고정된 형태가 될 수 없는 성질을 가지고 있다.


아키텍처는 과연 고정될 수 있을까?


아키텍처를 논하려면 상당한 인내가 필요하고, 다양한 정의들을 필요로 한다. SW 개발에 있어서 아키텍처를 어떠한 관점에서 바라볼 것인가는 늘 논란거리가 되며, 그러한 논란을 어떻게 합일점을 이루는가도 역시 보이지 않는 많은 노력이 들어간다. 아키텍처는 SW의 틀과 같기 때문에 아키텍처를 얼마나 빨리 고정시킬 수 있을 것인지가 SW 개발에 중요한 요소이기도 하다. 만일 SW 아키텍처를 고정적인 요소로 본다면 SW의 비기능 요구들 역시 고정적이라고 봐야 한다. 하지만, 비기능 요구들 역시 시간의 흐름에 따라서 바뀌고 그 기준치 역시 바뀌게 마련이다. 지금 중요하게 생각하는 비기능들이 법제도나 비즈니스 환경에 따라서 얼마든지 바뀔 수가 있다. 예를 들어, 사용자 정보에 대한 보안이 사회적인 이슈로 나타나면서 보안성의 품질 요소는 인터넷 환경에서 상당히 중요한 요건이 되기 시작했다. 기존에 이러한 품질에 대해서 전혀 신경쓰지 못했던 SW라면 이러한 보안성을 어떻게 강화시킬 것인지가 SW 아키텍처에 표현되고 영향을 미치게 되어 있다. 보안에 대한 문제가 계속해서 나타나는 이유 중에 하나는 SW 아키텍처에 이러한 품질을 애초부터 크게 고려하지 않았다는 반증이기도 하며, 이미 많은 기능을 안고 있는 SW 아키텍처에 이러한 비기능 요소를 강화시키기에는 너무나도 많은 것들에 영향을 미치기에 힘든(혹은 많은 작업을 필요로 하는) 작업이 될 가능성이 높다.


즉, SW 아키텍처는 고정될 수 있는 성질을 지닌 형태로 설계되는 것보다 언제든지 SW를 바라보는 관점에 따라서 바뀔 수 있는 형태로 설계되어야 함을 의미한다. 아키텍처가 바뀔 수 있다(혹은 진화할 수 있다)라는 전제는 SW를 만드는 입장에서도 상당한 부담이 될 수 밖에 없다. 아키텍처는 최소한 품질 속성에 대해서 얼마든지 확장 가능하거나 대체 가능한 형태로 만들어져야 됨을 의미한다. 이는 비단 SW 아키텍처 설계만을 의미하는 것은 아니다, 그러한 형태로 만들어진 SW 아키텍처에 얻혀지는 기능 역시 동일한 품질 기준을 달성해야 됨을 의미한다. 확장 가능한 아키텍처 형태로 클라우드 개념을 도입했다면, 클라우드를 기반으로 하는 비즈니스 로직들이 느슨한 관계로 연결되지 않는 한 아무리 아키텍처를 바꾸어 본들 비즈니스의 유연성을 보장하기는 힘들다.


브레이크는 더 빨리 달리기 위한 장치이다.


SW 개발에서 개발속도는 많은 부분에 영향을 미치며 따라서 개발속도와 관련된 것들이 어떠한 형태로 영향을 미치는지를 가늠해볼 필요는 있다. 즉, 계기판에 나타난 속도계의 수치만을 보고 개발속도를 가늠하기도 한다. 그렇지만, 브레이크라는 장치가 없으면 자동차는 속도를 내기 힘들다. 브레이크 없이 자연적인 법칙으로 차를 세워야 한다면, 자동차는 빠른 속도를 낼 수 없다. 최소한 자연적으로 멈출 수 있을 만한 속도로 자동차를 몰아야 위급 상황에서 멈출 수 있다. 브레이크가 있다라는 의미는 얼마든지 원하는 지점에서 차를 멈출 수 있고, 다시 원하는 속도로 차를 몰 수 있다라는 의미이다.



Modarres Highway / Tehran
Modarres Highway / Tehran by Hamed Saber 저작자 표시



SW 개발에서 브레이크가 없는 개발속도는 더디게 마련이다. 브레이크는 자동차의 크기와 종류에 따라서 그 장치가 다르며, 수동이나 자동에 따라서 움직이는 메커니즘이 다르다. SW 개발에서 속도를 제어하기 위한 장치들은 오히려 속도를 높일 수 있게 하기 위해서 필요하다. 개발자들의 능력과 개발 문화에 어울리는 개발 환경, 전반적인 개발 내용을 파악할 수 있는 높은 수준의 문서들, 핵심내용을 표현하는 설계 문서, 지속적인 품질 향상을 위한 메커니즘들. 이러한 모든 것들은 개발 속도를 저해하는 것처럼 보이지만, 멈춰야 할 때와 어디로 가야하는지를 알려주는 브레이크나 핸들과 같은 것들이다. 브레이크나 핸들을 단순히 해당 기능만을 수행하도록 만들 수도 있겠지만, 좀더 운전자가 편리한 기능을 부여할 수도 있다. 가야하는 길들을 사전에 알려주는 기능이 추가된다면, 미리 방향성을 인지하여 마음의 준비를 할 수 있거나 차선을 바꿀 수도 있다. 기능이 사용되는 최종 모습을 알려준다면, 그리고, 현재 만들고 있는 기능이 그 안에서 어떤 부분을 차지하고 있는지를 안다면 방향을 바꾸거나 수정하는데 최소한 설계 측면의 고려를 하여 이를 반영할 수도 있을 것이다. 차를 멈추는데 급작스런 브레이크를 작동시키는 대신에 여러차례 나누어서 브레이크를 조정한다면 좀더 안전하게 (안락하게) 차를 제어할 수 있을 것이다. 마찬가지로 갑자기 설계 문서를 만들거나 품질을 점검하는 것보다는 점점 기능이 풍부해지는 과정을 설계 문서와 같이 표현하거나 품질을 자동으로 매일 점검하는 장치를 둔다면 SW를 좀더 안전하게 만들 수 있을 것이다.


SW는 겉으로 보기에 사람을 투입해서 완성해가는 인력 기반의 공정을 가지는 것처럼 보이겠지만, 브레이크와 핸들이라는 장치를 통해서 자동차가 더 빠르고 안전하게 달릴 수 있듯이 SW 개발과 관련된 사람들이 인지하고 공감할 수 있는 장치들을 통해서 제대로 된 방향과 그에 맞는 제어를 할 수 있는 분위기 역시 무시못할 요소 중에 하나이다.




저작자 표시 비영리 동일 조건 변경 허락
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
먼저번 가정에서 개발 가속도는 최적의 개발환경에 비례한다고 가설을 세웠습니다. 개발환경은 최고 수준보다는 최적을 지향해야 합니다. 무조건 개발자 PC의 성능이 좋거나 네트워크가 빠르다고 해서 개발 생산성이 좋다고 말할 수 없으며, 가장 비싸고 성능이 좋은 IDE 도구를 갖춘다고 해서 개발 생산성이 높아진다고 단정할 수는 없습니다. 개발환경과 개발하려는 대상의 아키텍처와는 궁합이 맞아야 하며, 이를 가지고 작업하는 개발자에도 친숙하고 쉽게 접근할 수 있는 환경이 최적화된 개발환경입니다.

통상 개발환경은 작업자인 개발자의 환경인 개인 작업장(workspace), 공용으로 (통합용으로) 사용되는 공유 개발 환경, 형상항목을 이력 관리하는 형상 환경, 개인 작업장과 공유 개발 환경을 연결해주는 배포 환경 등으로 나뉠 수 있습니다. 물론, 테스트를 위한 환경 역시 개발환경에 포함될 수도 있습니다.

모든 개발환경에 공통적으로 적용되는 원칙은 깨끗한 상태를 유지해야 한다는 것입니다. [클린 코드와 클린 작업장, 항상 청결을 유지하라] 깨끗한 상태를 유지하려면 무엇보다도 많은 노력이 들 수 밖에 없으며, 이러한 노력은 실제 개발을 수행하는 개발자에게는 또 다른 부담이 되기도 합니다. 깨끗한 상태를 유지하려는 노력은 다분히 반복 수행적인 작업들이 많으며, 이러한 작업들은 자동화를 통해서 상당히 많은 부담을 경감시킬 수 있습니다. [TDD, CI, CD]

개발환경이 만들어지는 시점은 아키텍처의 기본적인 골격이 어느 정도 나타나는 시점과 비슷합니다. 즉, 아키텍처가 만들어지는 시점에 개발환경에 관련된 부분들이 같이 고려가 되어야 하며, 필요한 SW 구성 요소들이 아키텍처를 통해서 식별/조합될 때 개발환경에 필요한 구성 요소들도 같이 식별/조합됩니다. 하지만, 개발환경의 구성 요소들이 모두 식별되었다고 하더라도 이를 어떻게 운영하고, 어떠한 방식으로 조화를 이룰지는 순전히 개발자의 몫입니다. 형상관리 도구를 아무리 비싸고 성능이 좋은 것을 선정했다고 하더라도 형상항목에 대한 디렉토리 구조를 체계적이거나 직관적으로 구성하지 못하면 형상항목을 찾는데에만 시간을 낭비하거나 동일하거나 유사한 내용이 중복되어 관리되어서 형상관리 도구를 사용하지 않느니만 못합니다.

최적의 개발환경은 최적의 개발도구를 선정하는 것 뿐만 아니라, 최적의 개발 상태를 유지하도록 체계적이고 직관적인 개발환경을 관리하는 것까지 포함됩니다. 이와 같은 관리를 하려면 선정된 개발도구가 미처 제공하지 못하는 기능들을 확장하거나 변형하여 현재의 개발 상태를 최적화시킬 수 있는 장치를 추가로 고안해야 한다는 의미입니다. 예를 들어, 수많은 컴포넌트들의 의존관계로 인해서 빌드/통합에 많은 시간을 필요로 한다면, 변경되지 않은 컴포넌트에 대한 빌드를 제외하고 변경된 컴포넌트들만 빌드/통합하도록 변경할 필요가 있습니다. 매회의 빌드는 형상도구에서부터 변경된 내용만을 체크아웃받고, 변경되지 않은 컴포넌트를 빌드하는 순간에 빌드를 건너뛰어 이전에 빌드된 내용으로 그 다음으로 진행하도록 하면 많은 시간을 절약할 수 있습니다. 이와 같은 내용은 빌드 도구가 이를 지원하지 않는다면 간단한 스크립트나 확장을 통해서 가능할 것입니다. 이러한 내용들은 초반에 개발환경을 선정하는 시점에는 나타나지 않은 문제들이지만, 계속해서 빌드 내용을 모니터링하여 빌드 프로세스를 조정해야 하는 것입니다.

최적은 어느 순간을 의미하는 것이 아니라, 꾸준히 지속적으로 관리되는 상태를 의미합니다. SW 개발의 처음부터 끝까지 (이후 유지보수를 지나 해당 SW 폐기까지) 개발환경이 최적화 상태를 유지하려는 노력은 개발 생산성/가속도에 보이지 않게 영향을 미치는 요소입니다.
저작자 표시 비영리 동일 조건 변경 허락
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
물리 법칙에는 여러가지 종류가 있습니다. 지구상에 있는 대상들은 특정 조건에서 물리의 법칙에 지배를 받습니다. 그 중에서 속도(velocity)는 많은 법칙에 존재하며, 특히 속도가 늘어나는 현상의 가속도를 사용하기도 합니다. 뉴턴의 두번째 운동 법칙인 가속도의 법칙은 힘(F) = 질량(m) * 가속도(a)로 나타냅니다. 여기서 가속도는 시간에 따른 속도의 순간적인 변화량을 뜻합니다. 가속도의 법칙은 운동의 변화는 가해진 힘에 비례하며 힘이 가해진 직선 방향으로 일어난다라는 것을 의미합니다.

SW 개발에 있어서 이 가속도의 법칙은 개발 속도에 비유될 수 있습니다. 개발 속도 역시 일정 시간 동안의 개발된 결과물이 산출되는 양으로 측정할 수 있다면, 어느 순간에 산출된 결과물의 양(특정 시점에 있어서 증분된 개발량)의 변화를 생각해볼 수 있습니다. 개발속도는 통상 일정하게 증가되는 형태로 나타날 가능성이 높습니다. 그러면 가속도의 법칙에 의해서 시간이 흐른다면, 개발 속도가 가속이 붙게되게 되고, 전체적인 개발의 변화는 빠른 성장을 이룹니다. 물론, 개발 속도를 저해하는 다양한 이벤트와 이슈로 인해서 특정 시점에는 이러한 속도가 감속되기도 하지만, 실험실 환경(이상적인 환경)이라고 보면 이러한 부분은 지금은 무시하겠습니다. 가속도는 개인적인 편차가 있지만, 개발 초기의 환경을 익히고 프로세스를 익히는 과정의 느린 속도로 출발하여 점차 요구사항이나 비즈니스가 명확해지면서 그 속도가 일반적으로 증가할 것입니다.

가속도의 법칙에서 가속도는 힘(F)에 비례하고, 질량(m)에 반비례하는 것으로 볼 수 있습니다. SW 개발에 있어서 힘(F)은 다양하게 비유가 될 수 있을 것 같습니다. 예를 들면, 잘 정리되고 개발하기 쉬운 개발 환경(자동화도구 포함)이나, 깔끔하고 원칙이 있는 아키텍처, 고객과의 좋은 관계, 팀 구성원들의 지적 수준 등이 개발 속도를 가속화시키는 힘이라고 볼 수 있습니다. 그렇다면 개발 속도에 반비례하는 질량(m)은 어떠한 관점에서 볼 수 있을까요? 가속도의 법칙에서 질량은 '관성질량'이라고 하며, '두 물체를 작용시켰을 때, 두 물체의 가속도는 항상 반대 방향이며, 그 크기의 비는 두 물체에 고유한 양이 된다'라고 설명하고 있습니다. SW 개발에 있어서 동일한 비즈니스의 구현에 대해서 비교를 통해 질량을 구해볼 수 있습니다. 동일한 기능을 구현하는데 한쪽에서는 전체 기능을 한번에 구현하는 방식을 취하고 다른 편에서는 전체 기능을 잘개 쪼개어서 구현한다고 하면, 전체 질량(기능)의 합은 동일할 수 있겠지만, 개발 (가)속도는 분명 차이가 날 것입니다. 

즉, 질량은 SW 개발하는데 있어서 구현하는 기능의 양으로 비유할 수 있으며, 기능의 양이 많음은 개발 속도가 그 만큼 빨라질 수 없음을 의미합니다. 역으로 자그마한 기능을 구현하는 개발 속도는 상대적으로 빠르며, 이러한 개발 속도의 합이 기능 전체를 구현하는 개발의 속도와 비교해서 그 차이를 가늠해볼 수 있을 것입니다.

SW 개발을 하는데 있어서 질량에 해당되는 기능은 사실 고정적이지는 않습니다. 시간이 흐르면서 점점 확장되고 변화되기 때문에 현실적으로 고정된 질량을 보장할 수는 없습니다. 설사 고정적이라고 하더라도 기능을 적절한 크기와 관리할 수 있는 수준으로 나누어서 개발하지 않는다면 개발 (가)속도가 붙기까지는 상당한 시간과 노력이 들며, 일단 붙기 시작한 개발 (가)속도는 질량이 크기 때문에 쉽게 방향을 바꾸거나 멈추기가 어렵습니다. 작은 단위로 관리하고 테스트할 수 있는 형태의 개발 방식으로 개발 (가)속도를 효율적으로 관리하고, 이들의 총합인 전체 개발 (가)속도의 크기를 현저하게 증가시킬 수 있습니다.

만일 이러한 질량 자체도 어느 정도 유사한 형태의 도메인이라면(주로 동일 업무의 SI 개발이나, 패키지/솔루션을 활용한 개발 등) 개발 (가)속도는 힘의 관점에서 증가시킬 수 있습니다. 위에서 언급했듯이 이러한 힘에는 다양한 요소들이 있지만, 팀 구성원의 지적 수준(노하우의 정도)에 초점을 맞춘다면 프로젝트 기간 동안 팀 구성원이 이해하는 비즈니스 상황, 기술 상황을 어느 수준으로 유지할 것인가가 관건이 됩니다. 이러한 관점에서 본다면 개발자의 추가 투입이 결코 개발 속도에 영향을 주기 힘들다는 공식도 관련있게 됩니다. 즉, 프로젝트에 투입되는 개발자가 이해하는 비즈니스/기술의 정황의 이해도를 얼마나 빨리 습득/체득하는가가 개발 속도에 영향을 미치게 됩니다. 그래서 경험이 있는 개발자들을 선호하기는 하지만, 이마저도 현재의 상황(기술 변화의 속도와 다양성의 증가)에서는 꼭 맞는 개발자를 구하기도 어렵습니다.

가속도의 법칙을 통해서 SW 개발 (가)속도 법칙을 유추해본다면 다음과 같은 공식을 만들 수 있을 것입니다.

개발 (가)속도 = (f(최적의 개발환경) * f(적합한 아키텍처) * f(고객과의 관계) * f(팀 구성원의 지적 수준)) * f(1/구현 기능의 양)


 
저작자 표시 비영리 동일 조건 변경 허락
신고

+ Recent posts

티스토리 툴바