* 비유는 접근성을 높일지라도 본질을 흐리기 마련입니다.
해당 포스트는 실습 과정 중 학습을 정리하는 글이기에 주관적인 내용이 포함되어 있을 수 있습니다.
잘못된 부분이 있다면 걸러들으시거나 댓글로 남겨주시면 감사하겠습니다.
* CS 카테고리의 흐름 정리 파트는 정확한 개념 파악보단 전체적인 흐름을 이해하는데 초점을 맞춰 진행합니다.
* 예전에 쓴 글이다보니 의욕이 앞섰는지 존댓말이 아닌 반말로 진행되는 점 양해 부탁드립니다. 언제 한 번 수정하겠습니다.
Index
1 API? 그게뭔데?
2 프레임워크와 라이브러리? RESTAPI?
3 정리
API? 그게뭔데?
우선 글을 시작하기에 앞서 예시 하나를 들어보겠다. A와 B가 있고 이 둘 사이는 줄로 이어져있으며 어떤 버튼을 누르면 무언가 전해줄 수 있다고 가정해보자. 그 가정에서 어떤 버튼이 맡은 역할은 API이고, 어떤 버튼을 어떻게 만드는지 적힌 설계도가 API 사양, 어떤 버튼의 실물 자체는 API의 구현체로 볼 수 있다. 이 말이 너무 어렵게 느껴질 수도 있으니 글을 이어가겠다.
# 교양으로 가볍게 보는 분들을 위한 예시
흔히 일상에서 게임(대표적으로 마인크래프트)나 어플에서 무언가 API를 연동한다는 문장을 많이 접할 수 있을 것이다.
조금 더 구체적인 예를 들어 게임 마인크래프트에서 누군가의 후원을 받으면 내가 아이템을 받는다고 생각
해보자. 근데 누군가 후원을 했는데 나에게 아이템이 안들어와서 후원한 사람이 'API 연동되었는지 확인하셨나요?'라고 질문했다고 하자. 이 때 API라는 단어를 '후원 버튼'으로 치환해서 이해해보면 조금 더 쉽게 알 수 있을 것이다.
하지만 개발자라면 교양 정도로는 부족하다. 처음 코딩 공부를 시작했을때 API는 너무나도 뜬구름 잡는 개념이었다.(사실 지금도 그렇지만...) 처음에 API를 받아들이기 힘들어 개발자들이 사용하는 추상적인 도구라는 식으로 이해하고 넘어갔던 것 같은데, 이게 공부를 진행함에 있어 API가 나올때마다 뭔가 답답한 느낌이 조금씩 쌓인다고 느껴져 이를 한번 더 정리하고 넘어가기로 했다.
일단 API는 개발 공부를 하고 있는 사람이라면 정말 많이 들어본 개념일테고 대충 무엇인지 아는 사람도 존재할 것이다. 하지만 API가 무엇인지 설명해보라고 했을땐...?
잘 설명이 안된다. '모르면 위키에 쳐보면 되지!'라는 생각으로 API를 쳐보면...
그렇기에 이 포스트에서 저 복잡한 정의를 한 번 설명할 수 있는 수준까지 이해해보도록 하자. 우선 약어의 의미를 알기 위해선 Full name을 알아야한다. API란 Application Programming Interface다. 여기서 3단어 각각의 의미는 충분히 알겠지만 종합해서 의미를 파악하기엔 다소 어려워보인다.
그렇기에 다음으로 API와 같은 level들을 살펴봐야한다.(엄밀히 말하면 완전히 같은 level은 아니라고 하지만 너무 깊은 의미까지는 들어가지 않겠다.) 이에는 ABI(Application Binary Interface), UI(User Interface)가 있는데 이 단어들을 나열해보니 맨처음보단 조금 의미 파악이 될 듯 하다. API, ABI, UI엔 각각 binary, programming, user 세 단어가 비교군에 있는데 이를 하나씩 살펴보겠다. 기계어로 된 코드를 binary code라고 하는걸 들어봤을텐데 binary란 사전적으로 이진, 쌍의 라는 뜻을 지니고 있으며 보통 0과 1로된 기계 수준의 정보 저장 형태라고 알면 되고 비교군을 살펴볼때 binary를 기계라고 간주해도 무방할 것 같다. programming은 당연히 program을 다루는 programmer로 간주하면 될 것이고, user는 user 그 자체로 보면 될 것이다.
한마디로 저 셋을 컴퓨터, 프로그래머, 사용자 세 명이 다루는 각각의 인터페이스라고 생각한다면 조금 더 이해가 잘 될 것 같다. 여기서 한 발자국 더 나가서 비교군 중 가장 이해하기 쉬운 UI를 보고 그 이후 다른 비교군으로 확장해나가면 API에 대한 이해가 더 깊어질 것이다.
그렇다면 우선 본격적으로 UI(User Interface)를 살펴보기 전에 Interface에 대해 더 다가가보자. Interface의 사전 정의는 이렇다.
두 물체, 공간, 단계 등의 공통 접점면
독립되고 관계가 없는 시스템이 접촉하거나 통신이 일어나는 부분
인터페이스에서 상호작용이나 통신이 일어날 때의 수단인터페이스가 감이 너무 안잡히신다면 필자의 다른 글인
https://fadet-coding.tistory.com/36를 보시거나 검색을 해보시길 추천합니다.
그렇다면 인터페이스를 우리는 어떻게 받아들이는게 맞을까? 심화해서 얘기하자면 끝도 없겠지만 글이 너무 길어지지 않게 짧게 이해하고 넘어가자면 서로 다른 환경의 만남이라고 볼 수 있을 것 같다. 더 나아가 UI는 살면서 너무나도 많이 듣게 되는 개념인데. 앱을 쓰다 '흠... UI가 이러면 더 좋았을텐데...'라고 많이들 하듯이 우리가 흔히 말하는 UI는 사용자와 시스템 간의 소통의 매개이다. 쉽게 말해 사람 <-> 기계간의 매개라고 보면된다. 우리가 스마트폰 앱을 사용할때 쓰는 손가락부터 누르는 터치스크린, 서버로 무언가 요청을 보내는 버튼 등이 다 이에 속할텐데 그렇다면 UI는 우리 입장에선 시스템과 사용자 사이의 소통 매개체라고 생각하는 것이 편할 것이다. 참고로 같이 많이 언급되는 UX(User Experience)는 이를 포괄하는 유저의 시스템 사용 경험이라고 생각하면 될 것 같다.
UI를 대충 알아봤으니 이제 다시 돌아가 API를 이해하려는 시도를 해보자. 우선 API의 대략적인 느낌은 유저가 스마트폰을 이용하기 위해 버튼을 누르듯(UI) 개발자가 어떤 기능을 요청하기 위해 누르는 버튼이라고 생각하면 편하다.
# UI를 이해한 분들을 위한 예시
우리가 어플을 사용해 배달 주문을 한다고 가정해보자. 먹고 싶은 음식을 모두 장바구니에 담고 이제 결제 버튼을 누르면 배달이 시작된다. 이 때 앱에서 누르는 '결제'란 버튼 자체가 하나의 UI다. 앞선 UI에 대한 예시를 확장하면 API에 대한 감을 확실히 잡을 수 있다. 이번엔 내가 결제하기 전을 한 번 생각해보자. 당신은 장바구니에 추가하기 위해 먹고싶은 음식의 카테고리나 음식점명을 검색했을 것이다. 여기서 검색을 위한 돋보기 버튼, 검색창, 카테고리 버튼 모두 다 UI다. 1차적으로 UI를 통해 사람이 배달앱(클라이언트)에 정보를 전달했다. 하지만 이 상태에선 내 스마트폰에 깔린 배달앱(클라이언트)만이 당신이 뭘 먹고 싶은지 알 것이다. 바로 이 때 배달앱(클라이언트)에서 배달앱 회사(서버)로 그 정보를 전달하는 매개체가 API다. API와 UI의 일반적인 구분점은 1. UI는 사람 <-> 기계, API는 기계<->기계 2. UI는 사용자의 눈에 보이지만 API는 사용자의 눈에 보이지 않음 이다.
위의 예시는 정말 일반인을 위해 간단히 든 것이고 이후부터는 개발을 공부하는 분들을 위해 작성하겠다.
우리가 가장 흔하게 API 요청을 하는 경우를 살펴보자. 로컬로 개발 중일때 포스트맨처럼 툴을 따로 쓰거나 IDE 플러그인으로 API 요청을 보내는 경우도 있겠지만 그런 개발자부터 사용자까지 일상에서 접하는 가장 익숙한 API 툴이 존재하는데 그것은 바로 '브라우저'이다. 브라우저로 크롬을 사용한다고 했을때 내가 어떤 홈페이지에 들어가고 싶으면 주소창에 URL을 작성하는데 그 URL이 바로 API 요청이다. GET, POST 등 요청 형식/엔드포인트가 위치한 URI/구체적인 번호 등을 포함하는 요청 파라미터 보통 이렇게 3가지 요소로 구성되는 URL을 사용하여 브라우저를 쓰는 우리는 날마다 API 툴을 이용해 서버에 API 요청을 보내고 있는 것이라고 생각하면 된다.
(이 글에선 웹 페이지 요청과 API 요청을 우선 구분하지 않겠습니다)
이제 조금 구체적인 예를 하나 들어 우리가 날씨앱을 만든다고 가정해보자. 우선 날씨앱을 만든다고해서 막무가내로 우리가 날씨에 대한 정보를 DB부터 구축해서 하루하루 관찰한 후 기록한 뒤 분석한다는 건 사실상 말이 안된다. 당연히 기상청으로부터 날씨 정보를 가져와 그를 기반으로 앱을 구축해야 할 것이다.
그 다음 나에게 스마트폰이 없다면 자기가 기상청까지 걸어가서 정보를 얻어야하겠지만 우리는 스마트폰이 있으니 이를 사용하자. 자, 이 때 당신은 스마트폰을 이용해 기상청에게 어떻게 정보를 얻을 것인가?
우선 가장 오래된 방식인 전화나 문자가 있을 것이다. 하지만 요샌 전화로 그렇게 정보를 얻는 것보단 직접 기기를 조작하여 정보를 얻는 것을 더 선호하니 그 방식을 사용해보자. 기상청은 더욱 쉽게 정보를 사용자가 얻을 수 있도록 기상청 앱을 우리에게 제공한다. 당연히 당신은 앱을 실행시켜서 내일 날씨에 대한 버튼을 하나 누를 것이고 내일 날씨가 화면에 그려질 것이다. 그렇다. 그 버튼을 누른 뒤 당신이 이해하기 쉬운 정보를 제공받았다면 그 버튼은 당신과 기상청의 시스템이 소통하는 가장 최적의 UI인 것이다. UI를 통해 시스템과의 소통을 위해 해야하는 복잡한 과정을 사용자가 하나하나 거칠 필요가 전혀 없고 실행 후 버튼만 누르면된다. 하지만 이 말은 당신이 개발자가 아닌 사용자일 때에 한해서이다.
앱의 경우 손가락을 통해 버튼만 누르더라도 사용자와 시스템간의 충분한 소통이 가능하기에 사용자에게 필요할만한 정보를 제공해줄 수 있겠지만, 날씨 앱을 만드는 개발자는 코드를 짜는 사람이기에 단순히 버튼을 누른다고 개발자에게 필요할법한 수많은 정보들을 제공하지는 않는다. 그리고 무엇보다 당신은 사용자가 아닌 개발자이다. UI는 '사용자'와 시스템 간의 매개라는 것을 잘 생각해보자.
다시 앱을 만드는 과정으로 돌아가서 개발자가 서울의 날씨 정보를 직접 기상청 DB에서 가져와야한다고 생각해보자. 물론 이 때 그 모든 정보를 서버DB로 가져와 직접 쿼리를 작성해 필요한 정보만을 사용할 수는 있다. 하지만 기상청에서 공개한 정보가 얼마나 될 줄 알고 그 모든 데이터를 긁어올 것인가?
이 과정에서 많은 개발자들은 생각했다. '앱의 사용자는 버튼을 누르기만 해도 원하는 정보를 쉽게 얻을 수 있었는데 개발자도 기상청에 날씨 정보를 요청만 하면 그 정보를 앱 화면에 띄우기만 하면 참 편리할 것 같지않은가?'. 여기서 API는 이것을 가능케 한다. 앞서 말했던 외부에 공개된 public한 정보들 중 개발자가 원하는 범위만 취사 선택하여 코드를 작성해 API 요청을 보낸다면 우리 서버는 최근 한달 서울의 날씨 정보처럼 필요한 데이터만큼의 응답만 받을 것이다.
이처럼 API는 UI가 사용자와 시스템의 쉬운 소통을 매개하듯이 개발자와 시스템간의 쉬운 소통을 매개하는 것이다. 여기서 API의 정의를 다시 살펴보겠다. UI는 사용자가 손가락으로 버튼을 터치한다는 눈에 보이는 level에서 소통을 하지만 API는 더 나아가 개발자가 코드 level에서 시스템(소프트웨어)과 소통을 하는 인터페이스를 말한다.
여기까지 글이 너무 길었으니 알기 쉽게 핵심만 정리하면 이렇다.
- 사용자는 날씨 정보의 분석, 통신 등의 과정을 알 필요 없이 버튼이라는 인터페이스에 대한 이해만 하면된다.
- 개발자는 기상청 내의 DB 내부, 정보의 가공 과정을 알 필요 없이 API라는 인터페이스에 대한 이해만 하면된다.
앱을 사용하는 사람이라면 그냥 단순히 내일 우리 지역 날씨만 알고싶은데 사용할때마다 다른 외부 정보를 알아야한다면 더 이상 그 앱을 사용하지 않을 것이다. 마찬가지로 만약 수정할때마다 개발자가 직접 기상청 DB에서 필요한 정보를 가져와야 한다고 생각해보면 일단 권한도 승인 받아야하고 기상청 DB 스키마도 알아야하고... 등등 내가 필요한 앱을 제작하는데 써야할 쓸데 없는 시간이 너무 많이 소요된다. 당연히 좋은 개발자라면 API뿐만 아닌 관련 정보를 아는 것이 실력을 키우는데 도움이 되겠지만 API는 개발자가 수많은 부가 시간을 쓸 필요 없이 본인의 전문 분야에 힘을쏟는데 엄청난 득이 되어줄 것이다.
잘 사용하는 용어는 아니지만 비슷하게 생긴 ABI도 잠시 언급해보면 ABI 역시 기계와 시스템의 소통을 컴퓨터 내부 level에서 하게 만드는 인터페이스라고 보면 될 것 같다. ABI도 아키텍처, 런타임 호환성 등의 개념부터 엄청 깊은 수준까지 파고들 수 있기때문에 이쯤 살펴보고 넘어가는 것이 좋을 것 같다
API의 대략적인 느낌을 잡아냈다. 그렇다면 좀 더 디테일하게 다듬어보자. 글의 맨 처음 API를 버튼이 아닌 버튼의 '역할'이라고 표현했었다. 만약 필자와 같이 스프링을 사용하는 사람이라면 '역할'과 '구현'이라는 단어에 익숙할 것이다. 만약 와닿지 않는다면 '역할' 대신 '논리', '추상', '사양' 정도의 단어로 대신해서 이해하면 편할 것이다.
이를 이해하기 위해 조금 다른 설명을 해보겠다. API란 어떤 소프트웨어를 접근할때 좀 더 쉽게 개발 관련 정보를 제공받기 위한 장치인데 여기서 개발자라면 너무나도 친숙한 라이브러리가 떠오를 것이다. 그렇다면 라이브러리 또한 API로 보면 될까? 흠 정확히는 아니다. 하지만 아주 틀린 것도 아니다. 라이브러리는 쉽게 말해서 API의 구현체라고 생각할 수 있다.
좁은 의미에서 API는 정의된 프로토콜을 기반으로 소통을 더욱 쉽게 해주는 일종의 인터페이스 사양이기에 추상적인 개념이며 이를 구현하여 결과물로 만든 라이브러리는 API의 구현체이다. API는 인터페이스기에 정하기에 따라 정보의 다양한 제어를 할 수 있지만 라이브러리는 특정 분야에 집중해서 정보를 제어하도록 구현되었기에 개발자에게 구체적인 결과물을 줄 수 있지만 쓰임새가 다른 분야에는 사용하기 어려우며 이후 나올 프레임워크 역시 그런 다수의 라이브러리를 포함한 틀과 같기에 차이가 있다.
예를 들어 일반적인 웹 어플리케이션에 특화된 spring 프레임워크로 인공지능 분야의 시스템을 구축하는 것이 매우 어렵듯 구현체가 개발자에게 특정 분야에 도움이 되면 될수록 다른 분야로 확장하기엔 무리가 존재한다. 따라서 좁은 의미의 API는 추상적인 인터페이스 사양이며 넓은 의미의 API는 이 추상 인터페이스에 라이브러리나 프레임워크 같은 구현체까지 포함한 것이다. 더 나아가 API는 추상적인 사양이기에 라이브러리 같은 구체적인 구현과는 독립적이다. 또, 우리가 자바를 접할때 많이 듣는 SDK(Software Development Kit)는 프로그램 개발에 필요한 라이브러리와 함께 API가 제공되는 프로그램이다.
이제 살펴본바를 종합해서 다시 맨 처음 예시와 비교해보면 좁은 의미의 API를 의미하는 추상적인 인터페이스를 메뉴판의 '역할'이라고 볼 수 있고 넓은 의미의 API에 포함되는 인터페이스의 구현체를 메뉴판이라고 하면 될 것 같다. 앞서 프로토콜이란 용어를 사용했는데 이 프로토콜을 이 예시에 끼워보자면 '한국에 있는 식당이니까 메뉴판의 언어는 한글로 하자', '메뉴판에 꼭 표기해야할 건 메뉴의 이름과 가격으로 하자' 같이 가게마다 통용되는 사항이라고 생각하면 된다.
* 프로토콜에 대한 조금 자세한 설명은 https://fadet-coding.tistory.com/36 참고
요약해보자면 좁은 의미에서 UI는 어플리케이션 표면 수준에서 정의되는 인터페이스이며 API는 소스 코드 수준에서 정의되는 인터페이스라고 할 수 있고 ABI는 바이너리(기계) 수준에서 정의되는 인터페이스이다. 또한 이들을 넓은 의미로 확장했을때 그 구현체들 또한 포함한다고 생각하면 될 것 같다.
프레임워크와 라이브러리? RESTAPI?
앞서 살펴본 프레임워크와 라이브러리를 좀 더 살펴보자.
흔히 특정 기능을 묶은 라이브러리 모음을 프레임워크로 정의한 뒤 넘어가곤 하는데, 개발자들에게 라이브러리와 프레임워크의 좀 더 정확하고 와닿는 구별은 제어 흐름(Control Flow)의 주도권이 누구에게 있냐로 볼 수 있다. 흔히 스프링 컨테이너를 IoC(Inverse of Control) 컨테이너라 부른다. 스프링을 사용해보면 알겠지만 코딩 과정에서 필요한 객체가 있다면 코더가 직접 control하여 생성하는 것이 아닌 컨테이너에게 DI(dependency Injection)받는다. 더 자세한건 나중에 다루기로하고 앞서 살펴본 스프링처럼 전체적인 제어 흐름은 스스로가 쥐고 있고 코더는 필요한 코드만 짜넣는 API 구현체를 프레임워크라 하며 이와 다르게 코더가 전체적인 흐름을 쥐고 호출하는 주체이며 필요에 따라 호출되는 객체인 API 구현체를 라이브러리라 할 수 있겠다.
(모든 라이브러리나 프레임워크가 API 구현체인 것은 아닙니다. 하지만 이렇게 이해하는 것만으로도 충분합니다.)
이때까지 API에 대한 공부를 해봤으니 가장 유명한 REST API에 대해 살펴보자. 사실 REST API란 용어는 엄밀히 말하면 RESTful API, REST스타일의 HTTP API가 더 정확한 표현이지만 실제 개발 현장에선 이 세 단어들이 모두 혼용되기에 넘어가겠다.
REST란 네트워크 통신을 구성할 때 설계에 대한 통일을 하게끔 하는 지침을 뜻한다. 한마디로 REST는 API가 네트워크 통신을 할 때 내용을 누가봐도 이해가 되게끔(당연히 개발자 level부터) 정하라는 일종의 디자인 스타일이다. 그렇기에 REST API란 말은 사실 없는 말이고 REST라는 유명한 지침을 더욱 잘 준수하는 API를 'RESTful API'라고 부른다.
쉽게 네트워크 통신을 할 때 개발자 입장에서 HTTPRequest를 보내서 JSON 또는 XML 형식으로 데이터 묶음이 온다면 RESTful API라고 보면 될 것이고 일반적으론 요청 방식이 GET, POST, PUT, DELETE 중에 하나고 매핑되는 DB 쿼리가 CRUD에 해당되는 경우엔 거의 해당된다고 보면 편하다.
RESTful API는 자세하게는 무상태성으로 대표되는 HTTP 프로토콜을 기반으로 자원(Resource)을 URI로 식별하고, HTTP 메서드(GET, POST, PUT, DELETE 등)의 의미를 일관되게 사용하는 등의 REST 아키텍처 스타일을 준수하는 API를 의미하며 단순히 위 문단의 조건에 해당된다고 REST API라고 할 수는 없지만 처음 학습하는 단계에선 이를 모두 이해할 필요는 없습니다.
정리
API에 대한 나름의 정리를 위해 포스트를 해봤는데, 잠깐 다른데로 샜지만 이 포스트를 읽고 다시 처음의 정의를 보면
어떤가? 아까보단 이해가 조금되나? 아직도 감이 안잡힌다면 처음 들었던 예시를 다시 꺼내보자. 이 포스트대로 정리해보면 소프트웨어 두개가 있고 이 둘 사이는 네트워크로 이어져있으며 버튼을 누르면 정보가 이동한다고 가정해보자. 이 버튼의 역할이 API가 될 것이고, 이 버튼을 어떻게 만드는지 적힌 설계도가 API 사양, 버튼 자체는 API의 구현체라고 하면 될 것 같지 않나? 그리고 여기서 가장 중요한 것은 API란 '사용자에겐 보이지 않는 컴퓨터나 컴퓨터 프로그램 사이의 연결'이라는 것이다. 이를 넓게 해석하면 개발자와 시스템, 개발자와 개발자 정도까지로 볼 수 있겠지만 중요한 것은 결국 사용자에겐 보이지 않는다는 것이다. 물론 의도하고 사용자에게 API를 노출할 수야 있겠지만 말이다.
필자도 자바를 주로 공부하기에 자바를 만약 접한 분을 위해 추가로 적어보자면
자바엔 Interface와 Class가 존재합니다.
Class는 Interface를 구현하여 작성하게되는데 실제 개념은 좀 차이가 있지만 비유적으로 이 과정은 앞서 살펴본 API 학습 과정과 유사합니다.
Interface는 구현할 Class에 포함될 메소드를 선언하며 이를 구현하는 Class는 반드시 해당 메소드를 포함해야 합니다.
하지만 Interface에는 단지 메소드명만 선언하며 각 메소드들은 Class로 구현되지 않으면 별 쓸모가 없습니다.
둘이 정확히 같은 것은 아니지만 이해할 때 API도 이같은 interface처럼 바라본다면 조금 더 잘 파악할 수 있습니다.
위에서 Interface에 java 언어로 메소드명을 선언했듯 API도 특정 프로토콜로 사양을 선언합니다.
이 다음 Interface가 Class로 구현되며 메소드가 구체화되듯 API 역시 그 구현체로 구현되며 정해진 사양이 구체화됩니다.
'CS' 카테고리의 다른 글
| 배경학습_2_이더리움, NFT, 그리고 지금의 블록체인 (0) | 2022.05.24 |
|---|---|
| 배경학습_1_블록체인과 정보의 가치 (0) | 2022.05.17 |
| 4_짧_프로토콜과 인터페이스 (0) | 2022.05.06 |
| 2_흐름정리_백엔드란? (0) | 2022.02.17 |