IT 시스템 구축 과정(3/3): 시스템 개발 단계

IT System Building Process100명이 함께 만드는 하나의 시스템

시스템 구축은 크게 3단계(의사결정 - 준비 - 시스템 개발)로 이뤄집니다.
드디어 마지막 단계인 시스템 개발 단계입니다.

‘시스템 개발’ 단계 개요

  • 시스템 개발 단계는 발주처가 사업수행기관과 계약을 체결하면서 시작됩니다.
  • 사업수행기관은 발주처와 협의하여 시스템 개발 및 테스트 계획을 수립하고, 일정에 따라 프로젝트를 진행합니다.
    ※ 참고로, 소프트웨어 개발 프로젝트를 관리하는 일은 소프트웨어 엔지니어링(Software Engineering)이라는 전문 분야의 일입니다.
  • 이 단계에서 고용노동부는 사업의 발주처로서 3가지 역할을 수행하게 됩니다.
    • 첫째는, 사업 수행기관에게 어떤 시스템을 만들 것인지 설명하는 것입니다.
    • 둘째는, 시스템이 예정된 일정대로 개발되고 있는지 진행상황을 확인하는 것입니다.
    • 마지막으로, 완성된 시스템이 요구사항을 충족하는지 확인하고 검수하는 것입니다.

소프트웨어 개발 사업의 실패사례가 주는 교훈

  • IT 산업분야 중에서 기업이나 정부기관 등의 요구에 따라 시스템을 개발하는 업체를 SI(System Intergration) 업체라고 부릅니다. 대부분의 사업 수행기관은 SI업체입니다.
  • 시스템 개발에 대한 경험이 쌓이면서 성공한 프로젝트와 실패한 프로젝트의 차이를 연구하는 사람들이 생겨났는데, 이들에 따르면 가장 큰 실패요인은 발주처와 사업 수행기관 사이의 의사소통의 문제였습니다.
  • 의사소통 문제가 일어나는 이유는 IT 역량이 부족한 발주처는 시스템이 만들어지기 전까지는 자신이 원하는 시스템을 명확하게 설명할 능력이 부족하고, 사업 수행기관은 IT 역량은 뛰어나지만 어떤 시스템을 만들어야 할지 정확히 알 수 없기 때문입니다.
  • 그래서, SI 업체의 소프트웨어 엔지니어들은 제대로 작성된다면 발주처가 원하는 바를 알아낼 수 있는 문서 서식(산출물)을 만들었습니다.
  • 주요 산출물은 다음과 같습니다.
    1. 제안요청서 & 사업설명회
    2. 제안서
    3. 계약서(착수계)
    4. 요구사항정의서
    5. 상세설계서(화면 포함)
    6. 파일럿 프로젝트
    7. 검수 기준(지표)
1. 제안요청서 & 사업설명회
  • 제안요청서는 계약이 이루어지기 전에 불특정 다수의 업체를 대상으로 발주처가 원하는 시스템이 무엇인지를 설명하는 문서입니다.
  • 제안요청서의 내용은 시스템 구축 계획(안)을 토대로 작성하되, 입찰대상자들이 발주처의 요구사항을 명확히 이해하여 제안서를 제출할 수 있도록 과업내용, 요구사항, 계약조건, 평가요소와 평가방법, 제안서의 규격 등을 명시해야 합니다.
  • 제안요청서의 내용만으로 SI 업체가 충분한 정보를 알 수 없는 경우가 많기 때문에 입찰을 희망하는 업체들을 대상으로 사업설명회를 개최하는 것이 좋습니다.
  • 사업설명회를 통해 발주처는 원하는 시스템이 무엇인지 설명할 수 있고, SI 업체는 시스템의 목적이나 주요 기능들에 대해 발주처의 생각을 들어볼 수 있습니다.
  • 하지만, 이 단계에서 완전히 세부적인 내용까지 정의하기는 어렵고, 주요한 방향을 확인하는 수준에서 마무리될 가능성이 높습니다.
2. 제안서
  • 제안요청서와 사업설명회를 통해 프로젝트에 대한 정보를 수집한 SI업체들은 제안서를 작성하여 제출하게 됩니다. 제안서는 해당 업체가 프로젝트를 수주할 경우 어떤 방식으로 시스템을 구축할 것인지에 대해 설명한 자료입니다.
    • 참고로 제안서 작성에는 약 1개월 정도가 소요되며 작성비용도 수천만원에 이릅니다.
  • 제안서는 SI 업체에서 작성한 것이기 때문에 제안요청서의 내용을 어떻게 구현할 것인지에 대한 보다 기술적인 내용이 포함되어 있으며, 발주처는 각 업체가 제출한 제안서 내용을 참고하여 계약체결시 반영할 수도 있습니다.
