SI와 솔루션 개발의 차이 - 프로세스편

느리게 따라가기·2022년 12월 13일
0

생각거리

목록 보기
5/6

출처: 소프트웨어 공학센터 웹진자료-2015년 11월)

SI와 솔루션 개발의 차이 중에서 가장 큰 부분은 프로세스다. SI는 요구사항을 중심으로 개발하고 솔루션은 기획을 중심으로 개발한다. 따라서 SI는 요구사항을 어떻게 시스템으로 만드는지에 초점이 맞춰진다. 전통적인 소프트웨어 개발 프로세스, 개발방법론, 툴 등은 요구사항을 분석하고 기술적인 설계를 한 후 코딩 하기 때문에 SI에 잘 맞춰졌다고 볼 수 있다. 하지만 솔루션의 경우, 불특정 사용자를 대상으로 하기 때문에 사용자 분석에 많은 시간을 할애한다. 사용자 분석에 따라 솔루션 개발의 성패가 좌우되는 것이 일반적이다.

좋은 소프트웨어를 만들기 위해서는 개발 프로세스를 잘 지켜야 한다고 알려져 있다. 이러한 이유로, 다양한 형태의 개발방법론과 ISO, SPICE, CMMi 등 프로세스 준수 여부를 인증하는 기관도 나타나기도 했다. 그리고, 최근에는 사용자와 팀원 간의 커뮤니케이션이 원활해야 좋은 소프트웨어를 만들 수 있다고 하여 애자일이 만들어지기도 했다. 애자일에서는 원활한 커뮤니케이션을 위해 다양한 프로세스를 제시하고 있다.

이번 회에서는, SI와 솔루션 개발의 차이, 마지막 시간으로 프로세스의 차이를 살펴본다. 먼저, SI와 솔루션 개발 프로세스의 목적이 무엇인지 알아보고, SI와 솔루션 개발 프로세스를 비교해보면서 차이점을 살펴본다. 마지막으로, SI와 솔루션 개발이 끝난 후 유지보수 프로세스는 어떻게 되는지 알아본다.


1. SI와 솔루션 개발 프로세스의 목적

전통적인 소프트웨어 개발 프로젝트 형태인 SI는 크게 고객과 개발자라는 이해관계자가 존재한다. 고객은 자신들이 원하는 소프트웨어를 발주하고 개발자는 제안서를 제출하여 고객이 만족하는 소프트웨어의 모습을 보여준다. 이 때 나타나는 문서가 RFI(Request for Information), RFP(Request for Proposal)이다. RFI는 고객이 진행하려는 프로젝트에 대한 기본적인 정보를 전달하기 위한 문서다. 일반적으로 사업 개요, 발주업체 정보, 주요 요구사항을 형식에 구애받지 않고 자유롭게 작성된다. RFP는 고객이 프로젝트를 수행하기 위해 필요한 요구사항을 구체적으로 작성하는 문서다. 사업의 범위를 구체적으로 정의하고, 주요 요구사항을 정의한다. 최대한 자세하고 구체적이고 정확하게 작성한다. 소프트웨어 개발자들은 이러한 문서를 바탕으로 제안서를 작성하고 프로젝트를 시작한 후에는 요구사항 정의서를 작성하여 고객의 요구사항을 구체적으로 정의하는 것이 일반적이다. SI는 고객의 요구사항을 명확히 정의하여 소프트웨어에 잘 반영되도록 하는 것이 가장 큰 목적이다. 따라서 SI 프로세스는 RFI, RFP, 제안서부터 요구사항을 정의하고 분석, 설계, 개발에 어떻게 반영되었는지 정의하도록 되어있다. <그림 1>은 SI 프로세스가 고객의 요구사항을 어떻게 반영되고 있는지 나타내고 있다.

<그림 1> SI 프로세스에서 고객의 요구사항이 반영되는 예

<그림 1>을 살펴보면, RFI, RFP에서는 고객의 요구사항이 제시되고, 고객의 요구사항이 반영된 시스템의 모습을 제안서를 통해 제안한다. 프로젝트가 시작되면, 고객의 요구사항은 요구사항정의서를 통해 정의되고, 분석 단계에서는 모델링, 설계 단계에서는 프로그램사양서와 테스트시나리오를 통해 고객의 요구사항이 소프트웨어로 변형된다. 이후, 코딩과 테스트를 통해 고객의 요구사항이 모두 반영된 시스템이 완성된다. <그림 1>에 표시되지 않은 액티비티나 태스크 프로세스는 이러한 프로세스를 보완하는 것으로 이해해도 무방하다. 이처럼, SI 프로세스는 고객의 요구사항이 시스템에 잘 반영하고 확인하는 것이 목적이다. 한마디로 표현하면, 소프트웨어를 고객이 원하는 형태로 만드는 것이다.

