소프트웨어 품질통제(QC)를 개발 수명주기에 정착시키는 방법
소프트웨어 품질통제(QC)의 제품 중심 역할과 품질 모니터링, 편차 분석, 시정·예방조치, 개발 단계별 운영 방법을 정리한다.
2026-08-14 · 최초 발행 2025-05-23
품질 결과를 제품 기준으로 되돌리는 QC
소프트웨어 품질통제(Quality Control, QC)는 개발된 결과물이 미리 정한 품질 요구사항을 만족하는지 확인하고 추적하는 활동이다. 품질 계획과 실제 결과의 차이를 확인한 뒤 필요한 조치를 취해 최종 제품의 품질을 관리한다.
QA가 프로세스 관점에서 ‘올바른 일을 하고 있는가’를 다룬다면, QC는 제품 관점에서 ‘일을 올바르게 하고 있는가’를 확인한다. 결함을 식별하고 제거해 품질 기준 충족 여부를 검증하며, 프로젝트 위험과 고객 만족도에도 직접 영향을 준다.
초기에 드러난 결함이 비용을 바꾸는 이유
품질 결과를 개발 내내 관찰해야 하는 가장 직접적인 이유는 결함 발견 시점에 따라 수정 비용이 달라지기 때문이다. 요구분석 단계의 결함 수정 비용을 1로 보면, 설계 단계는 36배, 구현 단계는 10배, 테스트 단계는 1540배, 운영 단계는 40~1000배가 될 수 있다.
모니터링은 비용만의 문제가 아니다. 품질 결과를 쌓아 보면 개발 프로세스를 개선할 근거가 생기고, 일정과 비용에 영향을 줄 품질 이슈를 조기에 관리할 수 있다. 객관적인 품질 데이터는 우선순위와 투자 판단에도 쓰인다.
측정에서 계획 갱신까지 이어지는 통제 루프
품질통제는 측정만으로 끝나지 않는다. 코드 복잡도, 테스트 커버리지, 결함 밀도 같은 정량 지표와 사용자 피드백, 전문가 검토, 팀 회고 같은 정성 평가를 함께 본다. 정적 분석 도구인 SonarQube와 PMD, 동적 분석 도구인 JUnit과 Selenium도 이 과정에 활용할 수 있다. 일일, 주간, 스프린트 단위 가운데 프로젝트 특성에 맞는 주기를 정한다.
A금융사 핀테크 프로젝트는 Jenkins 기반 CI/CD 파이프라인에 SonarQube를 통합해 코드 품질 지표를 일일 단위로 모니터링하고, 주간 품질 회의에서 결과를 검토했다. 그 결과 코드 중복률을 28%에서 8%로 낮췄다.
측정값이 계획과 다르면 편차를 식별하고 원인을 확인해야 한다. 5 Why 분석, 특성요인도(Fishbone Diagram), 파레토 분석(80:20 법칙)은 근본 원인을 파악하는 데 쓸 수 있다. 이후 영향도와 시급성을 기준으로 해결할 이슈의 순서를 정한다.
B제조업체의 MES 시스템 개발에서는 성능 테스트 결과 데이터 조회 응답시간이 목표인 1초 이내보다 3배 느렸다. 불필요한 JOIN 쿼리와 인덱스 최적화 문제가 원인으로 확인됐고, 쿼리를 재구성해 응답시간을 0.8초로 개선했다.
원인이 확인되면 발견된 결함을 해결하는 시정조치(Corrective Action)와 유사 결함의 재발을 막는 예방조치(Preventive Action)를 함께 계획한다. 조치마다 담당자와 책임을 정하고, 수정에 필요한 시간·인력·비용을 배정한다. C통신사 웹서비스 개발 프로젝트에서는 다수의 보안 취약점이 발견된 뒤 XSS 및 SQL 인젝션 취약점을 즉시 수정하고, 개발자 보안 교육 강화와 코드 리뷰 프로세스의 보안 체크리스트 추가를 실행했다.
측정 결과, 분석 내용, 조치 사항은 품질 기록으로 남긴다. 주기적인 품질 보고서로 이해관계자와 현황을 공유하고, 분석 결과에 따라 품질 목표와 측정 지표, 기준을 갱신한다. D공공기관 시스템 구축 사업은 매월 품질보고서를 PMO와 발주처에 공유하고 분기별로 품질 계획을 검토했다. 초기 테스트 커버리지 목표 70%가 현실적이지 않다고 판단한 뒤 핵심 모듈 85%, 일반 모듈 60%로 조정하고 테스트 계획도 수정했다.
개발 단계마다 다른 품질 신호를 확인한다
요구사항 단계에서는 요구사항 검토, 명확성 검증, 일관성 검사가 중심이다. 인스펙션, 워크스루, 동료검토로 요구사항 변경률과 명확하지 않은 요구사항 비율을 확인한다.
설계 단계에서는 설계 검토, 표준 준수 확인, 아키텍처 평가를 수행한다. ATAM(Architecture Tradeoff Analysis Method)과 설계 인스펙션을 적용할 수 있으며, 설계 복잡도, 모듈 간 결합도, 내부 응집도가 주요 지표가 된다.
구현 단계에서는 코드 리뷰, 정적 분석, 단위 테스트가 품질통제의 기반이다. 자동화된 코드 분석과 표준 준수 검사, 피어 리뷰를 통해 코드 복잡도, 중복 코드 비율, 테스트 커버리지, 결함 밀도를 관리한다.
테스트 단계는 기능·성능·보안·사용성 테스트를 수행하는 구간이다. 블랙박스/화이트박스 테스트, 회귀 테스트, 스트레스 테스트 결과에서 결함 발견률, 결함 수정률, 테스트 실행률, 성능 지표를 확인한다.
운영 및 유지보수 단계에서는 성능 모니터링, 장애 관리, 사용자 피드백 수집이 이어진다. 로그 분석, 사용자 만족도 조사, 가용성 측정을 통해 MTBF(평균 고장 간격), MTTR(평균 복구 시간), 사용자 만족도를 살핀다.
품질통제가 지속되는 운영 조건
지속적 통합(CI) 환경에서는 Jenkins, GitLab CI, GitHub Actions를 활용해 빌드와 테스트를 자동화할 수 있다. SonarQube, PMD, ESLint는 코드 품질 측정에, Selenium, JUnit, TestNG는 테스트 자동화에 활용된다. 성능 모니터링에는 APM(Application Performance Monitoring) 도구를 적용할 수 있다.
도구만으로 품질통제가 자리 잡지는 않는다. 개발자가 품질의 중요성을 이해하도록 교육하고, 단순 기능 구현이 아니라 품질 기여도를 반영하는 평가 체계를 고려해야 한다. 개발과 운영이 품질 책임을 함께 지는 DevOps 문화, 품질 지식을 공유하고 학습할 기회도 필요하다.
프로젝트 특성에 맞는 핵심 품질 메트릭을 정하고, 실시간 품질 현황을 대시보드로 공유하면 관리의 기준이 선명해진다. 시간에 따른 품질 변화 추세를 분석하고 과거 데이터를 바탕으로 품질 위험을 예측하는 방식도 품질통제의 범위를 넓힌다.
품질통제는 결함을 찾는 단발성 검사가 아니라, 품질 결과를 관찰하고 계획과 비교한 뒤 조치와 기록을 통해 다음 개발 활동에 반영하는 과정이다. 이 순환이 유지될 때 결함 수정 비용 감소, 사용자 만족도 향상, 브랜드 가치 제고를 위한 기반이 만들어진다.