공공 SI의 검수 분쟁은 대부분 비기능 요구사항에서 생긴다. 제안요청서에 "안정적인 성능", "충분한 보안"처럼 적힌 문장은 사업이 끝날 때 누가 어떻게 확인할지 정해져 있지 않기 때문이다. 이 글은 제안요청서의 모호한 비기능 요구사항을 측정 가능한 문장으로 바꾸고, 요구사항마다 검증 방법·시점·증빙을 미리 설계하는 방법을 정리한 것이다.
비기능 요구사항은 어디에 있나
공공 제안요청서는 요구사항을 보통 다음처럼 나눈다. 이 중 기능 요구사항(SFR)을 뺀 나머지가 비기능 요구사항이고, 아키텍처와 검수 기준을 직접 바꾼다.
| 분류 | 흔한 ID 접두어 | 아키텍처에 주는 영향 |
|---|---|---|
| 시스템 장비 구성 | ECR | 서버 대수, 이중화, 망 구성 |
| 성능 | PER | 응답 시간, 처리량, 동시 사용자 |
| 인터페이스 | SIR | 연계 방식, 주기, 장애 시 처리 |
| 데이터 | DAR | 이관 범위, 정합성, 보관 기간 |
| 테스트 | TER | 시험 종류, 환경, 합격 기준 |
| 보안 | SER | 인증, 암호화, 접근 통제, 보안약점 진단 |
| 품질 | QUR | 웹 접근성, 호환성, 가용성, 사용성 |
| 제약사항 | COR | 표준 프레임워크, 지정 DBMS, 운영 환경 |
착수 첫 주에 이 항목들을 모두 뽑아 한 표에 모으는 것부터 시작한다. 기능 요구사항 사이에 숨은 비기능 요구사항("조회는 즉시 처리되어야 한다")도 함께 옮긴다.
모호한 문장을 측정 가능한 문장으로
비기능 요구사항 한 줄은 다섯 칸을 채워야 검증할 수 있다.
- 대상: 어떤 화면, 기능, 구간인가
- 조건: 언제, 어떤 부하와 데이터에서인가
- 기준값: 숫자와 단위, 통계 기준(평균인지 95퍼센타일인지)
- 측정 방법: 무엇으로 어떻게 재는가
- 증빙: 합격을 무엇으로 보여 주는가
| 원래 문장 | 측정 가능한 문장 |
|---|---|
| 신속한 응답 시간을 보장한다 | 민원 조회 화면은 동시 사용자 2,000명, 데이터 100만 건 조건에서 응답 시간 95퍼센타일 2초 이내 |
| 안정적으로 운영되어야 한다 | 업무 시간(09~18시) 가용성 99.5% 이상, 서버 1대 장애 시 30초 안에 서비스 전환 |
| 보안 취약점이 없어야 한다 | 보안약점 진단과 모의해킹 결과 고위험 0건, 중위험은 조치 계획 승인 |
| 데이터를 정확히 이관한다 | 대상 테이블별 건수와 금액 합계가 원천과 100% 일치, 불일치 0건 |
| 다양한 환경을 지원한다 | 지정 브라우저 최신 2개 버전과 해상도 2종에서 주요 업무 화면 정상 동작 |
숫자는 AA가 정하는 것이 아니라 발주처와 합의하는 것이다. 근거로는 현행 시스템의 사용량(월별 피크, 동시 접속), 유사 시스템 사례, 발주처의 업무 기준을 쓴다. 합의한 숫자는 회의록이 아니라 비기능 요구사항 정의서에 남긴다.
검증 기준을 요구사항과 함께 설계한다
요구사항을 정의할 때 검증 방법도 같이 정한다. 검증 방법은 네 가지 중 하나를 고른다.
| 방법 | 언제 쓰나 | 예 |
|---|---|---|
| 시험(Test) | 수치로 재현할 수 있을 때 | 부하 도구로 응답 시간 측정 |
| 시연(Demonstration) | 동작 여부만 보면 될 때 | 서버 한 대를 내리고 서비스 전환 확인 |
| 검사(Inspection) | 문서·설정·코드로 확인할 때 | 암호화 설정, 로그 보관 기간 확인 |
| 분석(Analysis) | 직접 재기 어렵거나 비쌀 때 | 5년 뒤 데이터 증가량을 산정해 저장 용량 검토 |
정의서 한 줄은 이런 모양이 된다.
ID PER-001
분류 성능
요구사항 민원 조회 화면은 피크 시간 부하에서도 응답한다
조건 운영과 같은 사양의 시험 환경, 데이터 100만 건, 동시 사용자 2,000명, 30분 지속 부하
기준값 응답 시간 95퍼센타일 2초 이내, 오류율 0.1% 미만
검증 방법 시험 — 부하 도구(nGrinder, JMeter 등)로 시나리오 실행, APM으로 서버 지표 수집
증빙 성능 시험 결과서(그래프 포함), 원본 측정 데이터
검증 시점 통합 시험 2회, 인수 시험 1회
책임 측정: 테스트 담당 / 판정: 품질 담당 / 승인: 발주처
조건 칸이 가장 자주 빠진다. 같은 "2초"라도 데이터 1만 건과 100만 건, 동시 사용자 100명과 2,000명은 전혀 다른 요구사항이다.
요구사항에서 증빙까지 한 줄로 잇는다
검증 기준은 요구사항, 시험 케이스, 결과 증빙과 같은 ID로 이어져야 인수 시험 때 빠짐없이 확인할 수 있다.
- 요구사항 추적표에 비기능 요구사항 열을 따로 두지 말고, 기능 요구사항과 같은 표에서 같은 방식으로 추적한다.
- 시험 케이스 ID는 요구사항 ID를 포함한다(PER-001-TC01). 결과서는 시험 케이스 ID로 정리한다.
- 기준 미달이 나오면 두 길만 있다. 개선해서 다시 재거나, 변경 요청으로 기준을 바꾼다. 결과서에 "참고 사항"으로 적고 넘어가는 것은 길이 아니다.
언제 무엇을 검증하나
마지막 인수 시험에서 처음 재면 고칠 시간이 없다. 단계마다 확인할 것을 나눈다.
| 단계 | 비기능 요구사항에 대해 할 일 |
|---|---|
| 착수 | 항목 추출, 측정 가능한 문장으로 바꾸기, 기준값 합의 |
| 분석·설계 | 검증 방법·시점·증빙 확정, 아키텍처 대응 방안 작성, 시험 환경 요청 |
| 구현 | 위험 큰 항목은 PoC로 미리 측정, 보안약점 진단과 코드 검사 반복 |
| 통합 시험 | 성능·전환·이관 리허설을 운영과 같은 조건에서 측정 |
| 인수 시험 | 합의한 기준과 방법 그대로 재측정, 결과서와 원본 데이터 제출 |
특히 시험 환경은 착수 때 요청해야 한다. 운영과 사양이 다른 환경에서 잰 성능 수치는 인수 기준으로 인정받기 어렵다.
분류별 검증 포인트
성능: 평균이 아니라 퍼센타일로 기준을 잡는다. 평균 1초여도 5%가 10초면 민원이 들어온다. 부하는 계단식으로 올리고, 목표 부하에서 30분 이상 유지한다.
가용성·이중화: "이중화 구성"은 검증 기준이 아니다. 서버 한 대를 실제로 내렸을 때 전환까지 걸린 시간, 그동안 실패한 요청 수, 로그인 유지 여부를 잰다.
보안: 소프트웨어 개발보안(시큐어코딩) 기준에 따른 보안약점 진단, 모의해킹, 개인정보 처리 점검으로 나눈다. 기준은 "고위험 0건"처럼 등급별 건수로 정한다.
데이터 이관: 건수 대사와 합계 대사를 모두 한다. 건수만 맞고 금액이 틀리는 경우가 흔하다. 이관 리허설을 최소 2회 하고 걸린 시간을 재서 실제 전환 일정을 정한다.
품질(접근성·호환성): 웹 접근성은 지침(KWCAG) 항목별 점검표로, 호환성은 브라우저·해상도 조합표로 검사한다. 대상 화면 목록을 미리 합의한다.
자주 하는 실수
- 기준값만 있고 조건이 없다. 시험할 때마다 조건이 달라져 결과를 비교할 수 없다.
- 평균으로 기준을 잡는다. 느린 일부 요청이 가려지고 체감 품질과 수치가 어긋난다.
- 인수 시험에서 처음 잰다. 기준 미달이어도 고칠 기간이 없어 분쟁이 된다.
- 시험 환경을 늦게 요청한다. 운영과 다른 환경의 결과는 증빙으로 인정받기 어렵다.
- 기준 미달을 "참고 사항"으로 넘긴다. 개선 또는 변경 요청 중 하나로 정리해야 검수가 닫힌다.
점검표
- 제안요청서의 비기능 요구사항을 한 표에 모두 모았다
- 항목마다 대상·조건·기준값·측정 방법·증빙이 있다
- 성능 기준은 퍼센타일과 오류율로 적었다
- 기준값의 근거(현행 사용량 등)를 남기고 발주처와 합의했다
- 항목마다 검증 방법(시험·시연·검사·분석)과 시점이 정해졌다
- 시험 케이스 ID가 요구사항 ID와 이어진다
- 운영과 같은 사양의 시험 환경을 착수 때 요청했다
- 위험 큰 항목은 구현 중 PoC로 미리 쟀다
- 기준 미달 시 개선 또는 변경 요청으로 처리하는 규칙이 있다
비기능 요구사항은 쓰는 순간 검증 방법까지 정해져야 끝난 것이다. 숫자, 조건, 재는 방법, 보여 줄 증빙이 한 줄에 있으면 인수 시험은 확인하는 자리가 되고 다투는 자리가 되지 않는다.
댓글 0개
아직 댓글이 없습니다. 첫 댓글을 남겨보세요.