Skip to content
Published on

IT사업 기획과 제안서 작성 완전 가이드: RFP 분석·ISMP·WBS·비용 산정·SLA까지

Authors
  • Name
    Twitter

IT사업 기획과 제안서 작성

들어가며

IT사업은 단순히 시스템을 개발하는 것이 아니라, 조직의 전략적 목표를 기술로 구현하는 종합적인 활동이다. 성공적인 IT사업을 위해서는 사업 기획 단계부터 제안서 작성, 프로젝트 수행, 그리고 서비스 운영까지 체계적인 접근이 필요하다.

한국의 IT사업 환경은 공공과 민간 영역에서 서로 다른 특성을 보인다. 공공 IT사업은 조달청 나라장터를 통한 입찰 절차, 소프트웨어 진흥법에 따른 사업 대가 산정 기준, 그리고 국가정보화 기본법에 근거한 정보화전략계획(ISMP) 수립 의무 등 엄격한 규정이 적용된다. 민간 IT사업은 상대적으로 유연하지만, 비용 대비 효과(ROI)를 명확히 증명해야 하는 비즈니스 논리가 더욱 중요하다.

이 글에서는 IT사업의 유형과 생명주기를 시작으로, RFP 분석 전략, ISMP 방법론, 제안서 작성 핵심 기법, 프로젝트 계획 수립, 비용 산정과 ROI 분석, SLA 관리, 그리고 실제 성공 사례까지 IT사업 기획의 전 과정을 실무 관점에서 체계적으로 다룬다.

IT사업의 유형과 생명주기

IT사업의 주요 유형

IT사업은 수행 목적과 방식에 따라 크게 다음과 같이 분류된다.

유형설명주요 특징
SI (System Integration)새로운 정보시스템의 분석, 설계, 개발, 구축명확한 시작과 종료, 산출물 중심
SM (System Management)구축된 시스템의 운영, 유지보수연단위 계약, SLA 기반 관리
컨설팅IT전략 수립, 진단, 개선 방안 도출지식 기반 서비스, 보고서 산출
SaaS 도입클라우드 기반 소프트웨어 서비스 도입구독 모델, 커스터마이징 범위 제한
클라우드 전환온프레미스에서 클라우드로의 마이그레이션인프라 재설계, 리팩토링 필요
데이터 분석빅데이터, AI/ML 기반 분석 시스템 구축데이터 품질이 성패 좌우

IT사업 생명주기

IT사업은 기획에서 폐기까지 뚜렷한 생명주기를 거친다.

사업 기획 → 예산 확보 → RFP 작성 → 입찰/제안 → 평가/선정 → 착수 → 수행 → 검수/종료 → 운영/유지보수

각 단계별 핵심 활동은 다음과 같다.

1단계: 사업 기획

  • 현행 시스템 분석(As-Is) 및 목표 시스템 정의(To-Be)
  • 사업 타당성 분석 (기술적, 경제적, 운영적 타당성)
  • 이해관계자 식별 및 요구사항 수집
  • 사업 범위 및 추진 전략 수립

2단계: 예산 확보 및 조달

  • 사업 대가 산정 (SW사업 대가산정 가이드 기준)
  • 예산 요구서 작성 및 승인
  • 조달 방식 결정 (일반경쟁, 제한경쟁, 수의계약)

3단계: 제안 및 선정

  • RFP 작성 및 공고
  • 사전 설명회(Pre-bid Conference) 개최
  • 제안서 접수 및 기술/가격 평가
  • 우선협상대상자 선정 및 계약 체결

4단계: 사업 수행

  • 착수 보고, 중간 보고, 최종 보고
  • 단계별 산출물 검토 및 품질 관리
  • 변경 관리(Change Management) 프로세스 운영
  • PMO에 의한 거버넌스 관리

공공 IT사업과 민간 IT사업의 차이

# 공공 IT사업 특징
규제_환경:
  - 국가정보화 기본법
  - 소프트웨어 진흥법
  - 전자정부법
  - 조달청 계약 규정

대가_산정:
  기준: SW사업 대가산정 가이드 (과학기술정보통신부)
  방식:
    - 기능점수(FP) 방식
    - 투입공수(Man/Month) 방식

