27장: 프로그램의 크기가 구현에 미치는 영향

27장: 프로그램의 크기가 구현에 미치는 영향

• 소프트웨어 규모 확대는 작은 프로젝트의 모든 요소를 같은 비율로 늘리는 일이 아님.
• 코드가 10배인 프로젝트는 전체 노력이 약 30배, 구현은 25배, 아키텍처와 시스템 테스트는 40배가 들 수 있으며 오류도 15배 이상 생길 수 있음.
• 작은 프로젝트의 비형식적인 방식을 그대로 키우면 통제하기 어렵고, 큰 프로젝트의 엄격한 방식을 작은 프로젝트에 그대로 쓰면 절차의 무게에 눌림.

27.1 의사소통과 규모

• 팀원이 n명이고 모두 서로 소통한다면 잠재적인 의사소통 경로는 n(n-1)/2개임.
• 2명은 1개, 5명은 10개, 10명은 45개이며 50명은 1,200개가 넘음.
• 팀이 커질수록 의사소통 시간과 오해 가능성이 급격히 늘어나므로 경로를 합리적으로 제한하고 정돈할 조직 기법이 필요함.
• 대표적인 방법은 정보를 문서로 공식화하는 것임. 모든 사람이 매번 서로 설명하는 대신 공통 텍스트·그림·전자 문서를 읽고 갱신함.

27.2 프로젝트 규모의 범위

• 프로젝트 규모의 범위가 넓어 하나의 크기를 전형적이라고 할 수 없음.
• 큰 프로젝트의 수는 적지만 프로젝트마다 많은 인력이 참여하므로 전체 프로그래머의 상당수가 큰 팀에서 일함.

27.3 프로젝트 규모가 오류에 미치는 영향

• 프로젝트가 커지면 오류의 수뿐 아니라 발생 원인의 구성도 달라짐.
• 작은 프로젝트에서는 구현 오류가 전체의 약 75%를 차지하고 개별 프로그래머의 역량이 품질에 큰 영향을 줌.
• 큰 프로젝트에서는 요구사항과 아키텍처 작업이 늘어 구현 오류의 비율이 약 50%까지 낮아질 수 있음. 다만 일부 대형 프로젝트에서는 구현 오류가 여전히 75%에 이름.
• 규모가 2배가 되면 오류 수도 단순히 2배가 되는 것이 아니라 코드 1,000줄당 결함 밀도까지 증가함.

• 대형 프로젝트가 소형 프로젝트와 같은 오류율을 달성하려면 요구사항, 아키텍처, 구현 전반에서 더 강한 결함 예방과 제거 활동이 필요함.
• 산업 자료에서 초대형 프로젝트의 KLOC당 오류 수는 소형 프로젝트보다 최대 4배까지 많았음.

27.4 프로젝트 규모가 생산성에 미치는 영향

• 2K LOC 이하에서는 개인의 역량이 생산성에 가장 큰 영향을 주지만 규모가 커질수록 팀 규모와 조직 방식의 영향이 커짐.
• 한 실험에서는 2명 팀이 3명 팀보다 생산성이 39% 높았으며, 작은 인원 차이도 생산성에 영향을 줄 수 있음을 보여 줌.

• 실제 생산성은 소프트웨어 종류, 인력 수준, 언어, 방법론, 복잡도, 도구, LOC 집계 방식 등에도 크게 좌우됨.
• 세부 수치보다 규모가 커질수록 생산성이 낮아지는 경향이 중요함. 소형 프로젝트는 대형 프로젝트보다 2~3배, 가장 작은 프로젝트는 가장 큰 프로젝트보다 5~10배 높은 생산성을 보일 수 있음.

27.5 프로젝트 규모가 개발 활동에 미치는 영향

활동 비율과 규모

• 1명 프로젝트에서는 개인이 성공과 실패를 좌우하지만, 25명 프로젝트에서는 조직이 더 큰 영향을 미침.
• 작은 프로젝트에서는 구현이 전체 개발 시간의 최대 65%를 차지하고, 중간 규모에서는 약 50%로 줄어듦.
• 큰 프로젝트에서는 아키텍처, 통합, 시스템 테스트가 더 빠르게 늘어 구현이 전체 노력에서 차지하는 비율이 작아짐.
• 구현 작업은 규모에 거의 선형으로 증가하지만 다음 활동은 규모보다 빠르게 증가함.
  • 의사소통, 계획, 관리
  • 요구사항 개발, 시스템 기능 설계, 인터페이스 설계·명세, 아키텍처
  • 통합, 결함 제거, 시스템 테스트, 문서 작성
• 코드가 10배로 커지면 구현 노력은 약 25배, 계획은 25~50배, 통합은 30배, 아키텍처와 시스템 테스트는 40배까지 늘 수 있음.
• 약 10K LOC 프로젝트는 전체 노력의 5% 정도를 요구사항과 아키텍처에 쓸 때 비용이 낮았지만, 100K LOC에서는 15~20%가 적절했음.
• 규모와 관계없이 규율 있는 코딩, 동료의 설계·코드 검사, 좋은 도구, 고급 언어는 유용하며 큰 프로젝트일수록 더 중요함.

