RFI 분석, 어떻게 읽어야 하는가 — 조달청 RFI를 예시로
"요구사항을 읽는 눈을 가진 개발자가, 결국 시스템을 설계하는 사람이 된다."
1. RFI란 무엇인가
RFI(Request for Information) 는 직역하면 정보 요청서다.
발주 기관이 본격적인 사업 발주(RFP, Request for Proposal)
전에 시장 조사를 목적으로 배포하는 문서로, 다음과 같은 질문을 내포하고 있다.
"이런 사업을 하려고 하는데, 업계에서는 어떻게 보십니까?"
즉 RFI는 확정된 요구사항이 아니다. 발주 기관이 현황을 파악하고,
기술 동향을 수집하며, 향후 RFP를 정교화하기 위한 탐색 단계의 문서다.
| 구분 | RFI | RFP |
|---|---|---|
| 목적 | 시장 조사 / 기술 동향 파악 | 제안 요청 / 사업자 선정 |
| 구속력 | 없음 | 계약의 기초 |
| 단계 | 사업 기획 초기 | 사업 발주 단계 |
| 응답 주체 | 이해관계자, 벤더, 전문가 | 입찰 참여 기업 |
2. RFI를 분석하는 목적
개발자 혹은 SI 기업 입장에서 RFI를 분석하는 이유는 명확하다.
- 사업의 방향성을 조기에 파악하여 사전 준비를 시작할 수 있다.
- 기술 스택, 규모, 예산 수준을 가늠해 리소스 계획을 세울 수 있다.
- 요구사항의 모호성과 리스크를 식별하여 제안 전략을 수립할 수 있다.
- RFP가 나왔을 때 이미 반 걸음 앞서 있을 수 있다.
3. 조달청 RFI 구조 이해
조달청(나라장터, G2B)에 게시되는 공공기관 RFI는 대체로 아래의 구조를 따른다.
## RFP 개요 분석
1. 사업 개요
- 추진 배경 및 목적
- 사업 범위
2. 현황 및 문제점
- 현행 시스템 현황
- 개선 필요 사항
3. 주요 요구 기능 (초안)
- 기능 요구사항 (Functional Requirements)
- 비기능 요구사항 (Non-Functional Requirements)
4. 정보 요청 항목
- 기술 구현 방안
- 예상 사업 기간 및 규모
- 유사 구축 실적
5. 제출 방법 및 일정
이 구조를 숙지한 상태에서 문서를 읽으면, 각 섹션이 무엇을 물어보고 있는지
빠르게 파악할 수 있다.
4. 실전 RFI 분석 방법 — 5단계 프레임
Step 1. 추진 배경 분석 — "왜 만드는가"
가장 먼저 읽어야 할 부분은 추진 배경이다.
기관이 이 사업을 추진하는 정치적·행정적 맥락을 이해해야 요구사항의 우선순위가 보인다.
예시: 조달청 수요기관 업무포털 고도화 RFI
"현행 조달 업무 포털은 2015년 구축 이후 노후화되어 모바일 환경 대응 미흡,
사용자 편의성 저하 등의 문제가 지속적으로 제기되고 있음."
여기서 핵심 키워드를 추출한다.
### 추출 키워드
- 노후 시스템 → 레거시 마이그레이션 가능성
- 모바일 대응 미흡 → 반응형 UI / 앱 개발 포함 가능성
- 사용자 편의성 → UX 개선이 핵심 KPI일 것
Step 2. 현황 파악 — "무엇을 가지고 있는가"
현행 시스템 현황 섹션은 기술 부채(Technical Debt)의 단서가 숨어 있다.
체크할 항목:
- 현행 기술 스택 (Java 6? .NET Framework 3.5?)
- 데이터 규모 (일 처리 건수, DB 용량)
- 연계 시스템 목록 (국세청, 은행, 타 부처 등)
- 현행 운영 인프라 (IDC 온프레미스? 클라우드?)
연계 시스템이 많을수록 인터페이스 정의서의 분량이 늘고, 개발 리스크가 증가한다.
이 부분에서 프로젝트 난이도를 1차 가늠할 수 있다.
Step 3. 요구 기능 분해 — "무엇을 만드는가"
RFI 단계의 기능 요구사항은 추상적인 경우가 많다.
"통합 사용자 관리 기능 구현"
이런 문장 하나에는 실제로 수십 개의 기능이 숨어 있다. 이를 기능 트리(Function Tree)
형태로 분해하는 훈련이 필요하다.
### 현황분석
통합 사용자 관리
├── 회원가입 / 탈퇴
│ ├── 본인 인증 (공동인증서 / 간편인증)
│ └── 약관 동의 관리
├── 로그인 / 로그아웃
│ ├── SSO (단일 로그인) 연계
│ └── 세션 / 토큰 관리
├── 권한 관리
│ ├── 역할 기반 접근 제어 (RBAC)
│ └── 부서/기관 단위 권한 분리
└── 사용자 정보 관리
├── 개인정보 조회 / 수정
└── 접속 이력 조회
이렇게 분해해야 개발 공수 산정이 가능해진다.
Step 4. 비기능 요구사항 심층 분석 — "얼마나 잘 만드는가"
공공 SI에서 간과하기 쉬운 영역이지만, 실제 검수와 운영에서 가장 많은 분쟁이 발생하는 곳이다.
| 항목 | 확인 내용 | 예시 기준 |
|---|---|---|
| 성능 | 응답시간, 동시접속자 | 3초 이내 응답 / 500명 동시접속 |
| 가용성 | 서비스 연속성 | 99.9% 이상 (연간 다운타임 약 8.7시간) |
| 보안 | 개인정보보호, 인증 | ISMS-P, 전자정부 보안 가이드 준수 |
| 호환성 | 브라우저, OS | Chrome, Edge, IE 11(구형 기관 여전히 존재) |
| 유지보수성 | 소스코드 품질 기준 | 코드 복잡도, 단위 테스트 커버리지 |
특히 보안 항목은 공공 사업에서 필수 준수 사항이므로 반드시 별도로 정리해 두어야 한다.
Step 5. 정보 요청 항목 역독해 — "발주처가 진짜 원하는 것"
RFI의 정보 요청 항목은 단순히 "이걸 써서 내세요"가 아니다.
발주 기관이 어떤 부분을 불확실해하는지, 역으로 읽으면 된다.
"유사 구현 사례 및 기술적 접근 방법을 기술해 주시기 바랍니다."
이 질문은 곧 다음을 의미한다.
### 현업(고객)의 속마음
발주처의 속뜻: "우리가 원하는 게 현실적으로 가능한가?" "어떤 기술로 풀어야 하는지 아직 모르겠다." "시장에 레퍼런스가 있는지 확인하고 싶다."
이 부분을 정확히 읽어낼수록, 이후 RFP 대응과 제안서 작성의 설득력이 달라진다.
5. RFI 분석 시 흔히 하는 실수
① 표면적 기능 나열에 그친다
기능 목록만 읽고 분해하지 않으면, 개발 범위를 과소 산정하는 실수를 저지른다.
② 연계 시스템을 가볍게 본다
"단순 API 연동"처럼 보이는 항목도 국세청, 행정안전부 등 공공 연계는 프로토콜 협의,
보안 심의, 테스트 환경 제한 등으로 인해 일정을 크게 잡아먹는다.
③ 비기능 요구사항을 부록으로 취급한다
성능 기준 미충족으로 검수 반려를 받는 것은 SI 프로젝트에서 흔히 발생하는 사태다.
반드시 설계 단계부터 반영해야 한다.
④ RFI를 RFP로 착각한다
RFI의 내용은 확정 요구사항이 아니다. 이후 RFP에서 내용이 달라지거나,
항목이 추가/삭제될 수 있음을 항상 염두에 두어야 한다.
6. 분석 결과 정리 템플릿
RFI 분석 후 다음 형식으로 정리해 두면 팀 공유와 사전 기술 검토에 효과적이다.
## [사업명] RFI 분석 요약
### 기본 정보
- 발주 기관:
- 사업 기간 (예상):
- 예산 규모 (언급된 경우):
- RFP 예상 시기:
### 핵심 요구사항 요약
- 주요 기능:
- 연계 시스템:
- 보안 / 인증 요건:
### 기술 스택 추정
- 프론트엔드:
- 백엔드:
- 인프라:
### 리스크 항목
1.
2.
3.
### 대응 전략 메모마치며
RFI는 발주 기관이 던지는 첫 번째 언어다. 그 언어를 정확히 해독하는 능력이 기획자와 개발자를 가르는 경계선 중 하나다.
그러나 문서 분석만이 전부는 아니다. 실제 개발 현장에서는 RFI나 RFP가 모든 것을 담아내지 못한다. 문서에 적히지 않은 현업의 실제 불편함, 담당자도 미처 인식하지 못한 잠재적 요구사항은 오직 현업 인터뷰를 통해서만 수면 위로 올라온다.
결국 개발자는 문서를 읽는 것에서 멈추지 않고, 직접 현업 사용자를 만나 인터뷰하고, 그 내용을 바탕으로 요구사항 정의서(SRS, Software Requirements Specification) 를 스스로 작성할 줄 알아야 한다. 그것이 진짜 분석이고, 진짜 설계의 시작이다.
'사업관리' 카테고리의 다른 글
| RFP 란 무엇인가? - 공공사업 (1) | 2026.04.18 |
|---|