이번 주말에 교육 때문에 이틀을 꼬박 반납했더니 한 주가 무지 피곤합니다. 아무래도 프로젝트에 있다 보니 교육을 받기가 어려워서 나름대로 교육신청을 한다고 한 것이 주말이었는데, 한 주의 시작부터 힘든 것을 보니 다음부터는 받지 말아야 할 것 같다는 생각이 듭니다.

패키지에 관련된 교육이었는데, 제가 현재 사용하고 있는 패키지와는 다른 형태로 인터페이스를 하는 것이 좀 특이했습니다. 제가 지금까지 사용하던 패키지는 각 모듈간의 인터페이스가 데이터 모델링(Data Modeling)에 의해서 움직이는 관계로 하나의 레코드가 발생할 때 관련 테이블에 관련 데이터들이 모두 반영되는 형태였는데, 제가 이번에 배운 패키지는 일시에 데이터가 반영되는 것이 아니라 한 모듈에 데이터가 반영된 뒤 다른 모듈에 배치작업을 통해서 데이터가 연계되는 형태로 운영되는 패키지였습니다.

이런 형태로 패키지를 운영하게 되면 나름대로 좋은 장점이 있다는 생각이 듭니다. 예를 들어 대형 패키지를 개발할 때, 각 부분별로 모듈을 분리하고 각기 모듈을 개발한 뒤에 배치작업을 통해서 데이터를 연계하면 됨으로 프로젝트 초기에 어떤 방식으로 데이터를 넘겨 줄지만 결정한 후 바로 개발에 들어갈 수 있는 장점이 있습니다. (이 패키지의 경우도 제가 사용하고 있는 패키지의 후발주자인데 그러한 방식으로 엄청나게 빠른 속도로 기능 개선을 이루어서 현 시점까지 왔습니다.)

이전의 제 생각으로는 이렇게 할 경우 같은 인스턴스를 사용하더라도 데이터의 정합성이 깨질 가능성이 높기 때문에 잘 고려하지 않는 방법이었는데, 널리 쓰이는 패키지가 이러한 방식의 아키텍처(Architecture)를 가져가는 것을 보면서 이러한 방식도 개발의 좋은 한 방편이 될 것이라는 생각을 해 봅니다.

실은 이러한 생각을 하기 전에도 데이터 모델링(Data Modeling)과 데이터 교환(Data Exchange)에 대해서 생각을 해 본 적이 있습니다. 예를 들어 기업 내에 많은 어플리케이션이 존재하는 경우 이에 대한 연계가 어려워서 EAI(Enterprise Application Integration)을 도입하는 경우가 많기 때문에 생각해 보았는데, 실제로 EAI를 도입하면 데이터의 연계가 N^2 모델에서 N의 모델로 변경되기 때문에 상당히 유용하다고 할 수 있습니다.

제가 고민했던 부분 중 하나는 시스템 통합(Consolidation)할 때와의 차이점이었는데, 시스템 연계(Integration)을 할 때는 시스템의 수가 많으면 많을 수로 데이터 모델링(Data Modeling)보다는 데이터 교환(Data Exchange)가 중요하다는 점이고, 반대로 시스템을 통합(Consolidation)할 때는 그 반대의 경우라는 것입니다. (궁극적으로 다수의 시스템을 하나의 시스템으로 통합하게 되면 데이터 교환(Data Exchange)은 아예 없어진다고도 생각할 수 있다고 생각했습니다.)

사용자 삽입 이미지

그런데, 이러한 제 상식을 깨는 형태를 가진 패키지를 보니 시스템은 역시 공부하면 할수록 다양한 형태를 가지고 있다는 생각이 듭니다.

아키텍트(Architect)의 길은 역시 멀고도 험한 것 같습니다. ^^
,

카테고리

나누어보기 (648)
스타트업 & 벤처 (15)
컨설팅이야기 (239)
MBA이야기 (39)
CC Korea 이야기 (36)
문화 이야기 (92)
세상사는 이야기 (188)
IT 이야기 (39)

최근에 올라온 글

최근에 달린 댓글

03-19 08:44
BLOG main image
세상을 보는 또 다른 시선
때로는 '사실'보다 '희망'이 더 절박할 때가 있습니다. 적절한 희망이야말로 사람을 움직이게 하는 원동력이 되고, 사람이 움직이면 희망은 곧 사실로 바뀌게 됩니다.
by 5throck

세상을 보는 또 다른 시선

5throck's Blog is powered by Tattertools / Supported by TNM Media
Copyright by 5throck [ http://mbastory.tistory.com/ ]. All rights reserved.

Tattertools TNM Media DesignMyself!