[ 품질 목표 ]
요구 분석 단계에서 기능 요구는
비교적 명확하게 정리된다.
하지만 설계 단계로 들어오면 같은 기능을
만족하는 설계안이 여러 개로 갈라진다.
이때 설계안을 가르는 핵심 기준이
기능 외적인 요구, 즉 '비기능 요구'다.
비기능 요구는 곧 시스템의 '품질 특성'이며,
설계에서 반드시 목표로 다뤄야 한다.
기능 요구는 하나, 설계안은 여러 개
기능 요구는 사용자가 원하는 일을
시스템이 할 수 있느냐에 대한 조건이다.
예를 들면 로그인, 글 작성, 검색 같은 것들이다.
반면 품질 목표는 그 기능을
어떤 수준과 방식으로 제공할지에 대한 조건이다.
- 빠르게 반응해야 한다
- 장애가 나도 빨리 복구돼야 한다
- 처음 온 사용자도 쉽게 쓸 수 있어야 한다
- 바뀌는 요구에 쉽게 수정 가능해야 한다
기능 요구가 같아도 품질 목표를 어디에 두느냐에 따라
아키텍처, 데이터 설계, 화면 흐름, 운영 방식까지 달라진다.
그래서 설계는 결국 품질 목표를 만족시키기 위한 선택 과정이 된다.
설계 전에 품질 목표를 먼저 확정해야 하는 이유
품질 목표는 요구 명세서 단계에서 결정되지만,
실제로 구현 형태로 녹여내는 것은 설계 단계의 몫이다.
설계 전에 품질 목표가 정리되지 않으면
흔히 이런 문제가 생긴다.
- 성능은 나왔는데 안정성이 약함
- 유지보수는 쉬운데 응답이 느림
- 화면은 예쁜데 사용 흐름이 복잡함
- 기능은 다 있는데 운영에 취약함
즉, 품질 목표는 설계 전체의 기준선이고,
아키텍처는 그 기준선을 충족시키는 구조적 결론이다.
품질 목표 결정 흐름
품질 목표는 설계에서 자연스럽게 따라오는 부가 요소가 아니라,
설계가 도달해야 하는 목표로 명시되어야 한다.
[ 흐름도 ]
이해당사자
↓
요구 수집
↓
요구 정리
├─ 기능 요구
└─ 비기능 요구 = 품질 목표
↓
합의 및 우선순위
↓
아키텍처 선택 및 상세 설계
↓
개발 및 검증
품질 목표는 서로 충돌할 수 있다
품질 목표는 동시에 모두 최대로 만족시키기 어렵다.
대표적인 충돌 예시는 다음과 같다.
- 안정성 강화(이중화, 검증 강화)
→ 성능 저하, 비용 증가 가능 - 성능 최적화(캐시, 비동기)
→ 복잡도 증가로 유지보수성 저하 가능 - 보안 강화(권한, 인증, 로깅)
→ 사용성 저하 가능
그래서 설계 작업에서 중요한 것은 아래 2가지다.
- 품질 목표의 우선순위를 정한다
- 충돌하는 목표 사이에서 절충안을 설계로 만든다
설계는 정답을 맞히는 작업이 아니라,
선택을 정당화하는 작업에 가깝다.
ISO 25010 품질 특성 정리
ISO 25010은 소프트웨어 품질을 여러 특성으로 분류한다.
여기서는 기능적합성 외의 품질 특성을 중심으로 정리한다.
| 품질 특성 |
의미 | 설계 관점 체크포인트 |
예시 측정 방법 또는 속성 |
| 신뢰성 | 정해진 조건과 기간 동안 요구 기능을 안정적으로 수행 |
장애 허용, 복구 전략, 예외 처리, 모니터링 |
가용률, 성숙성, 결함수용성, 복구용이성 |
| 사용성 | 사용자가 효율적으로 작업하고 만족스럽게 사용할 수 있는 정도 |
화면 동선 단순화, 단계 수 최소화, 일관된 UI 패턴 |
학습성, 운영성, UI 만족, 접근성 사용자 오류 보호 |
| 성능 효율성 |
자원 대비 응답 속도와 처리 효율 |
쿼리 최적화, 캐시, 비동기, 서버/네트워크 병목 제거 |
시간 효율성, 자원 효율성, 단위시간당 사용자 수, 평균 실행시간 |
| 유지 보수성 |
변경 요구와 오류 수정에 얼마나 잘 대응하는지 |
모듈 분리, 결합도 관리, 테스트 전략, 코드 규칙 |
분석성, 변경가능성, 모듈성, 테스트가능성, 재사용성 |
| 이식성 | 환경이 바뀌어도 쉽게 옮길 수 있는 정도 |
배포 방식, 환경 의존성 최소화, 설정 분리 |
환경 적응성, 설치 용이성, 대체 가능성 |
| 호환성 | 같은 환경에서 다른 시스템과 공존 및 연동 가능 |
API 규격, 데이터 포맷, 버전 정책, 통합 테스트 |
상호운용성, 상호공존성 |
| 보안성 | 권한 수준에 맞게 정보와 데이터를 보호 |
인증/인가, 접근 제어, 감사 로그, 위변조 방지 |
기밀성, 무결성, 부인방지, 책임성, 인증성 |
품질 목표를 설계 산출물로 바꾸는 방법
품질 목표를 실제 설계로 연결하려면,
목표를 선언하는 데서 끝내면 안 되고
설계 결정으로 변환해야 한다.
아래처럼 정리하면 흐름이 깔끔해진다.
- 품질 목표를 문장으로 구체화한다
예: '페이지 응답은 2초 이내' '장애 시 10분 내 복구' - 품질 목표를 시나리오로 만든다
예: 사용자 1,000명이 동시 접속할 때 검색이 느려지지 않는다 - 목표 간 우선순위를 정한다
예: 성능보다 안정성 우선, 사용성보다 보안 우선 - 목표를 만족시키는 설계 기법을 매핑한다
예: 성능 → 캐시/쿼리 최적화
신뢰성 → 재시도/서킷 브레이커/장애 격리
유지보수성 → 레이어 분리/테스트 전략 - 측정 지표를 정하고 검증 계획을 붙인다
예: 평균 응답시간, 오류율, 가용률, 배포 성공률
마무리
품질 목표는 설계의 장식이 아니라,
설계안을 결정하는 기준이다.
기능 요구를 만족시키는 설계안은
여러 개가 나올 수 있지만,
어떤 설계가 더 좋은지는 결국
'어떤 품질 목표를 우선하는가'로 갈린다.
따라서 설계 단계에서 해야 할 가장 중요한 일은
품질 목표를 명시하고, 우선순위를 정하고,
충돌을 절충한 설계를 선택하는 것이다.
'개주 훈련일지 > 📚 코살대 교본 학습' 카테고리의 다른 글
| SQL) 그룹 함수 (0) | 2026.02.02 |
|---|---|
| 전통적인 설계 원리 (0) | 2026.02.01 |
| 설계 원리와 설계 기본 개념 (0) | 2026.01.26 |
| SQL) 서브쿼리 (0) | 2026.01.25 |
| 모델 검증 (0) | 2026.01.24 |