비개발자를 위한 IT 상식 #2 API란 무엇인가 — 서비스끼리 대화하는 약속
지난 글에서 웹사이트가 프론트엔드, 백엔드, 데이터베이스라는 세 층으로 이루어지고, 이 세 층이 사용자의 행동 하나마다 끊임없이 서로 대화한다고 했습니다. 그러면서 한 가지를 다음으로 미뤄 두었습니다. 그 대화가 어떤 약속 위에서 이루어지는가, 바로 API입니다.
API는 개발자들이 하루에도 몇 번씩 쓰는 단어입니다. “그 데이터는 API로 받아와요”, “API가 안 내려와요”, “그 기능은 외부 API 연동이 필요해서 시간이 좀 걸립니다” 같은 말을 들어본 적이 있을 것입니다. 이번 글에서는 이 API가 정확히 무엇인지, 그리고 왜 요즘 서비스는 API 없이는 거의 굴러가지 않는지 살펴보겠습니다.
이번 시리즈는 비개발자를 위한 IT 상식 5편으로 구성됩니다.
- #1 웹사이트는 무엇으로 이루어지는가 — 프론트엔드,백엔드,데이터베이스
- #2 API란 무엇인가 — 서비스끼리 대화하는 약속 ← 이번 글
- #3 서버, 클라우드, 그리고 배포
- #4 버그, 핫픽스, 롤백 — 개발자가 장애에 대응하는 법
- #5 Git과 버전 관리 — 여러 명이 한 코드를 고치는 법
API는 정해진 방식으로 주고받는 약속입니다 #
지난 글에서 백엔드를 식당의 주방에 비유했습니다. 손님은 주방에 직접 들어가지 않습니다. 메뉴판을 보고, 점원에게 정해진 방식으로 주문하면, 정해진 형태로 음식이 나옵니다. 손님은 주방이 어떻게 동작하는지 몰라도 됩니다. 메뉴판과 점원이라는 정해진 창구만 거치면 원하는 것을 받을 수 있습니다.
API가 바로 이 메뉴판이자 점원입니다. “이렇게 요청하면 이런 형식으로 응답해 준다"는 약속이고, 그 약속에 따라 주고받는 창구입니다. 프론트엔드는 백엔드의 내부 사정을 몰라도, API라는 정해진 창구로 요청하면 원하는 데이터를 받을 수 있습니다.
API는 Application Programming Interface의 줄임말입니다. 단어가 어렵게 들리지만, 풀어 보면 프로그램끼리 정해진 방식으로 주고받는 창구라는 뜻입니다. 사람이 메뉴판을 통해 주방과 소통하듯, 프로그램은 API를 통해 다른 프로그램과 소통합니다.
요청과 응답으로 이루어집니다 #
API를 통한 대화는 요청과 응답이라는 두 단계로 이루어집니다.
날씨 앱을 예로 들어 보겠습니다. 앱 화면(프론트엔드)이 “서울의 지금 날씨를 알려 달라"고 백엔드에 요청합니다. 이때 요청에는 무엇을 원하는지와 함께, 필요한 정보(어느 도시인지)를 담습니다. 백엔드는 그 요청을 받아 데이터를 찾은 뒤, 약속된 형식으로 응답합니다. 예를 들어 “도시는 서울, 온도는 21도, 상태는 맑음"과 같은 형태입니다.
이때 응답이 아무 모양이나 오는 것이 아니라 미리 약속된 형식으로 온다는 점이 중요합니다. 개발에서는 주로 JSON이라는 형식을 씁니다. 사람이 봐도 “이름은 무엇, 값은 무엇” 식으로 정리된 형태라고 생각하면 됩니다. 형식이 약속돼 있기 때문에, 프론트엔드는 받은 응답에서 온도 값을 꺼내 화면에 그대로 보여 주기만 하면 됩니다.
안에서도 쓰고, 밖에서도 가져다 씁니다 #
API는 한 서비스 안에서만 쓰는 것이 아닙니다. 크게 두 가지로 나눠 볼 수 있습니다.
첫째는 내부 API입니다. 한 서비스의 프론트엔드와 백엔드가 주고받는 창구입니다. 지난 글에서 본 로그인 과정이 여기에 해당합니다.
둘째는 외부 API입니다. 다른 회사가 만들어 둔 기능을 API라는 창구로 가져다 쓰는 것입니다. 우리가 매일 쓰는 앱에는 이런 외부 API가 가득합니다. 화면에 지도를 띄우는 기능은 보통 지도 API를 붙인 것이고, 결제는 결제 대행사의 API를, 카카오나 구글로 간편하게 로그인하는 기능은 그 회사가 제공하는 로그인 API를 연동한 것입니다. 문자 발송, 환율 조회, 번역 같은 기능도 마찬가지입니다.
덕분에 모든 기능을 직접 만들 필요가 없습니다. 잘 만들어진 외부 기능을 API로 끼워 넣어 빠르게 서비스를 완성합니다. 요즘 앱은 여러 API를 조합해 만든 결과물에 가깝습니다.
왜 비개발자가 알면 일이 편해지는가 #
API를 이해하면 실무에서 개발자와의 대화가 한결 수월해집니다.
- 기능 요청의 무게를 가늠할 수 있습니다. “여기 지도를 띄워 주세요"라는 요청은 지도 API를 연동해야 하는 일이고, 그만큼 시간과 비용이 듭니다. 외부 기능을 새로 붙이는 일인지, 이미 있는 데이터를 보여 주는 일인지 구분되면 일정 감각이 생깁니다.
- 문제의 위치를 좁힐 수 있습니다. “지도가 안 떠요”, “결제가 멈췄어요” 같은 상황에서, 우리 서비스의 문제인지 연동한 외부 API의 문제인지 함께 의심해 볼 수 있습니다.
- 기획 단계에서 좋은 질문을 던질 수 있습니다. “이 기능, 제공되는 API가 있나요? 아니면 직접 만들어야 하나요?“라는 질문 하나가 일정과 비용을 크게 바꿉니다.
특히 외부 API는 대부분 사용량에 따라 요금이 매겨집니다. 사용자가 늘어 호출이 많아지면 그만큼 비용도 늘어납니다. 이 점을 알아 두면 서비스가 커질 때의 비용 구조를 미리 가늠할 수 있습니다.
API에도 규칙과 한계가 있습니다 #
API는 아무나 마음대로 쓸 수 있는 창구가 아닙니다. 몇 가지 규칙이 따라붙습니다.
먼저 인증입니다. 외부 API는 보통 API 키라는 일종의 출입증을 발급합니다. 이 키로 신원을 확인하고, 허락된 사용자만 창구를 이용하게 합니다.
다음은 호출 한도입니다. 흔히 rate limit이라고 부르는데, 일정 시간에 정해진 횟수만 요청할 수 있게 제한합니다. 이 한도를 넘으면 잠시 요청이 막힙니다. 한 서비스의 폭주가 다른 사용자까지 망가뜨리지 않게 하는 장치입니다.
마지막은 의존에 따르는 위험입니다. 외부 API에 기댄다는 것은 그 제공자의 정책에 따라간다는 뜻이기도 합니다. 제공자가 응답 형식을 바꾸거나, 요금을 올리거나, 서비스를 종료하면 그 영향을 그대로 받습니다. 편리함의 이면에는 이런 의존이 있다는 점도 함께 알아 두면 좋습니다.
정리 #
이번 글에서는 API가 무엇인지 살펴봤습니다.
- API는 프로그램끼리 정해진 방식으로 요청하고 정해진 형식으로 응답받는 약속이자 창구입니다.
- 대화는 요청과 응답으로 이루어지고, 응답은 주로 JSON처럼 약속된 형식으로 옵니다.
- 한 서비스 안을 잇는 내부 API와, 남의 기능을 가져다 쓰는 외부 API가 있습니다.
- API에는 인증, 호출 한도, 의존 위험 같은 규칙과 한계가 따라붙습니다.
지난 글에서 본 백엔드, 그리고 이번 글에서 본 API는 모두 사용자 눈에 보이지 않는 곳에서 실행됩니다. 그렇다면 이 백엔드와 API는 실제로 어디에서 실행되고 있을까요. 다음 글에서는 서버, 클라우드, 그리고 배포가 무엇인지 알아보겠습니다.