라이브러리 vs 프레임워크

라이브러리 vs 프레임워크

간단한 정리

• 라이브러리, 프레임워크 둘다 공통으로 사용될 수 있는 특정한 기능들을 모듈화한 것
• 라이브러리
  • 폴더명, 파일명에 대한 규칙이 없고, 프레임워크에 비해 자유로움
  • ex.) 자동차(창문열기, 경로 변경 등이 자유롭다, 그러나 제공되는 서비스는 별로 없다.), axio, React.js
• 프레임워크
  • 폴더명, 파일명에 대한 규칙이 있고, 라이브러리에 비해 더 엄격함
  • ex.) 비행기(창문열기, 경로변경 불가능, 그러나 승무원이 제공해주는 서비스가 있음), vue.js, Django

제대로된 정리

프레임워크와 라이브러리의 차이

• 우리가 작성하는 코드와의 관계에 있어서 차이가 있다.

프레임워크

• 내가 작성한 코드가 프레임워크를 호출하는 것이 아니라, 프레임워크가 필요할 때, 내가 작성한 코드를 호출한다.
• 프레임워크는 애플리케이션 전체 실행의 흐름을 좌우한다.
  • 그래서 특정 프레임워크로 개발된 애플리케이션을 다른 프레임워크로 바꾸기 어렵다.
  • 실행의 흐름이 이미 해당 프레임워크에 맞춰서 개발되어 있으므로
• 제어의 역전(IoC) 개념이 적용된 대표적인 사례

라이브러리

• 내 코드를 필요할 때 호출해서 사용
• 라이브러리의 경우, 상대적으로 다른 라이브러리로 바꾸는 것이 간단하다.
  • 내가 작성한 코드에서 부분적으로만 사용되고 있기 때문에.

<aside> 💡 핵심은 프레임워크가 내가 작성한 코드를 호출한다는 것이다. → 제어의 역전(IoC: Inversion Of Control)

</aside>

• 즉, 프레임워크와 라이브러리의 차이점에 있어서 핵심은 애플리케이션의 실행 흐름을 누가 쥐고 있느냐에 달려 있다.
• 프레임워크에게 제어의 흐름을 넘겨서 개발자가 작성하는 코드에서 신경써야 할 부분을 줄인다.
• 프레임워크가 전체적인 흐름을 쥐고 있으며, 애플리케이션 코드는 프레임워크가 짜 놓은 틀에서 수동적으로 동작하기 때문에 제어의 흐름은 프레임워크에 있다.
• 반면 라이브러리는 개발자가 전체적인 흐름을 만들고, 라이브러리를 가져다가 쓴다. 즉, 개발자에게 전적으로 제어의 흐름이 있으며 필요할 때마다 능동적으로 라이브러리를 호출하여 사용한다.

• 프레임워크는 라이브러리를 포함한다.
  • 프레임워크 위에 개발자가 작성한 애플리케이션 코드가 올라가게 되고, 이 애플리케이션 코드에서 라이브러리를 호출할 수 있다.
• 프레임워크는 그 스스로 제어의 흐름을 가지고 있는 반면, 라이브러리는 개발자가 가지고 있다.
• 프레임워크는 집이고, 라이브러리는 집 안의 가구
• 라이브러리와 달리 프레임워크는 이미 프로그래밍에 대한 규칙을 가지고 있다.
  • 예를 들면 설정파일의 태그설정이나, DB연동 방법 등에 대한 규칙을 가지고 있고 개발자는 이를 따라야한다.

IoC

• IoC는 제어의 역전이라는 뜻으로 프로그램의 제어 흐름을 직접 제어하는 것이 아니라 외부에서 관리하는 것을 말한다.
• 이전에는 개발자가 객체를 생성하고 관리하며 프로그램의 제어 흐름을 스스로 조종했다.
• 하지만 Spring을 사용하면 스프링 컨테이너가 프로그램의 제어흐름을 제어하게 된다.
• 스프링에서는, 스프링 IoC 컨테이너에 의해 관리되고 애플리케이션의 핵심을 이루는 객체들을 Bean이라고 부른다.
• Bean은 스프링 IoC 컨테이너에 의해 인스턴스화되어 조립되거나 관리되는 객체를 말한다.

참고 링크

[개발상식] 프레임워크(Framework) 와 라이브러리(Library)의 차이

프레임워크(Framework)와 라이브러리(Library)의 차이