예전 메모 - SAP & MS SSRS

2009년도인가 SAP 세미나에 참석하여 이야기를 듣다 말고 당시에 신경 쓰던 ERP 결산 모니터링 시스템 생각이 나서 끄적거렸던 메모가 나왔다. 요즘 쓰는 태블로 생각이 나기도 하여 바로 버리지 않고 블로그에 옮겨 둔다. 저 때에는 MS SQL Server Reporting Service (SSRS)로 SAP ERP에 remote function call (RFC)을 하여 월간 결산의 진척을 ERP 모듈 별 리포트에 나타내는 식으로 구현했다. 개중에 몇몇 리포트는 애초에 RFC 소요시간이 너무 걸렸고, 이를 해결하기에는 수지타산이 맞지 않을 정도로 작업공수가 많이 들어서 고민을 했던 기억이 난다.

 

메모 윗편에는 SAP 개발생명주기, 비즈니스 프로세스 모니터링, BI 연계, 메모 아랫편에는 MS SSRS로 개발한 결산 모니터링 시스템 개선안을 적었다.

MS SSRS는 나름 역사가 있는 솔루션이라 이런 때를 대비한 몇 가지 대안을 제공했다.

 

하나는 캐싱(caching)으로, 약정한 방식으로 리포트를 주로 새벽에 혹은 주기적으로 미리 실행해 두면 SSRS가 해당 결과를 캐싱해두어 사용자는 지체시간 없이 리포트를 조회하게 된다. 캐싱 주기에 따라 최신 정보를 보지 못하며 캐싱하지 않는 과거의 정보를 '굳이' 보려고 하면 ERP에 RFC를 새로 해야 하므로 리포트 출력 시간이 오래 걸리는 약점이 있다. 이를 해결하려면, 결산 관련 정보를 실시간/준실시간으로 추출하는 데이터 마트를 구성해야 하므로, 배보다 배꼽이 큰 작업공수를 들일 수밖에 없다. 어떤 현업은 '그래도 네가 고생해서 만들면 어떨까' 같은 희망을 비치기도 했는데, 운영 공수까지 생각하면 지속가능하지 못해 포기하자고 했었다. 매개변수는 집합을 몇 개 만들어서 캐싱할 수 있기에 다양하게는 못하더라도 우선순위가 높은 니즈는 어느 정도 대응이 가능했다.

 

다른 하나는 스냅샷(snam shot)으로, 사용자가 매개변수를 조작하지 못하고 설정한 매개변수로만 스냅샷을 만들어 데이터 원천에 질의하지 않고 바로 리포트를 출력하는 기능이다. 캐싱보다는 제한적으로만 써야 하지만 출력속도가 캐싱보다 빨랐다. 스냅샷을 여러 개 만들어서 필요 시 조회하는 것도 가능해서 대시보드 용도로 쓸 만했다.

 

ERP 결산 모니터링 시스템 개발 프로젝트 때에 특기할 만했던 건, 당시 SAP ERP 모듈 담당자들이 직접 SSRS 리포트를 만들었다는 점이다. 나는 SSRS 사용법을 교육하고 지원하며 MS SharePoint Server 기반으로 포탈을 구성하는 역할만 수행했다. 최근의 조류를 감안하면, 상상도 못할 방식이었다. 지금 같으면 SSRS 기반 레포트는 외주 개발을 맡길 수 밖에 없었을 것이다. 내게는 뿌듯했던 경험이었지만, 일이 많았던 동료들에게는 어떤 기억으로 남았을지 지금에서야 다소 마음이 쓰인다. 어떻게 그러고 살았을까.