DRY Principle

DRY(Don’t Repeat Yourself) Principle

DRY(Don’t Repeat Yourself) 는 소프트웨어 개발에서 중복된 코드, 데이터, 문서 등을 제거하고, 각각의 지식이나 로직이 시스템 내에서 유일하게 정의되도록 하는 설계 원칙이다. 이 원칙은 코드 재사용, 유지보수성 향상, 오류 감소, 일관성 확보 등 다양한 이점을 제공하며, 함수, 모듈, 컴포넌트, 설정 파일 등 다양한 수준에서 적용된다. 하지만 과도한 추상화나 무분별한 적용은 오히려 복잡성을 초래할 수 있으므로, 상황에 맞는 균형 잡힌 적용이 필요하다.

핵심 개념

DRY 원칙은 “Every piece of knowledge must have a single, unambiguous, authoritative representation within a system” (모든 지식은 시스템 내에서 단일하고 명확하며 권위 있는 표현을 가져야 한다) 라는 철학을 기반으로 한다.

핵심 요소:

• 지식의 단일성 (Knowledge Singularity): 동일한 비즈니스 로직이나 알고리즘은 한 곳에만 존재
• 권위적 표현 (Authoritative Representation): 특정 기능에 대한 명확한 소스
• 추상화 (Abstraction): 공통 로직을 재사용 가능한 형태로 변환
• 코드 재사용성 (Code Reusability): 중복 제거를 통한 효율성 향상

코드, 데이터베이스 스키마, 문서, 테스트, 빌드 시스템 등 소프트웨어 전 영역에 적용되며, 중복을 제거하여 유지보수성을 높이고, 일관성을 보장하며, 오류 발생 가능성을 줄이는 것을 목표로 한다.
함수/메서드 추출, 모듈화, 컴포넌트화, 설정 파일 분리, 디자인 패턴 활용 등 다양한 기법으로 구현할 수 있으며, 무분별한 추상화나 조기 적용은 오히려 복잡성과 기술부채 (Technical Debt) 를 유발할 수 있으므로, 상황에 맞는 적용이 중요하다.
DRY 를 효과적으로 적용하려면 맥락을 고려하고, 점진적으로 리팩토링하며, 테스트로 변경 사항을 뒷받침하고, 공통점과 차이점을 명확히 식별해야 한다. 현대적인 소프트웨어 개발에서 DRY 는 여전히 중요하지만, 마이크로서비스, 분산 시스템 및 대규모 애플리케이션에서는 상황에 맞게 적용해야 한다.

배경

DRY 원칙은 1999 년 Andy Hunt 와 Dave Thomas 가『The Pragmatic Programmer』에서 공식적으로 정의했다. 이 원칙은 소프트웨어 개발에서 발생하는 지식 중복 (Knowledge Duplication) 문제를 해결하기 위해 고안되었다.

역사적 배경:

• 대규모 소프트웨어 프로젝트에서 코드 중복으로 인한 유지보수 문제 증가
• 객체지향 프로그래밍 패러다임 발전과 함께 모듈화 필요성 증대
• 소프트웨어 복잡성 증가에 따른 체계적인 설계 원칙 필요

목적 및 필요성

주요 목적:

1. 유지보수성 향상: 변경사항을 한 곳에서만 수정
2. 일관성 보장: 동일한 로직의 일관된 동작 보장
3. 오류 감소: 중복 코드로 인한 불일치 오류 방지
4. 개발 효율성: 재사용을 통한 개발 시간 단축

필요성:

• 코드 중복으로 인한 기술 부채 (Technical Debt) 축적 방지
• 대규모 팀 협업 시 코드 일관성 유지
• 장기적인 소프트웨어 유지보수 비용 절감

주요 기능 및 역할

핵심 원칙

1. Once and Only Once: 모든 지식은 정확히 한 번만 표현
2. Single Source of Truth: 각 정보의 권위적 소스 존재
3. Abstraction over Duplication: 중복보다는 추상화 선택
4. Logical Cohesion: 논리적으로 관련된 요소들의 응집

