CMS (컨텐츠 관리 시스템) 설계 및 개발

1. 프로젝트 개요

  • 개발 기간: 2022. 06 ~ 2022. 07 (2개월)
  • 개발 인원: 총 6명 (백엔드 2명, 프론트 2명, UI/UX 1명, QA 1명)
  • 담당 역할:
    • 백엔드 개발 리드 및 시스템 설계 (50%)
    • 백엔드 API 개발 (70%)
    • 멀티 모듈 및 클린 아키텍처 기반 프로젝트 환경 구성 (100%)
    • 문서화 (회의록, API 스펙, 기술 문서 등) (70%)

2. 기술 스택

  • Language & Framework: Java 17, Spring Boot 2.7
  • Database: MySQL 8 (JSON 데이터 타입 활용), Redis Cache
  • Library: JPA, QueryDSL, Spring Batch
  • Infra & Tool: ArgoCD, IntelliJ IDEA 2021

3. 배경 및 필요성

  • 기존 홈 화면 관리가 프론트엔드 하드코딩 방식으로 되어 있어 확장성과 유지보수성이 낮고 개발 속도가 저하되는 이슈가 있었습니다.
  • 더욱 다양하고 유연한 모듈 단위로 홈 화면을 자유롭게 구성할 수 있는 시스템 구축이 필요했습니다.

4. 어려웠던 점 및 해결 방안

  • 다양한 컨텐츠 유형 대응:
    • 상품, 이미지, 타임딜 등 다양한 유형의 컨텐츠를 유연하게 관리 및 처리해야 했습니다.
    • 해결: 확장성을 크게 높이기 위해 컨텐츠 데이터를 JSON 형태로 저장하도록 시스템을 설계했고, @JsonType과 MySQL의 JSON 타입을 효과적으로 활용했습니다.
  • 인력 공백 발생:
    • 협업하던 다른 백엔드 개발자 분의 신혼여행으로 인해 개발 공백이 발생했습니다.
    • 해결: 제한된 시간을 최대한 밀도 있게 사용하기 위해 '오전 소통, 오후 집중 개발' 이라는 전략적 루틴을 세워 무사히 혼자서 소통과 메인 개발 업무를 병행했습니다.

5. 아쉬웠던 점

  • 기술적 측면:
    • 캐시 단위 설정 오류: 초기에 전체 데이터를 한 번에 캐싱하는 단일 키 방식으로 설계하여, 리프레시 시 타임아웃이 간헐적으로 발생했습니다. 이후 진행된 스타일 서비스 프로젝트에서는 이를 교훈 삼아 개별 단위 캐싱 방식으로 개선했습니다.
    • ID 체계: 식별자로 순수 UUID만을 사용하여 로그 트래킹 및 유지보수가 꽤 번거로웠습니다. Sequential ID와 병행하는 것이 운영상 훨씬 더 효율적이었을 것이라 판단합니다.
  • 협업 측면:
    • 불명확한 요구사항: 프로젝트 초기 플래닝 단계에서 기획 스펙 및 요구사항이 다소 명확하지 않아 결국 개발팀 측에서 기획서를 역으로 재정리해야 하는 리소스 낭비가 있었습니다.
    • 우선순위 부재: 기능별로 필수(Mandatory) 요건과 선택(Optional) 요건에 대한 명확한 구분이 미흡해 일정 산출 및 관리에 아쉬움이 남았습니다.

6. 좋았던 점

  • 커뮤니케이션 프로세스 개선: 백엔드와 프론트엔드 개발자들만의 전용 슬랙 채널을 별도로 운영하여 의사소통 비용을 낮추고 팀워크를 강화했습니다. 이를 통해 대기 시간을 최소화하고 전반적인 업무 효율을 대폭 향상시켰습니다.

7. 주요 성과 (성능 개선 지표)

  • 시스템 설계 확장성: 도입 후 시스템이 처리 가능한 홈 화면 컨텐츠 유형이 2개에서 6개로 유연하게 확장되었습니다.
  • 프론트엔드 브라우저 렌더링 성능 향상:
    • Speed Index (SI): 5.0s → 3.5s (30% 감소)
    • Time to Interactive (TTI): 6.5s → 6.0s (8% 감소)
    • Largest Contentful Paint (LCP): 6.8s → 6.3s (7% 감소)
    • Total Blocking Time (TBT): 0.8s → 0.6s (25% 감소)


(원문 출처: https://kdohyeon.tistory.com/75 [대니기록:티스토리])