MCMS 웹 프로젝트 후기

출처: pixabay

개요

---

• 목적: mcms 사용자 사이트 구축
• 수행 기간: 2022년 11월 1일 ~ 2022년 12월 3일
• 수행 인원: 디자이너 1,  풀스택3
• 기술 스택: jsp, javascript, springframework, java, mybatis, mariaDB
• 협업 툴: svn

본래 해당 프로젝트는 후기를 작성하지 않으려 하였다. mcms는 관리자 사이트가 거의 모든 기능을 담당하고 사용자 페이지는 대부분 저장된 데이터들을 카테고리별로 분류하여 화면에 뿌려주기만 하면 되는 프로젝트였기 때문이다. 또한 대부분의 시간을 테이블 간의 관계 분석과 쿼리문을 짜는데 보내기도 했다. 그러나 해당 프로젝트에서 테스트 코드를 작성하며 느낀 테스트 코드의 중요성과 검색엔진을 도입하며 공부했던 것을 적용시켜보는 경험이 기억에 남아 후기를 통해 기록을 남기기로 하였다.

 

MCMS 란?

---

mcms는 Media Contents Management System의 약자로 미디어 컨텐츠(기록물)를 관리하는 아카이브다. 좀 더 풀어서 설명하자면 여러 가지 콘텐츠들을 기준별로 분류하여 관리하는 사진, 영상 콘텐츠/시청각기록물 관리 솔루션이다. 기록물을 컨텐츠별로 볼 수 있는 사용자 사이트와 기록물을 등록하고 관리하는 관리자 사이트로 구성된다. 

 

MCMS 프로젝트 담당 페이지

---

마이페이지
대표 이미지 변경, 프로필 수정, 비밀번호 변경

작품 관리 페이지
작품에 대한 기본적인 CRUD , 대표 이미지 자동 등록 및 수정, 콘텐츠(사진, 영상)에 대한 CRUD

통합 검색 페이지
검색엔진을 통해 데이터를 조회하고 화면에 바인딩

3명의 인원이 분담하여 작업했기에 생각보다 필자가 담당한 페이지가 많지 않았다. 그렇다고 프로젝트 기간이 여유로운 것은 아니었다. 관리할 수 있는 기록물과 분류가 다양한 덕에 테이블 관계가 꽤나 복잡했기 때문이다. 때문에 기존 mcms 프로젝트 소스 분석과 테이블 간의 관계 분석에 시간을 많이 할당하였다. 또한 필요한 쿼리문을 만드는데도 시간을 많이 썼다. 아이템을 CRUD 할 때마다 연계된 테이블이 많아 생각보다 많은 테이블에 작업을 해야 했었다.

 

프로젝트 일정 관리

---

일정 및 완료사항 공유

이슈사항 공유

프로젝트의 일정관리 및 이슈사항 공유는 구글 스프레드 시트를 사용하여 진행했었다. 서로의 개발 일정을 공유하고 개발이 먼저 끝난 팀원이 아직 일정을 완료하지 못한 팀원의 개발을 돕거나 개발이 완료된 페이지들을 미리 테스트하여 수정이 필요한 곳을 적어줬다. 오류 수정은 본인이 개발한 곳은 본인이 직접 하는 방식으로 진행했다. 본인이 작성한 코드를 본인이 가장 잘 알기에 다른 팀원들이 디버깅 및 수정하는 것보다 효율적이기 때문이었다. 물론 프로젝트 기간이 상당히 여유 있었던 것도 있었다.

테스트 코드

---

기존 mcms 프로젝트들은 작성된 테스트 코드가 없다. 때문에 기존 mcms 시스템을 분석할 때 어려움이 있었다. 눈으로 보며 분석할 수 있으나 작성된 코드를 실행해보며 검증하는 과정의 필요성을 느꼈다. 때문에 이번 mcms 프로젝트는 테스트 코드를 작성하였고 작성함으로 얻은 이점들과 느낀 점을 적어봤다.

