Antigravity Agent
3.8 KiB
3.8 KiB
SOLID Principles
📌 Brief Summary
SOLID 원칙은 소프트웨어를 더 명확하고 체계적이며 유지보수하기 쉽게 작성하도록 돕는 5가지 핵심 설계 원칙의 약자입니다[1]. 본래 객체 지향 프로그래밍(OOP)을 위해 고안되었으나, 현대의 함수형 React 코드베이스에서도 유연하게 해석되어 컴포넌트 아키텍처에 적용됩니다[2]. 프론트엔드 개발에서 컴포넌트 간의 결합도를 낮추고 로직의 예측 가능성을 높여 대규모 애플리케이션의 구조적 확장성을 확보하는 데 필수적인 역할을 합니다[3, 4].
📖 Core Content
- 단일 책임 원칙 (SRP - Single Responsibility Principle):
- 컴포넌트, 훅, 모듈은 오직 하나의 역할과 변경 이유만을 가져야 합니다[2, 5, 6].
- 코드 품질을 향상시키는 가장 효과적인 원칙으로 평가됩니다[5]. 만약 컴포넌트가 300줄을 넘는다면 상태 관리, 데이터 페칭, 렌더링 등 너무 많은 역할을 수행하고 있을 가능성이 큽니다[5].
- 거대한 컴포넌트를 더 작고 명확한 컴포넌트(예:
UserDashboard를UserProfile,UserPosts등으로 분할)로 나누거나, 비즈니스 로직을 커스텀 훅으로 분리하여 이 원칙을 준수할 수 있습니다[2, 5].
- 개방-폐쇄 원칙 (OCP - Open/Closed Principle):
- 소프트웨어는 확장을 위해서는 열려 있어야 하고, 수정을 위해서는 닫혀 있어야 합니다[2, 7].
- React에서는 기존 컴포넌트의 내부 코드를 수정하는 대신, 컴포넌트 합성(Composition)을 활용하거나
children및 render props 패턴을 사용하여 새로운 기능을 유연하게 추가하는 방식으로 구현됩니다[2, 6, 8].
- 리스코프 치환 원칙 (LSP - Liskov Substitution Principle):
- 자식 클래스는 기존 코드를 손상시키지 않고 부모 클래스를 대체할 수 있어야 한다는 원칙입니다[7].
- React 관점에서는 하위 컴포넌트가 기본 컴포넌트를 매끄럽게 대체할 수 있어야 함을 의미합니다[6]. 다만, 상속보다는 함수형 컴포넌트 합성을 주로 사용하는 현대 React에서는 상대적으로 사용 빈도가 낮습니다[2].
- 인터페이스 분리 원칙 (ISP - Interface Segregation Principle):
- 컴포넌트는 자신이 사용하지 않는 props에 의존해서는 안 됩니다[2, 8].
- 예를 들어, 단지 'username' 속성만 필요한 작은 컴포넌트에 거대한 'user' 객체 전체를 전달하면 불필요한 결합이 발생합니다[8]. 책임을 명확히 분리하여 필요한 데이터만 전달해야 하며, 이는 TypeScript 환경에서 특히 중요합니다[2, 6].
- 의존성 역전 원칙 (DIP - Dependency Inversion Principle):
- 구체적인 구현체가 아닌 추상화에 의존해야 합니다[2, 9].
- React에서는 한 컴포넌트가 다른 컴포넌트에 직접적으로 의존하기보다, props나 Context API를 통해 외부에서 의존성을 주입받는 방식으로 이 원칙을 적용하여 유연성을 높입니다[2, 6].
🔗 Knowledge Connections
- Related Topics: Clean Code, DRY, KISS, YAGNI, React Architecture, Component Composition
- Projects/Contexts: Large-scale React Applications, Functional Programming in React, Refactoring
- Contradictions/Notes: 소스 [6]에서는 하위 컴포넌트가 기본 컴포넌트를 대체하는 방식으로 LSP를 설명하며 React에서의 적용법을 제시하지만, 소스 [2]에서는 현대의 함수형 React 코드에서는 클래스 상속이 거의 쓰이지 않아 LSP의 실질적인 적용 가능성은 낮다고 지적합니다.
Last updated: 2026-04-26