입찰_방식:
  - 일반경쟁입찰 (기본)
  - 제한경쟁입찰 (자격 제한)
  - 협상에 의한 계약 (기술 중심 평가)

# 민간 IT사업 특징
의사결정:
  - C-Level 승인 중심
  - 비즈니스 케이스(ROI) 기반
  - 벤더 관계 및 레퍼런스 중요

계약_방식:
  - 정액(Fixed Price)
  - 실비정산(Time and Material)
  - 성과기반(Outcome-based)

RFP 분석과 대응 전략

RFP의 구조 이해

RFP(제안요청서)는 발주 기관이 IT사업의 목적, 범위, 요구사항, 평가 기준 등을 정리하여 제안사에 전달하는 핵심 문서다. 잘 작성된 RFP를 정확히 분석하는 것이 제안 성공의 첫걸음이다.

RFP 일반 구조:

1. 사업 개요
   - 사업 배경 및 목적
   - 사업 범위
   - 추진 일정
   - 사업 예산

2. 현행 시스템 현황
   - 인프라 구성도
   - 응용시스템 현황
   - 데이터 현황

3. 요구사항
   - 기능 요구사항 (FR)
   - 비기능 요구사항 (NFR)
   - 데이터 요구사항
   - 인터페이스 요구사항
   - 보안 요구사항

4. 제안 요건
   - 기술 부문 (시스템 구성, 아키텍처)
   - 관리 부문 (방법론, 조직, 일정)
   - 지원 부문 (교육, 유지보수, 기술 이전)

5. 제안서 평가 기준
   - 기술 평가 항목 및 배점
   - 가격 평가 방식
   - 프레젠테이션 평가

6. 제안 안내
   - 제출 일정 및 방법
   - 제안서 작성 규격
   - 문의처

RFP 분석 체크리스트

RFP를 수령하면 다음 항목을 체계적으로 분석해야 한다.

분석 영역핵심 확인 사항분석 목적
사업 배경발주 동기, 상위 계획과의 연계고객의 진짜 니즈 파악
사업 범위포함/제외 범위의 명확성리스크 및 추가 비용 예측
요구사항기능/비기능 요구의 구체성 수준제안 방향 및 차별화 포인트
평가 기준배점 구조, 가점/감점 항목제안서 역량 집중 영역
일정사업 기간의 현실성투입 인력 및 공수 산정
예산사업비 적정성Go/No-Go 의사결정
기술 환경지정 플랫폼, 기존 시스템 연동기술 아키텍처 설계 방향

Go/No-Go 의사결정 프레임워크

모든 RFP에 제안하는 것은 비효율적이다. 체계적인 Go/No-Go 분석이 필요하다.

Go/No-Go 평가 매트릭스 (100점 만점)

전략적 부합성 (25점)
  - 회사 사업 전략과의 일치도        0-10점
  - 레퍼런스 확보 가치               0-8점
  - 장기 관계 구축 가능성            0-7점

경쟁력 (25점)
  - 유사 사업 수행 경험              0-10점
  - 핵심 기술 보유 여부              0-8점
  - 전문 인력 확보 가능성            0-7점

수익성 (25점)
  - 예산 대비 수익률 전망            0-10점
  - 추가 사업 연계 가능성            0-8점
  - 투입 리소스 대비 효율성          0-7점

리스크 (25점)
  - 기술적 난이도                    0-10점
  - 일정의 현실성                    0-8점
  - 발주처 협력 수준 전망            0-7점

판정 기준:
  80점 이상: Go (적극 참여)
  60-79점: Conditional Go (조건부 참여)
  60점 미만: No-Go (불참)

RFP 질의응답 전략

사전 설명회와 질의응답은 RFP의 모호한 부분을 명확히 하고, 경쟁사 대비 우위를 확보하는 중요한 기회다.

효과적인 질의 전략:

  • 핵심 기술 요건의 해석 범위를 확인하는 질문
  • 발주처가 가장 중요시하는 가치가 무엇인지 간접적으로 파악하는 질문
  • 현행 시스템의 운영 현황과 애로사항을 확인하는 질문
  • 기존 유사 사업과의 차별성을 확인하는 질문

