데브허브 | DEVHUB | 엉망진창 DB 개선 전략 feat. 레거시를 남기고 도망친 개발자....엉망진창 DB 개선 전략 feat. 레거시를 남기고 도망친 개발자....
- 엉망진창 DB 문제: 테이블명이
QU10203040과 같이 의미 불명확하고, 컬럼명도 CU1, CU2 등 약자로 되어 있어 가독성이 극도로 낮음. 🤯
- 최악의 상황: DB뿐만 아니라 코드 역시 JDBC 템플릿으로 직접 쿼리하고,
if문으로 비즈니스 로직이 뒤섞여 있으며, SELECT *로 불필요한 데이터를 가져오는 등 총체적 난국. 💥
- DB 직접 개선의 어려움: 이미 "요단강을 건넌" 상태로, DB 테이블명이나 컬럼명을 직접 개선하는 것은 매우 힘들고 비효율적이며, 사실상 불가능에 가까움. 🚧
- 코드 기반 개선 전략: DB 자체를 건드리기보다, DB와 상호작용하는 코드 레벨에서 먼저 접근하여 개선하는 것이 핵심. 💻
- 레이어 도입 및 복잡성 숨기기:
Repository와 같은 추상화 레이어를 만들어 지저분한 DB 쿼리와 테이블명이 애플리케이션 코드 상위 계층으로 노출되지 않도록 격리. 🛡️
- 의미 있는 타입 정의: 실제 비즈니스 도메인을 반영하는
ProductType과 같은 의미 있는 클래스를 정의하여, 내부의 지저분한 DB 필드(예: CU1)를 깔끔한 속성으로 매핑. 🏷️
- 쿼리 영역 통합 및 정적 언어 활용: 모든 쿼리 로직을 한곳으로 모으고, 자바/코틀린과 같은 정적 언어의 컴파일 타임 검사를 활용하여 코드의 안정성을 확보. 🔍
- 점진적 개선: 한 번에 모든 것을 바꾸려 하기보다, 코드 레벨에서 조금씩 의미를 파악하고 정리해나가며 점진적으로 시스템을 개선. 🐢
- JPA 활용 가능성: JPA를 사용한다면 엔티티 매핑을 통해 지저분한 DB 구조를 코드 레벨에서 숨기는 데 유리할 수 있음. 🔗
- 궁극적 목표: 의미 있는 클래스를 최대한 많이 만들어 "쓰레기 같은" 테이블과 쿼리가 외부로 노출되지 않도록 수술한 후, DB 개선을 고려하는 단계로 나아감. 🩺