기능 vs 비기능 · Functional vs Non-functional

“동작을 정의하는 기능과 품질을 정의하는 비기능. 검수 분쟁은 대개 비기능에서 난다.”

동작이냐 품질이냐

기능 요구사항은 시스템이 무엇을 해야 하는지, 즉 입력에 대해 어떤 처리와 출력을 내놓는지를 정의한다. 회원 가입, 결제, 검색처럼 사용자가 실제로 수행하는 행위가 여기에 속한다.

비기능 요구사항은 그 동작이 어느 수준의 품질로 제공되어야 하는지를 정의한다. 얼마나 빠른가, 얼마나 안전한가, 얼마나 잘 견디는가가 비기능의 영역이다.

같은 결제 기능이라도 결제가 된다는 것은 기능이고, 천 명이 동시에 눌러도 일정 시간 안에 처리된다는 것은 비기능이다. 둘은 대체 관계가 아니라 한 요구의 서로 다른 면이다.

동작과 품질로 나눈 요구 분해

품질 속성을 나누는 틀

비기능 요구는 막연히 잘 만들어 달라는 기대로 흩어지기 쉬워, 품질 속성으로 분류해 다루는 것이 정석이다. 국제 표준인 ISO/IEC 25010은 성능 효율성·신뢰성·보안성·사용성·유지보수성·이식성 등으로 소프트웨어 품질을 구조화한다.

초기의 FURPS 모델도 기능·사용성·신뢰성·성능·지원성으로 요구를 갈라 보는 관점을 제시했다. 이런 틀의 가치는 빠진 품질 영역을 빈칸으로 드러내 준다는 데 있다.

분류 없이 비기능을 적으면 성능만 떠올리고 보안·유지보수성은 통째로 누락하기 쉽다.

언제 어느 쪽에 무게를 두는가

요구 추출 초기에는 기능을 폭넓게 식별하는 데 시간이 쏠리는 것이 자연스럽다. 사용자가 수행할 행위를 빠짐없이 그려야 시스템의 윤곽이 잡히기 때문이다.

그러나 설계로 넘어가는 시점부터는 비기능에 의도적으로 무게를 실어야 한다. 아키텍처는 대개 기능보다 비기능 요구가 결정하기 때문이다.

동시 사용자 규모, 응답 시간 목표, 보안 등급 같은 비기능 조건이 서버 구성과 데이터 구조를 좌우한다. 비기능을 뒤로 미루면 기능은 다 만들었는데 품질 기준을 못 맞춰 구조를 다시 짜는 사태가 벌어진다.

구분	기능	비기능
정의	무엇을 한다	어떤 품질로
예시	결제 처리	동시 천명 처리
판정	명확	수치 합의 필요
분쟁 위험	낮음	높음

기능과 비기능 비교

검수 분쟁은 비기능에서 난다

기능 요구는 충족 여부를 비교적 명확히 판정할 수 있다. 화면이 뜨고 처리가 되면 됐다고 본다.

분쟁이 집중되는 곳은 비기능이다. 빠르게, 안정적으로, 안전하게 같은 표현은 측정 기준 없이는 사람마다 다르게 해석되기 때문이다.

발주 측의 빠르게와 수행 측의 빠르게가 다를 때, 합의된 수치가 없으면 검수는 주관의 충돌로 번진다. 그래서 비기능 요구는 명세 단계에서 응답 시간·동시 처리량·복구 시간처럼 측정 가능한 값으로 적어 두어야 검수의 기준선이 선다.

현장에서 갈리는 지점

주니어는 기능 목록을 채우는 것으로 요구 정의를 끝냈다고 여긴다. 시니어는 그 목록 옆의 비어 있는 비기능 칸을 먼저 들여다본다.

둘의 차이는 보이는 동작을 적느냐, 보이지 않는 품질 기준까지 끌어내 수치화하느냐에 있다. 이해관계자는 성능·보안·가용성을 당연한 전제로 여겨 말로 꺼내지 않으므로, 이를 먼저 물어 측정 가능한 조건으로 못 박는 것이 분석가의 몫이다.

비기능을 공란으로 둔 명세는 후반에 추가 요구와 검수 분쟁으로 반드시 되돌아온다.

검수와 실무 함의

검수 기준선은 측정 가능한 비기능 명세 위에 세워야 분쟁을 줄인다. 기능은 통과 여부가 분명하지만, 비기능은 합의된 수치가 없으면 종료 자체가 흔들린다.

따라서 명세 단계에서 각 품질 속성에 목표값과 측정 방법을 함께 적고, 어떤 수준까지 보장하는지를 문서로 남겨야 한다. 합의 이후 솟아오르는 추가 요구는 대개 비기능이며, 일정 폭 안의 조정으로 흡수하되 경계를 넘는 요건은 무리하게 떠안기보다 운영 단계의 개선으로 이관하는 협상이 정석이다.

기능과 비기능을 같은 무게로 명세할 수 있어야 검수가 정리되고 산정의 정확도가 올라간다.