[스크랩/SW] SI와 솔루션 개발의 차이 - 개발 편

이번 달은 SI와 솔루션 개발의 차이에 대해 다섯 가지 분야로 살펴보고 있다. 이번 회는 네 번째 시간으로 개발에 대해 살펴본다. SI도 완성하고 나면 패키지 형태의 소프트웨어로 볼 수 있기 때문에 일부 개발자들은 SI에서 개발하는 소프트웨어도 솔루션이라고 말하기도 한다. 하지만 이전 회에서도 가조했지만, SI와 솔루션 개발은 요구사항을 고객이 주는가 아니면 개발 프로젝트에서 자체적으로 정리하는가 하는 것으로 구분하는 것이 좋다. 솔루션 개발은 개발자에게 솔루션의 기획 단계에 반드시 참여할 것을 요구한다.

개발자가 기획 단계에 참여한다는 것은 많은 의미를 가지고 있다. SI에서 개발자는 거의 모든 것을 고객의 요구사항에 맞추어야 한다. 심지어는 화면 디자인까지 고객에게 확인을 받아야 하기 때문에 개발자는 '요구사항 정의서'에 맞추어 개발만 하면 됐다. 하지만 솔루션 기획에 참여하게 되면 개발자는 이전의 개발 경험과 의견을 충분히 전달 할 수 있고, 솔루션에 대한 많은 공감을 가지고 개발을 시작한다. 따라서 개발자는 코딩만 잘하는 것이 아니라 솔루션을 기획, 평가하는 역할까지 해야 한다. 이처럼 개발자가 직접 기획, 계획, 개발하는 솔루션은 일반적으로 완성도나 만족도가 높게 나타난다.

이번 회에서는 SI와 솔루션의 개발 방향을 살펴보면서 어떻게 다른지 확인하고, SI와 솔루션 개발자의 역할에 대해 살펴본다. 그리고 솔루션 개발에 필요한 자동화 도구에 대해서도 살펴본다.

SI와 솔루션의 개발 방향

SI는 고객의 요구사항을 분석하여 아키텍처로 나타낸다. 아키텍처는 소프트웨어를 구성하는 소프트웨어 아키텍처, 시스템을 구성하는 인프라 아키텍처, 그리고 데이터를 구성하는 소프트웨어 아키텍처, 시스템을 구성하는 인프라 아키텍처, 그리고 데이터를 구성하는 데이터 아키텍처를 포함한다. 이 밖에 애플리케이션 아키텍처 등과 같은 다양한 아키텍처들이 더 존재 할 수 있다. 여기서 중요한 포인트는 고객의 요구사항을 아키텍처로 정의한다는 것이다. 고객은 자신이 만들고자 하는 시스템이나 소프트웨어가 어떤 모습인지 대부분 알지 못한다. 따라서 고객이 원하는 모습을 미리 보여줄 필요가 있으며, 이러한 모습을 기준으로 개발을 진행한다. SI 프로젝트에서 가장 중요한 역할은 아키텍처라고 말하는 이유가 바로 여기에 있다.

아키텍처를 크게 고민하지 않던 초기 SI에서는 프로세스, 이벤트, 데이터 모델을 만들어 내고, 이 모델을 기준으로 개발이 진행되었지만 고객이나 개발자도 이해하기 어려웠기 때문에 개발에 적극 활용되지는 못했다. 아키텍처는 고객이나 개발자가 한눈에 보기에 매우 용이했기 때문에 커뮤니케이션이나 개발에 중요한 자료로 활용되었다. <그림 1>은 SI 프로젝트의 개발 방향을 나타낸다. 요구사항을 분석한 후, 해당 내용을 아키텍처를 정의하고 점진적인 개발을 하게 된다.

<그림 1> SI 프로젝트의 개발 방향

