품질 요구와 평가 모델
ISO/IEC 25010:2023의 아홉 가지 제품 품질 특성과 그 전신인 ISO/IEC 9126을 구별하고, 제품 품질, 사용 품질, 프로세스 평가가 각각 무엇을 묻는지 정리합니다. 모임 앱의 품질 질문을 확인 방법과 함께 적고, 측정값 하나로 품질을 요약할 때의 함정을 실행으로 확인합니다.
신청 결과가 맞는지 확인하는 테스트는 중요하지만, 참가자가 거절된 이유를 이해하는지나 저장에 실패한 뒤 명단을 되살릴 수 있는지는 다른 질문입니다. 품질(quality)은 소프트웨어가 정해진 필요와 조건을 얼마나 만족하는지에 대한 판단이며, 무엇을 묻느냐에 따라 확인하는 방법도 달라집니다. 이 글에서는 품질을 여러 특성으로 나누어 보는 표준 모델을 정리하고, 모임 앱의 품질 질문을 확인할 수 있는 형태로 적어 봅니다.
품질을 여러 특성으로 나누어 본다
ISO/IEC 25010:2023의 제품 품질 모델은 품질을 기능 적합성, 성능 효율성, 호환성, 상호작용 능력, 신뢰성, 보안성, 유지보수성, 유연성, 안전성의 아홉 특성으로 나눕니다. 판본과 다루는 범위는 ISO의 공식 소개에서 확인할 수 있습니다. 이 특성들은 빠뜨린 질문이 없는지 점검하는 분류이며, 모임 앱이 넘어야 할 기준값까지 정해 주지는 않습니다.
이 모델에는 앞선 판본들이 있습니다. 원자료가 설명하는 ISO/IEC 9126은 기능성, 신뢰성, 사용성, 효율성, 유지보수성, 이식성의 여섯 특성으로 품질을 나누었고, 2011년에 나온 ISO/IEC 25010의 첫 판은 이를 여덟 특성으로 다시 짰습니다. 2023년 판에서는 사용성이 상호작용 능력으로, 이식성이 유연성으로 이름과 범위가 바뀌고 안전성이 새로 더해졌습니다. 시험이나 옛 문서를 읽으려고 이전 판본을 배우는 것과 지금의 제품을 평가하는 것은 목적이 다르므로, 어느 판본의 특성을 쓰는지 밝히고 서로 섞지 않습니다.
품질을 묻는 대상도 구별해야 합니다. 제품 품질(product quality)은 소프트웨어 자체의 특성을 보고, 사용 품질(quality in use)은 정해진 사용자가 정해진 과업과 환경에서 실제로 얻는 결과를 봅니다. 프로세스 평가(process assessment)는 소프트웨어를 만드는 조직이 개발 활동을 얼마나 잘 수행하고 관리하는지를 봅니다. 그래서 조직의 프로세스 수준이 높다는 평가가 곧 이 제품에 결함이 없다는 뜻은 아닙니다.
SOFTWARE ENGINEERING · READING CLUB
품질 질문에서 조건을 정하고 증거를 얻는다
같은 함수의 실행 시간 하나로 복구·사용성·보안을 모두 판단하지 않습니다.
ISO 품질 모델은 질문을 빠뜨리지 않도록 돕습니다. 수락 기준과 검증 환경은 제품의 목적에서 정합니다.
모임 앱의 품질 질문과 확인 방법
그림처럼 품질 질문마다 평가의 조건을 정하고, 질문에 맞는 방법으로 확인합니다. 같은 함수의 실행 시간 하나로 복구, 사용성, 보안을 모두 판단할 수는 없습니다.
| 품질 특성 | 모임 앱의 질문 | 확인하는 방법 |
|---|---|---|
| 기능 적합성 | 신청과 취소의 결과 코드와 상태가 요구 R1–R6과 맞는가 | 결과 코드와 상태의 단언 |
| 신뢰성 | 프로그램을 끝냈다가 다시 시작해도 저장한 명단이 돌아오는가 | 저장과 복원의 통합 테스트, 복구 연습 |
| 상호작용 능력 | 처음 쓰는 참가자가 FULL 안내를 보고 다음에 할 일을 아는가 | 과업을 정한 사용성 시험 |
| 보안성 | 권한이 없는 사람이 명단을 읽지 못하는가 | 인증과 인가 기능이 있는 환경에서 시험 |
| 성능 효율성 | 정한 부하에서 신청 처리 시간이 기준 안에 드는가 | 환경을 고정한 반복 측정 |
사용성처럼 사람이 관련된 품질은 다음과 같이 질문, 환경, 관찰할 것, 판단 기준, 한계를 함께 적어 둡니다.
품질 질문: 처음 쓰는 참가자가 아이디 오류를 스스로 고칠 수 있는가?
환경: 같은 안내 문구, 같은 입력 장치, 미리 정한 과업.
관찰할 것: 과업 성공 여부, 고치는 데 걸린 시간, 되풀이한 오류, 도움 요청.
판단 기준: 대상 사용자와 목표를 정한 뒤 합의한다.
한계: 작은 시험의 결과를 모든 사용자에게 일반화하지 않는다.측정값 하나로 요약하지 않는다
성능처럼 숫자로 재는 품질도 값을 어떻게 요약하느냐에 따라 결론이 달라집니다. 다음 코드는 신청 처리 시간을 열 번 잰 가상의 측정값을 평균, 90번째 백분위수, 최댓값으로 요약합니다. 이 값은 설명을 위해 정한 것이며 실제로 잰 결과가 아닙니다.
const samples = [4, 5, 5, 6, 6, 7, 7, 8, 9, 48];
const average = samples.reduce((sum, value) => sum + value, 0) / samples.length;
const sorted = [...samples].sort((a, b) => a - b);
const p90 = sorted[Math.ceil(0.9 * sorted.length) - 1];
console.log("평균:", average, "90번째 백분위수:", p90, "최댓값:", sorted.at(-1));평균: 10.5 90번째 백분위수: 9 최댓값: 48백분위수(percentile)는 값을 크기순으로 늘어놓았을 때 그 비율의 위치에 있는 값으로, 90번째 백분위수 9는 열 번 가운데 아홉 번이 9 이하였다는 뜻입니다. 그런데 평균은 10.5로 90번째 백분위수보다도 큽니다. 한 번 크게 늦어진 48이 평균을 끌어올렸기 때문이며, 평균만 보면 대부분의 요청이 느린 것처럼, 백분위수만 보면 가끔 매우 느린 요청이 없는 것처럼 보일 수 있습니다. 그래서 비기능 요구와 변경 추적에서처럼 성능 요구에는 측정 환경, 횟수, 어떤 값으로 요약할지를 함께 정하고, 필요하면 최댓값도 따로 봅니다.
품질 보증과 품질 관리
품질 보증(quality assurance, QA)은 알맞은 개발 활동과 확인 활동이 계획되고 실제로 수행되는지를 미리 살펴 결함을 예방하는 활동입니다. 품질 관리(quality control, QC)는 만들어진 산출물을 검사해 실제 품질을 확인하고 고치는 활동에 무게를 둡니다. 두 활동은 서로 이어져 있으므로, 요구 검토나 코드 검토, 테스트를 어느 한쪽에 기계적으로 넣기보다 각 활동의 목적과 맡은 사람을 분명히 하는 편이 낫습니다.
품질 목표끼리 부딪히기도 합니다. 모든 기록을 영원히 보관하면 문제를 분석하기에는 좋지만, 개인 정보를 정해진 기간만 보관해야 한다는 요구와 충돌할 수 있습니다. 또 성능을 높이려고 저장 자료의 검사를 빼면 잘못된 상태를 받아들일 위험이 커지므로, 품질 목표 사이의 우선순위를 합의하고 그 이유를 남깁니다.
정리
- 품질은 정해진 필요와 조건을 얼마나 만족하는지에 대한 판단이며, 질문에 따라 확인하는 방법이 다릅니다.
- ISO/IEC 25010:2023은 품질을 아홉 특성으로 나누며, 전신인 ISO/IEC 9126과 2011년 판의 특성을 섞어 쓰지 않습니다.
- 제품 품질, 사용 품질, 프로세스 평가는 서로 다른 대상을 보므로, 프로세스 수준이 높다고 제품에 결함이 없는 것은 아닙니다.
- 측정값은 평균, 백분위수, 최댓값 가운데 무엇으로 요약하느냐에 따라 결론이 달라지므로 요약 방법을 요구에 함께 적습니다.
- 품질 보증은 예방에, 품질 관리는 산출물의 검사에 무게를 두며, 품질 목표 사이의 충돌은 우선순위와 이유를 남겨 다룹니다.
연습 문제
1. 하나의 수치로 비교하기
A 판은 신청 처리가 빠르고, B 판은 복원에 실패했을 때 무엇을 해야 하는지 더 잘 안내합니다. 팀은 실행 시간 하나로 두 판의 품질 순위를 정하려 합니다. 빠진 질문과 함께 비교할 자료를 제안하세요.
해설 보기
성능 효율성과 신뢰성, 상호작용 능력을 실행 시간 하나로 판단하려 하고 있습니다. 같은 기기와 같은 부하에서 잰 처리 시간의 분포, 저장에 실패했을 때 상태가 보존되고 다시 시도할 수 있는지, 사용자가 오류 안내를 이해하는지를 각각 확인해야 합니다. 그런 다음 업무의 목표에 따라 특성 사이의 우선순위를 합의하고, 가중치를 두었다면 그 이유를 남깁니다. 빠르다는 이유만으로 복구도 잘 된다고 결론 내릴 수는 없습니다.
2. 판본이 다른 특성 이름
어떤 보고서가 "이 앱은 ISO/IEC 25010:2023 기준으로 이식성과 사용성이 우수하다"고 적었습니다. 무엇이 어긋났는지 설명하세요.
해설 보기
이식성과 사용성은 ISO/IEC 9126과 25010의 2011년 판에서 쓰던 특성 이름이고, 2023년 판에서는 각각 유연성과 상호작용 능력으로 이름과 범위가 바뀌었습니다. 판본은 2023년 판이라고 적으면서 이전 판의 특성 이름을 쓰면, 어떤 기준으로 평가했는지 알 수 없게 됩니다. 어느 판본을 썼는지 밝히고 그 판본의 특성 이름과 정의를 일관되게 써야 하며, "우수하다"는 판단에도 어떤 조건에서 무엇을 확인했는지가 함께 있어야 합니다.
3. 평균이 숨기는 것
본문의 측정값에서 48을 8로 바꾸면 평균과 90번째 백분위수, 최댓값은 어떻게 되나요? 이 결과에서 무엇을 배울 수 있는지 설명하세요.
해설 보기
값은 [4, 5, 5, 6, 6, 7, 7, 8, 9, 8]이 되어 합이 65이므로 평균은 6.5입니다. 크기순으로 늘어놓으면 [4, 5, 5, 6, 6, 7, 7, 8, 8, 9]이므로 90번째 백분위수는 아홉 번째 값인 8이고, 최댓값은 9입니다. 매우 느린 요청 하나가 사라지자 평균이 4나 줄었지만 90번째 백분위수는 1만 줄었습니다. 평균은 드물게 크게 벗어난 값에 크게 흔들리므로, 사용자가 겪는 느림을 판단할 때는 백분위수와 최댓값을 함께 보아야 합니다.
품질을 정의하고 확인했다면, 그 품질을 유지하면서 소프트웨어를 계속 바꾸어 가야 합니다. 다음 글 유지보수와 기술 부채에서는 전달한 뒤에 일어나는 변경의 종류와, 동작을 지키며 바꾸는 방법을 다룹니다.