현대화 프로젝트를 진행하면서 기존에 사용하던 MyBatis 기반의 시스템을 JPA 기반으로 전환하게 되었다.
이 과정에서 가장 먼저 발생한 문제는 Entity 클래스의 대량 생성이다.
기존 시스템은 테이블 정보가 Dataware에 잘 명시되어 있었지만, 이를 기반으로 매번 수작업으로 Java Entity 클래스를 생성하는 것은 비효율적이라고 생각했다.
수천 개에 이르는 테이블 정보를 일일이 열람하고, 이에 맞는 Java 클래스를 작성한다는 것은 단순 반복 작업일 뿐만 아니라 많은 비용이 소모된다고 생각했다.
게다가 Oracle의 데이터 타입과 Java의 데이터 타입 간 매핑 기준이 명확하지 않아, 매번 다음과 같은 고민이 뒤따랐다.
- Number(10)은 Integer로 두는게 맞을까? Long 로 두는게 맞을까?
- Number (10, 2)은 Double로 두는게 맞을까? BigDecimal로 두는게 맞을까?
- Date는 LocalDate가 맞을까, LocalDateTime으로 처리할 것인가?
이러한 고민들은 코드 일관성을 해치는 요인이라 생각했고, Entity 클래스 생성을 자동화 할 수 있다면 많은 시간을 절약함과 동시에 팀 내에서 데이터 타입 매핑 기준을 명확히 정립할 수 있다고 판단했다.
그래서 JavaParser를 활용해 Entity 클래스를 자동으로 생성하는 프로그램을 구축하게 되었다.
JavaParser란?
JavaParser - Home
Amazing stats The most popular parser for the Java language When choosing open source technologies it is important to know your choice will be rewarded by continuous support. The JavaParser community is vibrant and active, with a weekly release cadence tha
javaparser.org
JavaParser는 Java 소스 코드를 파싱하고, 분석하거나 수정 및 생성할 수 있는 오픈소스 라이브러리이다. 내부적으로는 Java 코드를 추상 구문 트리(AST, Abstract Syntax Tree) 형태로 변환해, 마치 JSON이나 XML을 다루듯 Java 코드를 구조적으로 접근할 수 있게 해준다.
해당 라이브러리를 활용해 Oracle테이블 정보를 기반으로 Entity 클래스를 자동 생성하며, Thymeleaf 기반의 웹 UI를 통해 사용자가 원하는 테이블을 선택하고, 선택한 테이블들의 Entity 클래스 파일을 압축(zip) 형태로 다운로드할 수 있도록 설계했다.
기존 단일 프로젝트를 MSA 기반으로 점진적으로 분리해 나가는 과정에서, 각 팀이 사용하는 테이블 범위가 서로 달랐다.
이에 따라 각 팀이 필요에 따라 웹 페이지(Thymeleaf 기반)에서 Oracle에 존재하는 테이블 목록을 조회하고, 원하는 테이블을 선택할 수 있도록 구성했다.
해당 테이블 목록 조회는 다음의 쿼리를 활용했다
Oracle 시스템 뷰인 ALL_TAB_COMMENTS 로, 사용자가 접근 가능한 모든 테이블, 뷰, 컬럼의 주석 정보를 담고 있다.
해당 뷰를 이용해 특정 스키마(:schema)에 존재하는 모든 테이블의 이름과 주석(Comment) 을 조회하는 쿼리다.
사용자가 대상 Entity를 선택한 후 Parser 버튼을 누르면 웹페이지에서 Zip 파일을 다운로드 할 수 있으며, 아래와 같은 그림을 확인할 수 있다.
해당 클래스 파일의 내부는 JavaParser 에서 제공하는 CompilationUnit 객체를 활용하여 임의대로 Import, Annotation, Filed, Constructure, Extend Entity등 자유롭게 제공할 수 있다.
다음은 JavaParser를 활용한 소스 코드에 대한 설명이다.
이 코드는 CompilationUnit을 이용해 테이블 정보를 기반으로 Java Entity 클래스를 자동으로 만들어주는 기능을 한다. 테이블 이름을 받아 그에 맞는 클래스를 생성하고, 여기에 @Getter, @Setter, @NoArgsConstructor 같은 Lombok 애너테이션을 붙여, 반복적인 getter/setter 작성이나 생성자 정의 없이도 사용할 수 있게 했다.
실제 필드 정의는 테이블에서 가져온 메타데이터를 참고해서 생성되며, 각 필드에는 컬럼 설명이 주석으로 달려 있어 클래스만 보고도 어떤 역할을 하는지 쉽게 알 수 있도록 구성했으며, 컬럼 타입 중 LocalDateTime과 같이 Java의 특정 타입이 필요한 경우엔 자동으로 해당 import 구문도 함께 추가되도록 처리했다.
이전에는 JPA로 전환하는 과정에서 가장 부담이 컸던 부분이 바로 수많은 Entity 클래스를 일일이 사람이 작성해야 했다는 점이었다. 테이블 수가 수천 개에 달하다 보니, 단순히 스키마를 확인하고 필드명을 옮겨 적고, 타입을 매핑하는 반복 작업만으로도 몇 주 이상의 시간이 필요했다.
게다가 사람이 직접 옮기는 과정이다 보니 타입 실수, 필드 누락같은 사소하지만 치명적인 오류가 잦았다. 해당 오류를 코드 리뷰 단계에서 다시 잡아내야 했고, 이 역시 불필요한 리소스를 소모하게 만들었다.
해당 프로그램을 구축함으로써 95% 이상 시간을 단축을 체감했으며, 매핑 기준을 사전에 정의해 두었기에 사람에 따라 달라지는 매핑 편차를 사라지게 할 수 있었다.
JPA 전환 작업을 하고 있는 팀 혹은 개인에게 많은 도움이 되길 바라며, Source Code는 아래 링크를 참고하면 된다.
https://github.com/junxtar/automate-entities
'Spring' 카테고리의 다른 글
Spring Boot에서 성능 저하를 유발하는 DataSource 설정 (1) | 2025.05.08 |
---|---|
스프링 vs 스프링 부트 (1) | 2023.06.07 |
application.properties과 application.yml 차이 (1) | 2023.02.06 |
[Spring] 빌드 관리 도구 메이븐(Maven)과 그래들(Gradle) (1) | 2023.01.11 |