개발자의 꿈을 이루고 개발자가 되었지만 개발 업무 외에도 해야 할 일들이 상당히 많았습니다. 사회생활을 하면서 가장 많이 하게 되는 작업이 문서를 만드는 일이었습니다. 저는 좋아하는 개발을 많이 해서 좋은 프로그램을 만들고 싶었지만 실상은 문서 작업에 할애되는 시간이 상당히 많았습니다.
장애가 발생하면 장애 보고서를 써야 했고, 배포를 하기 위해서는 배포를 위한 작업 계획서를 써야 했으며, 업무를 진행하기 위해서는 업무 보고서를 써야 했습니다. 그 외에도 다양한 양식의 보고서를 작성해야 했죠.
구직 사이트 사람인에서 진행한 설문조사에 따르면, 직장인이 상사에게 보고하기 위해 문서를 만드는 일이 업무의 1/3 정도 차지한다고 합니다. 그리고 직장인 70%가 보고서를 쓰는 일에 많은 스트레스를 받는다고 답했습니다. 그만큼 보고서가 중요하고 만드는 데에 많은 시간이 든다는 겁니다.
제가 와탭랩스에 입사하여 처음 받은 업무가 보고서를 개편했으면 한다는 요건이었습니다. 저는 다년간의 사회생활로 문서 작업도 많이 해 보았고, 중요성도 알고 있었기 때문에 보고서를 제대로 만들어 보기로 결심했습니다. 그래서 아래와 같은 절차를 거쳐 보고서에 대한 분석과 설계를 해 보았습니다.
[STEP 1] As-Is 보고서 분석
기존 보고서에 어떤 것들이 있는지 조사했고, 보고서를 만드는 과정과 개발에 드는 소요시간을 조사해 보았습니다. 보고서는 APM 보고서와 SERVER 보고서가 있었고, 각각 일간, 주간, 월간 보고서와 몇 개의 Custom 보고서가 존재했습니다.
[STEP 2] As-Is 보고서 개발 방법 분석
- 1. 보고서를 만들 때 사용될 데이터가 있는지 확인한다.
- A. 서버 파트 – 고객이 원하는 데이터를 뽑을 수 있는지 확인한다.
- 2. 고객이 원하는 형태를 구현할 수 있는지 확인한다.
- A. Front 파트 – Table 형태, Chart 형태가 구현 가능한지 확인한다.
- 3. (1)에서 OK가 되면 서버 파트에서 먼저 관련 데이터를 보여 줄 수 있는 API를 개발한다.
- 4. API를 Front 파트에 전달하고 Front 파트에서 페이지를 개발한다.
- 5. 개발이 완료되면 화면 메뉴에 관련 보고서 메뉴를 추가한다.
- 6. 서버와 Front 모두 배포한다.
보고서 메뉴 하나를 추가하고 배포까지 기다리면 근 한 달의 시간이 소요되었습니다. 아무래도 한 달은 너무 긴 시간이다 보니 이렇게 해서는 고객의 마음을 사로잡을 수 없겠다 생각했습니다.
[AS-IS 보고서]그래서 저는 아래와 같이 보고서를 새롭게 설계하기로 했습니다.
[STEP 3] 신규 보고서 설계
1. 프로젝트별로 메뉴 List가 달라질 수 있어야 한다.
A. 특정 고객사가 요청한 보고서가 공용적으로 사용될 수도 있겠지만, 특화된 보고서일 수도있으니 각 프로젝트별로 메뉴를 넣고 빼고 할 수 있으면 좋겠다고 생각했습니다.
2. 서버에서 CSS 와 HTML을 사용하여 HTML 페이지를 만들면 어떨까?
A. 데이터를 잘 알고 있는 서버 파트에서 데이터 단위까지도 신경 써 HTML을 만들어 보내면, Front 개발자와의 커뮤니케이션도 줄고 그만큼 업무 효율이 올라갈 것이라는 생각이들었습니다.
3. 위의 2번이 되면 JavaScript를 사용하여 간단한 차트도 그릴 수 있지 않을까?
A. 보고서 하면 차트가 빠질 수 없겠죠? 하지만 과연 서버에서 String으로 전달되는 데이터가 화면에서 잘 동작할지 의문이었습니다.
4. 다국어 지원은 먼저 한글과 영어 두 개만 지원하자.
A. 아직은 한글과 영어로 충분할 것으로 보였고, 추후 일본어나 중국어를 추가하려고 생각했습니다.
5. 보고서 개발은 되도록 수집 서버에 종속적이지 않은 방식으로 외부 JAR를 읽는다면 동적으로 보고서 배포할 수 있을 텐데, 가능할까?
A. 사실 이게 핵심 기능입니다. 아무래도 보고서 때문에 서버를 내린다? 그리고 보고서 개발이 너무 오래 걸린다? 이런 제약을 없애고 싶었고 고객이 필요한 부분을 빠르게 대처할 수 있으면 좋겠다고 생각했습니다.
사실 저도 남들과 마찬가지로 일반적인 JAVA 개발자였습니다. 대체로 고객이 쓰는 데이터를 DB에 저장하고 저장된 데이터를 보여주기 위한 API를 만들고, 부하가 많으면 쿼리 튜닝을 하고 아니면 데이터 캐싱을 통한 성능 최적화 작업을 하고… 현재 개발자라면 어느 정도 느낌이 오실 겁니다.
하지만 이건 제가 해 보지 않았던 개발 영역이라 어떻게 해야 할지 처음에는 막막했습니다. 그래도 손놓고 있으면 그건 월급루팡(?)이겠죠? 그래도 경력직인데 한번 보여주자 결심하고 중요한 기능 테스트부터 하기 시작했습니다.
[STEP 4] 기능 테스트 시작
[1] 첫 번째 테스트: 수집 서버에서 주는 자체 CSS와 HTML을 받아 Front 화면 특정 공간에 제대로 그려지는가?
- 작업 순서 –
1. Front 개발자를 통해 기능 테스트를 위한 페이지 개발을 요청합니다. 그리고 element.innerHTML 속성을 사용하여 서버 API를 통해 받은 데이터를 넣을 수 있도록 개발을 요청합니다.
2. CSS와 HTML 문법을 사용하여 간단한 Table 형식의 데이터를 생성합니다.
3. 생성된 데이터를 Content-Type을 text/html 형태로 전송하는 API를 개발합니다.
두근두근 개발이 완료되어 이제 클릭만 하면 결과를 알 수 있는데… 과연 성공했을까요? 결과를 말씀드리면 70% 정도 성공했습니다. 제가 고려하지 못한 점이 있었습니다. 그 부분은 기존에 와탭 프론트에서 사용 중인 CSS였습니다. 중복적인 CSS로 인해 제가 생각한 대로 Table이 그려지지 않고 스타일이 깨져서 보였습니다.
- 해결 포인트 -
CSS를 만들 때 보고서용 CSS를 따로 만들고 이름도 “pluginReport”라는 이름을 포함시켜 중복되지 않도록 따로 만들었습니다.
[2] 두 번째 테스트: HTML이 표현되는 걸 확인했으니 JavaScript 문법도 포함시켜서 Chart를 그려 보기로 했습니다.
[간단한 라인차트]- 작업 순서 –
