통 라이브러리를 조합 가능한 의존성 모듈로 쪼개라

출처 및 AI 안내: 이 글은 제미니의 개발실무 유튜브를 기반으로 작성되었습니다. gpt-5.6-sol 모델을 사용해 생성·편집했습니다.

Redis를 쓰지 않는 서비스의 운영 로그에 Redis 경고가 나타났다. 더 나쁜 경우에는 쓰지도 않는 연동의 문제로 서비스 자원이 고갈될 수 있었다. 전사 통 라이브러리 하나를 받는 순간 Redis, Kafka, 메시징, Swagger와 다른 인프라가 모두 따라온 것이 원인이었다.

의존성 제외는 내용 모를 쓰레기통을 뒤지는 일이다

Gradle exclude로 사용하지 않는 전이 의존성을 뺄 수 있고 실제 그런 회사에서도 사용했다. 문제는 번들 안에 무엇이 있는지 알아낸 뒤에야 뺄 수 있다는 점이다. Redis 의존성 하나가 여러 클라이언트와 라이브러리를 타고 들어오면 한 줄로 명확하게 끝나지 않는다.

모든 연동을 기본 비활성화하는 설정은 런타임 동작 일부를 막으므로 더 낫다. 그래도 관련 없는 코드는 의존성 그래프에 남는다. 거의 모든 서비스가 실제로 같은 인프라를 쓰는 큰 조직이라면 넓은 표준 패키지가 편리할 수 있다. 규모와 목적이 다른 서비스까지 같은 전제로 묶을 수는 없다.

전사 라이브러리를 선택 가능한 부품으로 만든다

로깅, 데이터 접근, Redis, Kafka와 테스트 지원을 각각 모듈로 나눈다. 서비스는 이해하고 필요한 기능만 추가한다. 직전 회사에서 운영한 공통 구조도 이런 조합형이었고, 리뷰에서는 한 모듈이 관계없는 인프라를 몰래 경계 너머로 끌고 오지 않는지 살폈다. Spring Boot 4.0의 더 잘게 나뉜 테스트 모듈이 구체적인 예다. JDBC나 JPA 테스트 지원을 하나의 거대한 테스트 자동 설정 묶음으로 받지 않고 해당 기능에 필요한 의존성과 함께 고를 수 있다. 새 비즈니스 로직이 생긴 것이 아니라 구조가 더 잘 보이고 조합하기 쉬워진 변화다.

편의 기능은 부품을 대체하지 말고 그 위에 둔다

작은 모듈에는 발견 비용이 있다. 보통 서비스에 무엇을 조합해야 하는지 개발자가 알아야 한다. 회사는 ‘심플 웹’, ‘헤비 웹’ 같은 문서화된 상위 조합으로 이를 줄일 수 있다. 다만 프리셋은 작은 모듈을 조립하고 ‘심플’에 무엇이 들어가는지 정의해야지 다시 불투명한 만능 의존성이 되어서는 안 된다. 조직은 동일한 서비스를 빨리 찍어내는 것과 개발자가 어떤 모듈을 추가할지 생각하게 하는 것 중 어디에 무게를 둘지 정해야 한다. 둘 다 비용이 있다. 모르는 동작을 나중에 빼기보다 알고 있는 부품을 추가하는 쪽을 선호한다. 보이는 블록으로 가장 작은 서비스를 만들고, 필요할 때 이름 붙은 상위 조합을 제공한다.