# [[Single Responsibility Principle]]

## 📌 Brief Summary
SRP(단일 책임 원칙)는 컴포넌트, 함수 또는 모듈이 단 하나의 책임이나 목적만을 가져야 한다는 소프트웨어 설계 원칙입니다 [1-3]. 본래 객체 지향 프로그래밍의 클래스 설계를 위한 원칙이지만, React와 같은 함수형 코드에서도 '하나의 코드는 오직 하나의 작업만 수행해야 한다'는 개념으로 번역되어 널리 적용됩니다 [3]. 코드가 변경되어야 하는 이유는 단 하나뿐이어야 하며, 이를 통해 코드의 품질을 향상시키고 애플리케이션의 유지보수성을 크게 높일 수 있습니다 [3, 4].

## 📖 Core Content
*   **개념과 적용의 핵심:** SRP는 장난감 상자에서 각 장난감이 자신만의 특별한 위치를 가지듯, 코드의 각 부분이 오직 한 가지의 특정한 일만 수행하도록 제한하는 원칙입니다 [1]. React 개발 환경에서는 컴포넌트나 훅(hook)이 변경되어야 할 이유가 명확히 하나만 존재하도록 설계해야 함을 의미합니다 [2, 4].
*   **식별 방법 (코드 스멜):** 컴포넌트가 300줄을 넘어가는 등 과도하게 커진다면, 이는 상태 관리(managing state), 데이터 페칭(fetching data), 복잡한 JSX 렌더링 등 너무 많은 작업을 동시에 수행하고 있다는 신호일 수 있습니다 [4]. 모든 것을 한 곳에서 처리하려는 거대한 컴포넌트를 만드는 것은 흔한 설계 함정입니다 [5].
*   **React에서의 구현 방법:**
    *   **컴포넌트 분할:** 거대한 로직을 가진 큰 컴포넌트를 더 작고 명확한 목적을 가진 컴포넌트로 분리합니다. 예를 들어, `UserDashboard` 컴포넌트를 `UserProfile`, `UserPosts`, `UserNotifications`로 나누는 방식입니다 [3, 4].
    *   **함수 추출:** 특정 작업을 별도의 범용 함수(general-purpose functions)로 분리합니다 [3].
    *   **Custom Hook 활용:** 컴포넌트 내에 혼재된 비즈니스 로직이나 상태 관리 로직을 사용자 정의 훅(custom hooks)으로 이동시킵니다 [3]. 범용적이고 재사용 가능한 컴포넌트는 공유 폴더에, 기능별 컴포넌트는 해당 기능 디렉토리에 유지합니다 [5].
*   **기대 효과:** 코드를 작고 집중된 형태의 컴포넌트로 리팩토링하면 테스트 가능성(testability)과 코드의 명확성이 크게 향상됩니다 [4]. 또한, 단일 목적을 가진 작은 컴포넌트들은 프로그램의 여러 영역에서 재사용하고 유지보수하기가 훨씬 쉽습니다 [5].

## ⚖️ Trade-offs & Caveats
소스에 단일 책임 원칙(SRP) 자체에 대한 구체적인 부작용이나 제약 사항(Trade-offs)에 대한 관련 정보가 부족합니다. 다만 SRP가 포함된 전체 SOLID 원칙에 대해서는, 코드를 고도로 유지보수하기 쉽고 조직적으로 만들어주지만 초기에는 적용하기 복잡하게 느껴질 수 있다(May initially feel complex)는 점이 제약 사항으로 언급되어 있습니다 [6]. 

## 🔗 Knowledge Connections

### Related Concepts

#### [소프트웨어 설계 및 기반 원칙]
- [[SOLID Principles]]
  - 연결 이유: SRP는 SOLID를 구성하는 5가지 설계 원칙 중 첫 번째 핵심 요소입니다 [7].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 객체 지향 프로그래밍에서 시작된 이 원칙들이 대규모 애플리케이션의 구조화와 확장성에 어떻게 종합적으로 기여하는지 이해할 수 있습니다 [8].
- [[Clean Code]]
  - 연결 이유: 읽기 쉽고 유지보수하기 쉬운 코드를 작성하기 위한 원칙으로, 코드를 명확하고 단순하게 작성할 것을 강조하는 SRP와 긴밀하게 연관됩니다 [2, 9].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 단일 책임을 지키면서도 어떻게 변수명, 컴포넌트 구조 등을 읽기 쉽게 다듬을 수 있는지 실천적 방법을 이해할 수 있습니다 [9].

