비기능 요구사항 정의서 템플릿: MVP·SaaS 외주개발 성능·보안·운영 기준 잡는 법
기능목록만 정리한 상태라면 외주 견적은 비교하기 어렵고, 검수 기준도 흔들립니다. 비기능 요구사항 정의서는 ‘어떤 기능을 만들 것인가’가 아니라 ‘그 기능이 어느 정도 빠르고, 안전하고, 장애에 대비되어 있으며, 운영자가 확인할 수 있어야 하는가’를 수치와 증빙 방식으로 합의하는 문서입니다. MVP라도 최소한 성능, 보안, 가용성, 백업, 로그, 운영 인수인계 기준은 비워두지 않는 편이 안전합니다.
창업팀과 PM이 자주 겪는 문제는 기능이 부족해서가 아니라 기준이 모호해서 생깁니다. 예를 들어 ‘관리자 대시보드 개발’이라는 기능은 누구나 이해합니다. 하지만 동시에 30명이 접속해도 되는지, 엑셀 다운로드가 3초 안에 끝나야 하는지, 고객 개인정보 조회 기록을 남겨야 하는지, 장애가 나면 누가 몇 시간 안에 복구해야 하는지는 기능목록만으로 알 수 없습니다. 이 공백이 출시 직전 성능개선비, 서버 재구성비, 보안 조치비, 유지보수 분쟁으로 바뀝니다.
이 글은 대기업 수준의 두꺼운 NFR 문서를 만들자는 이야기가 아닙니다. 정부지원사업 MVP, 초기 SaaS, B2B 업무 자동화, AI 서비스 외주개발에서 실제로 견적과 검수에 쓸 수 있는 ‘최소 운영 기준’ 중심으로 정리했습니다. 전체 요구사항 문서의 구조가 아직 없다면 먼저 요구사항 명세서 템플릿과 실전 예시를 보고 기능 요구사항을 정리한 뒤, 본문의 비기능 요구사항 표를 붙이는 방식이 좋습니다.
1. 비기능 요구사항은 고급 문서가 아니라 검수 가능한 운영 기준이다
비기능 요구사항, 즉 NFR은 성능, 보안, 신뢰성, 사용성, 확장성, 유지보수성, 호환성처럼 서비스의 품질을 정의하는 요구사항입니다. 기능 요구사항이 ‘회원은 이메일로 로그인할 수 있다’라면, 비기능 요구사항은 ‘로그인 API는 지정된 테스트 조건에서 p95 800ms 이하로 응답한다’, ‘관리자 로그인은 2단계 인증 또는 이에 준하는 보완 통제를 적용한다’, ‘개인정보 조회 이력은 운영자가 추적할 수 있어야 한다’처럼 표현됩니다.
여기서 핵심은 멋진 용어가 아니라 측정 가능성입니다. ‘빠르게’, ‘안전하게’, ‘안정적으로’는 계약서와 검수표에서 거의 힘을 쓰지 못합니다. 반대로 ‘테스트 데이터 10만 건, 동시 사용자 50명, 핵심 API p95 1.5초 이하, 오류율 1% 이하, 테스트 결과 리포트 제출’처럼 쓰면 개발사도 작업량을 산정할 수 있고 발주자도 합격·보류를 판단할 수 있습니다.
좋은 비기능 요구사항은 기술팀을 괴롭히는 문서가 아니라, 창업자와 PM이 ‘어디까지가 이번 MVP이고 어디부터가 다음 단계인가’를 결정하기 위한 비용·리스크 조절 장치입니다.
2. 기능목록만으로 견적이 달라지는 이유
같은 ‘SaaS 관리자 화면’이라도 개발 범위는 크게 달라질 수 있습니다. 단순 CRUD 화면만 만들면 빠르게 끝납니다. 하지만 역할별 권한, 감사 로그, 대량 다운로드 제한, 실패 알림, 백업 복구, 배포 자동화, 모니터링, 보안 헤더, 취약점 점검, 성능 테스트까지 포함하면 완전히 다른 프로젝트가 됩니다. 어느 쪽이 맞는지는 사업 단계에 따라 다르지만, 둘을 같은 견적서로 비교하면 안 됩니다.
| 모호한 요청 | 발생할 수 있는 해석 차이 | NFR로 바꾸면 |
|---|---|---|
| 서비스가 느리지 않게 해주세요 | 개발사는 로컬 테스트 기준, 발주자는 실제 사용자 기준으로 생각할 수 있음 | 핵심 화면 5개, 테스트 데이터량, 동시 사용자 수, p95 응답시간, 측정 도구를 명시 |
| 보안은 기본으로 해주세요 | HTTPS만 의미할 수도 있고 권한·로그·암호화·취약점 조치까지 의미할 수도 있음 | 인증, 권한, 개인정보 저장, 접속기록, 관리자 접근, 취약점 점검 범위를 분리 |
| 장애 나면 대응해주세요 | 하자보수인지 운영 SLA인지, 야간 대응인지 구분되지 않음 | 장애 등급, 응답시간, 복구 목표, 연락 채널, 유지보수 계약 포함 여부를 명시 |
| 백업은 해주세요 | 백업 설정만인지 실제 복구 테스트까지인지 불분명 | 백업 주기, 보관 기간, RPO, RTO, 복구 리허설 증빙을 명시 |
외주개발에서는 이 차이가 곧 비용 차이입니다. 따라서 견적을 요청할 때는 ‘기본 구현’과 ‘검수 가능한 NFR 포함 구현’을 나눠 달라고 요청하는 편이 좋습니다. 그러면 무조건 비싼 업체를 고르거나, 반대로 가장 싼 견적을 선택했다가 운영 기준이 빠지는 실수를 줄일 수 있습니다.
3. 비기능 요구사항 정의서 템플릿: 최소 필드
아래 템플릿은 MVP·SaaS 외주개발에서 바로 복사해 사용할 수 있는 최소 구조입니다. 모든 칸을 처음부터 완벽하게 채우려고 하지 말고, ‘미정’이라고 두기보다 가정과 제외 범위를 적는 데 집중하세요.
| 필드 | 작성 방법 | 예시 |
|---|---|---|
| 요구사항 ID | 영역별 번호를 붙여 추적 | NFR-PER-001, NFR-SEC-003 |
| 영역 | 성능, 보안, 가용성, 백업, 로그, 유지보수성 등 | 성능 |
| 대상 기능 | 모든 기능이 아니라 핵심 시나리오 중심 | 로그인, 대시보드 조회, 보고서 생성 |
| 사용자·데이터 가정 | 동시 사용자, 총 계정 수, 데이터 건수, 파일 크기 | 동시 50명, 고객 1만 명, 거래 10만 건 |
| 목표값 | 숫자와 허용 조건으로 작성 | p95 1.5초 이하, 오류율 1% 이하 |
| 측정 환경 | 개발 PC가 아니라 스테이징·운영 유사 환경을 명시 | 스테이징 서버, 서울 리전, 테스트 계정 |
| 검수 방법 | 도구, 테스트 절차, 합격 기준 | 부하테스트 리포트, 모니터링 캡처 |
| 증빙 산출물 | 문서, 로그, 대시보드, 리포트 | 테스트 결과 PDF, 설정값 캡처, 운영 매뉴얼 |
| 제외 범위 | 이번 단계에서 하지 않는 것을 명시 | 대규모 오토스케일링은 유료 전환 전 재검토 |
| 책임 주체 | 개발사, 발주사, 클라우드 계정 소유자, 운영자 | 개발사는 설정, 발주사는 계정·비용 승인 |
이 템플릿의 장점은 논쟁을 줄인다는 점입니다. ‘성능이 안 나온다’가 아니라 ‘NFR-PER-001의 테스트 데이터 조건에서 p95 목표를 넘었다’고 말할 수 있어야 수정 범위와 추가비 판단이 쉬워집니다.
4. 단계별로 어디까지 정의해야 할까
모든 MVP가 높은 가용성, 자동 확장, 무중단 배포, 보안 인증 수준을 갖춰야 하는 것은 아닙니다. 오히려 초기 검증 단계에서 과도한 NFR을 요구하면 핵심 기능 검증에 쓸 예산이 줄어듭니다. 다만 ‘이번 단계에서는 제외한다’는 사실을 문서에 남겨야 다음 단계 비용을 예측할 수 있습니다.
| 단계 | 목표 | 반드시 적을 NFR | 주의할 점 |
|---|---|---|---|
| PoC | 기술 가능성 검증 | 데모 환경, 테스트 데이터, 실패 시 대체 시나리오 | 실사용자·개인정보 투입을 전제로 쓰지 않기 |
| 정부지원사업 MVP | 시연, 중간점검, 최종보고 대응 | 기본 보안, 테스트 계정, 배포 URL, 산출물, 검수 시나리오 | 공고·협약 조건이 우선이며 실서비스 수준과 구분 필요 |
| 클로즈드 베타 | 제한된 실제 사용자 검증 | 개인정보 처리, 백업, 모니터링, 오류 알림, 장애 대응 | 데이터 삭제·문의 대응·운영자 권한을 미리 정해야 함 |
| 유료 SaaS | 고객 계약과 반복 운영 | SLO, 장애 등급, RTO/RPO, 감사 로그, 권한, 비용 알림, 확장 계획 | SLA와 유지보수 계약 범위를 별도 문서로 연결해야 함 |
정부지원사업의 경우 비기능 요구사항은 ‘선정 가능성을 보장하는 문서’가 아닙니다. 그러나 선정 후 개발 범위, 외주 견적, 최종 산출물 설명, 운영 로드맵을 정리하는 데 유용합니다. 시연용 MVP라면 ‘실서비스 전 추가로 필요한 NFR’ 목록을 따로 두는 것이 좋습니다.
5. 영역별 작성 기준과 예시
5-1. 성능: 평균이 아니라 p95와 조건을 적는다
성능 요구사항에서 가장 흔한 실수는 ‘평균 응답속도 2초’처럼 쓰는 것입니다. 평균은 일부 사용자의 극단적으로 느린 경험을 가릴 수 있습니다. MVP 단계에서는 모든 API를 세밀하게 측정하기보다 사용자가 가장 자주 쓰거나 매출·업무에 직접 연결되는 화면을 골라 p95 기준으로 작성하는 편이 현실적입니다. p95는 100번의 요청 중 느린 5번을 제외한 나머지 대부분의 응답시간을 보는 방식으로 이해하면 됩니다.
| 항목 | 작성 예시 | 검수 증빙 |
|---|---|---|
| 핵심 화면 응답 | 로그인, 프로젝트 목록, 대시보드 조회는 스테이징 환경에서 p95 1.5초 이하 | 부하테스트 결과, APM 캡처 |
| 대량 작업 | 보고서 1만 건 다운로드는 30초 이내 시작 또는 비동기 처리 전환 | 테스트 파일, 작업 로그 |
| 동시 사용자 | 동시 50명 조회 중심 사용 시 오류율 1% 이하 | JMeter, k6 등 테스트 리포트 |
| 프론트 성능 | 첫 화면 주요 콘텐츠가 과도하게 늦지 않도록 이미지·스크립트 최적화 적용 | Lighthouse 또는 브라우저 성능 캡처 |
숫자는 서비스마다 달라야 합니다. 내부 관리자 도구와 소비자용 랜딩페이지, AI 응답 서비스, 대량 데이터 분석 SaaS의 기준이 같을 수 없습니다. 중요한 것은 ‘누가, 어떤 데이터로, 어느 환경에서 측정하는가’를 함께 적는 것입니다.
5-2. 보안·개인정보: 기본 보안과 법적 검토 대상을 나눈다
보안 요구사항은 ‘기본 보안 적용’이라는 한 줄로 끝내면 안 됩니다. 최소한 인증, 권한, 입력값 검증, 개인정보 저장·전송, 관리자 접근, 접속기록, 외부 API 키 관리, 배포 계정 권한을 나눠야 합니다. OWASP ASVS처럼 웹 애플리케이션 보안 요구사항을 통제 항목으로 나누는 기준을 참고하면, 개발사와 발주자가 같은 언어로 논의하기 쉽습니다.
| 보안 항목 | MVP 기준 예시 | 주의 |
|---|---|---|
| 인증 | 비밀번호 정책, 세션 만료, 소셜 로그인 사용 시 리다이렉트 URI 제한 | 민감 서비스는 2단계 인증 또는 별도 통제 검토 |
| 권한 | 관리자, 일반 사용자, 고객사 관리자 등 역할별 접근 제어 | 프론트 화면 숨김만으로 권한 통제했다고 보면 안 됨 |
| 개인정보 | 수집 항목, 저장 위치, 암호화 대상, 삭제 요청 처리 방식을 문서화 | 법률 자문이 필요한 항목은 개발 견적과 분리 |
| 접속기록 | 관리자 로그인, 개인정보 조회·수정·다운로드 이력을 남김 | 보관 기간과 열람 권한을 함께 정해야 함 |
| 비밀관리 | API 키, DB 비밀번호, AI API 키를 소스코드에 직접 저장하지 않음 | 인수인계 시 키 회전 절차가 필요 |
개인정보를 처리한다면 국내 개인정보 보호 관련 기준을 별도로 확인해야 합니다. 이 글의 예시는 법률 자문이 아니라 개발 요구사항 정리를 돕기 위한 기준입니다. 주민등록번호, 결제정보, 의료·민감정보, 미성년자 정보, B2B 고객사의 영업 데이터가 포함된다면 초기 MVP라도 보안·법무 검토 범위를 따로 잡는 것이 안전합니다.
5-3. 가용성·장애 대응: SLA가 아니라도 SLO는 필요하다
초기 SaaS가 고객에게 공식 SLA를 약속하지 않더라도 내부 SLO는 필요합니다. SLO는 서비스가 어느 정도 정상 동작해야 하는지에 대한 내부 목표입니다. 예를 들어 월 30일 기준 99.9% 가용성은 단순 환산 시 약 43분의 허용 불가용 시간입니다. 이 숫자가 부담스럽다면 99.5%나 99%를 선택할 수 있지만, 그 선택이 고객 경험과 계약 리스크에 어떤 영향을 주는지는 알고 있어야 합니다.
| 가용성 목표 | 월 30일 기준 단순 환산 | 적합한 상황 |
|---|---|---|
| 99% | 약 7.2시간 불가용 | 내부 도구, 시연용 MVP, 초기 검증 |
| 99.5% | 약 3.6시간 불가용 | 제한된 베타, 업무 영향이 낮은 SaaS |
| 99.9% | 약 43분 불가용 | 유료 B2B SaaS, 고객 업무에 직접 연결되는 기능 |
| 99.95% 이상 | 약 21.6분 이하 | 고가용성 아키텍처와 운영 인력이 필요한 영역 |
가용성은 서버 사양만으로 달성되지 않습니다. 배포 방식, 모니터링, 장애 알림, 롤백, 백업, 외부 API 의존성, 담당자 연락 체계가 함께 있어야 합니다. 유지보수 계약까지 연결해야 한다면 외주개발 유지보수 SLA 설계 가이드를 함께 확인해 장애 등급과 응답시간을 분리해두는 것이 좋습니다.
5-4. 백업·복구: 백업 설정이 아니라 복구 가능성을 검수한다
백업 요구사항은 ‘매일 백업’으로 끝나면 부족합니다. 실제로 중요한 것은 장애나 삭제 사고가 발생했을 때 어느 시점의 데이터까지 되돌릴 수 있는지, 복구에 얼마나 걸리는지입니다. 이때 쓰는 기준이 RPO와 RTO입니다. RPO는 감수 가능한 데이터 손실 시간, RTO는 서비스를 복구하는 데 허용되는 시간입니다.
| 항목 | 질문 | MVP 예시 |
|---|---|---|
| 백업 주기 | 얼마나 자주 백업할 것인가 | 운영 DB 일 1회 자동 백업 |
| 보관 기간 | 며칠 또는 몇 주 동안 보관할 것인가 | 사업·법무·비용 기준에 따라 별도 합의 |
| RPO | 최대 어느 정도 데이터 손실을 감수할 것인가 | 초기 MVP는 24시간, 유료 서비스는 더 짧게 검토 |
| RTO | 장애 후 몇 시간 안에 복구할 것인가 | 초기 MVP는 영업일 내, 유료 고객은 등급별 정의 |
| 복구 테스트 | 백업이 실제로 복구되는지 확인했는가 | 스테이징 환경 복원 결과 캡처 제출 |
백업은 비용이 들고, 복구 테스트도 시간이 듭니다. 하지만 복구가 안 되는 백업은 운영 기준으로 보기 어렵습니다. 더 구체적인 자동화와 증빙 방식은 백업 복원 테스트 자동화 가이드를 참고해 별도 운영 과제로 분리할 수 있습니다.
5-5. 로그·모니터링·관리자 기능: 운영자가 볼 수 있어야 한다
초기 서비스에서 자주 빠지는 항목이 운영 관측성입니다. 사용자는 오류가 났다고 말하지만 운영자는 어떤 요청이 실패했는지, 어느 버전에서 발생했는지, 외부 API가 실패했는지, DB가 느린지 확인할 수 없는 경우가 많습니다. 기능은 완성됐는데 운영이 불가능한 상태입니다.
- 애플리케이션 로그: 오류, 경고, 주요 업무 이벤트를 추적할 수 있어야 합니다.
- 감사 로그: 관리자 로그인, 권한 변경, 개인정보 조회, 결제·정산 관련 조작을 남깁니다.
- 모니터링: CPU, 메모리, DB 연결, 응답시간, 오류율, 큐 적체를 확인합니다.
- 알림: 장애 기준을 넘으면 이메일, 메신저, SMS 등 합의한 채널로 알립니다.
- 관리자 대시보드: 고객 상태, 실패 작업, 재처리 대상, 사용량, 과금 관련 데이터를 운영자가 확인합니다.
AgentMit이 BizMit 기반 SaaS, 관리자 대시보드, 업무 자동화, AI 기능을 설계할 때도 이 부분을 별도 화면으로 분리해 봅니다. 특히 AI API를 쓰는 서비스는 응답 지연, 토큰 비용, 실패 재시도, 프롬프트·응답 로그의 개인정보 포함 여부를 NFR로 적어야 운영비와 보안 리스크를 동시에 관리할 수 있습니다.
5-6. 유지보수성·인수인계: 외주개발 후에도 고칠 수 있어야 한다
유지보수성은 코드 내부 품질처럼 들리지만, 발주자 입장에서는 ‘외주개발이 끝난 뒤에도 다른 개발자가 이해하고 수정할 수 있는가’의 문제입니다. 소스코드 저장소, README, 환경변수 목록, 배포 절차, DB 스키마, API 문서, 관리자 계정, 클라우드 권한, 외부 서비스 계정 소유권을 산출물로 명시해야 합니다.
| 항목 | 검수 기준 예시 |
|---|---|
| 소스코드 | 발주자 소유 저장소에 최신 코드와 배포 브랜치가 존재 |
| 환경 설정 | 개발·스테이징·운영 환경변수 목록과 비밀값 관리 위치 문서화 |
| 배포 | 배포 절차, 롤백 절차, 배포 담당자 권한 설명 |
| DB | 주요 테이블 설명, 마이그레이션 방법, 백업 위치 문서화 |
| API | 주요 API 명세, 인증 방식, 오류 코드 설명 |
| 운영 매뉴얼 | 자주 발생하는 오류, 재처리 방법, 문의 대응 절차 포함 |
6. 외주개발 견적 요청서에 넣는 방식
비기능 요구사항은 별도 문서로만 두면 견적에 반영되지 않을 수 있습니다. 견적 요청서, 제안서, 계약서, 검수표에 같은 ID로 연결해야 합니다. 예를 들어 NFR-PER-001은 견적서의 성능 테스트 항목, 개발 일정의 테스트 주간, 검수표의 부하테스트 리포트와 연결되어야 합니다.
- 기능목록 옆에 NFR ID를 붙입니다. 로그인 기능 옆에 인증·세션·응답속도 요구사항을 연결합니다.
- 기본 범위와 옵션 범위를 나눕니다. 예를 들어 기본은 일 1회 백업, 옵션은 복구 리허설 자동화처럼 분리합니다.
- 테스트 환경을 명시합니다. 운영 서버에서 무리하게 부하테스트를 하지 않도록 스테이징 환경을 합의합니다.
- 증빙 산출물을 계약서에 적습니다. 문서, 로그, 테스트 리포트, 캡처, 계정 인수인계 목록을 남깁니다.
- 예외와 재검토 조건을 적습니다. 외부 API 장애, 클라우드 비용 제한, 데이터량 급증 같은 조건을 미리 둡니다.
견적이 너무 올라갈까 걱정된다면 ‘반드시 필요한 NFR’과 ‘출시 후 3개월 내 개선할 NFR’을 분리하면 됩니다. 초기 SaaS에서 모든 것을 최고 수준으로 만들 필요는 없습니다. 다만 고객 데이터가 들어가는 순간 보안·백업·로그는 미룰 수 있는 항목인지 신중하게 봐야 합니다.
7. 바로 쓰는 비기능 요구사항 정의서 샘플
아래는 초기 B2B SaaS를 가정한 샘플입니다. 그대로 복사하기보다 괄호 안의 수치를 서비스 상황에 맞게 조정하세요.
| ID | 영역 | 요구사항 | 검수 방법 |
|---|---|---|---|
| NFR-PER-001 | 성능 | 로그인, 프로젝트 목록, 대시보드 조회는 테스트 데이터 10만 건, 동시 사용자 50명 조건에서 p95 1.5초 이하를 목표로 한다. | 스테이징 부하테스트 리포트 제출 |
| NFR-PER-002 | 대량 작업 | 엑셀 다운로드가 30초를 초과할 가능성이 있는 경우 비동기 처리 또는 진행 상태 표시를 제공한다. | 대량 데이터 테스트 화면 캡처 |
| NFR-SEC-001 | 인증 | 관리자와 일반 사용자는 권한을 분리하고, 서버 API에서 권한을 검증한다. | 권한별 접근 테스트 결과 |
| NFR-SEC-002 | 개인정보 | 개인정보 수집 항목, 저장 위치, 접근 가능 역할, 삭제 요청 처리 방식을 운영문서에 포함한다. | 개인정보 처리 흐름 문서 |
| NFR-LOG-001 | 감사 로그 | 관리자 로그인, 권한 변경, 고객정보 조회·수정 이벤트를 추적 가능한 형태로 남긴다. | 샘플 로그와 조회 화면 |
| NFR-REL-001 | 가용성 | 정기 점검 시간을 제외하고 월간 내부 목표 가용성을 정의하며, 장애 발생 시 공지·복구 절차를 문서화한다. | 운영 매뉴얼, 장애 공지 템플릿 |
| NFR-BCK-001 | 백업 | 운영 DB 백업 주기, 보관 기간, RPO, RTO를 정의하고 스테이징 환경에서 복구 가능 여부를 확인한다. | 백업 설정 캡처, 복구 테스트 결과 |
| NFR-OPS-001 | 모니터링 | 오류율, 응답시간, 서버 자원, DB 연결 상태를 확인할 수 있는 대시보드 또는 로그 조회 수단을 제공한다. | 모니터링 화면 캡처 |
| NFR-MNT-001 | 인수인계 | 소스코드, 배포 절차, 환경변수, 외부 서비스 계정, 관리자 계정, DB 구조 설명을 인수인계한다. | 인수인계 체크리스트 서명 |
| NFR-COST-001 | 비용 | 클라우드와 외부 API의 월 예상 비용 산정 기준을 남기고, 예산 초과 알림 또는 확인 절차를 정한다. | 비용 산정표, 알림 설정 캡처 |
8. 작성 전 최종 체크리스트
- 핵심 사용자 시나리오 3~5개를 골랐는가?
- 동시 사용자, 총 사용자, 데이터 건수, 파일 크기 등 테스트 가정을 적었는가?
- 응답속도는 평균만이 아니라 p95 또는 유사 기준으로 정의했는가?
- 개인정보 처리 항목과 관리자 접근권한을 분리했는가?
- 접속기록과 감사 로그의 대상 이벤트를 정했는가?
- 백업 주기뿐 아니라 RPO, RTO, 복구 테스트 여부를 적었는가?
- 장애 등급, 연락 채널, 응답시간, 유지보수 포함 여부를 구분했는가?
- 소스코드, 계정, 배포, DB, 운영문서 인수인계를 산출물로 적었는가?
- 이번 MVP에서 제외하는 고가용성·자동확장·보안 인증 범위를 명시했는가?
- 견적서, 계약서, 검수표에서 같은 NFR ID를 사용했는가?
9. AgentMit 관점: 처음부터 무겁게 만들지 말고, 나중에 증명 가능하게 설계한다
AgentMit은 비기능 요구사항을 과도한 엔터프라이즈 문서가 아니라, MVP 단계에서 반드시 정해야 하는 최소 운영 기준으로 봅니다. 특히 BizMit 기반의 SaaS, 관리자 대시보드, 업무 자동화, AI 서비스 개발에서는 기능 구현과 동시에 ‘운영자가 무엇을 볼 수 있어야 하는가’, ‘데이터가 어디에 남는가’, ‘장애 때 무엇을 복구할 수 있는가’를 함께 설계해야 출시 후 재작업이 줄어듭니다.
다만 모든 프로젝트에 같은 수준의 NFR을 적용하지는 않습니다. PoC라면 데모 안정성과 데이터 분리를 우선하고, 정부지원사업 MVP라면 시연·검수 산출물을 우선하며, 유료 SaaS라면 권한·감사 로그·백업·장애 대응을 더 강하게 잡습니다. 성능 목표 수치, 클라우드 구조, 관리자 화면, 운영 자동화 범위를 함께 산정해야 한다면 BizMit 서비스 구성을 참고하거나 프로덕션 문의에서 현재 기능목록과 함께 NFR 초안을 공유하면 논의가 훨씬 빨라집니다.
FAQ
Q1. MVP도 비기능 요구사항 정의서를 꼭 써야 하나요?
모든 항목을 엔터프라이즈 수준으로 작성할 필요는 없습니다. 다만 응답속도, 동시사용자 가정, 개인정보 처리 여부, 백업, 장애 대응, 검수 증빙은 최소한으로 적어야 견적 비교와 출시 후 책임 범위를 정할 수 있습니다.
Q2. 성능 요구사항은 몇 초, 몇 명 동시접속으로 잡아야 하나요?
정답 숫자부터 정하면 과하거나 부족해지기 쉽습니다. 핵심 화면 3~5개, 예상 사용자군, 테스트 데이터량, 피크 시간대, 허용 가능한 대기시간을 먼저 정한 뒤 p95 응답시간, 오류율, 동시 사용자 수를 합의하는 방식이 안전합니다.
Q3. 외주개발 계약서에 비기능 요구사항을 넣으면 견적이 많이 올라가나요?
성능 테스트, 보안 점검, 모니터링, 백업 복구 리허설까지 포함하면 작업량은 늘어납니다. 대신 무엇이 기본 범위이고 무엇이 옵션인지 분리되므로 출시 직전 추가비 논쟁을 줄이는 효과가 큽니다.
Q4. 개인정보가 많지 않은 초기 SaaS도 보안 요구사항이 필요한가요?
필요합니다. 회원가입, 로그인, 결제, 문의, 관리자 조회만 있어도 접근권한, 인증, 암호화, 접속기록, 데이터 삭제 기준이 필요합니다. 민감정보나 B2B 고객 데이터가 있으면 별도 법률·보안 검토가 필요합니다.
Q5. 정부지원사업 MVP 검수에도 비기능 요구사항이 도움이 되나요?
도움이 됩니다. 공고와 협약 조건이 우선이지만, 비기능 요구사항은 시연용 MVP와 실서비스 범위를 구분하고 테스트 결과, 배포 환경, 운영문서, 보안 조치 같은 산출물 설명을 명확히 만드는 데 유용합니다.
참고한 기준과 적용 범위
아래 자료들은 그대로 인증 수준을 요구하라는 의미가 아닙니다. 초기 SaaS와 MVP에 맞게 낮춰 적용할 수 있는 품질·보안·운영 항목을 뽑는 기준으로 참고했습니다.
- ISO/IEC 25010:2023 Product Quality Model — 소프트웨어 품질 속성 분류 참고
- OWASP Application Security Verification Standard — 웹 보안 요구사항과 검수 항목 참고
- NIST Cybersecurity Framework 2.0 — 보안 리스크 관리 범주 참고
- Google SRE Workbook: Error Budget Policy — SLO와 오류 예산 개념 참고
- AWS Well-Architected Reliability Pillar — 클라우드 신뢰성과 복구 설계 관점 참고
- 개인정보의 안전성 확보조치 기준 및 개인정보보호위원회 ISMS-P 제도 소개 — 개인정보 처리 서비스의 보호대책 범주 참고
