시스템통합(SI)

개요

시스템통합(SI:System Integration)이란 기업이나 기관에서 필요로 하는 정보시스템을 기획에서부터 개발과 구축 그리고 운영까지의 모든 서비스르 제공하는 형태로의 개발을 말합니다. 한마디로 무엇이든 원하는 시스템을 요구사항에 맞추어 개발하는 방식을 통상 SI 개발이라 부릅니다. 흔히 맞춤 양복점에 비유하는 개발방식입니다.

폭포수모델

폭포수 모델 SI 개발방식은 전통적으로 폭포수모델(waterfall model, 출처: 위키피디아) 개발방법을 따릅니다. 이는 순차적인 소프트웨어 개발 프로세스(소프트웨어를 만들기 위한 프로세스)로, 개발의 흐름이 마치 폭포수처럼 지속적으로 아래로 향하는 것처럼 보이는 데서 붙여진 이름입니다. 이 폭포수 모델의 흐름은 소프트웨어 요구사항 분석 단계에서 시작하여, 소프트웨어 설계, 소프트웨어 구현, 소프트웨어 시험, 소프트웨어 통합 단계 등을 거쳐, 소프트웨어 유지보수 단계에까지 이릅니다. 이 전통적인 개발방식은 유구사항 및 사양을 모두 문서화하여 개발하는 방식으로 모든 개발시스템 적용할 수 있는 일반적인 모델이지만 장기간의 시간과, 많은 인력 리소스가 필요한 개발 방식입니다. 또한 초기 분석에 착오가 있을 경우 개선이 어렵고 개발팀의 능력에 따라 품질이 불균질한 단점이 있습니다.

CBD 방식

이러한 단점을 보완하기 위해 2000년대에 들어서 CBD(컴포넌트 기반 개발,component-based development) 개발방법이 제안되었습니다. CBD 방삭 CBD 방식은 기존의 시스템이나 소프트웨어를 구성하는 컴포넌트를 조립해서 하나의 새로운 응용 프로그램을 만드는 소프트웨어 개발방법론입니다. 예를 들어 전자 상거래시스템을 개발한다고 하면쇼핑바구니, 사용자 인증, 검색엔진, 카탈로그 등 상업적으로 이용 가능한 컴포넌트를 결합하여 개발할 수 있습니디. 이렇게 컴포넌트 미리 만들어 놓고 이들의 조합을 기반으로 진행합니다.

이 방식의 가장 큰 단점은 DBMS 중심 시스템의 경우 componet화에 근본적인 제약이 있다는 점입니다. JPA(Java Persistent API)를 이용하여 어느정도 한계는 극복할 수 있지만 DB 호환성 문제 등을 극복하는데는 한계가 있어 모든 SI 프로젝트에 전면적으로 적용하기는 어려운 모델이었습니다. RFX는 주 속성과 보조 보조속성을 분리하여 주 속성의 정합성은 유지하되 보조속성을 커스토마이징 하는 방식으로 이러한 한계를 극복, 테이블 변경없이 다양한 요구에 적용될 수 있습니다.

애자일 방법론

최근들어 주목받는 개발방법은 애자일 방법론입니다. 애자일 소프트웨어 개발(Agile software development) 개념은 반복적으로 분석, 개발, 검증하여 프로젝트의 기간동안 작은 개발을 반복 진행하는 방식입니다. 애자일 방식 애자일 방법론은 아무런 계획이 없는 개발 방법과 계획이 지나치게 많은 개발 방법들 사이에서 적절할 타협점을 찾는 방법론입니다. 계획이 없는 경우, 앞으로의 일을 예측하기 힘들고 효율적이지 못한 취약점이 있으며, 계획에 너무 의존하는 경우는 형식적인 절차에 따른 시간과 비용이 많이 드는 단점이 있습니다. 애자일 방법론과 폭포수 모델의 가장 큰 차이점은 문서를 통한 개발 방법이 아니라 실질적인 코딩을 통한 방법론이라는 점입니다. 애자일 개발 방법론은 계획을 통해서 주도해 나갔던 과거의 방법론과는 다르게 앞을 예측하며 개발을 하지 않고, 일정한 주기를 가지고 끊임없이 프로토 타입을 만들어내며 그때 그때 필요한 요구를 더하고 수정하여 하나의 커다란 소프트웨어를 개발해 나가는 방식입니다. 이 방식은 사내 시스템 개발 또는 롱텀 SM(System Mgmt.)개발에는 가능하나, 단기 계약에 의해 진행한는 SI 프로젝트에서는 계약 범위가 불분명해지는 문제점이 있습니다. RFX는 테스트베드 채용으로 이러한 문제를 해결합니다.

SI 적용분야

예산에 제한이 없는 공공분야 프로젝트, 대기업 프로세스 중 기업고유의 프로세스에 적용할 필요가 있는 경우에는 일반적으로 SI프로젝트로 진행합니다.


패기지S/W

개요

기성복처럼 이미 개발이 완료된 패키지 S/W를 도입하면 SI프로젝트에 비해 경제적으로 고품질의 S/W를 단기간에 구축할 수 있습니다. 다만 기업 시스템은 모든 기업이 자신만의 고유한 속성을 가지고 있어 이를 일률적으로 표준화하기 어렵다는 문제가 있습니니다. 패키지 S/W는 이를 해결하기 위해 기본 소프트웨어의 기능 위에 각 기업마다의 고유한 특성에 맞추는 커스토마이제이션(Customization) 절차를 따르게 됩니다.

