ISMP로 개발사업 요구사항과 RFP를 구체화하는 법
ISMP의 수행 흐름과 기능점수 산정, RFP 작성까지 SW 개발 사업을 구체화하는 핵심 산출물과 관리 관점을 정리한다.
2026-08-14 · 최초 발행 2025-05-23
개발사업의 출발점을 구체화하는 ISMP
ISMP(Information Strategy Master Plan)는 특정 소프트웨어 개발 사업을 추진하기 위한 전략적 계획 수립 활동이다. 조직의 비즈니스와 IT 현황을 분석하고, 그 결과를 요구사항으로 도출한 뒤 기능점수(Function Point)를 산정할 수 있을 만큼 상세화한다. 이 과정은 제안요청서(RFP)의 근거가 되며, 구축 전략과 단계별 이행 계획까지 함께 다룬다.
개발 범위를 명확히 하고 비용과 기간을 예측할 근거를 만드는 것이 ISMP의 역할이다. 발주자와 개발사 사이의 해석 차이를 줄이고, 개발 중 범위 변경과 리스크를 관리할 기반도 마련한다. 정보화 투자 효율을 높이기 위한 계획 활동이기도 하다.
현황에서 RFP까지 이어지는 작업 흐름
ISMP는 현황을 파악하는 단계에서 출발해 요구사항과 설계 방향을 정리하고, 사업 발주에 필요한 RFP를 작성하는 흐름으로 진행된다.
현황 분석에서는 비즈니스 프로세스와 조직, 기존 정보시스템을 AS-IS 관점에서 검토한다. 관련 법과 제도, 기술 동향과 선진 사례를 조사하고, 이해관계자 인터뷰와 업무 워크숍을 통해 실제 업무 맥락을 확인한다. A 공공기관의 ISMP에서는 기존 레거시 시스템에서 데이터 일관성 부재, 업무 프로세스와 시스템의 불일치, 시스템 간 연계 미흡이 문제로 확인됐다.
이후 업무 요구사항, 사용자 요구사항, 기능 요구사항, 비기능 요구사항, 제약사항을 정리한다. 요구사항은 Use Case 모델링, 데이터 모델링, 기능 정의서, 화면 프로토타입, 인터페이스 요구사항으로 더 세밀하게 표현한다. 기능 정의서는 사업 범위와 구현 대상을 같은 기준으로 논의하게 만드는 문서다.
| 기능 ID | 기능명 | 상세 설명 | 입력 데이터 | 출력 데이터 | 관련 업무 | 우선순위 |
|---|---|---|---|---|---|---|
| F001 | 회원 등록 | 신규 사용자 정보 등록 기능 | 개인정보, 계정정보 | 등록 결과 | 회원관리 | 상 |
| F002 | 거래 내역 조회 | 특정 기간의 거래 내역 조회 | 조회 기간, 조회 조건 | 거래 목록 | 거래관리 | 중 |
아키텍처 설계에서는 애플리케이션, 데이터, 기술, 보안, 인프라 아키텍처를 다룬다. 이후 개발 방법론과 아웃소싱 전략, 품질 관리, 추진 체계, 위험 관리 방안을 정하고, 단계별 로드맵·일정·예산·투자 대비 효과·변화관리 전략을 이행 계획에 반영한다. RFP에는 사업 개요와 범위, 상세 요구사항, 제안서 평가 기준, 계약 조건과 이행 요건, 산출물과 품질 기준을 담는다.
계층을 나눠 보는 아키텍처
업무 기능과 데이터 처리, 인프라의 연결 관계는 설계 단계에서 함께 검토해야 한다.
기능점수로 규모를 산정하는 방식
기능점수 산정은 ISMP에서 사업 규모와 비용을 객관적으로 산정하기 위한 중요한 작업이다. 데이터 기능은 내부 논리 파일(ILF: Internal Logical File)과 외부 연계 파일(EIF: External Interface File)로, 트랜잭션 기능은 외부 입력(EI: External Input)·외부 출력(EO: External Output)·외부 조회(EQ: External Inquiry)로 구분한다.
총 기능점수 = 데이터 기능점수 + 트랜잭션 기능점수
데이터 기능점수:
- ILF 10개 (복잡도 높음) × 15 = 150점
- EIF 5개 (복잡도 중간) × 7 = 35점
트랜잭션 기능점수:
- EI 20개 (복잡도 중간) × 4 = 80점
- EO 15개 (복잡도 높음) × 7 = 105점
- EQ 25개 (복잡도 낮음) × 3 = 75점
총 기능점수 = 150 + 35 + 80 + 105 + 75 = 445 FP
계획 문서가 남겨야 할 근거
ISMP의 결과물은 분석 보고서만으로 끝나지 않는다. 현황 분석 보고서에는 AS-IS 업무 프로세스 모델, 정보시스템 현황 분석서, 이슈 및 개선과제 목록이 포함된다. TO-BE 모델에는 업무 프로세스와 애플리케이션 아키텍처, 데이터 아키텍처가 담긴다.
요구사항 명세서는 기능·비기능·인터페이스 요구사항을 구분해 기록한다. 구축 전략과 이행 계획에서는 단계별 로드맵, 투자 계획 및 ROI 분석, 위험 관리 계획을 제시한다. RFP에는 사업 개요와 추진 배경, 상세 요구사항 목록, 제안서 작성 지침과 평가 기준이 이어진다.
참여와 검증이 빠질 때 생기는 문제
ISMP의 품질은 이해관계자가 얼마나 실질적으로 참여하는지에 달려 있다. 경영진의 지원, 실무자의 충분한 의견 수렴, 외부 컨설턴트와 내부 실무자 사이의 협업 체계가 필요하다. 요구사항에는 우선순위를 부여하고, 상충 항목을 조정하며, 변경 관리 절차를 둬야 한다.
프로젝트 범위도 경계를 분명히 해야 한다. 단계별 목표와 성과 지표를 정하고 범위 확장(Scope Creep)을 막을 방안을 마련해야 한다. 실제 현황 파악 없이 문서 작업에만 치중하거나 기존 자료를 그대로 재활용하면 계획은 형식에 머문다. 검증 없는 계획, 지나치게 낙관적인 일정, 리스크를 반영하지 않은 예산, 조직의 수용 능력을 넘는 변화 속도 역시 실패 요인이 된다.
B 기업에서는 현업 참여 부족으로 실제 업무와 괴리된 요구사항이 도출됐다. 이후 개발 단계에서 대규모 요구사항 변경이 발생했고, 프로젝트 지연과 예산 초과로 이어졌다.
EA·ISP와 ISMP가 연결되는 위치
ISMP는 조직 전체의 정보화 구조와 전략을 특정 개발 사업의 실행 계획으로 이어 주는 위치에 있다.
EA(Enterprise Architecture)는 조직 전체 정보화 구조를 설계하는 최상위 수준의 계획이다. ISP(Information Strategy Planning)는 조직의 정보화 전략을 수립하는 중간 수준의 계획이며, ISMP는 특정 개발 사업에 초점을 둔 실행 수준의 계획이다.
사례에서 확인되는 계획 품질의 차이
C 금융기관의 차세대 시스템 구축 ISMP에서는 경영진의 지원과 리더십, 현업 전문가의 전담팀 구성 및 풀타임 참여, 단계별 검증과 피드백 체계, 요구사항 우선순위화와 단계적 구현 전략이 성공 요인으로 작용했다. 이 사례는 기존 예상보다 20% 정확한 예산 및 일정 산정, 개발 과정의 주요 요구사항 변경 최소화, 시스템 오픈 후 안정화 기간 단축, 사용자 만족도 90% 이상이라는 성과로 이어졌다.
D 공공기관은 최초 ISMP에서 기능점수 산정 오류에 따른 예산 부족, 비기능 요구사항 명세 부실에 따른 성능 이슈, 데이터 연계 요구사항 분석 미흡에 따른 통합 어려움을 겪었다. 이후 기능점수 산정 전문가를 참여시키고, 비기능 요구사항 분석과 검증을 강화했으며, 데이터 연계 요구사항을 상세화했다. 이해관계자 참여와 커뮤니케이션도 확대했다.
ISMP는 시스템 구축 자체를 위한 문서가 아니라, 조직의 전략적 목표와 비즈니스 요구를 개발 사업의 범위·요구사항·이행 계획으로 연결하는 로드맵이다. 기술과 시장 환경의 변화를 고려하고, 성과 지표와 측정 방법을 통해 진행 상황과 효과를 검증하며, 정보보안과 리스크 관리까지 계획에 통합해야 한다.