소스 코드 QA: 더 이상 개발자만을 위한 것이 아닙니다.

게시 됨: 2022-03-11

20년 전 내가 자동차 업계에서 일할 때 한 공장의 이사는 종종 "우리는 자동차를 만드는 데 하루가 있지만 고객이 그것을 검사하는 데는 평생이 있습니다."라고 자주 말했습니다. 품질이 가장 중요했습니다. 실제로 자동차 및 건설 산업과 같은 보다 성숙한 부문에서 품질 보증은 제품 개발 프로세스에 체계적으로 통합되는 핵심 고려 사항입니다. 이것은 확실히 보험 회사의 압력에 의해 주도되지만, 그 공장 이사가 언급했듯이 결과 제품의 수명에 의해 결정되기도 합니다.

그러나 소프트웨어와 관련하여 더 짧은 수명 주기와 지속적인 업그레이드는 소스 코드 무결성이 종종 새로운 기능, 정교한 기능 및 출시 속도를 위해 간과된다는 것을 의미합니다. 제품 관리자는 소스 코드 품질 보증이 제품의 운명을 결정하는 더 중요한 요소 중 하나라는 사실에도 불구하고 종종 소스 코드 품질 보증의 우선순위를 낮추거나 개발자가 처리하도록 합니다. 제품 개발을 위한 견고한 기반을 구축하고 위험을 제거하는 데 관심이 있는 제품 관리자에게는 소스 코드 품질에 대한 체계적인 평가를 정의하고 구현하는 것이 필수적입니다.

"품질" 정의

소스 코드 QA 프로세스를 적절하게 평가하고 제정하는 방법을 탐색하기 전에 소프트웨어 개발의 맥락에서 "품질"이 의미하는 바를 결정하는 것이 중요합니다. 이것은 복잡하고 다면적인 문제이지만 단순성을 위해 품질은 소비자 만족도를 손상시키거나 개발 회사의 비즈니스 모델을 위험에 빠뜨리지 않으면서 제품의 가치 제안을 지원하는 소스 코드를 의미한다고 말할 수 있습니다.

즉, 품질 소스 코드는 제품의 기능적 사양을 정확하게 구현하고, 비기능적 요구사항을 만족시키며, 소비자의 만족을 보장하고, 보안 및 법적 위험을 최소화하고, 저렴하게 유지 및 확장할 수 있습니다.

좋은 소프트웨어 품질 관리 프로세스는 소프트웨어 오류, 레거시 시스템 문제 및 취소된 프로젝트와 관련된 비용을 줄일 수 있습니다. — 출처: CISQ

소프트웨어가 얼마나 광범위하고 빠르게 배포되는지를 고려할 때 소프트웨어 결함의 영향은 상당할 수 있습니다. 버그 및 코드 복잡성과 같은 문제는 제품 채택을 방해하고 소프트웨어 자산 관리(SAM) 비용을 증가시켜 회사의 수익을 해칠 수 있으며, 보안 위반 및 라이선스 준수 위반은 회사 평판에 영향을 미치고 법적 문제를 제기할 수 있습니다. 소프트웨어 결함이 치명적인 결과를 초래하지 않더라도 부인할 수 없는 비용이 발생합니다. 2018년 보고서에서 소프트웨어 회사인 Tricentis는 314개 회사에서 606개의 소프트웨어 오류가 발생하여 전년도에 1조 7천억 달러의 매출 손실이 발생했다고 밝혔습니다. 막 발표된 2020년 보고서에서 CISQ는 미국의 저품질 소프트웨어 비용을 2조 8000억 달러로 추산했으며 기술 부채로 인한 미래 비용은 1조 3100억 달러로 추산됩니다. 이러한 숫자는 더 이른 개입으로 완화될 수 있습니다. 제품 설계 중 문제를 해결하는 평균 비용은 테스트 중에 동일한 문제를 해결하는 것보다 훨씬 낮으며, 배포 후 문제를 해결하는 것보다 기하급수적으로 적습니다.

비용을 낮추기 위해 소프트웨어 qa 프로세스는 소스에 가까운 문제를 식별해야 합니다. — 출처: IBM 시스템 과학 연구소

뜨거운 감자 다루기