솔루션은 가상의 사용자를 정의하여 해당 사용자가 원하는 기능을 개발하는 것을 목적으로 한다. 가상의 사용자가 무엇을 원하는지 사용자 분석을 하는 것에 많은 시간을 할애한다. 또한 사용자 분석을 한 것이 옳은지 수정을 해야 하는지 지속적으로 확인하며 개발한다. 따라서 솔루션 개발 프로세스는 가상의 사용자가 원하는 기능을 작게 분리하여 짧은 기간 단위로 개발 프로세스를 반복 확인하면서 개발한다. 애자일이 솔루션 개발에 적합한 이유가 바로 여기에 있다. 애자일은 짧으면 1주, 길면 2~3주 단위로 짧게 개발 프로세스를 반복하며 사용자의 요구사항을 만족시킨다. <그림 2>는 야후에서 제시하는 애자일을 적용한 솔루션 개발 프로세스를 나타내고 있다.

<그림 2> 야후의 애자일 기반 솔루션 개발 프로세스의 예

<그림 2>를 살펴보면, 앞쪽의 ‘Planning & Ideation’에서 사용자 분석을 하게된다. 공학트렌드에서도 많이 살펴보았던 ‘인셉션(Inception)’, ‘사용자 스토리 워크샵(User Story Workshop)’ 등이 이 프로세스에서 수행된다. 솔루션은 가상의 사용자가 원하는 것을 예측하여 완성품을 만든 후 사용자에게 제공되기 때문에 이 프로세스가 가장 중요한 프로세스라고 할 수 있다. 사용자 분석이 끝나면, UI/UX 디자인을 수행하고 코딩과 빌드, 테스트를 마친 후 적용되도록 되어 있다. 그리고, UI/UX 디자인부터 적용까지, 프로세스는 기능이 추가될 때마다 반복해서 수행한다. 솔루션 프로세스는 가상의 사용자가 원하는 것이 무엇인지 예측하고 조사하여 정의하고 이를 구현하는데 목적이 있으며, 정의된 기능을 짧고 빠르게 구현되도록 하고 있다.

2. SI와 솔루션 개발 프로세스의 비교

SI와 솔루션은 모두 요구사항을 정의하는 것으로 소프트웨어 프로젝트를 시작한다. 다만, SI는 미리 정해진 고객이 명확한 요구사항을 전달하고 솔루션은 가상의 사용자를 대상으로 요구사항을 추정한다. <그림 3>은 SI에서 요구사항을 정의하여 후반부 프로세스와 연계되는 모습을 나타내고 있다.

<그림 3> SI의 요구사항 정의와 활용

<그림 3>을 살펴보면, 요구사항 분석 단계에서 고객의 요구사항을 요구사항정의서에 정의한다. 이 정의에서 소프트웨어 관련 요구사항을 분리하여 기능이나 프로세스를 명세화 한다. 명세화된 요구사항은 고객의 업무 형태인 스토리보드나 유즈케이스 시퀀스명세서로 명세화 하면서 요구사항이 명확히 분석되었는지 확인할 수 있다. 인프라처럼 소프트웨어와 관련이 없는 것들은 별도의 프로세스로 정의된다. 이렇게 정의된 명세서들을 기초로 설계 단계를 수행하도록 되어 있다. SI 프로세스는 요구사항정의서가 가장 기본이 되는 문서다. 고객의 요구사항은 모두 요구사항정의서에 포함해야 하며, 요구사항마다 관리번호를 붙여 분석, 설계, 개발 단계에서 어떻게 반영되었는지 추적을 해야 한다. 이러한 결과를 요구사항추적표라는 문서를 통해 확인한다. 따라서, SI 프로젝트는 이 두가지 문서를 통해 프로세스가 진행되는 모습을 확인할 수 있다.

