Ivan가 거대한 Repository 인터페이스 대신 Consumer-Defined Interface 패턴을 적용하여 테스트 가능성과 유지보수성을 획기적으로 개선한 사례를 소개한다

Context

기존 Repository Pattern 구현에서는 모든 데이터 접근 메서드를 단일 거대한 인터페이스에 정의하여 테스트 시 50개 이상의 메서드를 일일이 mock해야 하는 문제가 발생한다. 이 구조는 Interface Segregation Principle을 위반하며 서비스 간 불필요한 의존성을 야기한다.

Technical Solution

• Go 프로젝트 → Service 단위로 분리된 작은 인터페이스를 정의하는 Consumer-Defined Interface 패턴 적용
• UserRepository → 결제 서비스용 PaymentRepository, 알림 서비스용 NotificationRepository 등으로 구체적인 용도에 맞게 분리
• 비즈니스 로직이 포함된 Service가 필요한 메서드만 가진 인터페이스를 직접 정의하고 구현하는 구조 채택
• 구체적인 비즈니스 케이스에 맞는 쿼리 메서드(PaymentExpiredUsers, GetAllPremiumUsersWithPendingNotifications 등) 생성

Impact

테스트 시 필요한 메서드만 mock하여 설정 시간 단축 및 테스트 코드 간소화

Key Takeaway

커다란 범용 인터페이스보다 작은 서비스 특화 인터페이스가 더 강한 추상화를 제공하며, 잘못된 추상화는 추상화 없는 코드보다 더 해롭다