DRY 원칙 (Don't Repeat Yourself)

📌 Brief Summary

DRY(Don't Repeat Yourself) 원칙은 시스템 내의 모든 지식과 로직이 단일하고 명확하며 권위 있는 표현을 가져야 한다는 소프트웨어 개발의 핵심 원칙이다 [1]. 앤디 헌트와 데이브 토마스의 저서 '실용주의 프로그래머'에서 대중화된 이 개념은 코드와 정보의 중복을 줄이는 것을 목표로 한다 [1]. 동일한 로직이 여러 곳에 복사 및 붙여넣기 되는 것을 방지하여, 단일 변경 사항이 코드베이스 전체에 일관되게 적용되도록 함으로써 기술 부채를 최소화하고 장기적인 유지보수성을 높인다 [1].

📖 Core Content

DRY 원칙은 공통 기능을 재사용 가능한 컴포넌트로 추상화하여 로직이 단 한 곳에만 존재하도록 보장하는 방식으로 구현된다 [2].

유틸리티 함수 및 라이브러리 활용: 데이터 검증이나 포맷팅 로직 등이 애플리케이션 여러 부분에서 반복될 경우, 이를 중앙 유틸리티 함수나 공유 라이브러리로 추출하여 통합 관리한다 [2].
기본 클래스 및 상속(객체 지향 프로그래밍): 여러 클래스에서 공유되는 공통 동작이나 속성을 기본 클래스(Base Class)에 배치하고, 다른 하위 클래스들이 이를 상속받아 기능을 사용하도록 설계하여 재정의를 방지한다 [2].
구성 관리의 중앙화: 데이터베이스 연결 문자열이나 API 키와 같은 환경 구성 값을 여러 파일에 하드코딩하는 대신, 전체 애플리케이션이 참조할 수 있는 단일 중앙 구성 파일에 저장한다 [2].
논리적 중복의 제거: 단순히 동일한 코드 라인이 반복되는 '구문적 중복(syntactic duplication)'에 그치지 않고, 동일한 비즈니스 규칙이나 개념이 반복되는 '논리적 중복(logical duplication)'을 식별하고 통합하는 데 집중해야 한다 [3].
프레임워크의 활용: 인증, 라우팅, 데이터 접근 등 공통적인 소프트웨어 개발 작업에 잘 확립된 프레임워크와 라이브러리를 활용하면, 바퀴를 다시 발명하는 수고를 덜고 DRY 원칙을 효과적으로 준수할 수 있다 [3].

⚖️ Trade-offs & Caveats

DRY 원칙을 맹목적으로 적용할 경우 불필요한 복잡성을 더하는 '성급한 추상화(Premature abstraction)'로 이어질 수 있다 [3]. 이를 방지하기 위해 코드가 최소 두 번 이상 중복되는 것을 목격한 후에 추상화를 결정하는 '3의 규칙(Rule of Three)'을 따르는 것이 강력히 권장된다 [3]. 또한 지나친 추상화로 인해 코드가 심하게 꼬이는 것보다는 약간의 중복을 허용하는 것이 오히려 읽기 쉽고 덜 복잡할 때가 있으므로, 개발자는 원칙의 기계적인 준수보다 코드의 명확성(Clarity)과 단순성을 항상 우선시해야 한다 [3].

🔗 Knowledge Connections

[관계 유형: 소프트웨어 아키텍처 및 설계 원칙]

SOLID 원칙
- 연결 이유: DRY와 함께 객체 지향 프로그래밍에서 소프트웨어 설계를 이해하기 쉽고 유연하며 유지보수 가능하게 만드는 파운데이션 원칙이다 [4].
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 단일 책임 원칙(SRP)이나 개방/폐쇄 원칙(OCP)을 이해하면, 중복 제거(DRY) 시 클래스의 책임을 명확히 분리하고 올바르게 추상화하는 관점을 기를 수 있다 [4, 5].
관심사의 분리 (Separation of Concerns, SoC)
- 연결 이유: 시스템을 서로 겹치지 않는 별개의 섹션으로 분할하여 복잡성을 줄이는 근본 원칙으로, 논리와 코드의 겹침(중복)을 피하는 DRY 원칙과 상호 보완적인 관계이다 [6].
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 프레젠테이션 로직, 비즈니스 규칙, 데이터 접근 계층 등을 분리하는 안목을 통해 코드베이스 내에서 공통 로직이 어떤 계층에 배치되어야 하는지 파악할 수 있다 [6, 7].

[관계 유형: 구현/활용 도구 및 유지보수 개념]

디자인 패턴 (Design Patterns)
- 연결 이유: 소프트웨어 설계에서 반복적으로 발생하는 문제에 대한 일반적이고 재사용 가능한 해결책(템플릿)을 제공하여, 실무에서 DRY 원칙을 효율적으로 실현하게 해준다 [8].
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 코드베이스를 파악할 때 생성, 구조, 행위 패턴을 식별함으로써 반복되는 로직이 어떻게 추상화되고 객체화되어 관리되는지 구조적으로 이해할 수 있다 [9-11].
기술 부채 (Technical Debt)
- 연결 이유: DRY 원칙을 위배한 무분별한 코드 중복은 시스템의 복잡성을 가중시키고 향후 수정을 매우 어렵게 만들어, 장기적인 기술 부채를 유발하는 핵심 원인이 된다 [1, 12].
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 기존 대규모 코드베이스를 리뷰하거나 수정할 때, 리팩토링이 가장 시급한 고통 지점(high-pain area)을 식별하고 부채를 상환하는 기술적 맥락을 이해하는 데 도움이 된다 [13].

Deeper Research Questions

구문적 중복(Syntactic duplication)과 논리적 중복(Logical duplication)을 실제 코드베이스 상에서 어떻게 정확히 식별하며, 각각의 추상화 기준은 어떻게 설정하는가? [3]
'3의 규칙(Rule of Three)'을 준수하여 두 번의 코드 중복까지 허용하는 것이, 오히려 장기적인 코드베이스 유지보수성 및 시스템 복잡도 완화에 미치는 긍정적 영향은 무엇인가? [3]
코드의 명확성(Clarity) 확보와 DRY 원칙 기반의 추상화 적용이 충돌하는 상황에서, 어느 수준까지 추상화를 허용할 것인지 결정하기 위한 구체적인 코드 리뷰 지침은 어떻게 마련해야 하는가? [3]
대규모 코드베이스를 리팩토링할 때, 여러 곳에 중복된 기존 로직을 중앙 유틸리티 함수나 공유 라이브러리로 병합하면서 발생할 수 있는 부작용과 의존성 문제는 어떻게 제어할 수 있는가? [2, 13]
마이크로서비스(Microservices) 아키텍처 환경에서 여러 자율적인 서비스 간에 발생하는 논리적 중복은 어떻게 관리하며, 이를 맹목적으로 DRY 원칙으로 묶어낼 때 발생할 수 있는 강결합(Tight coupling) 위험은 어떻게 극복하는가? [14, 15]

Practical Application Contexts

Implementation: 개발 시 동일한 데이터 검증 및 포맷팅 로직이나 구성 값(데이터베이스 연결 정보 등)이 여러 곳에 하드코딩되지 않도록, 중앙 유틸리티 함수나 단일 구성 파일에 모아 단일 진실 공급원(Single source of truth)을 확보한다 [1, 2].
System Design: 초기 시스템 설계 및 아키텍처 정의 단계에서 반복될 수 있는 비즈니스 규칙을 파악하고, 기본 클래스를 상속받게 하거나 잘 확립된 프레임워크를 사용하여 불필요한 코드 생성을 사전에 방지한다 [2, 3].
Operation / Maintenance: 기존 레거시 시스템을 유지보수할 때, 코드 복사 및 붙여넣기로 인해 변경이 어렵고 복잡성이 높은 영역을 찾아 DRY 원칙을 적용하는 '목적 있는 리팩토링(Refactor with a purpose)'을 수행한다 [13].
Learning Path: 낯선 대규모 코드베이스에 온보딩하여 시스템을 파악할 때, 전반적으로 반복 사용되는 공유 유틸리티 모듈이나 공통 베이스 클래스를 먼저 확인함으로써 시스템의 핵심 동작 규칙을 신속하게 이해할 수 있다 [2].
My Project Relevance: 프로젝트 내 무의식적인 코드 복제 관행을 점검하고 논리적 중복을 통합하여, 향후 시스템의 특정 기능이 변경될 때 단 한 곳의 수정만으로 코드베이스 전체에 정확하게 반영되도록 코드의 신뢰성을 높인다 [1].

Adjacent Topics

리팩토링 (Refactoring)
- 확장 방향: 기존의 중복 코드를 추출(Extract Method)하거나 분리된 로직을 병합하는 등, 소프트웨어의 외부 동작 변경 없이 내부 구조를 개선하여 DRY 원칙을 실현하는 구체적인 코드 수준의 실무 기법으로 학습을 확장할 수 있다 [16].
클린 아키텍처 (Clean Architecture)
- 확장 방향: 비즈니스 규칙과 엔터프라이즈 논리를 시스템의 가장 깊은 중심에 두고 프레임워크, UI, 데이터베이스 등의 외부 프레임워크와 엄격하게 분리함으로써, 핵심 도메인 지식의 중복을 방지하고 프레임워크에 독립적인 시스템을 설계하는 거시적인 아키텍처 철학으로 이해를 넓힐 수 있다 [17].

Last updated: 2026-05-02

9.2 KiB Raw Blame History