디지털 아카이브 시스템 고도화 후기

개요

• 프로젝트 목적 : 기존 MCMS에 로그인 연계 기능 추가. 마이페이지와 통계 기능을 추가.
• 프로젝트 기간 : 2023년 5월 26일 ~ 2023년 9월 26일
• 프로젝트 인원 : 2명
• 기술 스택 : 자바, 스프링 프레임워크 (전자정부 프레임워크 3.5.0), JSP(관리자 페이지의 경우), vue.js(사용자 페이지의 경우), Mybatis, MariaDB
• 핵심 키워드 : 기획, 통계, 배포, Mybatis

 해당 프로젝트는 5월 2일에 입사한 내가 맡은 최초의 프로젝트이다.

기존 프로젝트에 로그인 기능과 마이페이지 (히스토리, 북마크) 기능, 통계 기능이 추가된 간단한 고도화였기에 2년차 중간이 된 사수와 막 입사한 내가 해당 프로젝트를 맡아서 진행하게 되었다. 기간이 좀 긴데, 고도화 프로젝트의 사업 기간이 길었기에 중간에 회사의 내부 모듈을 개발하는 시간과 여름 휴가 기간, Paas-Ta 응시 기간이 포함되어 그렇지 실질적인 프로젝트 기간은 2달쯤이다. 내가 프로젝트를 하면서 깨달은 점들을 공유하고 싶어 글을 작성하게 되었다.

 

MCMS란?

:  'Media Contents Management System'의 약자로 미디어 컨텐츠(기록물)를 관리하는 아카이브를 의미한다. 아카이브 사이트와 어드민 사이트가 하나의 세트이다. 관리자는 기록물을 저장하고 관리하며 아카이브 사이트에서 저장된 기록물을 조회할 수 있었다. 기능을 말로만 설명하면 굉장히 간단해 보이지만 막상 하나의 기록물 테이블에 수많은 연관 테이블이 있고 외에도 테이블 관계가 복잡하기에 처음에 프로젝트를 분석하는데에 애를 먹었던 기억이 있다. 타 부서의 솔루션이지만 우리 팀에서 유지보수 및 고도화를 맡게 되었다.

 

깨달은 점?

1. 기획

 프로젝트를 맡고 처음에 한 일은 제안 요청서에 맞는 화면 설계였다. 우리 팀에서는 내가 처음 입사했을 때부터 기획과 설계의 중요성을 강조했고 사수와 내게 해당 고도화 사업을 맡아서 스토리 보드를 그려보라고 하였다. 스토리 보드를 그리기 위해 사수와 함께 머리를 맞대고 어떤 버튼은 어디에 있어야할까, 이 기능은 어떤 화면이 필요할까 상의하면서 하루를 보냈었다. 피그마로 그린 스토리보드를 PL에게 가져갈 때마다 부족한 점을 짚어주셨고 사용자 친화적인 설계에 대해서 고민할 수 있었다. 실제로 프로젝트 회의로 PL과 함께 클라이언트를 만나서 이야기할 때, PL이 먼저 짚은 내용들을 클라이언트가 원하는 것을 보고 개발도 개발이지만 기획자로서 공부가 필요하겠다는 생각을 했던 계기가 되었다.

 

2. 통계

 통계를 만들어 보라고 했지만 사실 아무런 지식이 없이 시작했다. 처음에 사수는 통계는 batch(이후 배치)로 만드는 것이라고 했지만 막상 이야기를 해보니 사수도 그 부분에 대해서 자세히 아는 것은 아니었고 당시에는 우리는 조회 속도와 효율성만 생각했기에 같이 이야기를 해보면 할수록 '그럴거면 그냥 요청할 때마다 쿼리 한번에 조회하는 것이 낫지 않은가?'라는 결론만 나왔다. 차장님께 생각한 것이 맞는가 자문을 구했고 차장님은 이야기를 듣고 완전히 틀렸다며 통계에 대해서 설명해주셨다. 

 차장님이 말씀해주신 이야기를 요약하면,

