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

패키지에 관련된 교육이었는데, 제가 현재 사용하고 있는 패키지와는 다른 형태로 인터페이스를 하는 것이 좀 특이했습니다. 제가 지금까지 사용하던 패키지는 각 모듈간의 인터페이스가 데이터 모델링(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)의 길은 역시 멀고도 험한 것 같습니다. ^^