Files
2nd/10_Wiki/Topics/Architecture/DRY_Principle.md
T

4.7 KiB

category, tags, title, last_updated
category tags title last_updated
Unified
auto-consolidated
technical-documentation
DRY 원칙과 지식의 단일 표현 (Don't Repeat Yourself)
2026-05-02

DRY 원칙과 지식의 단일 표현 (Don't Repeat Yourself)

📌 Brief Summary

"중복은 모든 악의 근원이다." 시스템 내부의 모든 지식은 단 한 번만, 단 하나의 명확한 형태로 존재해야 한다는 원칙이다.

📖 Core Content

  • Core goal: 유지보수성 향상. 기능을 수정할 때 여러 곳을 고쳐야 한다면 반드시 실수하게 되어 있다.
  • Beyond Code: 단순히 '복사-붙여넣기' 코드를 줄이는 것뿐만 아니라, DB 스키마, 테스트 케이스, 문서화 등 프로젝트 전반의 정보 중복을 제거하는 것을 포함한다.
  • Mechanisms: 함수화, 클래스화, 모듈화, 상수 관리 등을 통해 구현한다.

⚖️ Trade-offs & Caveats

  • DRY를 맹신하면 '성급한 추상화(Premature Abstraction)'에 빠지게 된다. 모양만 같고 '의미(Semantics)'가 다른 두 코드를 억지로 합치면, 나중에 각자의 비즈니스 로직이 달라질 때 코드가 꼬여버린다. 이럴 때는 차라리 중복을 허용하는 'WET(Write Everything Twice)'가 나을 수도 있다.

🔗 Knowledge Connections

  • Separation_of_Concerns: 중복을 제거하기 위해 코드를 어떤 기준으로 나누어야 하는지에 대한 원칙.
  • SOLID_Principles: 중복 제거와 설계의 건전성을 동시에 확보하기 위한 5대 원칙.
  • Technical_Debt: DRY 원칙을 무시했을 때 발생하는 유지보수 비용의 총칭.

1. 개요

DRY(Don't Repeat Yourself) 원칙은 "시스템 내의 모든 지식은 단일하고, 명확하며, 신뢰할 수 있는 표현을 가져야 한다"는 소프트웨어 개발의 핵심 원칙이다. 이는 단순히 코드의 텍스트가 겹치는 '구문적 중복'을 넘어, 비즈니스 규칙이나 데이터 모델링 등의 '지식의 중복'을 제거함으로써 시스템의 복잡성을 낮추고 변경 시의 일관성을 보장하는 것을 목표로 한다.

2. 주요 실천 방안

  • 추상화 및 모듈화: 반복되는 로직을 재사용 가능한 함수, 유틸리티 클래스, 혹은 공통 라이브러리로 추출하여 중앙에서 관리.
  • 상속과 합성: 객체 지향 언어의 특징을 활용하여 공통 속성과 동작을 기본 클래스(Base Class)에 배치하거나, 작은 컴포넌트들을 조합하여 복잡한 기능 구현.
  • 중앙 집중식 구성 관리: DB 연결 정보, API 엔드포인트 등 환경 설정 값을 코드 곳곳에 하드코딩하지 않고, 중앙 설정 파일이나 환경 변수를 통해 관리(SSOT: Single Source of Truth).
  • 자동화된 코드 생성: 반복적이고 정형화된 보일러플레이트(Boilerplate) 코드는 수동 작성이 아닌 템플릿 엔진이나 코드 생성기를 활용하여 오타와 누락 방지.

3. 엔지니어링 가치

  • 수정의 효율성: 특정 비즈니스 규칙이 변경될 때, 중복이 제거된 시스템에서는 단 한 곳의 코드만 수정하면 되므로 변경 비용이 획기적으로 절감됨.
  • 데이터 무결성 및 일관성: 동일한 로직이 여러 곳에 흩어져 있어 발생할 수 있는 '일부 누락' 현상을 방지하여, 시스템 전반의 동작 신뢰성 확보.
  • 가독성 향상: 핵심 로직이 명확하게 정의된 지점(Single Point of Truth)에 집중되어 있어, 개발자가 시스템의 의도를 파악하는 속도 향상.

4. 트레이드오프 및 주의사항

  • 성급한 추상화(Premature Abstraction)의 위험: 아직 명확한 패턴이 발견되지 않은 상태에서 무리하게 중복을 제거하려다 오히려 코드 구조가 복잡해질 수 있음. '3의 법칙(Rule of Three)'을 고려할 것.
  • 우연한 중복(Accidental Duplication): 모양은 같지만 비즈니스적 의미가 다른 두 코드를 억지로 하나로 묶으면, 향후 두 로직이 서로 다른 방향으로 진화할 때 강결합으로 인한 유지보수 대란 발생 가능.
  • 가독성과의 충돌: 지나친 추상화는 코드를 직접적으로 읽는 것을 방해할 수 있다. 때로는 약간의 중복이 과도한 추상화보다 더 명확하고 단순할 때가 있음.

🧪 검증 상태 (Validation)

  • 정보 상태: 검증 완료 (Verified)
  • 출처 신뢰도: A
  • 검토 이유: 시스템의 일관성을 유지하고 변경에 기민하게 대응하기 위한 지식 관리 및 중복 제거 표준 정립.