기능·품질속성·제약

무엇을 하는지만 맞아도 실패할 수 있다

시스템이 주문을 접수하는 기능을 제공해도 혼잡할 때 한 시간씩 걸리거나 누구나 다른 사람의 주문을 읽을 수 있다면 쓸 수 없다. 반대로 응답시간과 보안 목표만 적고 어떤 업무를 처리하는지 빠뜨려도 제품을 만들 수 없다. 요구는 기능, 잘하는 정도, 선택의 한계를 나눠 읽어야 한다.

먼저 되짚기: 요구사항

요구사항은 이해관계자의 필요와 외부 의무를 시스템이 충족하는지 검증할 수 있는 조건이나 능력으로 표현한 약속이다. 이제 한 요구를 무엇을 하는지, 얼마나 잘해야 하는지, 어떤 선택을 할 수 없는지로 나눠 읽는다.

기능·품질속성·제약의 정의

기능은 시스템이 수행할 행동이나 제공할 결과다. 품질속성은 성능·가용성·보안·사용성처럼 그 기능을 어떤 조건에서 얼마나 잘 수행해야 하는지를 나타내는 성질이다. 제약은 법, 예산, 일정, 호환성, 기술환경처럼 설계 대안의 선택범위를 제한하는 조건이다. 세 종류는 서로 대체하지 않으며 함께 검증되어야 한다.

모호한 품질을 시나리오로 바꾼다

성능이 좋아야 한다 대신 평일 9시, 동시에 2천 명이 조회할 때, 정상 네트워크에서 95% 요청을 2초 안에 응답처럼 자극·환경·대상·반응·측정값을 적는다. 기능에는 정상 흐름과 예외 결과를 붙이고, 제약에는 근거와 적용범위를 붙인다. 이렇게 해야 설계 대안을 비교하고 시험으로 확인할 수 있다.

해결책을 요구로 위장하지 않는다

서버를 세 대 쓴다는 대개 요구가 아니라 한 해결안이다. 실제 요구가 장애 중 서비스 지속이라면 다른 구조도 가능하다. 모든 품질을 최고로 요구하면 비용과 복잡도가 폭증하고 서로 충돌한다. 중요 사용상황, 실패 피해와 비용을 기준으로 목표 수준과 우선순위를 정하며 근거 없는 제약은 다시 검토한다.

세 종류의 요구가 설계와 시험으로 이어지는 길

상자 안의 대상과 화살표의 조건을 함께 읽으세요. 좁은 화면에서는 같은 관계를 세로로 재배치한 도식을 보여 줍니다.

세 가지 요구는 서로 대체하지 않는다. 기능의 흐름·예외, 품질의 구조 대안과 부하·장애·보안, 제약의 준수·적용범위를 각각 확인하고 하나의 수용기준과 추적 증거로 연결한다.

기능은 행동의 존재를, 품질속성은 행동의 수준을, 제약은 해법의 경계를 정한다. 세 가지가 같은 사용자 상황을 향하도록 연결해야 기능은 맞지만 느리거나, 빠르지만 법을 어기는 시스템을 피할 수 있다.

문장 모양과 검증 증거가 다르다

품질속성은 “빠르다”, “안전하다” 같은 형용사만으로 시험할 수 없다. 자극, 대상, 환경, 기대 반응과 측정값을 붙인다. 제약에는 출처와 적용범위, 예외 승인자를 붙여 근거 없는 관행과 구분한다.

모든 품질을 최대로 만들 수는 없다

강한 암호화와 추가 본인확인은 보안을 높일 수 있지만 응답시간과 운영비용을 늘리고 사용 편의를 낮출 수 있다. 복제본을 많이 두면 장애 격리와 읽기 처리량은 좋아질 수 있지만 비용과 데이터 일관성 관리가 어려워진다. 따라서 “성능 대 보안”처럼 속성을 단순 대립시키지 말고 중요한 사용상황별 최소 수용수준과 우선순위를 정한다.

판단 순서는 치명적 실패와 법적 한계를 먼저 지키고, 업무가치가 큰 시나리오의 목표를 정한 뒤, 비용·복잡도·운영역량 안에서 대안을 비교하는 것이다. 한 속성의 이익을 위해 포기한 수준과 잔여위험, 실제 운영에서 재측정할 지표를 남긴다.

