계약 인수 기준 읽기 — 제안요청서(RFP)의 요구사항을 인수 케이스로

개념

RFP 는 요구사항 명세가 아니다

제안요청서(RFP)는 발주처가 사업자를 고르기 위해 쓰는 문서 다. 목적이 다르니 성격도 다르다.

그런데 인수 판정의 최종 근거는 계약 문서 다. 아무리 착수 후에 요구사항정의서를 잘 써도, 검수 자리에서 발주처가 펼치는 것은 과업지시서다. 그래서 QA 가 가장 먼저 해야 하는 일은 RFP·과업지시서의 모든 요구 항목에 번호를 붙이고 인수 케이스로 옮기는 것 이다. 이 작업을 착수 첫 2주에 해 두느냐 아니냐가 사업 후반의 난이도를 결정한다.

요구사항 한 줄을 인수 케이스로 옮기는 5단계

1. 식별     RFP 문장을 쪼개 요구 항목에 고유 번호를 붙인다
            (한 문장에 요구가 두 개 이상 들어 있는 경우가 매우 흔하다)
2. 분류     기능 / 성능 / 가용성 / 보안 / 데이터 / 인터페이스 / 운영 / 산출물
3. 판정화   "무엇을 관찰하면 충족인가" 로 다시 쓴다 — 여기가 이 레슨의 핵심
4. 케이스화 판정 문장마다 인수 케이스를 만든다 (전제·절차·기대결과·증거)
5. 추적     요구 번호 ↔ 인수 케이스 ↔ 증거를 표로 잇는다

1번에서 이미 일이 갈린다. 예를 들어 이런 문장이 있다.

"사용자는 모바일 및 PC 환경에서 원활하게 결재를 상신·처리할 수 있어야 하며, 처리 결과는 실시간으로 확인 가능해야 한다."

이 한 문장 안에 요구가 최소 다섯 개 있다. 모바일 지원 / PC 지원 / 상신 기능 / 처리 기능 / 결과 확인. 여기에 판정 불가 표현이 두 개 섞여 있다("원활하게", "실시간으로"). 쪼개지 않고 그대로 두면 검수 때 "모바일에서 좀 느린데요" 한마디로 전체가 막힌다.

모호한 표현을 판정 가능한 기준으로

국내 RFP 에서 반복해서 나오는 표현과, 그것을 바꾸는 방식이다.

바꾸는 방법은 언제나 같은 세 질문이다.

Q1. 무엇을 측정하는가 (지표)
Q2. 어떤 조건에서 측정하는가 (부하·데이터 규모·환경·시간대)
Q3. 어떤 값이면 충족인가 (임계값과 통계 기준 — 평균인가 p95 인가)

세 질문에 답이 다 있으면 판정할 수 있고, 하나라도 비면 분쟁의 씨앗이 남는다.

정량 요구는 값보다 측정 조건이 분쟁을 만든다

"응답 시간 3초 이내"라고 계약서에 적혀 있다고 해서 분쟁이 사라지지 않는다. 실제로 싸우는 지점은 값이 아니라 어떻게 쟀는가 다.

[측정 조건으로 반드시 합의할 것]
  대상      어느 화면·거래인가 (전부인가, 지정한 목록인가)
  구간      어디서 어디까지인가
              사용자 체감(브라우저 렌더 완료) / 서버 응답 / API 왕복
  부하      동시 사용자 몇 명, 어떤 시나리오 믹스
  데이터    운영 수준 데이터 규모인가, 초기 데이터인가
  환경      운영 환경인가 검증 환경인가 — 사양 차이가 있으면 환산 규칙
  네트워크  내부망 기준인가, 외부 회선 포함인가
  통계      평균 / 중앙값 / p95 / p99 중 무엇, 몇 회 측정, 이상치 처리
  제외      계획 점검, 외부 시스템 장애, 사용자 단말 문제

가용률도 같다. 99.9% 라는 값은 측정 기간(월간인가 연간인가), 다운타임의 정의(전체 불가인가 일부 기능 불가인가), 제외 사유(계획 점검·외부 원인)가 붙어야 의미가 생긴다. 이 항목들이 과업지시서에 없으면 착수 단계에 합의하고 그 합의를 문서로 남긴다. 검수 자리에서 정하면 늦다.

