Lumira 대시보드 리팩토링 정리

개요

오늘은 최근 열중하고 있는 업무에 대해서 간단히 정리해보려고 한다. 작업량이 워낙 많다보니 블로그 글을 쓸 여유를 가지지 못했고 마지막 포스팅으로부터 일주일이라는 시간이 지나버렸다. 어떻게든 틈을 내서 블로그 글을 쓸 시간은 내었으나 포스팅할만한 주제가 떠오르지 않아서 최근 열중하고 있는 업무 그 자체를 포스팅해봐야겠다고 생각했다.

Lumira 소개

SAP Lumira Designer는 웹 대시보드 개발을 위한 툴이다. SAP에서 제공하는 다른 BI 툴인 WebI나 SAC와 비교하면 차원을 추가했다가 뺐다가 하는 식의 능동적인 분석이 제한적이고 개발 인터페이스도 현대적이지 못하며 온 프레미스 시스템위에서 동작한다는 점 등 구시대적면이 있는 BI툴이다. 그렇지만 명백한 장점도 있다. 그것은 SAP에서 제공하는 그 어떤 BI 툴보다도 자유도가 높고 디자인 요소가 풍부하다는 점이다. Lumira는 '웹' 대시보드 개발을 위한 툴이다. 웹이라는 걸 강조한 이유는 WebI나 SAC는 애플리케이션으로서 포털에 올라가 있다는 인상을 주는 툴인데 비해 Lumira는 대시보드 '웹 화면'을 만든다는 인상을 주기 때문이다.

루미라는 개발부터가 웹 개발의 프로세스를 따르고 있다. 웹 개발은 자바스크립트를 기반으로 이벤트를 제어하고 데이터를 정리, 표시한다. 루미라도 마찬가지로 자바스크립트와 비슷한 루미라 스크립트로 이벤트를 제어하고 데이터를 정리, 표시한다. 데이터를 정리하는 자유도도 대단하다. 일단 데이터를 불러오기만하면 자유롭게 계산하고 배치할 수 있으며 데이터 셋을 스크립트 내부에서 차원을 넣었다가 뺏다가 필터를 걸었다가 풀었다가하면서 다양한 형태로 활용할 수 있다. 이벤트를 다루는 데에 있어서도 화면이 처음 열렸을 때, 버튼 클릭, 요소 클릭, 화면 팝업 등의 다양한 부분에 대응이 가능하도록 기능이 준비되어 있다. 이러한 스크립트를 다양한 함수로 나누어서 관리할 수 있어 기초적인 객체지향 코딩도 가능하다. 

또한 오브젝트에 css 선택자를 부여할 수도 있고 그 선택자를 기준으로 지정한 css를 디자인 요소로 먹일 수 있다. 그 말은 css를 이용하여 차트 같은 걸 180도 회전하여 보여주는 것도 가능하다는 이야기다. BI 툴에서 제공하는 차트는 그 모양이나 생김새가 어느정도 정형화된 데이터를 표현하기 위해 고정된 부분이 있는데 그 한계를 넘어서는 요구사항도 어느정도 깰 수 있다. 실제로 180도 회전하는 기능을 이용하여 원래라면 구현 불가능했던 서로 마주보는 막대차트를 만든 적도 있었다.

이렇듯 스크립트와 css의 조합은 웹개발의 프로세스로 가능했던 자유도를 BI 툴에서 가능하게 한다. 다른 애플리케이션에서는 찾아보기 힘든 특이한 장점이라고 할 수 있다. 다만 이렇게 높은 자유도는 자연히 개발 난이도의 상승과 숙련 기술자의 부재, 로직 관리의 어려움으로 연결된다. 내가 요즘 루미라 로직 리팩토링을 수행하고 있는 이유도 이 때문이다.

루미라 리팩토링 1 - 빈 셀로 만든 테이블

현재 내가 운영을 맡고 있는 루미라 대시보드는 해도 너무한다는 말이 나올만큼 문제가 많았다. 가장 근본적인 문제는 데이터를 표시하는 테이블 객체가 테이블이 아니라 빈 셀이라는 점이다. 이게 어떤 의미인지 설명해보자면 일반적인 BI 툴의 경우 차원과 계수를 끌어다가 표시할 수 있는 테이블 객체를 제공한다. 아래 AO리포트 처럼 Business Partner를 배치하고 Order Quantity, Gross Order를 배치하면 자동으로 테이블을 그려주는 객체가 존재한다. 

루미라도 당연히 그런 테이블 객체가 존재한다. 하지만 지금 내가 운영하고 있는 대시보드는 그런 테이블 객체를 사용하지 않고 빈 셀 들을 테이블처럼 붙여놓아서 배치해두었다. 그리고 각각의 셀에 일일이 데이터를 뿌리고 있다. 이렇게하면 데이터 배치의 자유도는 무한정으로 높아진다. 멋대로 계산하고 뿌릴 수도 있고. 고객이 원하는 특이한 배치에도 문제없이 대응할 수 있다. 하지만 반대 급부로 데이터 정합성이 깨질 위험도 급상승하고 각각의 로직이 따로 노는 문제가 생길 수도 있다. 운영을 하는 입장에서는 운영할 거는 생각하지 않고 만든 무책임한 디자인이라고 밖에 할 수 없는 데이터 표현 방식이었다. 그리고 로직을 하나씩 따져보았을 때 테이블 객체를 사용하여 만들 수 없는 데이터 셋인가 하면 또 그렇지도 않다. 충분히 Cal View를 이용하여 쿼리를 잘 만들면 테이블 객체로도 충분히 데이터를 만들 수 있는 형태였다. 하지만 차마 이 셀 타입의 데이터를 테이블 객체로 바꾸어서 표현하는 식으로 리팩토링을 수행할 수는 없었다. 디자인적 요소의 문제도 있었고 혹시 모르는 쫓아가질 모를 로직이 있을지도 모른다는 생각에서였다.

 

