미소띠움

연계시스템 구축 시 고려할 사항들 본문

Diary/Diary

연계시스템 구축 시 고려할 사항들

미소띠움 2010. 12. 2. 11:59

기업의 비전에 도달하기 위해 전사적 자원을 하나로 모아 효율적으로 미션을 성공하고 내외적인 이슈에 능동적으로 즉각 대처하는 등 기능적으로 설계된 실제 시스템을 소프트웨어적으로 구현하는 것을 시스템 통합이라고 한다. 또한 근래에는 그 기능적인 면뿐만 아니라 시스템 통합 시 데이터의 품질 관리 또한 매우 중요해지는 현실이다. 그 배경은 무엇일까? 가비지 데이터(Garbage Data)에 대한 폐해와 피해 사례가 여러 매체를 통해 알려지면서 더 이상 데이터가 소프트웨어에 종속되지 않으며 독립된 관리가 필요하다는 인식이 높아졌기 때문이다.

최근에는 과거의 데이터를 통해 미래를 고려하는 DW 시스템이나 DSS 시스템 같은 VLDB(Vary Large DataBase) 시스템 구축을 단위 시스템 통합과 연계해 수행하는 경우가 많은 것 같다. 이른바 정보계 시스템과 정보계 시스템의 원천이 되는 계정계 시스템들이다. 이 정보계 시스템에 더 정제되고 의미 있는 데이터를 제공하기 위해 계정계 시스템 설계 시부터 고려하겠다는 발상은 매우 좋다.
그러나 한 발짝 내딛어서 그 안을 들여다보면 시스템 설계 시 계정계 시스템과 정보계 시스템의 구축 과정 및 기간이 서로 다른 경우가 많아서 일반적으로 먼저 시작되는 계정계 시스템의 설계 변경이 많아진다면 기존에 설계된 정보계 시스템 설계에도 많은 영향을 줄 수 있다는 점이다.
결국 계정계 시스템과 정보계 시스템을 함께 설계해도 구축 및 구현 과정 중 발생된 이슈에 따라 함께 변경되어야 하는 것이 많다는 의미다. 즉, 2개 시스템의 업무적인 싱크를 맞추기 위해 별도의 인력이나 솔루션을 구비해야 된다는 얘기가 된다.
그리고 또 한 가지 문제점은 정보계 시스템은 그 근간을 계정계 시스템으로 삼기 때문에 계정계 시스템의 구축이 지연될 경우 정보계 시스템 또한 추가적으로 지연 될 수밖에 없게 된다. 경우에 따라 다르겠지만 계정계 시스템에서 중요한 설계 실수가 발견되어 설계의 많은 부분을 변경해야 한다면 그 여파는 해당 사업 수행에 있어서 엄청난 재앙이 될 것이다
따라서 차세대 시스템 구축사업을 수행하면서 정보계 시스템 또한 같은 선상에 놓고 계획하고 있는 곳이 있다면 다음과 같은 리스크를 고려해야 할 것이다.

1.시스템 표준 및 데이터 표준과 같은 메타정보가 계정계 시스템과 마찬가지로 정보계 시스템도 같은 기준으로 동작 및 기능하는가?

정보계 시스템에서 사용하는 데이터 표준과 계정계 시스템이 사용하는 데이터 표준이 다르다면 개발 중에라도 즉시 드러나는 성능 저하 같은 문제뿐만 아니라 추후 유지보수 시에도 불명확한 의미나 서로 상이한 뜻, 그리고 도메인 불일치 등으로 많은 문제가 발생할 수 있다. 그러나 이와 같은 설계 단계의 데이터 표준은 발견 즉시 수정하기 어려운 경우가 많아 또다시 다음의 차세대를 기약하는 경우도 발생하게 된다.
이처럼 동시에 여러 프로젝트를 진행할 경우 기존부터 전사적인 메타 시스템이 구축되어 있다면 이를 잘 관리해 운용하면 되겠지만 신규로 시스템을 구축하며 전사적인 메타 시스템도 함께 정비하려 한다면 이음동의어나 동음이의어 등 용어에 의해 용어 정의조차도 쉽지 않기 때문에 어려움이 따를 수밖에 없기 때문이다.
또한 정보계 시스템은 한번 구축하면 변경하기 힘든 구조를 가지거나 집계성 데이터를 많이 포함하고 있으므로 최초 구현 시 시스템의 기초가 되는 표준 용어사전과 도메인과 같은 메타 영역에 대한 많은 고려와 검토가 이뤄져야 할 것 이다

2.계정계 시스템 설계 시 정보계 시스템에 필요한 요구 데이터 수준에 대해 충분히 고려되었는가?

계정계 시스템에서 도출되지 못한 속성이 존재하고 의미상 중요해 정보계 시스템에서 수용해야 하는 속성이라면 경우에 따라서 이의 반영이 용이하지 못할 수 있다. 이런 경우는 정보계 시스템에서 구축하려던 기능 및 필요한 속성에 대해 계정계 시스템 설계 시 상호검증으로 어느 정도 리스크를 줄일 수 있으므로 반드시 필요하다.
사실상 개발이 진행되면서 설계 시 미 도출된 내역이 많이 발견되지만 또 다른 많은 경우 고객사에서 사업시작 시 발표했던 요구사항 명세에 명기되지 않은 추가적인 요구를 설계 종료 이후나 개발 기간 중 요청하는 경우(심지어 프로젝트 오픈 직전에도 경험할 수 있다) 사회적 역학관계에 의해 요구를 물리치지 못하고 수락하는 경우가 많은 것 같다.
이를 미연에 방지하기 위해서는 설계 시 고객보다 한발 더 내딛는다는 전향적인 마음가짐으로 현재의 트렌드와 고객사가 가지고 있는 비전과 미션에 대한 앞으로의 니즈(Needs)를 설계 시 반영하는 것이 추후 요구사항에 대응할 수 있는 가장 적극적인 방법이라 생각된다.
이를 위해 많은 인터뷰와 함께 고민하면서 밤을 하얗게 지새워야 할지도 모르겠다. 계획된 사업범위를 넘치지 않고 적절하게 고객의 요구를 수용하는 것은 거의 불가능한 미션에 가깝기 때문에 업무 외적으로 고려해야 할 것이 많아질 수도 있기 때문이다

