소프트웨어 개발에 있어 개발자들을 대상으로 한 생산성을 측정하고 관리하는 것은
매우 어려운 주제 중 하나입니다. 생산성 측정에는 마법같은 해결책이 있는 것도 아니고요.
이번 포스팅에서는 소프트웨어 생산성을 측정하고 개선하기 위한 실무적 접근법에 대해 살펴 보겠습니다.
이 포스팅은 Cristof Ebert "Measure and Improve Software Productivity" (IEEE Software, DOI Bookmark: 10.1109/MS.2023.3324466)의 내용을 기반으로 작성되었습니다.
이번 포스팅에서는 소프트웨어 생산성을 효과적으로 측정함에 있어 모호한 선언 대신 실질적인 방법론에 대해 설명하고자 합니다. 조사 결과에 따르면 팀 협업, 도구의 효율성, 프로세스 개선, 관리 관행 등이 생산성에 큰 영향을 미치는 주요 요인으로 나타났습니다. 이러한 요인들은 측정 가능할 뿐만 아니라 관리 가능하다는 점에서 소프트웨어 생산성 향상을 위한 필수적인 요소로 자리 잡고 있습니다.
소프트웨어 생산성 측정과 개선
- 소프트웨어공학: 소프트웨어 생산성 측정과 개선 - 생산성 측정 프로세스
- 소프트웨어공학: 소프트웨어 생산성 측정과 개선 - 생산성 개선 절차
소프트웨어 생산성 개선 절차
Step 1: Identify Improvement Needs
개선의 시작: 목표 설정
개선은 스포츠에서와 마찬가지로, 적절한 목표 설정에서 시작됩니다. 오늘날 대부분의 기업은 소프트웨어 중심으로 운영되거나, 최소한 소프트웨어에 의해 그 성과가 좌우됩니다. 이러한 변화는 기업이 소프트웨어 생산성이 무엇을 의미하는지, 그리고 이를 개선하는 데 필요한 비용을 알아야 함을 요구합니다. 그러나 현실적으로 소프트웨어 생산성은 측정하기 어려운 영역 중 하나로 간주됩니다.
측정하지 않으면 개선되지 않는다
많은 기업은 소프트웨어 생산성을 측정하지 않거나, 측정 방법조차 제대로 정의하지 않습니다. 생산성을 측정하지 않으면, 이를 효과적으로 개선할 방법도 없게 됩니다. 이로 인해 기업은 소프트웨어 비용을 아웃소싱하거나, 경영진의 결정에 따라 무작위로 예산을 삭감할 수밖에 없는 상황에 놓입니다. 이런 접근은 비용 절감이라는 단기 목표를 달성할 수는 있지만, 장기적으로는 효율성과 효과성 모두를 저해할 가능성이 큽니다.
생산성 개선에 대한 오해
일부 사람들은 소프트웨어 생산성 개선이 불가능하다고 주장하기도 합니다. 그 이유로 다음과 같은 점들을 들 수 있습니다:
- 비가시성: 생산성은 구체적으로 눈에 보이지 않음.
- 다양성: 프로젝트 간의 특성이 서로 다름.
- 복잡성: 대규모 상태와 상호작용, 비선형성, 지속적인 업데이트 등이 포함됨.
이러한 복잡성에도 불구하고, 측정하지 않으면 관리할 수 없다는 Peter Drucker의 말처럼, 생산성 개선은 여전히 가능하며 필요합니다.
효율성과 효과성의 차이
많은 IT 및 소프트웨어 회사는 소프트웨어 개발에 자원을 투자하지만, 그 노력이 올바른 일을 하고 있는지(효과성, effectiveness) 또는 일을 제대로 하고 있는지(효율성, efficiency)에 대한 판단 없이 진행되는 경우가 많습니다.
- 효과성(Effectiveness): 개발된 소프트웨어가 실제 비즈니스 가치를 창출하는가?
- 효율성(Efficiency): 최소한의 자원으로 최대한의 성과를 달성하고 있는가?
많은 조직이 다양한 도구에서 데이터를 수집하고 있지만, 측정 데이터를 활용하고 학습하는 문화가 부족한 경우가 대부분입니다.
경쟁 환경에서의 생존
경쟁사가 동일한 가치를 더 낮은 비용으로 제공할 수 있다면, 기업은 반드시 움직여야 합니다.
- 더 많은 가치를 제공하거나,
- 동일한 가치를 더 적은 비용으로 제공해야 합니다.
그러나 비용 절감에만 초점을 맞추는 것은 레드 오션 전략으로, 치열한 경쟁과 점유율 축소로 이어질 가능성이 높습니다. 대신 산출물(output)을 개선하는 데 초점을 맞춰야 합니다.
다른 방식으로 생각하라
소프트웨어 생산성 개선은 단순히 비용 절감이나 도구 추가로 해결되지 않습니다. 보다 깊이 있는 분석과 창의적인 접근을 통해, 조직의 목표에 부합하는 생산성 개선 전략을 세우는 것이 중요합니다. 이제 본격적으로 측정을 시작하고, 데이터를 기반으로 개선의 방향성을 설정할 때입니다. 생산성을 정의하고, 목표를 설정하며, 이를 중심으로 조직의 노력을 효과적으로 배분하는 것이 첫걸음입니다.
Step 2: Determine Where You Are
소프트웨어 생산성을 개선하려면 먼저 현재 상태를 파악해야 합니다. 생산성은 기본적으로 산출물(Output) 대비 투입물(Input)로 정의됩니다. 이를 통해 기업은 어떤 산출물을 제공하는지(효과성)와 이를 얼마나 효율적으로 제공하는지(효율성)를 평가할 수 있습니다.
생산성의 두 축: Output과 Input
1. Output: 효과성 (Effectiveness)
- Output은 비즈니스 용어로 가치를 전달하는 것, 즉 “올바른 일을 하는지”를 의미합니다. 고객이나 이해관계자가 가치를 인식하는 것이 핵심입니다.
- Output은 고객과 시장의 인식에 따라 결정됩니다.
- 산출물은 단순히 소스 코드나 테스트 케이스 같은 물리적 결과물이 아닌, 고객이 느끼는 가치입니다.
- 측정 방법: 기능점수(Function Points, FPs) 사용.
FPs는 코드 양이 아닌 소프트웨어의 기능적 가치를 측정하는 데 유용하며, 초기 요구사항 분석 단계에서도 사용할 수 있습니다.
2. Input: 효율성 (Efficiency)
- Input은 Output을 창출하기 위해 투입된 리소스, 즉 “일을 제대로 하고 있는지”를 나타냅니다.
- 측정 요소:
• 시간: 프로젝트에 투입된 인력 시간(정규 근무시간 + 초과 근무시간 포함).
• 비용: 설계, 품질, 반복 작업, 결함 수정 등의 비용.
• 정확한 데이터 수집: 정확한 노력과 비용 데이터를 수집하고 분석하는 것이 중요합니다.
현재 상태 분석의 주요 과제
1. Input 관련 도전과제
- 노력의 정확한 측정 문제: 소프트웨어 개발에서는 투입된 시간(인력 시간)이 주요 비용 요소이지만, 종종 명확하게 보고되지 않습니다. 또한 초과 근무나 원격 근무 시 보고 누락이 발생할 수 있습니다.
- 비용 항목 분석 필요성: 비용은 설계, 품질, 비품질(Non-Quality), 반복 작업, 기술 부채, 결함 수정 등으로 세분화해야 합니다.
예: 프로젝트 비용의 40%가 결함 수정에 소요되는 경우도 흔합니다. - 기능 과잉(Gold Plating): 고객이 요구하지 않은 기능을 추가하면서 가치를 저해하고 복잡성을 증가시키는 경우.
2. Output 관련 도전과제
- 출력의 비가시성: 단순히 소스 코드나 테스트 케이스를 제공하는 것이 아닌, 고객이 인식하는 가치를 측정해야 합니다. 과거에는 코드 라인(Line of Code, LOC)이 생산성 측정 지표로 사용되었으나, 코드 양의 증가는 가치와 반드시 비례하지 않음을 확인했습니다.
- 코드 품질의 중요성: 동일한 기능을 수행하는 코드라도 코드의 크기와 품질이 다를 수 있습니다. 또한 코드 복제(clone)와 같은 문제는 유지보수를 어렵게 하고 생산성을 저해합니다.
- 기능점수(Function Points, FPs): FPs는 기능적 가치 측정을 위한 좋은 도구입니다. 요구사항 분석 단계에서 조기에 측정 가능하며, 소프트웨어의 기능성과 관련된 산출물을 보다 명확하게 정의할 수 있습니다.
생산성 분석의 핵심 전략
1. 비용 분석
- 비용 분해(Breakdown): 설계 비용, 품질 비용, 결함 수정 비용 등으로 세분화하여 비용의 흐름을 명확히 파악합니다.
- 데이터 수집의 중요성: 기술 부채, 반복 작업, 복잡성 등 프로젝트의 전 과정에서 데이터를 철저히 수집해야 합니다.
예: 기술 부채가 증가하면 반복 작업과 유지보수 비용이 증가하게 됩니다.
2. 기능점수를 활용한 Output 측정
- 기능점수(Function Points, FPs): 소프트웨어의 기능적 요소를 측정하여 Output을 평가할 수 있습니다. 또한 초기 요구사항 분석 단계에서 기능점을 측정함으로써 프로젝트의 가치를 조기에 파악 가능합니다.
- FPs의 장점: 코드 라인 수 대신 기능적 가치를 강조.
예) T 시스템, 애플리케이션 소프트웨어, 실시간 임베디드 소프트웨어 등 다양한 도메인에 적용 가능. - FPs의 한계: 요구사항 분석이 선행되어야 기능점수를 정확히 측정할 수 있음.
Step 3: Determine How to Improve
소프트웨어 엔지니어링 생산성을 효과적으로 개선하려면 생산성의 정의(Step 1)와 현재 상태(Step 2)를 이해한 상태에서 어떤 변경이 필요한지 결정해야 합니다. 생산성은 산출물(Output)과 투입물(Input)을 중심으로 다양한 개선 레버를 활용하여 관리됩니다. 하지만 모든 레버가 동일하게 중요한 것은 아니며, 상황에 따라 중요한 요소가 달라집니다.
생산성 개선의 핵심 원칙
1. Output 중심으로 시작하라
- 생산성 개선은 산출물이 고객에게 진정한 가치를 전달하고 있는지를 중심으로 시작해야 합니다.
• 제품의 콘텐츠와 로드맵을 충분히 관리하고 있습니까?
• 고객의 비즈니스 요구사항과 시장에서의 제품 포지셔닝이 명확합니까?
• 불필요한 변형 관리(Customization)로 자원을 낭비하고 있습니까? - 핵심 질문: “우리가 올바른 일을 하고 있는가?”
2. 효율적인 자원 배분
자원이 제한적이므로, 오늘의 현금 흐름을 책임지는 제품(Cash Cow)과 미래 기술로 성장할 제품(Stars)에 자원을 집중해야 합니다. 비용 절감은 불필요한 활동을 제거하는 데 유용하지만, 잘못된 활동을 효율적으로 수행하는 것은 문제를 해결하지 못합니다.
생산성을 개선하는 방법
1. RACE 원칙
- 생산성을 개선하는 핵심은 RACE (Reduce Accidents and Control Essence)입니다.
- Accidents(불필요한 사고): 불필요한 작업, 비효율적인 프로세스, 복잡성, 반복 작업 등에서 발생하는 낭비를 줄입니다.
- Essence(핵심 가치를 통제): 고객에게 가치를 전달하는 본질적인 활동, 즉 기능성, 서비스, 소프트웨어 업데이트, 사용성, 신뢰할 수 있는 사이버 보안을 중심으로 개선합니다.
2. 프로세스 최적화
(1) 활동 기반 회계(Activity-Based Accounting)
- 프로세스별로 투입되는 리소스와 이들이 가치 창출에 기여하는 정도를 측정합니다.
- 예: 결함 수정 비용이 전체 비용의 40%를 차지한다면, 결함 예방에 집중해야 합니다.
(2) 재작업 감소(Rework Reduction)
- 재작업의 원인은 요구사항 변경, 결함 수정, 프로세스 부족, 자동화 미비 등에서 발생합니다.
- 해결 방법:
• 요구사항 분석 단계에서 명확한 정의와 합의.
• 도구와 자동화를 통해 프로세스 효율성 향상.
(3) 테스트 최적화
- 테스트는 자원 소모가 많지만, 직접적인 가치 창출 활동이 아닙니다.
- 질문:
• 테스트의 몇 %가 중복되었습니까?
• 얼마나 테스트해야 충분합니까?
• 테스트 전략은 비즈니스 사례를 기반으로 수립되었습니까?
3. 요구사항 안정화
요구사항 변경의 영향
- 프로젝트 시작 후 요구사항 변경은 생산성을 저하시키는 주요 원인입니다.
- 요구사항 변경률이 20% 이하에서는 안정적인 생산성을 유지할 수 있지만, 그 이상일 경우 생산성이 급격히 감소합니다.
문제 원인
- 본질적 이유(Essence): 고객의 새로운 요구.
- 사고적 이유(Accidents): 초기 분석 부족, 명확하지 않은 요구사항 정의, 로드맵 부재.
개선 방법
- 프로젝트 시작 전 요구사항을 철저히 분석하고, 명확한 사양을 정의합니다.
- 요구사항 변경의 원인을 파악하고, 고객과의 정기적인 합의를 통해 변경을 최소화합니다.
Step 4: Implement Improvements
생산성 개선을 실현하는 것은 단순히 계획을 세우는 것보다 훨씬 어렵습니다. 이는 예산, 커뮤니케이션, 경영진의 강력한 의지를 필요로 하는 변화 관리 과정이기 때문입니다. 생산성 개선의 다양한 레버는 결과를 얻는 데 걸리는 리드 타임이 다르기 때문에, 단기, 중기, 장기적 개선 활동을 조화롭게 병행하여 실행하는 것이 중요합니다.
단계별 개선 활동
1. 단기적 영향 (1~2개월)
단기적 개선은 즉각적인 성과를 목표로 합니다.
- Scrum 도입: 매일, 매주 커밋을 관리하여 효율성을 높이고 불필요한 이메일 교환을 방지합니다.
- 시간 관리 교육: 엔지니어들에게 기본적인 시간 관리 및 우선순위 설정 기술을 교육합니다.
- 집중 시간 확보: 중단 없는 “조용한 시간”을 설정하여 생산성을 높입니다.
- 요구사항 검토: 커밋 전에 요구사항을 철저히 검토하고, 각 요구사항에 대해 하나의 테스트 케이스를 작성합니다.
- 낮은 기여도의 제품 종료: 기여도가 낮은 제품을 정리하여 자원을 재배분합니다.
- 기본 프로젝트 관리: 프로젝트 관리를 체계화하고, 구성 관리(Configuration Control)를 강화합니다.
2. 중기적 영향 (수개월)
중기적 개선은 프로세스의 품질을 높이고 재작업을 줄이는 데 중점을 둡니다.
- 초기 결함 제거 강화:
- 자동화된 단위 테스트와 정적 분석 도구를 활용하여 초기 결함을 발견합니다.
- 테스트 주도 개발(TDD) 도입: 민첩한 테스트 주도 개발을 통해 품질을 보장합니다.
- ‘처음부터 제대로’ 문화 정착: 정확성과 품질을 최우선으로 하는 문화를 만듭니다.
- 적절한 도구 도입: 엔지니어링 및 관리 도구를 개선하여 작업 효율성을 증대합니다.
- 소싱 전략 재검토: 자체 개발, 재사용, 구매의 균형을 맞춰 소싱 전략을 최적화합니다.
3. 장기적 영향 (1~2년)
장기적 개선은 조직의 성숙도와 기술 부채를 줄이는 데 초점을 맞춥니다.
- 프로세스 성숙도 개선:
- 모든 엔지니어링 팀의 프로세스 성숙도를 높입니다.
- 기술 부채 감소: 설계 리팩토링 및 코드를 최적화하여 장기적인 품질을 유지합니다.
- 모델링 및 코드 생성 도입: 생산성을 높이기 위해 자동화된 코드 생성 도구를 사용합니다.
- 아키텍처 교육 및 리뷰:
• 팀에게 아키텍처 설계를 교육하고, 정기적인 리뷰를 통해 품질을 보장합니다.
• 디자인 리팩토링 예산 확보: 설계 개선을 위한 지속적인 투자를 진행합니다.
변화 관리와 조율의 중요성
1. 병행 실행의 필요성
단기, 중기, 장기 활동은 서로 다른 리드 타임을 가지므로 병렬적으로 실행해야 합니다.
예를 들어, 초기 비용 절감 활동과 프로세스 개선은 함께 실행될 수 있지만, 효과적으로 조율되지 않으면 상호 경쟁하며 결과를 약화시킬 수 있습니다.
2. 사례: 개선 프로그램 간 상호작용
- 문제: 어떤 회사가 비용 절감을 위해 프로세스 개선과 엔지니어링 비용 절감을 독립적으로 실행한다고 가정합니다.
- 프로세스 개선 팀은 품질을 개선하려고 하지만, 비용 절감 팀은 프로세스 개선을 불필요한 형식주의로 간주하여 상호 갈등이 발생할 수 있습니다.
- 해결책: 모든 개선 활동을 조화롭게 통합하여, 서로 간의 목표가 충돌하지 않도록 설계해야 합니다.
소프트웨어 생산성 관련글
'Software Engineering' 카테고리의 다른 글
| 소프트웨어공학: 소프트웨어 생산성 측정과 개선 - 생산성 측정 프로세스 (0) | 2024.12.20 |
|---|---|
| 자동차 제어 소프트웨어 개발에서의 나쁜 소프트웨어 엔지니어 특징과 교훈 (2) | 2024.12.18 |
| FMECA를 활용한 신뢰성 및 위험 분석: 시스템 고장 예측과 개선 전략 (Failure Modes, Effects and Criticality Analysis) (0) | 2024.12.18 |
| 끊임없이 진화하는 소프트웨어: Lehman의 8대 법칙 (리먼 법칙) (2) | 2024.12.15 |
| 객체지향 프로그래밍의 핵심: 추상화란 무엇인가? (0) | 2024.12.15 |