#Backend

경계를 빌드로 못 박으면, 경계를 옮기는 일도 빌드가 붙잡습니다

Summary

빌드로 꽁꽁 묶어둔 코드 경계, 진짜 견고한 걸까 아니면 발목을 잡힌 걸까?

컴파일러에게 의존성을 맡겼을 때 찾아오는 '두 번째 청구서'와 변경 리듬을 따르는 실용적 설계 방법론

이 아티클은 Gradle 멀티 모듈로 아키텍처 경계를 강제하며 겪었던 현실적인 고충과 해법을 솔직하게 공유합니다. 컴파일러가 의존성을 완벽하게 지켜주는 편안함의 이면에 '경계 유연성 상실'이라는 거대한 트레이드오프가 존재함을 폭로하며, 비즈니스의 빠른 성장에 부합하도록 경계를 변경 주기에 맞춰 재구성하고 소프트웨어를 유연하게 유지하는 실전 아키텍처 전략을 선사합니다.

01컴파일 타임에 의존성을 제어하는 완벽한 아키텍처는 경계를 다시 옮겨야 할 때 막대한 마찰 비용을 초래합니다.
02경계 변경 비용이 크면 개발자는 모듈 병합 대신 명시적 의존성 우회 규칙을 남용하여 결국 아키텍처를 훼손하게 됩니다.
03경계를 긋는 진정한 기준은 정적인 모듈 구조가 아니라, 변경사항이 함께 발생하는 코드가 움직이는 리듬(변경 주기)이어야 합니다.
04설계가 모호하고 도메인에 대한 확신이 없을 때는 섣불리 쪼개기보다 애매하게 뭉쳐두는 편이 나중에 합치는 비용을 아끼는 지름길입니다.
05물리 모듈 분리는 도메인이 비교적 안착되고 다수의 팀이 거대한 코드베이스를 안정적으로 운영해야 하는 성숙기에 도입하는 것이 효율적입니다.

RECOMMENDATION

수시로 도메인이 요동치는 신규 스타트업 환경에서는 모듈 분리를 지양하고 모놀리식 구조로 시작하되, 서비스가 고도화되고 협업 조직이 증가하는 시점에 변경 리듬 분석을 거쳐 멀티 모듈로 전환하는 것을 적극 권장합니다.

The Problem

Gradle 멀티 모듈 등을 통해 물리적으로 의존성 경계를 컴파일러 수준에서 강력히 제어하는 방식은 초기 경계 설정이 틀렸을 때 리팩토링 비용을 과도하게 증가시킵니다. 이로 인해 개발자들이 복잡한 모듈 병합 공사를 피하려고 편법적인 의존성 선언을 추가하여 경계를 우회하고 아키텍처가 손상되는 문제가 발생합니다.

The Solution

모듈 분리의 기준을 고정된 아키텍처 다이어그램이 아닌 함께 변경되고 배포되는 리듬(변경 주기)에 맞추어 조정하고, 확신이 없을 때는 일단 덜 쪼개는 전략을 적용했습니다. 또한, 경계 자체를 주기적으로 조정하는 리팩토링 작업을 정상적인 일상 정비 작업으로 취급하여 적극적으로 개선하도록 유도했습니다.

The Result

컴파일러가 강제하는 강력한 의존성 제어(견고함)를 유지하면서도, 설계 오류로 인해 발생하는 아키텍처 우회 현상과 불필요한 마찰을 유기적인 경계 조정을 통해 해결했습니다. 변경 내역이 빌드 구성 수정을 통해 명확하게 시각화되어 구조 붕괴를 예방할 수 있게 되었습니다.

Trade-off

경계의 견고함을 얻은 대신 유연함을 잃게 되어, 잘못 설정된 경계를 병합하는 등 대규모 구조 조정 시 물리적인 의존성 설정 변경 공사를 감수해야 합니다. 도메인이 수시로 급변하는 프로젝트 초기 단계에서는 이 같은 엄격한 컴파일 기반 통제가 개발 속도를 늦추는 걸림돌이 될 수 있습니다.

Key Concepts

Concept · 01

물리 모듈 분리 (Physical Module Separation)

소프트웨어 프로젝트를 빌드 관리 도구(예: Gradle)의 독립적인 모듈 단위로 쪼개어, 각 컴파일 환경의 참조 범위와 의존 관계를 빌드 구성 수준에서 원천 차단하는 방식입니다.

리뷰어의 주관적 검토에만 의존하지 않고 컴파일 에러를 통해 도메인 코어가 인프라를 직접 참조하는 나쁜 의존성을 방지하는 데 사용되었습니다.
잘못 그은 아키텍처 경계를 다시 병합하려고 할 때 수많은 설정 파일 변경과 다수의 소스코드 이관 공사를 발생시키는 마찰 원인이 되기도 합니다.

Concept · 02

변경 리듬 (Rhythm of Change)

기능 개선 및 비즈니스 로직 요구조건이 변화할 때, 서로 다른 코드 조각들이 같은 주기에 동시다발적으로 변경되고 배포되는 결합적 특성을 말합니다.

외관상의 계층 구조를 맹신하는 모듈 경계를 대체하여 실무 관점에서 함께 수정되는 도메인 모델들을 하나의 단위로 묶는 핵심 설계 기준으로 사용되었습니다.
서로 다른 리듬으로 움직이는 코드들을 올바르게 고립시켜 특정 비즈니스 변경이 전체 시스템에 부작용을 일으키거나 불필요한 전체 빌드를 유도하지 않도록 방어하는 역할을 합니다.

Concept · 03

설계 가역성 (Design Reversibility)

한 번 내린 기술적 의사결정을 비즈니스 변화나 기술 사양 변경 등에 맞추어 비용 손실 없이 쉽게 되돌릴 수 있는 정도입니다.

쪼개진 모듈을 합치는 고비용 작업(비가역성)과 단일 모듈 내에서 경계를 가르는 저비용 작업(가역성)의 비용 비대칭성을 판단하는 도구로 응용되었습니다.
미래의 변경을 정확히 파악하기 전까지는 모듈 경계 설정을 보류하고 단일 덩어리로 유지하여 변경 유연성을 확보하는 실용적 결정 기준이 됩니다.

Continue reading · same source