품질모델·QA·QC·V&V·측정

주문 금액을 바르게 계산하지만 장 시작 직후 응답이 멈추는 시스템을 생각하자. 계산 테스트는 통과했어도 성능과 신뢰성에 문제가 있다. 빠르고 잘 동작하지만 다른 고객의 주문이 보이면 보안 문제가 남는다. 따라서 “테스트를 많이 했다”는 사실과 “필요한 품질을 확보했다”는 판단은 같지 않다.

1. 테스트가 모두 통과했는데 왜 출시할 수 없을까

이번 절은 품질을 나누어 설명하는 모델 → 측정 가능한 요구 → 확인할 증거 → 출시와 개선의 판단을 하나로 연결한다. 먼저 품질모델의 분류와 사례를 배우고, 이어 QA·QC·V&V의 역할을 구분한 뒤 금융 주문시스템의 보증계획을 실제로 작성한다. 마지막에는 기출 연계 문제와 자체 10점·25점 문제를 풀고 부족한 답안을 고친다.

통제와 증거를 되짚는다

자산·위험·통제·증적에서 통제는 위험을 줄이는 조치이며, 증거는 그 조치의 설계와 실제 작동을 확인할 자료라고 배웠다. 이번 절에서는 품질요구를 정하고 어떤 검토·시험·측정이 그 요구를 뒷받침하는지 연결한다.

소프트웨어 품질보증은 합의한 품질요구가 충족될 것이라는 신뢰를 제공하기 위해 필요한 활동을 계획하고, 그 수행과 결과의 증거를 체계적으로 확인하는 품질관리 활동이다. 품질보증(Quality Assurance, QA)은 검사자의 직함이 아니라 활동의 목적을 가리킨다. 위험이 큰 부분은 작성자와 다른 검토자가 확인하도록 설계할 수 있지만, 모든 QA가 반드시 별도 조직에서만 수행된다는 뜻은 아니다. [S4]

예를 들어 주문 금액 요구와 시험 결과의 연결이 끊겼다면 “검사 완료” 표시에 서명하는 대신 어떤 요구가 빠졌는지 찾아 보완해야 한다. 실제 제품이 기준을 충족하도록 검사·수정하는 활동과 그 충족을 신뢰할 수 있도록 계획·증거를 확인하는 활동이 함께 필요하다.

이 절의 전체 지도

품질모델의 이름을 요구와 판단 근거로 연결한다

화살표의 방향과 조건을 따라 연결을 읽습니다.

화살표는 품질요구와 증거의 연결이다. QA는 계획과 증거의 신뢰를 확인하며 출시 권한을 자동으로 얻는 것이 아니다. 제품품질의 9개 주특성·40개 부특성은 아래 상세 표에 그대로 둔다. 운영에서 발견한 변화는 요구·계획도 갱신한다.

화살표는 조직의 지휘 관계가 아니라 요구에서 증거와 판단으로 내려가는 순서다. 모델을 외웠다는 사실만으로 시험 결과나 품질보증이 만들어지지는 않는다.

2. 품질모델: 좋은 제품이라는 말을 작은 질문으로 나눈다

품질모델은 품질을 검토할 관점을 체계적으로 나눈 지도다. 주특성(characteristic)은 신뢰성·보안성처럼 큰 관점이고, 부특성(subcharacteristic)은 그 안에서 별도로 판단할 세부 관점이다. 예를 들어 신뢰성 안에서도 고장 없이 작동하는가, 필요할 때 쓸 수 있는가, 일부 고장을 견디는가, 고장 뒤 되찾는가를 나누어 본다.

ISO/IEC 25010:2023은 소프트웨어를 포함한 정보통신기술 제품의 제품품질 모델을 제시한다. 9개 주특성의 이름을 답안에 쓰는 것과 우리 제품이 그 특성을 만족한다는 증거를 제시하는 것은 별개의 작업이다. 한국어 명칭은 학습을 위한 번역이며 혼동할 수 있는 항목은 영문을 함께 적는다. [S1][S3]

아래 표는 표준의 그림이나 정의문을 복제한 것이 아니다. 공개 표준 미리보기의 실제 수록 범위와 연구자 원문 부록 [S8]의 9개 주특성·40개 부특성 분류를 대조하고, 주문서비스에 적용하는 질문과 사례는 새로 작성했다. [S8]은 연구자료이지 표준 전문이나 공식 한국어 번역이 아니다. 원 표준 전문과 한국어 용어의 독립 대조는 최종 검수에 남긴다.

기능 적합성 (Functional suitability)

필요한 일을 빠짐없이, 바르게, 목적에 맞게 하는가. [S3]

부특성	원어	적용해서 물을 질문
기능 완전성	Functional completeness	주문·정정·취소라는 필요한 업무 중 취소 기능이 빠져 있지 않은지 본다.
기능 정확성	Functional correctness	수량과 단가가 주어졌을 때 금액이 정한 계산·반올림 규칙과 일치하는지 본다.
기능 적절성	Functional appropriateness	이미 확인한 정보를 반복 입력하지 않고 주문 목적을 수행할 수 있는지 본다.

기능이 존재하는지, 결과가 맞는지, 그 기능이 업무 수행에 적절한지를 구분한다. 취소 메뉴가 있다는 이유만으로 취소 금액이 정확하다고 말할 수 없다.

성능 효율성 (Performance efficiency)

정한 자원과 부하에서 얼마나 신속하고 효율적으로 일하는가. [S3]

부특성	원어	적용해서 물을 질문
시간 반응성	Time behaviour	정한 요청 혼합과 부하에서 응답시간·처리율이 요구를 만족하는지 본다.
자원 활용성	Resource utilization	동일 부하를 처리할 때 CPU·메모리·통신 자원의 사용이 정한 한도 안에 있는지 본다.
용량	Capacity	요구한 동시 사용자·거래량·저장량을 처리할 수 있는지 본다.

평균 응답시간 하나만 쓰지 말고 요청 종류·동시성·응답 분포를 붙인다. 현재 구성의 처리 한도를 보는 용량과 부하 변화에 맞추어 그 한도를 조절하는 확장성은 질문이 다르다.

호환성 (Compatibility)

다른 제품과 함께 있어도 일하고 필요한 정보를 주고받는가. [S3]

부특성	원어	적용해서 물을 질문
공존성	Co-existence	같은 장비에서 보고서 작업이 돌아가도 주문 처리가 과도하게 방해받지 않는지 본다.
상호운용성	Interoperability	주문시스템과 결제시스템이 금액·통화·상태의 의미를 일치시켜 교환하고 사용하는지 본다.

공존은 자원을 함께 쓰는 상황이고 상호운용은 교환한 정보를 실제로 이용하는 상황이다. JSON을 전송할 수 있어도 금액의 단위를 다르게 해석하면 상호운용 요구를 만족하지 못한다.

상호작용 역량 (Interaction capability)

다양한 사용자가 제품을 알아보고 배우며 통제할 수 있는가. [S3][S8]

