물리 법칙에는 여러가지 종류가 있습니다. 지구상에 있는 대상들은 특정 조건에서 물리의 법칙에 지배를 받습니다. 그 중에서 속도(velocity)는 많은 법칙에 존재하며, 특히 속도가 늘어나는 현상의 가속도를 사용하기도 합니다. 뉴턴의 두번째 운동 법칙인 가속도의 법칙은 힘(F) = 질량(m) * 가속도(a)로 나타냅니다. 여기서 가속도는 시간에 따른 속도의 순간적인 변화량을 뜻합니다. 가속도의 법칙은 운동의 변화는 가해진 힘에 비례하며 힘이 가해진 직선 방향으로 일어난다라는 것을 의미합니다.
SW 개발에 있어서 이 가속도의 법칙은 개발 속도에 비유될 수 있습니다. 개발 속도 역시 일정 시간 동안의 개발된 결과물이 산출되는 양으로 측정할 수 있다면, 어느 순간에 산출된 결과물의 양(특정 시점에 있어서 증분된 개발량)의 변화를 생각해볼 수 있습니다. 개발속도는 통상 일정하게 증가되는 형태로 나타날 가능성이 높습니다. 그러면 가속도의 법칙에 의해서 시간이 흐른다면, 개발 속도가 가속이 붙게되게 되고, 전체적인 개발의 변화는 빠른 성장을 이룹니다. 물론, 개발 속도를 저해하는 다양한 이벤트와 이슈로 인해서 특정 시점에는 이러한 속도가 감속되기도 하지만, 실험실 환경(이상적인 환경)이라고 보면 이러한 부분은 지금은 무시하겠습니다. 가속도는 개인적인 편차가 있지만, 개발 초기의 환경을 익히고 프로세스를 익히는 과정의 느린 속도로 출발하여 점차 요구사항이나 비즈니스가 명확해지면서 그 속도가 일반적으로 증가할 것입니다.
가속도의 법칙에서 가속도는 힘(F)에 비례하고, 질량(m)에 반비례하는 것으로 볼 수 있습니다. SW 개발에 있어서 힘(F)은 다양하게 비유가 될 수 있을 것 같습니다. 예를 들면, 잘 정리되고 개발하기 쉬운 개발 환경(자동화도구 포함)이나, 깔끔하고 원칙이 있는 아키텍처, 고객과의 좋은 관계, 팀 구성원들의 지적 수준 등이 개발 속도를 가속화시키는 힘이라고 볼 수 있습니다. 그렇다면 개발 속도에 반비례하는 질량(m)은 어떠한 관점에서 볼 수 있을까요? 가속도의 법칙에서 질량은 '관성질량'이라고 하며, '두 물체를 작용시켰을 때, 두 물체의 가속도는 항상 반대 방향이며, 그 크기의 비는 두 물체에 고유한 양이 된다'라고 설명하고 있습니다. SW 개발에 있어서 동일한 비즈니스의 구현에 대해서 비교를 통해 질량을 구해볼 수 있습니다. 동일한 기능을 구현하는데 한쪽에서는 전체 기능을 한번에 구현하는 방식을 취하고 다른 편에서는 전체 기능을 잘개 쪼개어서 구현한다고 하면, 전체 질량(기능)의 합은 동일할 수 있겠지만, 개발 (가)속도는 분명 차이가 날 것입니다.
즉, 질량은 SW 개발하는데 있어서 구현하는 기능의 양으로 비유할 수 있으며, 기능의 양이 많음은 개발 속도가 그 만큼 빨라질 수 없음을 의미합니다. 역으로 자그마한 기능을 구현하는 개발 속도는 상대적으로 빠르며, 이러한 개발 속도의 합이 기능 전체를 구현하는 개발의 속도와 비교해서 그 차이를 가늠해볼 수 있을 것입니다.
SW 개발을 하는데 있어서 질량에 해당되는 기능은 사실 고정적이지는 않습니다. 시간이 흐르면서 점점 확장되고 변화되기 때문에 현실적으로 고정된 질량을 보장할 수는 없습니다. 설사 고정적이라고 하더라도 기능을 적절한 크기와 관리할 수 있는 수준으로 나누어서 개발하지 않는다면 개발 (가)속도가 붙기까지는 상당한 시간과 노력이 들며, 일단 붙기 시작한 개발 (가)속도는 질량이 크기 때문에 쉽게 방향을 바꾸거나 멈추기가 어렵습니다. 작은 단위로 관리하고 테스트할 수 있는 형태의 개발 방식으로 개발 (가)속도를 효율적으로 관리하고, 이들의 총합인 전체 개발 (가)속도의 크기를 현저하게 증가시킬 수 있습니다.
만일 이러한 질량 자체도 어느 정도 유사한 형태의 도메인이라면(주로 동일 업무의 SI 개발이나, 패키지/솔루션을 활용한 개발 등) 개발 (가)속도는 힘의 관점에서 증가시킬 수 있습니다. 위에서 언급했듯이 이러한 힘에는 다양한 요소들이 있지만, 팀 구성원의 지적 수준(노하우의 정도)에 초점을 맞춘다면 프로젝트 기간 동안 팀 구성원이 이해하는 비즈니스 상황, 기술 상황을 어느 수준으로 유지할 것인가가 관건이 됩니다. 이러한 관점에서 본다면 개발자의 추가 투입이 결코 개발 속도에 영향을 주기 힘들다는 공식도 관련있게 됩니다. 즉, 프로젝트에 투입되는 개발자가 이해하는 비즈니스/기술의 정황의 이해도를 얼마나 빨리 습득/체득하는가가 개발 속도에 영향을 미치게 됩니다. 그래서 경험이 있는 개발자들을 선호하기는 하지만, 이마저도 현재의 상황(기술 변화의 속도와 다양성의 증가)에서는 꼭 맞는 개발자를 구하기도 어렵습니다.
가속도의 법칙을 통해서 SW 개발 (가)속도 법칙을 유추해본다면 다음과 같은 공식을 만들 수 있을 것입니다.
만일 이러한 질량 자체도 어느 정도 유사한 형태의 도메인이라면(주로 동일 업무의 SI 개발이나, 패키지/솔루션을 활용한 개발 등) 개발 (가)속도는 힘의 관점에서 증가시킬 수 있습니다. 위에서 언급했듯이 이러한 힘에는 다양한 요소들이 있지만, 팀 구성원의 지적 수준(노하우의 정도)에 초점을 맞춘다면 프로젝트 기간 동안 팀 구성원이 이해하는 비즈니스 상황, 기술 상황을 어느 수준으로 유지할 것인가가 관건이 됩니다. 이러한 관점에서 본다면 개발자의 추가 투입이 결코 개발 속도에 영향을 주기 힘들다는 공식도 관련있게 됩니다. 즉, 프로젝트에 투입되는 개발자가 이해하는 비즈니스/기술의 정황의 이해도를 얼마나 빨리 습득/체득하는가가 개발 속도에 영향을 미치게 됩니다. 그래서 경험이 있는 개발자들을 선호하기는 하지만, 이마저도 현재의 상황(기술 변화의 속도와 다양성의 증가)에서는 꼭 맞는 개발자를 구하기도 어렵습니다.
가속도의 법칙을 통해서 SW 개발 (가)속도 법칙을 유추해본다면 다음과 같은 공식을 만들 수 있을 것입니다.
개발 (가)속도 = (f(최적의 개발환경) * f(적합한 아키텍처) * f(고객과의 관계) * f(팀 구성원의 지적 수준)) * f(1/구현 기능의 양)
반응형
'Homo Ware' 카테고리의 다른 글
문제는 속도가 아니라 방향과 제어이다. (0) | 2012.04.14 |
---|---|
개발 가속도의 법칙 - 최적의 개발환경 (0) | 2012.03.26 |
Balanced shipping is a feature (0) | 2012.03.08 |
비즈니스 관점의 프로세스와 IT 관점의 프로세스 (0) | 2012.01.29 |
스마트의 의미 (0) | 2011.11.21 |