주의할 점:

  • 자사의 제안 방향을 노출하는 질문은 피한다
  • 경쟁사에게도 도움이 되는 범용적 질문은 최소화한다
  • 핵심적이고 구체적인 질문으로 발주처의 신뢰를 확보한다

ISMP와 정보화 전략

ISMP의 개념과 목적

ISMP(정보화전략계획, Information Strategy Master Plan)는 조직의 중장기 정보화 비전과 전략을 수립하고, 이를 실현하기 위한 단계별 실행 로드맵을 도출하는 체계적인 계획 수립 활동이다.

공공 부문에서는 대규모 IT사업(일정 규모 이상)을 추진하기 전에 ISMP 수립이 의무화되어 있으며, 이를 통해 사업의 타당성과 추진 방향을 사전에 검증한다.

ISMP 수립 절차

Phase 1: 환경 분석 (약 전체 기간의 25%)
  ├── 경영 환경 분석
  │   ├── 조직 전략 및 비전 분석
  │   ├── 업무 프로세스 분석 (BPR)
  │   └── 이해관계자 인터뷰
  ├── 정보화 현황 분석
  │   ├── 현행 시스템 아키텍처 분석
  │   ├── 정보자원 현황 분석
  │   └── 정보화 성숙도 평가
  └── 벤치마킹
      ├── 동종 업계 사례 분석
      └── 선진 기술 트렌드 조사

Phase 2: 미래 모델 수립 (약 전체 기간의 35%)
  ├── 목표 아키텍처 설계
  │   ├── 비즈니스 아키텍처 (BA)
  │   ├── 데이터 아키텍처 (DA)
  │   ├── 응용 아키텍처 (AA)
  │   └── 기술 아키텍처 (TA)
  ├── 갭 분석 (As-Is vs To-Be)
  └── 정보화 과제 도출

Phase 3: 실행 계획 수립 (약 전체 기간의 40%)
  ├── 과제 우선순위 평가
  │   ├── 전략적 중요도
  │   ├── 시급성
  │   ├── 기술적 실현 가능성
  │   └── 과제 간 선후행 관계
  ├── 단계별 추진 로드맵
  │   ├── 단기 (1년 이내)
  │   ├── 중기 (1-3년)
  │   └── 장기 (3-5년)
  ├── 투자 소요 예산 산정
  └── 추진 체계 설계

정보화 아키텍처(EA) 프레임워크

ISMP에서 목표 아키텍처를 설계할 때는 EA(Enterprise Architecture) 프레임워크를 활용한다.

아키텍처 영역주요 내용산출물
비즈니스 아키텍처(BA)업무 프로세스, 조직 구조, 기능 분류업무 기능 분해도, 프로세스 맵
데이터 아키텍처(DA)데이터 모델, 데이터 흐름, 데이터 표준개념/논리 데이터 모델, 데이터 흐름도
응용 아키텍처(AA)응용시스템 구성, 시스템 간 연동, 기능 배치응용 구성도, 인터페이스 정의서
기술 아키텍처(TA)인프라, 네트워크, 보안, 플랫폼 기술 스택인프라 구성도, 기술 표준 정의서

ISMP 성공 요인

핵심 성공 요인:

  1. 경영진의 적극적 참여와 지원 (Executive Sponsorship)
  2. 현업 부서와의 긴밀한 협업 및 의견 수렴
  3. 현실적이고 실행 가능한 과제 도출
  4. 기존 정보화 자산의 활용도를 고려한 점진적 전환 전략
  5. 명확한 성과지표(KPI) 설정과 추적 체계

흔한 실패 원인:

  • 경영 전략과 괴리된 기술 중심 계획
  • 현업의 참여 없이 외부 컨설턴트 주도로 수립
  • 과도한 목표 설정 (Big Bang 접근)
  • 예산 확보 없는 로드맵 수립
  • 수립 후 실행 관리 체계의 부재

제안서 작성 핵심 전략

제안서의 구성 체계

제안서는 크게 기술 제안, 관리 제안, 가격 제안의 세 영역으로 구성된다. 각 영역에서 RFP의 평가 기준에 맞춰 전략적으로 내용을 구성해야 한다.

제안서 표준 목차 구조:

제1편 기술 부문
  제1장 사업 이해
    1.1 사업 배경 및 환경 분석
    1.2 현행 시스템 분석
    1.3 핵심 과제 도출
  제2장 제안 시스템
    2.1 시스템 아키텍처
    2.2 기능 설계
    2.3 데이터 설계
    2.4 인터페이스 설계
    2.5 보안 설계
  제3장 개발 방안
    3.1 개발 방법론
    3.2 단계별 수행 방안
    3.3 품질 관리 방안

제2편 관리 부문
  제1장 프로젝트 관리
    1.1 프로젝트 추진 체계
    1.2 프로젝트 관리 방안 (범위, 일정, 품질, 위험)
    1.3 의사소통 관리
    1.4 변경 관리
  제2장 투입 인력
    2.1 투입 조직도
    2.2 핵심 인력 역량
    2.3 인력 투입 계획
  제3장 사업 수행 일정
    3.1 마스터 스케줄
    3.2 단계별 상세 일정

제3편 지원 부문
  제1장 교육 및 기술 이전
  제2장 하자 보수 및 유지보수
  제3장 유사 사업 수행 실적

기술 제안 작성 전략

기술 제안은 제안서의 핵심이며, 발주처의 문제를 어떻게 해결할 것인지를 기술적으로 증명하는 영역이다.

아키텍처 설계 원칙:

원칙설명적용 사례
확장성 (Scalability)사용자/데이터 증가에 유연하게 대응마이크로서비스 아키텍처, 오토스케일링
가용성 (Availability)장애 시에도 서비스 연속성 보장이중화, 페일오버, DR 구성
보안성 (Security)데이터 보호 및 접근 통제암호화, 인증/인가, 네트워크 분리
호환성 (Interoperability)기존 시스템과의 원활한 연동표준 API, ESB, 메시지 큐
유지보수성 (Maintainability)변경과 개선이 용이한 구조모듈화, 클린 아키텍처, CI/CD

차별화 전략:

  • 고객의 숨겨진 니즈(Hidden Needs)를 발굴하여 반영
  • 업계 트렌드와 혁신 기술을 접목한 미래지향적 아키텍처 제시
  • 유사 프로젝트 수행 경험에서 도출한 베스트 프랙티스 제시
  • 구체적인 PoC(Proof of Concept) 결과나 프로토타입 시연

관리 제안 작성 전략

관리 제안은 프로젝트를 성공적으로 수행할 수 있는 관리 역량을 증명하는 영역이다.

# 프로젝트 추진 체계 예시
추진_조직:
  발주처:
    역할: 사업 총괄, 요구사항 확정, 검수
    구성:
      - 사업 책임자 (PO)
      - 현업 담당자
      - 정보화 담당자

  수행사:
    역할: 시스템 분석/설계/개발/테스트
    구성:
      PM:
        역할: 프로젝트 총괄 관리
        자격: PMP 또는 유사 사업 PM 경력 10년 이상
      PL:
        역할: 기술 리더십, 아키텍처 설계
        자격: 해당 기술 분야 전문가
      개발팀:
        역할: 설계/개발/단위테스트
      QA팀:
        역할: 통합테스트, 성능테스트, 품질 관리
      DBA:
        역할: 데이터 모델링, DB 튜닝

  PMO:
    역할: 사업 감리, 품질 감독
    구성:
      - 감리원
      - 품질 관리 전문가

가격 제안 전략

가격 제안은 기술력을 합리적인 비용으로 제공할 수 있음을 증명하는 영역이다. 공공사업에서는 대가산정 기준에 따라 투명하게 산출해야 하며, 민간사업에서는 경쟁력 있는 가격과 가치 제안의 균형이 중요하다.

가격 구성 요소산정 기준비중 (SI 기준)
직접인건비등급별 노임단가 x 투입공수약 60-70%
직접경비장비, 소프트웨어, 출장, 교육약 10-15%
제경비직접인건비의 110-120%포함 계산
기술료(직접인건비+제경비)의 20-40%포함 계산
일반관리비직접인건비의 일정 비율포함 계산
이윤총원가의 일정 비율 이내약 10-15%

프로젝트 계획 수립

WBS(작업분해구조) 작성

WBS는 프로젝트의 전체 범위를 관리 가능한 단위(Work Package)로 계층적으로 분해하는 기본 도구다. 효과적인 WBS 작성이 프로젝트 성공의 기초가 된다.