부특성	원어	적용해서 물을 질문
적절성 인지성	Appropriateness recognizability	처음 온 사용자가 이 화면으로 주문을 취소할 수 있다는 것을 알아보는지 본다.
학습성	Learnability	정한 초보 사용자군이 안내를 이용해 첫 주문 방법을 익히는지 본다.
운용성	Operability	사용자가 수량 수정·진행 중 취소처럼 필요한 조작을 제어할 수 있는지 본다.
사용자 오류 방지	User error protection	과도한 수량 입력이나 잘못된 계좌 선택을 확인·제한하는지 본다.
사용자 참여	User engagement	명료한 진행상태와 피드백이 필요한 상호작용을 지속하도록 돕는지 본다.
포용성	Inclusivity	언어·연령·배경 등이 다른 사용자를 처음부터 고려했는지 본다.
사용자 지원	User assistance	시각·청각·조작 능력이나 사용환경의 차이에 맞게 입력·출력·도움을 제공하는지 본다.
자기 설명성	Self-descriptiveness	현재 단계의 의미와 다음 행동을 화면 자체의 적절한 안내로 알 수 있는지 본다.

사용자 지원을 고객센터 전화번호 하나로, 자기 설명성을 긴 매뉴얼의 존재로 축소하지 않는다. 예컨대 음성과 화면의 병행 안내는 능력·환경 차이에 대한 지원이고, 주문이 아직 확정되지 않았음을 바로 알리는 안내는 현재 상태의 자기 설명성을 돕는다.

신뢰성 (Reliability)

정한 조건과 기간에 기능을 지속하고 장애에 대응하는가. [S8]

부특성	원어	적용해서 물을 질문
무결점성	Faultlessness	정상 운영 조건에서 주문 기능이 고장 없이 수행되는지를 본다.
가용성	Availability	사용이 필요한 시간에 주문 기능에 접근해 사용할 수 있는지 본다.
결함 허용성	Fault tolerance	처리 노드 하나가 고장 나도 정해진 기능이 계속 수행되는지 본다.
복구성	Recoverability	장애 뒤 데이터와 업무 상태를 원하는 상태로 회복하는지 본다.

무결점성은 모든 입력·모든 미래 상황에서 버그가 없다는 보증이 아니다. 앞에서 배운 가용성·복구성을 모델의 세부 질문으로 적용하되, 짧은 중단을 빨리 복구하는 것과 중단 자체가 없는 것을 구분한다.

보안성 (Security)

허용된 접근을 지키고 악의적 행위에 대응하는가. [S8]

부특성	원어	적용해서 물을 질문
기밀성	Confidentiality	다른 고객에게 주문·계좌 정보가 노출되지 않는지 본다.
무결성	Integrity	권한 없는 금액·수취인 변경이나 데이터 파괴를 막는지 본다.
부인 방지성	Non-repudiation	주문을 수행했다는 사실을 나중에 부당하게 부인하기 어렵도록 증거를 마련하는지 본다.
책임 추적성	Accountability	어느 주체가 어떤 승인·변경을 수행했는지 유일하게 추적할 수 있는지 본다.
진본성	Authenticity	상대방이나 정보가 주장하는 신원·출처와 일치하는지 확인하는지 본다.
저항성	Resistance	명시한 악의적 공격 상황에서도 운영을 유지하며 방어할 수 있는지 본다.

기밀성과 무결성은 앞서 학습한 보안 목표를 재사용한다. 부인 방지는 모든 로그가 곧 법적 증거가 된다는 말이 아니며, 책임 추적은 익명 공용계정의 접속 기록만으로 달성되지 않는다. 표준 분류에서 가용성은 신뢰성 아래에 있어도 보안 공격이 가용성을 해칠 수 있다.

유지보수성 (Maintainability)

담당자가 제품을 이해하고 안전하게 바꾸기 쉬운가. [S8]

부특성	원어	적용해서 물을 질문
모듈성	Modularity	수수료 규칙 변경이 관련 없는 로그인 기능까지 퍼지지 않는지 본다.
재사용성	Reusability	검증된 금액 계산 부분을 의미가 같은 다른 업무에서도 사용할 수 있는지 본다.
분석성	Analysability	실패 원인·변경 영향·수정할 부분을 진단하기 쉬운지 본다.
변경성	Modifiability	변경이 새로운 결함이나 기존 품질 저하를 만들지 않도록 수행되는지 본다.
시험성	Testability	판정 가능한 기준과 시험을 마련하고 실행하여 요구 충족을 확인하기 쉬운지 본다.

시험성은 테스트 실행 건수 자체가 아니다. 시간을 외부에서 주입해 만료 경계를 재현하거나 상태를 관찰할 수 있게 하는 구조가 시험을 쉽게 만든다. 내부 구조를 바꾸는 유지보수성과 실행·사용 환경 변화에 적응하는 유연성을 구분한다.

유연성 (Flexibility)

요구·사용 맥락·운영환경의 변화에 적응할 수 있는가. [S8]

부특성	원어	적용해서 물을 질문
적응성	Adaptability	다른 운영환경·장비·사용 조건으로 옮길 때 적절히 적응하는지 본다.
확장성	Scalability	부하의 증가·감소에 대응하여 용량을 조절할 수 있는지 본다.
설치성	Installability	정한 환경에서 설치와 제거를 성공적이고 효율적으로 수행하는지 본다.
대체성	Replaceability	같은 목적과 환경에서 기존 제품을 대신할 수 있는지 본다.

서버 두 대를 추가했다는 사실보다 그 뒤 증가한 부하를 요구 품질로 처리했는지가 중요하다. 설치가 성공해도 기존 데이터 형식·외부 계약을 잃으면 대체 가능성이 입증되지 않는다.

안전성 (Safety)

정한 조건에서 사람의 생명·건강, 재산 또는 환경을 위험에 빠뜨리지 않는가. [S3][S8]

부특성	원어	적용해서 물을 질문
운영 제약	Operational constraint	위험한 명령·상태로 들어가지 않도록 허용 운영 범위를 제한하는지 본다.
위험 식별	Risk identification	받아들일 수 없는 피해를 낳을 상황을 식별하는지 본다.
고장 안전	Fail safe	고장 시 피해를 피하거나 줄일 수 있는 상태로 대응하는지 본다.
위험 경고	Hazard warning	대응할 수 있는 시간 안에 받아들일 수 없는 위험을 알리는지 본다.
안전한 통합	Safe integration	다른 구성요소와 결합하는 동안과 결합한 뒤에도 안전을 유지하는지 본다.

보안성은 권한과 공격을 중심으로, 안전성은 피해를 중심으로 질문한다. 공격자가 없어도 단위 변환 오류가 위험한 명령을 만들 수 있다. 고장 안전이 언제나 전원 차단을 뜻하지는 않으며, 멈추는 것과 계속하는 것 중 어느 쪽이 덜 위험한지는 해당 시스템의 피해 분석으로 정한다.

2011판과 2023판을 섞지 않는다

2011판은 제품품질의 8개 주특성과 사용품질 모델을 함께 다뤘다. 2023판은 제품품질 모델이며 사용품질은 ISO/IEC 25019:2023으로 분리되었다. 2023판 머리말은 2011판의 폐지·대체 관계를 밝히며, IEC 발행기관 카탈로그에서도 판본별 범위를 구분할 수 있다. 다만 과거 기출과 교재가 2011판을 전제로 썼다면 그 문맥을 먼저 읽어야 한다. [S1][S2][S5]

