# [[DRY]]

## 📌 Brief Summary
DRY(Don't Repeat Yourself)는 동일한 코드를 두 번 작성하지 않고 기존 코드를 재사용해야 한다는 핵심 소프트웨어 개발 원칙입니다 [1]. 코드의 중복을 피하고 이를 별도의 컴포넌트나 함수로 분리하여 향후 코드의 유지보수와 수정을 용이하게 만드는 것을 목표로 합니다 [2]. React 환경에서는 주로 공통 로직을 커스텀 훅(Custom Hooks)이나 고차 컴포넌트(Higher-Order Components)로 추출하는 방식으로 구현됩니다 [3, 4].

## 📖 Core Content
*   **중복 제거의 이점**: 코드를 작성할 때 중복을 피하면 향후 요구사항 변경 시 유지보수가 훨씬 쉬워집니다 [2]. 중복된 코드가 많으면 코드를 변경할 때 여러 곳을 찾아 수정해야 하지만, DRY 원칙을 지키면 단일 위치(one place)에서만 변경 사항을 적용하면 되기 때문입니다 [2].
*   **React에서의 구현 방법**: 반복적인 로직이 존재하는 애플리케이션에서는 재사용 가능한 로직을 추출해야 합니다 [4]. React에서는 이를 주로 커스텀 훅(Custom Hooks)이나 고차 컴포넌트(Higher-Order Components, HOC)를 생성하여 처리합니다 [3, 4].
*   **적절한 추상화 타이밍**: 성급한 최적화를 방지하고 코드를 단순하게 유지하기 위해, 특정 코드 패턴이 최소 '3번' 반복될 때까지 기다렸다가 추상화(abstraction)를 진행하는 것이 권장되는 가이드라인입니다 [3].

## ⚖️ Trade-offs & Caveats
*   **과도한 추상화의 위험성**: 중복을 줄이려는 노력으로 인해 추상화가 지나치게 복잡해질 수 있는 부작용이 있습니다 [5]. 
*   **KISS 원칙과의 충돌**: 재사용 가능한 추상화를 만들었지만, 그 결과물이 원래의 반복된 코드보다 이해하기 더 어려워진다면 이는 추상화의 목적을 상실한 것입니다 [3]. 이 경우 코드를 단순하게 유지하라는 "KISS (Keep It Simple, Stupid)" 원칙을 위반하게 됩니다 [3].
*   **유연성 저하 우려**: Feature-Sliced Design과 같은 최신 프론트엔드 아키텍처에서는 DRY 원칙의 준수와 특정 기능에 맞춘 로컬 커스터마이징(local customization) 사이에서 적절한 균형을 유지해야 한다고 강조합니다 [6]. 즉 무조건적인 중복 제거가 능사는 아닙니다.

## 🔗 Knowledge Connections

### Related Concepts

#### [소프트웨어 엔지니어링 원칙]
- [[KISS]]
  - 연결 이유: DRY 원칙을 강박적으로 적용하여 추상화를 진행하다 보면 코드가 지나치게 복잡해져 이 KISS(Keep It Simple, Stupid) 원칙에 위배될 수 있습니다 [3].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 효율적인 코드 작성에 있어 중복 제거(DRY)와 코드의 단순성(KISS) 사이의 트레이드오프와 균형점을 이해할 수 있습니다.
- [[YAGNI]]
  - 연결 이유: DRY 원칙과 함께 언급되며(You Aren't Gonna Need It), 코드 리팩토링 시 불필요한 코드를 줄이는 기준이 됩니다 [7, 8].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 당장 필요하지 않은 미래를 대비해 미리 추상화하지 말라는 개념을 통해 '3번 반복 시 추상화'라는 DRY 적용 시점을 명확히 이해할 수 있습니다 [3].

#### [React 구현/활용 도구]
- [[Custom Hooks]]
  - 연결 이유: React 애플리케이션에서 코드 중복을 피하고 공통 로직을 추출할 때 가장 널리 권장되는 수단입니다 [3, 4].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 상태 관리나 라이프사이클과 같은 React 고유의 로직을 어떻게 재사용 가능한 형태로 분리(DRY)할 수 있는지 배울 수 있습니다.
- [[Higher-Order Components]]
  - 연결 이유: 커스텀 훅과 함께 React 내에서 반복되는 컴포넌트 로직을 재사용하고 DRY 원칙을 준수하기 위한 구현 도구입니다 [4].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: UI 렌더링 측면에서 컴포넌트의 중복 코드를 어떻게 추상화하는지 이해할 수 있습니다.

### Deeper Research Questions

- React 애플리케이션에서 DRY 원칙을 지키기 위해 로직을 무분별하게 커스텀 훅으로 분리했을 때 발생할 수 있는 렌더링 성능 이슈는 무엇인가?
- '3번 반복되면 추상화하라'는 가이드라인 외에, 과도한 추상화(Over-abstraction)를 진단할 수 있는 코드 리뷰 상의 지표는 무엇이 있는가?
- Feature-Sliced Design과 같이 도메인 단위로 기능을 격리하는 구조에서, 전역적인 DRY 원칙 준수와 도메인 간 결합도(Coupling) 최소화 목표는 어떻게 상충하며 어떻게 해결할 수 있는가?
- 컴포넌트의 UI 구조적 중복과 비즈니스 로직적 중복을 해소하는 구체적인 React 패턴(Render Props, HOC, Custom Hooks)은 각각 어느 상황에 최적화되어 있는가?
- DRY 원칙에 따라 하나의 유틸리티 함수나 공유 컴포넌트를 변경했을 때, 이를 참조하는 다른 모듈들(Blast Radius)에 미치는 부작용을 사전에 테스트하고 제어하는 방법론은 무엇인가?

### Practical Application Contexts

- **Implementation:** React로 화면을 구현할 때, 서로 다른 페이지에서 동일한 데이터 페칭 방식이나 폼 처리 로직을 사용 중이라면 이를 `useFetch`나 `useForm`과 같은 커스텀 훅으로 빼내어 코드 중복을 제거합니다 [3, 4].
- **System Design:** 프로젝트의 폴더 구조를 잡을 때 공통 로직을 재사용할 수 있도록 `shared` 또는 `utils` 같은 전역적인 레이어를 두어 중복 코드를 최소화하고 재사용성을 촉진합니다 [6, 9].
- **Operation / Maintenance:** 중복 로직을 별도의 함수나 컴포넌트로 관리하면 특정 API 스펙이나 UI 정책이 변경될 때 수십 개의 파일을 수정할 필요 없이 단 한 곳만 수정하여 애플리케이션 전체에 반영할 수 있습니다 [2].
- **Learning Path:** 처음부터 완벽하게 중복이 없는 코드를 작성하려 하기보다는 일단 코드를 작성한 뒤, 같은 패턴이 3번 이상 반복되는 것을 목격했을 때 리팩토링을 통해 추상화하는 훈련을 합니다 [3].
- **My Project Relevance:** React 코드베이스를 리팩토링(refactoring)하는 과제 수행 시, DRY 및 YAGNI 원칙을 척도로 삼아 Lint를 설정하고, 흩어진 유사 함수들을 작고 명확한 재사용 모듈로 통합하는 것을 목표로 할 수 있습니다 [7].

### Adjacent Topics

- [[SOLID]]
  - 확장 방향: 객체 지향 및 함수형 프로그래밍에서 코드 품질을 높이는 5대 원칙으로, DRY와 함께 React 컴포넌트 구조화(단일 책임 원칙 등)를 학습하는 데 도움이 됩니다 [10, 11].
- [[Clean Code]]
  - 확장 방향: 중복 제거(DRY)뿐만 아니라 명확한 네이밍, 함수 크기 축소 등 코드의 가독성과 유지보수성을 총체적으로 향상시키는 원칙을 더 넓게 포괄합니다 [1, 4].

---
*Last updated: 2026-04-30*