AOP는 문제 해결이 아니라 문제 은닉 도구가 될 수 있다

AOP는 잘 쓰면 생산성 도구지만, 잘못 쓰면 문제 은닉 도구

 

왜 문제 은닉 도구가 되나

1. 본질적 설계 문제를 가린다

• 트랜잭션 경계가 애매함
• 책임이 불분명한 서비스 계층
• 도메인 로직과 인프라 로직이 뒤섞임
  → 이걸 AOP로 감싸면 설계 부실이 안 보이게만 됩니다.

2. 실행 흐름이 코드에서 보이지 않는다

• 메서드 시그니처만 보면 정상
• 실제로는 로깅, 트랜잭션, 리트라이, 보안 체크가 뒤에서 개입
  → 장애 시 콜스택 추적 난이도 급상승, 신규 인력 온보딩 지옥.

3. “일단 붙이고 보자” 문화

• 에러 처리 → AOP
• 성능 문제 → AOP
• 보안 → AOP
  → 결국 비즈니스 로직이 얇아지는 게 아니라 공허해짐.

---

그럼 언제 써야 하나 (명확한 사용 조건)

AOP는 아래 조건을 모두 만족할 때만 의미가 있습니다.

1. 횡단 관심사가 명확할 것
   • 로깅, 모니터링, 인증/인가, 공통 트랜잭션 정책
2. 비즈니스 규칙과 완전히 분리 가능할 것
   • “업무 규칙”이 들어가면 그 순간 설계 실패
3. 적용 범위가 문서화·가시화되어 있을 것
   • 어떤 패키지/레이어에 걸리는지 팀 공통 인식 필요

---

실무 기준 한 줄 요약

• ❌ “귀찮아서 AOP” → 문제 은닉
• ❌ “설계 대신 AOP” → 기술 부채
• ✅ “설계가 끝난 뒤 반복 제거용” → 정상 사용

---

냉정한 결론

AOP는 문제를 해결하지 않는다.
문제를 ‘보이지 않게’ 만들 뿐이다.

그래서 공공 SI에서는:

• AOP 남용 = 운영 리스크
• 감사/장애/인수인계에서 반드시 터집니다.