[스크랩/SW] 웹진 150호: 공학 트렌드> SI와 솔루션 개발의 차이 - 아키텍처 편

불과 얼마 전까지만 해도 소프트웨어는 기관이나 기업에서 필요에 의해 만들어지는 경우가 대부분이었다. 컨설팅이 고객에게 시스템의 필요성을 전달하고 고객은 필요한 예산을 확보한 후 SI(System Integration) 프로젝트로 이어지는 흐름이었다. 하지만 최근에는 어느 정도 구축이 완료된 상태인 ICT의 투자 필요성이 많이 줄어들었고 오픈 플랫폼, 클라우드와 같은 다양한 ICT 기술이 나타나면서 SI 사업은 예전보다는 많이 줄어들고 있는 추세다.

이와는 반대로, 모바일 디바이스와 같은 개인용 기기가 늘어나면서 불특정 다수가 사용하는 솔루션 소프트웨어가 증가 추세에 있다. 솔루션 소프트웨어는 고객이 미리 정해져 있지 않기 때문에 소프트웨어를 개발하는 프로세스나 방법이 SI와는 다소 상이한 편이다. SI는 고객의 요구사항을 파악하고 분석하는데 많은 시간을 할애하지만 솔루션은 개발과 딜리버리, 그리고 업그레이드 등에 많은 시간을 할애한다. 다수의 사용자가 원하는 소프트웨어를 개발하고 오랫동안 사용될 수 있도록 서비스하고 업그레이드를 해야 하기 때문이다.

SI와 솔루션 소프트웨어의 차이를 좀 더 체계적으로 확인하여 소프트웨어 개발에 도움을 주고자 이번 달에는 SI와 솔루션 개발의 차이를 아키텍처, UX, 테스트, 그리고 개발 관점으로 알아보고자 하며, 이번 회에서는 아키텍처 관점으로 차이점을 살펴보기로 한다. 먼저, SI의 아키텍처와 솔루션 아키텍처의 구성과 역할에 어떤 차이가 있는지 알아보고, 두 아키텍처의 설계 프로세스를 비교하여 차이점을 살펴보기로 한다.

아키텍처 구성과 역할의 차이

아키텍처 구성의 차이

사전에서 정의하는 아키텍처란 컴퓨터 시스템의 컴포넌트를 배치하고 통합하는 방식으로 나타나 있고, IEEE에서는 시스템을 구성하는 요소를 식별, 정의하고 그들 간의 관계를 설정해 놓은 기본적인 구조체, 그리고 설계와 전개에 대한 가이드 원칙으로 나타나 있다. 아키텍처는 다양한 의미로 해석되고 활용되지만 한마디로 요약하면 “시스템의 구조체”라는 것이다. 시스템을 만들기 위한 기본적인 요소를 비즈니스, 애플리케이션, 데이터, 기술로 나누어 구성한다. 이러한 4개의 구성을 계획자, 분석자, 설계자, 개발자의 관점으로 살펴본다면 <그림 1>과 같이 나타낼 수 있다.

SI는 고객의 요구사항에 맞춰 시스템을 구성하기 때문에 시스템 개발 초기에 기술적으로 시스템의 큰 그림을 그리는 성향이 강하다. SI는 시스템의 뼈대를 만들고 그에 맞춰 살을 붙여가는 것을 고객에게 보여주면서 완성해야 하기 때문이다. 솔루션은 고객의 요구사항을 전달받기보다 프로젝트 팀에서 사용자가 원하는 것을 자체적으로 파악하는 경우가 많기 때문에 소프트웨어를 개발하는 자체에 더 초점이 맞춰져 있다.

이러한 이유로, <그림 1>을 살펴보면 SI는 세부 기술과 관련된 데이터, 기술 아키텍처에 집중하는 성향이 강하고, 솔루션은 비즈니스, 애플리케이션에 집중하는 성향이 강하다. 이해관계자 관점에서 본다면, 전사적인 모델을 구축하는 계획자, 분석자는 SI 개발에서 더 많은 역할을 하고, 직접적으로 소프트웨어 개발을 하는 설계자, 개발자는 솔루션 개발에서 더 많은 역할을 한다.

아키텍처 역할의 차이

앞에서 살펴본 것처럼 아키텍처의 가장 큰 역할은 고객, 프로젝트 팀원과 같은 이해관계자들 간의 의사소통 수단이다. 특히 SI 프로젝트 초기에는 시스템의 실체가 없기 때문에 시스템의 뼈대를 보여주는 아키텍처의 중요성은 매우 높다. 또한 SI에서 아키텍처는 프로젝트를 성공시키기 위해 필요한 기술적인 접근방법, 프로젝트 위험을 최소화하기 위한 기준과 가이드 등을 제시하여 이해관계자의 의사결정과 프로젝트 관리계획을 수립하는데 가장 중요한 역할을 한다. 아래는 SI에서 아키텍처의 역할을 정리한 내용이다.

