요구사항은 어디까지 쓰고 어디부터 맡기나 (03/08)

발주자를 위한 RFP 가이드 · Ep.03

다 쓸 수는 없었다.
그래서 다 쓴 척을 했다.

요구사항은 어디까지 쓰고 어디부터 맡기나 · HFC Consulting

---

요구사항정의서는 팔백 줄이었다. 발주 담당자에게 물었다. 이 중 확정된 요구가 몇 줄입니까. 대답까지 시간이 걸렸다. "절반쯤 될 겁니다." 나머지 사백 줄도 확정과 같은 문장으로 적혀 있었다.

이번 화는 확정하지 못한 요구를 다루는 법이다. 요구사항(RFP 요구정의) 전체를 상세화하라는 이야기가 아니다. 그 반대다. 확정할 수 없는 것을 확정된 문장으로 쓰는 관행이 만드는 비용을 계산하고, 그보다 싼 대안을 제시한다.

다 쓴 척의 비용

미확정 요구를 확정처럼 쓰면 무슨 일이 벌어지는가. 입찰자는 팔백 줄을 전부 확정으로 읽고, 가장 값싼 해석으로 견적을 만든다. 착수 후 요구가 실제로 확정되기 시작하면, 그 차액은 전부 변경 협상이 된다. 발주자는 "원래 요구였다"고 말하고 수급인은 "새 요구"라고 말한다. 문서는 양쪽 모두의 편이다. 그것이 문제다.

반대의 실패도 있다. 미확정을 통째로 비워 두면 견적 자체가 불가능해지고, 위험 비용이 가격에 얹힌다. 쓰지 않는 것도, 다 쓴 척하는 것도 답이 아니다. 답은 구분이다.

팔백 줄의 정의서로 돌아가 보자. 그 문서의 문제는 분량이 아니라 화법이었다. 확정된 사백 줄과 희망에 가까운 사백 줄이 같은 문장 구조로 적혀 있었다. "시스템은 ~를 제공한다." 입찰자는 이 문장들 사이에 놓인 확신의 낙차를 읽을 방법이 없다. 발주 조직 내부에서는 모두가 아는 차이가, 문서 밖의 독자에게는 존재하지 않는다. 어떤 요구공학 기법보다 먼저 필요한 것은 이 화법의 분리다.

화법을 분리하는 순간 발주 조직 내부의 대화도 바뀐다. 현업 부서에 "이 요구는 확정입니까, 방향입니까"라고 물으면, 미뤄 온 결정들이 수면 위로 올라온다. RFP 작성이 곧 조직의 의사결정을 앞당기는 절차가 되는 것이다. 좋은 발주 문서는 쓰는 과정에서 이미 사업을 한 번 수행한다.

확정도라는 좌표

요구사항을 세 등급으로 나눈다. 등급의 이름은 중요하지 않다. 중요한 것은 등급이 RFP에 표기되어 입찰자가 같은 지도를 보게 하는 것이다.

등급	RFP에 쓰는 것	사업에서의 처리
A 확정	상세 사양까지 기술	변경 시 정식 변경관리
B 방향 확정	목적·원칙 + 확정 절차와 시한	착수 후 합의로 상세 확정
C 탐색	문제 정의와 검증 방법	프로토타입 검증 후 확정

이 구분은 방법론 선택과 직결된다. 요구 확정도는 규제 강도와 함께 사업 방식(단계식·반복식·혼합)을 정하는 두 축 중 하나다. 그 매트릭스는 4기 완결편에서 다뤘다. AI가 프로토타입 제작 비용을 낮춘 지금, C등급을 탐색으로 정직하게 표기하는 부담은 과거보다 훨씬 작다.

등급 표기는 대가산정과도 바로 연결된다. A등급은 확정 견적의 대상이 되고, B등급은 규모의 상한과 하한으로, C등급은 검증 예산으로 책정된다. 입찰자가 위험 비용을 총액에 뭉뚱그려 얹는 대신 등급별로 가격을 설계하게 되므로, 발주자는 제안 간 비교 가능성을 얻는다. 확정도의 표기가 곧 가격의 해상도가 되는 셈이다.

RFP에 넣을 문구

확정도 구분 기준 4

① 담당 부서가 화면·규칙 수준까지 답할 수 있는가 — 있으면 A.

② 목적은 합의되었으나 방식이 열려 있는가 — B.

③ 효과 자체가 가설인가 — C.

④ 등급을 정하지 못한 요구는 B로 표기하고 확정 시한을 건다.

미확정 요구 처리 문구 (예시)

① "B등급 요구사항의 상세 사양은 착수 후 6주 이내 발주기관과 수급인의 합의로 확정하며, 합의 결과는 요구사항추적표에 기록한다."

② "C등급 요구사항은 프로토타입 검증 결과에 따라 과업 반영 여부를 결정하며, 반영 시 과업 변경 절차를 따른다."

예상 반론과 대응

반론 — "미확정이라고 쓰면 감리와 감사에서 요구사항 부실로 지적받는다."

대응 — 지적의 대상은 미확정의 존재가 아니라 미확정의 은폐다. 확정하지 못한 요구를 확정처럼 쓴 문서가 부실이고, 확정도와 확정 절차를 명기한 문서는 관리다. 공공 소프트웨어사업의 법령이 요구사항 작성 의무와 함께 과업 변경 심의 절차를 두는 이유도 같다. 변할 것을 전제로 관리 구조를 만드는 것이다. 산출물이 형식이 아니라 기능으로 존재해야 한다는 원칙은 5기 1화에서 다뤘다.

시작이 부담스러우면 전수 등급화를 고집할 필요는 없다. 사업의 성패를 좌우하는 상위 요구 두어 줄 중 하나라도 미확정이라면, 그것부터 표기하는 것으로 충분히 효과가 난다. 형식도 거창할 것 없다. 요구사항 목록에 열 하나를 추가하고 A, B, C를 적는 것이 전부다. 중요한 것은 표기의 완성도가 아니라, 발주자와 입찰자가 확신의 낙차를 같은 문서에서 읽게 되는 것이다.

체크포인트 — 요구마다 확정도 표기 / B등급의 확정 절차·시한 존재 / C등급의 검증 방법 존재 / 등급 변경 시 기록 위치(추적표) 지정

전부를 확정하는 발주는 없다. 있는 것은 확정하지 못했음을 아는 발주와 모르는 발주다. 그 차이가 문서 한 줄의 차이다. 그리고 그 한 줄은 공고가 나가기 전에만 쓸 수 있다.

📎 더 읽을거리

소프트웨어 진흥법 시행령 (국가법령정보센터) — 요구사항 작성 의무와 과업 변경 심의 절차의 규정 원문

조달청 협상에 의한 계약 제안서평가 세부기준 (국가법령정보센터) — 요구의 명확성이 제안·평가 구조와 만나는 지점

HFC의 관점

귀사의 요구사항정의서에서 확정과 미확정의 비율을 알고 계십니까. HFC컨설팅은 공고 전 요구사항의 확정도를 진단하고, 미확정 요구의 처리 구조를 설계합니다.

changks@hfcconsulting.co.kr

1영업일 이내 답변 · 주식회사 에이치에프씨 컨설팅 · 대표이사 장기석

본 연재의 문구·양식 예시는 법률 자문을 대체하지 않으며, 실제 발주·계약 시 법무 검토를 권장합니다.

---

📚 발주자를 위한 RFP 가이드 (전 8화)

◀ 이전 편: 02 과업범위: "등"이라는 한 글자의 대가

다음 편 ▶ 04 AI 생산성 시대의 예산과 사업기간 책정

연재 전체 보기 →