주요 원리 및 작동 원리

graph TD
    A[중복 코드 식별] --> B[공통 로직 추출]
    B --> C[추상화 설계]
    C --> D[재사용 가능한 구성요소 생성]
    D --> E[기존 코드에서 참조]
    E --> F[유지보수 및 확장]
    
    subgraph "DRY 적용 과정"
        G[Before: 중복 코드] --> H[분석 및 식별]
        H --> I[리팩토링]
        I --> J[After: 단일 구현]
    end

작동 원리:

1. 중복 식별: 유사하거나 동일한 로직 찾기
2. 패턴 분석: 중복의 근본 원인 파악
3. 추상화 설계: 공통 인터페이스나 베이스 클래스 설계
4. 구현 통합: 단일 구현체로 통합
5. 참조 변경: 기존 중복 코드를 새로운 구현 참조로 변경

구조 및 아키텍처

DRY 원칙을 적용한 시스템의 구조는 다음과 같다:

graph TB
    subgraph "DRY 아키텍처 구조"
        A[클라이언트 코드 1] --> D[공통 추상화 레이어]
        B[클라이언트 코드 2] --> D
        C[클라이언트 코드 3] --> D
        
        D --> E[핵심 비즈니스 로직]
        D --> F[유틸리티 함수]
        D --> G[데이터 모델]
        
        E --> H[데이터베이스]
        F --> H
        G --> H
    end

구현 기법

graph TD
    A[비즈니스 로직] -->|공통 로직| B[함수/모듈/컴포넌트]
    B -->|재사용| C[여러 기능/화면/서비스]
    D[설정 파일/문서화] -->|참조| C
    E[DB 스키마] -->|정규화| C

구현 기법 예시

1. 함수 추출 (Function Extraction)

   • 정의: 중복된 코드 블록을 독립적인 함수로 분리
   • 구성: 매개변수화된 공통 로직
   • 목적: 코드 재사용성 향상
   • 예시:

   1 2 3 4 5 6 7 8 9 10 11 12

   // Before DRY function calculateTaxForEmployee(salary) { return salary * 0.2; } function calculateTaxForContractor(payment) { return payment * 0.2; } // After DRY function calculateTax(amount) { return amount * 0.2; }

2. 클래스 상속 (Class Inheritance)

   • 정의: 공통 기능을 부모 클래스에 정의
   • 구성: 베이스 클래스와 파생 클래스
   • 목적: 계층적 코드 재사용
   • 시나리오: 동물 클래스에서 공통 행동 정의, 개별 동물 클래스에서 특화된 행동 구현

   1 2 3 4 5 6 7

   class Animal: def speak(self): return "makes a sound" class Dog(Animal): def speak(self): return "barks"

3. 컴포지션 (Composition)

   • 정의: 기능을 독립적인 컴포넌트로 분리하여 조합
   • 구성: 독립적인 서비스 객체들의 조합
   • 목적: 유연한 객체 구성
   • 시나리오: 결제 시스템에서 검증, 처리, 로깅 컴포넌트를 독립적으로 구성

   1 2 3 4 5 6 7 8 9 10 11 12 13 14

   class PaymentProcessor { constructor(validator, executor, logger) { this.validator = validator; this.executor = executor; this.logger = logger; } process(paymentData) { if (this.validator.validate(paymentData)) { this.executor.execute(paymentData); this.logger.log(paymentData); } } }

4. 설정 기반 프로그래밍 (Configuration-Driven Programming)

   • 정의: 코드 로직을 설정 파일로 외부화
   • 구성: 설정 파일 + 해석 엔진
   • 목적: 코드 변경 없는 동작 수정
   • 시나리오: 비즈니스 규칙을 JSON 설정으로 관리

   1 2 3 4 5

   // discount_rules.json { "VIP": 0.2, "REGULAR": 0.1 }

   1 2 3

   function getDiscountRate(userType, config) { return config[userType] || 0; }

장점과 단점

도전 과제 및 해결책

분류에 따른 종류

