Framework vs Library vs API

Framework, Library, API 

세 단어 웹 개발을 한다면 많이 접해보는 단어이다.

하지만, 정확히 세 단어의 차이가 뭐냐고 물어보면 논리적으로 설명하기 힘들다.

대략, 느낌적으로는 Framework > Library > API의 순으로 스케일(?)이 큰 느낌이다. (나만 이런 느낌을 받나..?)

내가 알아본 바로, 나만의 방식으로 비유하여 작성해 보겠다.

 

1. Framework : 어떤 물건을 만드는데 필요한 틀, 뼈대라고 이해했다. 컴퓨터 본체로 생각한다면 케이스라고도 볼 수 있을 것 같다.

컴퓨터 케이스 안을 보면, 여러가지 하드웨어 부품을 연결하기 위해 정해진 위치가 있듯이, Application을 개발할 때 공통적으로 많이 사용되는 기능을 편리하게 제공해주는 것이다. 보통 데이터베이스 연동, 알고리즘 등이 있을 것이고, 이러한 틀(Framework)로 객체 지향 개발을 하면서 일관성 부족 등의 문제를 해결해 준다고 볼 수 있다.

 

2. Library : 프레임워크와 비슷한 느낌(?)이라 혼동할 수 있지만, 라이브러리는 특정 기능에 대한 도구나 함수를 모아둔 집합이다.

또.. 말도 안될 수 있지만 내 방식대로 해석해보자면, 흔히 스패너, 망치...등이 들어있는 공구박스가 라이브러리라고 볼 수 있을 것 같다. 못을 박을 땐 망치를, 너트를 죄거나 풀때는 스패너를... 처럼 상황에 따라 단순 활용이 가능한 도구들의 집합이라고 생각한다.

 

3. Framework vs Library : 둘의 차이는 흐름에 대한 제어 권한이 어디에 있느냐의 차이이다.

위의 컴퓨터 케이스와 공구박스 비유가 옳은지는 잘 모르겠다. (정말 초보자가 봐도 알기 쉬운 비유를 누가 알려줬으면 좋겠다...)

일단 내가 비유한 대로 이해해보자면, 컴퓨터 케이스에 각 하드웨어의 자리는 내가 바꿀 수 없다. 이는 바꿔말하면 짜여져있는 케이스에 내가 필요한 하드웨어를 사용하는 것이고, 이를 다시 코드에 비유하자면, 프레임워크는 전체적인 흐름(틀)을 자체적으로 가지고 있고, 그 안에 프로그래머가 필요한 코드를 작성하는 것이다. 다시 말하면, 개발자 마음대로 흐름을 제어하는 것이 아니라 프레임워크에서 정해진 흐름으로 흘러간다는 것이다.

반대로, 라이브러리는 공구박스에 비유했다. 공구박스에서 상황에 맞는 도구를 꺼내 적절히 사용하면 되는 것이다. 웹 에플리케이션에서 게시판 작성하는 기능을 만든다고 생각해보자. 글을 작성할 수 있는 기능을 만드는데, 단순히 textarea의 글만 쓰는 것이 아닌 여러가지 글쓰기 기능을 가진 에디터가 필요로 한다면, 에디터의 기능을 전부 일일이 만들어야한다. 하지만, 누군가가 만들어놓은 에디터 기능이 있다면, 우리는 그 에디터를 내가 만들고 있는 웹 에플리케이션에 껴넣기만 하면 되는 것이다. 다시 정리하자면, 라이브러리는 프레임워크와 반대로 개발자가 흐름을 제어하며, 필요한 상황에 가져다가 쓰는 것이다.

단순히 생각한다면, 웹 에플리케이션을 만드는 개발자가 흐름을 제어하지만, 일정한 틀안에서 정해진 흐름을 가지고 기능을 구현해 가는 프레임워크는 제어의 역전이 적용된다고 한다.

 

4. API : Application Programming Interface -> 응용 프로그램을 작성할 때 필요한 매개체

라이브러리에서 비유에 사용했던 공구박스를 여기서 다시 사용하려니 참 애매하다. 그래도... 굳~이 비유하자면, 공구박스의 망치를 예로 들겠다. 라이브러리에서는 공구박스 자체를 내가 가지고 있고, 거기서 망치를 꺼내 활용했다. 하지만 API는 다르다. 공구박스가 나에게 없는 것이다. 나에게 공구박스가 없어, 공구박스가 있는 다른 사람에게 나무판자를 주며 부탁을 하는 것이다. 나무판자에 망치를 이용해 못을 박아달라. 그리고 난 못이 박힌 나무판자만 얻는 것이다. 

 

실제 날씨 정보를 가져오는 API로 확인해보자. (GeoCoding API) 

 

이 API 사용한지가 좀 오래되서 정확히는 기억이 안나지만,,, 기능은 사용자가 자신의 위치를 위도, 경도로 API 서버에 보내면 주소로 변환해주는 것이다. 실제 내 에플리케이션 로직에는 위도,경도를 주소로 변환해주는 로직이 없지만 구글에서 지원해주는 API를 통해 로직을 이용하여 주소를 얻어내는 것이다. 여기서 요청과 응답은 HTTP로 이루어지며 위도,경도는 나무판자와 못, 망치는 변환하는 로직, 못이 박힌 나무판자는 주소로 비교할 수 있을 것 같다. 

 

5. Library vs API : 라이브러리는 컴포넌트 자체, API는 컴포넌트를 활용하는 규약!

라이브러리와 API에서의 공구박스 활용 위치를 살펴보자. 라이브러리에서는 나무판자에 못을 박기 위해서는 망치가 필요해 내 공구박스에 있는 망치를 사용했다. 하지만 API에서는 나는 나무판자와 못만 상대방에게 주고 상대방이 공구박스의 망치를 이용해 못이 박힌 나무판자를 만들어 준 것이다. 둘의 차이는 망치가 나에게 있느냐 없느냐, 그 망치로 내가 작업을 했냐이다. 

물론 그렇다고 라이브러리와 API가 완전 다른 존재는 아니다. API는 라이브러리는 아니지만 라이브러리 내부적으로는 API를 사용할 수도 있다. API에서 예로 든 GeoCoding API는 라이브러리가 아닌 API이지만 라이브러리에서 예로 든 에디터는 내부적으로 API를 가지고 있을 수 있다는 말이다.