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

[소프트웨어 엔지니어링 원칙]

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

7.1 KiB Raw Blame History

DRY