3.정보계 시스템의 구축을 위한 스케줄에 계정계 시스템의 딜레이에 의해 지연될 수 있는 리스크가 포함되었는가?

요즘 프로젝트 비용 효율화를 위해 긴축재정 기조를 유지하는 사업이 많은 상황에서 스케줄 관리를 위해 여유분을 둬야 한다는 이야기는 논란의 대상이 될지도 모르겠다(단일 프로젝트를 진행하는 것이라면 논란의 여지가 없다. 여분의 일정이라는 것이 용납되지 않기 때문이다).
하지만 계정계 시스템과 정보계 시스템, 두 시스템의 프로젝트가 연동하면서 각각 진행된다면 정보계 시스템은 정보계 시스템대로의 인력 및 스케줄 관리를 할 텐데 만약 계정계 시스템의 딜레이에 의해 정보계 시스템의 스케줄이 지연될 수 있다면 정보계 시스템의 잘못(fault)이 아니더라도 지연되고, 그리고 이에 따라 리스크를 예측할 수 없는 사업이 되어 프로젝트 리스크 관리의 위험성은 보다 커질 수 있을 것으로 예상되기 때문이다.
결국 정보계 시스템은 계정계 시스템의 설계 수정과 중요한 프로세스의 변경을 예의 주시하며 자체 일정 준수와 더불어 계정계 변경 분에 대한 조속한 반영을 요구 받는 혹독한 개발 환경에 놓이게 될 것이다.
4정보계 시스템의 비정형 데이터를 어떻게 관리할 것인가?
정보계 시스템을 설계하면서 많은 비표준 데이터 항목이 추가되곤 한다. 일반적으로 비표준 데이터라는 것에 대해 말하기 전에 반대되는 정형 데이터라는 것을 살펴보면 엔티티와 속성으로 구분해 관리할 수 있는 데이터를 들 수 있다. 일반적으로 우리가 데이터베이스에 입력하고 관리하는 데이터로 고객/물류/재무 등의 업무를 수행하는 데이터이다. 반면 비정형 데이터라는 것은 소위 디지털 콘텐츠라는 음악, 동영상, 이미지, 문서양식 등 일반적으로 파일형태의 데이터를 떠올릴 수 있다.
2008년 IDC 보고서에 따르면 현재 기업 내 데이터의 92%는 관리되지 않은 비정형 데이터이고 정형 데이터는 8%에 불과하다고 한다. 이렇게 비정형 데이터는 정형 데이터에 비해 압도적으로 많아지고 있으며 크리슈머라 불리는 일반 사용자들에 의해 소비되고 생산되는 비정형 데이터는 앞으로도 기하급수적으로 늘어날 것으로 보인다.
개중에는 정보계 시스템의 설계 시 동적으로 변화하는 성격을 가진 데이터를 관리하기 위해 비정형 데이터라는 사용자 데이터 타입을 도메인으로 선언 및 등록해 사용하는 것을 종종 보게 되는데 위에서 이야기한 디지털 콘텐츠와 같은 비정형 데이터와는 차이가 있다. 단순히 속성으로 나눌 수 없는 데이터를 단순히 비정형이라는 타이틀을 달아 묶어 두겠다는 것이다.
그냥 비정형이라는 테두리에 두어서는 의미 있는 또는 구별 가능한 데이터로 사용하기 힘들다. 정형화하기 힘든 콘텐츠를 전사적으로 표준화하고 구분해야 할 뿐 아니라 중복 관리가 가능하도록 속성을 나누고 메타정보를 추가해 관리할 필요가 있는 것이다. 그런 추가적인 가공과 관리를 통해 비로소 보다 의미 있는 데이터로 사용될 수 있?한 비정형 데이터를 관리함에 있어서 이러한 고려가 반드시 필요한 이유다. 계정계와 정보계 각 프로젝트를 관리하면서 이에 대비해 여러 가지 솔루션과 방법론을 가지고 준비하게 되겠지만 결과적으로는 2개 시스템의 인터페이스를 제어할 수 있는 경험 많은 관리자와 각각의 개발자는 프로젝트 관련 인원의 커뮤니케이션이 가장 중요한 부분이 될 것이고 많은 문제가 잘못된 커뮤니케이션으로 인해 발생할 것이므로 이에 대한 충분한 대비와 고려가 필요하다는 생각을 하게 된다.

<필자소개>
이지웅 woongs@axiominfo.co.kr|현재 엑시엄 정보에서 컨설턴트로 근무하고 있으며 튜닝, 모델링, DBA 업무를 수행하고 있다. DB에서 진리를 찾고자 노력하며 지금은 조그마한 책과 솔루션 개발을 준비하고 있다.

출처 : 한국 마이크로소프트웨어 11월호
제공 : DB포탈사이트 DBguide.net

Comments