아래는 이전 지식을 복습할 때 사용할 2011판 제품품질 목록이다. 2023판의 이름을 이 표에 덧붙여 새로운 8특성 체계를 만들지 않는다.

2011판 주특성	2011판 부특성
기능 적합성	기능 완전성·기능 정확성·기능 적절성
성능 효율성	시간 반응성·자원 활용성·용량
호환성	공존성·상호운용성
사용성(Usability)	적절성 인지성·학습성·운용성·사용자 오류 방지·사용자 인터페이스 심미성·접근성
신뢰성	성숙성(Maturity)·가용성·결함 허용성·복구성
보안성	기밀성·무결성·부인 방지성·책임 추적성·진본성
유지보수성	모듈성·재사용성·분석성·변경성·시험성
이식성(Portability)	적응성·설치성·대체성

2023판에서는 사용성을 상호작용 역량으로, 이식성을 유연성으로 바꾸고 안전성을 추가했다. 신뢰성의 성숙성은 무결점성으로, 사용자 인터페이스 심미성은 사용자 참여로 바뀌었다. 접근성은 포용성과 사용자 지원으로 나뉘며, 자기 설명성·저항성·확장성이 추가되었다. 이는 명칭만 고친 것이 아니라 검토 범위와 정의도 달라지는 개정이다. [S3, 머리말]

문제가 판본을 지정하면 그 판본으로 답한다. 판본을 지정하지 않으면 답안 첫머리에 적용 판본을 밝히고 필요할 때 구판과 달라진 점을 짧게 덧붙인다. 이 방법은 혼용을 피하는 학습용 원칙이며 비공개 채점기준이 어느 판본만 인정한다는 주장이 아니다.

자주 혼동하는 쌍을 작은 사건에 적용한다

한 주문이 두 번 처리되었다면 우선 요구한 결과가 맞는지 기능 정확성을 조사한다. 같은 요청의 재시도 처리, 저장 경계, 외부 결제의 계약은 가능한 원인이다. 화면의 확인 버튼을 바꾸었다는 이유만으로 중복 처리가 제거되지는 않는다.

악의적인 금액 변조는 보안 무결성 문제이고, 정상 사용 중 잘못된 금액을 계산한 것은 기능 정확성 문제다. 같은 사건이 여러 특성에 영향을 줄 수 있으므로 무조건 한 칸만 고르는 시험으로 생각하지 않는다.

안전성의 고장 안전과 신뢰성의 결함 허용성도 다르다. 결함 허용성은 고장 중에도 정해진 기능을 이어가는 쪽을 보지만, 고장 안전은 위험을 줄이기 위해 일부 기능을 정지해야 할 수도 있다. 주문 결과가 불명확할 때 새 주문으로 자동 반복하기보다 결과를 조회하도록 하는 설계는 그 업무의 피해와 가용성을 함께 고려해야 한다.

특성을 측정 가능한 품질요구로 구체화한다

“응답이 빠르다”는 성능 관점이지만 아직 판정할 수 있는 요구가 아니다. 대상 기능·사용자와 환경·자극·기대 반응·측정량·목표·제외 범위를 붙여야 시험할 수 있다. 요구마다 식별자를 붙이고 설계·시험·판정 증거를 연결하는 방식은 NASA의 검증 매트릭스 안내와도 연결된다. 이 절의 식별자와 수치는 자체 교육용이며 NASA 요구나 금융 규정이 아니다. [S6]

아래 예에서 시간은 서버 내부 계산만이 아니라 시험 클라이언트가 제출한 때부터 주문 결과를 받은 때까지 잰다. 실패한 요청을 빠른 요청으로 세거나 표본에서 조용히 제거하지 않는다.

QO 사례: 금융 주문시스템의 요구를 실제로 정한다

가상의 내부 주문시스템 QO를 설계한다. 대상은 로그인한 고객의 주문 접수·결과 조회이며 실제 거래소 체결 시간은 제외한다. 금액은 원 단위의 정수로 표현하고, 요청 식별자는 재시도에도 유지한다. 정상 부하는 초당 200건, 주문접수 70%·결과조회 30%이고 장애시험에서는 노드 한 대를 중단한다. 아래 목표는 설명을 위한 설계 가정이지 실측치·법정 기준·보편적 권고가 아니다.

요구	구체적인 목표	확인할 자료
QO-01 정확성·상호운용성	120개 규칙·경계 사례에서 기대 금액·통화·상태가 모두 일치	계약 버전, 입력·기대값·실제값, 외부 어댑터 결과
QO-02 성능 효율성	정상 부하 10분의 120,000건 중 99% 이상이 2초 이내 정상 결과, 나머지도 실패 여부를 별도 보고	동일 환경·요청 혼합의 시간과 응답 상태 원자료
QO-03 신뢰성	노드 한 대 중단 뒤 60초 이내 접수 재개, 이미 확정한 주문의 누락·중복 0건	장애 시점, 복구 시점, 주문 식별자별 원장 대조
QO-04 보안성	다른 고객의 조회·취소 40개 사례를 모두 거부하고 주문 상태도 불변	권한 행렬, 응답·상태·감사기록
QO-05 상호작용 역량	지정한 초보 사용자 12명 중 11명 이상이 안내 후 도움 없이 결과불명 주문의 상태를 확인	과업 시나리오, 관찰 기록, 막힌 지점
QO-06 유지보수성·유연성	외부 어댑터 교체 시 주문 규칙 모듈은 수정하지 않고 QO-01·03을 재통과	코드 차이, 계약 버전, 설치·회귀시험 증거

품질모델의 모든 관점을 검토하되, 이 작은 표가 9특성의 모든 부특성을 측정한다는 뜻은 아니다. 안전성은 결과불명 주문을 무조건 재발행할 때 생길 피해를 검토하고 조회·제한·운영자 경고를 설계한다. 이 사례만으로 특정 금융시스템의 안전 적합성을 인증할 수는 없다.

수치 판단을 끝까지 해 본다

QO-02의 전체 시도는 200건/초 × 600초 = 120,000건이다. 2초 이내 정상 결과가 118,900건이면 118,900 / 120,000 × 100 ≈ 99.083%로 그 목표는 충족한다. 118,700건이면 약 98.917%이므로 충족하지 못한다. 응답시간이 짧아도 오류 응답이면 분자에 넣지 않는다.

QO-03에서 중단 후 45초에 접수가 재개되었지만 이미 확정한 주문 한 건이 없다면 시간 목표만 통과한 것이다. 복구를 통과로 처리하지 않고 주문 대조와 원인 수정을 마칠 때까지 보류한다. 성능 목표 통과도 이 데이터 누락을 상쇄하지 못한다.

QO-05의 11/12는 해당 참여자와 과업의 관찰 결과일 뿐 모든 사용자에게 같은 성공률을 보장하지 않는다. 모집단으로 일반화할 근거와 더 넓은 사용자 검증은 따로 필요하다.

