API 뜻, 식당 웨이터 비유로 끝내는 가장 쉬운 설명

 

API 뜻을 검색하면 '응용 프로그램 프로그래밍 인터페이스'라는 번역만 나오고, 몇 번을 읽어도 프로그램들이 어떻게 소통하는지 감이 잘 잡히지 않습니다. 추상적인 용어가 겹쳐 있어 데이터가 오가는 장면이 그려지지 않기 때문입니다.

이 글에서는 식당 웨이터 비유로 API의 창구 역할을 잡고, 요청·응답과 상태 코드, API 키까지 비개발자도 따라갈 수 있게 정리합니다.

목차

1. API 뜻, 한 문장으로 정리하면
2. 레스토랑 비유로 보는 API 구조
3. 요청과 응답, 웨이터가 오가는 두 번의 걸음
4. 카카오 로그인 버튼 뒤에서 벌어지는 일
5. 왜 프로그램을 쪼개기 시작했을까
6. 배달앱 하나에 API가 몇 개나 들어갈까
7. 아무나 주문할 수 없는 이유, API 키
8. 웨이터를 이해하면 디지털 세상이 보입니다

1. API 뜻, 한 문장으로 정리하면

API는 Application Programming Interface의 약자입니다. 우리말로 옮기면 '응용 프로그램 프로그래밍 인터페이스'인데, 솔직히 번역이 더 어렵습니다.

한 문장으로 바꿔 보겠습니다. API는 프로그램끼리 서로 기능과 데이터를 주고받을 때 지키기로 한 약속, 그리고 그 약속대로 심부름을 해 주는 창구입니다. 사람과 사람이 대화할 때 언어라는 약속이 필요하듯, 프로그램과 프로그램이 대화하려면 API라는 약속이 필요합니다.

📌 핵심만 기억한다면 API = 프로그램 사이의 주문 창구. "이렇게 요청하면, 이렇게 답해 줄게"라는 규칙이 미리 정해져 있어서, 상대 프로그램의 내부를 몰라도 기능을 빌려 쓸 수 있습니다.

정의만 봐서는 아직 손에 잡히지 않을 겁니다. 이제 레스토랑으로 가 보겠습니다.

2. 레스토랑 비유로 보는 API 구조

레스토랑에 갔다고 상상해 보세요. 스테이크가 먹고 싶다고 해서 주방에 직접 들어가 냉장고를 열지는 않습니다. 주방은 위험하고, 복잡하고, 셰프만의 규칙이 있는 공간이니까요. 손님이 하는 일은 자리에 앉아 웨이터를 부르는 것뿐입니다.

프로그램 세계도 똑같습니다. 내 앱이 카카오의 회원 정보가 필요하다고 해서 카카오 서버에 직접 들어갈 수는 없습니다. 대신 카카오가 세워 둔 웨이터, 즉 API에게 정해진 방식으로 주문을 넣습니다.

손님은 클라이언트, 주방은 서버

비유 속 등장인물을 기술 용어와 짝지어 보면 구조가 선명해집니다.

반응형

레스토랑	프로그램 세계	하는 일
손님	클라이언트(Client)	필요한 것을 요청하는 쪽. 우리가 쓰는 앱이나 웹사이트
주방	서버(Server)	데이터와 기능을 실제로 갖고 있는 쪽
웨이터	API	주문을 전달하고 결과를 가져오는 중간 창구
메뉴판	API 문서	어떤 주문이 가능한지, 어떻게 주문해야 하는지 적힌 안내서

웨이터가 없는 식당을 떠올려 보면 API의 역할이 분명해집니다. 손님은 주방장을 찾아 헤매고, 주방은 주문이 뒤엉켜 멈춰 버리겠죠. 요청하는 쪽과 가진 쪽이 직접 부딪히지 않게 하는 것, 그게 이 웨이터의 존재 이유입니다.

메뉴판이 곧 인터페이스입니다

주문할 때 우리는 "고기를 200도에서 5분 굽고 소금을 3g 뿌려 주세요"라고 말하지 않습니다. 메뉴판을 보고 "A세트 주세요" 한마디면 끝입니다. 요리법을 몰라도 주문할 수 있는 이유는 메뉴판이라는 약속이 있기 때문입니다.

API 문서가 정확히 이 메뉴판입니다. 개발자는 카카오 서버 내부가 어떻게 돌아가는지 알 필요가 없습니다. 카카오가 공개한 문서에서 '로그인 정보 요청'이라는 메뉴를 골라 정해진 형식대로 주문하면, 정해진 형식의 답이 돌아옵니다.