• 이해관계자 간의 의사소통 수단

• 기술적으로 집중해야 할 사항을 결정

• 시스템의 초기 설계 결정의 기준과 가이드 제공

• 프로젝트에서 일어나는 기술적인 문제점을 최소화

• 재사용 가능한 추상화 모델 수립

SI에서 아키텍처는 위에서 보는 것처럼 만들고자 하는 시스템에 대한 의사소통과 의사결정을 위한 추상화 모델의 역할이라고 할 수 있지만, 솔루션에서 아키텍처는 불특정 다수가 사용하는 소프트웨어를 설계하고 개발하는 원칙과 개발 후 배포, 기능 추가, 업그레이드에 유연하게 대처하는 모델을 수립하는 역할이라고 볼 수 있다. 아키텍처의 구성 별 역할을 <표 1>과 같이 정리하였다.

<표 1> 솔루션 아키텍처의 역할

구성	역할
비즈니스 아키텍처	- 불특정 다수 사용자에 대한 솔루션의 프로세스, UX 수립
애플리케이션 아키텍처	- 불특정 다수 사용자가 원하는 기능/비기능 요건을 분석 - 소프트웨어의 배포, 기능 추가, 업그레이드에 유연하게 대처하는 모델 수립
데이터 아키텍처	- 소프트웨어에 필요한 데이터 모델 수립 - 소프트웨어의 기능 추가, 업그레이드에 유연하게 대처하는 데이터 모델 수립
기술 아키텍처	- 다수의 운영 환경(플랫폼, 클라우드 등)에 유연하게 대처하는 인프라 모델 수립 - 원활한 운영을 위한 성능, 가용성에 대한 대응 전략 수립

위와 같이 솔루션에서 아키텍처는 누가, 언제, 어떻게 사용하더라도 유연하게 대처하는 모델을 수립하는 것이 가장 중요하다. 또한 대개 완성 후 개발이 종료되는 SI와는 다르게 솔루션은 배포, 기능 추가, 업그레이드에 대한 전략이 반드시 필요하고, 관리 측면에서는 소프트웨어의 버전을 관리하는 버저닝(Versioning) 전략도 고려해야 한다.

버저닝 개념 이해 http://www.esri.com/news/arcuser/0110/versioning101.html

SI 아키텍처와 솔루션 아키텍처 비교

앞에서 살펴본 것처럼, SI는 고객이 요구하는 소프트웨어이고 솔루션은 구체적인 목표가 없는 상태에서 필요에 의해 만들어지는 소프트웨어이기 때문에 SI 아키텍처와 솔루션 아키텍처는 무슨 소프트웨어를 만들 것인지 목적이 다르다. 따라서 구성되는 아키텍처의 특징도 <표 2>와 같이 다르게 나타난다.

<표 2> SI 아키텍처와 솔루션 아키텍처의 특징

SI 아키텍처의 특징	솔루션 아키텍처의 특징
고객의 요청에 의해 프로젝트 구성	필요에 의해 프로젝트 구성
사전에 협의된 요구사항 범위와 목표에 의해 시작	구체적인 목표나 계획 없이 시작
전통적인 프로세스, 방법론에 따라 진행	세부적인 문서 등이 없이 진행
아키텍처를 먼저 수립하고 아키텍처를 기반으로 개발 진행	개발이 먼저 진행되고 아키텍처는 느슨하게 존재
기능/비기능 요구사항에 맞춘 아키텍처 수립	집단 지성과 협업에 의해 아키텍처 수립

<표 2>를 살펴보면, SI 아키텍처는 기술적인 요소가 반드시 포함되고 그에 따라 개발이 진행된다. 하지만, 솔루션 아키텍처는 설계와 개발이 진행되면서 아키텍처가 서서히 정의되기 때문에 기술적인 요소가 아예 포함되지 않을 수도 있다.

또한 두가지 아키텍처의 근본적인 목표는 비즈니스 요구사항을 만족하는 소프트웨어를 만들기 위한 요소들과 그 관계를 정의한 것이다. 따라서 비즈니스를 분석하여 정의하는 프로세스가 두가지 아키텍처에서 모두 존재하게 되는데, 여기서 SI 아키텍처와 솔루션 아키텍처의 가장 큰 차이점이 나타난다. SI 아키텍처는 비즈니스 요구사항을 기술로 해석한 후 필요한 요소들을 정의하여 소프트웨어를 개발하는 것이고, 솔루션 아키텍처는 비즈니스 요구사항을 그 자체로 해석한 후 소프트웨어를 개발한다. 아키텍처는 개발이 진행되면서 최종 완성된다. SI 아키텍처에 요구사항이 제대로 반영되었는지 고객들이 검증하기 어려웠던 것은 기술로 정의된 요인이 크다. <그림 2>는 SI 아키텍처를 정의하는 것을 나타내고 있다.