QO-M: 전체 비율이 높은데 주문 접수는 기준보다 낮다면

위 118,900건을 기능별로 나눈 별도 교육용 상세표를 보자. 120,000건의 요청을 중복 없이 주문 접수 84,000건과 결과조회 36,000건으로 나누면 원래 70/30 혼합과 일치한다. 각 요청의 기능 분류와 결과·시간 기록은 완전하다고 가정한다. 아래의 미충족은 2초 초과 또는 정상 결과가 아닌 요청이며, 지연과 오류의 세부 수는 이 표에 주어지지 않았다.

기능	전체 시도	2초 이내 정상 결과	미충족	기능별 충족률
주문 접수	84,000	82,950	1,050	98.750%
결과조회	36,000	35,950	50	약 99.861%
합계	120,000	118,900	1,100	약 99.083%

전체 충족률은 (82,950 + 35,950) / (84,000 + 36,000) × 100으로 계산한다. 주문과 조회의 시도 수가 다르므로 두 비율의 단순 평균 약 99.306%를 전체 비율로 쓰면 안 된다. 비율로 계산하려면 각각의 요청 비중을 곱하여 0.70 × (82,950/84,000) + 0.30 × (35,950/36,000)으로 합친다.

원래 QO-02는 지정한 70/30 혼합의 전체 99%를 요구했으므로 이 표는 기존 QO-02를 충족한다. 그러나 ‘모든 기능이 각각 99% 이상’이라는 결론은 틀리다. 주문 접수는 98.75%다. 기존 요구에 없던 기능별 기준을 사후에 끼워 넣어 종전 판정을 실패로 덮어쓰는 것과, 주문 과업의 위험 때문에 추가 요구를 검토하는 것은 구별해야 한다.

업무 책임자가 주문 접수에도 별도 99% 목표가 필요하다고 판단하면 변경 요구 QO-02a에 대상·같은 2초 경계·전체 주문 시도 분모·시험 혼합·적용 버전을 명시한다. 시험 책임자는 기존 원자료가 그 조건을 만족하는지 검토하고 부족한 조건은 새로 시험한다. QA는 기존 QO-02 결과와 새 요구의 증거를 따로 연결하며, 출시 책임자는 주문 지연의 영향과 미해결 항목을 보고 판단한다. 원래 요구의 Verification 통과와 그 요구가 실제 업무에 충분한지 확인하는 Validation은 이렇게 다른 결론을 낼 수 있다. 99%라는 값은 이 연습의 선택이지 표준이 요구한 기능별 수치가 아니다.

다음에는 주문/조회 비중만 90/10으로 바뀌고, 두 기능의 충족률은 위와 같다고 가정해 보자. 계산은 0.90 × 0.9875 + 0.10 × (35,950/36,000) ≈ 0.988611로 전체 약 98.861%다. 기능별 수치는 같아도 요청 구성의 변화만으로 전체 99% 아래가 된다. 반대로 혼합을 바꾸어 전체 비율을 높였다고 주문 기능 자체가 개선된 것도 아니다.

이 마지막 계산은 요청 비중에 대한 민감도 계산이다. 실제 부하 혼합이 바뀌면 자원 경합과 기능별 성능도 달라질 수 있으므로 90/10 조건의 실측 성능이나 시험 실패 결과로 기록하지 않는다. 판단 산출물에는 기존 혼합의 결과표, 기능별 미충족, 바뀐 업무 혼합의 가정, 변경 요구와 재시험 범위를 함께 남긴다. 확인하지 않은 오류 종류·원인·사용자 피해는 총 미충족 수에서 임의로 만들어 내지 않는다.

3. QA·QC·V&V: 조직 이름이 아니라 질문을 구분한다

품질관리(Quality Management)의 여러 활동 중 품질보증(QA)은 요구 충족에 대한 신뢰를 제공하는 데 초점을 두고, 품질제어(Quality Control, QC)는 품질요구를 충족시키는 활동에 초점을 둔다. 국내 문헌에서 QC를 품질관리로 번역하기도 하므로 상위 품질관리와 혼동하지 않게 약어를 붙인다. 계획·예방은 QA, 검사·시정은 QC의 대표 예지만 과정/제품 또는 예방/검출로 완전히 배타적인 집합을 만들지 않는다. QA의 목적은 [S4], 품질제어·인수 기준의 역할은 [S3] §1을 참고한 교육용 구분이다.

검증·확인·운영 피드백에서 검증(Verification)은 정해진 요구와의 부합, 확인(Validation)은 의도된 사용과 필요의 충족을 묻는다고 배웠다. 같은 문서 검토나 시험도 어느 질문을 확인하는지에 따라 역할이 달라진다. Validation을 개발 마지막의 사용자 시험에만 제한하지 않는다. 요구를 정할 때 사용자의 실제 과업과 맞는지 확인할 수도 있다. [S7]

관점	QO에서 하는 일	결과물
QA	QO-01~06에 필요한 검토·시험·변경 통제가 계획되고 누락 없이 실행되는지 점검	보증계획, 누락 목록, 증거 검토, 출시 권고
QC	금액·권한·복구 시험을 수행하고 실패 제품을 시정·재시험	실제 결과, 결함 기록, 시정·재시험 결과
Verification	정한 단위·권한·복구 요구대로 구현했는지 확인	요구별 시험과 코드·설계 검토
Validation	결과불명 화면이 고객의 중복 제출을 막고 과업을 돕는지 확인	업무 시나리오, 실제 사용 관찰, 요구 수정

QC는 테스트팀만의 일도 아니며 QA가 결함수정 책임을 대신 가져가는 것도 아니다. 활동을 누가 맡을지와 최종 위험수용 권한은 별도로 정한다.

QA-1: 커버리지 90%인데 요구변경이 누락된 경우

코드 커버리지는 실행된 코드의 범위를 보는 지표이지 그 코드가 모든 올바른 업무를 한다는 증거는 아니다. 취소 허용시점이 바뀌었는데 요구·시험 기대값은 옛 버전이라면 실행률이 높아도 새로운 요구의 검증은 빠져 있다.

QA 담당자는 요구 변경과 시험의 추적 누락을 기록하고, 개발·시험 담당자는 바뀐 규칙과 경계 사례를 반영하여 QC와 Verification 증거를 다시 만든다. 사용자의 실제 취소 과업에 맞는 규칙인지 의문이 생기면 업무 담당자와 Validation도 다시 수행한다.

테스트·리뷰·감사를 이름만으로 합치지 않는다

테스트는 실행 결과를 관찰하는 데 유용하고, 리뷰는 요구·설계·코드의 모순을 실행 전에 찾을 수 있다. 감사는 정한 절차나 기준이 지켜지는지 그 증거를 점검한다. 같은 요구를 여러 방법으로 볼 수 있지만 한 방법의 통과를 나머지 방법의 수행으로 기록하지 않는다.

4. 품질측정: 제품 결과와 과정의 증거를 나란히 본다