위험에도 불구하고 소프트웨어 개발의 품질 보증은 단편적으로 취급되며 다른 산업에서 취하는 사전 예방적 접근보다는 사후적 접근이 특징입니다. 소스 코드 품질의 소유권은 서로 다른 기능의 공동 책임으로 간주되어야 하는 경우 논쟁이 있습니다. 제품 관리자는 품질을 오버헤드가 아니라 영향력 있는 기능으로 보아야 하고, 경영진은 품질 상태에 주의를 기울이고 투자해야 하며, 엔지니어링 기능은 코드 정리를 "뜨거운 감자"로 취급하지 않아야 합니다.

이러한 위임 문제를 복잡하게 만드는 것은 기존 방법론과 도구가 코드 품질 문제를 전체적으로 해결하지 못한다는 사실입니다. 지속적인 통합/지속적인 전달 방법론을 사용하면 저품질 코드의 영향을 줄일 수 있지만 CI/CD가 철저하고 전체적인 품질 분석을 기반으로 하지 않는 한 대부분의 위험을 효과적으로 예측하고 해결할 수 없습니다. QA 테스트, 애플리케이션 보안 및 라이선스 규정 준수를 담당하는 팀은 문제의 한 부분만 해결하고 일부 비기능적 또는 기능적 요구사항만 평가하도록 설계된 도구를 사용하여 사일로에서 작업합니다.

제품 관리자의 역할 고려

소스 코드 품질은 제품 설계 중 및 소프트웨어 개발 수명 주기 전반에 걸쳐 제품 관리자가 직면하는 수많은 딜레마에 영향을 미칩니다. Τ기술적 부채는 무거운 간접비입니다. 저품질 코드베이스에서 기능을 추가하고 수정하는 것은 더 어렵고 비용이 많이 들며 기존 코드 복잡성을 지원하려면 신제품 개발에 사용할 수 있는 상당한 시간과 리소스 투자가 필요합니다. 제품 관리자는 시장 출시 속도와 위험 사이에서 지속적으로 균형을 유지하기 때문에 다음과 같은 질문을 고려해야 합니다.

OSS(오픈 소스 소프트웨어) 라이브러리를 사용해야 합니까 아니면 처음부터 기능을 빌드해야 합니까? 선택한 라이브러리와 관련된 라이선스 및 잠재적 책임은 무엇입니까?
어떤 기술 스택이 가장 안전한가요? 빠르고 저렴한 개발 주기를 보장하는 것은 무엇입니까?
앱 구성 가능성(높은 비용/시간 지연)을 우선시해야 하나요? 아니면 맞춤형 버전(높은 유지 관리 비용/확장성 부족)을 구현해야 하나요?
높은 코드 품질을 유지하고 위험을 최소화하며 엔지니어링 비용을 낮게 유지하면서 새로 획득한 디지털 제품을 통합하는 것이 얼마나 실현 가능합니까?

이러한 질문에 대한 답변은 비즈니스 결과와 제품 관리자 자신의 평판에 심각한 영향을 미칠 수 있지만 의사 결정은 종종 엄격한 조사와 견고한 측정 기준보다는 직관이나 과거 경험을 기반으로 내려집니다. 철저한 소프트웨어 품질 평가 프로세스는 의사 결정에 필요한 데이터를 제공할 뿐만 아니라 이해 관계자를 정렬하고 신뢰를 구축하며 우선 순위가 명확하고 합의된 투명성 문화에 기여합니다.

7단계 프로세스 구현

완전한 소스 코드 품질 평가 프로세스는 더 큰 문제의 몇 가지 고립된 증상보다는 전체 품질 결정 세트를 고려하는 진단을 초래합니다. 아래에 제시된 7단계 방법은 프로세스 개선을 위한 CISQ의 권장 사항과 일치하며 다음 목표를 촉진하기 위한 것입니다.

근본 원인에 가까운 문제를 찾고, 측정하고, 수정합니다.
전반적인 품질 측정을 기반으로 소프트웨어 품질 개선에 현명하게 투자하십시오.
전체 측정 세트를 분석하고 가장 비용 효율적인 최상의 개선 사항을 식별하여 문제를 공격합니다.
소유 비용, 유지 관리 비용, 라이선스/보안 규정 조정을 포함하여 소프트웨어 제품의 전체 비용을 고려하십시오.
불쾌한 놀라움을 방지하기 위해 SDLC 전체에서 코드 품질을 모니터링합니다.