<그림 2>는 반복, 점진적인 방법으로 아키텍처를 정의하는 것을 나타내고 있다. 사용자 요구사항을 파악하여 아키텍처 초안을 작성하고, 이를 정리하여 아키텍처를 설계한 후 개발을 하게 된다. 추가 요구사항이 있을 경우 아키텍처를 보완하여 개발한다. 이처럼 SI에서 아키텍처는 개발에 매우 중요한 요소이며, 아키텍처 없이는 개발이 어렵다고 해도 과언이 아니다. 왜냐하면, SI는 요구사항이 처음부터 정해져 있어 요구사항을 모두 반영한 아키텍처를 먼저 정의해 놓아야 고객과 커뮤니케이션도 쉽고 개발 방향도 명확해지기 때문이다.

<그림 2> 반복, 점진적 아키텍처 정의

그리고, SI 개발의 또 다른 특징은 기능의 대부분이 입력, 수정, 조회, 삭제이라는 것이다. SI개발이 3D 업종이라고 얘기하는 이유가 단순 기능의 반복적인 개발이 많기 때문이다. 하지만, 이러한 것은 처음부터 필요에 의해서 시스템이나 소프트웨어를 만드는 SI에서는 어쩔 수 없이 나타나는 현상이다. 솔루션 개발은 이처럼 단순 기능 개발에서 탈피하고자 하는 소프트웨어 개발 회사를 중심으로 발전 되었다.

솔루션은요구사항이 미리 정해진 SI와는 다르게 소프트웨어를 사용하는 사람의 입장을 조사하여 소프트웨어를 정의해 나간다. 솔루션이 '고객'이라고 하지 않고, '사용자'라고 하는 이유도 여기에 있다. 사용자가 직접 요구사항을 전달하는 것이 아니라, 사용자가 무엇이 필요할지 조사하고 고민해서 명확히 정리하는 것이 솔루션의 성공 요인이다. 따라서 솔루션은 사용자 중심으로 개발 방향을 맞춰야 한다. <그림 3>은 솔루션의 사용자 중심 개발 단계를 나타내고 있다.

<그림 3> 솔루션의 사용자 중심 개발 단계

자료: 반준철의 오래가는 UX디자인

솔루션 개발 초기에는 요구사항이 없기 때문에 솔루션은 사용자가 필요한 것이 무엇인지 조사하는 것이 매우 중요하다. <그림 3>을 살펴보면, 사용자 조사 후 인터랙션을 정의하고 프로토타입을 기준으로 개발을 하게 되고, 이를 반복하여 최종 솔루션을 완성하게 된다. 이 때, 사용자 조사에서 나온 결과는 스토리 형태로 정리를 하게 되는데 이 것을 '사용자 스토리'라고 한다. <그림 4>는 XP 프로젝트에서 사용자 스토리 중심으로 개발하는 예를 나타낸 것이다. 사용자 스토리가 요구사항이 되고, 요구사항에 따라 개발 계획을 세운 후 개발을 하게 된다.

<그림 4> 사용자 스토리 중심의 개발(예)

물론, 최근에는 SI 프로젝트에 솔루션을 적용하여 개발하는 경우도 있다. 매번 아무것도 없는 상태에서 개발을 하게 되면 비용과 시간이 너무 많이 소비되기 때문에 필요한 솔루션들을 미리 선정하여 적용한다. 이 때, 적용되는 솔루션은 아키텍처에서 확인 할 수 있도록 아키텍처를 정의한다.

SI와 솔루션 개발 방향의 차이를 정리하면 <표 1>과 같다.

<표 1> SI와 솔루션 개발 방향 비교

구분	SI	솔루션
요구사항 수집 및 정의 방법	프로젝트 발주 고객과 인터뷰	사용자 이해 및 조사
개발 중심 요소	아키텍처 중심	사용자 스토리 중심
주요 개발 조직	업무를 위한 기업	연구 개발 조직

SI와 솔루션 개발자의 역할

