DRY (Don't Repeat Yourself) 원칙

📌 Brief Summary

DRY(Don't Repeat Yourself) 원칙은 소프트웨어 개발에서 정보와 로직의 반복을 줄이는 것을 목표로 하는 핵심 설계 개념이다 [1]. "시스템 내에서 모든 지식은 단일하고 모호하지 않으며 권위 있는 표현을 가져야 한다"는 사상을 바탕으로 한다 [1]. 이 원칙을 준수하여 코드 중복을 피함으로써 기술 부채를 최소화하고, 장기적인 유지보수를 간소화하며, 보다 신뢰할 수 있고 이해하기 쉬운 코드베이스를 구축할 수 있다 [1].

📖 Core Content

DRY의 핵심 목표와 원리: DRY 원칙의 가장 기본적인 목표는 중복되는 코드와 로직을 방지하는 것이다. 동일한 로직이 여러 곳에 복사되어 붙여넣어질 경우, 단 한 번의 변경만으로도 모든 위치를 찾아 업데이트해야 하므로 오류가 발생하기 쉽고 비효율적이다 [1]. 따라서 공통 기능을 재사용 가능한 컴포넌트로 추상화하여 로직이 단 한 곳에만 존재하도록 보장해야 한다 [2].
실제 구현 방식 (How DRY Works in Practice):
- 유틸리티 함수 및 공유 라이브러리: 애플리케이션의 여러 부분에서 동일한 데이터 검증이나 포맷팅 로직을 작성하는 경우, 이를 중앙 유틸리티 함수나 공유 라이브러리로 추출하여 여러 곳에서 호출할 수 있게 만든다 [2].
- 기본 클래스(Base Classes) 및 상속: 객체 지향 프로그래밍(OOP)에서 여러 클래스가 공유하는 공통 동작이나 속성을 기본 클래스에 배치한다. 다른 클래스들은 해당 기능을 다시 정의할 필요 없이 이 기본 클래스를 상속받아 사용한다 [2].
- 구성(Configuration) 관리: 데이터베이스 연결 문자열이나 API 키와 같은 설정 값을 여러 파일에 하드코딩하는 대신, 전체 애플리케이션이 참조할 수 있는 단일의 중앙 집중식 구성 파일에 저장한다 [2].
프레임워크의 활용: 인증, 라우팅, 데이터 액세스와 같은 일반적인 작업에는 이미 확립된 프레임워크와 라이브러리를 활용해야 한다. 이러한 도구들은 이미 DRY 원칙을 기반으로 구축되어 있으므로, 개발자가 **바퀴를 다시 발명하는 일(reinventing the wheel)**을 방지해 준다 [3].

⚖️ Trade-offs & Caveats

성급한 추상화의 위험 (Premature Abstraction): 추상화를 도입하기 전에 **"3의 규칙(Rule of Three)"**을 따르는 것이 권장된다. 코드가 최소 두 번 이상 중복되는 것을 확인할 때까지 기다린 후 추상화를 결정해야 한다. 원칙을 기계적으로 적용하여 너무 일찍 추상화할 경우, 오히려 불필요한 복잡성이 시스템에 추가될 수 있다 [3].
구문적 중복과 논리적 중복의 구분: DRY는 단순히 동일한 코드 라인을 반복하는 것(구문적 중복)만을 피하려는 것이 아니다. 진정한 목표는 **동일한 비즈니스 규칙이나 로직(논리적 중복)**의 반복을 피하는 것이다. 겉보기에는 다른 코드 블록이라도 동일한 기본 개념을 나타낼 수 있으므로 이에 주의해야 한다 [3].
명확성과의 균형 (Balance DRY with Clarity): 때로는 약간의 코드 중복이 복잡하게 얽힌 추상화보다 훨씬 더 가독성이 높고 덜 복잡할 수 있다 [3]. 항상 코드의 명확성과 단순성을 우선시해야 하며, DRY 원칙에 지나치게 얽매여 오히려 읽기 어려운 코드를 만들어서는 안 된다 [3].

🔗 Knowledge Connections

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

Separation of Concerns (SoC)
- 연결 이유: 코드를 서로 중복되지 않는 별개의 섹션으로 나누어 기능별 책임을 분리하는 아키텍처의 기초 원칙이다 [4].
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 관심사를 명확히 분리함으로써 코드베이스 내에서 어떤 로직이 중복(DRY 위반)되고 있는지 명확히 식별하고, 각 모듈이 겹치지 않는 단일 책임을 갖도록 추상화하는 구조적 배경을 이해할 수 있다 [1, 4].
SOLID Principles
- 연결 이유: 시스템을 유연하고 이해 및 유지 관리하기 쉽게 만드는 객체 지향 프로그래밍의 5가지 기본 설계 원칙으로, DRY와 함께 코드 품질을 높이는 데 기여한다 [5].
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 특히 '단일 책임 원칙(SRP)'을 통해 특정 클래스나 로직이 왜 단 한 가지의 책임(단일하고 권위 있는 표현)만 가져야 하는지 논리적 맥락을 파악할 수 있다 [1, 5, 6].

[실무 구현 및 코드베이스 관리]

Refactoring
- 연결 이유: DRY 원칙을 위반한 중복 코드를 발견했을 때, 이를 더 나은 설계로 재구성하기 위해 수행하는 실무적인 개선 과정이다 [7, 8].
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 기존 코드베이스를 읽는 과정에서 높은 고통(high-pain)을 유발하는 중복을 식별하고, 목적을 가진 리팩토링을 통해 복잡성을 줄이고 명확성을 높이는 방법을 배울 수 있다 [8].

Deeper Research Questions

성급한 추상화(Premature Abstraction)가 유발하는 코드베이스의 복잡성 증가 사례는 무엇이며, 3의 규칙(Rule of Three) 외에 이를 감지할 수 있는 기준은 무엇인가?
코드 독해 과정에서 구문적 중복(Syntactic Duplication)과 논리적 중복(Logical Duplication)을 구별해 내는 가장 효율적인 전략은 무엇인가?
고도로 복잡하고 오래된 레거시 시스템에서 기존의 광범위한 중복 코드를 추출하고 추상화할 때 발생하는 구조적 리스크와 한계는 무엇인가?
시스템의 가독성(Clarity)과 단순성을 위해 DRY 원칙을 의도적으로 위반하는 것이 오히려 더 나은 아키텍처적 선택이 되는 구체적인 비즈니스 상황은 언제인가?
중복 로직을 중앙 집중식 유틸리티 함수나 공유 라이브러리로 추상화했을 때 발생할 수 있는 모듈 간의 강한 결합(Tight Coupling) 문제를 어떻게 예방할 수 있는가?

Practical Application Contexts

Implementation: 코드가 최소 두 번 이상 중복되는 논리적 반복(Rule of Three)을 발견했을 때, 유틸리티 함수, 클래스 상속, 또는 공유 라이브러리 형태로 추상화하여 중복을 제거한다 [2, 3].
System Design: 소프트웨어 아키텍처 설계 시, 비즈니스 규칙과 구성 요소들이 시스템 내에서 오직 하나의 권위 있는 위치를 가지도록 설계하여 구현 복잡성을 낮춘다 [1, 7].
Operation / Maintenance: 중복 로직을 제거함으로써, 향후 비즈니스 룰이 변경될 때 한 곳의 코드만 업데이트해도 전체 시스템에 반영되게 하여 운영 중의 오류와 유지보수 비용(기술 부채)을 최소화한다 [1, 7].
Learning Path: 복잡한 코드베이스를 처음 학습하고 파악할 때, 어디에 복사-붙여넣기 된 코드가 많은지 식별하여 코드베이스의 상태를 진단하고, 향후 리팩토링 및 코드 개선 방향의 지표로 삼는다 [7, 8].
My Project Relevance: 현재 탐색 중인 시스템 내에서 흩어져 있는 동일한 로직들을 하나의 흐름으로 이해하고, 이것이 의도된 명확성을 위한 중복인지 아니면 추상화가 필요한 기술 부채인지 판단하는 코드 리뷰의 핵심 기준이 된다 [1, 3, 8].

Adjacent Topics

Technical Debt
- 확장 방향: DRY 원칙을 무시하고 중복 코드를 방치했을 때 장기적으로 시스템 유지보수에 누적되는 기술 부채의 속성과 그 비용을 분석하는 방향으로 확장할 수 있다 [1].
Code Smells
- 확장 방향: 중복 코드(Duplicate Code), 거대한 클래스, 긴 메서드 등 코드베이스의 가독성과 유지보수성을 해치는 다양한 코드의 악취를 식별하고 이를 해결하는 리팩토링 패턴을 연구하는 것으로 확장할 수 있다 [9].

Last updated: 2026-05-02

8.5 KiB Raw Blame History