솔루션의 경우, 가상의 사용자가 원하는 요구사항을 예측하기 위해 애자일 기반의 사용자 스토리 워크샵 또는 인셉션을 진행한다. 애자일 기반이 아니더라도 가상 사용자에 대한 분석 프로세스가 진행된다. <그림 4>는 사용자 스트로 워크샵의 예를 나타내고 있다.

<그림 4> 솔루션의 사용자 스토리 워크샵의 예

<그림 4>를 살펴보면, 가상 사용자의 요구사항을 예측하여 정의하고 우선순위화 한 후, 이를 사용자 스토리로 명세화 한다. 정의된 사용자 스토리는 <그림 4>의 ‘Work items’로 최종 정의된다. ‘Work items’이 SI의 요구사항정의서와 유사한 개념이라고 볼 수 있으나, 항목 형태로 정의되는 요구사항정의서와는 달리 ‘Work items’는 사용자 스토리 형태로 정의된다. 사용자 스토리는 백로그로 저장되어 이후 개발 프로세스는 사용자 스토리 단위로 수행하게 된다. <그림 5>가 사용자 스토리를 중심으로 개발이 진행되는 프로세스를 나타내고 있고, 빨간색으로 표시한 것이 사용자 스토리 워크샵 부분이다.

<그림 5> 사용자 스토리 정의 후 개발 프로세스의 예

자료: http://www.blue-agility.com/scaling-agile-dad-vs-safe/

요구사항이 정의되고 나면, 분석, 설계, 개발 단계를 통해 소프트웨어를 구현하게 된다. 이 부분의 프로세스는 ‘공학트렌드 - SI와 솔루션의 차이’를 참고하면 된다.

3. SI와 솔루션 개발의 유지보수 프로세스

SI의 고객 요구사항은 대부분 고객의 업무를 시스템으로 구현하고자 하는 것이 많기 때문에 SI 시스템은 입력, 수정, 조회, 삭제 등의 단순 기능을 개발하는 경우가 많다. SI를 정보시스템 개발이라고 하는 이유도 고객의 업무에서 다루어지는 데이터를 기반으로 한 기능 개발이 대부분이기 때문이다. SI 유지보수 프로세스는 고객의 요구사항을 모두 구현한 이후이기 때문에 별도의 유지보수 계약을 통해 수행되는 경우가 많다. 전통적인 SI 프로세스나 개발방법론은 매우 많은 문서를 만들고 수정하게 되지만, 유지보수 프로젝트인 경우는 문서 수정없이 소프트웨어만 수정하거나 신규로 만드는 경우가 많다. 이미 운영 중인 시스템이기 때문에 고객은 별도의 문서를 요구하지 않는 경우가 많기 때문이다. <그림 6>은 SI 프로젝트의 프로세스를 나타내고 있다. 그림에서 보는 것처럼 유지보수 프로세스가 매우 단순하게 표시되어 있다. 또한 유지보수 시에도 이전 프로세스에 피드백을 보내도록 되어 있지만 실제는 계약도 따로 되어있고 고객이 관심도 없기 때문에 피드백은 거의 없는 경우가 많다.

<그림 6> SI 프로젝트 프로세스

솔루션인 경우는 유지보수 프로세스가 매우 중요하게 사용된다. 솔루션은 하나의 버전이 완성되어 배포된 후 프로젝트가 종료되는 것이 아니라, 지속적으로 버전 업그레이드나 기능 수정을 해줘야 하기 때문이다. 예를 들어, 최초 버전에 가상의 사용자가 원하는 부분을 잘못 예측하여 중요한 기능을 개발하지 않았다면 기능을 추가하여 버전을 업그레이드 해줘야 하고, 기능 구현이 잘못 되었다면 패치를 배포하여 오류가 발생하지 않도록 해줘야 한다. 따라서 솔루션에서는 배포 후의 프로세스가 매우 중요한 부분이라고 할 수 있다. <그림 7>은 솔루션 개발 프로세스를 나타내고 있다.

<그림 7> 솔루션 개발 프로세스

<그림 7>을 살펴보면, 애자일 기반으로 또는 전통적인 개발방법론으로 사용자 스토리 기반의 기능을 개발하게 된다. 이러한 것들을 통합하여 빌드하고 테스트를 수행하여 사용자에게 배포한다. 배포하는 미리 약속된 사용자들에게만 배포되는 알파 또는 베타 버전과 정식 버전으로 나뉠 수 있다. 이렇게 배포된 버전으로 운영을 하게 되고, 운영을 하면서 필요한 기능 추가나 수정 등을 통해 지속적으로 유지보수를 하게 된다. 최근에는 ‘DevOps’라는 용어로 소프트웨어 개발과 운영을 병행 또는 협업하는 방식이 트렌드로 자리잡고 있다.

