API 완벽 가이드: 식당 웨이터로 이해하는 API
API란 무엇인가?
API는 Application Programming Interface의 약자입니다. 한국어로 풀면 "프로그램과 프로그램이 대화하는 방법"이에요!
이 어려운 영어 단어를 하나씩 쉽게 풀어볼까요?
- Application(애플리케이션) = 프로그램, 앱 (카카오톡, 네이버 같은 것)
- Programming(프로그래밍) = 컴퓨터에게 일을 시키는 것
- Interface(인터페이스) = 서로 연결해주는 통로
즉, API는 프로그램과 프로그램 사이에서 정보를 주고받을 수 있게 해주는 약속된 통로예요!
💡 한 줄 요약: API = 프로그램들이 서로 대화하는 방법!
식당 비유로 이해하기
🍽️ 식당에서 밥을 먹는 과정을 떠올려보세요!
여러분이 식당에 갔다고 상상해보세요. 식당에는 세 가지 중요한 존재가 있어요:
- 손님 (나) = 음식을 주문하는 사람
- 웨이터 = 주문을 받아서 주방에 전달하고, 음식을 가져다주는 사람
- 주방 (셰프) = 실제로 음식을 만드는 곳
여기서 웨이터가 바로 API예요!
손님인 우리는 주방에 직접 들어가서 요리할 필요가 없어요. 메뉴판을 보고 웨이터에게 "비빔밥 하나 주세요!"라고 말하면, 웨이터가 주방에 전달하고, 맛있는 비빔밥이 나오죠!
🍳 비유 정리:
손님(앱/사용자) → 웨이터(API) → 주방(서버/시스템)
메뉴판 = API 문서 | 주문 = 요청(Request) | 음식 = 응답(Response)
🤔 만약 웨이터(API)가 없다면?
웨이터 없이 식당이 운영된다고 상상해보세요:
- 손님이 직접 주방에 들어가야 해요 (위험하고 복잡해요!)
- 어떤 재료가 있는지, 어떻게 요리하는지 알아야 해요
- 주방이 너무 복잡해서 원하는 음식을 만들기 어려워요
- 다른 손님들과 부딪힐 수도 있어요
API가 있으면? 그냥 메뉴판 보고 주문만 하면 돼요! 간단하죠? 😊
일상 속 API
우리가 매일 쓰는 앱들도 사실 API를 통해 작동하고 있어요! 몰랐죠?
📱 날씨 앱
날씨 앱이 직접 하늘을 보고 날씨를 판단하는 걸까요? 아니에요!
날씨 앱(손님) → 기상청 API(웨이터) → 기상청 서버(주방)
기상청이 가진 날씨 데이터를 API를 통해 가져와서 예쁘게 보여주는 거예요!
💬 카카오톡 로그인
다른 앱에서 "카카오로 로그인" 버튼을 누르면:
쇼핑몰 앱(손님) → 카카오 로그인 API(웨이터) → 카카오 서버(주방)
쇼핑몰이 직접 비밀번호를 관리하지 않아도, 카카오가 "이 사람 맞아요!"라고 알려주는 거예요.
🗺️ 지도 서비스
배달 앱에서 보이는 지도는 배달 앱이 직접 만든 게 아니에요!
배달 앱(손님) → 네이버/구글 지도 API(웨이터) → 지도 서버(주방)
지도 전문가가 만든 지도를 API로 가져다 쓰는 거예요.
💳 결제 시스템
온라인에서 물건을 살 때 카드 결제도 API로 작동해요!
쇼핑몰(손님) → 결제 API(웨이터) → 카드사 서버(주방)
쇼핑몰이 직접 카드 결제를 처리하지 않고, 전문 결제 회사의 API를 이용하는 거예요.
API 작동 원리
📝 식당 주문 과정 = API 통신 과정
식당에서 음식을 주문하는 과정을 API와 비교해볼까요?
| 식당 | API | 설명 |
|---|---|---|
| 메뉴판을 봄 | API 문서 확인 | 어떤 기능을 쓸 수 있는지 확인 |
| 주문서 작성 | 요청(Request) 생성 | 원하는 것을 정해진 양식으로 작성 |
| 웨이터에게 전달 | API 호출 | 서버에 요청을 보냄 |
| 주방에서 조리 | 서버에서 처리 | 요청받은 작업을 수행 |
| 음식 서빙 | 응답(Response) 반환 | 결과를 돌려받음 |
🎬 HTTP 메서드 = 식당에서 하는 행동들
식당에서 우리가 하는 다양한 행동들, API에서도 비슷한 "행동"이 있어요. 이걸 HTTP 메서드라고 부릅니다:
| HTTP 메서드 | 식당 비유 | 의미 | 예시 |
|---|---|---|---|
| GET | "메뉴판 보여주세요" | 정보 조회 (가져오기) | 사용자 정보 조회 |
| POST | "비빔밥 하나 주문할게요" | 새로운 것 생성 (주문하기) | 새 게시글 작성 |
| PUT | "아, 비빔밥 말고 불고기로 변경해주세요" | 기존 것 수정 (변경하기) | 프로필 정보 수정 |
| DELETE | "주문 취소할게요" | 삭제 (취소하기) | 게시글 삭제 |
📊 상태 코드 = 웨이터의 대답
웨이터가 주문을 받으면 다양한 대답을 하죠? API도 마찬가지예요!
| 상태 코드 | 웨이터의 대답 | 의미 |
|---|---|---|
| 200 | "네, 주문 완료! 음식 나왔습니다~" | 성공! |
| 201 | "새 메뉴 등록 완료했어요!" | 새로 만들기 성공! |
| 400 | "죄송한데, 주문서를 잘못 쓰셨어요" | 잘못된 요청 |
| 401 | "손님, 회원 전용 메뉴인데 회원증 보여주세요" | 인증 필요 |
| 404 | "그 메뉴는 저희 식당에 없어요" | 찾을 수 없음 |
| 500 | "죄송합니다, 주방에서 사고가 났어요..." | 서버 오류 |
API가 중요한 이유
🧩 레고 블록처럼 조립할 수 있어요!
API가 있으면, 모든 것을 처음부터 만들 필요가 없어요. 마치 레고 블록처럼 필요한 기능을 조립하면 되거든요!
- 편리함: 지도가 필요하면? 네이버 지도 API를 가져다 쓰면 끝! 직접 지도를 그릴 필요 없어요.
- 보안: 손님이 주방에 들어가지 않듯이, API를 쓰면 서버 내부를 직접 볼 수 없어서 안전해요.
- 표준화: 메뉴판에 정해진 양식이 있듯이, API도 정해진 규칙이 있어서 누구나 쉽게 사용할 수 있어요.
- 확장성: 새로운 기능이 필요하면 새 API를 연결하기만 하면 돼요. 레고에 새 블록 끼우는 것처럼요!
🧩 비유: API는 레고 블록! 날씨 블록 + 지도 블록 + 결제 블록 = 배달 앱 완성!
REST API 기초
API 중에서 가장 많이 사용하는 방식이 REST API예요. REST는 식당의 "운영 규칙"과 같아요!
🏠 URL = 식당 주소 + 메뉴 카테고리
식당에도 주소가 있듯이, API에도 주소가 있어요. 이걸 URL(엔드포인트)이라고 해요:
https://api.restaurant.com/menu → 전체 메뉴 보기
https://api.restaurant.com/menu/bibimbap → 비빔밥 정보 보기
https://api.restaurant.com/orders → 주문 목록 보기
https://api.restaurant.com/orders/123 → 123번 주문 상세 보기
📋 JSON = 주문서 양식
식당에서 주문서를 쓰듯이, API에서는 JSON이라는 양식으로 데이터를 주고받아요. JSON은 사람도 읽을 수 있고 컴퓨터도 읽을 수 있는 양식이에요!
식당 주문서 (사람 버전):
이름: 홍길동
메뉴: 비빔밥
수량: 2
특별 요청: 계란 추가
API 주문서 (JSON 버전):
{
"name": "홍길동",
"menu": "비빔밥",
"quantity": 2,
"special_request": "계란 추가"
}
비슷하죠? JSON은 중괄호 { } 안에 "항목": "값" 형태로 정보를 담는 거예요!
🔑 API Key = 회원증
어떤 식당은 회원만 이용할 수 있죠? API도 마찬가지예요. API Key는 "나는 허가받은 사용자예요!"라고 증명하는 회원증이에요.
API Key가 필요한 이유:
- 아무나 함부로 사용하지 못하게 하려고
- 누가 얼마나 사용했는지 추적하려고
- 나쁜 의도로 사용하는 사람을 막으려고
핵심 용어 정리
| 용어 | 식당 비유 | 실제 의미 |
|---|---|---|
| API | 웨이터 | 프로그램 간 소통 통로 |
| 엔드포인트(Endpoint) | 식당 주소 + 메뉴 카테고리 | API를 호출하는 URL 주소 |
| 요청(Request) | 주문서 | 서버에 보내는 메시지 |
| 응답(Response) | 나온 음식 | 서버가 돌려주는 결과 |
| HTTP 메서드 | 식당에서 하는 행동 | GET(조회), POST(생성), PUT(수정), DELETE(삭제) |
| JSON | 주문서 양식 | 데이터를 주고받는 표준 형식 |
| API Key | 회원증 | 인증을 위한 고유 키 |
| 상태 코드 | 웨이터의 대답 | 요청 결과를 알려주는 숫자 (200, 404 등) |
| REST API | 식당 운영 규칙 | API를 설계하는 가장 일반적인 방식 |
| 서버(Server) | 주방 | 요청을 처리하는 컴퓨터 |
| 클라이언트(Client) | 손님 | 요청을 보내는 쪽 (앱, 웹브라우저) |
실전 시나리오: 배달 앱의 비밀
우리가 매일 쓰는 배달 앱이 어떻게 작동하는지 API 관점에서 살펴볼까요?
📱 1단계: 앱을 열고 로그인
배달 앱을 열고 "카카오로 로그인" 버튼을 누르면:
배달 앱 → [카카오 로그인 API 호출] → 카카오 서버
← [사용자 정보 응답] ←
"이 사람은 홍길동이고, 인증된 사용자입니다!" (상태 코드: 200)
🏪 2단계: 주변 식당 찾기
내 위치 주변 식당을 보여주려면:
배달 앱 → [지도 API 호출: 내 위치 전송] → 지도 서버
← [주변 식당 목록 응답] ←
배달 앱 → [식당 API 호출: GET /restaurants?location=강남] → 배달 서버
← [식당 목록 + 메뉴 + 리뷰 응답] ←
🍕 3단계: 음식 주문
"피자 주문하기" 버튼을 누르면:
배달 앱 → [주문 API 호출: POST /orders] → 배달 서버
보내는 데이터 (JSON):
{
"restaurant_id": 42,
"menu": "페페로니 피자",
"quantity": 1,
"address": "서울시 강남구..."
}
← [주문 완료 응답: 주문번호 #9876] ← (상태 코드: 201)
💳 4단계: 결제
배달 앱 → [결제 API 호출] → 카드사 서버
← [결제 성공 응답] ← (상태 코드: 200)
🛵 5단계: 배달 추적
배달 앱 → [배달 API 호출: GET /delivery/9876/status] → 배달 서버
← [현재 상태: "배달원이 픽업했습니다"] ←
(30초마다 반복 호출해서 실시간 추적!)
🚀 놀랍지 않나요? 배달 앱 하나에 로그인 API, 지도 API, 주문 API, 결제 API, 배달 추적 API... 최소 5개 이상의 API가 함께 일하고 있어요!
API 흐름 한눈에 보기
👤 클라이언트 (손님) 🔌 API (웨이터) 🖥️ 서버 (주방)
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ │ 요청 │ │ 전달 │ │
│ 앱/웹사이트 │ ──────────→ │ API 통로 │ ──────────→ │ 데이터 처리 │
│ │ │ │ │ │
│ │ 응답 │ │ 결과 │ │
│ │ ←────────── │ │ ←────────── │ │
└──────────────┘ └──────────────┘ └──────────────┘
📋 메뉴판 = API 문서 📝 주문서 = 요청(Request) 🍽️ 음식 = 응답(Response)
요약
API는 프로그램과 프로그램이 서로 대화하는 방법이에요!
- API = 식당의 웨이터 → 손님(앱)과 주방(서버) 사이에서 주문을 전달
- 요청(Request) → "비빔밥 주세요!" (GET, POST, PUT, DELETE)
- 응답(Response) → "네, 여기 비빔밥이요!" (200, 404, 500)
- JSON → 주문서 양식 (정보를 담는 규칙)
- API Key → 회원증 (인증)
우리가 매일 쓰는 앱 뒤에는 수많은 API가 열심히 일하고 있어요. 날씨를 알려주고, 지도를 보여주고, 결제를 처리하고, 메시지를 보내주는 게 전부 API 덕분이에요!
🎯 핵심 요약: API = 웨이터! 손님(앱)이 주방(서버)에 직접 갈 필요 없이, 웨이터(API)에게 주문(요청)하면 음식(응답)이 나온다!
🎉 수고하셨습니다!
이제 API가 무엇인지 알게 되었어요!