API 연동
API는 프론트엔드와 백엔드 사이의 '주문 카운터'로, 둘이 어떻게 소통할지 정합니다.
한 문장으로
API는 시스템끼리 대화하는 '약속된 창구'예요. 어떻게 묻고, 어떤 답을 받는지를 정합니다.
쉽게 말하면
API(Application Programming Interface, 애플리케이션 프로그래밍 인터페이스) 란 두 시스템 사이에서 '약속된 소통 방식'이에요. 데이터를 원하는 프론트엔드는 백엔드의 주방에 무작정 들이닥칠 수 없어요. API라는 카운터를 거칩니다. 약속된 형식으로 요청을 보내면, 백엔드가 약속된 형식으로 답해 주죠.
좋은 API에는 명확한 계약이 있어요. 요청에 무엇을 담아야 하는지, 응답은 어떤 모양인지, 오류일 때 어떤 코드를 돌려주는지죠. 계약이 명확하면 프론트엔드와 백엔드를 각자 독립적으로 개발할 수 있고, AI에게 올바른 연동 코드를 생성하게 하기도 한결 쉬워져요.
아키텍처
동작 흐름
좋은 계약과 나쁜 계약
어떤 API가 연동하기 즐거운지, 골칫거리인지의 차이는 결국 계약으로 귀결돼요.
- 좋은 계약은 명확하고(요청과 응답의 모양이 분명히 적혀 있음), 안정적이며(당신 모르게 슬그머니 바뀌지 않음), 문서가 있고(각 필드가 무슨 뜻인지 찾아볼 수 있음), 버전이 있어요(새 버전은
/v2/로 내고, 옛/v1/은 그대로 동작함). - 나쁜 계약은 아무런 예고 없이 바뀌어 그것에 의존하는 모든 것을 망가뜨리고, 날것의 데이터베이스 컬럼이나 스택 트레이스 같은 내부 세부까지 흘리며, 문서가 없어서 거듭 시행착오로 동작을 더듬어 알아낼 수밖에 없어요.
흔한 오해: API가 곧 백엔드라는 생각이에요. API는 약속된 인터페이스(계약)이고, 백엔드는 그 뒤의 구현이에요. 계약만 그대로 유지되면 백엔드는 다시 써도 돼요 — 언어를 바꾸든 데이터베이스를 바꾸든, 프론트엔드는 전혀 눈치채지 못해요.
핵심 정리
- API = 시스템 간 '약속된 소통 창구'.
- 핵심은 계약: 요청 형식, 응답 형식, 오류 코드.
- 계약 변경에는 버전을 붙인다(예: /v1/, /v2/). 한 번의 변경으로 전부 망가지는 걸 막는다.
일상 속 비유
API는 레스토랑의 주문 카운터 같아요. 메뉴를 보고 주문하면(요청), 주방이 만들어 내오고(응답), 양쪽이 공통의 규칙을 가지죠.
장점
- 서로 다른 시스템을 깔끔하게 이어 줌
- 하나의 API로 웹과 앱을 동시에 감당함
- 계약이 명확하면 AI도 사람도 협업하기 쉬움
단점
- 계약을 바꾸면 양쪽도 바꿔야 함(버전 관리가 필요)
- 설계가 나쁘면 유지보수하기 어려운 결합을 만듦
적합한 경우
- 프론트엔드와 백엔드가 분리된 앱
- 제3자가 연동하도록 열어 두는 서비스
맞지 않는 경우
- 데이터 교환이 전혀 없는 순수 정적 페이지
초보자 점수표
- 초보자 추천도
- 4/5
- 학습 비용(높을수록 비용 큼)
- 3/5
- 시장 수요
- 5/5
- AI 생성 친화도
- 5/5
자주 묻는 질문
API가 정확히 무엇인가요?
시스템 사이의 ‘주문 창구’입니다. 약속된 형식으로 요청을 보내면 약속된 형식으로 데이터가 돌아오며, 서로의 내부 구조를 알 필요가 없습니다.
프런트엔드가 API 없이 데이터베이스에 직접 연결해도 되나요?
강력히 권장하지 않습니다. 창고 열쇠를 모든 손님에게 주는 셈입니다. API는 중간 관문으로서 신원과 권한을 검증하고 새어 나가면 안 되는 데이터를 걸러냅니다.
REST와 GraphQL 중 무엇을 써야 하나요?
초보자와 대부분의 프로젝트는 REST로 충분하며 간단하고 직관적입니다. 프런트가 많은 연관 데이터를 유연하게 조합해야 할 때만 GraphQL을 고려하세요. 유행이라고 미리 도입하지 마세요.
초보자 경로 다음 단계: DNS →