제품의 응답시간과 무단 조회 차단 결과는 제품의 품질에 관한 자료다. 요구변경 반영률과 검토 누락은 과정을 관리하는 자료다. 좋은 과정이 무결점 제품을 보장하지 않고, 한 번 우연히 성공한 제품도 반복 가능한 과정을 보장하지 않는다.

제품품질과 사용품질도 구별한다. 결과불명 상태를 명료하게 표시하는 제품의 능력과, 실제 사용자·과업·환경에서 혼란 없이 주문을 마치는 결과는 관련되지만 같다고 할 수 없다. ISO/IEC 25010:2023과 ISO/IEC 25019:2023의 구분을 유지한다. [S1][S5]

QA-2: 결함 수를 줄여도 비율은 그대로일 수 있다

릴리스 A는 변경 1,000건에서 결함 20건, B는 변경 500건에서 결함 10건이라고 하자. 변경 100건당 결함은 둘 다 2건이다. 다만 변경 한 건의 규모·위험이 같다는 보장이 없으므로 이 단순 정규화만으로 두 릴리스의 품질이 동일하다고 결론 내리지 않는다.

결함 심각도, 사용자 영향과 검출되지 않은 결함 가능성을 함께 본다. 결함 건수를 성과목표로 압박하여 보고를 늦추게 만들면 숫자는 좋아져도 품질정보는 나빠질 수 있다.

지표 정의서에 숫자와 다음 행동을 함께 적는다

측정값·지표·목표·기준선에서 배운 측정값·지표·기준선·목표를 QO에 적용한다. 분자·분모, 단위, 기간, 자료원, 제외 규칙, 기준선과 책임자가 같은 정의를 써야 비교가 가능하다. 기준선은 관찰한 기존 상태이고 목표는 앞으로 충족하기로 정한 조건이므로 가상의 목표를 실측 기준선처럼 쓰지 않는다.

QO-02는 전체 시도 중 2초 이내 정상 응답 비율, QO-03은 복구 시간과 확정 주문의 보존, QO-04는 무단 접근의 거부와 상태 불변을 함께 본다. 시험 담당자는 원자료를 남기고 운영 담당자는 같은 정의로 관측한다. 목표 미달이면 원인·수정 책임·재시험 범위를 정하고 통과 때까지 출시 판단을 보류한다.

종합 90점으로 치명적 결함을 덮지 않는다

응답시간과 화면 평가가 우수해도 다른 고객의 주문을 취소할 수 있다면 평균 점수로 상쇄할 수 없다. 이 사례에서는 무단 주문 변경과 확정 주문의 누락·중복을 출시 차단 조건으로 정한다. 모든 현실의 제품에 같은 임계값을 강요한다는 뜻이 아니라, 감수할 수 없는 피해는 합산 점수와 분리해야 한다는 판단이다.

5. QO의 품질보증 계획을 완성한다

먼저 범위·위험을 QO-01~06 요구로 구체화하고 각 요구에 확인 방법과 책임자를 붙인다. 그다음 설계·구현·시험·업무 확인을 연결하고 변경 후 어느 증거를 다시 만들어야 하는지 정한다. 요구와 시험을 연결한 표는 시험 건수를 늘리기 위한 표가 아니라 요구 누락을 찾는 지도다.

단계	이 사례에서 정한 활동	산출물·판정
요구·계획	업무 담당자와 주문 결과·단위·부하·장애 경계를 합의	QO 요구 목록, 보증계획, 위험·가정 목록
설계·구현	금액 단위와 재시도 식별자 계약을 검토하고 변경 영향 분석	계약·설계 버전, 검토 이슈, 코드 변경 연결
검증·확인	금액·성능·권한·복구 시험과 초보 사용자 과업 관찰	요구별 원자료·판정, 실패 재현, 사용자 혼동 기록
결함·출시	요구별 미달·예외와 필수 차단 조건을 검토	수정 책임·기한·재시험, 보류 또는 조건부 권고
운영·개선	실제 사건·지표·사용자 혼동을 같은 요구로 되돌림	운영 원인 분석, 개선 요구, 회귀시험 추가

표의 내용은 아직 수행한 결과가 아니라 작성한 계획이다. “실행 예정”과 “실행·검토 완료” 상태를 구분해야 보증 증거가 과장되지 않는다.

요구 하나의 변경을 끝까지 추적한다

계약 v2 변경은 v1의 시험 통과를 그대로 물려받지 않는다

화살표의 방향과 조건을 따라 연결을 읽습니다.

첫 행은 QO-01 금액·통화 요구의 기존 v1 연결이고 둘째 행은 v2 변경의 영향이다. 120개 경계 사례의 존재는 새 계약의 적합 증거를 자동으로 만들지 않는다. QA의 확인과 최종 출시 판단은 별도 책임으로 유지한다.

계약 버전이 바뀌면 이전 시험이 무엇을 확인했는지 다시 판단한다. 새 버전과 무관한 시험은 근거를 남겨 재사용할 수 있지만, 기대 금액·단위가 바뀐 시험 결과까지 그대로 통과 처리할 수는 없다.

책임과 출시 권한을 실제로 나눈다

QO의 업무 책임자는 요구와 업무 위험수용을, 개발 책임자는 구현·시정을, 시험 책임자는 시험·원자료를 맡는다. QA 검토자는 요구 누락·증거 적합성·미해결 위험을 검토해 출시를 권고하며 자기 코드의 증거를 혼자 승인하지 않는다. 최종 출시 책임자는 그 권고와 미해결 항목을 보고 승인 또는 보류한다.

무단 변경이나 확정 주문 누락은 이번 계획에서 예외 승인하지 않는 차단 조건이다. 낮은 위험의 도움말 표현 결함만 제한 사용자·담당자·만료일·재확인 조건을 붙여 예외를 검토한다. 인원이 적어 역할을 겸하더라도 작성과 확인의 이해상충, 근거, 결정권을 감추지 않는다.

두 대안 중 어떤 것을 택했는지 밝힌다

전체 시스템 시험만 수행하는 안은 현실성이 높지만 실패 원인을 좁히기 어렵고 반복 비용이 크다. 따라서 금액·권한 규칙은 작은 단위에서 빠르게 확인하고, 외부 단위·재시도 계약은 통합시험으로, 노드 중단과 종단 응답은 시스템시험으로 확인하는 안을 택한다. 실제 사용자 과업은 별도의 Validation으로 남긴다.

주문 결과를 알 수 없을 때 즉시 새 식별자로 반복 제출하는 안은 응답 성공률을 높여 보일 수 있지만 중복 처리 위험이 있어 기각한다. 동일 식별자의 결과 조회를 우선하고, 조회도 불가능한 상태는 처리 중·결과불명으로 표시하며 운영 확인으로 넘긴다. 안전·정확성과 가용성 사이의 대가를 숨기지 않는다.

QA-3: 실제 판정 기록을 읽어 본다

가상 시험에서 QO-01은 120/120, QO-02는 118,900/120,000, QO-04는 40/40이고 QO-03은 45초 복구·확정 주문 1건 누락이라고 하자. 앞의 세 결과가 기준에 맞아도 QO-03은 실패다. 개발 책임자가 누락 원인을 수정하고, 시험 책임자가 장애·재시도·원장 대조를 재수행한 증거를 QA가 확인하기 전에는 출시를 보류한다.