1. 통계는 과거의 데이터를 들여다보는 것이기에 무조건 배치를 돌려야한다. 값이 추가되거나 삭제되어 조회할 때마다 값이 변경되면 클라이언트가 정확한 값을 요구했을 때 데이터가 틀어질 수 있다.
2. 통계 데이터의 기준을 잡아놓는 것은 매우 중요하다. 다른 통계에 같은 항목이 있다면 그 데이터는 동일해야한다.
3. 쿼리는 최대한 간단하게. 유지보수와 검증을 위해서는 쿼리는 최대한 간단해야한다.
4. 통계마다 테이블이 존재해야한다. 원본(raw data)를 담는 이력 테이블, 그걸 통해서 집계를 내는 집계 테이블을 만들어야한다. 즉, 이력 > 집계 > 통계 과정을 거치게 되며 프론트엔드 개발자는 집계 테이블만 보고도 통계 개발이 가능하기 때문에 프론트엔드 백엔드 구분해서 작업할 때 더욱 효과적이다.
5. 최대한 많은 데이터를 테이블에 남겨두자
6. 검증 데이터를 만들어 두자

등이 있으며 해당 내용은 따로 정리하여 해당 블로그에 작성할 예정이다. 조언을 듣고 난 뒤 작업은 일사천리로 진행되었고 추후 PL의 의견에 따라 일부 통계를 실시간 조회로 변경하게 되었지만 (클라이언트가 요구하는 것은 최신 데이터이며 과거의 데이터와 달라져도 상관 없다) 통계에 대해서 많이 배울 수 있었던 시간이었다.

 

3. 배포

  진로를 개발자로 정하기 전에 오픈 소스 클라우드를 설치하기 위해서 우분투를 깔아본 거 외엔 배포 경험은 없었지만 회사에서는 어느 정도의 리눅스 실력을 요구했고 해당 프로젝트를 진행하면서 처음으로 배포해볼 수 있었다. 먼저 테스트 서버에 작업을 했는데 폐쇄망은 아니었지만 우리 팀에서 지정한 버전과 설치 경로를 맞추기 위해 apt-get install가 아닌 직접 파일을 넣어서 설치했다. 인터넷을 에서 설치 방법을 검색해가며 하나씩 설치했고 추후 유지보수 때 사용할 수 있게 해당 내용을 yona에 정리해두었다. 운영에 배포하는 것은 클라우드를 사용했고 나는 다른 프로젝트로 넘어가서 아쉽게도 직접 하지는 못 했다.

 

4. Mybatis

통계 같은 복잡한 쿼리가 필요할 때는 JPA보다 Mybatis를 사용하는 것이 권장된다. JPA는 Mybatis에 비해 프로젝트를 좀더 객체지향적으로 코드를 짤 수 있게 도와주지만 이런 케이스에 JPA를 도입했다가는 엄청나게 길고 복잡한 코드를 보게 될 것이다. 통계 파트는 sql문 작성할 때 방향성 때문에 코드도 계속 고치고 정말 많은 고민을 했지만 차장님의 조언에 따라 통계에 필요한 테이블과 칼럼을 정리한 뒤에 다시 작성해보니 수월하게 해결할 수 있었다.

 

후기

회사에서 진행한 첫번째 프로젝트기도 하고 기획 단계서부터 참가하여 클라이언트 회의 때도 동행했기에 정말 기억에 많이 남는 프로젝트였다. 4가지 키워드로 깨달은 점을 정리했는데 사실 그것보다 개발자로서 필요한게 개발 실력만이 아니라는 것이 가장 크게 와닿았었다. 또한, vue.js가 주는 편리함을 제대로 느꼈던 프로젝트기도 하다. 팀의 대부분의 프로젝트는 vue.js를 사용하고 있지만 해당 프로젝트의 어드민 페이지는 jsp를 사용하고 있었기에 ssr(서버 사이드 렌더링)과 csr(클라이언트 사이드 렌더링)의 차이, spa의 특성 등을 깨달을 수 있는 계기가 되었다.