개념
레슨 2가 남긴 질문 — "그래서 몇 점인가"
앞 레슨에서 ISO/IEC 25010이 품질을 여덟 갈래로 나눈다는 것을 봤다. 기능 적합성·성능 효율성·호환성·사용성·신뢰성·보안성·유지보수성·이식성. 갈래를 나눈 덕에 "품질이 좋다"는 말이 훨씬 구체적인 문장으로 바뀌었다.
그런데 회의실에서 다음 질문이 곧바로 따라온다. "그래서 우리 제품의 사용성은 지금 몇 점입니까?" 여덟 갈래로 나눴다는 것만으로는 이 질문에 답할 수 없다. 갈래는 무엇을 볼지를 정해줄 뿐, 어떻게 잴지 는 정해주지 않기 때문이다.
이 레슨은 그 빈칸을 메우는 이야기다. 특성을 숫자로 바꾸는 규격 (ISO/IEC 25023), 프로그램뿐 아니라 설명서까지 검증 대상으로 규정한 규격 (ISO/IEC 12119와 그 후속), 그리고 그 둘을 근거로 제3자가 도장을 찍어주는 제도(GS인증)를 차례로 본다.
ISO/IEC 25023이 하는 일 — 특성과 숫자 사이의 다리
ISO/IEC 25023의 정식 제목은 "시스템·소프트웨어 제품 품질의 측정 (Measurement of system and software product quality)" 이다. 이름 그대로 25010이 정의한 각 특성·부특성에 대해 측정량(quality measure)과 그 측정 방법 을 제시한다.
구조는 단순하다. 25023은 특성 하나마다 이런 형태의 정의를 준다.
- 무엇을 세는가 — 측정 대상이 되는 원소(quality measure element). 예를 들어 "명세된 기능의 개수", "구현되어 정상 동작하는 기능의 개수".
- 어떻게 계산하는가 — 원소들을 조합하는 공식. 대개
X / Y형태의 비율이거나, 시간·건수 같은 절대량이다. - 어떤 값이 좋은가 — 값의 범위와 해석 방향(0에 가까울수록 좋은지, 1에 가까울수록 좋은지).
핵심은 25023이 합격선을 정해주지 않는다 는 점이다. "기능 구현 충족도가 0.95 이상이어야 한다" 같은 문장은 규격에 없다. 규격은 재는 자를 주고, 눈금을 어디에 그을지는 조직이 정한다. 이 구분을 놓치면 "표준이 요구하는 수치"라는 존재하지 않는 것을 찾아 헤매게 된다.
측정량은 어떻게 생겼나 — 공식·단위·데이터 출처
말로만 보면 추상적이니 실제로 어떤 모양인지 표로 보자. 아래는 25023 계열의 측정량이 취하는 전형적인 형태 를 QA 실무 관점에서 정리한 것이다. 규격의 정확한 표기·기호와 항목 수는 판본마다 다르므로, 실제 문서를 인용해야 한다면 원문을 확인해야 한다.
| 품질 특성 | 측정량 예 | 공식 | 단위·범위 | 숫자를 어디서 얻는가 |
|---|---|---|---|---|
| 기능 적합성 | 기능 구현 충족도 | 구현되어 동작하는 기능 수 / 명세된 기능 수 | 0~1 비율 | 요구사항 추적표 + 테스트 실행 결과 |
| 기능 적합성 | 기능 정확성 | 정확한 결과를 낸 케이스 수 / 실행한 케이스 수 | 0~1 비율 | 테스트 관리 도구의 실행 기록 |
| 성능 효율성 | 평균 응답 시간 | 응답 시간 합 / 요청 수 | ms | APM·부하 테스트 도구 리포트 |
| 성능 효율성 | 처리량(Throughput) | 처리 완료 건수 / 측정 시간 | TPS, req/s | 부하 테스트 결과, 서버 메트릭 |
| 성능 효율성 | 자원 사용률 | 사용량 / 가용량 | % | OS·컨테이너 모니터링 지표 |
| 신뢰성 | 평균 무고장 시간(MTBF) | 총 가동 시간 / 고장 횟수 | 시간 | 운영 로그, 인시던트 기록 |
| 신뢰성 | 결함 밀도 | 발견된 결함 수 / 규모(KLOC·기능 수) | 건/단위 | 이슈 트래커 + 규모 산정값 |
| 신뢰성 | 가용성 | 가동 시간 / (가동 + 정지) 시간 | % | 모니터링·SLA 대시보드 |
| 사용성 | 과업 완료율 | 완료한 사용자 수 / 시도한 사용자 수 | 0~1 비율 | 사용성 테스트 세션 기록 |
| 보안성 | 접근 통제 적용률 | 통제가 적용된 자원 수 / 보호 대상 자원 수 | 0~1 비율 | 설계 문서 + 보안 점검 결과 |
| 유지보수성 | 모듈 결합도 관련 지표 | 정적 분석 도구가 산출하는 값 | 도구별 상이 | SonarQube 등 정적 분석 리포트 |
| 이식성 | 설치 성공률 | 성공한 설치 수 / 시도한 설치 수 | 0~1 비율 | 환경별 설치 테스트 기록 |
이 표에서 가장 눈여겨볼 열은 맨 오른쪽이다. 측정량을 정의하는 것보다 그 숫자를 매번 꺼내올 수 있게 만드는 것이 훨씬 어렵다. 공식은 한 줄이면 쓰지만, "명세된 기능 수"를 매 릴리즈마다 같은 기준으로 셀 수 있으려면 요구사항 추적표가 관리되고 있어야 하고, MTBF를 계산하려면 인시던트가 빠짐없이 티켓으로 남아야 한다. 지표를 도입하는 일은 사실상 기록 체계를 정비하는 일 이다.
모듈 6(레슨 5)에서 배운 결함 밀도·결함 탈출률·실패율을 떠올려보자. 그 레슨이 "우리 팀이 릴리즈 판단을 하려고 자체적으로 계산하는 지표"였다면, 25023은 같은 종류의 계산을 국제 규격 위에 올려 제3자와도 말이 통하게 만든 것 이다. 계산식은 놀라울 만큼 비슷하다. 달라지는 건 목적이다 — 내부 의사결정용이냐, 외부 증명용이냐.
지표 하나를 직접 정의해보는 연습
새 지표가 필요할 때 다음 다섯 칸을 채워보면 쓸 만한지 아닌지가 금방 드러난다.
- 이름 — 무엇을 재는지 한 단어로
- 분자(X) — 세려는 대상
- 분모(Y) — 비교 기준이 되는 규모
- 출처 — X와 Y를 각각 어느 시스템에서 뽑는가
- 해석 방향 — 값이 오르면 좋은가 나쁜가, 그리고 얼마부터 문제인가
4번을 못 채우면 그 지표는 "누군가 손으로 세어야 하는 숫자"라는 뜻이고, 손으로 세는 지표는 몇 달 안에 반드시 갱신이 멈춘다. 5번을 못 채우면 숫자는 나오지만 아무도 그 숫자로 결정을 내리지 못한다. 지표를 늘리는 일보다 이 다섯 칸이 다 채워지는 지표를 서너 개 유지하는 일 이 훨씬 가치 있다.
함정 1 — 재기 쉬운 것만 재게 된다
지표를 정하다 보면 어느새 목록이 성능·커버리지 쪽으로 쏠려 있다. 이유는 단순하다. 응답 시간과 테스트 통과율은 도구가 자동으로 뱉어주지만, 사용성이나 유지보수성은 사람이 붙어야 숫자가 나오기 때문이다.
이 쏠림은 조용히 해롭다. 대시보드에 올라간 지표가 곧 팀이 신경 쓰는 품질이 되기 때문이다. 응답 시간만 지표로 걸어두면 팀은 응답 시간만 개선한다. 그 사이 사용자가 화면을 이해하지 못해 이탈하는 문제는 아무 숫자에도 잡히지 않으므로 존재하지 않는 문제처럼 취급된다.
완화하는 방법은 지표를 늘리는 것이 아니다. 25010의 여덟 특성을 체크리스트 삼아 "이 특성은 지금 어떤 숫자로도 관측되지 않는다"는 사실 자체를 명시적으로 적어두는 것 이다. 빈칸을 빈칸으로 남겨두면 최소한 "안 재고 있다"는 것을 팀이 안다. 목록에서 아예 지워버리면 안 재고 있다는 사실조차 잊힌다.
함정 2 — 목표치를 어디서 가져올 것인가
"응답 시간 200ms 이하"라는 목표는 어디서 나왔을까. 실무에서 이 숫자는 너무 자주 회의실에서 즉석으로 만들어진다. 근거로 삼을 수 있는 기준은 보통 세 가지이고, 각각 성격이 다르다.
| 기준 | 어떻게 얻는가 | 강점 | 약점 |
|---|---|---|---|
| 과거 릴리즈 | 직전 버전의 실측값 | 데이터가 이미 있고 조작 여지가 적다 | 과거가 이미 나빴다면 나쁜 상태를 고착시킨다 |
| 경쟁 제품 | 공개 벤치마크, 직접 측정 | 시장에서 통하는 수준을 반영한다 | 측정 조건이 달라 공정한 비교가 어렵다 |
| 사용자 기대 | 사용성 테스트, CS 문의, 이탈 지점 분석 | 실제로 문제가 되는 지점을 짚는다 | 수집 비용이 크고 표본이 편향되기 쉽다 |
셋 중 하나를 고르는 문제가 아니다. 과거 릴리즈로 하한선을 잡고, 경쟁 제품으로 방향을 확인하고, 사용자 기대로 우선순위를 정하는 식으로 겹쳐 쓰는 편이 현실적이다. 중요한 건 목표치 옆에 그 숫자의 출처를 한 줄 적어두는 습관 이다. 출처가 적혀 있으면 나중에 "이거 왜 200ms죠?"라는 질문에 답할 수 있고, 답할 수 있으면 필요할 때 근거를 갖고 바꿀 수도 있다.
모듈 4(레슨 4)에서 "종료 조건은 측정 가능하게 써야 한다"고 배웠다. 25023의 측정량은 그 종료 조건에 그대로 꽂아 넣을 수 있는 형태다. "품질이 안정적일 때 릴리즈한다" 대신 "기능 구현 충족도 1.0, 심각도 높음 결함 잔존 0건, p95 응답 시간 500ms 이하"라고 쓸 수 있게 된다. 두 문장의 차이는 문체가 아니라 판정 가능성 이다.
ISO/IEC 12119 — 검증 대상은 프로그램만이 아니다
ISO/IEC 12119는 "소프트웨어 패키지 — 품질 요구사항 및 시험"을 다룬 규격이다. 1994년 판이며 현재는 폐지(withdrawn)되고 SQuaRE 계열의 ISO/IEC 25051로 이어졌다. 25051은 대상을 RUSP(Ready to Use Software Product), 즉 구매자가 사양에 관여하지 않고 그대로 사서 쓰는 완성품 소프트웨어 로 부른다. 패키지 소프트웨어, 상용 솔루션, 앱스토어에서 내려받는 제품이 여기 해당한다.
이 계열의 핵심 발상은 검증 대상을 셋으로 나눈 데 있다.
- 제품 설명서(product description) — 제품이 무엇을 하는지 구매자에게 알리는 문서. 카탈로그, 제품 소개 페이지, 기능 목록이 여기 해당한다.
- 사용자 문서(user documentation) — 설치·운영·사용 방법을 담은 매뉴얼.
- 프로그램과 데이터 — 실제 실행되는 소프트웨어.
그리고 규격은 이 셋 사이의 일치 를 요구한다. 즉 검사는 "프로그램이 잘 도는가"만 보는 게 아니라 "설명서에 적힌 기능이 실제로 그렇게 되는가" 를 본다. 카탈로그에 "엑셀 내보내기 지원"이라고 적혀 있으면, 시험자는 그 문장을 근거로 엑셀 내보내기를 시도한다. 안 되면 결함이다. 프로그램에 버그가 없어도 설명서가 과장돼 있으면 그 제품은 기준을 통과하지 못한다.
설명서 검증이 왜 QA의 일인가
이 발상은 처음 들으면 낯설다. 매뉴얼은 보통 테크니컬 라이터나 마케팅이 쓰는 문서이고, QA는 프로그램을 본다고 생각하기 때문이다.
그러나 사용자 입장에서 보면 구분이 사라진다. 사용자는 설명서를 읽고 기대를 형성한 다음 제품을 쓴다. 설명서가 실제와 다르면 사용자가 겪는 경험은 버그를 만난 것과 정확히 같다. "제품은 정상인데 문서가 틀렸다"는 구분은 만든 쪽의 사정일 뿐이다. 모듈 1(레슨 1)에서 결함을 "합의된 기대와의 차이"로 정의했던 것을 떠올려보자. 설명서는 그 기대를 만들어내는 가장 공식적인 문서다.
실무에서 이 관점을 도입하면 할 일이 구체적으로 늘어난다.
- 릴리즈 노트·기능 목록에 적힌 문장을 테스트 케이스의 입력으로 삼는다. 문장 하나마다 "이게 실제로 되는가"를 확인한다.
- 매뉴얼의 설치 절차를 적힌 그대로 따라 해본다. 중간에 생략된 단계나 이미 바뀐 화면 이름이 매우 자주 발견된다.
- 스크린샷의 버전을 확인한다. 기능이 바뀌었는데 이미지가 옛것이면 사용자는 화면에서 그 버튼을 찾지 못한다.
이 세 가지는 도구도 필요 없고 준비 시간도 짧은데, 발견되는 문제의 양에 비하면 비용이 거의 들지 않는 편이다.
GS(Good Software)인증 — 국내 상용 소프트웨어의 관문
GS인증은 국내에서 상용 소프트웨어가 받는 품질 인증으로, TTA(한국정보통신 기술협회)를 비롯한 지정 시험기관이 수행한다. 시험 기준은 앞에서 본 ISO/IEC 25023·25041·25051 계열의 국제표준을 기반 으로 삼는다 — 즉 이 레슨에서 다룬 두 축(측정 지표, 설명서를 포함한 패키지 품질 요구사항)이 그대로 심사 항목이 된다.
인증은 1등급과 2등급으로 나뉘며 1등급이 상위 인증이다. 문서 심사만으로 끝나지 않고 실제 운영 환경과 유사한 시험 환경에서 제품을 돌려보는 방식이라는 점이 이 제도의 성격을 잘 보여준다.
기업이 GS인증을 받으려는 동기는 품질 개선 그 자체보다 공공 조달 쪽에 있는 경우가 많다. 공공기관 소프트웨어 사업에서 GS인증 제품에 우대가 적용되는 구조가 있기 때문이다. 다만 우대의 구체적인 형태(가점 배점, 수의계약 가능 여부, 우수제품 지정과의 연계 등)는 제도와 고시가 개정되며 바뀌므로, 실제 사업에 적용하려면 해당 시점의 조달 규정과 공고문을 직접 확인해야 한다. 이 레슨에서 외워둘 것은 배점표가 아니라 "국내 공공 조달 맥락에서 GS인증이 사업 참여 조건에 영향을 준다"는 구조다.
인증 심사에서 실제로 오가는 것
QA 입장에서 준비물은 대체로 세 덩어리다. 정확한 서식과 목록은 시험기관이 안내하므로 신청 전 사전 상담에서 확인하는 것이 정석 이다.
| 덩어리 | 무엇을 준비하는가 | QA가 하는 일 |
|---|---|---|
| 제품과 시험 항목 | 기능 목록, 시험 항목별 절차와 기대 결과 | 기능 목록과 테스트 케이스를 1:1로 맞춰 빠진 기능이 없게 한다 |
| 문서 | 제품 설명서, 설치·사용자 매뉴얼 | 문서의 문장과 실제 동작이 어긋나는 곳을 먼저 잡아낸다 |
| 이력 | 결함 수정 이력, 재시험 결과 | 이슈 트래커 기록이 릴리즈 버전과 맞물리게 정리한다 |
세 덩어리 중 가장 자주 발목을 잡는 건 두 번째 다. 코드는 여러 사람이 계속 손보지만 매뉴얼은 초기 작성 이후 방치되기 쉬워서, 심사 시점에 기능과 문서 사이 간극이 상당히 벌어져 있는 경우가 흔하다. 인증을 준비한다면 문서 점검을 마지막이 아니라 가장 먼저 시작하는 편이 낫다.
세 번째 덩어리는 평소 습관의 결과물이라 벼락치기가 안 된다. 모듈 6에서 배운 결함 리포트 작성과 이슈 트래커 운영이 평소에 되고 있었다면 정리만 하면 되고, 안 되고 있었다면 인증 준비 기간에 몇 달치를 소급해서 만들어야 한다. 인증 준비가 QA 프로세스를 정비하는 계기가 된다는 말은 이런 뜻이다.
인증이 품질을 보장하지는 않는다
마지막으로 균형을 잡자. 인증서는 "정해진 기준을 정해진 시점에 통과했다" 는 증명이지, "좋은 제품"이라는 증명이 아니다. 한계는 분명하다.
- 시점의 문제 — 인증은 특정 버전에 대해 이뤄진다. 그 뒤에 나간 릴리즈의 품질을 인증서가 말해주지는 않는다.
- 기준의 문제 — 통과 기준은 합의된 최소선이다. 최소선을 넘었다는 것과 경쟁 제품보다 낫다는 것은 전혀 다른 이야기다.
- 환경의 문제 — 시험 환경은 실제 운영 환경과 비슷하게 구성하지만 같지는 않다. 인증받은 제품도 특정 고객사 환경에서 얼마든지 문제를 낸다.
그럼에도 인증을 받는 이유는 품질이 아니라 거래 비용 에 있다. 구매자는 공급자의 품질을 스스로 검증할 시간도 전문성도 없는 경우가 대부분이다. 이때 인증은 그 검증을 제3자에게 맡기는 장치, 말하자면 신뢰의 외주화 다. 여기에 조달 요건이 더해지면 인증은 "받으면 좋은 것"이 아니라 "없으면 입찰에 못 들어가는 것"이 된다.
그래서 QA가 취할 태도는 냉소도 맹신도 아니다. 인증은 통과해야 할 관문으로 다루되, 팀 내부의 품질 기준은 인증 기준보다 높게 유지하는 것. 인증 통과가 목표가 되는 순간 팀은 최소선을 향해 최적화하기 시작하고, 그때부터 인증서는 품질의 증거가 아니라 품질을 가리는 가림막이 된다.
실무에서 왜 필요한가
품질을 말로만 설명하는 QA와 숫자로 설명하는 QA는 회의실에서 전혀 다른 무게를 갖는다. "아직 좀 불안합니다"는 반박하기 쉽지만, "기능 구현 충족도 0.92, 미구현 기능 4건 중 2건이 결제 흐름"은 반박하려면 데이터가 필요하다. 25023이 주는 것은 그 문장을 만드는 틀이다.
패키지·솔루션을 파는 회사라면 12119 계열의 관점이 곧바로 일이 된다. 제안서와 카탈로그에 적힌 문장이 실제로 되는지 확인하는 일은 계약 이후 분쟁을 줄이는 가장 값싼 활동이고, 그 일을 할 수 있는 사람은 제품을 가장 넓게 만져본 QA다.
공공 조달을 겨냥하는 국내 소프트웨어 회사라면 GS인증은 언젠가 마주치게 된다. 그때 QA가 "인증 준비는 인증팀 일"이라고 물러서면, 결국 시험 항목과 매뉴얼과 결함 이력을 급하게 만들어내는 일이 QA에게 돌아온다. 평소에 지표와 문서와 이슈 기록을 굴려두면 인증 준비는 정리 작업으로 끝난다.
채용시장에서의 위치
국내 SI·솔루션 업체 채용공고에서 "GS인증 대응 경험"은 드물지 않게 보이는 문구다. 이 문구가 실제로 요구하는 능력은 규격 번호를 외우는 것이 아니라, 기능 목록–테스트 케이스–매뉴얼–결함 이력을 서로 어긋나지 않게 유지해본 경험 이다. 그 경험은 인증을 받아본 적이 없어도 쌓을 수 있다.
면접에서 "품질을 어떻게 측정하셨나요"라는 질문을 받았을 때, 지표 이름과 공식뿐 아니라 그 숫자를 어느 시스템에서 어떤 주기로 뽑았는지, 목표치를 무엇을 근거로 정했는지 까지 말할 수 있으면 답의 층이 달라진다. 이 레슨의 '다섯 칸' 연습이 그대로 답변의 뼈대가 된다.