SI와 솔루션 개발자의 역할은 매우 다르다. 그 중에서도 가장 크게 다른 점은, SI는 5년차 이하의 경력을 가진 팀원이 개발자로 활동하고, 솔루션은 경력과 상관없이 개발자로 활동하는 경우가 많다. 그 이유는, SI는 입력, 수정, 조회, 삭제와 같은 단순 기능 개발이 많기 때문에 경력이 크게 필요하지 않다. 이와 달리, 솔루션은 새로운 기능을 개발하는 경우가 많아 다양한 경력을 요구하는 경우가 많다.

<그림 5>는 SI 프로젝트의 역할자와 역할을 나타낸 것이다. 고객 중심으로 요구사항을 명세화 하고, 이를 바탕으로 분석, 설계자 중심으로 설계를 한다. 그리고 개발자가 개발을 한 후 테스트를 하게 된다.

<그림 5> SI프로젝트의 역할자와 역할

<그림 5>를 자세히 살펴보면, 요구사항은 SI프로젝트 시작 전에 이미 정해져 있고, 설계된 내용은 바꿀 수 없이 개발자에게 전달된다. 또한 개발자는 정해진 개발 툴과 가이드에 따라 개발을 하기 때문에 SI 개바라는 정해진 틀에서 벗어나지 못하는 구조를 가지고 있다. 하지만, SI개발자는 프로젝트를 수행할 때마다 새로운 비즈니스를 접할 수 있기 때문에 다양한 경험을 할 수 있다는 점도 있다.

솔루션 개발자는 모든 솔루션 개발 프로세스에 참여 한다. 사용자 스토리 중심으로 개발을 하기 때문에 사용자 스토리를 파악하는 사용자 조사부터 개발 계획 수립, UX 개발, 소프트웨어 개발, 내부 테스팅, 릴리즈, 사용자 지원 및 피드백 등 모든 프로세스에 참여하고, 경우에 따라 필요한 역할자를 변경해가며 수행한다. 예를 들면, 사용자 조사에서는 마케터, UX 개발에는 UX 개발자, 테그팅에는 테스터 역할을 수행 할 수 있다. 이러한 내용이 <그림 6>에 나타나 있다.

<그림 6> 솔루션 프로젝트의 역할자와 역할

솔루션 개발자는 SI 개발자와는 다르게 다양한 역할과 경험을 할 수 있다는 좋은 점이 있지만, 이러한 역할을 수행하기 위해 다양한 역량을 쌓아야 한다는 부담도 있다. <표 2>는 SI와 솔루션 개발자의 역할을 비교하였다.

<표 2> SI와 솔루션 개발자 역할 비교

구분	SI	솔루션
소프트웨어 개발 경험	5년차 이하	3년차 이상
경험 범위	다양한 개발, 비즈니스 경험	특정 개발, 비즈니스 경험
주요 역할	소프트웨어 개발	거의 모두

솔루션 개발 자동화

S는 소프트웨어의 개발을 수월하게 하기 위해 필요한 기능의 일부 또는 전체를 미리 구현하여 재사용 하도록 프레임워크를 활용하는데, 완성된 후에는 유지보수 외에 개발을 하는 경우는 많지 않기 때문에 프레임워크 활용도가 떨어지는 편이다. 하지만 솔루션의 경우, 완성 후에도 버전 업그레이드를 위해 지속적인 개발이 진행된다. 따라서 한 개의 버전에서 진행되었던 개발, 테스트 등을 다음 버전에서 재사용할 수 있는 것들이 많다. 특히 이러한 재사용을 자동화 한다면 많은 비용과 시간을 절약 할 수 있다. SI보다 솔루션에서 자동화 도구가 많이 사용되는 것이 이러한 이유 때문이다. 이러한 자동화 도구는 솔루션의 최초 버전부터 버전까지 테스트, 빌드, 배포를 동일한 환경에서 제공할 수 있어 높은 완성도와 신뢰도를 얻을 수 있다. 테스트 자동화에 대해서는 공학트렌드 이전 회에서 다룬 바 있어 제외하고, 빌드와 배포 자동화에 대해 알아본다.