전체 소프트웨어 품질 관리 프로세스에 필요한 7단계. — 코드 품질 평가를 위한 포괄적인 7단계 프로세스

1. 제품-코드 매핑: 제품 기능을 코드베이스로 다시 추적하는 것은 명백한 첫 번째 단계처럼 보일 수 있지만 개발 복잡성이 증가하는 속도를 고려할 때 반드시 간단한 것은 아닙니다. 어떤 상황에서는 제품의 코드가 여러 리포지토리에 나누어져 있는 반면, 다른 상황에서는 여러 제품이 동일한 리포지토리를 공유합니다. 추가 평가를 수행하기 전에 제품 코드의 특정 부분이 있는 다양한 위치를 식별해야 합니다.

2. 기술 스택 분석: 이 단계에서는 사용된 다양한 프로그래밍 언어 및 개발 도구, 파일당 주석 비율, 자동 생성 코드 비율, 평균 개발 비용 등을 고려합니다.

올바른 도구 선택

소프트웨어 품질이 제품과 비즈니스 결과에 영향을 미치지만 도구 선택은 일반적으로 개발 부서에 위임되며 비개발자가 결과를 해석하기 어려울 수 있습니다. 제품 관리자는 투명하고 접근 가능한 QA 프로세스를 보장하는 도구를 선택하는 데 적극적으로 참여해야 합니다. 평가의 다양한 단계에 대한 특정 도구가 위에 제안되어 있지만 도구 선택 프로세스에 고려해야 하는 여러 가지 일반적인 고려 사항이 있습니다.

지원되는 기술 스택: 사용 가능한 대부분의 제품은 소수의 개발 도구만 지원하므로 부분적으로 또는 오해의 소지가 있는 보고가 발생할 수 있습니다.
설치 단순성: 설치 프로세스가 복잡한 스크립팅을 기반으로 하는 도구에는 상당한 엔지니어링 투자가 필요할 수 있습니다.
보고: 주요 문제를 식별하고 수정 권장 사항을 제공하는 상세하고 구조화된 보고서를 내보내는 도구를 선호해야 합니다.
통합: 사용 중인 다른 개발 및 관리 도구와 쉽게 통합할 수 있도록 도구를 선별해야 합니다.
가격 책정: 도구에는 포괄적인 가격 목록이 거의 제공되지 않으므로 관련된 투자를 신중하게 고려하는 것이 중요합니다. 다양한 가격 책정 모델은 일반적으로 팀 인원수, 코드 크기, 관련된 개발 도구 등을 고려합니다.
배포: 온프레미스와 클라우드 배포를 비교할 때 보안과 같은 요소를 고려하십시오. 예를 들어, 평가 중인 제품이 기밀 또는 민감한 데이터를 처리하는 경우 온프레미스 도구 및 블라인드 감사 접근 방식(FOSSID)을 사용하는 도구가 선호될 수 있습니다.

계속하기

위험이 식별되고 체계적으로 분석되면 제품 관리자는 우선 순위 지정과 관련하여 신중한 결정을 내리고 결함을 보다 정확하게 분류할 수 있습니다. 가장 시급하거나 널리 퍼진 문제를 해결하기 위해 팀을 재구성하고 리소스를 할당할 수 있습니다. 고위험 라이선스 위반과 같은 "쇼스토퍼"는 심각도가 낮은 결함보다 우선하며 코드베이스 크기 및 복잡성 감소에 기여하는 활동에 더 중점을 둡니다.

그러나 이것은 일회성 프로세스가 아닙니다. 소프트웨어 품질 측정 및 모니터링은 SDLC 전체에서 지속적으로 이루어져야 합니다. 전체 7단계 평가는 각 분석 직후에 시작되는 품질 개선 노력과 함께 주기적으로 수행되어야 합니다. 새로운 위험 지점이 더 빨리 식별될수록 구제책은 더 저렴해지고 낙진은 더 제한됩니다. 소스 코드 품질 평가를 제품 개발 프로세스의 중심으로 만드는 것은 팀에 집중하고, 이해 관계자를 조정하고, 위험을 완화하고, 제품이 성공할 수 있는 최고의 기회를 제공하는 것입니다. 이것이 모든 제품 관리자의 업무입니다.