이건 기능이 아닌데

의례 스펙, 기능요구사항 등을 정리한 문서를 보면 기능만 잔뜩 나열되어 있는 것은 매우 흔한 일입니다.

소프트웨어를 만든다고 하면 구현해야 할 기능만 알면 제대로 잘 만들 수 있을 것으로 생각하기 십상입니다. 상식적으로 생각해도 기능면 제대로 구현하면 되겠지요. 여기에 UI는 살짝 추가하고요.

하지만, 분석을 할 때 기능보다 더 중요한 것이 비기능 요구사항입니다. 즉, 기능은 아닌데, 요구사항 즉, 스펙인 겁니다. 기능이 중요하기는 하지만, 기능 하나가 잘못되면 이를 고치는 것은 그렇게 어렵지 않습니다. 그런데 비기능에서 잘못되면 소프트웨어를 완전히 뒤엎어야 하는 일이 발생할 수도 있습니다. 

이렇듯 비기능이 기능보다도 더 중요한 측면이 있는데, 눈에 바로 보이지 않는 다는 이유로 간과되기 쉽습니다. 그럼 이렇게 중요한 비기능 요구사항에는 어떤 것들이 있는지 몇 가지만 알아 보겠습니다.

첫째 성능입니다. 소프트웨어가 얼마나 빨리 반응을 보이며 단위 시간당 얼마나 많은 데이터를 처리해야 하는지 정의해야 합니다. 또한 이를 검증하기 위한 기준도 마련이 되어야 합니다.

둘째 안정성입니다. Database와 위젯 시계는 요구되는 그 안정성이 다릅니다. Database는 시스템이 정전이 되어도 데이트가 파손이 되어서는 안됩니다. 그러한 안정성을 보장하기 위한 요구사항도 자세히 기술이 되어야 합니다.

셋째 보안입니다. 데이터는 암호화 되어서 저장이 되어야 하는지? 암호키는 어떻게 보관을 하는지? 프로토콜은 암호화 되어야 하는지? 시스템은 인증을 거쳐서 접근해야 하는지? 등등의 보안 요구사항은 각 소프트웨어마다 다른 요구사항을 가지고 있습니다.

그 외에도 많은 비기능 요구사항은 있습니다. 가용성은 시스템이 24시간 동작하는 것인지 MS-Word처럼 필요할 때 사용하고 종료하는 것인지 기술합니다. 또, 이식성은 현재 지원해야 하는 것이 아니고 향후 미래에 Porting을 하기 용이하도록 만들기 위한 요구사항입니다. 미래에 Windows에서 Linux로 포팅을 할 수도 있고, 여러 언어를 지원하도록 확장할 수도 있습니다. 또 64bit를 지원할 수도 있고, Unicode를 지원하게 될 수도 있습니다. 따라서 미래에 어떻게 할지 계획이 아무것도 없다면 이식성을 정의할 수가 없습니다. 다국어, 개발표준, 메모리 사용제한, 소스코드 재사용성, 유지보수 편의성 등 많은 비기능 요구사항이 있습니다.

딱 보시면 아시겠지만, 하나하나가 잘못 적히면 완전히 소프트웨어 전체를 뒤집어야 하는 것들입니다. 이런 것들이 눈에 보이지 않는다고 기능만 보고 제품을 만들었다가는 앞은 안보고 땅만 보고 달리는 자동차와 같습니다. 조금만 고개를 들면 보이는 막다른 골목으로 가고 있을지도 모릅니다.

기능 신경쓰기도 바쁜데 이러한 수많은 비기능까지 어떻게 신경을 써서 만드냐고요?

그럼, 신경 안쓰고 그냥 만들면 그 요구사항이 사라지나요? 무시된겁니다. 요구사항을 고스란히 남아 있고 나중에 비용을 수십,수백,수천배를 치러야 합니다.

비기능 요구사항을 잘 적는 방법은 그러한 비기능 요구사항에 대하여 경험이 있을 수 있도록 소프트웨어를 개발한 상당한 경력이 필요하고, 적는 방법에 대하여 배우거나 학습이 필요합니다. 또, 이런 과정을 통해서 과거에 간과된 비기능 요구사항이 현재 얼마나 많은 손해를 끼치는 깨우치면서 배워나가게 됩니다. 하지만 이런 과정을 거쳐야 시행착오가 최소화 되지, 비기능 요구사항을 고려하지도 않는다면 항상 바쁘고 앞으로 잘 나아가지 못하는 굴레를 벗어나기 어려울 겁니다.