루미라 리팩토링 2 - 부정확한 객체명

빈 셀들로 이루어진 테이블을 잘 관리하려면 각 셀들의 이름이라도 제대로 붙어 있어야 했다. 그래야 어떤 셀에 어떤 데이터가 들어가는지 분석이 가능할테니 말이다. 그런데 셀들의 이름이 _VAL1, VAL11,VAL222 이런 식었다. 일종의 좌표로 데이터를 구분하는 거라고 생각하면 어느정도 위치 파악은 되었지만 데이터를 세팅할 때쯤되면 이게 제대로 된 건지 안 된건지에 대한 확인이 어려웠다. 따라서 각 셀들의 명명을 다시했다. 참고로 테이블의 크기는 가로9 세로 35로 셀 갯수는 315개였다. 명명법은 해당 로우의 차원에 대한 의미가 담긴 접두어를 붙이고 담기는 데이터 타입으로 중간을 채우고 마지막 숫자로 컬럼 좌표를 표기하는 식으로 했다. 예를 들어서 국가 차원의 값이 독일이고 제품 차원의 값이 유리인 로우의 3번째 컬럼의 수치값이라면 DE_GLASS_VAL3이런 식으로였다. 315개 일일이 셀 이름을 부여하고 스크립트를 수정해나가기 시작했다. 스크립트는 스크립트 대로 문제였다.

 

루미라 리팩토링 3 - Don't Repeat Yourself

기존 스크립트 작성자는 루미라에 반복문이 존재하는 걸 몰랐던 게 분명하다. 펑션을 분리하여 해당 코드를 재사용할 수 있다는 것도 몰랐던 게 분명하다. 그게 아니면 설명이 되지 않는다. 개인적으로 코드 라인 수를 세어보지는 않았지만 코드 스크립트 자체를 100분의 1 이상 줄일 수 있었다고 자신한다. 루미라 스크립트에서 해야할 일을 나누어보자면

1. 데이터를 로드하고 필터링을 건다.

2. 데이터를 변수에 담는다. 변수를 이용하여 비율 등의 추가 계산을 수행한다.

3. 변수에 담긴 데이터를 표현 객체에 담는다.

4. 버튼 클릭, 검색 등의 이벤트에 대응하여 1,2,3을 수행할 수 있도록 한다.

 

정도로 나눌 수 있다. 반복문을 사용하지 않았던 이전 스크립트에서는 거의 로직이 동일한 데이터를 변수에 담고 계산하는 일을 각각의 로우마다 일일이 수행하고 있었다. 변수에 담긴 데이터를 객체에 담는 것도 모두 반복작업인데 그걸 일일이 수행하고 있었다. 35개의 로우를 그렇게 반복 수행하여 채우고 있었다. 다른 건 몰라도 이건 너무 개발의 기본에서 벗어난 일이었기에 비판적인 생각이 든다. 자신이 개발자라는 자각이 있기는 했던걸까라는 생각이 드는 부분이었다.

 

나는 우선 반복문을 사용하면서 로드된 데이터에서 데이터를 뽑아 변수에 담는 작업을 수행하였다. 분기가 될 수 있는 차원1,2를 각각 리스트에 담고 이중 for문을 썼다. 수량 데이터를 가져올지 금액 데이터를 가져올지에 대한 필터링 분기도 필요하였기에 해당 변수를 글로벌 변수로 선언하여 필터가 주어질 때마다 변경되어 반영될 수 있도록 하였다. 이중 for문이 돌면서 해당 데이터를 담을 수 있는 리스트 형태의 변수를 선언해 두었다. 당월 계획, 당월 목표, 당월 실적, 당월 달성률, 누계 목표, 누계 실적, 누계 달성률을 각각 계산하여 리스트에 담아서 7개의 값 리스트를 완성하였고 이 리스트도 반복문을 통하여 객체에 할당하였다. 객체들도 객체 리스트에 담아서 반복문 안에서 index값으로 위치를 잡고 데이터가 어긋나지 않게 할당하였다.

 

정리

여기까지가 내가 요 며칠동안 매달린 작업에 대한 정리이다. 이외에도 레이아웃을 수정 요청에 맞추어 수정하고 차트와의 데이터 연동, 쓸데없이 나누어진 쿼리의 통합 정리 과정 등의 작업을 수행하였다. 기존의 쿼리의 경우 다양한 테이블로부터 정리되지 않는채로 데이터를 가져와서 사용하는 부분이 있었고 이에 쿼리의 수가 10개가 넘어갔으나 소스가 다른 데이터들을 하나의 Cal View로 정리하여 가져올 수 있도록 하여 테이블, 차트1, 차트2, 차트3에 대응하는 4개의 쿼리만 가져올 수 있도록 수정하였다. 리팩토링 과정이 생각보다 길고 복잡해져서 힘든 부분이 있지만 그래도 프로그램 자체가 정리되어 가고 있는 데서는 뿌듯함이 느껴진다. 내일까지 힘내서 마무리 지을 수 있도록 하고 싶다.