스프링은 확장에 강하다. 대신 초기 설계를 대충하면 고통도 같이 확장된다

스프링은 확장에 강하다. 대신 초기 설계를 대충하면 고통도 같이 확장된다

업무 용어로 풀면 이겁니다.

---

 

왜 Spring은 확장에 강한가

• IoC / DI
  → 결합도 낮추기 쉬움
• 레이어드 구조
  → 기능 추가가 물리적으로 가능
• 풍부한 생태계
  → 보안, 트랜잭션, 배치, 메시징 다 있음

즉, “붙이는 것” 은 정말 쉽습니다.

---

그런데 고통도 같이 커지는 이유

1. 경계 없는 서비스

• Service가 비대해짐
• 유스케이스 단위가 아니라 테이블 단위 서비스
• 변경 영향도 예측 불가

👉 기능 하나 추가 = 전체 리그레션 공포

---

2. 엔티티 남용

• JPA 엔티티 = DTO = API 모델
• 양방향 연관관계 + 지연로딩 지옥
• 작은 요구사항에 쿼리 폭발

👉 성능 이슈가 설계 부채로 전환됨

---

3. 설정과 추상화의 과잉

• 인터페이스를 위한 인터페이스
• 전략 패턴 남발
• 실제로 교체 안 함

👉 확장을 대비했지만,
확장보다 유지보수가 더 어려워짐

---

4. “일단 돌아가게”

• 트랜잭션 범위 대충
• 예외 정책 없음
• 상태 관리 산만

👉 트래픽 늘면 바로 임계점 도달

---

그래서 Spring 잘 쓰는 팀의 기준

한 줄로 정리됩니다.

확장 포인트만 설계하고, 나머지는 단순하게 둔다

실무 체크리스트로 보면:

• 서비스는 유스케이스 기준
• 엔티티는 도메인 내부 전용
• API 모델 분리
• 트랜잭션 경계 명확
• “나중에 확장”이라는 말 금지

 

 

유스케이스는 정책의 흐름이고,
엔터티는 상태의 진실이고,
DB는 현실의 비용이다.
설계는 이 셋의 타협을 문서화하는 일이다.