WBS 구조 예시 (차세대 시스템 구축 사업)

1.0 프로젝트 관리
    1.1 착수 단계
        1.1.1 착수 보고서 작성
        1.1.2 착수 보고회
        1.1.3 프로젝트 계획서 수립
    1.2 실행 관리
        1.2.1 주간 보고
        1.2.2 월간 보고
        1.2.3 이슈/리스크 관리
    1.3 종료 단계
        1.3.1 최종 보고서 작성
        1.3.2 최종 보고회
        1.3.3 산출물 인수인계

2.0 분석
    2.1 현행 시스템 분석
        2.1.1 업무 프로세스 분석
        2.1.2 데이터 현황 분석
        2.1.3 인터페이스 현황 분석
    2.2 요구사항 분석
        2.2.1 요구사항 수집
        2.2.2 요구사항 정의서 작성
        2.2.3 요구사항 검토 및 확정
    2.3 분석 보고
        2.3.1 분석 보고서 작성
        2.3.2 분석 단계 검토회

3.0 설계
    3.1 아키텍처 설계
    3.2 UI/UX 설계
    3.3 데이터베이스 설계
    3.4 인터페이스 설계
    3.5 설계 보고

4.0 구현
    4.1 개발 환경 구축
    4.2 공통 모듈 개발
    4.3 업무별 기능 개발
    4.4 인터페이스 개발
    4.5 데이터 이행 개발

5.0 테스트
    5.1 단위 테스트
    5.2 통합 테스트
    5.3 시스템 테스트
    5.4 성능 테스트
    5.5 사용자 수용 테스트 (UAT)

6.0 이행
    6.1 이행 계획 수립
    6.2 데이터 이행
    6.3 시스템 전환
    6.4 안정화 운영

일정 계획 (스케줄링)

WBS를 기반으로 각 작업의 소요 기간, 선후행 관계, 자원 할당을 고려하여 상세 일정을 수립한다.

기법설명활용 시점
CPM (Critical Path Method)가장 긴 경로를 식별하여 최소 사업 기간 산정전체 일정 최적화
PERT (Program Evaluation and Review Technique)낙관/비관/최빈 3점 추정으로 불확실성 반영불확실성 높은 작업
간트 차트 (Gantt Chart)작업별 시작/종료 일정을 막대 그래프로 시각화일정 현황 보고
마일스톤 (Milestone)주요 체크포인트 정의진척 관리 기준점

자원 할당 계획

# 인력 투입 계획 예시 (12개월 SI 사업)
투입_인력_계획:
  분석_단계: # 1-3개월
    PM: 1명 (100%)
    PL: 1명 (100%)
    분석가: 3명 (100%)
    DBA: 1명 (50%)
    합계: 약 5.5 M/M per month

  설계_단계: # 3-5개월
    PM: 1명 (100%)
    PL: 1명 (100%)
    설계자: 4명 (100%)
    DBA: 1명 (100%)
    UI_설계자: 1명 (100%)
    합계: 약 8 M/M per month

  구현_단계: # 5-10개월
    PM: 1명 (100%)
    PL: 1명 (100%)
    개발자: 8명 (100%)
    DBA: 1명 (100%)
    QA: 2명 (50%)
    합계: 약 12 M/M per month

  테스트_이행: # 10-12개월
    PM: 1명 (100%)
    PL: 1명 (100%)
    개발자: 6명 (80%)
    DBA: 1명 (100%)
    QA: 3명 (100%)
    합계: 약 10.8 M/M per month

리스크 관리

프로젝트 리스크는 사전에 식별하고, 대응 전략을 수립해야 한다.

리스크 유형사례대응 전략
범위 확장 (Scope Creep)고객의 추가 요구사항 빈발변경관리 프로세스 엄격 적용, 요구사항 동결 시점 명확화
인력 이탈핵심 개발자 퇴사지식 공유 체계, 백업 인력 확보, 문서화 강화
기술 리스크신기술 적용 실패PoC 사전 수행, 기술 검증 단계 포함
일정 지연선행 작업 지연 누적크리티컬 패스 집중 관리, 버퍼 확보
품질 리스크테스트 커버리지 부족자동화 테스트 도입, 품질 게이트 설정
외부 의존성외부 시스템 연동 지연인터페이스 사전 협의, Mock 개발