여기서 재미있는 점이 하나 있습니다. 주방장이 요리법을 통째로 바꿔도, 메뉴 이름과 맛이 그대로라면 손님은 아무것도 눈치채지 못합니다. 프로그램도 마찬가지라서, 서버 내부를 뜯어고쳐도 API라는 창구의 약속만 유지되면 이용하는 쪽은 코드를 한 줄도 고칠 필요가 없습니다. 이 성질 덕분에 서로 다른 회사의 프로그램들이 안심하고 손을 잡을 수 있는 겁니다.

3. 요청과 응답, 웨이터가 오가는 두 번의 걸음

웨이터의 동선은 딱 두 걸음입니다. 주문을 받아 주방에 전달하는 걸음, 그리고 완성된 요리를 받아 식탁에 내려놓는 걸음. 이 두 걸음을 프로그램 세계에서는 요청(Request)과 응답(Response)이라고 부릅니다.

실제 주문서에는 생각보다 많은 정보가 적힙니다.

• 어느 창구로 갈지 - 주소(URL). "3번 테이블 담당 웨이터"를 지정하는 것과 같습니다
• 무엇을 원하는지 - 조회인지, 새로 등록인지, 수정인지 같은 요청의 종류
• 세부 조건 - "스테이크는 미디엄으로" 같은 구체적인 요구 사항

응답도 그냥 요리만 돌아오는 게 아닙니다. 주문이 잘 처리됐는지 알려주는 신호가 함께 옵니다. 웹 서핑을 하다 한 번쯤 만나 본 '404 Not Found'가 바로 이 신호 중 하나입니다. 웨이터가 "손님, 그 메뉴는 저희 가게에 없습니다"라고 답한 셈이죠. 200번대는 성공, 400번대는 주문한 쪽의 실수, 500번대는 주방 쪽 사고라는 식으로 번호 대역마다 의미가 정해져 있습니다.

💡 REST API라는 말을 들어 보셨다면 개발자들이 자주 쓰는 'REST API'는 이 주문서를 쓰는 방식 중 가장 널리 퍼진 표준 양식이라고 이해하시면 됩니다. 주문서 양식이 통일돼 있으니 처음 가는 식당에서도 헤매지 않고 주문할 수 있는 것과 같습니다.

실제 API에 주문서를 넣어 보면

요청과 응답이 추상적으로 느껴질 수 있어, 공개 GitHub API에 curl로 주문을 두 번 넣어 보았습니다(실측 2026-10-19 KST).

메뉴판에 있는 저장소를 주문한 경우입니다.

curl -sS -D - -o body.json \
  -H 'Accept: application/vnd.github+json' \
  -H 'User-Agent: devwar-lab' \
  https://api.github.com/repos/torvalds/linux

HTTP/2 200
content-type: application/json; charset=utf-8
content-length: 5487
...

본문 JSON에는 "full_name": "torvalds/linux"가 포함되어 있었습니다. 웨이터가 "주문 성공(200)"과 함께 요리를 내려준 셈입니다.

없는 메뉴를 주문하면 이렇게 답합니다.

curl -sS -D - -o body404.json \
  -H 'Accept: application/vnd.github+json' \
  -H 'User-Agent: devwar-lab' \
  https://api.github.com/repos/torvalds/this-repo-does-not-exist-xyz

HTTP/2 404
content-type: application/json; charset=utf-8
content-length: 132

{"message":"Not Found",...}

404는 "그 메뉴는 없습니다"라는 신호입니다. CSRF·쿠키 인증이 궁금하면 CSRF 정리를, 브라우저가 다른 출처 응답을 막는 규칙은 CORS 설명을 보면 이어집니다.

4. 카카오 로그인 버튼 뒤에서 벌어지는 일

이제 도입부의 질문으로 돌아가 보겠습니다. 새 쇼핑몰에서 '카카오로 3초 만에 시작하기'를 누르면, 쇼핑몰은 어떻게 내 닉네임을 아는 걸까요. 쇼핑몰 개발자가 카카오 서버실에 몰래 들어간 것은 당연히 아닙니다.

버튼을 누르는 순간 벌어지는 일을 순서대로 풀면 이렇습니다.

• 쇼핑몰이 카카오 API에 "이 사용자의 로그인 확인을 부탁합니다"라고 요청을 보냅니다
• 카카오가 사용자 본인에게 직접 묻습니다. "이 쇼핑몰에 닉네임과 이메일을 알려줘도 될까요?"
• 사용자가 동의하면, 카카오는 허락된 범위의 정보만 담아 쇼핑몰에 응답합니다