• 적용 범위는 DRY 가 코드 단위에만 적용되는 것이 아닌, 모듈 및 전체 시스템 단위까지 확장될 수 있음을 보여준다.
• 구현 방식은 DRY 를 실현하는 기술적 전략 (상속/조합/설정) 을 나누며, 각각 유지보수성과 유연성에 다른 영향을 준다.
• 추상화 정도는 중복 제거의 범위와 깊이를 결정하는 기준으로, 프로젝트 성숙도나 팀 역량에 따라 달라질 수 있다.

시스템 레벨 DRY

시스템 레벨에서 DRY(Don’t Repeat Yourself) 원칙을 적용한다는 것은 단순히 함수나 모듈의 중복 코드를 제거하는 것을 넘어서, 시스템 전반 (설계, 아키텍처, 인프라, API, 데이터모델 등) 에서 지식 (knowledge) 의 중복을 제거하고 변경을 단일화 (single-source-of-truth) 하는 것을 의미한다.

시스템 수준 DRY 적용 구조 예시

graph TD
  subgraph 공통 모듈
    A1[유틸 라이브러리] --> SVC1[Service A]
    A1 --> SVC2[Service B]
    A2[공통 인증 서비스] --> SVC1
    A2 --> SVC2
  end

  SVC1 --> API1[공통 API DTO]
  SVC2 --> API2[공통 API DTO]
  
  subgraph 인프라
    I1[Terraform Module: VPC]
    I2[Terraform Module: DB]
  end
  
  DEV1[Dev Environment] --> I1
  STG1[Staging] --> I1
  PRD1[Production] --> I2

분류에 따른 유형

• 함수형 DRY는 함수 중심으로 데이터 처리에 적합하고, 사이드 이펙트를 최소화한다.
• 객체지향 DRY는 구조화된 코드 베이스와 계층적 재사용에 유용하다.
• 설정 중심 DRY는 하드코딩 제거와 환경 유연성을 보장하며, 배포/운영 자동화에 적합하다.
• 템플릿 기반 DRY는 반복되는 프론트엔드, 마크업, 코드 생성을 효과적으로 통제한다.

설정 중심 DRY (Configuration-Driven DRY)

설정 중심 DRY는 코드 내의 반복되는 상수, 분기, 조건, 기능 구성 등을 코드 외부의 설정 파일 (configuration file) 로 분리하여 중복을 제거하고 유연성을 확보하는 접근 방식이다. 환경 변화나 기능 변경 시, 코드를 수정하지 않고도 설정 변경만으로 대응이 가능하게 설계한다.

목적:

• 하드코딩된 값이나 반복되는 조건 분기 로직을 설정으로 분리하여 중복 제거
• 개발, 테스트, 운영 등 다양한 환경에서 설정 파일만 변경하여 시스템 구성 가능
• 설정값 변경 시 코드 수정 없이 설정만 수정하면 되어 배포 및 테스트 부담 감소
• 운영/비개발 인력도 설정 파일만으로 일부 기능 제어 가능, DevOps 및 IaC(Infrastructure as Code) 에 적합

구성 요소:

예시:

1
2
3

# .env
PORT=3000
DB_HOST=localhost

1
2
3
4
5
6
7

// config.js
require('dotenv').config();

module.exports = {
  port: process.env.PORT,
  dbHost: process.env.DB_HOST,
};

1
2
3
4
5
6

// server.js
const config = require('./config');

app.listen(config.port, () => {
  console.log(`Server running on port ${config.port}`);
});

템플릿화 구현

템플릿화 (Templatization) 는 반복되는 코드 또는 UI 구조를 템플릿으로 추출하여, 중복을 줄이고 재사용성을 높이는 구현 기법이다. 주로 HTML UI, 이메일, 보고서, 코드 생성, SQL 쿼리 등에서 활용된다.

목적:

• 반복되는 구조의 중복 제거
• UI/출력 형식 일관성 유지
• 변경 시 단일 위치에서 수정 가능
• 재사용성 향상

구성 요소:

예시:

• 웹 UI 템플릿화 (Flask + Jinja2)

  1. 템플릿 파일 (product_card.html):

  1 2 3 4 5

  <div class="product"> <h3>{{ product.name }}</h3> <p>{{ product.description }}</p> <strong>${{ product.price }}</strong> </div>

  2. 부모 템플릿 (base.html):

  1 2 3 4 5 6 7 8 9

  <!DOCTYPE html> <html> <head><title>{% block title %}{% endblock %}</title></head> <body> <div class="container"> {% block content %}{% endblock %} </div> </body> </html>

  3. 페이지 템플릿 (home.html):

  1 2 3 4 5 6

  {% extends "base.html" %} {% block content %} {% for product in products %} {% include "product_card.html" %} {% endfor %} {% endblock %}

• Python 이메일 템플릿화 (Jinja2)

  1 2 3 4 5

  from jinja2 import Template template = Template("안녕하세요 {{ name }}님, 주문이 완료되었습니다.") output = template.render(name="홍길동") print(output) # 안녕하세요 홍길동님, 주문이 완료되었습니다.

실무 적용 예시

DRY vs. KISS 원칙

• 두 원칙은 상호 보완적이다.

  • DRY 를 적용하되 KISS 수준에서 적절하게 추상화하는 것이 실무의 핵심이다.

• 예: 복잡한 공통 로직을 추상화하면서도, 과도한 계층을 피하는 단순한 API 설계

충돌 가능 사례

SRP 와 DRY

SRP 의 적용은 책임을 분리하여 중복의 발생 지점을 명확하게 하며, DRY 는 중복된 로직을 추출하게 만들어 자연스럽게 책임이 응집되도록 유도한다. DRY 와 SRP 는 서로 다른 방향에서 시작되지만, 결과적으로 코드를 간결하고 유지보수 가능하게 만드는 목표는 동일하다. 실무에서는 두 원칙을 함께 고려한 설계와 리팩토링이 필수적이다.

예시

상황: 사용자의 주문 데이터를 저장하고, 저장 후 알림을 보내는 로직이 다음과 같다고 가정

1
2
3
4

def process_order(order_data):
    save_to_database(order_data)
    send_email_notification(order_data)
    send_sms_notification(order_data)

• 위 코드는 중복은 없지만 SRP 위반이다. 한 함수에 여러 책임 (저장, 이메일, SMS 발송) 이 있다.

SRP 적용

1
2
3
4
5
6
7
8

class OrderService:
    def save(self, order_data):
        save_to_database(order_data)

class NotificationService:
    def notify(self, order_data):
        send_email_notification(order_data)
        send_sms_notification(order_data)

DRY 적용

1
2
3
4
5
6
7
8

class NotificationService:
    def _notify_via(self, method, data):
        # 공통 포맷팅, 로깅 등 중복 로직 제거
        method(data)

    def notify(self, data):
        self._notify_via(send_email_notification, data)
        self._notify_via(send_sms_notification, data)

이렇게 하면 SRP 로 책임이 분리되고, DRY 로 중복된 처리 로직도 제거된다.

활용 사례

사례 1: 전자상거래 플랫폼의 제품 필터링 시스템

시나리오: 온라인 쇼핑몰에서 제품 검색, 추천, 관련 상품 페이지에서 유사한 필터링 로직이 중복 구현되어 유지보수에 어려움을 겪고 있다.

시스템 구성:

graph TB
    subgraph "Before DRY"
        A1[검색 페이지] --> B1[검색 필터링 로직]
        A2[추천 페이지] --> B2[추천 필터링 로직]  
        A3[관련상품 페이지] --> B3[관련상품 필터링 로직]
    end
    
    subgraph "After DRY"
        C1[검색 페이지] --> D[공통 필터링 서비스]
        C2[추천 페이지] --> D
        C3[관련상품 페이지] --> D
        
        D --> E[필터 엔진]
        D --> F[정렬 엔진]
        D --> G[페이징 엔진]
    end

Workflow:

1. 중복 식별: 각 페이지의 필터링 로직 분석
2. 공통 인터페이스 설계: ProductFilterService 인터페이스 정의
3. 핵심 로직 구현: FilterEngine, SortEngine, PagingEngine 구현
4. 통합 서비스 개발: 모든 필터링 요구사항을 처리하는 단일 서비스
5. 기존 코드 리팩토링: 각 페이지에서 공통 서비스 사용

역할:

• FilterEngine: 조건 기반 상품 필터링
• SortEngine: 다양한 정렬 옵션 제공
• PagingEngine: 페이징 처리
• ProductFilterService: 통합 인터페이스 제공

사례 2: 전자상거래 웹사이트

시나리오: 전자상거래 웹사이트에서 제품 정보를 여러 페이지 (홈, 상세보기, 장바구니, 결제 등) 에 공통적으로 출력해야 하는 경우

시스템 구성:

활용된 DRY 전략:

• 제품 정보를 표시하는 로직은 product_utils.py 에 함수로 작성되어 재사용
• 공통 UI 블록 (제품 썸네일, 가격, 버튼) 은 product_card.html 템플릿으로 분리
• 여러 페이지 (홈, 장바구니, 위시리스트 등) 에서 이 템플릿을 include 하여 중복 제거

시스템 구성 다이어그램

graph TD
A[Flask 라우팅] --> B["공통 함수 (product_utils.py)"]
A --> C["템플릿 렌더링 (Jinja2)"]
C --> D["공통 UI 템플릿 (product_card.html)"]
C --> E["개별 페이지 템플릿 (home.html, cart.html)"]
B --> F["DB 조회 (SQLAlchemy)"]
F --> G[PostgreSQL]

Workflow:

1. 클라이언트 요청 → Flask 라우터로 전달
2. 제품 ID 기반 데이터베이스 조회 수행
3. 공통 함수로 제품 정보 포맷팅
4. 제품 정보를 공통 UI 템플릿에 바인딩
5. 여러 페이지에서 동일한 UI 구성으로 출력

역할 정리:

실무에서 효과적으로 적용하기 위한 고려사항 및 주의할 점

최적화하기 위한 고려사항 및 주의할 점

• DRY 원칙을 적용할 때는 단순히 중복 제거에 집중하는 것이 아니라, 추상화의 비용과 성능적 여파까지 고려한 균형 있는 설계가 중요하다. 특히, **핫 경로 (Hot Path)**나 반복 호출이 많은 로직에는 선택적으로 중복을 허용하고 별도 최적화하는 전략이 권장된다.

대안적 접근

WET(Write Everything Twice)

핵심: " 반복을 허용하라 " 는 관점으로, 명확성과 독립성을 중시한다.
특징:

• 중복된 코드가 오히려 명확성을 높이고, 각 부분이 독립적으로 유지될 수 있다.
• 특히 작은 프로젝트, 테스트 코드, 특별한 요구사항이 있는 경우에 효과적.
  단점:
• 중복이 많아질수록 유지보수 비용이 증가하고, 여러 곳을 동시에 수정해야 할 위험이 있다.

AHA(Avoid Hasty Abstractions)

핵심: " 성급한 추상화를 피하라 " 는 원칙.
특징:

• 중복이 불편해질 때까지 기다렸다가, 충분히 패턴이 명확해졌을 때만 추상화한다.
• 잘못된 추상화 (wrong abstraction) 로 인한 리팩토링 비용을 줄인다.
• 변화 가능성, 실제 사용 사례가 쌓인 뒤에 적절한 추상화를 도입.
  장점:
• 유연성, 실질적 필요성에 기반한 추상화로 코드의 견고함과 유지보수성을 높임.
  단점:
• 중복이 일정 기간 남아 있을 수 있음.

DRY Vs 대안적 접근 (WET, AHA) 비교

• DRY 는 중복 제거와 추상화에 집중하지만, 과도한 적용은 오히려 유지보수성을 해칠 수 있다.
• WET 와 AHA 는 중복을 허용하거나, 추상화의 타이밍을 늦추는 방식으로, 명확성·유연성을 중시한다.
• 실제로는 세 가지 원칙을 상황에 맞게 조합하여 사용하는 것이 가장 효과적이다.