비용 산정과 ROI 분석

기능점수(Function Point) 방식

기능점수 방식은 소프트웨어의 기능적 크기를 측정하여 개발 비용을 산정하는 국제 표준(ISO/IEC 20926) 방법이다. 한국 공공 IT사업에서 가장 널리 사용되는 대가 산정 방식이다.

기능점수 산정 절차:

1. 기능 유형 식별
   - 내부논리파일 (ILF: Internal Logical File)
   - 외부연계파일 (EIF: External Interface File)
   - 외부입력 (EI: External Input)
   - 외부출력 (EO: External Output)
   - 외부조회 (EQ: External Inquiry)

2. 기능 복잡도 평가
   - 단순 (Low), 보통 (Average), 복잡 (High)
   - DET(데이터 요소 유형)과 RET/FTR 기준 적용

3. 미조정 기능점수 계산
   - 각 기능 유형별 복잡도에 따른 가중치 적용

   기능 유형별 가중치:
   ILF: 단순=7, 보통=10, 복잡=15
   EIF: 단순=5, 보통=7, 복잡=10
   EI:  단순=3, 보통=4, 복잡=6
   EO:  단순=4, 보통=5, 복잡=7
   EQ:  단순=3, 보통=4, 복잡=6

4. 보정계수 적용
   - 규모 보정, 애플리케이션 유형 보정, 언어 보정 등

5. 최종 개발비 산정
   기능점수당 단가 x 보정된 기능점수 = 개발원가

투입공수(Man/Month) 방식

# 투입공수 기반 비용 산정 예시
인건비_산정:
  등급별_노임단가: # 2026년 기준 (가상)
    기술사: 월 12,500,000원
    특급기술자: 월 10,800,000원
    고급기술자: 월 9,200,000원
    중급기술자: 월 7,600,000원
    초급기술자: 월 5,800,000원

  투입_계획:
    PM_특급: 12 M/M
    PL_고급: 12 M/M
    분석가_고급: 9 M/M (3명 x 3개월)
    설계자_중급: 12 M/M (4명 x 3개월)
    개발자_중급: 48 M/M (8명 x 6개월)
    QA_중급: 9 M/M (3명 x 3개월)
    DBA_고급: 12 M/M

  직접인건비_합계: 약 900,000,000원

총_사업비_산정:
  직접인건비: 900,000,000원
  제경비: 990,000,000원 # 직접인건비의 110%
  기술료: 378,000,000원 # (직접인건비+제경비)의 20%
  직접경비: 150,000,000원 # 장비, SW 라이선스, 교육 등
  총원가: 2,418,000,000원
  이윤: 241,800,000원 # 총원가의 10%
  총_사업비: 2,659,800,000원 # 약 26.6억원

TCO(총소유비용) 분석

TCO는 시스템 도입부터 폐기까지 전체 생애주기에 걸친 총비용을 분석하는 방법이다.

비용 항목초기 비용연간 운영 비용5년 TCO
하드웨어/인프라5억원5천만원 (유지보수)7억원
소프트웨어 라이선스3억원6천만원 (유지보수)5.4억원
개발비26.6억원-26.6억원
운영 인력-4억원20억원
교육/훈련5천만원1천만원9천만원
데이터 이관1억원-1억원
합계36.1억원5.2억원60.9억원

ROI(투자수익률) 분석

ROI 계산 프레임워크:

1. 정량적 효과 (Tangible Benefits)
   - 업무 처리 시간 단축: 연 2억원 (인건비 절감)
   - 수작업 오류 감소: 연 5천만원 (재작업 비용 절감)
   - 운영 효율화: 연 3억원 (프로세스 자동화)
   - 합계: 연 5.5억원

2. 정성적 효과 (Intangible Benefits)
   - 의사결정 속도 향상
   - 고객 만족도 증대
   - 데이터 기반 경영 역량 강화
   - 규제 준수 리스크 감소