아래 코드는 memberDAO 레이어의 비밀번호 변경 테스트 코드다. 특별한 내용은 없지만 회사 프로젝트에 사용한 코드를 그대로 올리는 것은 옳은 행동이 아니라 생각되어 몇몇 부분을 제거하고 변수 명도 다 변경한 상태다.

// @Transactional을 사용하여 실행된 결과를 롤백해준다.
@DisplayName("memberPasswordUpdate")
@Transactional
@Test
public void memberPasswordUpdate(){
    // Given
    long id = 0;
    String password = "secret";
    passwd = encryption(passwd, "secret");

    // When
    Integer resultRow = memberDAO.memberPasswordUpdate(id, password);

    // Then
    assertThat(resultRow).isEqualTo(1);
}

필자는 테스트 코드를 현업 프로젝트에서 작성하는 것은 이번이 처음이었다. 현업에 종사하는 수많은 선배 개발자들이 테스트 코드 작성을 중요시하고 강의와 블로그에서 필요성을 강조하기에 공부하고 토이 프로젝트에 적용해왔으나 중요성을 크게 느끼지는 못했었다. 그러나 이번 프로젝트를 통해 왜 필요한지 깨닫게 되었고 테스트 코드가 가져다준 이점들을 몇 가지 정리해봤다.

1. 웹 퍼블리싱 작업이 끝나지 않아도 기능 구현 후 검증이 가능하다.
2. 개발 종료 후 프로젝트 테스트 시 발생하는 오류를 좀 더 쉽게 찾고, 수정하고, 검증할 수 있다.
3. 테스트 코드를 통해 실패부터 성공까지 검증한 로직은 추후 에러가 발생할 확률이 크게 낮아진다.
4. 다른 동료가 작성한 로직에 문제가 생겼을 때 분석하고 수정 후 검증하기가 매우 편하다. 그 반대도 마찬가지다.

이번 mcms 프로젝트를 진행할 때 회사에 웹 퍼블리싱을 진행할 퍼블리셔의 숫자가 부족하여 퍼블리싱이 늦어졌다. 그러나 개발자가 프로젝트 마감시간이 다가오는데 가만히 있을수도 없었다. 그래서 테스트 코드를 작성함으로 문제를 해결했다. 작성한 서비스 로직과 쿼리문을 테스트 코드를 통해 미리 검증하였고 덕분에 수월하게 프로젝트를 진행할 수 있었다. 추후 테스트를 진행하며 생기는 오류들도 빠르게 수정할 수 있었고 웬만해서 테스트 코드를 통해 검증된 로직들은 문제가 발생하지 않았었다.

 

이미지 압축 및 리사이징

---

프로젝트 진행도중 메인 페이지에 올라가는 이미지를 원본 이미지로 잘못 뿌리는 일이 생겼고 메인 페이지 로딩 속도가 너무 느려 확인해봤더니 이미지가 원본 그대로 올라갔고 용량이 너무 커 화면을 그리는 시간이 오래 걸렸던 것이었다. 필자는 이미지 크기에 대한 중요성을 이번 프로젝트를 진행하며 알게 되었다.

필자가 회사에 처음 와서 진행했던 프로젝트는 iot프로젝트였다. iot 프로젝트는 장비에서 보내주는 데이터를 수집하고 실시간성으로 제어하는 것이 주된 목표인 프로젝트였다. 그렇기에 빠른 속도로 데이터를 수집하는 것, 실시간성, 정확성이 정말 중요했던 프로젝트였다. 그렇다 보니 이미지와 영상을 다뤄볼일이 거의 없었다. 가끔 사용하는 이미지도 이미 압축된 이미지를 제공받았기 때문이었다.

반면 mcms 프로젝트는 사진, 영상 콘텐츠/시청각기록물 관리 솔루션이기 때문에 많은 영상과 이미지를 저장하고 분류해야 했고 화면상에 많은 이미지와 영상을 띄워줘야 했다. 때문에 이미지 하나를 저장해도 원본, 관리자 페이지, 사용자 페이지, 썸네일 용으로 각 용도에 맞게 압축 및 리사이징을 하여 저장했다.

