우리가 사용하는 웹과 앱 서비스는 사실 서로 말을 주고받으며 움직입니다. 사용자인 클라이언트가 “이 정보 보여줘”라고 요청하면, 서버는 “여기 있어”라고 응답하는 방식입니다. 이때 서로 어떻게 말해야 하는지를 정해 놓은 약속이 바로 API(Application Programming Interface) 입니다.

API는 프로그램과 프로그램이 정해진 형식으로 데이터를 주고받기 위한 규칙이며, 로그인, 결제, 지도, 날씨 같은 대부분의 기능이 API를 통해 동작합니다. 즉, API를 이해하면 서비스가 어떻게 작동하는지 그 구조를 읽을 수 있게 됩니다. IT 서비스에서 자주 등장하는 이 개념을 알고 나면, 개발과 기획 모두를 바라보는 시야가 훨씬 넓어질 거예요!

IT 서비스는 API로 말해요

"행정복지센터에서 부동산 등기부등본을 열람하는 상황"을 예시로 들어 'API'를 설명해 보겠습니다. 바로 다음과 같은 과정으로 진행된다고 가정해 봅시다.

① 일단 행정복지센터로 가야 합니다. (어떻게 정보 열람을 신청하는지 몰라도 괜찮습니다.)
② 행정복지센터에 가면 친절한 설명과 함께 정해진 양식의 신청서가 준비되어 있습니다.
③ 우리는 안내에 따라 '부동산 등기부등본 열람' 신청서를 작성합니다.
④ 형식에 맞춰 작성한 신청서를 담당자에게 전달하면 민원 신청은 끝이 납니다.
⑤ 이제 담당자가 신청한 정보를 찾아서 '등기부등본'이라는 정해진 형식의 문서로 우리에게 전달합니다.

이러한 민원 처리 과정은 클라이언트와 서버의 통신 방식과 거의 동일합니다. 민원인의 요청이 들어오면, → 담당자는 요청을 처리하고, → 그 결과를 민원인에게 응답합니다. 민원인이 클라이언트, 행정복지센터의 담당자가 서버의 역할을 하는 셈입니다.

여기에서 주목해야 할 점은 민원인과 담당자가 요청과 응답을 주고받는 방법입니다. 클라이언트인 민원인과 서버인 담당자는 정해진 형식의 문서를 통해 소통합니다. 클라이언트는 '민원 신청서'라는 문서로 서버에게 요청을 전달하고, 서버는 처리 결과를 '부동산 등기부등본'이라는 문서로 클라이언트에게 응답합니다.

다른 민원인이 와도 행정복지센터는 동일하게 움직입니다. 만약 누군가가 다짜고짜 담당자에게 가서 '나를 모르느냐'며 소리를 지르면 어떻게 될까요? 담당자는 당연히 해당 민원인의 요청을 들어 줄 수 없습니다. 절차에 맞지 않을 뿐만 아니라, 어떤 민원인인지조차 알 수 없으니까요!

부동산 등기부등본 문서가 어려워서 이해를 못하겠다고, 본인이 이해하기 편한 방식으로 바꿔서 달라고 해도 소용없습니다. 같은 형식의 민원 신청서를 받고, 같은 형식의 등기부등본을 출력해 줍니다. 이러한 문서들은 행정복지센터에서 사용되는 일종의 통신 법칙인 셈입니다.

수많은 클라이언트의 요청을 처리하는 IT 서비스의 서버 역시 본인만의 서버 법을 만들 필요가 있습니다. 서버가 제공하는 기능의 범위와 요청 방식, 응답 결과의 형태를 미리 정해두는 것이죠. 이때, 서버가 만든 통신 규칙을 'API'라고 부르는 것입니다.

API (Application Programming Interface)
서로 다른 컴퓨터나 소프트웨어가 데이터나 기능을 주고받을 수 있도록 하는 표준화된 통신 규칙

Application Programming Interface라는 이름만 보면 어떤 역할을 하는지 잘 이해가 가지 않죠?

