AI 요약관련 정보

• 코드 중복 제거(DRY)는 초기 단계에서 섣불리 판단하여 적용하면 안 되며, 특히 도메인 코드는 미래 변화 가능성 때문에 독립적인 역할이 확정될 때까지 기다려야 합니다. ⏳
• 최소 집합으로 작성된 초기 코드는 비슷해 보일 수 있으나, 시간이 지나면서 완전히 다른 기능으로 발전할 수 있어 성급한 중복 제거는 나중에 더 큰 문제를 야기합니다. 🐛
• 비도메인적이고 순수 기능적인 코드(예: 수학 계산, 암호화)는 초기부터 중복 제거하여 라이브러리로 분리해도 안전합니다. 🧮
• 코드 중복 여부 판단은 개발자만의 영역이 아니며, 기획이나 사업적 관점에서 미래 변화 가능성을 고려해야 합니다. 🔮
• 공유 라이브러리는 코드 오너십이 다른 두 그룹 이상이 코드를 공유할 때 사용되는 개념으로, 자바의 경우 메이븐 저장소를 활용하는 것이 가장 쉬운 방법입니다. 📚
• 공유 라이브러리 오너십은 회사 문화에 따라 선호되거나 기피될 수 있으며, 이로 인해 별도의 라이브러리 조직을 만들거나 팀 간 책임 전가 문제가 발생하기도 합니다. 🤝
• 라이브러리 팀을 별도로 만들면 갈라파고스화 문제로 실패하는 경우가 많고, 팀에서 관리하는 방식도 완벽하지 않아 중앙 집중식과 분산식 관리 사이를 반복하는 경향이 있습니다. 🔄
• 공유 라이브러리는 개발 환경(예: 자바 버전) 불일치 및 연계 의존성 버전 충돌(트랜지티브 의존성 브릿지 문제)과 같은 심각한 문제를 야기할 수 있습니다. 💥
• 자바 프레임워크(예: 스프링 부트)는 BOM(Bill of Materials)을 통해 연계 의존성 버전 충돌 문제를 해결하지만, 이는 업데이트 유연성을 제한합니다. 🧱
• 공유 라이브러리의 문제점을 해결하기 위해 API화(컴파일 환경에서 분리)를 시도하지만, 이는 프로토콜 오너십 문제와 진정한 독립성 부족이라는 난관에 부딪힙니다. 🔗
• 대부분의 시스템은 진정으로 독립적이지 않기 때문에, API화는 '떡진 API'나 거대 시스템으로 변질될 위험이 있으며, 책에 나오는 예시처럼 완벽히 독립적인 API를 만드는 것은 매우 어렵습니다. 🕸️