주문 서비스 문장 네 개를 분류해 보기

1. “고객은 결제 전 배송지를 변경할 수 있어야 한다”는 기능이다. 정상 변경뿐 아니라 이미 출고된 주문의 거부 결과도 수용기준에 넣는다.
2. “서비스는 빨라야 한다”는 불완전한 품질 문장이다. “평일 행사시간, 동시 사용자 3천 명에서 주문 조회의 95%를 2초 이내 응답”으로 고친다.
3. “모든 데이터는 국내 지정 구역에 보관한다”는 계약이나 정책에서 온 제약일 수 있다. 출처, 적용 데이터와 예외를 확인한다.
4. “서버 세 대를 둔다”는 보통 설계안이다. 실제 요구가 “서버 한 대 고장 중에도 주문 조회를 계속 제공”인지 되묻고 대안을 열어 둔다.

분류 뒤에는 각 문장을 요구 식별자, 출처, 우선순위, 수용기준, 담당 설계와 시험에 연결한다. 문장 종류를 구분하는 목적은 표를 채우는 것이 아니라 빠진 질문과 잘못 고정된 해법을 찾는 데 있다.

배송지 변경 정책은 상태 공백 없이 정해야 한다. 다음은 실제 서비스 사실이 아닌 이 예의 선택안이다.

결제 완료/미출고에서 변경을 허용하는 다른 정책도 가능하지만 배송요금 재산정·결제차액·출고 동시성의 규칙과 시험을 추가해야 한다. 이 표에서는 그런 동작을 가정하지 않았다.

자체 10점 문제

기능 요구사항, 품질속성과 제약을 비교하고 품질 시나리오 작성법 및 상충관계 관리방안을 설명하시오.

요구어는 비교와 설명이다. 기능의 행동, 품질의 조건·수준, 제약의 선택 경계를 표로 나누고 품질은 자극–환경–대상–반응–측정값으로 검증가능하게 만든다.

10점 풀이 방향과 모범답안 보기

답안 목차

1. 기능·품질속성·제약의 개념과 상호관계
2. 문장 구조·출처·대표 검증증거 비교
3. 품질 시나리오의 자극·환경·대상·반응·측정값
4. 설계안과 요구사항의 구분
5. 품질 상충, 우선순위와 잔여위험 관리
6. 추적성·시험·운영 재측정 통제

답안에 넣을 핵심 도식

세 종류 요구의 연결 그림에서 기능의 행동·결과, 품질속성의 조건·수준, 제약의 선택 경계·의무를 같은 업무 필요에 연결한다. 이 세 질문을 기준으로 설계 대안을 비교하고, 기능·품질·준수 수용시험을 모두 통과했는지 확인한다.

도식은 세 요구가 독립 목록이 아니라 하나의 필요를 서로 다른 질문으로 제한하고, 함께 설계 대안과 검증 증거를 결정한다는 점을 보여 준다.

모범답안

기능은 시스템이 수행할 행동이나 제공할 결과, 품질속성은 정한 조건에서 그 기능을 얼마나 잘 수행해야 하는지를 나타내는 성질이고, 제약은 법·계약·예산·호환성처럼 설계 선택범위를 제한하는 조건이다. 기능은 정상·예외 흐름, 품질은 측정 가능한 수준, 제약은 출처와 적용범위로 검증하며 세 종류는 서로 대체할 수 없다.

품질 요구는 자극, 환경, 대상, 기대 반응과 측정값을 포함한 시나리오로 구체화한다. 예를 들어 “혼잡시간 동시 사용자 3천 명에서 주문 조회의 95%를 2초 안에 응답”이라고 쓰면 부하 설계와 시험 기준이 된다. “서버 세 대”처럼 특정 구현을 요구로 제시하면 실제 목적을 확인해 장애 중 서비스 지속 같은 품질 요구와 설계 대안을 분리한다.

품질속성은 보안·성능·가용성·사용성·비용 사이에서 서로 상충할 수 있다. 법적·안전 한계와 치명적 실패를 우선하고 중요 업무 시나리오별 최소 수용수준을 정한 뒤 비용과 운영역량으로 대안을 비교한다. 결정에는 포기한 이점, 잔여위험과 운영 재측정 지표를 남기고 기능·품질·제약을 설계와 시험까지 추적한다.