#### [React 패턴 및 활용 도구]
- [[Custom Hooks]]
  - 연결 이유: React에서 컴포넌트가 너무 많은 책임을 가질 때 데이터 페칭이나 상태 관리 로직을 UI로부터 분리해내는 핵심 수단입니다 [3].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: SRP를 실제 React 환경에서 적용하여 UI 렌더링 로직과 비즈니스 로직을 분리하는 구현 패턴을 깊게 파악할 수 있습니다 [3].
- [[Component Composition]]
  - 연결 이유: 하나의 큰 역할을 하는 컴포넌트를 여러 개의 독립된 책임을 가진 서브 컴포넌트로 분할하고 조합하는 방식입니다 [4, 5].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: OCP(개방-폐쇄 원칙)와 SRP를 동시에 만족시키며, 레고 블록처럼 유연하게 UI를 조립하고 재사용성을 높이는 방법을 이해할 수 있습니다 [2, 4].

### Deeper Research Questions

- 컴포넌트가 여러 책임을 수행하는지(예: 300줄 초과) 판단할 때, '단일 책임'의 경계(Boundary)를 어떻게 정의하고 평가해야 하는가?
- React 컴포넌트에서 상태 관리 책임을 분리하기 위해 Custom Hook을 사용하는 것 외에, 전역 상태 관리 라이브러리(Zustand, Context API 등)를 도입하는 것이 SRP 관점에서 어떤 영향을 미치는가?
- Feature-Sliced Design (FSD)와 같은 모듈형 아키텍처에서 SRP는 각 Layer(공유, 엔티티, 기능 등)에 어떻게 적용되며, 모듈 간 결합도를 낮추는 데 어떤 역할을 하는가?
- 비즈니스 로직이 강하게 결합된 거대한 레거시 React 컴포넌트를 SRP 원칙에 따라 분리할 때, 회귀(Regression)를 방지하기 위한 가장 안전한 리팩토링 및 테스트 전략은 무엇인가?
- SRP를 극단적으로 적용하여 컴포넌트와 훅을 너무 잘게 분해했을 때 발생할 수 있는 파일 구조 및 Props 전달의 복잡성은 어떻게 해결할 수 있는가?

### Practical Application Contexts

- **Implementation:** React 컴포넌트를 작성할 때 코드 라인 수가 지나치게 길어지거나(예: 300줄 초과) 로직이 복잡해지면, 데이터 페칭, 상태 관리 로직을 Custom Hooks로 추출하고 UI 렌더링을 쪼개어 단일 책임만 갖도록 구현합니다 [3, 4].
- **System Design:** 폴더 구조를 설계할 때 컴포넌트가 모든 것을 처리하도록 두지 않고, 재사용 가능한 공통 컴포넌트는 공유(Shared) 폴더에, 특정 기능에 종속된 컴포넌트는 Feature 디렉토리에 명확히 격리하여 배치합니다 [5].
- **Operation / Maintenance:** 버그가 발생했을 때 코드가 단일 책임 원칙에 따라 분리되어 있다면, 문제가 UI 렌더링에 있는지 상태 관리에 있는지 추적하기 쉬워져 유지보수 속도와 정확성을 크게 높입니다 [4-6].
- **Learning Path:** React의 기본 개념(State, Props, JSX)을 익힌 후, 애플리케이션 규모가 커짐에 따라 발생하는 스파게티 코드를 해결하기 위해 Clean Code와 SOLID 원칙(특히 SRP)을 학습하고 이를 코드 리팩토링에 적용해 보는 방식으로 나아갑니다 [7-9].
- **My Project Relevance:** 거대한 대시보드 애플리케이션 등을 구축할 때, 전체를 하나의 페이지나 컴포넌트로 짜지 않고 `UserProfile`, `UserPosts`, `UserNotifications` 등 독립적인 목적을 가진 컴포넌트들로 세분화하여 테스트와 유지보수를 용이하게 만듭니다 [4].

### Adjacent Topics

- [[DRY (Don't Repeat Yourself)]]
  - 확장 방향: 코드를 단일 책임으로 쪼갠 후, 중복되는 로직(예: 동일한 데이터 페칭 방식 등)을 식별하고 이를 재사용 가능한 함수나 훅으로 통합하는 최적화 방향으로 이해를 확장할 수 있습니다 [9, 10].
- [[KISS (Keep It Simple, Stupid)]]
  - 확장 방향: 단일 책임 원칙을 지키기 위해 코드를 분리하는 과정에서, 지나친 추상화로 인해 구조가 불필요하게 복잡해지지 않도록(단순함을 유지하도록) 돕는 보완적인 설계 원칙으로 학습을 확장할 수 있습니다 [9, 10].

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