패키지S/W 패키지S/W는 소프트웨어 고유의 기능을 가지고 있는 커널(Kernel)부, 외부에 사용자가 실재 사용하는 Application 부 그리고 Application 을 개발하기한 커널이 제공하는 도구모음인 API(Application Programming Interface) 로 구성이 됩니다. 이 구성이 가장 기본적인 구성이며 이밖에 각 소프트웨어 마다 공유의 커스토마이징 개발도구와 모듈이 제공됩니다.

API 수준에 따라 커스토마이징을 어느정도 수준으로 할 수 있는지 결정됩니다. 커스토마이징을 과도하게 진행할 경우 SI프로젝트와 동일한 품질문제를 일으킬 수 있으며, 커스토마이징 비용이 과다하게 증가하여 패키지 라이센스 비용과 커스토마이징 비용을 이중으로 지출하여 오히려 SI개발보다 더 많은 비용이 지출되는 경우도 많이 있습니다.

또한 커스토마이징으로 변경할 수 있는 수준은 패키지 개발시 정의된 범위 내 일수 밖에 없으며 무한정 가능한 것은 아닙니다. 그렇다보니 업무로직을 무리하게 소프트웨어의 틀에 끼워맞추는 부작용이 발생할 수 있으며 급변하는 기업환경 변화 대응에 뒤쳐질 수 있습니다.


구축절차

패키지 절차 패키지 S/W 경우 이미 검증된 모듈로 요구사항을 커스토마이징하여 사용하므로 요구사항정의, 커스토마이제이션, 적용의 비교적 단순한 절차에 따라 구축됩니다. 적용 후 필요한 경우 추가 개선 작업을 진행합니다. 커스토마이제이션은 표준양식 적용, 데이터 마이그레이션이 포함됩니다.

적용분야 및 한계

패키지 S/W의 이미 비즈니스 로직이 확정되어 있는 분야에는 탁월한 성능을 발휘합니다. 예를들어 법률에 의해 로직이 강제되는 재무회계 분야창고관리, 전통적인 대량생산의 MRP 분야등은 패키지 S/W 적용이 용이합니다. 반면에 비즈니스 로직이 기업에 따라 가변이 심한분야, 계속 성장하고 있어 로직이 계속 변경되는 하이테크 분야, 발주처의 요구에 따라 지속적인 프로세스 변경이 발생하는 주문 기반 모델에는 적합하지 않습니다. RFX는 패키지 S/W 이지만 필요한 경우 추가 모듈 개발이 기능합니다.


RFX 시스템 구축 방법

테스트베드 베이스 개발

패키지 절차 테스트베드란 요구사항이 제대로 반영되었는지 사용자가 직접 사용하면서 검증할 수 있는 시스템입니다. 이것은 완벽하진 않지만 구동가능하여, 실재 연계동작을 개발단계 전에 이루어진다는 점에서, 단순히 화면 디자인만 검증하는 "디자인 목업"과는 차별화된 시스템입니다.

테스트베드 구축시간은 요구사항접수 후 통상 2-3주면 완성이됩니다. 즉, 컨설턴트 미팅후 최대 3주안에 초기개발 시스템을 사용자가 미리 동작해 볼 수 있다는 의미입니다. 이것은 단순히 문서로 커뮤니케이션하는 여타 요구 사항정의 방법에 비해 매우 정확한 상호 커뮤니케이션이 가능함을 의미합니다.

이것이 가능한 이유는 RFX 시스템 자체가 워크플로우 상에 모듈화되어 있어, 시스템을 마치 조립하듯이 CBD 방법론에 따라 모듈의 조합으로 구성할 수 있고 메뉴관리 기능, 코드관리 기능으로 솔루션의 모든 화면을 간단하게 커스토마이징할 수 있기 때문입니다. 특히 화면구성이 Object의 상속으로 정의되어 있어 동일 소스시스템에서 기업별 특성화가 가능합니다.

테스트베드는 하나의 완전한 코드셋이지만 RFX의 개발 소스에서 분리되지 않은채 구현되어 별도의 절차없이 곧바로 실 개발로 연계됩니다. 즉 테스트베드는 커뮤니케이션 용도인 동시에 그 자체로 개발이 진행되고 있는 시스템 상태입니다. 고객은 계속해서 구현내용을 실시간으로 검증하면서 요구사항을 반영할 수 있습니다. 이는 애자일 방법론의 장점을 채용한 것입니다. (보통 1주일에 한번 배포합니다.) 일반적인 기능들, 통상 90% 이상의 기능은 이미 패키지S/W로 구현되어 있어 그대로 적용, 사용할 수 있습니다.

RFX 방법론의 장점

RFX의 테스트베드 기반 개발은 지금까지 나온 여러 개발 방법 방법론의 장점을 테스트베드라는 매개 시스템으로 통합하여 개발하는 방법입니다. 이러한 개발방법으로 다음과 같은 장점이 있습니다.

  1. 사전 검증으로 고객의 요구사항을 정확하게 반영할 수 있습니다.
  2. 개발시간이 단축되어 경제적인 시스템을 구축할 수 있습니다. 통상, SI의 20%, 패키지의 50% 정도의 시간만 소요됩니다.
  3. RFX의 모든 시스템은 단일 소스코드 상에서 개발됩니다. 품질의 향상 및 지속적인 유지보수가 가능합니다.
  4. 프로세스의 변경이 자주 발생하는 신사업 분야에 등에서 향후 필요에 따라 유연하게 변경 적용할 수 있습니다.
  5. 소규모의 예산집행 만이 가능한 중소기업도 대기업 수준의 고품질 시스템을 채택할 수 있습니다.