성능 결과를 어떤 통계로 보고할지, 측정 회차를 어떻게 잡을지는 모듈 31 레슨 4에서 더 깊게 다룬다. 여기서는 계약 문장에 무엇을 박아야 하는가 까지가 범위다.

인수 케이스의 형태

인수 케이스는 테스트 케이스와 생김새가 비슷하지만 두 칸이 더 있다. 근거(요구 번호) 와 증거(무엇을 남기는가) 다.

인수 케이스 AC-034
  근거 요구   REQ-F-021 (과업지시서 3.2.4 결재 상신)
  전제        결재선이 3단계로 설정된 부서, 상신자 권한 보유
  절차        1) 기안 작성 → 2) 결재선 확인 → 3) 상신
  기대 결과   - 상신 즉시 1차 결재자의 미결함에 나타난다(3초 이내)
              - 기안자 화면 상태가 "상신"으로 바뀐다
              - 알림이 1차 결재자에게 발송된다
  판정        위 3개가 모두 충족되면 합격, 하나라도 미충족 시 불합격
  증거        화면 캡처 3종(파일명에 일시·빌드), 알림 수신 로그 발췌
  판정자      발주처 총무팀 (UAT 라운드 2)

판정자 칸이 있는 이유는 레슨 1에서 본 그대로다. 누가 판정하는지 정하지 않은 케이스는 검수 자리에서 표류한다.

요구사항 추적표 — RFP ↔ 인수 케이스 ↔ 증거

감리와 검수에서 가장 많이 요구되는 문서이고, 가장 많이 급조되는 문서다. 최소 형태는 이렇다.

운용 규칙 세 가지만 지키면 이 표는 끝까지 살아남는다.

1. 요구 번호는 착수 때 확정하고 바꾸지 않는다. 번호가 흔들리면 모든 참조가 깨진다.
2. 1:N 을 허용한다. 요구 하나에 인수 케이스 여러 개가 정상이다. 반대로 어떤 인수 케이스도 없는 요구가 0건 이어야 한다 — 이게 이 표의 유일한 완료 조건이다.
3. 증거 위치는 사람이 찾아갈 수 있게 쓴다. "테스트 결과서 참조"가 아니라 경로와 파일명이다.

역방향 확인도 한다. 어떤 요구에도 연결되지 않은 인수 케이스 가 있으면, 그것은 계약에 없는 것을 검증하고 있거나(과잉), 요구 식별이 빠진 것이다(누락). 둘 다 확인해야 한다.

계약 범위 밖 요구가 들어올 때

사업 중반부터 반드시 일어난다. 현업이 UAT 에서 "이것도 되게 해 달라"고 하고, 발주 담당자는 "당연히 포함 아니냐"고 한다. 이때 감정으로 대응하면 관계가 상하고, 그냥 받으면 범위가 무너진다. 절차로 대응한다.

1. 기록한다      요청 내용·요청자·일시를 접수 목록에 넣는다. 그 자리에서 판정하지 않는다
2. 대조한다      요구사항 추적표에서 근거 요구 번호를 찾는다
                   찾힌다  → 범위 내. 결함 또는 미구현으로 처리
                   못 찾는다 → 범위 밖 후보
3. 판정 근거를 만든다
                   "과업지시서 3.2.4 에는 3단계 결재선까지 명시돼 있고,
                    5단계 확장은 해당 절에 없다" — 문서·절을 들어 말한다
4. 선택지를 제시한다
                   A. 차기 사업·변경 계약으로            (영향: 없음)
                   B. 이번 범위 내 다른 항목과 교환      (영향: 교환 대상 명시)
                   C. 범위에 추가                        (영향: 일정 N주, 비용)
5. 결정을 받고 기록한다
                   결정자·결정일·근거를 남긴다. 회의록 또는 공문

3번이 실무의 핵심이다. "그건 범위 밖입니다"는 주장이고, "과업지시서 3.2.4 에 없습니다"는 사실이다. 후자는 반박하려면 문서를 펼쳐야 하므로 대화가 문서 위에서 이뤄진다.

동시에 QA 가 조심할 것이 있다. 범위 밖이라는 판정이 곧 "안 해도 된다"는 뜻은 아니다. 그 요구가 시스템을 실제로 못 쓰게 만드는 것이라면, 범위 밖임을 확인한 뒤 그 사실과 위험을 함께 올린다. 범위를 지키는 일과 사업을 성공시키는 일은 같은 목표의 두 면이다.