3. 계약서(착수계)
  • 조달청은 각 업체가 제출한 제안서를 평가하여 우선협상대상자를 선정합니다.
  • 발주처는 특별한 사정이 없는한 우선협상대상자로 선정된 SI 업체의 제안서 내용을 기초로 계약을 체결합니다.
  • 사업 수행기관이 된 SI 업체는 계약 체결시 착수계를 제출하는데, 착수계는 사업수행계획서를 의미한다고 보면 됩니다. 즉, 언제 계약을 맺었으니, 그 이후 일정은 이렇게 진행되고, 인력을 어떻게 투입되고, 중간보고는 언제 가능하다 등등의 내용이 계약체결시 제출된다고 보면 됩니다.
  • 발주처는 사업 수행기관의 착수계 내용이 제안요청서의 내용을 충족한다고 판단하면 계약을 체결하고, 그렇지 않으면 재공고를 통해 다른 업체를 선정하게 됩니다.
4. 요구사항정의서
  • 이 단계는 사업 수행기관이 발주처에게 제안요청서의 내용을 다시 확인하는 단계입니다. 다만, 요구사항이 확정되면 그 이후에는 바로 설계 및 구현이 이뤄져야 하기 때문에 정말 세세한 부분까지 서로 확인하게 됩니다.
  • 제안요청서에 해당 내용이 다 있으니, 그것보고 알아서 만들어오라는 발주처가 상당히 많은데, 그렇게 되면 완성된 시스템은 발주처가 생각하는 것과는 상당히 다른 모습이 될 확률이 높습니다. 요구사항 정의 단계에서 자신이 원하는 바를 꼼꼼하게 설명하지 않았다면 시스템이 이상하게 구현되는 것에 대한 책임은 발주처에 있다고 생각합니다.
  • 이 과정에서 어려운 점 중의 하나는 발주처가 세세한 부분까지 다 생각한 것은 아니라는 점입니다. 프로그래머 입장에서는 중요한 결정이지만, 발주처는 아예 생각도 해보지 못한 문제들이 많이 발생하게 되며, 그 부분에 대해 발주처가 명확한 의사표현을 해주지 않으면 개발일정은 하염없이 미뤄집니다.
5. 상세설계서(화면 포함)
  • 발주처와 사업 수행기관 간에 요구사항 정의가 완료되면, 사업 수행기관은 그 요구사항을 기초로 설계서를 작성합니다.
  • 상세설계서는 프로그래머들에게 이러저러한 설계도에 맞는 프로그램을 만들어오라는 일종의 작업지시서입니다.
  • 상세설계서 중에는 당연히 구현되는 화면에 대한 설계도 포함되어 있는데, 발주처가 이 화면설계를 확인하면 실제로 시스템이 어떻게 구현되는지 미리 알 수 있는 효과가 있습니다.
  • 즉, 요구사항 정의가 제대로 되었는지 확인하는 방법 중의 하나는 화면설계서를 보는 것입니다.
6. 파일럿 프로젝트
  • 규모가 큰 사업의 경우 최종결과물을 바로 만들지 않고, 파일럿 프로젝트라고 부르는 시범사업을 하는 경우가 많습니다. 시스템은 매우 복잡한 것이기 때문에 위의 절차를 모두 거친다고 하더라도 의사소통이 제대로 되었다는 보장이 없으므로 시스템으로 만들어서 보여주고 다시 의견을 들어서 최종버전을 만드는 방식입니다.
  • 파일럿 프로젝트를 진행하는 경우 사업예산이 크게 증가하기 때문에 시스템 규모나 예산 상황에 맞춰 진행하는 것이 바람직합니다.
7. 검수 기준(지표)
  • 사업 수행기관이 시스템을 다 만들면 검수 기준에 따라 검수를 진행합니다. 검수를 통과해야만 납품을 하고 잔금을 받을 수 있기 때문에 검수는 굉장히 중요합니다.
  • 그리고, 발주처와 사업 수행기관이 검수 기준을 사전에 정해둔다면 발주처가 무엇을 중요하게 생각하는지 사업 수행기관이 알 수 있습니다. 예를 들어 빠른 처리가 중요한지, 아니면 안정적인 처리가 중요한지를 물어보면 발주처는 당연히 둘 다 중요하다고 대답하는데, 그런 경우 어떤 지표를 기준으로 검수하는지 보면 좀 더 명확한 방향을 정할 수 있습니다.

