Files

T

koriweb 5ba5a55c78 feat: Wiki 지식 자산 업데이트 - UX Scenarios, Frontend, Game Design, Topics 추가 [2026-05-08]

2026-05-08 19:52:07 +09:00

6.1 KiB

Raw Blame History

id, title, category, status, canonical_id, aliases, duplicate_of, source_trust_level, confidence_score, tags, raw_sources, last_reinforced, github_commit, inferred_by, tech_stack

title

SOLID 원칙

📌 한 줄 통찰 (The Karpathy Summary)

SOLID 원칙은 객체 지향 프로그래밍에서 소프트웨어 설계를 더 이해하기 쉽고, 유연하며, 유지보수하기 좋게 만들기 위해 고안된 5가지 핵심 설계 원칙의 집합이다 [1]. 로버트 C. 마틴(RoBERT C. Martin)에 의해 대중화된 이 원칙들은 코드의 부패를 방지하고 견고한 기반을 구축하는 데 필수적인 지침으로 작용한다 [1]. 이 원칙들을 올바르게 적용하면 시스템 내 컴포넌트 간의 의존성이 줄어들어 한 부분의 변경이 다른 부분에 미치는 영향을 최소화할 수 있다 [1].

📖 구조화된 지식 (Synthesized Content)

SOLID의 5가지 핵심 원칙

단일 책임 원칙 (SRP, Single Responsibility Principle): 클래스는 단 하나의 변경 이유만 가져야 하며, 이는 오직 하나의 역할(책임)만을 수행해야 함을 의미한다 [2, 3]. 이를 통해 클래스를 더 쉽게 이해하고 평가할 수 있으며, 코드의 명확성과 유지보수성이 향상된다 [3]. SRP는 '관심사의 분리(SoC)' 개념에서 직접적으로 파생된 원칙 중 하나이다 [4].
개방-폐쇄 원칙 (OCP, Open/Closed Principle): 소프트웨어 엔티티는 확장에는 열려 있어야 하지만 수정에는 닫혀 있어야 한다 [2, 3, 5]. 이는 인터페이스나 추상 클래스와 같은 추상화 및 다형성 과정을 사용하여, 기존 코드를 변경하지 않고도 새로운 하위 클래스를 통해 새 기능을 추가할 수 있게 함으로써 달성된다 [2, 3].
리스코프 치환 원칙 (LSP, Liskov Substitution Principle): 하위 타입(서브클래스)은 프로그램의 정확성을 훼손하지 않으면서 기본 타입(부모 클래스)을 대체할 수 있어야 한다 [2, 3]. 이는 파생 클래스가 기본 클래스의 동작을 임의로 변경하지 않고 매끄럽게 호환되어 시스템의 신뢰성과 견고성을 향상시킬 수 있도록 보장한다 [2, 3].
인터페이스 분리 원칙 (ISP, Interface Segregation Principle): 클라이언트는 자신이 사용하지 않는 인터페이스에 의존하도록 강요받아서는 안 된다 [2, 3]. 이를 위해 하나의 크고 범용적인 인터페이스보다는 작고 구체적이며 전문화된 인터페이스를 여러 개 만드는 것이 권장되며, 이 역시 '관심사의 분리(SoC)' 원칙에서 파생되었다 [2-4].
의존성 역전 원칙 (DIP, Dependency Inversion Principle): 고수준 모듈은 저수준 모듈에 의존해서는 안 되며, 양쪽 모두 추상화(예: 인터페이스)에 의존해야 한다 [2, 3, 6]. 이러한 접근은 종종 의존성 주입(Dependency Injection, DI) 프레임워크를 통해 구현되며, 모듈성을 높이고 시스템이 변화에 쉽게 적응할 수 있도록 만든다 [2, 3, 7].

구현 팁 및 기대 효과

SOLID 원칙을 레거시 애플리케이션 전체에 한 번에 적용하기보다는, 가장 적용하기 쉽고 즉각적인 이점을 제공하는 '단일 책임 원칙(SRP)'부터 시작하여 점진적으로 적용하는 것이 유리하다 [7].
구현 방법(How)보다 컴포넌트가 해야 할 일인 인터페이스(What)를 먼저 설계하는 관행을 들이면 자연스럽게 OCP와 DIP 원칙을 뒷받침할 수 있다 [7].
이 원칙들은 객체 지향 시스템, 라이브러리, 그리고 지속적으로 성장하는 대규모 코드베이스에 이상적으로 적용되며, 결합도가 낮고 테스트 가능성이 높으며 유연한 코드를 산출하는 핵심 기반이 된다 [8].

⚠️ 모순 및 업데이트 (Contradictions & Updates)

과거 데이터와의 충돌: 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
정책 변화: Programming & Language 분야의 자동 자산화 수행.

🔗 지식 연결 (Graph)

Related Topics: 객체 지향 프로그래밍(OOP), 관심사의 분리(SoC), 의존성 주입(DI)
Projects/Contexts: 클린 아키텍처(Clean [[Architecture)]], 소프트웨어 아키텍처 베스트 프랙티스
Contradictions/Notes: 소스 전반에 걸쳐 SOLID 원칙은 코드의 복잡성을 줄이고 유지보수성을 높이는 필수적인 기법으로 일관되게 강조되고 있으며, 서로 대립하거나 모순되는 주장은 존재하지 않습니다 [1, 3, 8].

Last updated: 2026-04-18

🤖 LLM 활용 힌트 (How to Use This Knowledge)

언제 이 지식을 쓰는가:

(TODO)

언제 쓰면 안 되는가:

(TODO)

🧪 검증 상태 (Validation)

정보 상태: needs_review
출처 신뢰도: A
검토 이유: (P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)

🧬 중복 검사 (Duplicate Check)

기존 유사 문서: (TODO: 인덱서 클러스터 리포트 참조)
처리 방식: UPDATE (자동 정규화)
처리 이유: Phase 1 정규화 — 옛 템플릿/누락 필드 보강.

🕓 변경 이력 (Changelog)

날짜	변경 내용	처리 방식	신뢰도
2026-05-08	P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화)	UPDATE	A

💻 코드 패턴 (Code Patterns)

패턴 1: (TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)

# TODO

🤔 의사결정 기준 (Decision Criteria)

선택 A를 써야 할 때:

(TODO)

선택 B를 써야 할 때:

(TODO)

기본값:

(TODO)

❌ 안티패턴 (Anti-Patterns)

[안티패턴]: (TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)

6.1 KiB Raw Blame History