요구가 애초에 모호한 채로 계약된 경우

이미 계약된 과업지시서에 "원활하게"가 들어 있다면, 문장을 고칠 수는 없다. 대신 해석을 합의하고 문서로 남긴다.

[요구사항 해석 확인서]  — 착수 단계 산출물
  요구 번호   REQ-P-003
  원문        "주요 화면은 원활하게 조회되어야 한다"
  해석        "주요 화면" = 별첨 목록의 10개 화면
              "원활하게" = 동시 사용자 200명 부하에서 응답 시간 p95 2초 이하
              측정 환경 = 검증계, 운영 데이터 규모의 100%
  합의일      2026-03-14
  합의 참석   발주처 정보화담당관실 OOO, 현업 OOO / 수행사 PM OOO, QA OOO

이 문서 한 장이 나중에 수천만 원어치 분쟁을 막는다. 만드는 데 필요한 건 회의 한 시간이다. 착수 단계에 요구사항 해석을 확정하지 않으면, 그 해석은 검수 자리에서 발주처 단독으로 정해진다.

실무에서 왜 필요한가

SI 사업에서 수익을 깎아먹는 1순위는 기술 난이도가 아니라 범위의 확장 이다. 그리고 범위는 대개 한 번에 크게 늘지 않는다. 판정 불가능한 문장 하나가 수십 번의 "이것도 포함이죠"로 쪼개져 들어온다. 착수 단계에 요구를 쪼개고 해석을 확정하는 작업은 그래서 문서 작업이 아니라 원가 관리다.

제품 조직에서도 같은 구조가 있다. 외주 개발을 맡길 때, 엔터프라이즈 고객과 계약할 때, 파트너와 연동 규격을 정할 때 — 판정 조건 없는 문장은 언제나 나중에 비용으로 돌아온다. 모듈 2에서 배운 "테스트 가능한 요구사항"이 계약 문서 위에서 어떻게 쓰이는지가 이 레슨이다.

채용시장에서의 위치

SI·공공 사업 QA 공고의 "과업 이행 관리", "요구사항 추적", "검수 대응"이 이 레슨의 내용이다. 경력 기술서에서 변별력이 나오는 문장은 "요구사항 추적표를 관리했다"가 아니라 "과업지시서 요구 240건을 인수 케이스 380건으로 전개하고 추적표로 검수까지 유지했다" 처럼 숫자와 범위가 붙은 문장이다. 면접에서는 거의 항상 "범위 밖 요구가 들어왔을 때 어떻게 했느냐"가 따라온다 — 본문의 5단계 절차가 그대로 답이 된다.

실습 과제

과제 1 — RFP 문장 전개 (20분)

다음 과업지시서 문단을 5단계 절차의 1~3단계까지 처리한다. 요구 번호 부여, 분류, 판정 가능한 기준으로 다시 쓰기까지다.

"본 시스템은 전 직원(약 3,000명)이 사용하는 그룹웨어로서, 결재·게시판·일정 기능을 제공하여야 한다. 모든 기능은 PC 및 모바일 환경에서 원활하게 동작하여야 하며, 시스템은 24시간 안정적으로 운영되어야 한다. 기존 인사시스템과 연동하여 조직 정보를 실시간으로 반영하고, 관련 법령 및 지침을 준수하여야 한다."

산출물은 요구 번호가 붙은 표다. 판정 불가 표현을 바꿀 때 정보가 부족해 스스로 정할 수 없는 값 이 나오면 임의로 채우지 말고 "발주처 확인 필요"로 표시하고 무엇을 물어야 하는지 적는다.

과제 2 — 측정 조건 합의서 쓰기 (20분)

과제 1에서 만든 성능 요구 하나를 골라 본문의 측정 조건 8개 항목을 모두 채운 합의서를 쓴다. 다음 제약을 반영한다.

• 검증 환경은 운영 환경의 50% 사양이다
• 운영 데이터는 이관 후에야 확보되고, 이관은 UAT 1주 전이다
• 발주처는 "사용자 체감 기준"을 요구하고 수행사는 "서버 응답 기준"을 제안한다

마지막 항목에 대해 양측이 받아들일 수 있는 문장 하나 를 만들어 본다.

과제 3 — 범위 밖 요구 처리 (15분)

UAT 2주 차에 다음 요청이 들어왔다. 본문의 5단계로 처리하고, 4단계의 선택지 A·B·C 를 구체적인 내용으로 채운다.

