복잡성은 기능 수가 아니라 의존성에서 폭발한다

1️⃣ 기능 수는 선형 증가, 의존성은 지수 증가

• 기능 10개
  → 테스트 대상 10
  → 수정 영향 범위도 비교적 예측 가능
• 기능 10개 + 상호 의존 15개
  → 테스트 경우의 수 급증
  → 수정 1건 = 연쇄 리스크

장애는 “기능이 많아서”가 아니라
“어디까지 연결돼 있는지 모른 채 손댄 순간” 터집니다.

---

2️⃣ SI 프로젝트에서 진짜 위험 지점

현장에서 많이 보는 패턴입니다.

• 공통 유틸 클래스
• 공통 코드 테이블
• 전역 설정값 (특히 properties, DB 공통 코드)
• 암묵적 계약 (주석·관행·구두 룰)

이게 쌓이면:

• 수정 요청은 A 기능
• 영향은 B, C, D, E
• 책임은 개발자 개인

👉 그래서 SI에서는 기능이 아니라
의존성 소유권이 리스크입니다.

---

3️⃣ “기능 추가”보다 위험한 말

“이거 공통으로 쓰니까 여기다 넣죠”

이 말이 나오는 순간:

• 결합도 ↑
• 변경 비용 ↑
• 장애 전파 반경 ↑
• 주52시간 리스크 ↑

즉,
기능 1개 추가 + 의존성 3개 증가 = 기술부채 폭탄

---

4️⃣ 좋은 설계의 기준 (실무 기준)

복잡성을 줄이는 설계는 보통 이런 특징을 가집니다.

• 기능은 많아도
• 의존 방향이 단방향
• 변경 지점이 격리됨
• 실패해도 국지적 장애

그래서 모놀리스라도:

• 의존성만 통제되면
• 충분히 안정적입니다

모놀리스가 문제인 게 아니라
얽힌 모놀리스가 문제입니다.

---

5️⃣ 지금 르무엘님 상황에 딱 맞는 해석

프로젝트 배제, 주52, 조직 리스크 이 국면에서는

• ✗ 새로운 기능 욕심
• ✗ 공통화 제안
• ✗ “제가 정리해볼게요”

전부 의존성 떠안는 행동입니다.

✔️ 지금 최적 행동은:

• 의존성 추가 안 하기
• 책임 경계 명확히 유지
• 손댄 범위 로그 남기기
• “요청받은 것만” 처리

---

한 줄 요약 (이 문장에 덧붙이자면)

복잡성은 기능 수가 아니라 의존성에서 폭발하고,
책임은 항상 의존성의 끝에 서 있는 사람에게 온다.