개념
이름을 외운 사람과 안 외운 사람의 케이스 목록이 같다면
모듈 1(레슨 1)에서 "품질은 하나의 값이 아니라 여러 축의 묶음"이라고 했고, 그 축의 이름으로 ISO/IEC 25010의 여덟 갈래를 한 줄로 훑고 지나갔다. 모듈 1(레슨 4)에서는 그 갈래들이 곧 비기능 테스트의 목록이라는 것도 봤다. 여기서 한 걸음 더 나간다.
이 레슨의 질문은 "품질 특성이 몇 개인가"가 아니다. "이 여덟 개를 손에 들고 있을 때, 눈앞의 기능 하나에서 검증 항목을 몇 개 더 뽑아낼 수 있는가" 다.
여덟 개 이름을 외우는 건 30분이면 끝난다. 그런데 외운 사람과 안 외운 사람이 같은 기능을 놓고 똑같은 케이스 목록을 만든다면 외운 의미가 없다. 25010이 값을 만드는 순간은 "아, 이 특성 칸이 비어 있네" 를 알아채는 순간 하나뿐이다.
25000번대라는 서랍장 — SQuaRE 시리즈
25010은 홀로 떠다니는 규격이 아니다. ISO/IEC 25000번대는 SQuaRE(Systems and software Quality Requirements and Evaluation) 라는 시리즈이고, 25010은 그 안의 한 칸이다.
| 번호대 | 부문 | 무엇을 담는가 | 이 커리큘럼에서 |
|---|---|---|---|
| 2500n | 품질 관리 | 시리즈 전체의 용어와 구조 안내(25000, 25001) | 지도 역할 |
| 2501n | 품질 모델 | 무엇을 품질이라 부르는가 — 25010(제품 품질·이용 품질), 25012(데이터 품질) | 이 레슨 |
| 2502n | 품질 측정 | 그 특성을 어떤 수식으로 재는가 — 25022, 25023, 25024 | 레슨 3 |
| 2503n | 품질 요구사항 | 품질 요구를 어떻게 명세하는가(25030) | 요구사항 리뷰(모듈 2) |
| 2504n | 품질 평가 | 평가를 어떤 절차로 수행하는가(25040~25045) | 인증·심사 실무 |
한 문장으로 줄이면 이렇다. 25010은 "무엇을 볼 것인가"의 목록이고, 25023은 "그것을 어떤 숫자로 잴 것인가"의 계산식이다. 목록만 있고 계산식이 없으면 "사용성을 확인했습니다"라는 말이 사람마다 다른 뜻이 되고, 계산식만 있고 목록이 없으면 왜 그 숫자를 재는지 설명하지 못한다. 그래서 두 편은 한 짝으로 쓰인다 — 레슨 3에서 25023과 GS인증(ISO/IEC 12119 계열의 시험 요구)을 이어서 다룬다.
25010이 정의하는 것과, 절대 정의해주지 않는 것
25010은 두 개의 모델을 담고 있다.
- 제품 품질 모델 — 제품 자체가 가진 성질. 여덟 특성이 여기 속한다.
- 이용 품질 모델(Quality in Use) — 실제 사용자가 특정 맥락에서 제품을 썼을 때 나타나는 결과. 효과성·효율성·만족도·위험 회피성·상황 커버리지 다섯 가지다.
이 둘의 관계가 모듈 1(레슨 1)의 "명세 충족 vs 쓰임에 적합함"과 겹친다. 제품 품질은 제품을 뜯어봐서 판정하고, 이용 품질은 사용자를 앉혀놓고 실제로 목표를 달성시켜봐야 판정된다. 우산 비유로 돌아가면 제품 품질은 "지름 1m, 방수 원단"이고 이용 품질은 "이 사람이 비 오는 날 젖지 않고 도착했는가"다.
그리고 25010이 절대 알려주지 않는 것 이 있다. 합격선이다. 표준은 "시간 반응성은 성능 효율성의 부특성"이라고만 말하지 "3초 안에 응답해야 한다"고는 하지 않는다. 숫자는 제품·계약·사용자가 정한다. 규격서를 펼치면 기준이 나올 줄 알았는데 나오는 건 항목 이름뿐이다 — 25010은 답안지가 아니라 질문지 다.
여덟 특성과 부특성 — "확인하려면 무슨 테스트를 하는가"까지
아래 표가 이 레슨의 뼈대다. 왼쪽 두 칸은 어디서나 볼 수 있는 목록이고 값이 있는 칸은 오른쪽이다. 부특성마다 "그래서 무슨 테스트를 하는가"가 붙어야 비로소 이 표가 도구가 된다.
| 특성 | 부특성 | 확인하려면 무슨 테스트를 하는가 |
|---|---|---|
| 기능 적합성 | 기능 완전성 | 요구사항 목록과 테스트 케이스를 맞대어 커버되지 않은 요구를 찾는다(추적 매트릭스) |
| 기능 정확성 | 경계값·동등분할로 뽑은 입력에 대해 기대 출력과 실제 출력을 비교한다 | |
| 기능 타당성 | "이 기능이 사용자의 목표 달성에 실제로 쓸모 있는가"를 시나리오로 확인한다 | |
| 성능 효율성 | 시간 반응성 | 평상시 부하에서 응답 시간을 측정한다(평균이 아니라 95·99퍼센타일로) |
| 자원 사용률 | 부하 중 CPU·메모리·디스크·네트워크 사용량을 모니터링한다 | |
| 용량 | 동시 사용자·데이터 건수를 올려가며 성능이 무너지는 지점을 찾는다(부하·스트레스) | |
| 호환성 | 공존성 | 같은 서버·단말에 다른 소프트웨어가 함께 있을 때 서로를 방해하지 않는지 본다 |
| 상호운용성 | 외부 시스템과 주고받는 데이터의 형식·인코딩·시간대를 검증한다(계약 테스트) | |
| 사용성 | 적절성 인지성 | 처음 보는 화면에서 "이게 찾던 기능"임을 알아보는지 관찰한다 |
| 학습성 | 안내 없이 첫 과업을 끝내는 데 걸리는 시간·실패율을 잰다 | |
| 운용성 | 반복 과업의 클릭 수, 단축키·되돌리기 유무를 확인한다 | |
| 사용자 오류 방지성 | 위험한 조작(삭제·전액 이체)에 확인 단계·되돌리기가 있는지 본다 | |
| 사용자 인터페이스 심미성 | 디자인 시안과 실제 화면을 비교한다(시각 회귀 테스트) | |
| 접근성 | 스크린 리더·키보드만으로 과업을 끝낼 수 있는지, 명도 대비가 기준을 넘는지 확인한다 | |
| 신뢰성 | 성숙성 | 장시간 연속 운전(soak) 후 오류율·메모리 증가 추이를 본다 |
| 가용성 | 일정 기간의 다운타임을 집계해 목표 가용률과 비교한다 | |
| 결함 허용성 | 의존 컴포넌트를 일부러 죽여도 서비스가 부분적으로 계속되는지 본다(장애 주입) | |
| 복구성 | 강제 종료 후 재기동 시간과 데이터 손실 범위를 측정한다(백업·복구 리허설) | |
| 보안성 | 기밀성 | 권한 없는 계정·비로그인 상태로 남의 자원에 접근되는지 시도한다 |
| 무결성 | 전송·저장 중 변조가 탐지되는지 확인한다(서명·체크섬 우회 시도) | |
| 부인 방지성 | 거래 후 "나는 안 했다"를 반박할 증거(전자서명·감사 기록)가 남는지 확인한다 | |
| 책임 추적성 | 누가 언제 무엇을 했는지 로그로 특정 가능한지, 로그가 위조 불가인지 본다 | |
| 인증성 | 주장하는 신원이 실제 그 사람인지 검증되는지 본다(토큰 위조·세션 탈취 시도) | |
| 유지보수성 | 모듈성 | 한 모듈을 고쳤을 때 영향 범위가 국소적인지 의존 관계로 확인한다 |
| 재사용성 | 공통 로직이 여러 곳에 복사되어 있는지, 한 곳만 고치면 되는지 본다 | |
| 분석성 | 장애 시 로그·추적 정보만으로 원인 위치를 좁힐 수 있는지 훈련해본다 | |
| 수정 용이성 | 작은 변경을 넣었을 때 회귀 결함이 얼마나 생기는지 이력으로 본다 | |
| 시험 용이성 | 테스트용 계정·데이터·스텁을 만들 수 있는지, 시간·랜덤을 고정할 수 있는지 확인한다 | |
| 이식성 | 적응성 | 다른 OS·브라우저·해상도·DB로 옮겨도 동작하는지 확인한다 |
| 설치 용이성 | 깨끗한 환경에서 설치·업그레이드·롤백·제거를 실제로 수행해본다 | |
| 대체 용이성 | 기존 버전이나 경쟁 제품에서 교체할 때 데이터가 그대로 넘어오는지 본다 |
이 표를 다 외울 필요는 없다. 필요한 건 오른쪽 칸을 스스로 채울 수 있는 상태 다. 부특성 이름만 보고 "그래서 뭘 하지?"가 안 떠오르면 그 특성은 아직 검증 항목이 될 수 없다.
품질 특성을 테스트 케이스로 옮기는 4단계
절차 자체는 단순하다. 어렵게 만드는 건 2단계다.
- 기능을 하나로 좁힌다. "우리 서비스"가 아니라 "프로필 사진 업로드"처럼 화면 하나·API 하나 크기로 잘라야 질문이 구체적으로 나온다.
- 여덟 특성을 차례로 놓고 "이 기능에 이 특성이 의미가 있는가"부터 판정한다. 없으면 빈칸으로 두지 말고 "해당 없음 — 이유" 를 적는다. 빈칸은 안 봤다는 뜻인지 봤는데 없다는 뜻인지 구분되지 않는다.
- 의미가 있으면 부특성 단위로 내려가 질문을 만든다. "보안성을 본다"에서 멈추면 막연하다. "인증성 — 남의 토큰으로 이 API를 부르면?"까지 내려가야 한다.
- 질문을 판정 가능한 문장으로 바꾼다. 조건 + 조작 + 기대 결과, 비기능이면 기준선 숫자까지. 모듈 1(레슨 4)의 "합격선이 없으면 판정이 불가능하다"가 그대로 적용된다.
3단계의 질문 중 일부는 테스트 케이스가 아니라 기획에 던지는 질문 으로 끝난다. 그것도 산출물이다 — 모듈 1(레슨 1)의 "코드가 생기기 전에 던지는 질문이 가장 싸다"가 바로 이 활동이다.
완결 사례 — 파일 업로드 하나가 3개에서 14개로
요구사항은 한 줄이다. "사용자가 프로필 사진을 업로드할 수 있다. JPG/PNG, 5MB 이하." 기능만 보고 케이스를 뽑으면 대개 이렇게 셋이다.
TC-1 2MB JPG 업로드 → 프로필에 반영된다
TC-2 GIF 업로드 → "지원하지 않는 형식" 메시지
TC-3 7MB JPG 업로드 → "5MB 이하만 가능" 메시지이제 여덟 특성을 차례로 훑는다. 2단계(의미 판정)를 포함해서 그대로 적어본다.
| 특성 | 이 기능에 던지는 질문 | 새로 나온 검증 항목 |
|---|---|---|
| 기능 적합성 | 명세된 형식이 전부 커버됐나? 5MB 초과가 "거부"가 맞나 "자동 축소"가 맞나? | TC-4 PNG 2MB 업로드 정상 반영 / Q-1 초과 시 정책 확인(기획 질문) |
| 성능 효율성 | 5MB를 느린 회선에서 올리면 얼마나 걸리나? 진행률이 멈춘 것처럼 보이지 않나? | TC-5 3G 환경 4.9MB 업로드가 30초 이내 완료, 진행률이 5초 이상 정지하지 않음 |
| 호환성 | iOS 사파리에서 고른 HEIC 사진은? 확장자 없는 파일은? | TC-6 iOS 17 사파리에서 HEIC 선택 시 변환 또는 명확한 거부 메시지 |
| 사용성 | 거부 메시지가 "무엇을 어떻게 하라"를 말하나? 키보드만으로 되나? | TC-7 초과 메시지에 현재 파일 크기와 허용 한도가 함께 표시 / TC-8 키보드 Tab·Enter만으로 선택 완료 |
| 신뢰성 | 업로드 중 네트워크가 끊기면? 재시도하면 두 장이 저장되나? | TC-9 전송 50%에서 회선 차단 → 오류 안내 후 재시도 가능, 부분 파일 없음 / TC-10 같은 파일 연속 2회 전송 시 이미지 1개만 유지 |
| 보안성 | 확장자만 .jpg로 바꾼 실행 파일은? 남의 이미지 URL을 알면 보이나? 누가 올렸는지 남나? | TC-11 실행 파일을 .jpg로 위장 업로드 → 서버가 실제 내용으로 거부 / TC-12 비로그인 상태로 타인 이미지 URL 접근 시 차단 / TC-13 업로드 시각·계정이 감사 로그에 기록 |
| 유지보수성 | 형식·용량 제한이 하드코딩인가 설정값인가? 테스트에서 한도를 바꿀 수 있나? | TC-14 설정으로 한도를 1MB로 낮춘 뒤 1.5MB 파일이 거부되는지 확인 |
| 이식성 | 저장소를 다른 곳으로 옮겨도 되나? 온프레미스 설치본에서도 되나? | 해당 없음 — 이 제품은 단일 SaaS 배포이며 저장소 교체 계획이 없음 |
3개가 14개가 됐고, 기획 질문 하나가 따로 남았다. 마지막 줄은 "해당 없음"으로 명시적으로 닫혔다 — 안 본 게 아니라 보고 넘긴 것이라는 기록이다.
오해하면 안 되는 게 있다. 이 14개를 다 실행해야 한다는 뜻이 아니다. 어느 것을 돌릴지는 리스크가 정한다. 다만 순서가 중요하다 — 떠오르지도 않은 항목은 우선순위를 매길 수조차 없다. 25010은 우선순위 도구가 아니라 누락 방지 도구 다. 목록을 먼저 넓히고 그다음에 자른다.
함정 1 — 여덟 칸을 억지로 다 채우기
가장 흔한 실패는 반대 방향에서 온다. 표의 여덟 줄이 눈앞에 있으면 사람은 빈칸을 못 견딘다. 그래서 이런 케이스가 만들어진다.
- 사내 30명이 쓰는 관리자 도구에 "동시 접속 1,000명 부하 테스트"
- 다시는 설치할 일이 없는 사내 웹 서비스에 "설치 용이성 검증"
- 로그인도 없는 사내 위키에 "부인 방지성 확인"
이런 케이스는 시간을 먹고, 통과해도 아무 정보를 주지 않으며, 테스트 스위트 전체의 신뢰를 깎는다. 기준은 하나다 — 그 케이스가 실패했을 때 릴리즈를 멈출 것인가? 멈추지 않을 항목이면 "해당 없음"이나 "차기 검토"로 적고 넘어가는 편이 정직하다.
함정 2 — 가중치 없이 여덟 개를 똑같이 취급하기
정반대 실패도 있다. 여덟 특성을 균등하게 한 칸씩 채워놓고 "골고루 봤다"고 하는 경우다. 제품에 따라 특성 하나가 나머지 일곱을 합친 것보다 중요하다.
| 제품 | 압도적으로 중요한 특성 | 상대적으로 낮은 특성 |
|---|---|---|
| 인터넷 뱅킹 앱 | 보안성, 신뢰성 | 이식성(배포 채널이 고정) |
| 대규모 트래픽 커머스 | 성능 효율성, 신뢰성 | 대체 용이성 |
| 공공기관 웹 서비스 | 사용성(특히 접근성), 호환성 | 재사용성 |
| 패키지로 판매하는 설치형 제품 | 이식성, 설치 용이성 | 사용자 인터페이스 심미성 |
| 사내 관리자 대시보드 | 기능 적합성, 유지보수성 | 성능 효율성(사용자 30명) |
이 가중치를 감으로 정하지 말고, 모듈 4(레슨 2)에서 배운 리스크 기반 우선순위를 특성 단위에 그대로 적용 하면 된다. 특성마다 "무너질 발생 가능성"과 "무너졌을 때의 영향도"를 매겨 곱한다. 뱅킹 앱의 보안성은 영향도가 최대치라 발생 가능성이 낮아도 상단에 오고, 사내 도구의 성능 효율성은 아래로 내려간다.
이 표를 테스트 계획서에 넣으면 부수 효과가 생긴다. "왜 성능 테스트를 안 했나요"라는 질문이 나왔을 때 안 한 이유가 이미 적혀 있다. 빠뜨린 것과 판단해서 뺀 것은 다른 이야기이고, 그 차이를 증명하는 건 사전 기록이다.
옛 문서에서 만나는 ISO 9126 — 25010으로 번역해 읽기
오래된 사내 품질 지침이나 공공 RFP에서 25010이 아니라 ISO/IEC 9126 용어를 만나는 일이 꽤 있다. 9126은 25010의 전신으로, 특성이 여섯 개였다. 대응만 알면 그대로 읽을 수 있다.
| ISO 9126 (구) | ISO/IEC 25010에서 어디로 갔나 |
|---|---|
| 기능성(Functionality) | 셋으로 쪼개졌다 — 기능 적합성 + 보안성(부특성에서 독립 특성으로 승격) + 호환성의 상호운용성 |
| 신뢰성(Reliability) | 신뢰성 그대로. 가용성이 부특성으로 추가됨 |
| 사용성(Usability) | 사용성 그대로. 접근성·사용자 오류 방지성이 부특성으로 들어옴 |
| 효율성(Efficiency) | 성능 효율성으로 개명. 용량이 부특성으로 추가됨 |
| 유지보수성(Maintainability) | 유지보수성 그대로. 모듈성·재사용성이 추가됨 |
| 이식성(Portability) | 이식성 그대로. 단 공존성은 호환성으로 이사감 |
| 각 특성 아래의 준수성(Compliance) | 삭제됨. 규격 준수는 특성의 하위가 아니라 별도 요구사항으로 다룬다 |
옛 문서를 읽을 때 실무 요령은 셋이다.
- "기능성"이라고 적힌 요구를 보면 보안이 그 안에 포함됐는지부터 확인한다. 9126 시절 보안은 기능성의 부특성이었으므로, "기능성 시험"만 적혀 있어도 발주처는 보안 검증을 기대하고 있을 수 있다.
- "효율성"은 성능으로 읽는다. 유지보수성이나 개발 생산성 이야기가 아니다.
- "준수성" 항목이 남아 있으면 그건 25010 특성이 아니라 법·규제·사내 표준 요구로 다시 분류한다. 이 모듈 뒷부분의 도메인 안전 규격들이 대개 여기로 온다.
판 이야기가 하나 더 있다. 이 레슨의 여덟 특성은 25010:2011판 기준이다. 2023년 개정판은 특성이 아홉 개다 — 안전성(Safety) 이 독립 특성으로 추가되고, 사용성은 상호작용 역량(Interaction Capability), 이식성은 유연성(Flexibility)으로 이름이 바뀌며 확장성(Scalability)이 그 아래로 들어왔다. 국내 GS인증 자료와 대부분의 RFP·교재는 아직 2011판을 쓰기에 이 레슨도 그것을 기준으로 삼는다. 다만 판을 말하지 않고 "25010에 따르면"이라고 하면 서로 다른 목록을 놓고 대화하게 된다 — 판 연도를 함께 말하는 습관 을 들이는 게 안전하다.
실무에서 왜 필요한가
가장 먼저 체감되는 곳은 테스트 계획서의 "범위" 절 이다. "결제 모듈 전체를 테스트한다"는 문장은 아무것도 약속하지 않는다. 특성별로 쪼개 적으면 그 문서는 협상 가능한 물건이 된다 — "기능 적합성과 보안성은 전수, 성능 효율성은 피크 시나리오 3건, 이식성은 해당 없음"이라고 적혀 있으면 일정이 줄었을 때 무엇을 포기할지가 항목 단위로 논의된다.
두 번째는 결함 심각도를 두고 벌어지는 논쟁 이다. "이건 버그가 아니라 스펙"이라는 대화는 대개 평행선을 달린다. 특성 언어를 넣으면 축이 바뀐다 — "기능 적합성은 통과입니다. 미달인 건 사용성의 사용자 오류 방지성이고요, 삭제에 확인 단계가 없어서 복구 불가능한 조작이 클릭 한 번에 일어납니다." 논쟁이 "버그냐 아니냐"에서 "이 특성의 목표 수준을 어디로 둘 것이냐"로 옮겨간다. 모듈 1(레슨 1)의 세 번째 결함 유형(이해관계자 간 기대 불일치)을 다루는 실용적인 도구다.
세 번째는 계약과 문서 다. 공공 SI, GS인증 준비, 협력사 품질 심사에서는 25010 용어가 산출물 서식에 그대로 박혀 있다. "품질 특성별 시험 결과서"를 제출하라는 요구를 받으면 이 레슨의 표가 그대로 목차가 된다.
네 번째는 릴리즈 판단 이다. 모듈 4(레슨 5)의 Go/No-Go 회의에서 가장 답하기 어려운 질문은 "무엇을 확인했나요"가 아니라 "무엇을 확인하지 않았나요" 다. 여덟 특성 표가 있으면 이 질문에 목록으로 답할 수 있고, "성능 효율성은 스테이징 데이터 기준이라 실제 용량은 미확인입니다" 같은 한 문장이 사고 시 대응 속도를 바꾼다.
채용시장에서의 위치
25010은 이 모듈에서 산업을 가리지 않는 몇 안 되는 표준 이다. ISO 26262나 DO-178C는 자동차·항공에 있지 않으면 평생 안 볼 수 있지만, 25010의 용어는 웹 서비스의 테스트 계획서에도 공공 SI 제안서에도 똑같이 등장한다. 모듈 개요가 말한 "표준 지도" 안에서 이 편이 가장 넓게 쓰인다. 값이 되는 지점은 셋이다.
- 면접 답변의 구조가 생긴다. "부하 테스트 조금 해봤습니다"로 끝나는 답과 "성능 효율성은 시간 반응성·용량 두 축으로 봤고, 신뢰성은 복구성만 검증했고 결함 허용성은 못 봤습니다"라는 답은 경력 판단을 완전히 다르게 만든다. 후자는 자기가 안 한 것까지 알고 있다 는 신호다.
- 공공·SI·GS인증 조직에서는 문서 작성 능력 그 자체다. GS인증(굿 소프트웨어 인증)을 준비하면 품질 특성별 시험 항목과 결과서를 만들어야 하고, 그 작업이 QA에게 온다. 레슨 3의 측정 지표와 묶이면 바로 산출물이 된다.
- ISTQB Foundation 시험 범위와 겹친다. 비기능 테스트 유형 분류의 근거로 25010이 인용되므로, 자격증 준비와 실무 학습이 같은 자리에서 해결된다.