앞선 두 편의 글에서 DDL-DSL 라이브러리의 개발 배경과 실제 구현에 대해 다루었습니다.
이번 마지막 편에서는 현재 라이브러리의 한계점을 분석하고, 이를 개선하기 위한 향후 개발 방향에 대해 포스팅하려 합니다.
현재 라이브러리의 한계점
1. 제한적인 DDL 지원
현재 DDL-DSL은 CREATE TABLE 문만을 지원합니다.
실제 데이터베이스 운영 환경에서는 테이블 생성 외에도 다양한 DDL 작업이 필요합니다:
- 테이블 구조 변경 (ALTER TABLE)
- 테이블 삭제 (DROP TABLE)
- 인덱스 관리 (CREATE/DROP INDEX)
- 뷰 관리 (CREATE/ALTER/DROP VIEW)
이러한 제한은 실제 프로덕션 환경에서 라이브러리의 활용도를 제한하는 요인이 됩니다.
2. 스키마 변경 관리의 부재
데이터베이스 스키마는 시간이 지남에 따라 진화합니다.
현재 라이브러리는 이러한 스키마의 변경 이력을 추적하거나 관리하는 기능을 제공하지 않습니다.
이는 다음과 같은 문제를 야기할 수 있습니다:
- 스키마 변경 이력 추적 불가
- 롤백 메커니즘 부재
- 협업 환경에서의 스키마 동기화 어려움
3. 데이터베이스 벤더 지원의 한계
현재는 SQLite만을 완벽하게 지원하고 있으며, 다른 데이터베이스 시스템에 대한 지원은 제한적입니다.
특히 각 데이터베이스 벤더별 특수한 기능들(예: PostgreSQL의 JSONB 타입, MySQL의 전문 검색 인덱스 등)을 활용할 수 없는 상황입니다.
향후 개발 방향
1. 마이그레이션 시스템 도입
가장 시급한 개선 사항은 마이그레이션 시스템의 도입입니다.
다음과 같은 기능을 구현할 예정입니다:
// 예시 코드
Migration.create(version = 1, description = "202402010001_add_user_table") {
up {
createTable("users") {
// 테이블 정의
}
}
down {
dropTable("users")
}
}
이를 통해 다음과 같은 이점을 얻을 수 있습니다:
- 버전 관리된 스키마 변경
- 양방향 마이그레이션 지원 (up/down)
- 마이그레이션 실행 이력 관리
2. ALTER TABLE 지원 확장
테이블 구조 변경을 위한 완벽한 DSL 지원을 구현할 예정입니다:
TableDefinition.alter("users") {
addColumn("last_login", ColumnType.TimeStamp) {
nullable(true)
default(DateTimeType.Now)
}
modifyColumn("email") {
unique(true)
}
dropColumn("temporary_field")
}
3. 데이터베이스 벤더별 최적화
각 데이터베이스 시스템의 고유한 기능을 활용할 수 있도록 확장할 예정입니다:
- MS SQL Server의 Identity 속성 지원
- PostgreSQL의 고급 데이터 타입 지원
- MySQL의 특수 인덱스 타입 지원
// PostgreSQL 특화 기능 예시
TableDefinition.create("documents") {
column("content", PostgresColumnType.JSONB) {
index(IndexType.GIN) // PostgreSQL의 GIN 인덱스 지원
}
}
4. 안전한 스키마 변경 메커니즘
스키마 변경 시 데이터 손실을 방지하기 위한 안전장치를 구현할 예정입니다:
- 변경 전 스키마 백업
- 데이터 마이그레이션 검증
- 롤백 트리거 포인트 설정
결론
DDL-DSL은 현재 기본적인 테이블 생성 기능을 안정적으로 제공하고 있지만, 실제 프로덕션 환경에서의 완벽한 활용을 위해서는 여러 가지 개선이 필요합니다.
특히 마이그레이션 시스템의 도입과 다양한 데이터베이스 벤더 지원은 가장 시급한 과제입니다.
특히 이번 라이브러리와 다음 포스팅 주제가 될 '영속성 레이어 코드 생성기' 라이브러리는 우리 팀 뿐만이 아닌 타 팀에도 도입되었기 때문에 어깨가 더 무겁네요.
이러한 개선사항들이 구현된다면, 프로덕션 상황에서 유지 보수나 추가 개발시 테이블 정의가 수정되더라도, 안정적으로 운영이 가능하리라 예상 됩니다.
소회
여태 까지와는 다르게, 앞서 방금 말씀드린 것 처럼, 다른 팀에도 도입되게 되면서 제작에 더 큰 보람을 느꼈던 라이브러리 였습니다.
언젠가는 사내 라이브러리 수준이 아니라, 여러 사람이 사용하는 오픈소스 라이브러리, 나아가 한 영역에서 인스턴스들의 라이프 사이클과 전체적인 플로우 까지 제어하는 프레임워크 수준의 개발도 해보고 싶네요!
그 날을 위해 계속 정진하여 열심히 공부하고 개발해야겠습니다.
멀티플랫폼 POS 출시 전까지 개선 사항들 보완을 해야 돼서 아마 그때 이 주제의 포스팅을 다시 이어 나갈 것 같아요.
그럼 여태까지 DDL-DSL 개발기 시리즈를 읽어주셔서 감사합니다~ (꾸벅)
'작디 작은 나만의 라이브러리 > DDL-DSL' 카테고리의 다른 글
[신입 개발자의 두 번째 라이브러리 개발기] 도메인 특화 언어(DSL)을 만들어 보자! DDL-DSL 개발기 -1. 구현- (0) | 2024.12.01 |
---|---|
[신입 개발자의 두 번째 라이브러리 개발기] 도메인 특화 언어(DSL)을 만들어 보자! DDL-DSL 개발기 -0. 개발 목적과 구상- (2) | 2024.12.01 |