주제와 관련하여 주목할 내용

9. 하위 주제별 추가 학습 필요 내용

관련 분야별 추가 학습 내용

용어 정리

설계 원칙 및 소프트웨어 철학

객체지향 및 모듈 설계 관련

소프트웨어 아키텍처 및 패턴

코드 품질 및 도구

개발 및 운영 도구 관련

성능/데이터 이슈

협업 및 개발 문화

참고 및 출처

공식/학술적 정의 및 원칙 설명

• Don’t Repeat Yourself - Wikipedia
• Martin Fowler – DRY Principle
• Martin Fowler – Code Smells
• Refactoring Guru – DRY 설명
• Refactoring Guru – SRP 설명
• Robert C. Martin – SOLID Principles

온라인 실무 가이드 및 설명

• DRY Software Design Principle - Baeldung
• Understanding the DRY Principle - Plutora
• The DRY Principle: Benefits and Costs with Examples - The Valuable Dev
• Software Design Principles DRY and KISS - DZone
• DRY vs KISS vs YAGNI Principles - Design Gurus
• Don’t Repeat Yourself in Software Development - GeeksforGeeks
• DRY Principle Java Examples - GeeksforGeeks
• TechTarget – DRY 정의
• Pixelfreestudio – DRY 실무 적용
• DEV Community – DRY 적용 사례
• Zetaton – Mastering the DRY Principle
• Sensiolabs – DRY와 코드 재사용의 균형
• Code.mu – DRY와 관련 원칙 요약
• ThoughtWorks – DRY Applied at System Scale

기술 적용 사례 및 실습 자료

• Real Python – The DRY Principle
• University of Auckland – DRY Principle (2.7)

프레임워크 및 도구 관련 자료

• Terraform Modules Guide
• Helm Chart Templates
• OpenAPI Reusable Schemas
• Jinja2 공식 문서
• Flask 공식 문서
• Flask 템플릿 구조 가이드

커뮤니티 토론/비판적 시각

• DRY Principle in Java - Stack Overflow
• Composition over Inheritance and DRY - Stack Overflow
• DRY Principle Complexity Issues - Software Engineering SE
• DRY is Overrated - Hacker News
• Code Conservatory – DRY Principle Analysis
• DigitalOcean – What is DRY Development

다양한 개발 영역에서의 DRY 적용

DRY 원칙은 코드 자체뿐만 아니라 소프트웨어 개발의 여러 측면에 적용될 수 있다:

데이터베이스 설계

정규화는 관계형 데이터베이스에서 DRY 원칙을 적용하는 방법이다.
이는 데이터 중복을 최소화하고 데이터 무결성을 보장한다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

-- DRY하지 않은 데이터베이스 설계
CREATE TABLE orders (
    order_id INT PRIMARY KEY,
    customer_name VARCHAR(100),
    customer_email VARCHAR(100),
    product_id INT,
    product_name VARCHAR(100),
    product_price DECIMAL(10, 2),
    quantity INT
);

-- DRY한 정규화된 설계
CREATE TABLE customers (
    customer_id INT PRIMARY KEY,
    name VARCHAR(100),
    email VARCHAR(100)
);

CREATE TABLE products (
    product_id INT PRIMARY KEY,
    name VARCHAR(100),
    price DECIMAL(10, 2)
);

CREATE TABLE orders (
    order_id INT PRIMARY KEY,
    customer_id INT REFERENCES customers(customer_id),
    product_id INT REFERENCES products(product_id),
    quantity INT
);

사용자 인터페이스 개발

컴포넌트 기반 UI 프레임워크 (React, Vue, Angular 등) 는 UI 요소를 재사용 가능한 컴포넌트로 추상화하여 DRY 원칙을 구현한다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44

// DRY하지 않은 UI 코드
function UserProfile() {
    return (
        <div className="card">
            <div className="card-header">사용자 프로필</div>
            <div className="card-body">…</div>
        </div>
    );
}

