Framework vs. Library

Framework vs. Library 프레임워크와 라이브러리는 소프트웨어 개발에서 필수적인 구성 요소로, 각각의 목적과 사용 방식이 다르다. 라이브러리는 특정 기능을 제공하는 코드 집합으로 개발자가 직접 호출해 사용한다. 반면, 프레임워크는 애플리케이션의 구조와 흐름을 정의하며, 개발자가 작성한 코드를 필요에 따라 호출하는 ’ 제어의 역전 ’ 원칙을 따른다. 이 차이는 시스템 설계의 핵심 원리와 실무 적용에 큰 영향을 미치며, 각 도구의 장단점, 적용 사례, 최적화 및 실무 적용 시 고려사항 등에서 뚜렷하게 드러난다. 핵심 개념 제어의 역전 (Inversion of Control, IoC): 프로그램의 제어 흐름이 전통적인 방식과 반대로 동작하는 설계 원칙 Hollywood Principle: “Don’t call us, we’ll call you” - 프레임워크가 개발자 코드를 호출 의존성 주입 (Dependency Injection): 객체의 의존성을 외부에서 주입하는 방식 애플리케이션 프레임워크 (Application Framework): 특정 도메인의 애플리케이션 개발을 위한 포괄적인 구조 코드 라이브러리 (Code Library): 재사용 가능한 함수와 클래스의 집합 Framework vs. Library 비교 구분 프레임워크 (Framework) 라이브러리 (Library) 정의 애플리케이션 개발을 위한 구조와 제어 흐름을 제공하는 소프트웨어 플랫폼 특정 기능을 수행하는 코드 집합으로, 필요 시 개발자가 직접 호출 제어 흐름 (Control Flow) 프레임워크가 전체 흐름을 제어하며, 개발자의 코드를 호출 (제어의 역전: IoC) 개발자가 라이브러리를 직접 호출하여 제어 흐름을 관리 사용 방식 프레임워크의 구조에 맞춰 코드를 작성하고, 확장 지점을 통해 기능 구현 필요한 기능만 선택적으로 가져와 호출 구조 제공 애플리케이션의 아키텍처 및 구성 방식을 정의 구조에 영향을 주지 않음 확장성 명확한 확장 포인트 제공 (예: Hook, 인터페이스 등) 함수 단위로 조합하여 사용 가능 유연성 프레임워크의 구조를 따르므로 상대적으로 유연성은 낮음 특정 기능 단위로 자유롭게 사용 가능 재사용성 특정 프레임워크에 종속적일 수 있음 다양한 프로젝트에서 재사용 가능함 예시 Spring, Angular, Django, React (의견 분분하지만 구조 제공 시 프레임워크로 분류되기도 함) Lodash, NumPy, jQuery, Requests 사용 시나리오 비교 구분 Framework Library 적합한 프로젝트 대규모, 복잡한 애플리케이션 특정 기능이 필요한 프로젝트 팀 규모 대규모 팀 (일관성 중요) 소규모 팀 (유연성 중요) 유지보수 프레임워크 업데이트에 의존 개별적으로 관리 가능 테스트 프레임워크 테스트 환경 사용 독립적인 단위 테스트 구조 및 아키텍처 Framework 아키텍처 graph TD A[Framework Core] --> B[Application Lifecycle] A --> C[Dependency Injection Container] A --> D[Configuration Management] A --> E[Plugin System] B --> F[Initialization] B --> G[Execution] B --> H[Cleanup] C --> I[Bean Factory] C --> J[Dependency Resolution] D --> K[XML/Annotation Config] D --> L[Environment Properties] E --> M[Extension Points] E --> N[Custom Components] F --> O[Developer Code] G --> O H --> O Framework 구성요소: ...

November 20, 2024 · 16 min · Me

Hollywood Principle

Hollywood Principle Hollywood Principle 은 객체지향 설계 및 프레임워크 설계에서 널리 쓰이는 원칙으로, “Don’t call us, we’ll call you” 라는 문구로 대표된다. 이 원칙은 저수준 (구현) 모듈이 고수준 (프레임워크, 추상화) 모듈을 직접 호출하는 것이 아니라, 고수준 모듈이 저수준 모듈을 필요할 때 호출하도록 구조를 설계한다. 이를 통해 의존성 부패 (Dependency Rot) 를 방지하고, 시스템의 유연성, 확장성, 테스트 용이성을 높인다. 대표적으로 Inversion of Control, Dependency Injection, Observer, Template Method, Strategy 패턴 등에서 적용된다. ...

February 4, 2025 · 22 min · Me