빌드 자동화

CI(Continuous Integration)도구는 개발자가 개발한 소스 코드를 모아서 한꺼번에 빌드하는 과정을 특정 시점이 아니라 매일, 매주와 같이 주기적으로 수행함으로써 통합에서 발생하는 오류와 시간을 줄여준다. 애자일의 일종인 XP(Extreme Programming Community)에서 Kent Beack에 의해서 고안된 방법이다. CI 도구는 소스 코드를 관리하면서 소스 코드가 수정될 경우 자동으로 빌드를 수행한다. 이때, 빌드가 이루어지는 시점은 <표 3>과 같이 두 가지로 정리 할 수 있다.

<표 3> CI 도구의 자동 빌드 시점

구분	설명
커밋에 따른 빌드	- 소스 코드 수정 후 커밋 되었을 때 자동으로 빌드 - 소스 코드에 대한 무결성을 보장하기는 좋지만, 빌드 시간이 길 경우 빌드가 정체되는 현상이 발생할 수 있음
시간에 따른 빌드	- 일정 주기를 정해서 자동으로 빌드(매주, 매일 등) - 빌드 스케줄이 정해져 있어 개발자가 커밋에 대한 스케쥴을 관리할 수 있고, 빌드 시간이 긴 경우에도 적정하다.

CI 도구에 대한 프로세스는 <그림 7>과 같다. <그림 7>을 살펴 보면, 개발자는 출근해서 최신 소스 코드를 받아 개발을 수행하고 테스트를 작성한 후, 로컬에서 빌드 및 테스트를 진행한다. 그리고, 필요하다면 테스트 코드의 커버리지 분석과 코드 인스펙션도 추가로 진행한다. 마지막으로 완료된 소스 코드를 소스 관리 시스템에 저장하고 커밋한다. CI도구는 이렇게 작성된 소스 코드를 받아 소스 코드에 내장되어 있는 빌드 스크립트를 실행하여 컴파일 하고, 테스트 서버에 배포한 후 테스트를 수행한다. 필요하다면, 커버리지 분석과 코드 인스펙션을 수행하고 리포트를 생성한다. 모든 과정이 정상적으로 수행되었다면 현재 버전을 저장(소스 태깅)한다.

<그림 7> CI도구 프로세스

자료: BEA Systems Korea의 Hudson을 이용한 빌드와 테스트의 자동화

이렇게 빌드 자동화가 종료될 때, 만약 실패인 경우에는 이전 버전으로 롤백하고, 성공한 경우에는 커버리지 분석 결과나 테스트 결과를 분석해서 테스트를 수정하거나 보강하도록 한다.

배포 자동화

이번에는 배포 자동화에 대해 알아본다. 몇 개 안되는 서버에 배포한다면 수동이라도 가능하겠지만, 여러 환경의 수십 대 이상의 서버에 배포해야 한다면 수동으로는 어렵다. 그래서 CI도구로 빌드를 완료한 후, CD(Continuous Deployment)도구를 이용해 <그림 8>과 같이 배포를 자동화 한다. 그리고, CD도구는 <표 4>와 같이 세 가지 형태로 나눌 수 있다.

<그림 8> CD도구를 활용한 배포 자동화

자료: BEA Systems Korea의 Hudson을 이용한 빌드와 테스트의 자동화

<표 4> CI 도구의 자동 빌드 시점

구분	설명
특정 솔루션에 종속적인 도구	- Tomcat이나 WebLogic 같은 WAS의 경우 각 제품에 특화된 배포 도구를 가지고 있음 - 이러한 도구는 해당 솔루션에 최적화가 되어 있어 RunTime Deploy나 특화된 기능을 활용할 수음
환경 설정 관리 도구	- Deployment보다는 초기 솔루션을 설치하거나 솔루션에 대한 환경 설정 정보를 중앙 관리하기 위함 - Deploy는 대부분 파일을 복사하고 서버를 restart 시키는 정도의 단순 작업
Remote Shell 기반의 도구	- SSH나 RSH과 같은 명령을 툴로 실행시켜 주는 도구로, 파일 복사부터 입력된 명령을 원격으로 실행 - 솔루션에 종속적이지 않으며 자유도가 높아 사용이 편리