function ProductDetails() {
    return (
        <div className="card">
            <div className="card-header">제품 상세정보</div>
            <div className="card-body">…</div>
        </div>
    );
}

// DRY 적용: 재사용 가능한 Card 컴포넌트
function Card({ title, children }) {
    return (
        <div className="card">
            <div className="card-header">{title}</div>
            <div className="card-body">{children}</div>
        </div>
    );
}

function UserProfile() {
    return (
        <Card title="사용자 프로필">
            …
        </Card>
    );
}

function ProductDetails() {
    return (
        <Card title="제품 상세정보">
            …
        </Card>
    );
}

테스트

테스트 코드에서도 DRY 원칙을 적용하여 설정, 데이터 생성, 단언 등에서 중복을 줄일 수 있다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85

// DRY하지 않은 테스트 코드
describe('User service', () => {
    let database;
    
    beforeEach(() => {
        database = new Database();
        database.connect();
    });
    
    afterEach(() => {
        database.disconnect();
    });
    
    it('should create a user', () => {
        const user = { name: 'John', email: 'john@example.com' };
        const result = createUser(database, user);
        expect(result.success).toBe(true);
    });
});

describe('Product service', () => {
    let database;
    
    beforeEach(() => {
        database = new Database();
        database.connect();
    });
    
    afterEach(() => {
        database.disconnect();
    });
    
    it('should create a product', () => {
        const product = { name: 'Phone', price: 999 };
        const result = createProduct(database, product);
        expect(result.success).toBe(true);
    });
});

// DRY 적용: 공통 테스트 설정 추출
function setupDatabase() {
    const database = new Database();
    database.connect();
    return database;
}

function teardownDatabase(database) {
    database.disconnect();
}

describe('User service', () => {
    let database;
    
    beforeEach(() => {
        database = setupDatabase();
    });
    
    afterEach(() => {
        teardownDatabase(database);
    });
    
    it('should create a user', () => {
        const user = { name: 'John', email: 'john@example.com' };
        const result = createUser(database, user);
        expect(result.success).toBe(true);
    });
});

describe('Product service', () => {
    let database;
    
    beforeEach(() => {
        database = setupDatabase();
    });
    
    afterEach(() => {
        teardownDatabase(database);
    });
    
    it('should create a product', () => {
        const product = { name: 'Phone', price: 999 };
        const result = createProduct(database, product);
        expect(result.success).toBe(true);
    });
});

인프라 및 배포

인프라스트럭처 코드에서도 DRY 원칙을 적용할 수 있다. 인프라스트럭처 as 코드 (IaC) 도구를 사용하면 인프라 설정에서 중복을 줄일 수 있다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48

# DRY하지 않은 Terraform 설정
resource "aws_instance" "web_server_1" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t2.micro"
  vpc_security_group_ids = ["sg-12345678"]
  subnet_id     = "subnet-12345678"
  tags = {
    Name = "WebServer1"
  }
}

resource "aws_instance" "web_server_2" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t2.micro"
  vpc_security_group_ids = ["sg-12345678"]
  subnet_id     = "subnet-12345678"
  tags = {
    Name = "WebServer2"
  }
}

# DRY 적용: 모듈 및 변수 사용
variable "ami_id" {
  default = "ami-0c55b159cbfafe1f0"
}

variable "instance_type" {
  default = "t2.micro"
}

variable "security_group_ids" {
  default = ["sg-12345678"]
}

variable "subnet_id" {
  default = "subnet-12345678"
}

module "web_server" {
  source = "./modules/web_server"
  count  = 2
  
  ami           = var.ami_id
  instance_type = var.instance_type
  vpc_security_group_ids = var.security_group_ids
  subnet_id     = var.subnet_id
  name          = "WebServer${count.index + 1}"
}

실제 사례 연구: DRY 원칙 적용

다음은 실제 애플리케이션에서 DRY 원칙을 적용하는 사례 연구:

사례 1: 코드 생성기

