Repository 패턴이란?
Repository 패턴은 데이터베이스나 외부 저장소에 접근하는 로직을 애플리케이션의 비즈니스 로직과 분리하기 위한 설계 패턴입니다. 쉽게 말하면, ‘데이터를 어떻게 가져올 것인가’와 ‘가져온 데이터를 어떻게 사용할 것인가’를 나누는 것입니다. 서비스 코드에서 직접 SQL을 작성하거나 ORM 객체를 다루는 대신, Repository라는 중간 계층을 통해서만 데이터에 접근하도록 강제합니다.
비유하자면 Repository는 도서관의 사서와 같습니다. 이용자는 책이 어느 서가에 있는지, 어떤 분류 체계로 정리되어 있는지 몰라도 됩니다. 그냥 사서에게 ‘이 책 좀 찾아주세요’라고 요청하면 됩니다. 서비스 로직도 마찬가지로 데이터가 MySQL에 있는지, MongoDB에 있는지, 파일로 저장되어 있는지 몰라도 Repository에게 요청만 하면 됩니다.
동작 원리와 예시
Repository는 보통 인터페이스와 구현체로 나뉩니다. 예를 들어 사용자 정보를 다루는 경우 다음과 같은 형태를 가집니다.
- 인터페이스:
UserRepository–findById(id),save(user),delete(id)같은 메서드 정의 - 구현체:
UserRepositoryImpl– 실제로는 JPA, MyBatis, 혹은 직접 SQL을 사용해 구현
서비스 계층에서는 UserRepository 인터페이스만 알고 있으면 되고, 실제 구현이 무엇인지는 신경 쓰지 않습니다. 만약 데이터베이스를 MySQL에서 PostgreSQL로 바꾸거나, 테스트를 위해 가짜 데이터를 반환하는 Mock 객체로 교체하더라도 서비스 코드는 전혀 수정할 필요가 없습니다. 인터페이스라는 ‘약속’만 지키면 내부 구현은 자유롭게 바뀔 수 있는 구조이기 때문입니다.
실무에서 왜 쓰는지
실무에서 Repository 패턴을 쓰는 가장 큰 이유는 테스트 용이성과 유지보수성입니다. 비즈니스 로직을 테스트할 때 실제 데이터베이스에 연결하지 않고도, Repository를 가짜 객체로 대체해서 원하는 데이터를 즉시 반환하도록 만들 수 있습니다. 덕분에 테스트 속도가 빨라지고 외부 환경에 의존하지 않는 안정적인 테스트가 가능해집니다.
또한 데이터 접근 로직이 한 곳에 모여 있기 때문에, 쿼리 방식이나 저장소 기술이 바뀌어도 영향 범위가 Repository 내부로 한정됩니다. 여러 개발자가 협업할 때도 ‘데이터는 어떻게 가져오는가’에 대한 고민 없이 비즈니스 로직 개발에만 집중할 수 있다는 점에서, Repository 패턴은 규모가 커질수록 그 진가를 발휘하는 설계 방식이라 할 수 있습니다.