# [[Software Engineering Core Principles (소프트웨어 엔지니어링 핵심 원칙)|Software Engineering Core Principles (소프트웨어 엔지니어링 핵심 원칙]]

## 📌 Brief Summary
소프트웨어 엔지니어링 핵심 원칙은 유지보수성이 뛰어나고 확장이 용이한 고품질 시스템을 구축하기 위한 설계 지침입니다 [1]. SOLID 원칙을 기반으로 객체 간의 결합도를 낮추고 응집도를 높이며, 검증된 디자인 패턴을 적용하여 반복되는 설계 문제에 최적의 해결책을 제시합니다 [4]. 코드 리뷰 과정에서 리뷰어는 단순히 코드가 동작하는지를 넘어, 해당 코드가 조직의 아키텍처 가이드라인과 설계 원칙에 부합하는 구조적인 무결성을 갖췄는지 평가해야 합니다 [1, 3].

## 📖 Core Content
*   **SOLID 5대 원칙:**
    *   **SRP (단일 책임 원칙):** 클래스/함수는 하나의 명확한 책임만 가져야 함 [4].
    *   **OCP (개방-폐쇄 원칙):** 확장은 열려 있고 수정은 닫혀 있어야 함 [5].
    *   **LSP (리스코프 치환 원칙):** 하위 타입은 상위 타입을 완벽히 대체 가능해야 함.
    *   **ISP (인터페이스 분리 원칙):** 사용하지 않는 인터페이스 구현을 강제하지 않음.
    *   **DIP (의존성 역전 원칙):** 구체적 구현이 아닌 추상화에 의존해야 함 [5].
*   **핵심 설계 기법:**
    *   **의존성 주입 (Dependency Injection, DI):** DIP를 실현하는 구체적 패턴으로, 의존성을 하드코딩하지 않고 외부에서 주입받아 결합도를 낮추고 테스트 용이성을 높입니다 [33, 34].
    *   **추상화 (Abstractions):** 복잡한 내부 로직을 단순한 인터페이스 뒤로 숨겨 시스템 이해도를 높입니다. 하지만 과도한 추상화는 오버 엔지니어링으로 이어질 수 있습니다 [7, 8].
    *   **디자인 패턴 (Design Patterns):** 생성, 구조, 행위 등 반복되는 설계 이슈에 대한 검증된 템플릿(예: 싱글톤, 전략, 옵저버 패턴 등)을 활용합니다.
*   **코드 건강 (Code Health):** 코드 가독성, 유지보수성, 테스트 가능성을 포괄하는 개념으로, 원칙 준수 여부가 시스템의 장기적인 생존력을 결정합니다 [49].

## ⚖️ Trade-offs & Caveats
*   **오버 엔지니어링 (Over-engineering):** 원칙을 맹목적으로 추종하여 불필요한 추상화나 미래를 대비한 과도한 일반화를 적용하면 시스템 복잡성만 가중됩니다 [7]. "현재 요구사항에 맞는 가장 단순한 설계(KISS)"와 "확장성" 사이의 균형이 필수적입니다.
*   **성능 vs 아키텍처:** 고도의 추상화와 객체 분리는 미세한 성능 오버헤드를 유발할 수 있습니다. 지연 시간에 극도로 민감한 시스템에서는 아키텍처 무결성과 성능 사이의 타협이 필요할 수 있습니다.
*   **인터페이스 파편화:** ISP를 너무 엄격히 적용하면 수많은 작은 인터페이스가 생성되어 오히려 시스템 전체 구조를 파악하기 어렵게 만들 수 있습니다.

## 🔗 Knowledge Connections

### Related Concepts
*   **[[Clean Architecture|Clean Architecture]]**: SOLID 원칙이 실제 계층형 아키텍처로 구현된 고수준 디자인 패턴입니다.
*   **Unit Testing / Testability**: SRP와 DIP를 준수할 때 모의 객체(Mock)를 활용한 단위 테스트가 용이해집니다.
*   **Technical Debt (기술 부채**: 설계 원칙을 무시했을 때 누적되는 눈에 보이지 않는 유지보수 비용입니다.
*   **[[Code Refactoring|Code Refactoring]]**: 거대해진 클래스를 SRP에 맞춰 분리하고 시스템을 안전하게 재구조화하는 활동입니다.

### Deeper Research Questions
*   복잡한 도메인 비즈니스 로직을 구현할 때, 단일 책임 원칙(SRP)을 위반하지 않기 위한 '책임의 경계'를 식별하는 구체적인 프레임워크는 무엇인가?
*   이미 강하게 결합된 레거시 시스템에 의존성 역전 원칙(DIP)을 도입하여 안전하게 리팩토링하기 위한 점진적인 전략과 코드 리뷰 절차는 무엇인가?
*   인터페이스 분리 원칙(ISP)을 적용할 때 발생하는 '인터페이스 폭발' 문제를 방지하기 위한 아키텍처적 임계점은 어떻게 설정하는가?
*   생성자 주입(Constructor Injection) 외에 Setter 주입이나 필드 주입이 아키텍처 순수성과 테스트 용이성에 미치는 구체적인 영향은 무엇인가?
*   AI가 제안하는 디자인 패턴이 프로젝트의 기존 컨벤션과 충돌할 때, 이를 조율하고 아키텍처 일관성을 유지하기 위한 인간 리뷰어의 가이드라인은 무엇인가?

### Practical Application Contexts
*   **Implementation:** 클래스가 너무 많은 책임을 지지 않게 쪼개고, 인터페이스 기반으로 통신하도록 설계하여 결합도를 낮춥니다 [47].
*   **System Design:** 새로운 모듈 설계 시 기존 객체 지향 구조에 맞게 확장 가능한지 SOLID 관점에서 검증합니다 [48].
*   **Operation / Maintenance:** 원칙을 준수한 코드는 모듈 재사용성이 뛰어나고 Mock 기반 테스트가 쉬워 장기적인 유지보수 비용을 낮춥니다 [49].
*   **Learning Path:** 코드 리뷰를 통해 시니어가 주니어에게 좋은 설계 원칙과 패턴을 전수하는 멘토링 도구로 활용합니다 [50].
*   **My Project Relevance:** 체크리스트에 '아키텍처 및 코드 구조 검토' 항목을 포함하여, PR이 기술 부채를 유발하지 않는지 객관적으로 검증합니다 [51].

### Adjacent Topics
*   **[[Domain-Driven-Design-DDD|Domain-Driven Design (DDD]]**: 비즈니스 도메인의 복잡성을 관리하기 위한 상위 수준의 설계 전략입니다.
*   **Egoless Programming**: 개인의 취항보다 팀의 설계 원칙을 우선시하는 협업 철학입니다.

---
*Last updated: 2026-05-02*
