어떻게 앱끼리 대화하는 창구, API

사람용 화면과 앱용 창구

앞 레슨에서 브라우저가 요청을 보내면 서버가 응답을 돌려준다는 것을 보았다. 사람이 받는 응답은 대개 웹 페이지다. 글자와 그림과 버튼이 보기 좋게 놓여 있다.
사람 눈에는 편하지만, 앱이 그 안에서 기온 하나를 찾아내려면 화면을 일일이 뜯어봐야 해요. 그래서 프로그램끼리는 화면 대신 곧장 쓸 수 있는 데이터를 주고받는다. 이 일을 위해 정해 둔 창구를 API라고 부른다.

사람용 화면과 앱용 창구를 눌러 비교해 보자. 어느 쪽이 앱이 쓰기에 편할까요?

같은 정보라도 모습이 다르다. 사람에게는 보기 좋게 꾸민 화면을 주고, 앱에게는 군더더기 없는 데이터를 준다. 화면은 사람이 읽으라고 만든 것이고, 창구는 프로그램이 읽으라고 만든 것이에요.
그렇다면 앱은 이 창구에 어떻게 말을 걸까? 사실 많은 API는 앞에서 배운 HTTP를 그대로 쓴다. 정해진 주소로 요청을 보내고 응답을 받는 것이다. 다만 요청에 무엇을 담아야 하는지는 창구마다 미리 정해져 있다.

정해진 형식으로 요청한다

창구에는 아무렇게나 말을 걸 수 없다. 미리 정해 둔 형식대로 물어야 한다. 예를 들면 '도시는 서울, 알고 싶은 것은 오늘 날씨' 하고 정해진 항목을 채워 보내는 식이다.
식당에서 메뉴판을 보고 적힌 이름 그대로 주문하는 것과 비슷해요. 주문이 약속된 말이면 주방은 헷갈리지 않고 바로 요리를 시작한다. API도 약속된 형식의 요청만 알아듣고, 형식에 맞지 않는 요청에는 잘못되었다는 답을 돌려준다.

약속된 요청을 눌러 API에 보내 보자. 정해진 형식이라 창구가 바로 알아들어요.

요청을 보냈으니 이제 답이 올 차례다. 사람에게 보내는 화면 대신 API는 무엇으로 답할까?
답은 앱이 곧장 쓸 수 있도록 깔끔하게 정리된 데이터로 온다. 꾸밈도 그림도 없이 필요한 값만 담겨 있어서 크기도 작아요. 그 데이터가 어떻게 생겼는지 다음 단계에서 펼쳐 보자.

그림이 아니라 데이터로 답한다

API의 답은 그림이 아니다. 이름과 값이 짝을 지어 적힌 데이터다. 예를 들어 온도는 23, 하늘은 맑음처럼 쓴다. 값마다 이름이 붙어 있어서 그 값이 무엇인지 분명해요.
이렇게 이름과 값을 짝지어 적는 형식으로 가장 널리 쓰이는 것이 JSON이다. 사람도 읽을 수 있을 만큼 단순하면서, 프로그램이 다루기에도 편하다. 앱은 이 데이터에서 필요한 값만 골라 자기 화면에 그린다.

데이터를 눌러 펼쳐 보자. 그림이 아니라 이름과 값(온도 23, 맑음)으로 깔끔하게 답해요.

값마다 이름이 붙어 있으니 앱은 헷갈리지 않는다. 온도가 필요하면 온도를, 하늘 상태가 필요하면 하늘 상태를 꺼내 쓰면 된다. 화면에서 숫자를 찾아내야 했다면 페이지 모양이 조금만 바뀌어도 앱이 틀린 값을 읽었을 거예요.
그런데 이런 창구는 하나만 있는 것이 아니다. 지도 창구, 날씨 창구, 결제 창구처럼 세상에는 수많은 API가 열려 있다. 둘 이상을 함께 쓰면 무엇을 만들 수 있을까?

창구를 엮어 새 서비스를 만든다

창구 하나하나는 한 가지 일만 한다. 지도 창구는 위치와 지도를 알려 주고, 날씨 창구는 날씨를 알려 준다.
그런데 둘을 엮으면 지도 위에 그 자리의 날씨를 띄우는 새 서비스가 생겨요. 블록을 끼워 맞추듯 여러 창구를 모아 더 큰 것을 만드는 것이다. 우리가 매일 쓰는 앱 가운데 상당수가 이렇게 여러 회사의 창구를 엮어 만들어져요.

지도 API와 날씨 API를 차례로 눌러 엮어 보자. 둘을 합치면 지도 위에 날씨가 뜨는 새 서비스가 돼요.

두 창구의 데이터가 만나자 혼자서는 못 하던 일이 생겼다. 지도도 날씨도 처음부터 만들지 않고, 이미 있는 창구를 빌려 합쳤을 뿐이다.
그래서 새 서비스를 빠르게 만들 수 있어요. 바퀴를 다시 깎는 대신 잘 만든 부품을 가져다 쓰는 셈이다. 창구를 연 쪽은 누가 얼마나 쓰는지 알아야 하므로, 많은 API는 요청에 열쇠처럼 쓰는 고유한 문자열을 함께 보내라고 요구한다.

정리

한 줄로 모으면 이렇다. 사람은 화면을 보지만 프로그램끼리는 데이터를 주고받고, 그 약속된 창구가 API다.
정해진 형식으로 요청하면 그림이 아니라 이름과 값으로 된 데이터로 답해요. 여러 창구를 엮으면 새 서비스가 돼요. 그래서 모든 것을 처음부터 만들지 않고, 이미 있는 창구를 빌려 새것을 만들 수 있다.

핵심을 차례로 눌러 되짚어 보자. (앱용 창구 → 정해진 형식으로 요청 → 데이터로 답 → 조합해 새 서비스)

이제 앱들이 어떻게 서로 데이터를 주고받는지 알았다. 눈에 보이는 앱 하나 뒤에서는 수많은 창구가 조용히 일하고 있다. 다음에 날씨 앱을 열 때 이 화면이 어느 창구에서 어떤 데이터를 받아 왔을지 생각해 보면 재미있어요.
그런데 HTTP는 지난 요청을 기억하지 않는다고 했다. 그렇다면 쇼핑몰은 로그인한 나를 페이지마다 어떻게 알아볼까? 다음 레슨에서는 그 답인 세션과 쿠키를 다룬다.