3. ROI 계산
   5년 총 효과: 5.5억원 x 5년 = 27.5억원
   5년 TCO: 60.9억원

   단순 ROI = (총 효과 - 총 비용) / 총 비용
            = (27.5 - 60.9) / 60.9
            = -54.8%

   그러나 정성적 효과와 기회비용을 포함하면:
   보정된 총 효과: 연 15억원 (정성적 효과 포함)
   5년 보정 효과: 75억원

   보정 ROI = (75 - 60.9) / 60.9 = 23.2%
   손익분기점(BEP): 약 4년 1개월

SLA와 서비스 수준 관리

SLA의 구성 요소

SLA(서비스 수준 협약)는 IT서비스의 품질을 정량적으로 정의하고, 이를 모니터링하며, 미달 시 패널티를 적용하는 체계적인 관리 도구다.

# SLA 정의서 예시
서비스_수준_협약:
  서비스_가용성:
    목표: 99.95%
    측정_기간: 월 단위
    제외_시간: 계획된 점검 시간 (매월 둘째 주 일요일 02:00-06:00)
    산정_방식: '(전체 서비스 시간 - 장애 시간) / 전체 서비스 시간 x 100'
    패널티:
      99.90_이상_99.95_미만: 월 유지보수비의 5% 감액
      99.50_이상_99.90_미만: 월 유지보수비의 10% 감액
      99.50_미만: 월 유지보수비의 20% 감액

  응답_시간:
    온라인_거래: 평균 3초 이내 (피크 시간 5초 이내)
    배치_처리: 정해진 시간 내 완료
    보고서_생성: 30초 이내

  장애_대응:
    심각(Critical): 인지 후 30분 내 대응, 4시간 내 복구
    주의(Major): 인지 후 1시간 내 대응, 8시간 내 복구
    경미(Minor): 인지 후 4시간 내 대응, 24시간 내 복구
    정보(Info): 인지 후 8시간 내 대응, 업무일 기준 3일 내 복구

SLA 모니터링 체계

모니터링 항목측정 도구측정 주기보고 대상
시스템 가용성APM(Application Performance Monitoring) 도구실시간월간 보고
응답 시간실사용자 모니터링(RUM)실시간주간 보고
장애 건수/복구 시간ITSM(IT Service Management) 시스템이벤트 기반월간 보고
배치 처리 현황작업 스케줄러일 단위일간 보고
보안 이벤트SIEM(Security Information and Event Management)실시간월간 보고

SLA 개선 사이클

효과적인 SLA 관리는 지속적인 개선 사이클을 통해 이루어진다.

SLA 개선 사이클 (PDCA):

Plan (계획)
  - SLA 지표 정의 및 목표 수준 설정
  - 모니터링 체계 구축
  - 이해관계자 합의

Do (실행)
  - SLA 기반 서비스 운영
  - 실시간 모니터링
  - 장애 대응 프로세스 실행

Check (점검)
  - 월간/분기별 SLA 달성률 분석
  - 미달 항목 원인 분석
  - 트렌드 분석 및 예측

Act (개선)
  - 개선 과제 도출 및 실행
  - SLA 기준 재설정 (필요 시)
  - 운영 프로세스 최적화

성공적인 IT사업 수행 사례

사례 1: 공공기관 차세대 시스템 구축

프로젝트 개요:

  • 대상: 정부 산하 공공기관의 핵심 업무 시스템 차세대 전환
  • 규모: 약 50억원, 18개월
  • 범위: 기존 메인프레임 기반 시스템을 오픈 플랫폼(Java/Spring)으로 전환

핵심 성공 요인:

  1. 철저한 현행 분석: 3개월간의 As-Is 분석을 통해 1,200개 업무 기능과 800개 화면을 정밀하게 매핑
  2. 단계적 전환 전략: Big Bang 방식이 아닌 업무 영역별 순차 전환으로 리스크 최소화
  3. 현업 참여 극대화: 업무 영역별 현업 담당자를 프로젝트 전담으로 배치
  4. 자동화 테스트: 회귀 테스트 자동화로 전환 오류를 사전에 90% 이상 차단
  5. 데이터 이행 리허설: 3회에 걸친 데이터 이행 리허설로 본번 이행 시 무결성 확보

교훈:

  • 차세대 사업에서 가장 중요한 것은 기존 업무 로직의 정확한 이해
  • 데이터 이행은 프로젝트 초기부터 별도 트랙으로 관리해야 한다
  • 사용자 교육 시간을 넉넉히 확보해야 오픈 후 혼란을 최소화할 수 있다

