“RFP 보고 견적 냈는데, 막상 들어가 보니 요구사항이 세 배였어요.”
10여 년 전 함께 프로젝트를 했던 개발팀 리더가 한 말이다. 그때는 그냥 웃어넘겼다. “그런 거지, 뭐.” 하고.
지금은 다르게 생각한다. 그 리더의 팀이 야근을 밥 먹듯 한 이유, 그 프로젝트가 납기를 두 번이나 넘긴 이유가 거기 있었다. RFP가 엉망이었던 것이다. 그리고 그 엉망 RFP를 만든 원인은 ISMP 없이 발주했기 때문이었다.
들어가며 — 공공 IT 현장에서 가장 자주 보이는 비극
공공 IT 프로젝트를 20년 넘게 들여다본 사람으로서 솔직하게 말한다. 국내 정보화 사업에서 프로젝트가 실패하는 가장 큰 이유 중 하나는 기술이 부족해서가 아니다. 개발자가 실력이 없어서도 아니다.
요구사항이 처음부터 제대로 정의되지 않았기 때문이다.
계약서에는 “전산시스템 구축”이라고 돼 있다. 그런데 막상 사업을 시작하면 발주처는 “우리가 원하는 건 이게 아닌데요”를 연발한다. 수주업체는 “그건 RFP에 없는 내용입니다”로 맞선다. 이 갈등이 프로젝트 내내 이어지다 보면 일정이 늘어지고, 품질이 무너지고, 관계가 망가진다.
ISMP(Information System Master Plan, 정보시스템 마스터플랜)는 바로 이 문제를 해결하기 위해 만들어진 제도다. 2010년대 초반에 처음 도입될 때만 해도 현장에서 “왜 이걸 또 해야 하나”는 반응이 많았다. 하지만 지금, 6,000억 원짜리 차세대 지방행정시스템도 ISMP부터 시작하고, K-에듀 통합플랫폼 같은 국가 핵심 사업도 ISMP를 먼저 띄운다. ISMP가 선택이 아닌 필수가 된 것이다.
오늘은 ISMP가 무엇인지, 현장에서 어떻게 작동하는지, 왜 잘 되기도 하고 왜 실패하기도 하는지를 현장 PM 시각에서 날것 그대로 정리해 본다.
1. ISMP란 무엇인가 — 가장 쉬운 정의부터
ISMP(Information System Master Plan, 정보시스템 마스터플랜)를 한 줄로 정의하면 이렇다.
“시스템을 만들기 전에, 무엇을 어떻게 만들지를 아주 구체적으로 설계하는 선행 작업.”
좀 더 공식적으로는 이렇다. 특정 SW 개발 사업에 대한 상세분석과 제안요청서(RFP)를 마련하기 위해 비즈니스(업무) 및 정보기술에 대한 현황과 요구사항을 분석하고 기능점수 도출이 가능한 수준까지 기능적·기술적·비기능적 요건을 상세히 기술하며, 구축 전략 및 이행 계획을 수립하는 활동이다.
핵심은 “기능점수 도출이 가능한 수준까지”라는 말이다. 기능점수(Function Point)는 시스템이 처리할 기능의 크기를 객관적으로 측정하는 단위다. 이게 나온다는 건, 얼마짜리 사업인지를 숫자로 말할 수 있게 됐다는 뜻이다. ISMP 전에는 “대략 이 정도 들 것 같은데요”가 사업 예산이었다. ISMP 이후에는 근거 있는 숫자가 나온다.
ISP와 ISMP, 뭐가 다른가
이 두 개를 헷갈려 하는 사람이 많다. 간단히 짚고 넘어가자.
ISP는 조직의 경영목표 전략을 효과적으로 지원하기 위한 정보화전략 및 비전을 정의하고 IT 사업(과제) 도출 및 로드맵을 수립하는 활동이다. 따라서 ISP는 수행 범위에 있어 전사 정보시스템을 포괄하므로 특정 SW사업에 대한 요구사항 분석 및 제안요청서 작성과 직접적으로 연관되지 않는다. 이에 반해 ISMP는 특정 SW사업, 정보시스템에 대한 요구사항을 상세히 기술함으로써 제안요청서(RFP) 작성 및 구축사업 계획을 수립한다는 점에서 차이를 보인다.
현장에서는 이렇게 기억하면 편하다.
- ISP: “우리가 앞으로 5년 동안 뭘 할지” → 전략 지도(Map)
- ISMP: “이번에 만들 시스템이 정확히 무엇인지” → 시공 설계도(Blueprint)
ISP가 도시 개발 마스터플랜이라면, ISMP는 특정 건물의 건축 설계도다. 빌딩 짓기 전에 도면 없이 공사 시작하는 건축사가 없듯이, 차세대 시스템 구축 전에 ISMP 없이 발주하는 건 그것과 같다.
2. 왜 지금 ISMP가 더 중요해졌나 — 2025~2026 현장 분위기
솔직히 말하면, ISMP가 제도화된 초기에는 현장의 반응이 그리 뜨겁지 않았다. “귀찮은 절차가 하나 더 생겼다”는 인식이 많았다. 발주처는 “왜 시스템 만들기 전에 또 돈을 써야 하나”라고 했고, 수행사는 “이게 또 산출물 잔치 아닌가”라고 했다.
그런데 2025~2026년 들어 분위기가 확 바뀌었다. 이유가 몇 가지 있다.
이유 1: 차세대 사업 규모가 기하급수적으로 커졌다
차세대 지방행정공통시스템은 17개 광역시도 공무원이 사용하는 ‘시도행정시스템’과 228개 시군구 기초단체 공무원이 사용하는 ‘새올행정시스템’을 통합·개편하는 사업이다. 이 두 시스템은 19년 전 처음 구축된 후 지금까지 시스템 개편이 이뤄지지 않았다. 이로 인해 장애·해킹 등 위협요인에 지속 노출됐으며 시스템 노후화로 인한 신기술 적용 불가 등 구조적 한계 봉착했다.
ISMP 사업 자체는 8억 원 규모 수준이지만, 이어질 본사업 규모는 6,000억 원에 이르러 공공 최대 사업이 될 것으로 전망된다. 이런 규모의 사업을 ISMP 없이 그냥 발주할 수는 없다. 잘못 설계된 요구사항 하나가 나중에 수백억 원의 변경 비용으로 돌아온다.
이유 2: 교육, 복지, 국방 등 전 분야에서 차세대 사업이 쏟아진다
2025년 한 해에 발주된 ISMP 사업 목록을 보면 그 스펙트럼에 놀라게 된다. 법무부 전송형전자영장집행시스템, 한국과학기술기획평가원 데이터 중심 R&D 통합 플랫폼, 한국로봇산업진흥원 로봇실증 데이터 인프라, 대법원법원도서관 미래통합관리시스템, 한국부동산원 차세대경영정보시스템까지. 국가철도공단 중장기정보화전략기본계획(2026~2030) 수립, 국방부 국방재정정보체계 국가결산개편 고도화 ISP, 법무부 전송형전자영장집행시스템 구축 ISMP 등 말 그대로 전방위에서 사업이 터지고 있다.
K-에듀 통합플랫폼 사업은 총 7년간 약 6천억 원의 예산이 투입될 공공 분야 최대의 정보화 사업으로, 초중고 학교 교육 현장에 도입하는 에듀테크로서 대입 이전의 모든 교육 활동을 디지털 기반으로 전환하기 위해 사실상 모든 교육 자원을 집중시킬 플랫폼을 구축할 계획이다. 이런 규모의 사업에서 ISMP 없이 RFP를 만드는 건 상상하기 힘들다.
이유 3: ISP·ISMP 공통가이드 제9판이 2025년 5월 개정됐다
각 중앙관서는 ‘예산안 편성 및 기금운용계획안 작성 세부지침’, ‘예산 및 기금운용계획 집행지침’에 따라 정보시스템 구축·재구축 예산 요구에 앞서 정보화전략계획(ISP) 또는 정보시스템 마스터플랜(ISMP)을 수립하여 최종산출물에 대한 기획재정부의 검토를 받아야 한다. 기획재정부와 한국지능정보원(NIA)은 ISP·ISMP 수립 시 기본적으로 수행되어야 하는 사항, 단계별 준수해야 하는 절차와 기준 등을 정의한 ‘ISP·ISMP 수립 공통가이드’를 매년 개정·배포한다.
2025년 5월에 나온 제9판에는 소규모 정보시스템 구축 사업계획 수립 안내가 추가됐고, 클라우드 네이티브 방식 우선 검토 기준이 더욱 명확해졌다. 디지털플랫폼정부(DPG) 기본원칙인 클라우드 기술 우선 적용, 국민 중심, AI·데이터 기반 서비스 등을 ISMP 단계에서부터 검토해야 하는 것이 의무화됐다. 이는 ISMP가 단순한 요구사항 문서를 넘어 디지털 전환 전략의 첫 관문이 됐다는 뜻이다.
3. ISMP의 핵심 구조 — 뭘 어떻게 하는 건가
ISMP를 처음 접하는 사람들이 가장 많이 묻는 질문이다. 구조를 명확히 이해하면 수행도, 발주도, 검수도 훨씬 쉬워진다.
ISMP의 4대 요구사항 유형
ISMP의 핵심 산출물은 요구사항 정의서다. ISMP 방법론은 특정 SW사업에 대한 사용자 및 비즈니스의 기능 요구사항·기술 요구사항·비기능 요구사항(성능, 품질, 보안)·프로젝트 지원 요구사항을 상세 설계한다.
이 네 가지가 뭔지 구체적으로 살펴보자.
① 기능 요구사항: “이 시스템이 무엇을 해야 하는가”다. 사용자가 특정 버튼을 눌렀을 때 어떤 처리가 일어나고, 어떤 결과가 나와야 하는지까지 기술한다. 입력값, 처리 로직, 출력값이 모두 정의돼야 한다. 이게 제대로 안 되면 개발자는 “어떻게 만들어야 할지 모르겠다”가 된다.
② 기술 요구사항: “어떤 기술 환경에서 만들어야 하는가”다. 운영체제, 데이터베이스, 미들웨어, 클라우드 방식, API 연계 방식 등이 여기 포함된다. 현재 가이드에서는 클라우드 도입 방안을 민간 클라우드 → 공공 클라우드 → 자체 클라우드 → 장비도입 순으로 검토하도록 명시하고 있다. 기술 요구사항이 명확해야 나중에 아키텍처 설계 단계에서 뒤집는 일이 없다.
③ 비기능 요구사항: “얼마나 잘 돼야 하는가”다. 성능(응답 속도), 가용성(장애 시간 허용 범위), 보안(암호화 수준, 접근 통제), 데이터 품질 기준이 여기 들어간다. 이 부분이 모호하면 나중에 “느려도 괜찮다고 했잖아요”, “보안은 기본만 하기로 했잖아요” 같은 말이 나온다. 수치화된 기준이 없으면 검수 때 분쟁의 씨앗이 된다.
④ 프로젝트 지원 요구사항: “프로젝트 진행 과정에서 발주처가 어떤 지원을 할 것인가”다. 현업 담당자 참여 계획, 데이터 이관 지원 방식, 테스트 환경 제공 여부 등이 여기 해당한다. 현장에서 가장 많이 빠지는 부분인데, 이게 없으면 나중에 “데이터 이관은 개발사가 알아서 해야 하는 거 아닌가요?”같은 황당한 상황이 생긴다.
ISMP의 핵심 산출물: 기능점수와 RFP
ISMP의 모든 작업은 결국 두 가지로 수렴한다. 기능점수(FP) 산출과 RFP(제안요청서) 작성이다.
기능점수는 시스템 규모를 객관적으로 측정하는 지표다. FP당 단가(2024년 기준 605,784원, 2023년 553,114원에서 9.52% 인상됨)를 곱하면 개발 예산의 합리적인 추정치가 나온다. 발주처는 “우리 예산으로 어디까지 가능한지”를 알 수 있고, 수행사는 “이 사업 규모가 정확히 얼마짜리인지”를 알 수 있다.
RFP는 ISMP의 최종 산출물이자 후속 구축사업의 출발점이다. 목표시스템 개념을 다소 피상적으로 기술하는 기존 제안요청서 작성 방식과는 달리, 관련 업무 및 정보기술 현황을 체계적으로 파악하고, 이용자 요구사항을 상세 분석하며, 제안요청서에 목표시스템의 기능 및 요건을 구체적으로 정의한다. 이처럼 제안요청서 명확성을 높임으로써 해당 사업의 규모 및 복잡도를 정확하게 산출할 수 있고, 여러 제안업체가 제시한 제안서를 공정하게 평가할 수 있다.
실제로 ISMP로 만들어진 RFP를 보면 두께부터 다르다. 기존 방식의 RFP가 30~50페이지라면, ISMP 기반 RFP는 200~400페이지를 넘기는 경우도 많다. 두껍다고 다 좋은 건 아니지만, 그 두께 안에 “이 기능은 이렇게 작동해야 한다”는 구체성이 담겨 있다.
4. ISMP 수행 단계별 현장 가이드 — PM이 실제로 봐야 할 것들
이론은 충분히 했다. 이제 실전이다. ISMP를 발주하거나 수행하는 PM 입장에서 각 단계에서 실제로 어떻게 접근해야 하는지를 정리한다.
Phase 1: 사업 착수 및 현황 분석 (2~4주)
착수 단계에서 해야 할 가장 중요한 일은 이해관계자 지도(Stakeholder Map)를 그리는 것이다. 이게 없으면 ISMP가 끝날 때까지 “이 사람이 원하는 게 뭔지”를 모르게 된다.
이해관계자는 계층별로 나눈다. 경영진(CIO, 담당 임원)은 사업의 전략적 방향과 예산 한계를 가장 잘 안다. 실무 부서장은 현재 시스템의 한계와 업무상 불편함을 구체적으로 안다. 현장 실무자는 시스템이 실제로 어떻게 쓰이고 있는지, 어디서 수작업이 생기는지를 안다. 이 세 계층 중 하나라도 빠지면 요구사항에 구멍이 생긴다.
현황 분석에서 빠지기 쉬운 것이 기존 시스템의 인터페이스 목록이다. 내부 시스템끼리의 연계, 외부 기관과의 연계가 모두 파악돼야 한다. 차세대 시스템을 만들더라도 기존 연계를 다 끊을 수는 없기 때문이다. 연계 목록이 누락되면 구축 단계에서 “이건 인터페이스 추가 개발이 필요하다”는 말이 나오면서 예산이 터진다.
Phase 2: 요구사항 분석 (4~8주)
요구사항 분석은 ISMP의 심장이다. 여기서 시간이 가장 많이 걸리고, 품질이 가장 중요하다.
요구사항 도출 방법은 크게 세 가지다. 인터뷰, 워크샵, 문서 분석. 이 세 가지를 조합해서 써야 한다. 인터뷰만 하면 “말해줬는데 왜 RFP에 없나”가 나온다. 워크샵만 하면 조용한 실무자의 중요한 니즈가 묻혀버린다. 문서 분석만 하면 현실과 다른 프로세스를 설계하게 된다.
현장에서 효과적인 방법이 있다. 요구사항 도출 워크샵에서 포스트잇 방식을 쓰는 것이다. 각 담당자가 자신의 업무 이슈를 포스트잇에 써서 붙이고, 비슷한 것끼리 묶어서 우선순위를 매긴다. 이게 회의식 인터뷰보다 훨씬 다양한 의견을 끌어낸다. 목소리 큰 사람이 회의를 지배하는 현상을 막을 수 있다.
요구사항 작성에서 가장 중요한 원칙은 **측정 가능성(Measurability)**이다. “빠르게 처리되어야 한다”는 요구사항이 아니다. “3초 이내에 응답해야 한다”가 요구사항이다. “안전해야 한다”가 아니라 “개인정보는 AES-256으로 암호화해야 하고, 접근 이력은 2년간 보관해야 한다”가 요구사항이다. 측정 불가능한 요구사항은 나중에 검수 때 반드시 분쟁이 된다.
Phase 3: 아키텍처 및 기술 설계 (3~5주)
여기서 ISMP가 단순한 요구사항 문서가 아니라 진짜 설계 작업임이 드러난다. 기능 요구사항만으로는 시스템을 만들 수 없다. 어떤 구조로, 어떤 기술을 써서, 어떤 환경에서 돌아갈지를 설계해야 한다.
2025년 이후 ISMP 아키텍처 설계에서 반드시 다뤄야 할 세 가지가 있다.
클라우드 전환 방향: 현재 가이드는 민간 클라우드 우선 도입을 권고하고 있다. 그러나 공공기관 특성상 보안, 데이터 주권 이슈로 민간 클라우드를 바로 선택하기 어려운 경우가 많다. ISMP에서 이 결정을 명확히 하지 않으면 구축 단계에서 인프라 방향이 흔들린다.
데이터 표준화와 마이그레이션: 차세대 시스템의 가장 큰 위험 중 하나가 데이터 이관이다. 기존 시스템에 10년치 데이터가 쌓여 있는데, 그 데이터 품질이 어떤 상태인지를 ISMP에서 파악해야 한다. 불량 데이터가 얼마나 있는지, 이관 전 정제가 필요한지, 이관 기간과 비용이 얼마나 드는지가 사전에 분석돼야 한다.
AI·데이터 기반 서비스 검토: 2025년 이후 ISMP에서 AI 기능 요구사항을 포함하는 사례가 급격히 늘었다. 그런데 AI를 막연하게 “AI로 자동화”라고만 쓰면 의미가 없다. 어떤 업무를 AI로 처리하고, 그 AI의 정확도 기준은 무엇이며, 학습 데이터는 어디서 확보하는지까지 ISMP에서 정의해야 한다.
Phase 4: 구축 전략 및 이행계획 (2~3주)
ISMP의 마지막 단계는 “이걸 언제, 어떻게, 얼마에 만들 것인가”를 확정하는 것이다.
이행계획에서 가장 중요한 게 단계 분할 전략이다. 모든 기능을 한 번에 구축하려다가 실패하는 프로젝트를 너무 많이 봤다. 특히 6,000억 원짜리 사업은 절대로 통으로 발주하지 않는다. 규모가 워낙 큰 사업이라 단일 발주보다는 여러 분야로 쪼개 나올 것이라는 분석이 많다고 업계에서 이미 예측하고 있다. ISMP에서 이 분할 기준과 단계별 범위를 합리적으로 정의해야 한다.
이행계획에는 PMO(Project Management Office) 운영 방안도 포함돼야 한다. 특히 대형 사업은 발주처 자체적으로 프로젝트를 관리할 역량이 충분하지 않은 경우가 많다. ISMP 단계에서 PMO 필요 여부, 운영 방식, 필요 인력까지 사전에 계획해야 한다.
5. ISMP가 가져오는 실질적 효과 — 숫자와 현장 경험으로
ISMP를 왜 해야 하는지에 대한 가장 강력한 근거는 역시 실제 효과다.
전반적으로 목표시스템 범위 정립, 현업부서와 개발부서 간 정보 공유 및 협력 증진, 발주기관과 수주업체 사이의 의사소통 원활, 요구사항 변경 감소 등 긍정적 효과가 발생하였다.
이걸 현장에서 본 경험으로 번역하면 이렇다.
요구사항 변경 감소: 프로젝트에서 요구사항이 변경될 때마다 비용이 든다. 기능 하나 추가하는 데 분석·설계·개발·테스트를 다시 해야 한다. ISMP를 제대로 하면 이 변경 빈도가 확연히 줄어든다. 내가 경험한 ISMP 적용 프로젝트와 미적용 프로젝트를 비교하면, 요구사항 변경 건수가 절반 이하로 줄어드는 게 일반적이다.
공정한 제안서 평가: RFP가 명확하면 여러 수행사의 제안서를 공정하게 비교할 수 있다. 모호한 RFP는 “각사가 알아서 해석”하게 만든다. 그러면 제안서 비교가 어렵고, 낙찰 이후에 “우리는 이렇게 이해했는데”라는 말이 나온다. 사업 규모 및 예산의 객관화된 산정, 요구사항 상세화를 통한 과업 명확화와 불합리한 과업 변경 최소화, 분석·설계 단계의 기간 지연 예방과 개발 일정 단축으로 인한 SW 품질 저하 예방이 ISMP의 주요 기대효과다.
현업과 개발의 소통 구조화: ISMP 과정에서 현업 담당자가 직접 요구사항 정의에 참여한다. 이 과정이 나중에 구축 단계에서 “그거 당연히 되는 거 아닌가요?”를 막아준다. 현업이 자신이 원하는 것을 글로 써보고 확인하는 과정을 거쳤기 때문이다.
6. ISMP의 실패 패턴 — 현장에서 직접 본 것들
좋은 면만 말하면 반쪽이다. ISMP도 잘못 하면 비효율의 집합이 된다.
실패 패턴 1: 현업이 빠진 ISMP
ISMP를 IT 부서가 혼자 하는 경우가 있다. 인터뷰는 형식적으로만 하고, 실제 요구사항은 IT 담당자가 “알아서” 정의한다. 이렇게 만들어진 요구사항은 나중에 반드시 “이건 우리가 원하던 게 아니다”로 돌아온다. 현업이 주인공이 돼야 하는 게 ISMP다.
실패 패턴 2: 요구사항이 기능 목록에 그친다
“로그인 기능”, “사용자 관리”, “보고서 출력”… 이런 수준의 기능 목록은 ISMP가 아니다. 각 기능이 어떤 입력을 받아서, 어떤 처리를 하고, 어떤 결과를 내는지까지 정의해야 진짜 ISMP다. 기능 목록 수준에서 만들어진 RFP로는 기능점수를 산출할 수 없다.
실패 패턴 3: 비기능 요구사항이 없다
성능, 보안, 가용성이 “최고 수준으로” 또는 “관련 법령 준수”로만 기술되는 경우가 많다. 이건 의미 없는 문구다. 응답 시간 3초 이내, 시스템 가동률 99.9% 이상, 개인정보 암호화 AES-256 적용처럼 구체적인 수치가 있어야 나중에 검수 기준이 된다.
실패 패턴 4: ISMP 수행사가 구축사업 수주를 염두에 두고 수행한다
ISMP 수주 시 본사업까지 수주할 것이라는 게 업계 관측이다. 이 때문에 이번 ISMP 사업 역시 규모는 작지만 이를 수주하기 위한 대기업과 중견기업 경쟁이 치열할 것으로 보인다.
이 구조가 ISMP 품질에 독이 되는 경우가 있다. ISMP를 수행하면서 자사에게 유리한 기술 아키텍처를 설계하거나, 자사가 잘하는 방향으로 RFP를 작성하는 경우다. 발주처가 이를 걸러내지 못하면, ISMP가 특정 업체를 위한 설계 문서가 된다. 발주처는 ISMP 결과물을 외부 전문가를 통해 독립적으로 검토하는 절차를 고려해야 한다.
실패 패턴 5: 기간이 너무 짧다
ISMP를 2~3개월 안에 끝내라는 압박이 종종 온다. 규모가 큰 사업일수록 이 기간은 턱없이 짧다. 제대로 된 인터뷰, 워크샵, 요구사항 검증까지 다 하려면 최소 4~6개월은 필요하다. 기간을 압박받으면 요구사항의 깊이가 얕아지고, 나중에 구축 단계에서 그 비용을 훨씬 크게 치르게 된다.
7. ISMP 성공 요인 — 현장 경험과 연구 결과의 교차점
ISMP 수행 성공요인으로서 ISMP 필요성에 대한 사전공감대 형성, CEO와 CIO의 지원에 의한 ISMP 수행 자원 확보, 요구사항 상세화 수준의 일관성 있는 적용 등 세 가지 요인이 도출됐다.
학술 연구의 결과인데, 현장에서 느끼는 것과 정확히 일치한다. 이 세 가지를 현장 언어로 풀어보면 이렇다.
성공 요인 1: 사전 공감대 형성 — “왜 이게 필요한지”를 먼저 팔아라
ISMP를 시작하기 전에 발주처 내부에서 “이번에 제대로 된 RFP를 만들어보자”는 공감대가 형성돼 있어야 한다. 이게 없으면 현업 담당자들이 인터뷰에 성의 없이 임하고, 워크샵에 나오지 않는다. PM은 킥오프 전에 반드시 발주처 내부 설명회를 요청해야 한다.
성공 요인 2: CEO·CIO의 지원 — 권한 있는 사람이 뒤를 봐줘야 한다
요구사항 분석 과정에서 부서 간 이해관계 충돌이 반드시 생긴다. A 부서는 이 기능이 필요하다 하고, B 부서는 그 기능이 자기 업무를 침범한다 한다. 이런 충돌을 해결할 수 있는 건 최고 의사결정자뿐이다. CIO가 “우리는 이 방향으로 간다”고 결정해줘야 ISMP가 앞으로 나간다.
성공 요인 3: 요구사항 상세화 수준의 일관성 — 어디까지 쓸지를 미리 정해라
모든 기능에 대해 같은 깊이로 요구사항을 정의하는 것이 중요하다. 어떤 기능은 아주 상세하게, 어떤 기능은 개략적으로 쓰면 나중에 “이건 ISMP에 없는 내용이니 별도 과업”이라는 말이 나온다. 착수 단계에서 요구사항 작성 템플릿과 상세화 수준 기준을 합의해야 한다.
8. 발주처 담당자가 꼭 알아야 할 것 — ISMP를 사는 쪽의 입장
ISMP를 발주하는 담당자 입장에서 현장 조언을 드린다.
조언 1: ISMP 수행사 선정 기준을 명확히 하라
ISMP 수행사를 고를 때 규모나 레퍼런스만 보면 안 된다. 요구사항 정의 전문성이 핵심이다. 수행사가 “이 분야 시스템을 만들어봤다”는 것과 “이 분야 요구사항을 제대로 정의할 수 있다”는 건 다른 문제다. 제안 평가에서 요구사항 도출 방법론, 샘플 산출물, 해당 분야 비즈니스 이해도를 중점적으로 봐야 한다.
조언 2: 현업 참여 계획을 사전에 수립하라
ISMP를 발주하기 전에 내부적으로 “우리 현업이 얼마나, 어떻게 참여할 것인가”를 정해야 한다. 인터뷰에 누가 응할 것인지, 워크샵에 누가 참석할 것인지, 요구사항 검토에 누가 사인할 것인지. 이게 없으면 ISMP 기간 내내 “담당자가 바빠서 시간이 안 된다”는 말이 나온다.
조언 3: 독립적인 품질 검토 메커니즘을 만들어라
앞서 말한 것처럼 ISMP 수행사가 본사업을 염두에 두고 수행할 수 있다. 이를 막으려면 ISMP 진행 중간 단계와 최종 산출물에 대한 독립적인 검토가 필요하다. 감리법인을 통한 중간 검토, 또는 외부 전문가 자문을 활용하는 것이 효과적이다.
조언 4: ISMP 예산을 아끼려 하지 마라
ISMP는 전체 사업비의 1~3% 수준이다. 100억짜리 시스템 구축 사업이라면 ISMP 예산은 1억~3억 원 정도다. 이걸 아끼려고 ISMP를 형식적으로 하거나 기간을 줄이면, 나중에 구축 단계에서 요구사항 변경으로 그 몇 배의 비용을 치른다. ISMP는 보험이다. 싸게 사면 나중에 적용이 안 된다.
9. 수행사 PM이 꼭 알아야 할 것 — ISMP를 파는 쪽의 입장
이번엔 ISMP를 수행하는 PM 입장이다.
핵심 1: 요구사항 트레이서빌리티(Traceability)를 유지하라
요구사항이 어디서 나왔는지, 누가 요청했는지, 어떤 업무 목적을 위한 것인지를 추적 가능하게 관리해야 한다. 나중에 “이 요구사항 왜 있는 거예요?”라는 질문에 바로 답할 수 있어야 한다. 이게 없으면 요구사항이 검수 과정에서 하나둘 빠지기 시작한다.
핵심 2: 요구사항 검토 회의를 형식화하라
현업 담당자가 요구사항을 검토하고 서명하는 절차를 반드시 거쳐야 한다. “구두로 확인했다”는 나중에 법적 효력이 없다. 요구사항 정의서를 버전별로 관리하고, 각 버전에 대한 검토자 서명을 받아야 한다. 이게 귀찮아 보이지만 나중에 분쟁이 생겼을 때 이 문서가 프로젝트를 살린다.
핵심 3: 범위 외 요구사항 관리 프로세스를 만들어라
ISMP 수행 중에 “이것도 넣어줄 수 있어요?”라는 요청이 계속 온다. 이걸 다 수용하면 ISMP 기간이 늘어나고 품질이 흔들린다. 범위 외 요청에 대해 “별도 사업으로 검토하겠습니다” 또는 “이번 ISMP 범위에 포함하려면 기간과 예산 조정이 필요합니다”라는 정식 프로세스를 착수 단계에 합의해야 한다.
10. 2026년 ISMP의 변화 — AI와 디지털플랫폼정부가 바꾸는 것들
마지막으로 앞을 내다본다.
2025년 개정된 공통가이드(제9판)는 ISMP에 몇 가지 새로운 요소를 추가했다. 그 중 가장 중요한 것이 디지털플랫폼정부(DPG) 기본원칙의 ISMP 단계 적용이다. 클라우드 기술 우선 적용, 국민 중심 서비스, AI·데이터 기반 운영이 이제 ISMP 요구사항 정의 단계에서부터 검토돼야 한다.
이게 현장에 미치는 영향은 구체적이다. 기존 ISMP에서 “클라우드 도입 여부”를 결론 부분에서 한두 페이지로 다루던 것을, 이제는 민간 클라우드 → 공공 클라우드 → 자체 클라우드 → 장비도입의 순서로 체계적으로 검토한 결과를 제시해야 한다. 클라우드 도입이 불가능하다면 구체적인 사유를 제시해야 한다.
AI 요구사항도 마찬가지다. “AI로 자동화”가 아니라, AI를 적용할 업무 영역, 기대 효과, 데이터 확보 방안, AI 성능 기준, AI 거버넌스 체계까지 ISMP에서 설계해야 하는 시대가 오고 있다. 이건 ISMP 수행사가 AI에 대한 기본 소양을 갖춰야 한다는 의미이기도 하다. “나는 요구사항 전문가지, AI 전문가가 아니다”는 말이 통하지 않는 시대가 됐다.
SW 개발 단가도 계속 오르고 있다. 2024년 기준 기능점수당 단가가 605,784원으로 인상됐는데, 이는 AI 도입, 보안 강화, 클라우드 전환 등 개발 복잡도가 높아지는 현실을 반영한다. ISMP에서 기능점수를 산출할 때 이런 단가 변화를 반영한 최신 기준을 써야 현실적인 예산 추정이 나온다.
마치며 — RFP 한 장의 무게
다시 처음으로 돌아가서.
10년 전, 야근을 밥 먹듯 한 그 팀의 리더는 분명 실력이 없어서 야근한 게 아니었다. 요구사항이 모호한 RFP를 받아서, 계약 후에 끝없이 바뀌는 요구사항을 처리하면서, 그 책임을 고스란히 짊어졌을 뿐이다.
ISMP는 그 리더를 위한 제도다. 발주처와 수행사가 같은 그림을 보고 출발하게 만드는 장치다. 계약 전에 “우리가 만들 것이 이것이다”를 글로 쓰고, 서로 확인하고, 서명하는 과정.
이게 귀찮고 비용이 든다고 느낄 수 있다. 하지만 이걸 생략하면, 그 비용은 구축 단계에서 몇 배로 돌아온다. 그리고 그 비용을 고스란히 짊어지는 건 현장의 개발자들이다.
ISMP를 제대로 하는 것이 발주처를 위한 일이면서, 동시에 수행사를 위한 일이고, 결국에는 그 시스템을 쓸 사용자를 위한 일이다.
RFP 한 장의 무게가 생각보다 훨씬 무겁다는 것, 이 글을 읽은 분들이 기억해 주셨으면 한다.