BlogTagsProjectsAbout
Published on

Repository 패턴 — 이해와 활용

Authors
  • avatar
    Name
    JaeHyeok CHOI
    Twitter
    none

Repository 패턴 — 이해와 활용

소프트웨어 개발에서 데이터 접근을 어떻게 설계할 것인가는 매우 중요한 문제입니다. 특히 규모가 커지고 복잡도가 높아질수록, 데이터베이스와 애플리케이션 로직을 분리하는 방식이 필요합니다. 이러한 요구에 응답하는 패턴 중 하나가 바로 Repository 패턴입니다.

1. Repository 패턴이란?

Repository 패턴은 도메인 로직과 데이터 접근 로직을 분리하여, 애플리케이션이 데이터 저장소(Database, API 등)에 직접 의존하지 않도록 하는 설계 방식입니다. 다시 말해, Repository는 도메인 객체를 수집하고 반환하는 컬렉션(Collection)처럼 동작합니다. 덕분에 데이터 소스가 SQL DB인지, NoSQL인지, 메모리 기반인지 상관없이 일관된 인터페이스로 접근할 수 있습니다.

텍스트 다이어그램

[ Application Service ]
         |
         v
 [   Repository   ]  <---->  [ Data Source ]
         ^                          ^
         |                          |
    [ Domain ]                 [ DB / API / etc ]

Repository는 도메인과 데이터 소스 사이의 추상 계층으로, 도메인 로직이 외부 저장소 세부사항에 영향을 받지 않도록 합니다.

2. 왜 Repository 패턴을 사용하는가?

  1. 의존성 역전(DIP) 실현 도메인 로직은 저장소의 세부 구현이 아니라, 저장소의 인터페이스에 의존합니다.

  2. 테스트 용이성 확보 데이터베이스에 연결하지 않고도 InMemory 저장소를 통해 단위 테스트를 쉽게 할 수 있습니다.

  3. 유연성 강화 데이터 저장소 교체가 필요할 때, Repository 인터페이스를 유지하면서 구현체만 바꾸면 됩니다.

3. 일반적인 구성

(1) 인터페이스 정의

Repository는 도메인 객체를 저장하고 조회하는 메서드를 정의합니다.

interface OrderRepository {
    save(order: Order): void
    get(order_id: string): Order
}

(2) 구현체 제공

구현체는 실제 데이터 소스에 맞게 구현합니다.

  • InMemoryRepository → 단위 테스트에서 사용
  • SQLRepository → 실제 운영 DB와 연동

(3) 서비스 계층에서 활용

서비스 계층은 Repository 인터페이스를 의존하므로, 구현체 교체가 자유롭습니다.

OrderService → (의존) → OrderRepository 인터페이스

4. 다른 패턴과의 비교

  • Active Record: 도메인 객체가 스스로 DB 연산을 수행 → 도메인 로직과 DB 로직이 섞임
  • DAO(Data Access Object): 데이터 접근 객체를 제공하지만 도메인 중심보다는 DB 중심 설계
  • Repository: 도메인 모델에 집중하면서, 데이터 접근을 추상화하여 표현
Active Record: [Domain + Persistence] 혼합
DAO: [DB 중심] 접근 계층
Repository: [Domain 중심] 추상 계층

5. 정리

Repository 패턴은 도메인 중심 아키텍처에서 필수적인 도구입니다.

  • 도메인 로직과 데이터 접근 로직을 분리하고,
  • 테스트 용이성과 유연성을 높이며,
  • 의존성 역전 원칙을 실현합니다.

결국 Repository 패턴은 도메인을 데이터 소스의 제약에서 해방시키는 역할을 하며, 클린 아키텍처와 DDD(도메인 주도 설계)에서도 널리 사용됩니다.

참고

View on GitHub