프로그램, 제품, 시스템, 시스템 제품

• 프로그램: 개발자 자신이나 소수 사용자가 비형식적으로 사용하는 단일 프로그램임.
• 제품: 다른 환경의 사용자도 쓸 수 있도록 충분히 테스트하고 문서화하며 타인이 유지보수할 수 있게 만든 프로그램으로, 단순 프로그램보다 약 3배의 비용이 듦.
• 시스템: 여러 프로그램이 함께 동작하도록 인터페이스를 만들고 통합한 것으로, 단순 프로그램보다 약 3배의 비용이 듦.
• 시스템 제품: 제품 수준의 완성도와 시스템의 다중 구성 요소를 모두 갖추며 단순 프로그램보다 약 9배의 비용이 듦.
• 단순 프로그램 경험만으로 시스템 제품을 추정하면 비용과 일정을 거의 10배까지 과소평가할 수 있음.
• 2K LOC 구현 경험만으로 2K 프로그램 전체를 추정하면 비구현 활동을 빠뜨려 실제 시간이 약 50% 더 들 수 있고, 같은 경험으로 32K 프로그램을 추정하면 실제 시간이 100% 더 들 수 있음.

방법론과 규모

• 작은 프로젝트의 방법론은 비형식적이고 직관적인 반면, 큰 프로젝트의 방법론은 엄격하고 의식적으로 계획됨.
• 명시적으로 고르지 않았더라도 모든 작업 방식은 방법론임. 큰 프로젝트에서는 무의식적인 선택만으로 복잡성을 감당할 수 없음.
• 형식적인 절차를 잘못 적용하면 산출물 작성 비용이 이득을 삼키지만, 큰 팀의 의사소통을 조정하려면 더 많은 계획과 문서가 필요함.
• 1K LOC 프로젝트는 노력의 약 7%를 문서 작업에 쓰지만 100K LOC 프로젝트는 약 26%를 쓸 수 있음.
• 문서는 그 자체가 목적이 아니라 계획을 충분히 생각하고 팀 전체에 전달한 결과여야 함. 내용 없는 범용 문서를 형식적으로 만들고 있다면 방법론을 잘못 적용한 것임.
• 큰 방법론을 작은 프로젝트에 맞게 덜어 내기보다 작은 방법을 필요한 만큼 확장하는 편이 나음.
• 가벼움과 무거움 중 하나를 고르는 것이 아니라 프로젝트의 규모와 종류에 맞는 적정 무게(right-weight)의 방법론을 선택함.

참고 자료

• 배리 뵘·리처드 터너, Balancing Agility and Discipline (Addison-Wesley, 2004): 프로젝트 규모에 따른 애자일 방식과 계획 중심 방식의 균형을 다룸.
• 앨리스터 코번, Agile Software Development (Addison-Wesley, 2002): 규모와 중요도에 맞는 방법론 선택과 Crystal 방법론을 설명함.
• 배리 뵘, Software Engineering Economics (Prentice Hall, 1981), Software Cost Estimation with Cocomo II (2000): 규모가 비용·생산성·품질과 개발 활동에 미치는 영향을 다룸.
• 케이퍼스 존스, Estimating Software Costs (McGraw-Hill, 1998), Programming Productivity (1986): 소프트웨어 생산성과 프로그램 규모의 영향을 자료로 분석함.
• 프레더릭 브룩스, The Mythical Man-Month, Anniversary Edition (Addison-Wesley, 1995): 대규모 팀과 프로젝트 관리 문제를 다룸.
• 피터 디그레이스·레슬리 스탈, Wicked Problems, Righteous Solutions (Yourdon Press, 1990): 규모와 형식성에 맞춰 개발 프로세스를 조정하는 방법을 다룸.
• 케이퍼스 존스, Program Quality and Programmer Productivity (IBM Technical Report, 1977): 대형 프로젝트와 소형 프로젝트의 활동·품질 차이를 분석함.

요점 정리

• 프로젝트가 커질수록 의사소통을 의식적으로 지원해야 한다. 방법론의 가치는 의사소통 문제를 얼마나 잘 줄이는지로 판단해야 한다.
• 다른 조건이 같다면 큰 프로젝트는 작은 프로젝트보다 생산성이 낮다.
• 다른 조건이 같다면 큰 프로젝트는 코드 1,000줄당 오류가 더 많다.
• 작은 프로젝트에서 당연하게 처리하던 활동도 큰 프로젝트에서는 세심하게 계획해야 하며, 규모가 커질수록 구현의 비중은 낮아진다.
• 무거운 방법론을 축소하기보다 가벼운 방법론을 확장하는 편이 낫다. 가장 효과적인 방식은 프로젝트에 맞는 적정 무게의 방법론이다.