일단 인터페이스(Interface)부터 이해해 봅시다. 인터페이스는 서로 다른 두 개체가 상호작용할 수 있도록 도와주는 매개체를 의미합니다. 프런트엔드가 바로 대표적인 인터페이스입니다.

우리는 애플리케이션을 매일같이 사용하지만, 그 내부의 동작까지는 전혀 알지 못합니다. 화면에 보이는 버튼을 누르기만 해도 원하는 대로 사용할 수 있죠. 사실 이는 사용자가 프런트엔드를 통해 요청을 하고, 애플리케이션은 응답값을 프런트엔드에 보여 주는 방식으로 프런트엔드가 통신 매개체로 동작하고 있기 때문입니다.

클라이언트와 서버의 관계도 사용자와 애플리케이션의 관계와 크게 다르지 않습니다. 클라이언트는 서버가 어떻게 동작하는지 잘 알지 못하지만, 서버에 요청을 보내고 싶어 합니다. 즉, 원하는 대로 움직이도록 서버에게 명령(Programming)을 하고 싶은 것입니다. 이때 클라이언트는 API라는 인터페이스를 활용합니다.

마치 애플리케이션이 사용자를 위해 프런트엔드를 제공하는 것처럼. 서버는 클라이언트를 위해 API라는 통신 규칙을 제공합니다. API만 있다면, 클라이언트는 그 서버가 어떻게 생겼는지, 정확히 어떤 로직으로 동작하는지 몰라도 괜찮습니다. API가 정해 놓은 규칙에 따라 서버에 요청을 보내고, 응답을 받기만 하면 되니까요!

정리하면, API는 특정 자원(Application)을 원하는 대로 사용(Programming)할 수 있도록 도와주는 매개체(Interface)라는 의미로 볼 수 있습니다. 쉽게 이야기하면 API는 클라이언트에게 제공되는 서버 사용 설명서인 셈입니다.

API의 중요성

이런 API가 없어진다면 어떤 문제가 발생할까요? 다시 행정복지센터로 돌아가서 생각해 봅시다. 일단 민원 신청 과정부터 혼란스러워집니다. 민원인은 민원 신청에 필요한 내용을 하나하나 알아내야 하고, 결과물을 얻더라도 담당자가 말로 줄줄 설명해주는 내용을 어떻게든 알아들으며 파악해야 하겠죠.

정해진 문서로 소통하면 명확하고 간단하게 끝날 일인데, 상상만으로 머리가 아픕니다.

클라이언트와 서버의 통신 과정에 API가 없을 때 발생하는 문제도 이와 크게 다르지 않습니다. 서버가 갑자기A PI를 없애 버렸다고 가정해 봅시다. 이제 클라이언트는 기상청 서버와 어떻게 통신해야 할까요? API가 없다면 클라이언트는 요청을 보내기 위해 뭘 해야 하는지 알 수 있는 방법이 없습니다. 심지어 요청을 보낼 서버의 위치조차 말이죠!

겨우겨우 서버의 네트워크 주소를 알아냈다고 쳐도, 바로 요청을 보낼 수 있는 건 아닙니다. 해당 서버가 어떤 언어를 사용하고 어떤 로직으로 돌아가는지 알 수 없으니까요. 또 겨우 서버에 데이터 조회 요청을 보냈다고 해도, 고생 끝에 응답 받은 데이터 또한 친절하지 않을 가능성이 큽니다. 서버가 내부적으로 사용하는 데이터 형태를 그대로 응답값으로 줄 것이기 때문입니다.

이러한 불편함은 API를 통해 간단하게 해결할 수 있습니다! 클라이언트가 정해진 API 형식에 맞게 요청을 보내면 서버는 요청의 내용을 빠르게 파악하고 처리할 수 있겠죠. 처리 결과에 대한 응답 역시 정해진 형식대로 반환되니 API 문서를 통해 응답 규칙을 알고 있는 클라이언트 역시 빠르게 서버의 응답을 해석할 수 있습니다.

