품질은 누구의 눈으로 정의하는가
4장에서 프로젝트 관리의 10개 지식 영역을 훑으며 "품질 관리는 19장에서 따로 깊이 다룬다"고 예고했다. 이제 그 약속을 지킬 차례다.
책마루 사장님에게 "이번에 만든 시스템, 품질이 어떤가요?"라고 물으면 무슨 대답이 돌아올까. 아마 "주문이 잘 들어오고, 재고가 안 꼬이고, 손님들이 불편함 없이 쓰면 좋은 거죠"일 것이다. 반면 개발자에게 같은 질문을 하면 "코드가 깔끔하고, 버그가 적고, 나중에 기능을 추가하기 쉬운 구조면 좋은 거죠"라는 답이 나올 법하다. 둘 다 틀린 말은 아니지만, 가리키는 대상이 다르다.
**품질(quality)**을 소프트웨어 공학에서 정의할 때도 이 두 관점이 함께 등장한다. 품질이란 소프트웨어가 사용자의 요구사항을 충족시키기 위해 갖추어야 할 제반 특성의 집합이며, 궁극적으로는 사용자 입장에서 평가되어야 한다. 그런데 이 "사용자가 만족하는 정도"라는 게 눈에 보이지 않으니, 그것을 판정할 기준이 필요하다. 그 기준이 바로 요구사항 명세서다. 1장에서 요구사항 명세서를 "개발사와 고객 사이의 약속 문서"라고 불렀는데, 품질 관리 관점에서 보면 이 문서는 한 가지 역할을 더 한다 — 품질을 측정하는 잣대가 되는 것이다. 요구사항이 모호하면 애초에 품질을 판정할 기준 자체가 없는 셈이다.
품질에는 비용이 든다 — 언제 쓰느냐가 관건
품질을 관리하는 데는 돈이 든다. 이 비용은 크게 세 갈래로 나뉜다.
| 비용 구분 | 의미 | 책마루 예 |
|---|---|---|
| 예방 비용(prevention cost) | 결함이 생기기 전에 막는 데 드는 비용 | 요구사항 분석에 시간을 들여 배달 가능 지역 기준을 명확히 정의 |
| 평가 비용(appraisal cost) | 결함을 찾아내는 데 드는 비용 | 코드 리뷰, 테스트 케이스 작성과 실행 |
| 실패 비용(failure cost) | 결함이 이미 발생한 뒤 수습하는 데 드는 비용 | 오픈 후 재고 동기화 버그로 이중 판매가 발생해 긴급 패치 배포 |
세 비용의 크기에는 뚜렷한 비대칭이 있다. "1온스의 예방이 1파운드의 치료를 아낀다"는 격언처럼, 요구사항 분석 단계에서 배달 가능 지역 기준을 명확히 하는 데 드는 비용은 크지 않지만, 이 기준이 모호한 채로 개발이 끝나 오픈 직후 손님 항의가 쏟아진 뒤 고치는 비용은 훨씬 크다. "처음 만들 때 바로 만드는 것(make it right the first time)"이라는 원칙이 품질 비용 이론의 핵심을 요약한다 — 품질은 아끼는 비용이 아니라 시점을 앞당기는 비용이다.
품질 요소 — 무엇을 재야 품질인가
"품질이 좋다"는 말은 그 자체로 막연하다. 소프트웨어 공학에서는 이를 측정 가능한 여러 요소로 쪼개어 다룬다. 아래 표는 대표적인 품질 요소를 세 가지 측면으로 나눈 것이다.
| 측면 | 품질 요소 | 정의 |
|---|---|---|
| 운용 측면 | 정확성(correctness) | 사용자의 요구사항을 만족시키는 정도 |
| 운용 측면 | 신뢰성(reliability) | 장애 없이 의도한 임무를 수행하는 정도 |
| 운용 측면 | 효율성(efficiency) | 자원과 코드량이 최적화된 정도 |
| 운용 측면 | 무결성(integrity) | 허가받지 않은 접근을 통제하는 능력 |
| 수정 측면 | 유지보수성(maintainability) | 오류를 발견하고 수정하는 데 드는 노력 |
| 수정 측면 | 이식성(portability) | 다른 환경으로 옮기는 데 드는 노력 |
| 적응 측면 | 시험성(testability) | 의도한 기능을 검사하는 데 드는 노력 |
| 적응 측면 | 재사용성(reusability) | 일부를 다른 시스템에서 재사용할 수 있는 정도 |
책마루 프로젝트라면 어떤 요소에 무게를 실어야 할까? 결제와 재고를 다루는 시스템이니 무결성과 신뢰성이 중요하고, 반면 대규모 트래픽을 다룰 일은 당분간 없으니 효율성은 상대적으로 여유를 둘 수 있다. 이렇게 품질 요소별로 상대적 중요도를 정하고, 각 요소를 어떻게 측정·검증할지를 요구사항 명세서에 함께 적어두는 것이 실질적인 품질 관리의 출발점이다. 모든 요소를 똑같이 완벽하게 챙기려는 시도는 예산과 일정을 무한정 늘릴 뿐이다.
품질 관리의 세 프로세스
프로젝트의 품질 관리는 크게 세 활동으로 진행된다.
- 품질 계획(quality planning): 프로젝트와 소프트웨어에 대한 품질 요구사항을 식별하고, 어떻게 만족시킬지 결정하는 단계. 다른 프로젝트 계획 활동과 병행하여 이루어진다.
- 품질 보증 수행(perform quality assurance, QA): 계획된 품질 활동이 실제로 적용되고 있는지 평가하고 지속적으로 개선하는 활동. "우리가 정한 절차를 정말 지키고 있는가"를 감사(audit)하는 성격이 강하다.
- 품질 통제(quality control, QC): 프로젝트 각 단계의 산출물이 품질 표준에 부합하는지 감시하고, 불만족스러운 경우 원인을 제거하는 활동. "이 결과물이 기준에 맞는가"를 검사(inspection)하는 성격이 강하다.
QA와 QC는 자주 혼동되지만, QA는 과정을 향하고 QC는 결과물을 향한다는 점이 다르다. 책마루 프로젝트로 비유하면, QA는 "우리 팀이 코드 리뷰를 매주 하기로 한 규칙을 실제로 지키고 있는가"를 점검하는 일이고, QC는 "이번 주에 작성된 재고 차감 코드에 결함이 있는가"를 검사하는 일이다.
공식기술검토회 — 눈을 여럿 두는 이유
QA와 QC를 실제로 구현하는 대표적인 방법이 **공식기술검토회(formal technical review, FTR)**다. 산출물의 오류를 발견하기 위해 여러 사람이 모여 객관적인 시각으로 문서를 살펴보는 활동으로, 특히 프로젝트 초기 요구사항 명세서에 대한 검토회가 중요하다. 이 시점의 오류를 걸러내지 못하면 그 오류가 설계와 구현까지 그대로 흘러가기 때문이다.
실전 지침: 검토회는 문서를 만든 사람이 아니라 산출물 자체를 검토하는 자리다. 참여 인원은 3~5명, 시간은 2시간을 넘기지 않는 것이 바람직하며, 문서는 일주일에서 열흘 전에 미리 배포해 참가자가 문제점을 준비해오도록 한다. 검토의 목적은 문제 발견이지 논쟁이 아니다 — 이 원칙이 흔들리면 검토회는 금방 방어와 반박의 자리로 변질된다.
책마루 프로젝트라면 요구사항 명세서가 완성된 시점에, 사장님·개발 담당자·QA 담당자가 모여 "배달 가능 지역 판단 로직이 실제로 명세서에 정의된 대로인지", "빠진 예외 상황은 없는지"를 짚어보는 자리가 곧 공식기술검토회다.
품질 표준 — ISO 9000 시리즈
품질을 조직 차원에서 보증하려면 외부에서 인정하는 기준이 필요할 때가 있다. 국제표준화기구(ISO)가 정한 ISO 9000 시리즈는 기업의 품질 시스템에 대한 국제 표준으로, 제품 자체를 검사하기보다 "이 조직이 품질을 관리할 수 있는 체계를 갖추고 있는가"를 평가하는 데 초점을 둔다. 그중 ISO 9001은 설계·개발·생산·설치·서비스 전 분야에 적용되는 품질 시스템 요구사항이며, ISO 9000-3은 이를 소프트웨어 개발에 맞게 풀어낸 가이드라인이다.
책마루처럼 소규모 프로젝트를 진행하는 조직이 ISO 9001 인증까지 받을 일은 드물겠지만, 원리는 참고할 만하다 — "품질은 개인의 실력이 아니라 조직의 체계에서 나온다"는 발상 자체가 다음 절에서 다룰 CMMI의 뿌리이기도 하다.
프로세스가 좋아야 제품이 좋다 — 프로세스 개선
소프트웨어 개발은 사람·기술·절차·도구가 뒤섞인 생산 라인이라 기계 조립 라인처럼 표준화하기가 쉽지 않다. 그래서 많은 조직이 시행착오를 반복한다. 그런데 완성된 소프트웨어의 품질은 그 소프트웨어를 만든 프로세스와 밀접하게 연결되어 있다는 것이 소프트웨어 공학의 오랜 관찰이다. 좋은 프로세스가 반드시 좋은 품질을 보장하지는 않지만, 좋은 프로세스 없이 좋은 품질이 안정적으로 나오기는 어렵다.
**소프트웨어 프로세스 개선(software process improvement, SPI)**은 기존 프로세스를 점검해 문제점을 찾아내고, 이를 개선해 품질을 높이거나 비용·일정을 줄이는 활동이다. 성공 사례는 유지하고 실패 사례에서는 원인을 찾아 예방한다는, 어찌 보면 당연한 삶의 지혜를 조직 차원에서 체계적으로 반복하는 것이라 할 수 있다.
이때 두 가지 개념을 구분할 필요가 있다.
- 능력(capability): 개인 또는 조직이 비용·일정·고객 만족 등의 목표를 달성해낼 수 있는 역량
- 성숙도(maturity): 그 능력을 계속 성장시킬 수 있는 조직의 잠재력
프로젝트의 성공이 특정 팀원 한 명의 역량에 의존하는 조직은 그 사람이 빠지는 순간 흔들린다. 프로세스 개선의 목표는 결과가 사람이 아니라 조직의 체계에 의해 예측 가능해지도록 만드는 것이다.
CMMI — 프로세스 성숙도를 재는 자
**CMMI(Capability Maturity Model Integration)**는 카네기멜론 대학교 소프트웨어공학연구소(SEI)가 개발한 프로세스 개선 성숙도 모델이다. 원래 미국 국방성이 소프트웨어 프로젝트 입찰자의 역량을 심사할 목적으로 만든 CMM에서 출발했고, 이후 하드웨어와 시스템 영역까지 통합해 CMMI로 확장되었다. 조직의 개발 프로세스가 얼마나 체계적인지를 0에서 5까지 여섯 단계로 평가한다.
| 레벨 | 명칭 | 특징 |
|---|---|---|
| 0 | 불완전(incomplete) | 가이드라인 없이 개인 역량에 의존, 프로젝트 결과를 예측할 수 없음 |
| 1 | 수행됨(performed) | 기본적인 프로세스는 있지만 개인·프로젝트 관리자에 따라 편차가 큼 |
| 2 | 관리됨(managed) | 요구사항·일정·비용이 문서화되고 추적됨, 프로젝트 단위로 관리 |
| 3 | 정의됨(defined) | 조직 전체에 표준화된 프로세스가 정립되고 훈련됨 |
| 4 | 정량적으로 관리됨(quantitatively managed) | 프로세스 성과를 수치로 측정하고 관리 |
| 5 | 최적화(optimizing) | 지속적인 프로세스 개선이 조직 문화로 자리잡음 |
각 레벨은 그 레벨에 도달하기 위해 만족시켜야 하는 **프로세스 영역(process area, PA)**을 함께 지정한다. 예를 들어 레벨 2에서는 요구사항 관리, 프로젝트 계획 수립, 프로젝트 모니터링 및 통제, 측정 및 분석, 형상 관리(20장에서 다룬다) 같은 영역이 요구된다. 눈여겨볼 점은, 레벨 0과 1의 차이가 "프로세스가 아예 없다"와 "프로세스는 있지만 사람에 따라 들쭉날쭉하다"의 차이라는 것이다 — 즉 레벨 1을 넘는 것부터가 이미 의미 있는 진전이다.
책마루 규모에서 CMMI를 어떻게 읽어야 할까: CMMI는 원래 대규모 국방 프로젝트의 입찰 심사를 위해 만들어진 모델이라, 책마루 같은 소규모 프로젝트가 레벨 인증 자체를 목표로 삼을 이유는 없다. 하지만 "요구사항이 문서화되어 관리되는가", "프로젝트 계획을 과거 데이터에 기반해 세우는가" 같은 레벨 2의 질문들은 규모와 무관하게 유효한 체크리스트다. CMMI의 진짜 쓸모는 인증서가 아니라, 우리 프로세스가 지금 어느 수준에 있는지 스스로 점검하는 거울에 가깝다.
ISO 9001과 CMMI/SPICE, 무엇이 다른가
ISO 9001과 CMMI는 둘 다 "좋은 프로세스가 좋은 품질을 만든다"는 전제를 공유하지만 접근 방식이 다르다. ISO 9001은 품질 시스템이 최소 기준을 충족하는지를 인증(pass/fail) 형태로 평가하는 반면, CMMI는 조직의 성숙도를 **단계적 수준(0~5)**으로 측정해 어디까지 왔고 다음 단계로 가려면 무엇이 필요한지를 보여준다. 국제 표준인 ISO/IEC 15504(흔히 SPICE로 불린다)는 이 둘의 성격을 절충한 것에 가깝다 — CMMI처럼 프로세스 영역별 능력 수준을 평가하면서도, 특정 모델에 종속되지 않는 국제 표준의 형태를 취한다. 요약하면, ISO 9001은 "합격선을 넘었는가"를 묻고, CMMI·SPICE는 "지금 어느 단계에 있고 다음 단계는 무엇인가"를 묻는다.
핵심 정리
- 품질은 궁극적으로 사용자 관점에서 정의되며, 요구사항 명세서가 그 판정 기준이 된다.
- 품질 비용은 예방·평가·실패 세 갈래로 나뉘고, 예방에 쓰는 적은 비용이 실패 비용의 큰 지출을 막는다.
- 품질 관리는 품질 계획, 품질 보증(과정 점검), 품질 통제(결과물 점검)로 이루어지며, 공식기술검토회가 이를 실제로 구현하는 대표적인 방법이다.
- CMMI는 조직의 프로세스 성숙도를 0~5단계로 평가하는 모델로, 프로젝트의 성공이 개인 역량이 아니라 조직의 체계에서 나오도록 만드는 것을 목표로 한다.
다음 장(20장)에서는 소프트웨어의 변경을 체계적으로 관리하는 형상 관리 — 문서의 동결과 기준선, 변경 통제 절차를 다룬다.