[신입 개발자의 두 번째 라이브러리 개발기] 도메인 특화 언어(DSL)을 만들어 보자! DDL-DSL 개발기 -0. 개발 목적과 구상-

개발 배경

이번에 저희 회사에서 멀티플랫폼을 지원하는 POS를 개발하게 되었는데요.
IOS를 제외한 Android와 Windows 플랫폼을 지원하는게 저희의 목표입니다.
저는 이번 프로젝트 에서 아키텍쳐 설계부터 프로젝트 환경 설정, 멀티플랫폼을 지원할 수 있도록 도와주는 사내 라이브러리 개발 등을 맡게 되었습니다.

일단 저희 회사가 당면한 과제는 크게 네 가지 였습니다.

1. 기존의 기술 스택을 유지해야 한다. (UI: React, Business Layer: Kotlin)
2. 다양한 RDBMS를 지원해야 한다.
3. 플랫폼 별 다양한 Van사 결제 모듈과, 다양한 회사의 프린터 기종을 지원해야 한다.
4. 메타 데이터 수정을 통해 위의 결제 모듈과 프린터 기종을 편하게 바꿀 수 있어야 한다.

그 중 첫 번째 문제인 '기존의 기술 스택을 유지해야 한다.' 는 Android환경 에서도 REST API 형태로 비즈니스 로직을 호출 할 수 있도록 하고, axios와 비슷한 인터페이스의 client 라이브러리를 만들어, 플랫폼에 따라 client 인스턴스를 교체하는 것으로 대응 하였습니다. 자세한 개발기는 아래 포스팅을 참고해주세요!

 

2024.07.22 - [작디 작은 나만의 라이브러리/BridgeApi] - [신입 개발자의 '작디 작고 작디 작고 자그만' 첫 라이브러리 제작기] 0. Bridge-Api를 구상하게 된 계기.

[신입 개발자의 '작디 작고 작디 작고 자그만' 첫 라이브러리 제작기] 0. Bridge-Api를 구상하게 된

 

 

이번에 제가 개발한 DDL-DSL 라이브러리는 두 번째 문제인 플랫폼에 따른 다양한 RDBMS 지원 해결하기 위해 제작되었습니다.
Android에서는 SQLite를, Windows에서는 MS SQL을 사용해야 하는 상황에서, 개발자들이 겪는 실질적인 문제들을 해결하고자 했습니다.

기존의 문제점

라이브러리 없이 Raw한 SQL DDL 문을 그대로 사용하려고 했을때의 문제점은 아래와 같습니다.

1. 중복 작업의 부담: 각 데이터베이스 시스템별로 별도의 DDL 문을 작성해야 했습니다. 이는 개발 시간을 늘리고 오류 가능성을 높이는 요인이 되었습니다.
2. 일관성 유지의 어려움: 테이블 구조가 변경될 때마다 여러 플랫폼의 DDL 문을 동시에 수정해야 했습니다. 하나라도 놓치면 데이터베이스 스키마의 불일치가 발생할 수 있었습니다.
3. 타입 안정성 부재: 기존의 문자열 기반 DDL 작성 방식은 컴파일 타임에 오류를 잡아내기 어려웠습니다.
4. 엔티티 정의와 테이블 정의간의 불일치 가능성: 엔티티의 정의가 달라질 때마다 엔티티 정의에 맞추어 테이블 정의 문을 수정해야 하는 문제가 있었습니다. (이 문제는 DDL-DSL 라이브러리를 통해서가 아닌, KSP 기반의 코드 생성 라이브러리를 개발하여 해결했습니다. 차후 persitence-code-genreater 라이브러리 제작기를 통해 포스팅 할 예정입니다.)

라이브러리의 목적

이러한 문제점들을 해결하기 위해 DDL-DSL 라이브러리는 다음과 같은 목적을 가지고 개발되었습니다:

1. 통합된 스키마 정의: 코드에서 볼 수 있듯이, TableDefinition 클래스를 통해 하나의 정의로 여러 데이터베이스의 DDL을 생성할 수 있도록 했습니다. 이는 SqlDialect 인터페이스를 통해 구현되었습니다.
2. 타입 안전성 보장: Kotlin의 타입 시스템을 활용하여, ColumnType sealed 클래스를 통해 컴파일 타임에 타입 안전성을 보장했습니다. 이는 코드에서 명확히 드러나는 핵심 설계 결정이었습니다.
3. DSL 기반 직관적 인터페이스: 테스트 코드에서 볼 수 있듯이, 직관적이고 가독성 높은 DSL을 제공함으로써 개발자의 생산성을 향상시켰습니다.

TableDefinition.create("users") {
    val id = column("id", ColumnType.Integer, isUnique = true)
    column("name", ColumnType.String())
    column("email", ColumnType.String())
    key {
        primaryKey(id)
    }
}

기대 효과

이 라이브러리의 도입으로 다음과 같은 효과를 기대할 수 있습니다:

1. 개발 생산성 향상: 하나의 코드로 여러 데이터베이스의 DDL을 생성함으로써, 개발 시간을 크게 단축할 수 있습니다.
2. 오류 감소: 컴파일 타임 검사와 통합된 스키마 정의를 통해 실수로 인한 오류를 최소화할 수 있습니다.
3. 유지보수성 개선: 스키마 변경이 필요할 때 한 곳만 수정하면 되므로, 유지보수가 훨씬 용이해집니다.

이번 편에서는 DDL-DSL의 구상과 목적에 대해 다뤄 보았습니다.
이러한 목적과 기대효과를 가지고 개발된 DDL-DSL 라이브러리의 실질적인 제작기는 다음 포스팅에서 다루도록 하겠습니다.
이번 라이브러리 제작기는 세 개 게시글 분량으로 포스팅 될 예정입니다.

0. 개발 목적과 구상
1. 실제 구현 과정
2. 향후 업데이트 계획

긴 글 읽어주셔서 감사합니다!!