[global] Gradle에서 Bazel로 빌드 시스템 전면 전환

[snowykte0426]

개요

빌드 시스템을 Gradle에서 Bazel로 전면 전환합니다. 7개 모듈 빌드·테스트·린트·컨테이너·발행·CI/CD를 모두 Bazel로 옮기고, Gradle 관련 파일(build.gradle.kts ×9, buildSrc, gradlew, settings.gradle.kts, gradle/, kotlin-js-store)을 제거했습니다.

연관 이슈

• Closes [global] 빌드 도구로 Bazel 도입 #365 — [global] 빌드 도구로 Bazel 도입
• Closes [global] KSP 파일 직접 쓰기 회피책 원복 및 증분 처리 복구 검토 #341 — [global] KSP 파일 직접 쓰기 회피책 원복: KmpExportProcessor를 codeGenerator.createNewFile 기반으로 되돌리고, 2차 라운드 가드를 추가해 PSI 무효화 문제를 회피했습니다.
• 관련 [global] KMP configuration cache 지원 시 problems=fail로 격상 #340 — [global] KMP configuration cache 제약: Gradle 제거로 해당 제약 자체가 소멸합니다.

검증 상태

• bazel build //... → 71개 타깃 그린
• bazel test //... → 6개 테스트 타깃 PASS (web 모듈만 332개 케이스)
• 서비스 OCI 컨테이너 4종 docker run 기동 검증 (Spring 컨텍스트·멀티스토어 정상)
• CD 산출물(java -cp 'lib/*') prod 프로파일 기동 검증
• 생성 산출물 동등성 검증: kmp-export Kotlin 25파일이 Gradle 산출과 @JsExport 잔재 외 100% 동일, .d.ts는 tsc --strict --noEmit 통과

나아진 점