누락 원인이 공급자 응답 형식 변경이라면 공급자 계약과 단위·상태 해석까지 영향 범위를 확장한다. “총 통과율이 높다”라는 문장으로 실패 요구를 숨기지 않는다.

공급자와 운영 결과를 같은 요구에 연결한다

외부 결제 어댑터는 계약 버전·금액 단위·상태 코드·시간초과·재시도·변경 통지 조건을 확보한다. 공급자의 시험 성적서가 있어도 우리 환경의 QO-01·03 상호작용을 대신하지는 못한다. 접속 경계와 가상 장애를 포함한 내부 수용시험으로 확인한다.

운영에서 새 지연·중복·사용자 혼동이 생기면 사건을 관련 QO 요구와 연결한다. 운영 책임자는 영향과 원인을 기록하고 업무 책임자는 요구를, 개발·시험 책임자는 설계와 회귀시험을 수정한다. QA는 변경이 실제 증거로 다시 확인되었는지 점검한다.

보증계획과 실행 결과를 구별한다

지금 이 교재가 제공한 것은 가정 아래 작성한 계획과 예시 판정이다. 실제 서비스가 통과했다거나 기관이 승인했다는 주장이 아니다. 시험 환경·판본·기간·관찰 대상이 달라지면 어떤 결론을 유지할 수 있는지 다시 확인한다.

공식 범위 연결 — IT품질 보증

IT품질 보증의 학습 요구를 품질기준·역할·검토·V&V·측정·변경과 결함의 추적으로 구체화한다. QO 사례에서 요구별 목표, 확인 방법, 서로 구분되는 책임, 출시 차단과 재시험을 설명할 수 있어야 한다. 공식 범위에 이름이 연결되었다는 사실만으로 이론이나 답안이 완성되지는 않는다.

출처와 적용 경계

정보 확인일은 2026-09-12다. [S1]과 [S2]는 발행기관의 판본·범위 안내이며 상세 조문 전체를 읽은 증거로 쓰지 않는다. [S3]은 ISO/IEC 원 출판물의 11쪽 공개 미리보기 PDF다. 머리말·범위·용어 §3.1~§3.4.4까지만 직접 확인했으며 §3.5~§3.9가 포함된다고 표시하지 않는다. 그 밖의 세부 분류는 연구자가 공개한 [S8]의 원문 표와 대조했다. [S4]는 QA의 목적을 지원하며 QC와의 사례 비교는 품질요구·판정기준에 대한 [S3] §1의 설명과 함께 구성했다. 공개 미리보기 밖의 전문 전체와 한국어 번역 명칭에 대한 독립 대조, 권리 검토는 최종 검수에 남아 있다. 본문의 사례·수치·설계·도식·답안·평가기준은 교육용 자체 작성이며 표준의 공식 예시·인증기준·채점표가 아니다.

[S1] ISO/IEC, ISO/IEC 25010:2023, edition 2, 2023-11. 제품품질 범위·9특성 및 판본 안내. https://webstore.iec.ch/en/publication/90024
[S2] ISO/IEC, ISO/IEC 25010:2011. 구판의 제품품질·사용품질 범위와 폐지·대체 관계. https://webstore.iec.ch/en/publication/11245
[S3] ISO/IEC, ISO/IEC 25010:2023 공개 미리보기, 머리말, §1, §3.1~§3.4.4. 표준 원문 공개 부분. https://cdn.standards.iteh.ai/samples/78176/13ff8ea97048443f99318920757df124/ISO-IEC-25010-2023.pdf
[S4] NIST CSRC Glossary, quality assurance, NIST SP 800-160v1r1과 ISO 9000:2015를 출처로 표시한 QA 정의. https://csrc.nist.gov/glossary/term/quality_assurance
[S5] ISO/IEC, ISO/IEC 25019:2023, 사용품질 모델 범위. https://webstore.iec.ch/en/publication/90105
[S6] NASA, Appendix D: Requirements Verification Matrix, 요구 식별자·출처와 검증 연결. https://www.nasa.gov/reference/appendix-d-requirements-verification-matrix/
[S7] NASA Software Engineering Handbook Ver D, SWE-055 — Requirements Validation, 의도된 사용과 요구 확인. https://swehb.nasa.gov/spaces/SWEHBVD/pages/102695440/SWE-055%2B-%2BRequirements%2BValidation
[S8] Research authors, EVSE software quality taxonomy supplement, Table I, PDF 1~3쪽. 분류 교차대조용 연구 원문이며 표준 전문을 대신하지 않는다. https://zenodo.org/records/14758339

기출 연결의 보존 자료는 work/qnet/raw/round_140.pdf의 첫 페이지 5번과 work/qnet/text/pdf/round_140.txt다. 기출 원문의 요구와, 적용 판본을 명시하여 만든 아래 자체 문제를 구분한다. 기준답안·채점기준을 확인한 것으로 표시하지 않는다.

6. 여기까지의 결론

품질모델은 무엇을 볼지 나누고, 품질요구는 어떤 조건에서 무엇을 만족할지 정하며, 시험·검토·사용 확인은 그 증거를 만든다. QA는 그 요구 충족을 신뢰할 수 있는지 확인하고 QC는 충족을 위한 실제 활동을 수행한다. 판본·조건·미해결 위험을 생략하면 특성 목록과 높은 통과율도 잘못된 결론으로 이어질 수 있다.

7. 기출 요구를 본문과 연결하기

ISO/IEC 25010:2023의 제품품질 주특성과 부특성을 설명하고 적용 시 유의사항을 제시하시오.

보존된 제140회 1교시 5번은 “ISO/IEC 25010의 주특성 및 부특성”을 요구한다. 위 문제는 그 학습 요구에 판본과 적용 질문을 명시한 자체 제작 문제다. 원문에 2023판이 지정되어 있었다는 뜻이 아니다.

먼저 모델·판본을 한 문장으로 정하고, 주특성별로 부특성을 대응시킨 뒤 짧은 적용 예로 마무리한다. 본문의 아홉 주특성 사례는 각 이름의 뜻을 이해하는 데 쓰고, 시험 문장에서는 질문이 요구한 분류와 관계를 먼저 쓴다. 아래는 완전한 목록을 확인하는 교육용 답안이며 실제 필기시간에 맞추어 표의 간격·표현을 연습해야 한다.

이 문제 풀이와 답안 구성 보기

답안 목차

모델의 목적과 2023판
9개 주특성과 부특성 대응
사례와 판본·측정 조건

답안의 분류·요구 연결

제품품질모델의 9개 주특성과 40개 부특성은 2023 모델 표와 아래 완성 답안의 목록으로 확인한다. 분류 이름을 조건·목표·증거가 있는 품질요구로 바꾸어야 판단할 수 있다.

교육용 완성 답안

ISO/IEC 25010:2023은 정보통신기술 제품의 품질을 9개 주특성과 세부 부특성으로 나누는 제품품질 모델이다. 적용 조건과 사용 목적에서 품질요구와 평가 관점을 도출하는 데 사용한다.

