---
title: "22장. 비기능 요구사항"
description: "성능·가용성·신뢰성·보안·사용성 등 품질 기대를 환경·자극·응답·측정치가 있는 시나리오로 바꾼다."
---
{/* v3:question */}
## 이번 장에서 해결할 질문
성능·보안·사용성 같은 품질을 측정 가능한 조건으로 어떻게 표현하는가?
{/* v3:objectives */}
## 학습 목표
학습 목표
- “성능·보안·사용성 같은 품질을 측정 가능한 조건으로 어떻게 표현하는가?”에 답하는 데 필요한 개념과 근거를 설명한다.
- 수강신청 사례에 같은 판단 기준을 적용하고 확인할 빈칸과 다음 행동을 기록한다.
{/* v3:concepts */}
## 핵심 개념
‘빠르고 안정적이며 안전해야 한다’는 기대는 중요하지만 그대로는 설계나 시험의 기준이 되지 못한다. 품질 속성은 서로 영향을 주며, 어떤 환경과 부하에서 누구에게 어느 정도의 응답을 제공해야 하는지에 따라 의미가 달라진다. 근거 없는 숫자를 붙이는 것 역시 모호한 형용사를 바꾸어 쓴 것에 불과하다.
이 장에서는 성능·가용성·신뢰성·보안·사용성 등 품질 기대를 환경·자극·응답·측정치가 있는 시나리오로 바꾼다. 현재 기준과 사업 근거를 확인하고 품질 간 트레이드오프를 드러내, 검증 가능하면서도 근거 없는 정밀성을 피한 품질 요구사항을 작성한다.
### 1. 성능
“비기능 요구사항”은 기능 이외의 모든 것을 한 바구니에 넣는 널리 쓰이는 이름이다. 그러나 이 장에서는 가능한 한 **품질 요구사항**이라고 부른다. 품질 요구는 시스템이 기능을 얼마나 잘 수행해야 하는지, 어떤 환경에서 어느 수준을 유지해야 하는지를 정의한다. “빠르고 안정적이며 사용하기 쉬워야 한다”는 기대가 아니라 검증 가능한 조건과 측정치가 필요하다.
[ISO/IEC 25010:2023](https://www.iso.org/standard/78176.html)은 ICT·소프트웨어 제품의 품질을 명세·측정·평가하기 위한 현행 제품 품질 모델을 제공한다. 이 장의 13개 절은 목차의 실무 관점을 따른 것이므로 표준의 특성명과 일대일 대응하지 않는다. 분류표는 누락을 찾는 출발점이지 요구를 자동 생성하는 목록이 아니다.
품질 시나리오는 다음 요소로 작성한다.
```text
출처 + 자극 + 환경 + 대상 + 응답 + 측정치
```
각 요소는 다음 질문에 답한다.
| 요소 | 의미 | 수강신청 예 |
|---|---|---|
| 출처 | 자극을 만드는 사람·시스템·조건 | 학생, 운영자, 규칙 서비스 장애 |
| 자극 | 품질 반응을 요구하는 사건·부하 | 상태 조회, 동시 신청, 저장소 장애 |
| 환경 | 평상시·최대 부하·저하·복구 등 | 본 신청 오픈 직후의 합의 부하 |
| 대상 | 반응해야 할 제품·기능·데이터 | 상태 조회 기능, 신청 판정, 결정 기록 |
| 응답 | 제품이 관찰 가능하게 하는 행동 | 결과 제공, 안전 보류, 접근 거부 |
| 측정치 | 합격·불합격을 나누는 기준 | p95, 성공률, RTO·RPO, 과업 성공률 |
“시스템은 안정적이어야 한다”를 이 구조로 바꾸면 누가 어떤 환경에서 무엇을 안정적이라고 느끼는지 질문하게 된다. 품질 속성의 이름은 요구가 아니다. 같은 성능도 학생의 결과 조회, 운영자의 대량 감사 조회, 야간 데이터 이관에서 자극·환경·측정치가 다르다.
품질 목표에는 범위와 반대 조건도 필요하다. 성공 요청만 측정하면서 오류 응답을 빼면 성능을 맞추기 위해 요청을 거절하는 구현이 통과할 수 있다. 정상 부하에서만 가용성을 측정하면 가장 중요한 오픈 직후의 저하가 보이지 않는다. 지표를 최적화해 업무 결과를 훼손하지 않도록 기능 정확성·오류율·데이터 최신성을 동반 기준으로 둔다.
성능은 주어진 자원·부하 조건에서 시스템이 처리량과 시간 요구를 얼마나 충족하는지다. “2초 이내”만 적으면 어느 기능, 어느 구간, 어느 부하, 어떤 표본인지 알 수 없다. 기존 `QR-001`은 다음처럼 구체화한다.
> 합의된 수강신청 부하 시험 환경에서 인증된 학생이 자신의 신청 상태를 조회하면, 수강신청 시스템은 성공한 상태 조회 요청의 p95 응답시간을 2초 이하로 유지해야 한다.
이 문장도 시험 기준선이 필요하다.
| 측정 요소 | `QR-001`에 정할 내용 |
|---|---|
| 시작·끝 | 시스템 경계의 요청 수신부터 응답 본문 완료까지 |
| 부하 | 동시 사용자·초당 요청·읽기/쓰기 비율 |
| 데이터 | 학생·강좌·신청 건수와 분포, 캐시 준비 상태 |
| 표본 | 워밍업 제외 여부, 측정 구간·최소 건수 |
| 통계 | p95 계산·반올림·구간 집계 방법 |
| 동반 기준 | 오류율, 오래된 상태 비율, 처리량 하한 |
평균값은 일부 느린 사용자를 숨길 수 있다. p95·p99만으로도 최대 지연과 시간 초과를 모두 설명하지 못하므로 업무 위험에 맞춰 분포와 오류를 함께 본다. 신청 제출과 상태 조회는 부하·일관성 비용이 다르므로 같은 목표를 복사하지 않는다. 2초는 사례용 후보이며 사용자 영향·기준선·비용 검토와 승인이 필요하다.
### 2. 가용성
가용성은 필요한 시점에 기능을 사용할 수 있는 정도다. 서버 프로세스가 살아 있다는 사실이 아니라 학생이 신청 제출·결과 조회 같은 업무를 성공적으로 수행할 수 있는지로 본다. 규칙 서비스가 응답하지 않아 모든 신청이 보류된다면 웹 페이지는 열려도 신청 판정 기능의 가용성은 낮다.
가용성 요구에는 서비스 시간, 측정 대상, 정상으로 인정할 결과, 관측 지점, 제외 시간과 계산 공식을 둔다.
```text
가용성 = 정상 업무 수행 가능 시간 / 합의된 서비스 대상 시간
```
`QR-002` 후보는 다음과 같이 쓸 수 있다.
> 본 신청 기간의 합의된 서비스 시간 동안, 수강신청 시스템은 신청 제출과 현재 결과 조회 업무를 99.9% 이상 수행 가능하게 유지해야 한다. 측정은 외부 사용자 관측 지점에서 하며, 제외할 계획 작업은 사전 승인된 시간만 포함한다.
99.9%는 사례용 값이다. 5일간 24시간 서비스라면 허용 불가용 시간이 약 7.2분이므로 비용과 운영 능력을 확인해야 한다. 월간 99.9%와 짧은 신청 기간 99.9%는 의미가 다르다. 전체 포털 평균에 섞으면 가장 중요한 기간의 장애가 숨을 수 있다.
전체 서비스와 기능별 가용성을 구분한다. 결과 조회가 가능하지만 신규 신청만 중단되거나, 보류 상태 제공은 가능하지만 확정 판정이 불가능할 수 있다. 부분 저하 상태와 학생에게 제공할 대체 행동을 정의하면 단순 up/down 지표보다 운영에 유용하다.
### 3. 신뢰성
신뢰성은 정해진 조건과 기간에 시스템이 의도한 기능을 실패 없이 일관되게 수행하는 정도다. 가용성이 “지금 사용할 수 있는가”라면 신뢰성은 “반복·시간 경과·장애 조건에서도 올바른 결과를 계속 만드는가”에 가깝다. 재시작이 빨라 가용해도 좌석을 중복 배정하면 신뢰할 수 없다.
수강신청의 핵심 신뢰성은 결과 정확성과 일관성이다.
`QR-003` 후보:
> 합의된 최대 동시 신청 시험에서 같은 강좌의 요청이 경쟁하더라도, 수강신청 시스템은 정책상 가용 좌석을 초과하는 확정 승인을 만들지 않고 각 신청에 모순 없는 단일 최종 상태를 유지해야 한다.
이 요구는 “오류율 0%”라는 막연한 문구보다 위험한 실패를 구체화한다. 시험에서는 마지막 좌석, 중복 제출, 지연된 규칙 응답, 처리 중 재시작, 취소와 신청의 경쟁을 포함한다. 좌석 정책 자체가 `ISS-001`로 미결정이므로 어떤 좌석 집합을 하한·상한으로 볼지 먼저 승인한다.
확률 지표를 쓸 수도 있다. 성공 처리율, 장애 사이 평균 시간, 데이터 손상 건수처럼 대상을 정의하되 드문 심각한 실패를 평균에 묻지 않는다. 자동 승인 금지 `IR-001`처럼 한 번도 발생하면 안 되는 안전 속성은 별도 불변식으로 검증한다.
### 4. 확장성
확장성은 사용자·요청·데이터·기능 범위가 커질 때 품질 목표를 유지하거나 예측 가능한 비용으로 수용하는 능력이다. 현재 부하의 성능 요구와 다르다. “무한 확장”이 아니라 어떤 성장 축을 어느 수준까지 언제 수용해야 하는지 적는다.
| 성장 축 | 사례 조건 | 관찰할 결과 |
|---|---|---|
| 동시 사용자 | 학년별 오픈 직후 급증 | p95·p99, 오류율, 처리량 |
| 강좌·신청 데이터 | 학기 누적·대학 통합 | 조회·판정 시간, 저장·이관 시간 |
| 규칙 수·복잡도 | 학생 유형·예외 증가 | 판정 지연, 규칙 변경 검증 시간 |
| 외부 연계 | 캠퍼스·기관 추가 | 격리 실패, 계약 관리 비용 |
`QR-004` 후보:
> 기준 부하 프로필의 요청량을 두 배로 높인 용량 시험에서 수강신청 시스템은 승인된 성능·오류율·신뢰성 기준을 유지해야 한다.
두 배 역시 사업 전망과 과거 로그를 근거로 정할 사례 값이다. 용량 확장에 필요한 자원과 준비 시간을 재현 가능하게 산정하는 일은 제품 품질 판정과 분리해 **운영 용량관리 요구**로 관리한다. 단순히 서버를 늘릴 수 있다는 설계 문구보다 어느 병목과 상태 저장소·외부 연계가 확장을 제한하는지 시험한다. 외부 규칙 서비스가 같은 용량을 제공하지 못하면 내부 확장만으로 목표를 충족하지 못한다.
### 5. 보안
보안 요구는 권한 없는 접근·변경·노출을 막고, 권한 있는 사용과 데이터의 기밀성·무결성·책임성을 보호한다. “암호화한다”, “보안 솔루션을 사용한다”는 통제 수단이지 보호할 자산·위협·상황·검증 수준을 완전히 설명하지 않는다.
수강신청의 자산과 위험을 먼저 연결한다.
| 자산·행동 | 대표 위험 | 요구 후보 |
|---|---|---|
| 학생의 신청·학적 | 다른 학생 조회·변경 | 객체·행동별 권한 확인 |
| 정원·판정 | 위변조·중복 승인 | 무결성·상태 전이 통제 |
| 규칙·버전 | 승인되지 않은 정책 적용 | 출처·버전·변경 권한 검증 |
| 운영 정정 | 권한 남용·사후 조작 | 이중 통제·불변 감사 이력 |
| 인증 정보 | 탈취·재사용 | 세션·재인증·전송 보호 |
`QR-005` 후보:
> 인증된 사용자가 신청 식별자를 변경해 요청하더라도, 수강신청 시스템은 자신의 데이터 범위 또는 명시적으로 승인된 업무 범위를 벗어난 신청의 조회·변경을 허용하지 않고 필요한 보안 사건을 기록해야 한다.
검증은 정상 권한뿐 아니라 직접 객체 참조 변경, 역할 전환, 만료 세션, 대량 조회와 운영자 오용 사례를 포함한다. [OWASP ASVS 5.0.0](https://owasp.org/www-project-application-security-verification-standard/)은 웹 애플리케이션 기술 보안 통제의 시험 기준을 제공한다. ASVS 요구를 참조할 때 버전과 요구 ID를 함께 기록하고, 제품의 위험·법적 의무에 맞는 검증 수준을 승인한다.
### 6. 사용성
사용성은 특정 사용자가 특정 사용 맥락에서 목표를 효과적·효율적이고 만족스럽게 달성할 수 있는가에 관한 품질이다. “직관적인 화면”은 사용자·과업·환경·성공 기준이 없어 검증하기 어렵다. 화면 예쁨이나 클릭 수 하나로 대신할 수 없다.
수강신청의 대표 과업을 정한다.
- 처음 이용하는 학생이 강좌를 찾아 선수과목·시간 충돌 정보를 이해한다.
- 마감 직전 학생이 신청 결과가 승인·거절·보류 중 무엇인지 확인한다.
- 거절된 학생이 사유와 가능한 다음 행동을 찾아 불필요한 재제출을 피한다.
- 키보드·화면낭독기 사용자가 같은 핵심 과업을 완료한다.
`QR-006` 후보:
> 대표 학생 표본이 승인된 수강신청 시제품에서 신청 결과와 사유 확인 과업을 수행할 때, 정해진 도움 없이 성공한 비율·완료 시간·치명 오류와 사후 이해도를 합의된 기준 이상으로 충족해야 한다.
수치는 사전 사용자 연구와 기준선으로 정한다. 만족도만 높고 실제 거절 상태를 승인으로 오해하면 성공이 아니다. 과업 성공·오류·시간·이해·만족을 함께 관찰하고, 초보·숙련자·보조기술 사용자의 맥락 차이를 기록한다.
### 7. 접근성
접근성은 장애를 포함한 다양한 능력과 보조기술 환경에서 정보와 기능을 인지·조작·이해할 수 있게 하는 요구다. 사용성의 일부로 묻힐 수 있지만 법·정책·사회적 영향과 검증 기준이 커 별도 추적한다.
`QR-007` 후보:
> 수강신청의 검색, 신청 준비, 제출, 승인·거절·보류 결과 조회와 취소 전체 흐름은 승인된 적용 범위에서 WCAG 2.2 Level AA 성공 기준을 충족해야 하며, 키보드와 조직이 선정한 화면낭독기 조합으로 핵심 과업을 완료할 수 있어야 한다.
[WCAG 2.2](https://www.w3.org/TR/WCAG22/)는 2024년 12월 갱신된 W3C Recommendation이며, W3C는 현재 버전 사용을 권고한다. Level AA라는 이름만 적지 않고 적용 페이지·상태·콘텐츠, 사용 기술, 시험 도구·보조기술·브라우저 조합과 판정 책임을 정한다.
자동 검사만으로 충분하지 않다. 초점이 가려지는지, 오류가 텍스트로 식별되는지, 색만으로 상태를 구분하지 않는지, 인증 과정이 인지 장벽을 만드는지 사람이 점검해야 한다. 외부 인증·결제·알림 링크가 전체 과업을 막는다면 경계 밖 제공자와의 책임도 인터페이스 계약에 포함한다.
### 8. 유지보수성
유지보수성은 결함 수정, 정책 변경, 시험과 분석을 안전하고 효율적으로 수행할 수 있는 정도다. “모듈화한다”는 설계 원칙만 요구로 적기보다 예상 변경 사건과 필요한 결과를 정의한다.
수강신청에서 가장 빈번하고 위험한 변경은 학사 규칙·사유 코드·학기 일정·외부 계약 변경이다. `QR-008` 후보는 다음과 같다.
> 승인된 `RULE-001–RULE-005` 중 하나가 변경되면, 수강신청 제품은 영향받는 규칙과 판정 경로를 식별할 수 있어야 하며, 변경 전 규칙 버전의 판정 결과를 재현하고 영향받지 않는 회귀 요구를 보존할 수 있어야 한다.
팀이 합의된 시간 안에 새 규칙을 검증·배포한다는 목표는 제품 유지보수성과 분리해 **조직 변경 프로세스 목표**로 관리한다. 그 시간은 실제 변경 빈도·위험·인력을 근거로 수치화한다. 제품 품질에서는 영향 누락, 규칙 버전 재현 가능성, 회귀 보존과 되돌림에 필요한 제품 정보를 본다. 코드 줄 수나 특정 아키텍처는 필요 근거가 있을 때 설계 제약으로 관리한다.
관측 가능성과 진단 가능성도 유지보수에 영향을 준다. 보류 증가 원인을 규칙 서비스·데이터 품질·권한 오류로 구분할 수 없다면 복구가 늦어진다. 로그를 많이 남기는 대신 필요한 사건·상관 ID·보호·보존 기준을 명세한다.
### 9. 호환성
호환성은 다른 제품·시스템과 같은 환경을 공유하거나 정보를 교환해 의도한 기능을 수행하는 품질이다. 단순히 “연동 가능”하다고 쓰지 않고 공존과 상호운용의 범위를 분리한다.
수강신청 사례에서는 다음 호환성이 필요하다.
- 학사정보 시스템의 학생·강좌 식별자와 의미를 보존한다.
- 인증 서비스의 주체·역할 문맥을 수강신청 권한에 정확히 매핑한다.
- 규칙 서비스의 버전·판정·오류 의미를 손실 없이 해석한다.
- 알림 서비스 장애가 신청 판정 가용성을 연쇄적으로 떨어뜨리지 않는다.
- 지원 브라우저·보조기술에서 핵심 사용자 흐름이 동작한다.
호환성 요구에는 상대 시스템·버전, 교환 의미, 문자·시간대·단위, 하위 호환 기간, 동시 운영과 시험 환경을 둔다. 24장의 인터페이스 계약이 상세 형식을 정의하더라도 품질 목표는 여기서 “서로 다른 버전이 어느 기간 어떤 결과를 유지해야 하는가”로 표현한다.
모든 과거 버전을 영구 지원하겠다는 요구는 비용이 크고 검증하기 어렵다. 지원 매트릭스와 폐기 공지·전환 기간을 승인한다.
### 10. 이식성
이식성은 제품을 다른 운영 환경·플랫폼으로 옮기거나 그 환경에 적응시키는 능력이다. 확장성이 같은 환경의 성장이라면 이식성은 환경 변화다. “어디서나 실행”이 아니라 실제 사업·운영 계획이 있는 대상과 전환 비용을 적는다.
수강신청에서 이식성 요구가 필요한 경우는 데이터센터·클라우드 전환, 지원 브라우저 변경, 조직 표준 런타임 교체, 캠퍼스별 배포가 있을 때다. 후보 시나리오는 다음과 같다.
> 승인된 대상 운영 환경으로 전환할 때 수강신청 시스템은 신청·판정 이력과 규칙 버전의 의미를 보존하고, 합의된 전환 시간·중단 시간·검증 절차 안에서 핵심 기능과 품질 기준을 재확인할 수 있어야 한다.
대상 환경과 전환 계획이 없다면 추상적인 이식성 목표를 Must로 만들지 않는다. 컨테이너나 특정 클라우드는 설계 대안일 수 있으며, 규정·조직 표준처럼 선택 불가능한 제약일 때만 출처와 적용 범위를 요구에 둔다.
이식은 23장의 데이터 이관과 다르다. 제품 실행 환경은 그대로인데 데이터만 새 구조로 옮길 수도 있고, 환경은 바뀌어도 데이터 형식은 유지될 수 있다. 두 변화의 책임·증거를 별도로 관리한다.
### 11. 감사 가능성
감사 가능성은 권한 있는 사람이 중요한 결정과 변경을 신뢰할 수 있는 증거로 추적·재현할 수 있는 능력이다. 단순 로그 저장량이 아니라 어떤 질문에 답해야 하는지부터 정한다.
수강신청 감사 질문은 다음과 같다.
- 누가 언제 어느 학생·강좌의 신청을 제출·조회·취소·정정했는가?
- 어떤 학적·강좌 기준 시점과 규칙 버전으로 결과를 냈는가?
- 승인·거절·보류의 사유와 상태 전이는 무엇이었는가?
- 운영자가 판정을 정정했다면 누가 승인했고 이전 값은 무엇인가?
- 기록 누락·위변조·시간 불일치를 어떻게 탐지하는가?
`DR-001`은 학생·강좌 ID, 요청 시각, 결과, 사유, 규칙 버전과 최종 상태 변경을 요구한다. 감사 품질 요구는 이 기록을 합의된 시간 안에 검색·상관·재현할 수 있고 권한 없는 수정·열람을 막는 수준을 더한다.
`QR-009` 후보:
> 권한 있는 감사자가 신청 ID를 제시하면, 시스템은 승인된 보존 기간 안의 판정 입력 기준·규칙 버전·상태 변경·수행 주체를 연결한 감사 증거를 합의된 조회 시간 안에 제공해야 한다.
감사와 개인정보 최소화는 긴장 관계가 있다. 모든 원문을 무기한 저장하지 않고 목적·법적 근거·접근·보존·마스킹을 23장과 함께 정한다.
### 12. 복구
복구 요구는 장애 뒤 어느 시점의 데이터와 기능을 얼마 만에 어떤 검증을 거쳐 되살릴지 정의한다. 백업이 있다는 사실과 복구 가능성은 다르다. 복원 시험, 업무 일관성, 외부 시스템 재동기화와 사용자 안내가 필요하다.
자주 쓰는 두 지표를 구분한다.
- RTO(Recovery Time Objective): 중단 뒤 목표한 업무 수준을 회복할 최대 시간.
- RPO(Recovery Point Objective): 복구 시 허용할 수 있는 데이터 손실 시점의 한도.
`QR-010` 후보:
> 신청 처리 저장소 장애가 발생하면 수강신청 시스템은 승인된 복구 절차에 따라 합의된 RTO 안에 결과 조회와 안전한 신청 처리를 회복하고, 합의된 RPO를 넘는 신청·판정 손실이 없음을 결정 기록과 외부 원천 대조로 검증해야 한다.
RTO·RPO 숫자는 업무 영향 분석과 기술·비용 근거로 정한다. 승인·정원처럼 재구성하기 어려운 데이터에 RPO 0을 요구할 수 있지만, 그 비용과 외부 연계의 보장까지 확인해야 한다. 캐시·통지 이력처럼 다시 만들 수 있는 데이터는 다른 목표가 가능하다.
복구 완료는 서버 기동이 아니다. 상태·좌석·판정 기록이 일치하고, 중복 재처리가 없으며, 학생이 공식 현재 상태를 확인할 수 있어야 한다. 정기 복구 훈련의 범위·주기·합격 기준도 운영 요구로 연결한다.
### 13. 개인정보 보호
개인정보 보호 요구는 개인정보의 생명주기에서 목적 적합성, 최소 처리, 투명성, 정보주체 권리, 안전조치와 책임을 정의한다. 보안이 무단 접근을 막는 데만 집중하면 적법한 권한으로 과도하게 수집·보존·사용하는 문제를 놓칠 수 있다.
수강신청에서 처리 후보를 목적과 함께 본다.
| 데이터 | 목적 후보 | 최소화·보호 질문 |
|---|---|---|
| 학생 ID·학적 | 자격·학점 판정 | 전체 학적이 필요한가, 필요한 속성만 가능한가? |
| 이수 과목 | 선수과목 판정 | 사유 제공 때 불필요한 상세 노출은 없는가? |
| 신청·취소 이력 | 현재 상태·분쟁·감사 | 보존 기간과 접근 역할은 무엇인가? |
| 인증·접속 정보 | 신원·보안 사건 확인 | 비밀번호·토큰을 기록하지 않는가? |
| 지원 문의·정정 사유 | 복구·책임 | 민감한 자유 입력을 어떻게 제한하는가? |
`QR-011` 후보:
> 수강신청 시스템은 승인된 수강신청·판정·지원 목적에 필요한 학생 정보만 처리하고, 목적·항목·원천·접근 역할·제공 대상·보존·파기와 정보주체 요청 처리 기준을 데이터 항목별로 추적할 수 있어야 한다.
대한민국의 실제 프로젝트라면 [국가법령정보센터의 개인정보 보호법](https://law.go.kr/unSc.do?query=%EA%B0%9C%EC%9D%B8%EC%A0%95%EB%B3%B4+%EB%B3%B4%ED%98%B8%EB%B2%95)과 적용 시점의 시행령, [개인정보보호위원회 고시](https://pipc.go.kr/np/cop/bbs/selectBoardList.do?bbsId=BS216&etc1=%EA%B3%A0%EC%8B%9C&mCode=G010020040)를 법무·개인정보 책임자와 확인한다. 2026년에도 시행일이 다른 개정이 존재하므로 원고의 예시를 법률 자문이나 고정 보존 기간으로 사용하지 않는다.
품질 요구 후보를 한 시나리오 표로 묶는다.
| ID | 자극·환경 | 필요한 응답 | 측정·증거 |
|---|---|---|---|
| `QR-001` | 합의 부하에서 상태 조회 | p95 2초 이하 후보 | 부하 시험·오류율 |
| `QR-002` | 본 신청 기간 | 핵심 업무 99.9% 가용 후보 | 외부 관측·기능별 가용성 |
| `QR-003` | 동시 신청 경쟁 | 정원 초과·모순 상태 없음 | 경쟁·장애 주입 시험 |
| `QR-004` | 기준 요청량 2배 후보 | 성능·오류·신뢰성 유지 | 용량 시험·자원 추세 |
| `QR-005` | 다른 학생 객체 접근 | 권한 외 조회·변경 거부 | 보안 시험·사건 기록 |
| `QR-006`, `QR-007` | 대표 사용자·보조기술 | 과업 성공과 WCAG 적용 기준 | 사용자 평가·수동/자동 검사 |
| `QR-008`, `QR-009` | 규칙 변경·감사 조회 | 영향 추적·판정 재현 | 변경 기록·감사 표본 |
| `QR-010`, `QR-011` | 장애·개인정보 처리 | 복구 목표·최소 처리 | 복구 훈련·처리 목록 |
품질끼리도 충돌한다. 강한 감사는 개인정보·저장 비용을 늘리고, 엄격한 실시간 일관성은 성능·가용성을 낮출 수 있으며, 자동 재시도는 가용성을 높이지만 중복 처리 위험을 키운다. 다음처럼 결정을 기록한다.
| 긴장 관계 | 잘못된 절충 | 결정에 필요한 근거 |
|---|---|---|
| 성능–정확성 | 오래된 상태를 조용히 반환 | 최신성 허용, 사용자 영향, 원천 지연 |
| 가용성–안전 | 규칙 실패 때 자동 승인 | `IR-001`, 위험·수동 복구 비용 |
| 감사–개인정보 | 모든 원문 무기한 저장 | 법적 근거, 목적, 보존·마스킹 |
| 사용성–보안 | 위험 행동의 재인증 모두 제거 | 위협·사용 맥락·대체 인증 |
| 확장성–비용 | 최대 부하를 상시 과잉 준비 | 성장 전망, 준비 시간, 저하 전략 |
품질 요구의 검증 개념도 요구와 함께 작성한다.
| 검증 질문 | 필요한 기록 |
|---|---|
| 어느 환경을 재현하는가? | 구성, 데이터 규모·분포, 외부 연계 상태, 시간대 |
| 자극을 어떻게 발생시키는가? | 사용자 과업, 요청률·동시성, 장애 주입 방법 |
| 어디서 무엇을 관측하는가? | 사용자·시스템 경계, 시각 동기화, 로그·지표 원천 |
| 어떤 표본을 포함·제외하는가? | 워밍업, 재시도, 오류, 시간 초과, 최소 건수 |
| 합격을 어떻게 계산하는가? | 공식, 분모, 구간, 반올림, 허용 오차 |
| 기능 결과도 올바른가? | 상태·좌석·사유·기록의 불변식과 대조 |
| 누가 판정하고 증거를 보관하는가? | 품질 책임자, 승인자, 결과 위치·보존 기간 |
한 번의 시험으로 품질을 영구 보증할 수 없다. 정적 검사, 시제품 사용자 평가, 보안 시험, 부하·용량 시험, 장애 주입, 복구 훈련과 운영 관측을 조합한다. 시험 환경 결과와 운영 결과가 다르면 부하 프로필·데이터·외부 의존성을 갱신해 요구의 전제가 여전히 유효한지 본다.
품질 분류 완전성도 교차 검토한다. 모든 기능에 모든 품질 속성을 붙이는 방식은 요구를 부풀린다. 대신 기능·위험별로 중요한 품질을 연결한다.
| 기능·위험 | 우선 연결할 품질 |
|---|---|
| 신청 제출·판정 | 성능, 신뢰성, 보안, 감사, 복구 |
| 결과·사유 조회 | 성능, 가용성, 사용성, 접근성, 개인정보 |
| 규칙 변경 | 유지보수성, 감사, 호환성 |
| 외부 학사·인증 연계 | 가용성, 호환성, 보안, 복구 |
| 이관·환경 전환 | 데이터 정합성, 이식성, 복구 |
요구가 서로 다른 품질을 지원해도 하나의 ID로 합치지 않는다. 변경 주체·검증 방법·적용 환경이 다르면 독립적으로 승인하고 추적할 수 있어야 한다. 반대로 같은 측정 시나리오를 문서 여러 곳에 복사하지 않고 기준이 되는 품질 요구를 참조한다.
목표 후보의 숫자를 승인 값처럼 쓰지 않는다. 각 값은 출처, 기준선, 사용자·운영 영향, 비용, 측정 방법, 책임자와 승인 상태를 가져야 한다. [ISO/IEC 25020:2019과 SQuaRE 관련 현행 목록](https://www.iso.org/committee/45086/x/catalogue/)은 품질 측정 프레임워크를 확인하는 출발점이다.
이 장에서 정리한 결과는 품질 분류표, `QR-001–QR-011` 시나리오 후보, 측정 기준과 트레이드오프 표다. 다음 장에서는 이 품질 목표를 학생·강좌·신청·판정·정원 데이터의 의미·원천·생명주기·품질·개인정보 요구로 연결한다.
{/* v3:case */}
## 수강신청 사례에 적용
수강신청 사례의 결정·근거·남은 쟁점을 22장에서 다룬 기준으로 구분한다.
{/* v3:criteria */}
## 판단 기준과 흔한 오류
:::warning[판단하기 전에 확인]
- 결정을 확인할 수 있는 출처와 근거가 있는가?
- 구현·검증·변경에 필요한 다음 행동과 책임자가 분명한가?
:::
{/* v3:practice */}
## 직접 해보는 실습
1. **1. 대상 선택**
현재 프로젝트 산출물 중 이 장의 질문과 관련된 항목 하나를 고른다.
2. **2. 근거와 예외 표시**
본문의 판단 질문으로 누락된 근거와 예외를 표시한다.
3. **3. 다음 행동 기록**
확인할 책임자, 필요한 최소 증거와 다음 행동을 기록한다.
{/* v3:summary */}
## 핵심 요약
:::success[이 장에서 가져갈 기준]
성능·가용성·신뢰성·보안·사용성 등 품질 기대를 환경·자극·응답·측정치가 있는 시나리오로 바꾼다.
:::
{/* v3:next */}
## 관련 도구와 다음 경로
바로 사용할 수 있는 점검표와 예제를 확인합니다.
학습 순서에 따라 다음 판단 주제로 이어갑니다.