---
category: Other
tags: [auto-wikified, technical-documentation, other]
title: Active Record Pattern vs Repository Pattern
description: "Active Record 패턴은 데이터베이스 모델의 관심사와 비즈니스 로직을 하나의 객체나 계층에 결합하여 처리하는 설계 방식이다 [1]."
last_updated: 2026-05-04
---

# Active Record Pattern vs Repository Pattern

## 📌 Brief Summary
Active Record 패턴은 데이터베이스 모델의 관심사와 비즈니스 로직을 하나의 객체나 계층에 결합하여 처리하는 설계 방식이다 [1]. 반면 Repository 패턴은 데이터 접근을 전담하는 저장소(Repository) 계층을 분리하고, 모델은 비즈니스 로직이 없는 단순한 객체(dumb models/DTOs)로 유지하는 상반된 접근 방식을 취한다 [1, 2]. 최근 소프트웨어 산업은 모델 중심이 아닌 기능(Feature)을 축으로 비즈니스 로직을 분리하기 위해 점차 Active Record에서 Repository 패턴으로 이동하는 추세를 보이고 있다 [1].

## 📖 Core Content
* **Active Record 패턴의 특성**
  Active Record 패턴은 데이터베이스 모델 내에 데이터 처리와 비즈니스 로직을 함께 구현하는 방식이다 [1]. 과거에는 데이터베이스 관련 관심사를 단순화하여 비즈니스 로직을 직관적으로 표현할 수 있다는 장점이 있었으나, 점차 애플리케이션 규모가 커지고 성능 및 확장성 등 다양한 기술적 관심사가 추가되면서 단일 계층에 너무 많은 책임이 혼재되는 문제를 겪게 되었다 [1].

* **Repository 패턴의 특성 및 구현**
  Repository 패턴은 데이터 접근은 오직 리포지토리를 통해서만 이루어지도록 강제한다 [2]. 이 패턴에서는 모델을 능동적인 객체가 아닌 '단순한 모델(dumb models)이나 DTO'로 정의하며, 실제 비즈니스 로직은 컨트롤러나 서비스 계층에서 담당하도록 관심사를 분리한다 [1]. 
  Spring Boot 환경에서는 Spring Data JPA를 통해 Repository 패턴을 핵심적으로 활용하며, 메서드 이름에 따라 자동으로 쿼리를 생성해 데이터 접근에 필요한 보일러플레이트 코드를 크게 줄여준다 [3]. 이 방식은 관심사의 깔끔한 분리를 유지하면서도 복잡한 데이터베이스 쿼리를 원활히 지원하는 장점이 있다 [4].

## ⚖️ Trade-offs & Caveats
* **Active Record의 관심사 혼재와 부작용 위험**
  Active Record 패턴을 유지하면서 Django의 시그널(Signals)과 같은 기능을 혼용할 경우, 비즈니스 로직이 예기치 않게 곳곳으로 스며들거나(creeping in) 보이지 않는 부수 효과(side-effects)를 발생시켜 시스템을 통제 불능 상태로 만들 수 있는 심각한 안티 패턴을 초래할 수 있다 [1, 5].
* **Repository 패턴의 계층 복잡성**
  Repository 패턴을 적용하면 Controller → Service → Repository로 이어지는 간접 참조(indirection) 및 계층화가 강제되므로, 단순한 로직을 처리할 때도 불필요한 스캐폴딩이 늘어나 애플리케이션 구조가 복잡해질 수 있다 [6]. 따라서 무조건적인 도메인 모델링보다는 도메인의 복잡성이 이를 요구할 만큼 충분히 높을 때 도입하는 것이 권장된다 [2].

---
*Last updated: 2026-05-03*