주특성	부특성
기능 적합성	기능 완전성·기능 정확성·기능 적절성
성능 효율성	시간 반응성·자원 활용성·용량
호환성	공존성·상호운용성
상호작용 역량	적절성 인지성·학습성·운용성·사용자 오류 방지·사용자 참여·포용성·사용자 지원·자기 설명성
신뢰성	무결점성·가용성·결함 허용성·복구성
보안성	기밀성·무결성·부인 방지성·책임 추적성·진본성·저항성
유지보수성	모듈성·재사용성·분석성·변경성·시험성
유연성	적응성·확장성·설치성·대체성
안전성	운영 제약·위험 식별·고장 안전·위험 경고·안전한 통합

예를 들어 주문 결과를 정해진 부하에서 2초 이내 받도록 하는 것은 성능 효율성의 시간 반응성 요구이며, 부하 변화에 맞추어 용량을 조절하는 것은 유연성의 확장성 관점이다. 2011판의 사용성·이식성 및 8특성 목록과 혼용하지 않고 적용 판본과 측정 조건을 밝힌다.

독립 연습 — 빠르게 복구한 주문 한 건이 사라졌다면

다음은 본문 사례의 조건을 적용하거나 바꾼 자체 연습이다. 먼저 판단과 근거를 적고 풀이를 펼친다.

QA-3의 QO-01은 120/120, QO-02는 118900/120000, QO-04는 40/40이다. QO-03은 45 초에 처리를 재개했지만 확정 주문 1 건이 돌아오지 않았다. 원래 QO-03은 60 초 이내 재개와 확정 주문 유실·중복 0 건을 함께 요구한다.

각 요구의 충족을 나누어 판정하라.
QA 출시 보류 문장에 부족한 증거·보완 담당·재검증 조건을 적어라.

풀이와 오답 교정 보기

QO-01과 QO-04는 해당 사례의 일치 및 거부·주문상태 불변 증거가 유효하다는 원래 조건에서 충족이다. QO-02는 118900/120000≈99.0833%로 99% 이상이다. QO-03은 시간 45≤60을 충족해도 유실 1 건 때문에 미충족이다. 개발 책임자가 원인을 조사하고 누락 주문 보전·복구 경로를 보완한다. 시험 책임자는 장애·재시도·원장 대조를 다시 수행하여 시간과 주문 무결성을 함께 재검증하고, QA 담당이 증거를 확인할 때까지 출시를 보류한다. 통과한 다른 수치가 주문 유실을 상쇄하지 않는다.

60 초만 읽었다면 QO의 요구 묶음, 충족률로 유실을 덮었다면 QA-3 판정에서 조건별 보고로 바꾼다.

8. 자체 10점 문제: 보증과 검증의 차이

소프트웨어 품질보증의 개념을 설명하고 QA, QC, Verification, Validation의 차이와 품질측정의 역할을 비교하시오.

정의 뒤 네 관점을 같은 질문·증거 축으로 비교한다. 하나의 주문 사례에서 활동이 어떻게 달라지는지 쓰면 조직명이나 예방/검출 두 단어만 적는 답안을 피할 수 있다.

이 문제 풀이와 답안 구성 보기

답안 목차

품질보증의 목적
QA·QC의 활동과 증거
Verification·Validation의 판단 대상
측정 조건과 개선

답안의 분류·요구 연결

연결	확인할 질문
품질요구 → 수행·시정(QC) → 결과 증거	검증과 사용 확인을 통해 요구를 충족했는가
QA의 계획·증거 확인	요구·수행·결과를 믿을 근거가 마련됐는가

QA는 QC 앞뒤의 계획과 증거를 함께 확인한다. QA·QC와 검증·사용 확인은 서로 배타적인 단계나 부서 이름으로 고정하지 않는다.

교육용 완성 답안

소프트웨어 품질보증은 합의한 품질요구의 충족을 신뢰할 수 있도록 활동을 계획하고 수행·결과의 증거를 체계적으로 확인하는 활동이다.

구분	판단과 사례
QA	요구별 검토·시험·변경 통제가 계획대로 수행되었는지와 증거 누락을 확인한다.
QC	금액·권한·복구 시험으로 요구 충족을 확인하고 실패 제품을 시정·재시험한다.
Verification	금액 단위·권한·복구가 명시한 요구대로 구현되었는지 확인한다.
Validation	결과불명 주문의 안내가 실제 고객의 과업과 중복 제출 방지에 적합한지 확인한다.

QA/QC와 V&V는 같은 활동을 다른 목적에서 볼 수 있으며, 조직명이나 개발 단계로 완전히 분리하지 않는다. 측정에는 대상·환경·기간·분모와 목표를 붙이고 미달 요구의 수정 책임과 재확인 방법을 연결한다. 높은 종합 통과율로 무단 변경이나 확정 주문 누락을 상쇄하지 않고, 운영 결과를 요구·시험·보증계획에 되돌린다.

9. 자체 25점 문제: 계획이 아니라 설계 결과를 쓴다

금융 주문시스템의 품질보증 체계를 수립하려 한다. 품질특성, QA/QC, V&V, 품질측정, 변경·결함·예외 추적, 독립성, 공급자 증거와 운영피드백을 포함한 품질보증 방안을 설계하시오.

문제가 실제 수치와 조직을 주지 않았으므로 가정을 먼저 밝힌다. 요구를 나열하는 대신 본문의 QO 사례에서 목표·책임·증거·실패 판정을 가져와 하나의 계획으로 연결한다. 이 답안은 가정 아래 완결된 작성 예이며 유일한 정답이나 공식 채점표가 아니다. 실전에서는 핵심 표와 판단을 먼저 쓰고 설명을 시간에 맞추어 압축하되 필수 요구를 삭제하지 않는다.

이 문제 풀이와 답안 구성 보기

답안 목차

서비스 경계와 측정 가능한 품질목표
QA/QC 책임·독립성과 V&V
요구·변경·결함 추적과 출시 판정
공급자·기각 대안·운영피드백

답안의 분류·요구 연결

품질 증거 연결 그림의 요구·확인·QA·판단·운영 피드백을 답안에 다시 사용한다. QO 요구·목표에 맞춰 설계·구현 → 검증·실사용 확인을 수행하고, QA가 증거와 예외를 검토한 뒤 권한 있는 출시·보류 판단으로 연결한다. 운영 개선은 다음 요구·목표에 반영한다.

교육용 완성 답안

1. 범위와 품질목표. 금융 주문시스템 QO의 접수·결과 조회를 대상으로 하며 실제 거래소 체결시간은 제외한다. 다음 목표는 교육용 설계 가정이다.

품질관점	선택한 목표·확인 방법
정확성·상호운용성	원 단위 정수 금액·통화·상태의 계약을 고정하고 금액·경계 120개 사례를 대조한다.
성능 효율성	초당 200건, 접수/조회 70/30, 10분의 120,000건 중 99% 이상이 2초 이내 정상 결과를 받게 한다.
신뢰성	노드 한 대 중단 뒤 60초 안에 접수를 재개하고 확정 주문의 누락·중복은 0건이어야 한다.
보안성	타 고객 조회·취소 40개 사례를 거부하고 상태가 바뀌지 않아야 한다.
상호작용 역량	초보 사용자 12명 중 11명 이상이 도움 없이 결과불명 주문 상태를 확인하도록 한다.
유지보수성·유연성	어댑터 교체 때 주문 규칙 모듈을 수정하지 않고 금액·복구 회귀시험을 재통과한다.