가상의 사례로 알아보는 단계별 의사소통

  • 위에서 설명한 내용만으로는 이해가 어려울 수 있어 가상의 프로젝트인 전국민 고용보험 시스템 구축으로 각 단계별 의사소통 내용을 비유해보겠습니다.
    • 제안서: (고용부) 전국민 고용보험 시스템을 만들고 싶습니다. 전국민의 고용보험 취득, 상실, 지원금 지급 등 50여가지 업무를 전산으로 처리할 수 있어야 합니다. 예산은 300억원 개발기간은 2년입니다.
    • 제안요청서
      • (SI업체1) 국민연금 시스템을 만들어 본 경험이 있습니다. PC를 활용해 국민 누구나 고용보험을 쉽게 가입하고, 실직할 경우 지원금을 받을 수 있도록 하겠습니다.
      • (SI업체2) 건강보험 시스템을 만들어 보았고, 현재도 운영을 맡고 있습니다. PC보다는 휴대폰 중심으로 고용보험 업무를 처리할 수 있도록 하겠습니다.
      • (SI업체3) 카카오톡과 연계하여 본인인증을 간단히 할 수 있는 솔루션이 있습니다. 완전히 혁신적인 고용보험 시스템을 만들어 보겠습니다.
    • 계약서(착수계): (사업 수행기관) 우리 업체는 ‘20.10월부터 작업을 시작하여 ‘21.2월까지 현황 분석 및 요구사항 정의를 마무리하고, ‘21.6월까지 상세설계를 마무리하고, ‘22.2월까지 시스템 개발을 마치고, ‘22.3~4월 기간에 테스트를 진행하겠습니다.
    • 요구사항정의서
      • 요구사항 OOO: 고용보험에 가입하려는 사람은 휴대폰 본인인증이나 공인인증서 제출이 가능해야 하고, 그렇지 못한 사람은 고용센터를 직접 방문해야만 가입신고가 가능하게 함
      • 요구사항 OOO: 고용보험 가입 신고는 최대 1000명의 신고를 한꺼번에 처리해도 시스템 운영에 문제가 없어야 함
      • 요구사항 OOO: 지원금 신청이 접수되면 신청자의 휴대폰으로 문자메시지가 자동으로 발송되어야 하며, 발송 문구는 유형별로 편집할 수 있어야 함
    • 상세설계서(화면 포함)
      • 설계서 OO-OOO: 가입신청 화면에는 이름, 주민등록번호, 주소, 핸드폰, 이메일 주소를 입력할 수 있는 텍스트 창이 제공되어야 하며, 주소 입력칸에는 주소 검색기능이 포함되어햐 하며, 핸드폰 번호 입력시 전화번호가 아닌 문자열은 입력이 불가능해야 함
      • 설계서 OO-OOO: 사업주가 OO지원금을 신청할 때, 상시 근로자수는 전년도 말 기준으로 자동으로 입력되어야 하며, 수정이 불가능하게 구현되어야 함
      • 설계서 OO-OOO: 실직자가 ‘내 정보’ 메뉴를 선택했을 때, 이름, 전화번호, 비밀번호, 주소, 고용보험 취득·상실 내역, 지원금 수령 내역이 차례로 보여야 하며, 비밀번호는 ** 형태로 표시되어야 함
    • 검수 기준
      • 검수 지표 OO-OOO: 이름 칸에 이름 대신 12345를 입력한 경우 다시 입력하도록 안내메시지가 표출되는지 확인
      • 검수 지표 OO-OOO: 2군데 이상 사업장에서 고용보험을 취득하기 위해 취득신고를 한 경우 다시 신고할 것을 안내하는지 확인
      • 검수 지표 OO-OOO: 지원금을 입력하다가 뒤로 가기 버튼을 눌렀을 때 현재까지 입력된 내용을 임시저장하는 기능이 제대로 동작하는지 확인
  • 발주처와 사업 수행기관 사이의 의사소통은 쉽지 않습니다. 그렇지만 누구나 열의를 가지고 대화를 한다면 시스템 개발 과정이 실패로 끝나는 사례를 막을 수 있다고 생각합니다.

참고자료

소프트웨어 단계별 발주 가이드(정보통신산업진흥원)