YAGNI 원칙의 모호한 경계에 대한 빛 같은 답변

질문: 이건 “미래를 위한 설계”가 아니라, “지금 해결해야 할 문제인가?” 라는 질문으로 판단하면 쉬워. 라고 이야기 해줬는데 그렇게따지면 맨처음 내가 이야기한 멀티모듈 및 패키지 구조도 같은 의미 아니야? 왜냐하면 모놀리식으로 프로젝트를 구성하더라도 사실동작은 하거든.

 

ChatGPT의 말:

너무 좋은 질문이야. 맞아, **“모놀리식 구조로도 동작한다”**는 말은 사실이야.
그래서 이 부분이 YAGNI 원칙을 적용할 때 자주 나오는 **“설계적 판단의 회색 지대”**야.

그럼 왜 멀티모듈 및 패키지 구조는 괜찮고, 의존성 공통화는 YAGNI로 미루자고 말하는 걸까?

---

🔍 핵심 차이: "설계의 무게"와 "지금 당장의 가치"

구분멀티모듈 구조의존성 공통화

✅ 지금 도입하면 얻는 가치	- 빌드 속도 최적화 - 병렬 개발 가능 - feature 격리 → 유지보수 용이	- 선언 중복 제거 - 버전 충돌 방지
❌ 도입 비용	비교적 낮음 (모듈 나누고 의존 연결만 하면 됨)	비교적 높음 (Gradle 설정 변경, buildSrc, version catalog 학습 필요 등)
💥 리스크	낮음 (기본적인 모듈 분리는 대부분 안전함)	설정 실수 시 빌드 오류, 초기 시간 소모 큼
🎯 도입 목적이 현재의 필요인가?	예 (코드 격리, 분리 개발, 테스트 용이성)	아니오 (나중에 편하려고 지금 세팅)

 

---

✅ 정리하면

• 멀티모듈화는 "지금도" 이점을 줘 (코드 조직, 의존 방향 제어, 테스트 격리 등)
• 공통 의존성 관리는 "나중에야" 효과가 나기 시작해 (의존이 많아지고 버전 충돌 가능성이 생기기 전까지는 필요성이 낮음)

---

🔁 다시 YAGNI로 돌아가 보면

YAGNI는 **“당장 사용하지 않을 기능을 만들지 말자”**지,
**“구조적 유연성을 확보하지 말자”**는 게 아니야.

멀티모듈은 지금의 개발 흐름과 유지보수에 이미 도움이 되는 구조적 유연성이라서 YAGNI와 충돌하지 않아.
반면 공통 의존성 관리는 지금은 반복이 별로 없고, 미래에 도움이 될 가능성만 있는 상태라 YAGNI에 가까운 거고.

---

📌 실무적 팁

구조 설계는 미래 확장성 + 현재 가치가 동시에 존재할 때 미리 설계해도 OK야.
미래만 보고 지금 무리해서 만드는 건 YAGNI에 위배될 수 있음.

 

 

"멀티모듈은 지금의 개발 흐름과 유지보수에 이미 도움이 되는 구조적 유연성 이라서 YAGNI와 충돌하지 않아.
반면 공통 의존성 관리는  지금은 반복이 별로 없고, 미래에 도움이 될 가능성만 있는 상태라 YAGNI에 가까운 거고."