반응형
Spring Boot로 넘어가기 전, 현재 운영 중인 레거시(Spring Framework 기반) 프로젝트를 정확히 이해하고 진단하는 것은 매우 중요합니다. 이 글에서는 마이그레이션에 앞서 현재 프로젝트의 기술 스택, 구조, 문제점 등을 상세히 분석하고자 합니다.
기존 프로젝트 개요. : 마이그레이션 전 진단 보고서
- 프로젝트 목적: 레시피 게시판 서비스를 제공하는 웹 애플리케이션
- 사용자: 웹(PC), Flutter 기반 모바일 클라이언트에서 REST API 호출
- 주요 기능: 게시글 CRUD, 이미지 업로드, 댓글, 좋아요 기능 등
기존 기술 스택 요약
| 구분 | 기술 |
|---|---|
| 백엔드 프레임워크 | Spring Framework (4.x) |
| 템플릿 엔진 | JSP + JSTL |
| ORM/DB 연동 | MyBatis + XML 기반 SQL Mapper |
| DBMS | MariaDB (Docker 기반) |
| 서버 배포 방식 | WAR 패키징 → 외부 Tomcat 배포 |
| 설정 방식 | web.xml + dispatcher-servlet.xml + context-*.xml |
레이어 구조 및 패키지 구성
전형적인 MVC 패턴 기반으로 다음과 같이 계층이 분리되어 있음:
controller: @Controller 기반 클래스, 요청/응답 처리service: 비즈니스 로직 담당, 트랜잭션 처리dao또는mapper: SqlSession 사용 또는 @Mapper 인터페이스로 SQL 실행model,domain: DTO / VO 객체view: /WEB-INF/views/ 하위의 JSP 파일들
정적 자원(css/js 등)은 /resources/ 혹은 /static/에 위치
주요 설정 구성(XML 기반)
- web.xml: DispatcherServlet 등록, 인코딩 필터, ContextLoaderListener
- dispatcher-servlet.xml: ViewResolver, component-scan, 메시지 리졸버 등
- context-datasource.xml: DB 연결 정보, DBCP(DataSource) 설정
- context-mybatis.xml: SqlSessionFactory, MapperScanner 설정
- context-transaction.xml: 트랜잭션 매니저 설정
문제점 및 한계 분석
| 항목 | 문제점 |
|---|---|
| 설정 복잡도 | 여러 개의 XML 파일로 설정 분산 → 유지보수 어려움 |
| 뷰 기술 | JSP는 유지보수가 어렵고, 현대적 프론트엔드와 분리 불리 |
| ORM/SQL 관리 | MyBatis XML 방식은 SQL 분리 장점 있지만 중복 증가 |
| 의존성 관리 | XML 기반 DI 설정으로 코드 흐름 파악 어려움 |
| 배포 방식 | WAR 패키징 후 외부 톰캣에 복사 → 자동화 어려움 |
| 테스트 | 레거시 환경에서는 테스트 코드 기반 개발이 어려움 |
마이그레이션 목표 정의
| 전환 대상 | 변경 내용 |
|---|---|
| Spring Framework → Spring Boot | 자동 설정, 내장 톰캣, 단일 설정 파일로 전환 |
| MyBatis → Spring Data JPA | Entity 기반 도메인 모델링, SQL 최소화 |
| JSP → Thymeleaf | HTML5 기반 템플릿으로 가독성 및 유지보수 향상 |
| XML 설정 → Java Config / application.yml | 설정 중앙 집중화, 가독성 향상 |
| WAR → JAR (또는 유지) | 내부 실행 방식으로 변경 또는 WAR 유지 (선택적) |
정리
Spring Boot로의 마이그레이션은 단순한 기술 스택 교체가 아니라, 유지보수성과 확장성을 고려한 구조적 재설계입니다. 이 분석을 통해 기존 문제점을 명확히 인식하고, 이후 단계에서 어떤 기준으로 전환할 것인지 분명히 할 수 있습니다.
다음 포스트에서는 Spring Boot 프로젝트를 생성하고 WAR 구조를 구성하는 방법부터 실습해보겠습니다.
반응형