• 재현성/hermetic 빌드 — 툴체인(JDK·Kotlin 2.3.10)이 Bazel에 고정되어 호스트 JDK와 무관하게 동일 산출.
• 원격 캐시 ready — CI가 머신·실행 간 캐시 공유 가능 (content-addressed). 향후 CI 비용 절감 여지.
• [global] KSP 파일 직접 쓰기 회피책 원복 및 증분 처리 복구 검토 #341 해소 — KSP 직접 파일 쓰기 해킹 제거(표준 createNewFile + 라운드 가드). 부수적으로 멀티라운드에서 index.d.ts가 부분 덮어쓰기되던 잠재 버그도 구조적으로 차단.
• [global] KMP configuration cache 지원 시 problems=fail로 격상 #340 무의미화 — Gradle configuration cache × KMP 한계가 사라짐.
• 모듈별 JDK 타깃이 명시적 — 서비스/ksp는 JVM 25(프로덕션 서버 일치), 발행 SDK(datagsm-shared)는 JVM 17(소비자 하한) 유지를 //bazel:kt_jvm_target 플래그로 분리.
• 컨테이너 네이티브 — OCI 이미지가 1급 빌드 산출물(bazel run //<module>:<name>_image_load).
• 단일 도구 — 빌드/테스트/린트(ktlint)/패키징/컨테이너/발행을 Bazel 하나로.

퇴보한 점 / 트레이드오프

• 로컬 전체 증분이 다소 느림 — bazel test //...는 OCI 이미지·deploy tar·TS 패키지까지 함께 빌드해 Gradle build보다 산출물이 많음(아래 벤치 참고). 타깃 단위(bazel test //datagsm-web:web_test)로 빌드하면 동등.
• ktlint가 bazel test에 미통합 — 별도 명령(bazel run //bazel:ktlint). Gradle은 build에 포함했음.
• 발행이 덜 통합적 — datagsm-shared Maven 발행은 mvn deploy:deploy-file에 의존(PATH에 mvn 필요).
• IDE 통합 약화 — IntelliJ Gradle 연동 대비 Bazel 플러그인은 매끄러움이 덜함. BUILD 파일 유지보수·러닝커브 존재.
• 프로세서 소스 수정 필요 — @JsExport 제거 및 createNewFile 전환(단, 이는 [global] KSP 파일 직접 쓰기 회피책 원복 및 증분 처리 복구 검토 #341 해소이기도 함).

정량 벤치마크 (로컬, M-series / 의존성 캐시 상태)

단일 머신 단발 측정이라 지표성 참고용. Gradle은 warm 데몬, Bazel은 clean 후.

시나리오	Gradle	Bazel	비고
Cold (전체 컴파일+300+테스트)	33s	37s	대등. Bazel은 분석 단계 포함
No-op 재빌드	2s	2.3s	대등
증분 — 전체(//..., 서비스 1파일)	5s	11s	Bazel은 OCI·deploy tar·TS까지 함께 빌드
증분 — 타깃 모듈 테스트만	~1s	~1s	ABI 기반 재테스트 회피로 대등

해석: 7모듈 규모에선 로컬 빌드 성능은 대등합니다. Bazel의 실익은 로컬 속도가 아니라 원격 캐시(CI)·재현성·세분화된 의존 그래프·컨테이너 네이티브에 있습니다.

미검증 / 후속 과제

• AWS CodeDeploy 실배포 — 빌드/패키징/dockerfile 기동은 검증했으나, S3→CodeDeploy→EC2 구간은 직접 검증 불가. 머지 전 실파이프라인 1회 확인 권장.
• oci 이미지 digest 핀 고정(재현성), 프로덕션용 amd64 베이스 추가.
• 원격 빌드 캐시(Develocity/HTTP) 연결로 CI 캐시 이점 실현.

[gemini-code-assist]

Code Review

This pull request migrates the project's build system from Gradle to Bazel, removing all Gradle-related files and introducing Bazel module definitions, custom Kotlin toolchains, and module-specific BUILD files. It also updates the Dockerfiles to use layered runtime classpaths instead of fat jars, and refactors the KmpExportProcessor to use standard KSP code generation with a guard against multi-round PSI invalidation. Feedback on the changes identifies a security vulnerability in datagsm-shared/publish.sh where the use of exec mvn prevents the cleanup of a temporary file containing the sensitive GITHUB_TOKEN; it is recommended to remove exec and use a trap to guarantee deletion.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

Code Review

This pull request migrates the project's build system from Gradle to Bazel, removing all Gradle-related configuration files and wrapper scripts. It introduces Bazel module definitions, custom Kotlin toolchains, and shared macros for Spring Boot service containerization and Kotest execution. Additionally, the KSP processor was refactored to safely use CodeGenerator with a multi-round guard, and the Dockerfiles were updated to run services using a layered classpath (java -cp) instead of a fat JAR. During the review, a high-severity issue was identified in the publishing script (datagsm-shared/publish.sh), which incorrectly searches for shared.jar instead of the Bazel-generated libshared.jar.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[wwwcomcomcomcom]

아래표가 제가 생각하는 해당 작업을 통해 얻는 주요 트레이드 오프입니다.

장점	단점
KSP, KMP의 내부 문제 해결	러닝커브
한번에 컨테이너까지 빌드	ktlint, IDE등 일부 통합에 부적합

가장 큰 문제는 IDE와의 통합이 떨어지고, 팀원들이 익숙하지 않은 DSL과 빌드 툴을 사용하면서 겪는 러닝 커브라고 생각되는데, 그에 비해 해결하는 문제가 마이너하다고 생각됩니다. 기존의 ksp, kmp 동작에서 내부 구조적으로 문제가 있었지만 실사용에 문제가 될 정도는 아니였는데, 이 부분을 위해 빌드툴 전체를 교체하고, 팀원들이 새 빌드툴을 배우는데에 리소스가 사용되는 것은 제 생각에 좋은 변경이 아닌 것 같습니다.

[snowykte0426]

가장 큰 문제는 IDE와의 통합이 떨어지고,

IDE 통합은 JetBrains의 공식 지원에 포함되는 부분이라 크게 문제가 되지 않는다고 생각합니다.
러닝커브에 대한 우려는 어느 정도 공감합니다. 다만 해당 도구는 커뮤니티가 강력한 편이라 LLM의 이해도 역시 높은 편이고, AI 활용에 대해 다소 공격적인 입장을 취하고 있다는 점은 인정하지만 러닝커브는 더 이상 결정적인 장애물이 아니라고 판단하고 있습니다.