배포 자동화 도구인 Capistrano에서는 배포 시 고민해야 할 사항으로 <표 5>와 같이 네 가지를 가이드 하고 있다. 최근의 솔루션 트렌드는 신속하고 적기에 서비스를 오픈해야 살아남을 정도로 너무나 많으 제품이 쏟아지고 있다. 소프트웨어 개발도 사람이 하는 것이기 때문에 언제나 오류가 나타날 수 있다. 따라서 검증된 자동화 도구를 사용하여 빠른 배포 주기를 유지하고 오류가 발생했을 때 자동으로 대처할 수 있도록 해야 한다.

<표 5> 자동화 배포 시 고민해야 할 사항

구분	설명
배포 주기	- 과거에는 특정한 날짜에 대규모 배포가 일반적이었지만 최근에는 배포 주기가 점차 짧아지는 추세 - 배포 자동화가 구축되었다면, 필요에 따라 하루 단위로 배포하는 것도 고려할 수 있음
수동 배포	- 운영 환경 배포는 반드시 수동으로 하는 것을 권고 - 여러가지 명령을 수행하기 때문에 오류 발생률이 높음. 반드시 사람이 지켜보면서 배포해야 함
배포 롤백	- 배포 시 오류가 발생했을 경우 이전 버전으로 신속하게 롤백해야 함 - 이전 버전을 반드시 저장해야 하고, 배포 스크립트에도 이전 버전이 다시 배포될 수 있도록 포함해야 함
릴리즈 노트	- 릴리즈 노트를 작성하여 함께 배포하는 것이 좋음 - 서비스가 변경 되었을 때 추가된 기능과 변경된 사항을 알려줄 필요가 있음

소프트웨어를 만드는데 가장 중요한 것은 최초에 의도한 형태로 만드는 것이다. SI프로젝트에서는 고객의 변심이나 개발자들의 소프트웨어에 대한 공감 부족으로 프로젝트가 진행되면서 많이 변해 가는 것이 사실이다. 하지만 솔루션의 경우 최초에 의도한 바가 개발이 완료될 때까지 유지되는 경우가 많다. 개발 초기에 솔루션에 대한 공감대를 형성하였고 폭포수 모델을 기초로 한 기존의 개발 프로세스보다는 커뮤니케이션 위주의 프로세스가 많이 강조되고 있기 때문이다.

이번 회에서는 SI와 솔루션 개발에 대한 차이에 대해 살펴보았고, 이를 기준으로 개발자의 역할을 알아보았다. 그리고 솔루션을 효율적으로 유지 관리 할 수 있는 자동화 도구에 대해서도 알아보았다.

SI개발이 줄어들고 솔루션 개발이 증가하는 것은 최근 변화하는 소프트웨어 사용자 환경의 변화로 볼 수 있다. 또한 앞으로 이러한 현상이 더 심화될 것으로 보인다. 소프트웨어 개발자가 지금 시점에 준비해야 할 것은 새로운 개발 환경의 코딩 기술이 아니라 사용자가 원하는 것을 솔루션에 잘 반영하는 트레이닝을 해야 할 것이다. 솔루션이 SI 와 가장 다른 점은 개발자가 소프트웨어의 기획에 참여하고, 이를 소프트웨어에 잘 반영해야 하는 역할과 책임이 있다는 것이다.

출처: http://www.sw-eng.kr/member/customer/Webzine/BoardView.do?boardId=00000000000000033093&currPage=&searchPrefaceId=&titOrder=&writeOrder=&regDtOrder=&searchCondition=TOT&searchKeyword=