많은 프레임워크와 도구는 코드 생성을 사용하여 중복을 줄인다. 예를 들어, Ruby on Rails 의 스캐폴딩은 일반적인 CRUD 작업에 대한 코드를 자동 생성한다.

사례 2: 마이크로서비스의 공유 라이브러리

마이크로서비스 아키텍처에서는 인증, 로깅, 오류 처리 등의 공통 기능을 위한 공유 라이브러리를 만들어 서비스 간 코드 중복을 줄일 수 있다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

// 공유 라이브러리: 인증 및 인가
package com.company.shared.auth;

public class AuthService {
    public static User authenticate(String token) {
        // 토큰 검증 및 사용자 정보 반환
    }
    
    public static boolean authorize(User user, String permission) {
        // 사용자 권한 확인
    }
}

// 마이크로서비스에서 사용
import com.company.shared.auth.AuthService;

@RestController
public class UserController {
    @GetMapping("/users/{id}")
    public User getUser(@RequestHeader("Authorization") String token, @PathVariable Long id) {
        User currentUser = AuthService.authenticate(token);
        if (!AuthService.authorize(currentUser, "READ_USER")) {
            throw new UnauthorizedException();
        }
        // 사용자 조회 로직
    }
}

사례 3: CSS 프레임워크

Bootstrap 과 같은 CSS 프레임워크는 공통 UI 패턴을 추상화하여 스타일 코드의 중복을 줄인다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

<!-- DRY하지 않은 CSS -->
<div style="margin: 20px; padding: 15px; border: 1px solid #ddd; border-radius: 5px;">
    <h2 style="font-size: 20px; margin-bottom: 10px;">제목</h2>
    <p style="line-height: 1.5;">내용…</p>
</div>

<!-- Bootstrap을 사용한 DRY 접근 방식 -->
<div class="card m-3">
    <div class="card-body">
        <h2 class="card-title">제목</h2>
        <p class="card-text">내용…</p>
    </div>
</div>

DRY 원칙의 진화와 현대적 적용

시간이 지남에 따라 DRY 원칙에 대한 이해와 적용은 진화해 왔다:

마이크로서비스 및 분산 시스템에서의 DRY

마이크로서비스 아키텍처에서는 서비스 간 중복이 때로는 허용된다. 각 서비스가 독립적으로 발전할 수 있도록 특정 유형의 중복이 허용되거나 심지어 권장되기도 한다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

// 서비스 A에서의 사용자 모델
public class User {
    private String id;
    private String name;
    private String email;
    // 서비스 A에 필요한 필드만 포함
}

// 서비스 B에서의 사용자 모델
public class User {
    private String id;
    private String name;
    private String address;
    // 서비스 B에 필요한 필드만 포함
}

이러한 중복은 서비스 간 결합을 줄이고 독립적인 배포를 가능하게 한다.

DRY 와 아키텍처 경계

DRY 는 아키텍처의 동일한 계층이나 경계 내에서 더 엄격하게 적용되어야 하지만, 다른 계층이나 경계를 가로지를 때는 중복을 더 관대하게 허용할 수 있다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

// 도메인 계층에서의 검증 로직
export class UserDomain {
    static validateEmail(email: string): boolean {
        return /^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(email);
    }
}

// API 계층에서의 유사한 검증
// 아키텍처 경계를 가로지르는 일부 중복은 허용됨
export class UserController {
    validateUserInput(user: any): boolean {
        if (!user.email || !/^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(user.email)) {
            return false;
        }
        // 기타 검증…
        return true;
    }
}

의도적 DRY 위반

때로는 성능, 안정성 또는 독립성을 위해 의도적으로 DRY 를 위반하는 것이 합리적일 수 있다.

1
2
3
4
5
6
7
8

// 성능을 위한 의도적 DRY 위반
public class PerformanceCriticalCode {
    public double calculateFast(double x) {
        // 외부 함수 호출 없이 직접 계산
        // 함수 호출 오버헤드를 피하기 위해 일부 로직 중복
        return x * x * 3.14159265359;
    }
}