회의 때 "그건 API로 연동하면 돼요", "저쪽에서 API를 열어줘야 해요" 같은 말이 오갑니다. 다들 고개를 끄덕이지만, 속으로 "그런데 API가 정확히 뭐지?" 싶었던 적 없으신가요? 이 글은 코드 한 줄 없이, 식당에서 밥 한 끼 주문하는 이야기로 API를 5분 만에 정리해 드립니다.

왜 요즘은 모든 게 API로 연결될까

우리가 쓰는 앱은 혼자 모든 걸 하지 않습니다. 배달 앱은 지도를 직접 만들지 않고 지도 회사의 기능을 빌려 쓰고, 쇼핑몰은 결제 시스템을 직접 만들지 않고 결제 회사의 기능을 빌려 씁니다. 이렇게 서로 다른 서비스가 서로의 기능을 빌려 쓰는 통로가 바로 API입니다.

예전에는 필요한 기능을 처음부터 다 만들어야 했습니다. 지금은 잘 만들어진 남의 기능을 API로 가져다 쓰면 되니, 서비스를 훨씬 빠르게 만들 수 있습니다. 그래서 요즘 나오는 거의 모든 앱과 웹사이트는 뒤에서 수많은 API로 연결되어 있습니다.

API를 식당 주문으로 이해하기

API는 Application Programming Interface의 줄임말입니다. 단어가 어렵게 들리지만, 가운데 있는 인터페이스(interface)라는 말만 잡으면 됩니다. 인터페이스란 서로 다른 둘이 만나 소통하는 접점을 뜻합니다. 식당으로 치면, 손님과 주방 사이에 있는 점원(카운터)이 인터페이스입니다.

식당에서 밥을 먹는 과정을 떠올려 볼까요?

정리하면, API는 내가 원하는 것을 대신 전달하고 그 결과를 받아다 주는 점원입니다. 손님은 주방에 직접 들어가지 않아도 되고, 주방이 어떻게 돌아가는지 몰라도 됩니다. 그저 점원에게 정해진 방식으로 주문(요청)하면, 원하는 결과(응답)를 받습니다. 이 "요청하고 응답받는" 한 쌍이 API의 전부라고 해도 과언이 아닙니다.

메뉴판이라는 약속

식당에는 메뉴판이 있습니다. 메뉴판에 없는 걸 주문하면 만들어 주지 않죠. API에도 이 메뉴판이 있습니다. "이런 것들은 요청할 수 있고, 이렇게 요청하면, 이런 형태로 응답해 준다"를 미리 정해 둔 약속 목록입니다.

이 약속이 중요한 이유가 있습니다. 손님과 주방이 서로의 사정을 몰라도, 메뉴판이라는 공통 약속만 지키면 거래가 성립하기 때문입니다. 그래서 개발자들이 "저쪽 API 문서 봤어?"라고 말할 때, 그 문서가 바로 이 메뉴판입니다. 무엇을 요청할 수 있고 어떤 응답이 오는지 적어 둔 설명서죠.

콘센트처럼 규격이 정해져 있다

또 하나의 비유는 벽에 있는 콘센트입니다. 우리는 선풍기든 노트북 충전기든 콘센트 모양만 맞으면 꽂아서 씁니다. 콘센트 뒤로 전기가 어떻게 오는지는 몰라도 됩니다. 규격(인터페이스)만 맞으면 되니까요.

API도 똑같습니다. 규격만 맞추면 내 서비스에 남의 기능을 "꽂아서" 쓸 수 있습니다. 상대가 그 기능을 어떻게 구현했는지는 알 필요가 없습니다. 이렇게 속은 감추고 약속된 겉면만 노출하는 것이 API의 핵심 성질입니다. 덕분에 서로 다른 회사, 서로 다른 프로그램이 레고 블록처럼 맞물려 돌아갑니다.

실제로 이런 곳에 쓰입니다

멀리 있는 이야기가 아닙니다. 여러분이 오늘 쓴 앱에도 API가 깔려 있습니다.

공통점이 보이시나요? 모두 "내 서비스가 남의 기능에 요청을 보내고, 응답을 받아 내 화면에 보여 주는" 구조입니다.

비개발자가 API를 보는 눈

개념을 잡았으니, 회의실에서 바로 써먹을 관점을 정리해 봅니다.

마무리

정리하면, API는 서로 다른 서비스가 정해진 약속(인터페이스)에 따라 요청을 주고받고 응답을 받는 창구입니다. 식당의 점원이자, 벽의 콘센트인 셈이죠. 이 개념 하나만 잡아도 "API 연동", "API 연다" 같은 말이 더 이상 낯설지 않을 것입니다. 다음에 어떤 서비스를 볼 때 "이건 무엇을 요청하면 무엇을 응답으로 줄까?"를 떠올려 보세요. 그 순간부터 여러분은 API를 아는 사람입니다.