자체 25점 문제

주문 서비스의 기능·성능·가용성·보안·법적 제약을 검증 가능한 요구로 구체화하고 상충하는 품질목표를 조정하는 절차를 설계하시오.

요구어는 구체화·조정·설계다. 요구 유형과 설계안을 혼동하지 않고 각 품질의 측정환경·수용수준과 상충·잔여위험을 연결한다.

25점 풀이 방향과 모범답안 보기

25점 답안 목차

1. 기능·품질·제약 분류
2. 품질 시나리오의 자극·환경·대상
3. 반응과 측정값·수용수준
4. 법·계약·기술 제약의 출처
5. 설계안과 요구 분리
6. 성능·가용성·보안 상충
7. 최소수준·우선순위·잔여위험
8. 시험·운영 재측정과 변경

25점 답안 도식

업무 필요의 질문	설계 대안 비교 뒤 얻을 증거
기능: 무엇을 하는가	기능시험의 정상·예외 결과
품질: 어떤 조건에서 얼마나 잘하는가	같은 환경·부하의 품질 측정
제약: 어떤 선택을 할 수 없는가	적용범위에 대한 제약 준수

대표 그림과 아래 주문 시나리오의 측정조건을 함께 사용한다.

25점 모범답안

주문 변경·조회 같은 행동은 기능 요구로, 혼잡시간 응답시간·장애 중 서비스 지속·권한 없는 접근 차단은 품질 요구로, 법·계약·예산·호환성은 설계 선택을 제한하는 제약으로 분리한다. 모호한 품질문장은 부하·환경·대상·반응·측정값을 포함한 시나리오로 바꾼다.

서버 수처럼 구현을 미리 고정한 문장은 실제 목적을 확인해 품질 요구와 설계 대안을 분리한다. 법적 제약은 출처·적용대상·예외를 확인해 근거 없는 기술선택과 구분한다.

법적·안전 한계와 치명적 실패를 먼저 지키고 중요 업무 시나리오별 최소 수용수준을 정한다. 성능·가용성·보안·비용 대안을 같은 조건에서 비교하고 선택한 이점, 포기한 이점, 잔여위험과 재검토 조건을 기록한다. 시험과 운영에서 같은 측정정의를 사용해 실제 결과가 수용수준을 만족하는지 재측정한다.

선택한 교육용 시나리오는 행사시간 동시 사용자 3000명에서 전체 조회 시도의 95% 이상이 2초 안에 정상 응답, 서버 1대 고장 시 새 조회가 30초 안에 재개, 타인 주문 변경은 허용 0건이다. 오류·시간초과를 95% 계산에서 빼지 않는다. 고장 중 재개시간과 월간 가용성은 다른 지표이므로 이 시험만으로 월간 가용성을 승인하지 않는다.

주소 변경은 앞의 상태표를 채택하고 매 요청 서버 권한검사를 유지한다. 권한검사를 생략해 응답을 빠르게 하는 대안은 기각한다. 다중 서버는 단일 서버 장애 대응을 위한 선택이며 공통 저장소 장애는 남은 위험이다. 동일 부하·주소 상태·권한 조합에서 목표를 시험하고, 고장전환 중 타인 주문이 수정되거나 응답 목표를 넘으면 배포를 보류한다.

출처와 적용 경계

기능·품질속성·제약과 품질 시나리오는 안정된 요구·아키텍처 기초개념이다. 주문 서비스의 부하·응답 수치는 자체 교육 가정이며 실제 서비스 SLA·법적 의무를 뜻하지 않는다.

자기교정과 조건 변경

동시 사용자가 크게 늘어나면? 동일 응답목표의 용량·비용 영향을 다시 분석하고 설계·시험 조건을 갱신한다.

법적 보관구역 제약이 해제되면? 기존 품질·비용·이전위험을 포함해 대안을 다시 비교한다.

보안 강화를 위해 추가 인증단계를 넣으면? 보안 향상과 응답·사용성 영향을 같은 시나리오에서 측정해 수용수준을 조정한다.

한 번에 되찾기

기능은 무엇을 하는지, 품질속성은 어떤 조건에서 얼마나 잘하는지, 제약은 선택을 무엇이 제한하는지 말한다. 측정 가능한 시나리오와 근거로 세 종류를 구분해야 설계와 검증이 이어진다.