현업 부서장: "결재선이 5단계까지 되어야 합니다. 지금 3단계까지만 되는데, 우리 부서는 원래 5단계예요. 이건 당연히 되는 거 아닌가요?"

확인 결과 — 과업지시서 3.2.4 에는 "3단계 결재선"으로 명시돼 있고, 요구사항정의서에도 3단계로 확정돼 있다. 해당 부서의 실제 업무는 5단계가 맞다. 남은 기간은 6주, 개발 공수는 약 2주로 추정된다.

자가 체크리스트

• RFP·과업지시서와 요구사항 명세서의 목적·작성 시점·수정 가능성 차이를 설명할 수 있다
• 요구사항 한 줄을 인수 케이스로 옮기는 5단계를 순서대로 수행할 수 있다
• 한 문장에 섞인 복수 요구를 쪼개고 각각에 번호를 붙일 수 있다
• 모호한 표현을 지표·조건·임계값 세 질문으로 판정 가능한 기준으로 바꿀 수 있다
• 정량 요구의 측정 조건 8개 항목을 나열하고 합의서로 만들 수 있다
• 인수 케이스에 근거·증거·판정자 칸이 왜 필요한지 설명할 수 있다
• 요구사항 추적표의 완료 조건과 역방향 확인 방법을 말할 수 있다
• 계약 범위 밖 요구가 들어왔을 때의 5단계 절차를 수행할 수 있다
• 이미 모호하게 계약된 요구를 해석 확인서로 고정할 수 있다

흔한 실수

• RFP 문장을 그대로 요구 번호 하나로 잡는다. 한 문장에 요구 다섯 개가 들어 있으면, 그중 하나가 미충족일 때 전체가 불합격으로 걸린다.
• 판정 불가 표현을 착수 때 그냥 넘긴다. "원활하게"는 개발 중에는 아무 문제도 일으키지 않다가 검수 자리에서만 문제가 된다. 그때는 협상력이 발주처에 있다.
• 정량 값만 합의하고 측정 조건을 빼먹는다. 3초라는 숫자는 어디서 어떤 부하로 쟀는지가 없으면 판정 근거가 못 된다.
• 부족한 정보를 임의로 채운다. "아마 이 정도겠지"로 채운 임계값은 수행사 단독 해석이고, 발주처는 동의한 적이 없다. 모르면 "확인 필요"로 남기고 물어본다.
• 요구사항 추적표를 종료 단계에 만든다. 그때 만들면 사후 정리가 되고, 누락된 요구를 발견해도 고칠 시간이 없다.
• 역방향 확인을 하지 않는다. 요구에 연결되지 않은 인수 케이스는 과잉 검증이거나 요구 식별 누락이다. 둘 다 확인해야 한다.
• 범위 밖 요구를 그 자리에서 판정한다. 현업 앞에서 즉답하면 감정 문제가 되거나 즉석 수락이 된다. 접수하고, 대조하고, 선택지로 돌려준다.
• 범위 밖이라는 결론에서 멈춘다. 그 요구가 실제로 시스템을 못 쓰게 만드는 것이면, 범위 밖임을 확인한 뒤 위험으로 보고한다.

참고 자료

• 국가종합전자조달 나라장터 — 공고별 제안요청서·과업지시서 원문. 실제 RFP 문장을 연습 재료로 구할 수 있다
• 국가법령정보센터 — 「소프트웨어 진흥법」의 과업 내용 변경·하자담보책임 관련 조문. 현행 조문 직접 조회
• NIA 정보시스템 감리자료실 — 요구사항 추적과 산출물 점검이 감리에서 어떻게 확인되는지
• ISO/IEC/IEEE 29148 Requirements engineering — 검증 가능한 요구사항의 특성(명확성·검증가능성·추적가능성). 최신판 원문 확인
• 레슨 s1-m02-l02 — 테스트 가능한 요구사항 쓰기 / s1-m02-l03 — 모호성과 공백 찾기
• 레슨 s1-m02-l05 — 요구사항 변경과 추적성
• 레슨 s2-m31-l04 — 성능 결과의 통계 처리 (p95·측정 회차)
• 레슨 s2-m56-l01 — UAT 설계 / s2-m56-l02 — 예제로 인수 기준 정제하기 / s2-m56-l03 — 공공 SI 검수와 감리 대응