사례 2: 금융권 클라우드 전환 사업

프로젝트 개요:

  • 대상: 중견 금융사의 비핵심 업무 시스템 클라우드 전환
  • 규모: 약 30억원, 12개월
  • 범위: 20개 응용시스템의 클라우드 마이그레이션

마이그레이션 전략 (6R 프레임워크 적용):

전략적용 시스템 수설명
Rehost (리호스트)8개변경 없이 클라우드 인프라로 이동
Replatform (리플랫폼)5개일부 플랫폼 요소만 클라우드 최적화
Refactor (리팩터)4개클라우드 네이티브 아키텍처로 재설계
Retire (폐기)2개사용 중단 시스템 폐기
Retain (유지)1개온프레미스 유지 (규제 요건)

핵심 성공 요인:

  1. 금융 규제 사전 검토: 금융감독원 클라우드 이용 가이드라인 준수 확인
  2. 보안 아키텍처 설계: 네트워크 분리, 데이터 암호화, 접근 통제 체계 수립
  3. 비용 최적화: 리저브드 인스턴스와 오토스케일링 조합으로 연 40% 비용 절감
  4. 점진적 전환: 비핵심 시스템부터 전환하여 운영 경험 축적 후 확대

사례 3: 대기업 ERP 고도화 컨설팅

프로젝트 개요:

  • 대상: 제조 대기업의 ERP 시스템 고도화 전략 컨설팅
  • 규모: 약 8억원, 6개월
  • 범위: ISMP 수립 및 ERP 고도화 로드맵 도출

수행 방법론:

  1. 글로벌 14개 법인의 업무 프로세스 표준화 수준 진단
  2. 산업별 베스트 프랙티스 대비 갭 분석
  3. ERP 확장 모듈(SCM, PLM, MES) 도입 타당성 분석
  4. 3개년 단계별 고도화 로드맵 수립

주요 산출물:

  • 현행 업무/시스템 분석 보고서
  • 목표 아키텍처 설계서
  • 과제 정의서 (32개 실행 과제)
  • 3개년 추진 로드맵
  • 투자 소요 예산서 (총 150억원 규모)

마치며

IT사업의 성공은 기술적 역량만으로 이루어지지 않는다. 사업의 본질을 이해하고, 고객의 니즈를 정확히 파악하며, 이를 체계적인 방법론과 관리 체계로 실현하는 종합적인 역량이 필요하다.

IT사업 기획자와 제안서 작성자가 기억해야 할 핵심 원칙:

  1. 고객 관점에서 생각하라: 기술이 아닌 비즈니스 가치를 먼저 이야기하라
  2. 숫자로 증명하라: 정성적 효과도 가능한 한 정량화하여 설득력을 높여라
  3. 리스크를 숨기지 마라: 리스크를 인지하고 대응 방안을 제시하는 것이 신뢰를 준다
  4. 실행 가능한 계획을 세워라: 과도한 약속은 프로젝트 실패의 시작이다
  5. 소통을 게을리하지 마라: 이해관계자와의 지속적인 커뮤니케이션이 변경 리스크를 줄인다
  6. 교훈을 축적하라: 모든 프로젝트의 경험을 조직 자산으로 관리하라

IT사업 환경은 클라우드, AI, 디지털 전환 등으로 빠르게 변하고 있지만, 체계적인 기획과 탄탄한 제안 역량의 중요성은 변하지 않는다. 이 글에서 다룬 내용이 IT사업을 기획하고 제안서를 작성하는 실무자에게 실질적인 도움이 되기를 바란다.

참고자료

  • 한국정보화진흥원(NIA), 정보화전략계획(ISMP) 수립 가이드
  • 과학기술정보통신부, SW사업 대가산정 가이드 (2025년 개정판)
  • PMI, PMBOK Guide 7th Edition
  • IFPUG, Function Point Counting Practices Manual (CPM) 4.3.1
  • 한국소프트웨어산업협회, 소프트웨어 기술자 평균 임금 공표
  • ITIL 4 Foundation, Service Level Management Practice
  • 조달청, 협상에 의한 계약 제안서 평가 기준 가이드
  • 금융감독원, 금융 부문 클라우드 이용 가이드라인