<그림 2> SI 아키텍처 설계 프로세스

<그림 2>를 살펴보면, 비즈니스 아키텍처 수립 후에 애플리케이션, 기술, 데이터 아키텍처가 정의되는 것을 볼 수 있다. 하지만 내부의 아키텍처 정의 내용들이 모두 기술적으로 정의되고 있다. 기술 요소로 구성된 SI 아키텍처는 설계자나 개발자들이 해석하고 활용하기는 좋으나 추상적인 비즈니스를 기술적인 아키텍처로 옮기기에는 다소 무리가 있다. 이러한 이유로, SI에서는 비즈니스와 기술을 연결해주는 부분을 해결하고자 엔터프라이즈 아키텍처(EA, Enterprise Architecture)를 적용하였지만 크게 호응을 얻지는 못했다.

<그림 3>은 솔루션 아키텍처 설계 프로세스를 나타내고 있다. 비즈니스 전략과 목적을 통해 비즈니스 모델을 만들고 엔터프라이즈 아키텍처를 거쳐 비즈니스 프로세스와 비즈니스 시스템, 그리고 솔루션 아키텍처를 만들고 있다.

<그림 3> 솔루션 아키텍처 설계 프로세스

자료: Alan McSweeney의 Structured Approach to Solution Architecture

솔루션 아키텍처의 근본적인 목적은 <그림 4>에서 보는 것처럼 비즈니스 모델에서 요구되는 요구사항을 효율적이고 명확하게 파악하여 비즈니스 시스템을 정의하고, 이를 소프트웨어로 만들어 딜리버리 하도록 하는 것이다. 비즈니스 모델을 비즈니스 시스템으로 정의하기 위해 엔터프라이즈 아키텍처를 활용한다. 일반적으로 TOGAF를 많이 사용하며, TOGAF는 하단을 참조한다. 여기까지는 SI와 유사하다고 볼 수 있다.

<그림 4> 솔루션 아키텍처 설계의 근본적인 목적

자료: Alan McSweeney의 Structured Approach to Solution Architecture

Enterprise Architecture: TOGAF 개념 이해 https://www.opengroup.org/togaf/

<그림 5>는 비즈니스 요구사항과 아키텍처 기준을 기반으로 솔루션 아키텍처를 정의하고, 이를 솔루션으로 딜리버리하는 것을 나타내고 있다. 이처럼 비즈니스 요구사항 자체를 아키텍처에 반영하고, 이를 바탕으로 원하는 소프트웨어를 딜리버리 하는 것이 솔루션 아키텍처의 장점이라고 볼 수 있다. 다만, 이러한 비즈니스를 반영하기 위해 설계자와 개발자도 비즈니스에 대한 많은 경험과 지식이 요구된다.

<그림 5> 솔루션 딜리버리를 위한 아키텍처 설계

자료: Alan McSweeney의 Structured Approach to Solution Architecture

아키텍처는 만들고자 하는 소프트웨어를 미리 살펴보면서 필요한 요소들을 큰 그림으로 나타내는 것이다. 그리고 소프트웨어를 분석, 설계, 개발하면서 원래의 의도대로 만들고 있는지 비교해보는 기준을 나타내기도 한다. 지금까지 살펴본 바와 같이 SI와 솔루션 아키텍처는 만들어지는 목적과 시점이 다소 다르다. SI의 아키텍처는 고객이 요구하는 환경에 맞게 구성해야 하고, 솔루션 아키텍처는 소프트웨어가 구동하는데 가장 이상적인 환경을 가정하여 구성한다.

이번 회에서는 SI와 솔루션 아키텍처를 구성하는 방법과 역할, 그리고 두 아키텍처에 대한 차이점을 비교해보면서 장단점을 살펴보았다. 모바일 디바이스의 증가 추세로 볼 때, 불특정 다수가 사용하는 솔루션 형태의 소프트웨어가 점점 증가할 것으로 보인다. 지금까지 안정화된 많은 SI 아키텍처의 특징과 구성을 잘 파악하여 지속적으로 늘어나는 솔루션 아키텍처를 효율적으로 구성할 수 있도록 해야 할 것이다. 솔루션 아키텍처는 기하급수적으로 늘어나는 솔루션들의 개발 방향을 알려줄 것이다.

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