중요한 건 쇼핑몰이 내 카카오 비밀번호를 끝까지 모른다는 점입니다. 웨이터가 주방 금고 열쇠를 손님에게 넘기지 않듯, API는 딱 허락된 접시만 내어 줍니다. 동의 화면에서 "닉네임, 프로필 사진 제공"이라고 항목이 뜨는 게 바로 그 접시의 목록입니다.

5. 왜 프로그램을 쪼개기 시작했을까

API가 지금처럼 중요해진 배경에는 개발 방식의 큰 흐름 변화가 있습니다. 예전에는 하나의 프로그램이 모든 걸 다 했고, 지금은 여러 프로그램이 나눠 맡습니다.

모놀리식, 사장님 혼자 다 하던 시절

과거에는 프로그램을 하나의 거대한 덩어리로 만들었습니다. 이런 구조를 모놀리식(Monolithic)이라고 부릅니다. 은행 시스템이라면 로그인, 계좌 조회, 이체, 상담 기능이 전부 한 몸에 붙어 있는 식이죠.

작은 식당을 사장님 혼자 운영하는 모습과 비슷합니다. 요리도 하고, 서빙도 하고, 계산도 합니다. 가게가 작을 땐 오히려 단순하고 효율적입니다. 문제는 손님이 늘었을 때입니다. 이체 기능 하나 고치려는데 시스템 전체를 멈춰야 하고, 작은 실수 하나가 로그인부터 상담까지 모든 기능을 마비시킵니다. 몸집이 커질수록 이 방식은 감당이 안 됩니다.

API 연결로 분업하는 지금

그래서 개발자들은 프로그램을 기능별 부품으로 나누기 시작했습니다. 결제는 결제 전문 프로그램이, 지도는 지도 전문 프로그램이 맡고, 서로 필요한 것은 API로 주고받자는 방향입니다. 이렇게 잘게 나눈 구조를 마이크로서비스(Microservices)라고 부릅니다.

이 변화가 가져온 효과는 생각보다 큽니다. 지도 기능이 필요한 회사가 지도를 밑바닥부터 만들 필요 없이, 네이버나 카카오가 이미 잘 만들어 둔 지도를 API로 빌려 쓰면 됩니다. 각자 잘하는 것에 집중하고 나머지는 연결로 해결하는 것. 혼자 다 만들던 시대에서 빌리고 연결하는 시대로 넘어온 겁니다.

6. 배달앱 하나에 API가 몇 개나 들어갈까

점심에 배달앱으로 음식을 시키면 배달원의 위치가 지도 위에서 실시간으로 움직입니다. 사용자 눈에는 매끄러운 앱 하나로 보이지만, 뒤에서는 여러 회사의 서버가 API로 쉴 새 없이 대화하고 있습니다.

• 지도 API - 배경 지도와 길 찾기는 지도 회사가 제공합니다
• 위치 API - GPS 좌표를 받아 배달원의 점을 찍습니다
• 결제 API - 카드 승인은 결제 대행사(PG사)가 처리합니다
• 알림 API - "배달이 시작되었습니다" 메시지는 메시징 서비스가 보냅니다

배달 회사가 직접 만든 것은 이 재료들을 엮는 부분과 자기들만의 핵심 데이터뿐입니다. 이렇게 남의 서비스를 조합해 새 서비스를 만드는 방식을 매시업(Mashup)이라고 부르는데, 스타트업이 큰 자본 없이도 빠르게 서비스를 내놓을 수 있는 비결이 여기에 있습니다. 대기업이 수년간 쌓은 인프라를 주문 몇 줄로 빌려 쓸 수 있으니까요.

배달앱 뒤의 API와 멱등성

배달·결제처럼 같은 주문이 두 번 들어가면 안 되는 API는 "같은 요청인지"를 알아보는 꼬리표가 필요합니다. 결제 중복을 막는 실무 패턴은 API 멱등성 글에서 이어집니다.

7. 아무나 주문할 수 없는 이유, API 키

여기까지 읽으면 이런 의문이 들 수 있습니다. 그럼 아무나 카카오 API에 주문을 넣을 수 있는 건가? 그렇지는 않습니다.

