설정이 적은 코드가 아니라 의도가 분명한 코드가 좋은 스프링 코드다

❌ “설정이 적은 코드”가 좋은 코드라는 착각

스프링에서 설정이 적다는 건 대부분 이런 상태입니다.

• 애노테이션이 의미를 숨김
• 자동 설정이 어디서 들어오는지 모름
• 조건부 빈(@Conditional)이 암묵적으로 동작
• AOP·프록시·트랜잭션이 보이지 않게 개입

→ 코드량은 줄었지만, 인지 부하는 폭증합니다.

---

✅ 좋은 스프링 코드의 기준: “의도가 보이느냐”

1. 이 클래스가 왜 존재하는지 한 눈에 보인다

 

@Service public class OrderPaymentService { // 결제 승인 규칙만 존재 }

• 잡다한 공통 처리 없음
• “무엇을 하는지”가 클래스명/메서드명으로 드러남

---

2. 어디서 무엇이 적용되는지 추적 가능하다

 

@Transactional public void approvePayment(...) { ... }

• 트랜잭션 경계가 코드에 드러남
• AOP 뒤에 숨기지 않음
• 장애 나면 여기부터 본다가 명확

---

3. 자동화보다 명시성을 우선한다

• @Autowired 남발 ❌ → 생성자 주입 명시
• 컴포넌트 스캔 범위 최소화
• @Configuration 클래스에서 의존성 구조가 드러남

 

@Configuration public class PaymentConfig { @Bean PaymentService paymentService(...) { return new PaymentService(...); } }

→ 설정이 늘었지만 시스템 구조는 선명해짐

---

4. 프레임워크 코드는 가장자리로 밀어낸다

• 컨트롤러 / 인프라 계층만 스프링 의존
• 도메인/서비스는 POJO 유지
• 테스트에서 스프링 띄우지 않아도 돌아감

이게 진짜 유지보수 가능한 스프링입니다.

---

SI / 공공 프로젝트에서의 현실적인 결론

• 설정 적음 = 초기 개발 속도
• 의도 명확 = 운영·감사·인수인계 생존

공공 SI에서 “마법 같은 코드”는
100% 나중에 설명 요구서로 돌아옵니다.

---

한 줄 정리 (업무용 문장)

좋은 스프링 코드는 설정이 적은 코드가 아니라,
‘이 코드가 왜 존재하는지’가 드러나는 코드다.