기술 부채 소개
기술 부채란 더 나은 방법이 있더라도 완료하는 데 시간이 더 오래 걸린다는 이유로 더 쉬운 솔루션을 선택하여 발생하게 될 향후 비용을 설명하는 용어입니다.
기술 부채라는 용어는 금융 부채와 비교하기 위해 선택되었습니다. 금융 부채가 있는 사람은 당시에 적절하거나 유일한 옵션으로 보이는 결정을 내리는 것이 일반적이지만 그렇게 하면 이자가 증가합니다.
이자가 누적될수록 미래에 더 어려워지고 나중에는 부차적인 옵션을 더 많이 사용하게 됩니다. 금융 부채가 있으면 곧 이자에 대한 이자가 증가하여 눈덩이 효과가 발생합니다. 마찬가지로 기술 부채가 쌓이면 개발자가 가치를 더하기 보다는 (계획된 것이든 계획되지 않은 것이든) 문제를 분류하고 재작업하는 데 거의 모든 시간을 사용해야 하는 상황까지 됩니다.
그렇다면 이런 상황이 어떻게 발생할까요?
가장 흔한 변명은 촉박한 마감일입니다. 개발자는 코드를 신속하게 만들어야 하는 경우 바로 가기를 사용하는 경우가 많습니다. 예를 들어 새로운 기능을 포함하는 메서드를 리팩터링하는 대신 메서드를 복사하여 새 버전을 만듭니다. 그런 다음, 새 코드만 테스트하고 원래 메서드를 변경하는 경우 코드의 다른 부분에서 사용하기 때문에 필요한 테스트 수준을 피할 수 있습니다.
이제 나중에 수정해야 하는 동일한 코드의 복사본이 하나가 아닌 두 개가 있기 때문에 논리가 벗어날 위험이 있습니다. 원인은 여러 가지입니다. 예를 들어, 개발자들 간에 기술적 수완이나 숙련도가 부족하거나 제품의 소유권이나 방향이 명확하지 않을 수 있습니다.
조직에 코딩 표준이 전혀 없을 수도 있습니다. 그러면 개발자들은 무엇을 제작해야 하는지조차 모릅니다. 개발자가 목표로 하는 정확한 요구 사항이 없을 수도 있습니다. 게다가 막바지 요구 사항이 변경될 수도 있습니다.
필요한 리팩터링 작업이 지연될 수 있습니다. 코드 품질 테스트(수동 또는 자동)가 없을 수도 있습니다. 결국 합리적인 시간 내에 합리적인 비용으로 고객에게 가치를 제공하기가 점점 더 어려워질 뿐입니다.
기술 부채는 프로젝트가 마감일을 지키지 못하는 주된 이유 중 하나입니다.
시간이 지날수록 따라 금융 부채와 거의 동일한 방식으로 증가합니다. 기술 부채의 일반적인 원인은 다음과 같습니다.
- 코딩 스타일과 표준이 부족합니다.
- 단위 테스트 사례에 대한 디자인이 부족하거나 부실합니다.
- 개체 지향 디자인 원칙을 무시하거나 이해하지 못합니다.
- 클래스 및 코드 라이브러리가 모놀리식입니다.
- 아키텍처, 접근 방식, 기술 사용에 대해 제대로 구상하지 못했습니다. (유지 관리, 사용자 환경, 확장성 등에 영향을 주는 모든 시스템 특성을 고려해야 한다는 사실을 잊어버렸습니다).
- 오버엔지니어링 코드(필요하지 않은 코드를 추가 또는 생성, 기존 라이브러리가 충분한데 사용자 지정 코드를 추가, 필요하지 않은 레이어 또는 구성 요소를 생성)
- 불충분한 의견 및 설명서
- 설명을 제공하거나 의도를 나타내는 클래스, 메서드 및 변수 이름이 포함된 자체 문서화 코드를 작성하지 않습니다.
- 마감일을 맞추기 위해 쉬운 방법을 선택합니다.
- 데드 코드를 그대로 둡니다.
참고
시간이 지날수록 기술 부채를 상환해야 합니다. 그렇게 하지 않으면 팀에서 문제를 해결하고 새로운 기능과 개선 사항을 구현하는 데 시간이 더 오래 걸리고 결국 엄청난 비용이 소요됩니다.
기술 부채가 있으면 개발 중에 일련의 문제가 추가되며 고객 가치를 더하기가 훨씬 더 어려워집니다.
프로젝트에 기술 부채가 있으면 생산성이 떨어지고 개발 팀에 방해가 되며 코드를 이해하기 어렵고 취약하게 만들며 코드를 변경하고 변경한 사항을 확인하는 데 걸리는 시간이 늘어납니다. 계획에 없던 작업이 계획했던 작업을 방해하는 경우가 빈번합니다.
장기적으로는 조직의 힘을 약화시키기도 합니다. 기술 부채는 조직에 서서히 영향을 미치는 경향이 있습니다. 작게 시작하지만 시간이 지날수록 커집니다. 급하게 변경해야 한다는 이유로 급하게 과정을 축소하거나 테스트를 우회할 때마다 문제는 점점 더 악화됩니다. 지원 비용은 점점 높아지고, 예외 없이 심각한 문제가 발생합니다.
결국 조직은 고객의 요구에 대해 적시에 비용 효율적인 방식으로 대응할 수 없게 됩니다.
모니터링을 위한 자동 측정
기술 부채가 지속적으로 늘어나는 것을 최소화하는 한 가지 주요 방법은 자동화된 테스트 및 평가를 사용하는 것입니다.
다음 데모에서는 부채를 평가하는 데 사용되는 일반적인 도구 중 하나인 SonarCloud를 살펴보겠습니다. (원래 온-프레미스 버전은 SonarQube입니다.)
사용할 수 있는 다른 도구도 있으며, 그 중 몇 가지를 살펴보겠습니다.
다음 실습 랩에서는 SonarCloud를 사용하도록 Azure Pipelines를 구성하고, 분석 결과를 이해하고, 프로젝트를 분석할 때 SonarCloud에서 사용하는 규칙 집합을 제어하도록 품질 프로필을 구성하는 방법에 대해 알아봅니다.
자세한 내용은 SonarCloud를 참조하세요.
검토할 사항:
Azure DevOps는 빌드 중에 코드 품질을 확인하는 데 사용되는 다양한 기존 도구와 통합할 수 있습니다.
현재 어떤 코드 품질 도구를 사용하고 있나요(있는 경우)?
그 도구에 대해 좋아하거나 좋아하지 점은 무엇인가요?