비기능 요구사항

비기능 요구사항이란

비기능 요구사항(Non-functional Requirement, NFR)은 시스템이 무엇을 하는가가 아니라, 그 기능을 어떤 품질 수준으로 제공해야 하는가를 규정하는 요구사항이다. 기능 요구사항이 화면·처리·연산 같은 동작 자체를 정의한다면, 비기능 요구사항은 성능·보안·사용성·신뢰성·유지보수성·이식성 같은 속성으로 그 동작의 질을 제약한다.

동일한 로그인 기능이라도 평균 응답이 1초 안이어야 하는지, 만 명이 동시에 접속해도 견뎌야 하는지, 비밀번호를 어떤 강도로 보호해야 하는지는 모두 비기능 영역에서 결정된다. 기능이 통과해도 비기능이 무너지면 사용자에게는 결함으로 체감되기 때문에, 분석·설계 단계부터 명시적으로 다뤄야 한다.

품질 모델로 본 분류

비기능 요구사항을 체계적으로 다루기 위한 대표적 기준이 ISO/IEC 25010 품질 모델이다. 이 모델은 제품 품질을 성능 효율성, 신뢰성, 보안성, 사용성, 호환성, 유지보수성, 이식성, 기능 적합성 같은 여러 특성으로 나누고, 각 특성을 다시 세부 부특성으로 나누어 점검할 수 있게 한다.

분류 체계를 활용하면 요구사항을 누락 없이 펼쳐 볼 수 있고, 이해관계자마다 다르게 부르는 품질 개념을 공통 언어로 정렬할 수 있다. FURPS 같은 점검 약어도 같은 목적의 보조 도구로, 비기능 항목을 빠뜨리지 않고 훑는 체크리스트 역할을 한다.

측정 가능해야 통제된다

비기능 요구사항의 가장 흔한 실패는 정성적 표현에 머무는 것이다. 빠르게, 안전하게, 쉽게 같은 서술은 검증할 수 없어 합의의 근거가 되지 못한다.

응답 시간은 초 단위 목표로, 가용성은 운영 기준 비율로, 동시 처리량은 구체적 단위로 환산해야 인수 시점에 통과 여부를 판정할 수 있다. 측정 지표와 측정 조건이 함께 기술되지 않은 비기능 항목은 사실상 통제 불가능한 요구사항이며, 검수 단계에서 분쟁의 씨앗이 된다.

정량화는 개발팀에게는 설계 목표를, 발주 측에게는 검수 기준을 동시에 제공한다.

설계와 아키텍처를 좌우

비기능 요구사항은 개별 화면이 아니라 시스템의 구조 전체를 결정한다. 높은 가용성을 요구하면 이중화와 장애 복구 설계가 따라오고, 대규모 동시 접속을 전제하면 확장 가능한 아키텍처와 캐싱 전략이 필요하다.

이런 속성은 코드 한 줄을 고쳐 충족되는 것이 아니라, 초기 구조 선택에 깊이 박히기 때문에 뒤늦게 추가하면 비용이 급격히 커진다. 따라서 비기능 요구사항은 기능 명세보다 앞서 또는 함께 확정되어야 하며, 설계 결정의 근거 문서로 남겨 두는 편이 안전하다.

상충과 우선순위 조정

비기능 요구사항은 서로 독립적이지 않고 자주 충돌한다. 보안을 강화하면 처리 단계가 늘어 성능이 떨어지고, 이식성을 높이면 특정 환경에 최적화한 성능을 포기해야 하는 식이다.

모든 품질 속성을 동시에 최고 수준으로 끌어올리는 설계는 존재하지 않으므로, 어떤 속성을 우선할지 합의하는 과정이 분석 단계의 핵심이 된다. 이 균형점을 명문화하지 않으면 개발 도중 임의의 절충이 일어나 누구도 의도하지 않은 품질로 시스템이 굳어진다.

우선순위는 비즈니스 가치와 위험을 기준으로 정렬해 두어야 한다.

요구사항 명세서에 통합

비기능 요구사항은 별도의 부록으로 밀려나기 쉽지만, 요구사항 명세서 안에 기능과 동등한 비중으로 기록되어야 관리된다. 각 항목은 적용 범위, 측정 지표, 목표값, 검증 방법을 갖춘 형태로 작성해 추적 가능성을 확보한다.

이렇게 정리해 두면 변경관리 과정에서 어떤 비기능 항목이 영향을 받는지 식별하기 쉽고, 인수 테스트의 체크리스트로 곧장 활용할 수 있다. 명세에 자리 잡지 못한 비기능 요구사항은 구현 단계에서 우선순위에 밀려 사라지고, 운영에 들어가서야 결함으로 드러나는 경우가 많다.