라이브러리, API, SDK, 프레임워크에 대해서

라이브러리와 API에 대해

라이브러리는 유용한 컴포넌트들의 집합이라고 볼 수있다. 여기서의 컴포넌트는 클래스, 함수, 변수 등 그 모든 것들이 될 수 있다.

라이브러리의 사용자는 이 컴포넌트들을 가져다 쓰면 되지만, 처음 라이브러리를 사용하는 사람들은 이것이 어떤 스펙을 가지고 있는지를 알기 위해 소스코드를 보고 해석하는 방법 밖에 없다. 하지만 이마저도 바이너리화 되어 있다면 도저히 알 도리가 없다. 그래서 라이브러리의 사용방법이나 컴포넌트의 인터페이스에 대한 정보가 필요하다. 이런 정보는 흔히 API문서로 정리되어 라이브러리 사용자들에게 라이브러리의 정보가 제공된다.

위에서 들었던 예에서 처럼 라이브러리가 바이너리화 되면 사용자들은 오로지 API만 접하게 된다. 클래스, 변수, 함수 등의  컴포넌트에 대한 선언만이 있을 뿐 내부의 구현까지는 확인할 수 없다. 그래서 처음 라이브러리를 가져다 쓰기 위해서는 라이브러리 사용 메뉴얼이나 API에 대한 기능명세가 필요하다. 이러한 기능명세가 적힌 것이 API문서 혹은 Development Document이다. 물론 API는 SDK에서도 프레임워크에서도 제공할 수 있다.

라이브러리와 SDK에 대해

SDK는 Android SDK, iOS SDK, Windows 10 SDK 등 운영체제 기능을 제공하기 위한 SDK, 카카오나 페이스북SDK 처럼 서비스를 제공하기 위한 SDK 등이 있다. 이처럼 SDK는 모두 대상이 되는 운영체제나 서비스 등이 존재한다. 

반면 라이브러리는 오히려 알고리즘이나 특정 로직을 작성하여 편리하게 사용한다는 데 목적이 있기 때문에 SDK와 사용목적에서 차이점을 찾아볼 수 있다. 그리고 라이브러리는 프로그래밍 언어에만 종속되기 때문에 운영체제나 서비스에도 의존성을 갖는 SDK에 비하면 경량성과 이식성이 훨씬 좋아야 한다. 그래서 만약 라이브러리 안에 SDK가 종속되면 그 라이브러리는 라이브러리라 부르기가 참 민망해진다.

프레임워크에 대해

프레임워크는 디자인패턴과 뗄 수 없는 사이다. 대표적으로 스프링 프레임워크를 들 수 있는데, 이 프레임워크를 조금만 찾아보면 MVC패턴과 DI(Dependency Injection)에 대해 듣게 될 것이다. 고급 패턴에 속하는 이 패턴들은 응용 개발자가 직접 구현해서 사용하기에는 많은 시간과 노력이 필요하다. 게다가 아무리 쉬운 패턴이라고 해도 구현은 번거롭고 지루하다. 따라서 프레임워크는 패턴과 관련된 구현의 현실적 어려움이나 불필요한 작업의 반복을 최소한으로 하기 위해 미리 구현된 디자인패턴을 개발자에게 컴포넌트와 API로 제공한다.

ps) 가끔 프레임워크를 설명할 때 프레임워크에서 코드를 호출한다는 것으로 프레임워크를 구분하려 하는데 이는 적절하지 않다. 왜냐하면 이는 프레임워크에 DI가 구현되었기 때문에 가능한 것이며, DI 역시 패턴의 하나이다.