핵심 인사이트 (3줄 요약)
- 본질: DRY (Don't Repeat Yourself)는 특정 지식이나 비즈니스 규칙이 시스템 내에서 단일하고 모호하지 않으며 권위 있는 유일한 표현인 SSOT (Single Source of Truth)를 가져야 한다는 설계 원칙이다.
- 가치: 중복된 지식을 제거함으로써, 정책 변경 시 여러 곳을 동시에 수정해야 하는 산탄총 수술(Shotgun Surgery)을 방지하고 유지보수성을 극대화한다.
- 판단 포인트: 형태만 우연히 같은 코드를 섣불리 통합하는 성급한 추상화(Premature Abstraction)를 하면 결합도(Coupling)가 높아지므로, "변경의 이유"가 동일할 때만 DRY를 적용해야 한다.
Ⅰ. 개요 및 필요성
DRY (Don't Repeat Yourself) 원칙은 실용주의 프로그래머(The Pragmatic Programmer)에서 강조된 소프트웨어 설계의 근본 철학이다. 코드나 시스템 아키텍처에 동일한 의미를 가진 논리, 데이터, 설정이 여러 번 반복해서 등장하는 것을 경계한다.
이 원칙이 필요한 이유는 '동기화의 실패'를 막기 위해서다. 부가세 계산 로직이 시스템의 5곳에 복사되어 있다면, 세법이 바뀌었을 때 개발자가 4곳만 수정하고 1곳을 누락할 위험이 매우 커진다. 이러한 중복은 결국 데이터 불일치와 예측 불가능한 버그를 낳으며, 시스템의 신뢰도를 바닥으로 떨어뜨린다.
- 📢 섹션 요약 비유: DRY 원칙은 회사 규정집을 한 권만 만드는 것과 같다. 부서마다 각자의 규정집을 복사해서 가지고 있으면, 나중에 출근 시간이 바뀌었을 때 누군가는 예전 시간으로 출근하는 대참사가 벌어진다.
Ⅱ. 아키텍처 및 핵심 원리
DRY는 단순히 복사하여 붙여넣기를 하지 말라는 구문(Syntax) 차원의 조언을 넘어, 지식(Knowledge)과 의도(Intent)의 중복을 제어하는 아키텍처 원리다.
- SSOT (Single Source of Truth): 시스템 내의 모든 상태나 로직은 오직 하나의 진실의 원천에서 파생되어야 한다. 데이터베이스의 정규화도 데이터 중복을 막는 DRY의 일환이다.
- 추상화와 모듈화: 중복된 코드는 함수, 클래스, 또는 MSA (Microservices Architecture) 구조의 마이크로서비스로 추출(Extract)하여 공통 모듈화한다. 이를 통해 클라이언트는 로직의 내부 구현을 몰라도 단순히 호출(Call)만 하면 된다.
- 코드 생성기와 매크로: 스키마 정의서나 API 명세서에서 반복적인 보일러플레이트 코드를 자동 생성하는 것도 지식의 원천을 문서 하나로 모으는 DRY의 훌륭한 적용 사례다.
┌─────────────────────────────────────────────────────────────┐
│ [ DRY Principle의 적용 구조 ] │
├─────────────────────────────────────────────────────────────┤
│ [위반 상태 (WET)] │
│ Module A ──▶ (로직 X 복사본) ◀─ 변경 발생 시 둘 다 수정해야 함│
│ Module B ──▶ (로직 X 복사본) │
│ │
│ [DRY 적용 후] │
│ Module A ──▶ ┌────────────────┐ │
│ │ 공통 서비스 (X)│ ◀─ 변경 시 여기 1곳만 수정 │
│ Module B ──▶ └────────────────┘ │
└─────────────────────────────────────────────────────────────┘
DRY 원칙이 제대로 적용된 시스템은 응집도(Cohesion)가 높고 중복이 없기 때문에, 요구사항 변경에 따른 파급 효과가 한곳으로 제한된다.
- 📢 섹션 요약 비유: 집안의 모든 조명을 끄기 위해 방마다 돌아다니며 스위치를 누르는 대신, 현관에 '일괄 소등 스위치(공통 서비스)' 하나를 만들어 중앙 통제하는 것이 바로 DRY의 핵심 원리다.
Ⅲ. 비교 및 연결
DRY 원칙을 맹신할 때 발생하는 부작용을 경계하기 위해, 상반되거나 보완적인 개념과 비교해야 한다.
| 비교 항목 | DRY (Don't Repeat Yourself) | WET (Write Everything Twice) / AHA |
|---|---|---|
| 핵심 철학 | 중복을 피하고 추상화하라. | AHA (Avoid Hasty Abstractions): 성급한 추상화를 피하라. |
| 발생 시점 | 규칙과 도메인 지식이 확실하게 정립되었을 때 | 요구사항이 불확실하고 변경 가능성이 높을 때 |
| 장점 | 유지보수 포인트의 단일화, 무결성 보장 | 모듈 간 결합도 저하, 독립적인 기능 수정 가능 |
| 단점 | 잘못 추상화하면 강한 결합(Coupling)을 유발함 | 수정 누락에 따른 버그 발생 확률 증가 |
"형태가 같다고 해서 같은 지식은 아니다"라는 점이 중요하다. 프론트엔드의 유효성 검증과 백엔드의 검증 코드는 우연히 같아 보일 뿐, 보안과 사용자 편의성이라는 서로 "다른 변경의 이유"를 가지므로 강제로 하나로 합치면 안 된다.
- 📢 섹션 요약 비유: 쌍둥이가 같은 옷(코드)을 입고 있다고 해서, 한 명의 옷이 작아졌다고 두 명의 옷을 한 번에 이어 붙이는 수선(잘못된 DRY)을 하면 안 된다. 겉모습은 같아도 크는 속도(변경의 이유)가 다르면 각자 옷을 맞춰야 한다(WET).
Ⅳ. 실무 적용 및 기술사 판단
실무 프로젝트나 감리 과정에서 DRY 원칙은 소프트웨어의 지속 가능성을 평가하는 가장 직관적인 척도다.
- Rule of Three (3의 법칙) 적용: 중복 코드를 처음 발견했을 때는 그냥 둔다. 두 번 발견되었을 때도 참는다. 하지만 세 번째로 동일한 로직을 작성해야 할 때 비로소 리팩토링하여 공통화(DRY)한다. 이는 미래를 너무 앞서서 설계하는 YAGNI (You Aren't Gonna Need It) 위반과 성급한 추상화를 막기 위한 실무적 가이드라인이다.
- 매직 넘버(Magic Number) 제거 판단: 코드 내에 하드코딩된 숫자나 문자열이 여러 번 등장하는 것은 명백한 DRY 위반이다. 이를 전역 상수나 설정 파일로 추출하여 중앙에서 통제하도록 아키텍처 지침을 내려야 강제할 수 있다.
- MSA 환경에서의 DRY 타협: MSA에서는 서비스 간의 완벽한 독립성을 위해 도메인 객체나 유틸리티 코드의 복사를 일부 허용한다. 결합도를 낮추는 것이 무조건적인 중복 제거보다 더 큰 가치를 지닐 때가 있기 때문이다.
- 📢 섹션 요약 비유: 실무에서 DRY의 적용은 "공용 공구함"을 만드는 것과 같다. 망치가 한 번 필요하다고 무작정 공용으로 만들면 관리만 힘들다. 망치를 세 명 이상이 매일 빌리러 올 때 비로소 번듯한 공용 도구함(공통 모듈)을 짜는 것이 현명한 판단이다.
Ⅴ. 기대효과 및 결론
DRY 원칙을 적절하게 준수하면 개발 생산성이 비약적으로 상승한다. 기존 로직을 수정할 때 버그의 연쇄 발생을 두려워하지 않아도 되며, 새로운 개발자는 중앙화된 지식(SSOT)만 읽고도 시스템의 정책을 명확하게 파악할 수 있다.
하지만 맹목적인 DRY는 코드를 스파게티처럼 얽히게 만드는 강한 결합(Tight Coupling)의 원흉이 될 수 있다. 결론적으로 DRY 원칙의 진정한 목표는 "코드 라인 수를 줄이는 것"이 아니라, "변경을 안전하고 국소적으로 통제하여 지식의 일관성을 유지하는 것"임을 기억해야 한다.
- 📢 섹션 요약 비유: 나무뿌리를 하나로 묶어두면 물 주기는 편하지만(DRY의 장점), 한 나무가 병들면 전체가 죽을 위험도 있다(강결합의 단점). 따라서 정말 같은 영양분을 먹는 뿌리들만 신중하게 묶어야 한다.
📌 관련 개념 맵
| 개념 | 연결 포인트 |
|---|---|
| SSOT (Single Source of Truth) | 시스템 내에서 단 하나의 데이터 원천만 신뢰한다는 정보 관리 철학 |
| 리팩토링 (Refactoring) | 중복 코드를 함수나 객체로 추출(Extract)하여 DRY 상태를 만드는 활동 |
| YAGNI (You Aren't Gonna Need It) | 미리 필요할 것 같아서 성급하게 공통화(추상화)하는 것을 막는 방어 원칙 |
| Rule of Three (3의 법칙) | 세 번째로 중복 코드가 나타날 때 비로소 DRY를 적용하라는 실무 지침 |
📈 관련 키워드 및 발전 흐름도
소프트웨어 설계 원칙의 진화
│
▼
Spaghetti Code (무분별한 복사-붙여넣기, WET 상태 방치)
│
▼
DRY (Don't Repeat Yourself, 중복 제거와 SSOT 확보)
│
▼
Rule of Three & YAGNI (성급한 추상화 경계, 실용적 적용)
│
▼
MSA 아키텍처 (독립성을 위해 의도적인 중복을 전략적으로 허용)
👶 어린이를 위한 3줄 비유 설명
- DRY 원칙은 "엄마한테 들은 잔소리를 아빠한테 또 듣지 않게 하는" 규칙이에요.
- 집안의 규칙은 냉장고에 딱 한 장만 붙여두면, 가족 모두가 헷갈리지 않고 따를 수 있잖아요?
- 코딩할 때도 똑같은 규칙이나 계산법은 딱 한 군데에만 적어둬서 나중에 고치기 쉽게 만드는 거랍니다.