정리하자면, SI와 솔루션은 개발 프로세스는 일부 유사하게 진행되는 것이 많다. 하지만, 유지보수는 목적이 매우 다르게 수행된다. SI 유지보수는 운영을 더 원활하게 하기 위함이 강하고, 솔루션의 경우는 새로운 버전을 만들기 위한 목적이 강하다. 소프트웨어 라이프 사이클 관리 관점으로 볼 때, SI는 단발성으로 사이클이 이루어지는 경우가 대부분이지만 솔루션은 지속적인 관리로 인해 소프트웨어의 생명주기가 매우 길다는 것을 예측할 수 있다. 최근에 SI 형태보다 솔루션 형태의 소프트웨어 개발이 주목받는 이유가 솔루션은 장기적인 관점의 소프트웨어 관리가 가능하다는 것도 있다.

이번 회에서는 SI 프로세스와 솔루션 프로세스의 목적에 대해 살펴보았고, 소프트웨어 개발 완료 또는 배포 후 유지보수에 대해서도 알아보았다. 불과 몇 년 전만 해도 소프트웨어는 점점 더 커질 것으로 보여, 당시보다 훨씬 복잡한 기술이 요구될 것이라고 말하는 전문가들이 많았다. 하지만, 다양한 오픈소스, 프레임워크 등이 발달하면서 소프트웨어의 형태가 점점 비슷해지고 있다. 사용자의 빠른 요구사항 변화에 대응하기 위해서는 무조건 처음부터 다시 개발하는 것이 아니라, 미리 만들어진 오픈소스, 프레임워크 등에 기능을 추가하여 새로운 솔루션만드는 형태가 늘어나고 있다.

SI에서 개발되는 소프트웨어도 일종의 솔루션이라고 볼 수 있다. 고객의 업무를 그대로 적용하다보니 입력, 수정, 조회, 삭제와 같은 단순 기능 위주로 구현되지만, 완성된 소프트웨어는 솔루션이라고 할 수 있고, 차기 시스템 개발을 버전 업그레이드 된 버전으로 봐도 무방하다. 소프트웨어를 개발할 때 SI보다는 솔루션 형태로 개발하는 것을 권장하는 이유는, 앞에서 말한 것처럼 소프트웨어의 라이프 사이클을 좀 더 장기적이고 체계적으로 관리할 수 있기 때문이다.SI의 유지보수보다 솔루션의 유지보수가 조금 더 편한 것도 이러한 이유 때문이다.


지금까지 SI와 솔루션의 차이를 아키텍처, UX, 테스트, 개발, 그리고 프로세스 편으로 나누어 살펴보았다. 전통적인 소프트웨어 개발 프로세스는 요구사항 분석, 분석, 설계, 개발, 구현으로 구성되어 SI에서 유용하게 사용되어 왔다. SI는 고객이 스스로 원하는 소프트웨어가 어떻게 만들어져야 한다는 것을 잘 모르기 때문에 제시하는 요구사항이 명확하게 되기까지 많은 수정이 필요했다. 이와 달리, 솔루션은 가상의 사용자 분석을 통해 사용자가 원하는 것이 무엇인지 사용자 관점으로 반복 분석하여 정의함으로써 사용자의 만족도를 높이고 있다. 최근에 SI 프로젝트에서도 솔루션 프로젝트에서 많이 사용되는 애자일 기반의 프로세스를 도입하여 사용하는 경우가 점차 늘어나는 이유도 이 때문이다. SI와 솔루션 개발의 가장 큰 차이는 사용자의 관점을 이해하는 것으로 볼 수 있다. 사용자가 원하는 것이 무엇인지, 원하는 UI/UX가 무엇인지, 이러한 내용이 잘 반영되었는지 확인하고 테스트하는 것을 개발자가 아닌 사용자가 바라보는 시각으로 개발한다면 소프트웨어의 가치는 더 높아질 것이다.

profile
두걸음 뒤에서.. 그래도 끝까지!!

0개의 댓글