이미지를 압축하면 화질이 저하되지만 눈으로 보기에는 큰 차이를 느끼지 못한다. 아래는 비교 사진을 통해 비교해보자.

이미지 출처 : Pixabay

두 이미지의 크기 차이는 10배가 넘지만 눈으로 봤을때 화질 차이가 나는걸 필자는 느끼지 못했다. 이번에는 크기 차이가 가져다주는 속도의 영향력이 얼마나 큰지 확인해보자.

이미지에 표기되는 숫자도작고 화질이 좋지 않아 잘 보이지 않지만 이미지 압축 전에는 약 2500ms 라는 시간이 걸렸고 압축 후에는 약 250ms라는 시간이 걸리는걸 볼수있다. 둘의 테스트 환경은 동일하다. 메인 페이지에 5장의 이미지를 뿌려주면되는 상황이였다. 위에 보듯이 용량에 따른 화질에 차이는 거의 느끼지 못하지만 속도차이는 약10배 정도로 이 차이는 실제 웹페이지에서 크게 체감된다.

이번 프로젝트를 통해 이미지 사이즈에 대한 중요성을 알게 되었는데 이미지 압축과 리사이징이 언제 이루어지는 게 가장 좋은 걸까 라는 의문이 남았다. 게시물을 작성하며 텍스트 에디터에 이미지를 등록할 때, 게시물을 저장할 때 어느 순간 이루어져야 할까? 현재 회사에서는 게시물을 등록할 때에 이루어진다. 로딩 바가 있어서 변환 진행 현황을 확인할 수 있으나 느리다는 생각을 하였다. 사용자 입장에서 볼 때에 가장 자연스럽고 속도가 지연되지 않는다고 느끼려면 필자 생각에는 텍스트 에디터에 이미지를 올릴 때에 압축 작업이 이루어져 올라가는 방법이 괜찮은 것 같다. 압축이 되며 로딩 시간이 있겠지만 하나하나의 로딩 시간을 잠깐 기다리는 것과 여러 개가 로딩되는걸 한 번에 기다리는 건 다를 것 같다는 생각이 든다. 물론 해당 이미지를 사용하지 않고 다시 취소할 수도 있지만 말이다.

 

특수 사례 패턴 (외부 API를 대하는 방법)

---

2022.12.19 - [Apply/BACKEND] - 특수 사례 패턴 (외부 API를 대하는 방법)

 

마무리

---

아무런 기대가 없었던 mcms 프로젝트를 진행하며 많은 경험을 하게 되었다. 이미지 크기의 문제, 이론적으로만 필요성을 알고 있었던 테스트 코드의 중요성, 클린 코드를 읽으며 배웠던 외부 api를 대하는 방법 정말 많은 걸 배웠다. 또한 텍스트 에디터를 통해 이미지를 업로드할 때에 어느 순간에 이미지 압축작업이 이루어져야 하는지에 대한 생각을 해볼 수 있어서 좋았다. 이 부분에 대한 건 토이 프로젝트에 적용하며 테스트를 해봐야겠다. 개발자에 입장으로써는 한 번에 처리하는 것이 편하다고 느껴지나 사용자의 경험 측면에서 볼 때에 저장시간이 오래 걸리는 건 쾌적하지 못하겠다는 걸 느꼈다.

클린 코드를 읽고 언제 외부 api를 대하는 방법에 대하여 배운 것을 현업 프로젝트에 언제쯤 써먹어볼 수 있을까 고민했는데 이렇게 기회가 빨리 찾아올 줄은 몰랐다.

필자 개인적 소감으로 이번 프로젝트를 통해 배우고 공부했던걸 토대로 한층 더 성장했다고 생각되며, 다음번에 특수처리 클래스를 만들 때에는 지금은 알지 못하는 더 좋은 방법을 통해 훨씬 더 잘 만들 수 있지 않을까? 라는 기대감을 스스로에게 가져보며 마무리한다.

긴 글을 읽어주셔서 감사합니다ㅎㅎ.