시작하기

이미지 작업 하나를 끝낼 수 있는 가장 작은 의존성과 런타임부터 고른다. Scrimage와 libvips는 겹치는 문제를 풀지만 배포 조건과 자원 소유 방식이 다르다. 처음부터 백엔드를 모두 넣을 이유는 없다.

1. 중앙 BOM 가져오기

애플리케이션의 다른 Bluetape 라이브러리와 같은 bluetape4k-dependencies 버전을 쓴다.

dependencies {
    implementation(platform("io.github.bluetape4k:bluetape4k-dependencies:<version>"))
    implementation("io.github.bluetape4k.image:bluetape4k-images")
}

저장소에서 bluetape4k-image-bom도 배포하지만, 일반 사용자는 중앙 BOM을 쓰는 편이 맞다. 그래야 Kotlin, Coroutines, 프레임워크와 다른 Bluetape 라이브러리 버전까지 함께 정렬된다. Image 계열만 따로 관리해야 한다면 Image BOM 문서를 참고한다.

2. 실행 경로 하나 고르기

• JVM만으로 로드, 저장, 필터, 변환과 분석을 처리하려면 불변 이미지 처리를 선택한다.
• 애플리케이션에 필요한 경우에만 CAPTCHA, OCR, Ktor, Spring Boot를 더한다.
• JDK 21 서비스에서 libvips를 설치할 수 있다면 Java 21 JVips를 검토한다.
• JDK 25와 native-access 옵션을 받아들일 수 있다면 Java 25 FFM을 검토한다.

비교 기준은 백엔드 선택에 정리했다.

3. 워크숍 실행하기

가장 짧은 JVM 경로는 기본 이미지 처리 워크숍이다. 프레임워크 애플리케이션은 Ktor 이미지 API나 Spring Boot 이미지 API로 이어간다. OCR은 실행 환경에 Tesseract를 설치하는 과정도 학습 범위에 들어가므로 Ktor와 Spring Boot 예제를 따로 제공한다.

4. 실제 경계 검증하기

루트 컴파일만 확인하지 말고 사용할 모듈의 테스트를 실행한다.

./gradlew :bluetape4k-images:test

네이티브와 OCR 검사는 실행 환경에 별도 소프트웨어가 필요하며 순차로 실행해야 한다. 활성화하기 전에 OCR 설정과 native 자원 수명 주기를 읽는다.

근거 소스

• 릴리스 빌드 설정
• 릴리스 의존성 예제