대부분의 API는 회원제 레스토랑처럼 운영됩니다. 입장하려면 멤버십 카드가 필요한데, 이 카드가 바로 API 키(Key)입니다. 어느 서비스가 주문했는지 식별하는 고유 번호죠. 키가 있어야 주문을 받아 주고, 키별로 하루에 몇 번까지 주문할 수 있는지 횟수 제한을 두기도 합니다. 무료 손님에게는 하루 1만 번, 유료 손님에게는 무제한, 이런 식입니다.

이 구조 덕분에 API 제공사는 누가 얼마나 쓰는지 관리할 수 있고, 이상한 주문을 쏟아내는 손님을 차단할 수도 있습니다. 개발 뉴스에서 가끔 보이는 "API 키 유출 사고"가 왜 문제인지도 여기서 답이 나옵니다. 남의 멤버십 카드를 주운 사람이 그 사람 이름으로 마음껏 주문을 넣는 상황이 되기 때문입니다.

📌 뉴스 속 API 이해하기 "OO사가 API를 유료화했다"는 뉴스는 "회원제 식당이 멤버십 요금을 올렸다"는 뜻입니다. 그 API에 기대어 서비스를 만들던 회사들이 술렁이는 이유가 이제 보이실 겁니다.

API 키는 멤버십 카드

공개 조회와 달리, 쓰기·높은 한도가 필요한 창구는 API 키로 손님을 가릅니다. 키가 유출되면 남의 이름으로 주문이 나가는 것과 같아서, 저장소·로그·프론트 코드에 키를 박아 두지 않는 것이 기본입니다.

8. 웨이터를 이해하면 디지털 세상이 보입니다

API는 프로그램과 프로그램 사이에서 주문을 전달하는 웨이터입니다. 메뉴판(문서)이 있어 내부 요리법을 몰라도 주문할 수 있고, 요청과 응답이라는 두 걸음으로 움직이며, 멤버십 카드(키)로 손님을 가려 받습니다. 그리고 이 웨이터 덕분에 혼자 다 만들던 프로그램들이 서로의 기능을 빌려 쓰는 연결의 시대가 열렸습니다.

스마트폰에서 버튼 하나를 누를 때마다 여러 회사의 서버 사이를 웨이터들이 바쁘게 오가고 있다는 것. 개인적으로는 이 그림 하나만 머리에 남아도 API 뜻은 충분히 이해하신 거라고 생각합니다. 카카오 로그인, 배달앱 지도, 결제 승인이 전부 같은 원리 위에서 돌아가고 있으니까요.

API에 대해 자주 묻는 질문

API와 프로그램은 다른 건가요?

API는 프로그램 그 자체라기보다 프로그램이 외부에 열어 둔 창구입니다. 레스토랑(프로그램)과 웨이터(API)의 관계로 보시면 됩니다. 하나의 프로그램이 여러 개의 API 창구를 열어 둘 수도 있습니다.

API는 전부 인터넷을 통해 작동하나요?

꼭 그렇지는 않습니다. 이 글에서 다룬 것은 인터넷으로 통신하는 웹 API지만, 운영체제가 프로그램에게 제공하는 API처럼 한 컴퓨터 안에서만 작동하는 API도 있습니다. 다만 일상에서 'API 연동'이라고 하면 대부분 웹 API를 가리킵니다.

API를 쓰면 무조건 돈을 내야 하나요?

서비스마다 다릅니다. 일정 사용량까지는 무료로 열어 두고 그 이상부터 과금하는 방식이 흔한 편입니다. 지도, 로그인처럼 자사 생태계를 넓히는 API는 무료 구간이 넉넉하고, 데이터 자체가 상품인 API는 처음부터 유료인 경우가 많습니다.

비개발자도 API를 알아야 하나요?

코드를 쓸 일이 없어도, 서비스 기획이나 협업에서 "이건 API로 되나요?"라는 질문 하나가 대화를 크게 줄여 줍니다. 우리 회사가 직접 만들 부분과 빌려 올 부분을 구분하는 감각은 직군과 상관없이 쓸모가 있습니다.

📚 함께 보면 좋은 글

CSRF란? 개념부터 방어까지 쉽게 정리

CORS는 왜 항상 프론트 개발자만 잡을까 - 동일 출처 정책의 역사와 현장 이야기

API 멱등성이란? 결제 중복 요청 막는 실무 방법, 버튼 비활성화로는 못 막습니다

웹 API 서버 디도스 방어에 스로틀링 기술이 필수인 숨은 이유가 있습니다

2차 도메인 뜻, 서브도메인과 SLD 헷갈리는 이유