2. 역할과 V&V. 업무 책임자가 요구·업무 수용을, 개발 책임자가 구현·시정을, 시험 책임자가 원자료·재시험을 맡는다. QA는 요구와 검토·시험 증거의 적합성·누락을 확인해 출시를 권고하고 최종 출시 책임자가 승인·보류한다. 금액 단위와 권한 규칙의 부합은 Verification으로, 실제 고객이 결과불명 상황을 올바르게 이해하는지는 Validation으로 확인한다. QA/QC를 별도 부서의 이름이나 예방/검출의 완전한 이분법으로 보지 않는다.

3. 추적과 판정. QO 요구 식별자–계약·설계 버전–코드 변경–시험 사례–결과–결함을 연결한다. 계약 변경은 영향 분석 후 관련 기대값·시험·증거를 갱신한다. 성능은 118,900/120,000이면 약 99.083%로 목표를 만족하지만, 복구가 45초여도 확정 주문 한 건이 누락되면 출시를 보류한다. 개발자가 수정하고 시험 담당자가 장애·재시도·원장 대조를 재수행한 증거를 QA가 확인한다. 무단 변경과 확정 주문 누락·중복은 차단 조건이며 낮은 위험의 표현 결함만 책임자·만료일·재확인 조건을 붙여 예외를 검토한다.

4. 공급자·대안·개선. 외부 어댑터의 통화·단위·상태·시간초과·재시도와 변경 통지 조건을 계약 버전으로 관리하고 내부 수용시험을 수행한다. 전체 시스템 시험만 하는 안 대신 규칙은 단위, 외부 계약은 통합, 종단 성능·장애는 시스템 시험으로 나누어 반복 비용과 현실성을 함께 확보한다. 결과불명 주문을 새 식별자로 무조건 재발행하는 안은 중복 위험으로 제외하고 기존 결과 조회와 운영 확인을 택한다. 운영 사건은 해당 QO 요구와 연결해 설계·시험·보증계획을 수정한다. 미검증 조건과 실제 사용자 일반화의 한계는 별도로 보고한다.

10. 혼자 답안을 고치는 방법

부족한 답안: “ISO 25010은 8개 특성이다. 안전성을 포함한다. QA는 예방, QC는 검출이며 모든 시험이 통과하면 출시한다. 성능목표와 책임체계를 수립한다.”

첫 문장은 판본과 목록이 섞였다. 이 절에서 2023판을 택했다면 9특성으로 쓰고, 2011판을 설명한다면 안전성을 그 목록에 끼우지 않는다. 둘째 문장은 대표 활동을 배타적인 정의로 바꿨다. 셋째 문장은 누가 어떤 요구를 확인했는지 없으며 시험통과를 사용 적합성과 전체 보증으로 확대했다. 마지막 문장은 설계 결과가 아니라 해야 할 일의 지침이다.

수정 예: “2023판 제품품질 모델을 기준으로 한다. QO의 정상 부하 10분 120,000건 중 99% 이상이 2초 이내 정상 결과를 받는 것을 목표로 정한다. 시험 담당자가 원자료를 남기고 QA가 요구별 증거와 미해결 위험을 확인한다. 노드 복구가 60초 안이어도 확정 주문이 누락되면 출시를 보류하고 대조·재시험한다.”

수정 예는 전체 답안을 대신하는 축약본이 아니라 위 결함을 고친 부분이다. 보안·사용자 확인·공급자·개선 등 원래 문제의 다른 요구는 완성 답안처럼 추가해야 한다.

자기점검 질문	부족하면 돌아갈 곳
판본과 주특성·부특성의 대응이 일치하는가?	‘2011판과 2023판을 섞지 않는다’와 특성별 표
비슷한 이름을 사건에서 구별할 수 있는가?	‘자주 혼동하는 쌍’
설계 요구에 실제 목표·책임·결과물을 썼는가?	QO 사례와 ‘책임과 출시 권한’
응답 실패·누락을 평균이나 종합점수로 덮지 않았는가?	‘수치 판단’과 ‘QA-3’
QA/QC·V&V를 조직명·단계명으로 단순화하지 않았는가?	‘QA·QC·V&V’ 비교
공급자와 변경 뒤 어떤 증거를 다시 확인하는가?	‘요구 하나의 변경’과 ‘공급자와 운영 결과’

이 점검표는 학습용이며 공식 점수 산정표가 아니다. 처음에는 본문을 보며 틀린 문장을 고치고, 다음에는 요구를 읽어 목차를 직접 만든 뒤 완성 답안과 대조한다. 학습 입력이나 통과가 다음 절을 읽는 조건은 아니다.

전체 비율을 기능별 보증으로 바꾼 답안을 고친다

오답: “QO-M은 99.083%이므로 주문과 조회가 모두 99%를 넘었다.” 전체와 하위집단의 분모를 섞었다. “기존 70/30 혼합의 전체 목표는 충족하지만 주문은 82,950/84,000=98.75%다. 업무상 필요한 기능별 목표와 시험 범위는 별도로 검토한다”로 고친다. 복습: QO-M의 상세표와 요구 변경.

또 다른 오답: “주문이 99%에 못 미치므로 과거 QO-02를 실패로 다시 기록한다.” 당시 요구는 전체 비율이었다. “기존 판정과 요구 버전을 보존하고, 새 주문 요구 QO-02a의 적용 조건·증거·판정을 별도로 연결한다”로 고친다. 새 위험을 발견한 것과 과거 측정값을 바꾸는 것은 다르다.

조건 변경 연습: 기능별 비율은 그대로이고 주문/조회 비중만 50/50이면 전체는 얼마인가? 두 비율에 각각 0.5를 곱하여 0.5 × 0.9875 + 0.5 × (35,950/36,000) ≈ 0.993056, 약 99.306%다. 전체 숫자가 높아져도 주문의 98.75%는 변하지 않는다. 이 값은 비중 변화의 가정 계산이며 새 혼합의 실제 성능 시험으로 기록하지 않는다. 먼저 기능별 분자·분모와 혼합을 적은 뒤 무엇이 달라졌고 무엇이 그대로인지 한 문장씩 설명한다.

마지막으로 남길 세 문장

품질모델의 분류와 제품의 품질 충족 증거는 다른 것이다. 답안에는 적용 판본과 실제 조건·목표·역할·증거·실패 판단을 함께 쓴다. 품질보증은 높은 점수를 선언하는 일이 아니라 요구와 증거의 빈틈을 드러내고 바로잡는 활동이다.

다음 안전 관련 주제에서는 안전성의 피해·운영 조건을 더 자세히 다룬다. 이 절의 Safety 개요를 위해분석·안전사례 전체의 학습 완료로 보지 않는다.

이 페이지 목차

이 페이지 목차