다양한 모습의 API

API는 누가 제공하는지에 따라 서로 다른 모습을 가지고 있습니다. 검색 서비스인 네이버의 프런트엔드와 메시지 서비스인 카카오톡의 프런트엔드가 서로 다른 것처럼, 네이버 검색 서버와 카카오톡 메시지 서버의 API 역시 서로 다릅니다. 그럼에도 불구하고 공통적으로 가지고 있는 특성에 따라 몇 가지 종류로 분류해 볼 수 있습니다. 대부분의 공공기관에서 유사한 문서 형식을 사용하고 있는 것처럼 말이죠!

기상청 시스템에서 날씨 조회용 API를 만든다고 생각해 봅시다. 기상청은 일반 사용자와 기상청 내부 날씨 분석 팀에게 날씨 정보를 제공하려고 합니다. 이때, 일반 사용자는 기온, 강수량 등의 간단한 정보만 보면 만족합니다. 하지만 날씨 분석팀은 훨씬 자세하고 복잡하고 방대한 정보를 필요로 합니다. 따라서 두 가지 버전의 API가 필요하게 됩니다.

IT 세상에서는 이렇게 누구에게 제공되는지에 따라 조금씩 다른 모습을 가지는 API의 특성을 기준으로 API의 유형을 크게 Public API, Partner API, Private API로 분류하고 있습니다.

Public API: 공개적으로 제공되는 API
Partner API: 특정 사용자에게만 제공되는 API
Private API: 회사 내부적으로 사용하는 API

어떻게 API로 요청과 응답을 주고받을까?

클라이언트와 서버가 API로 통신을 하고 있다고는 하지만, 아직 잘 와 닿지 않습니다. 보이지 않는 곳에서 일어나는 상호작용을 상상하기란 쉬운 일이 아니죠. 하지만 알고 보면 API는 그다지 대단한 모습을 가지고 있지는 않습니다. 한번 확인해 볼까요?

클라이언트가 열심히 일을 하다 보니 서버에게 부탁해야 하는 일이 생겼습니다. 그러면 클라이언트는 서버에게 API로 요청을 보냅니다. 이때, API의 규칙에 맞춰 누가 무엇을 해야 하는지를 정확히 알려줘야 합니다. 서버는 요청이 정확히 본인에게 들어오지 않으면 움직이지 않습니다. 마치 침대에 누워 뒹구는 주말 오전의 우리처럼 말이죠!

API를 통해 클라이언트의 요청을 받은 서버는 열심히 요청을 처리합니다. 상황에 따라 클라이언트의 요청은 성공적으로 처리될 수도 있고, 실패할 수도 있습니다. 결과가 어찌 되었든 시킨 일을 끝낸 서버는 그 결과를 클라이언트에게 API에 정의된 형식대로 응답합니다. 서버에게 요청의 결과물을 전달받은 클라이언트는 이를 사용해서 남은 일을 마저 처리합니다.

이처럼 클라이언트는 서버에 API 요청(API request)을 보내고, 서버는 클라이언트에게 API 응답(API response)을 반환하며 통신하고 있습니다. 클라이언트는 서버가 API로 정한 방법대로 API 요청을 보냅니다. 요청을 받은 서버는 API로 미리 정해 둔 형식에 맞춰 클라이언트에게 API 응답을 반환해 줍니다.

AI 시대의 ‘일잘러’는 단순히 AI를 잘 쓰는 사람을 넘어서, 그 뒤에서 어떤 방식으로 서비스와 기술이 움직이는지까지 이해하려는 사람입니다. API를 알게 된 지금, IT 세상이 조금은 더 또렷하게 보이기 시작하지 않으셨나요?

이 글은 길벗에서 출간된 책 <감각 있는 일잘러의 IT 지식>에서 발췌·편집한 글입니다. 원문은 [여기]에서 볼 수 있습니다.