SharePoint 기반의 결산 모니터링 시스템

 '월말 결산'이라는 용어 자체가 생소하신 분들에게는 뜬구름 잡는 듯한 얘기라 익숙하신 분들을 대상으로만 얘기해 보겠습니다. 결산 업무가 BPM으로 구조화, 시각화 된 곳이 아닌 이상, 현업들의 머리만 의지하다 보면 결산 처리에 구멍이 나게 마련입니다. 물론 개별 리포트 건으로 이를 확인 가능하지만 포탈 등에 올라가 눈에 보이지 않는 이상 리포트 실행 자체를 잊기도 하지요.

 이에 따라 고객사에서 결산 업무를 모니터링할 시스템을 주문했습니다.추가 비용 없이요. ^^ 향후 EIS 프로젝트 때 제대로(?) 하자는 약속을 한 후, ERP 팀에서 콘텐트 기획을 맡고 저는 BI 담당자로서 일단의 아키텍처를 구성해 보았습니다. 가용한 자원을 보니 MS SQL Server 2008, MS Office SharePoint Server 2007 정도더군요. 남는 서버가 없어서 VMware 상의 가상 서버를 사용하기로 했습니다.

전체 구성도

 실은 EIS 프로젝트 때 제대로 하자는 약속 외에도 몇 개 더 합의를 해야 했습니다.

 일단 성능입니다. 아시다시피 데이터 웨어하우스에는 결산 이후의 데이터가 태반입니다. 물론 일일 배치로 추출하는 자료도 많지만 고객사의 결산 모니터링 콘텐트와는 무관한 게 많았지요. 결국 ERP를 직접적인 데이터 소스로 삼아야 하므로 성능 면에서 한계가 있을 수 밖에 없습니다. 그렇다고 결산 모니터링을 위해 휘발성 데이터에 대한 별도의 데이터 마트를 구성하는 건 여러 가지로 낭비라고 봤기 때문에 고객사와 합의를 했습니다. 다행히 MS Reporting Service에는 캐싱과 스냅 샷 같은 보조적인 성능 보조 기술이 있어서 상당 부분 보완 가능했습니다.

 안타까운 건 디자인이었습니다. SharePoint 2007의 기본 템플릿은 한국인을 만족 시키기에 너무나 부족해서 이 부분이 정말 큰 이슈가 되었고 여전히 미완으로 남았습니다.

 '주요' Presentation 도구로 사용한 MS Reporting Service는 2005 버전 때 꽤 쓸만해졌고 2008 버전에 이르러서는 차트 면에서도 괄목할 만한 발전을 했습니다. 사용법도 일단 시작은 쉬운 편이라 SAP ERP의 RFC 개발을 담당한 ERP 모듈 담당자들이 제가 이틀간 진행한 6시간 교육만 받고도(^^;;;;) 각 리포트 페이지의 90% 이상을 담당했습니다. (이해력이 좋은 팀원들입니다.) 여러 사람이 작업했기에 차트 테마 통일 같은 작업을 해야 했지만 비용 면으로 보면 엄청난 절약이었죠. (뭐, 저나 회사 입장에서는 돈이 안 됐습니다만.)

 인프라 구성을 내부적인 사정에 따라 어쩔 수 없이 제가 하는 바람에 시행착오가 참 많았고 여전히 몇 가지 소소한 이슈가 남았지만 이렇게 SharePoint와 MS SQL Server를 기반한 아키텍처 자체는 쓸 만한다고 말씀 드리겠습니다. 분명 고객은 불만을 얘기하지만 비용적인 측면을 되짚어 주면 대체로 수긍하게 되거든요. 비용 대비 성능은 정말 좋은 아키텍처입니다.

 별도로 BizTalk Adapter Pack(BAP)에 대해 말씀 드리면 이미 BizTalk Server 라이선스와는 별개인 듯합니다. MSDN Subscription을 구매한 상태라면 역시 그냥 써도 되지 않을까 해요. 이 부분은 MS 영업에 문의해 보시는 게 좋겠습니다. BAP의 WCF Adapter로 인해 .NET 개발은 물론 Reporting Service의 데이터 소스 이슈는 거의 사라졌다고 봅니다만 아쉬운 게, 느리고 한 번에 처리할 수 있는 데이터량도 크지 않아요. 그렇다 해도 상황에 맞게 쓴다면 생산성은 더 말할 나위 없이 높아집니다. 고민을 좀 해 볼 가치가 있겠습니다.

 SSIS를 사용한다면 오픈소스 Flash Chart 등을 활용하는 게 불가능하지는 않겠지만 이번 참엔 포기했고요. 현재 결산 모니터링 시스템 메인의 요약 화면은 HTML로 콘텐트 별 Box를 만들어 JQuery로 각 콘텐트의 최근 10분 수치를 저장한 CSV 파일을 읽게 했습니다. 앞으로 콘텐트가 어떻게 변할지 몰라 유지보수가 쉬운 방향을 생각하다 보니 이렇게 됐네요.

 고객사가 올해 엄청난 변혁을 하는 중이라 현업 사용자의 요구분석을 전체적으로 하지 못하고 소수 부서의 니즈에 따라 만들었으므로(-_-) 변화의 방향을 예측하기가 쉽지 않거든요. 그래도 이 아키텍처라면 변화의 폭이 꽤 크더라도 고객사의 니즈를 충분한 수준으로 대응하게 되리라 기대해 봅니다.