---
term: 'API (애플리케이션 프로그래밍 인터페이스)'
seoTitle: 'API란? 애플리케이션 프로그래밍 인터페이스 설명'
headline: 'API(애플리케이션 프로그래밍 인터페이스)란?'
slug: api
category: api-realtime
shortDefinition: 'API는 한 애플리케이션이 다른 애플리케이션의 내부 코드를 알지 못해도 그 데이터와 기능을 요청할 수 있게 하는 규칙의 집합입니다.'
relatedTerms:
  - rest-api
  - graphql-vs-rest
  - backend-sdk
  - auto-generated-database-apis
  - api-gateway-architecture
contrastsWith:
  - backend-sdk
faq:
  - question: 'API는 무엇의 약자입니까?'
    answer: 'Application Programming Interface(애플리케이션 프로그래밍 인터페이스)입니다. "애플리케이션"은 고유한 기능을 가진 모든 소프트웨어이고, "인터페이스"는 그 둘 사이의 계약, 즉 한쪽이 보낼 수 있는 정의된 요청의 집합과 다른 쪽이 돌려주기로 약속한 응답입니다. 핵심은 "프로그래밍"입니다. UI가 사람을 위한 인터페이스라면 API는 소프트웨어를 위한 인터페이스입니다.'
  - question: 'API를 쉽게 설명하면 무엇입니까?'
    answer: '메뉴를 든 전달자입니다. 한 프로그램이 자신이 할 수 있는 일의 목록(이 데이터를 가져오기, 저 작업을 수행하기)을 노출하고, 다른 프로그램들은 내부에서 작업이 어떻게 이루어지는지 전혀 보지 않고 정의된 요청으로 이를 호출합니다. 고전적인 예시로, 날씨 앱은 하늘을 측정하지 않고 날씨 서비스의 API를 호출합니다.'
  - question: 'API는 어떻게 동작합니까?'
    answer: '요청과 응답으로 동작합니다. 클라이언트는 리소스를 가리키는 URL인 엔드포인트에, 의도를 나타내는 메서드, 메타데이터와 자격 증명을 담은 헤더, 때로는 데이터 본문을 실어 요청을 보냅니다. 서버는 이를 검증하고 작업을 수행한 뒤 상태 코드와 응답 본문(보통 JSON)을 반환합니다. 지금까지 사용해 본 모든 연동은 이 루프로 환원됩니다.'
  - question: 'API의 예시에는 무엇이 있습니까?'
    answer: 'ID 공급자(IdP)를 통한 로그인, 체크아웃의 결제 단계, 배달 앱에 삽입된 지도, 날씨 위젯. 각각은 한 애플리케이션이 다른 애플리케이션의 API를 호출하는 것입니다. 개발자 관점의 예시는 더 단순합니다. 백엔드 플랫폼이 데이터베이스를 모바일 앱이 조회하는 HTTP 엔드포인트로 노출하는 것입니다.'
  - question: 'API와 SDK의 차이는 무엇입니까?'
    answer: 'API는 계약이고, SDK는 그 계약을 소비하기 위한 도구 모음입니다. SDK는 API 호출을 언어에 맞는 관용적 함수로 감싸고 세션 처리, 재시도, 타입을 더합니다. API는 네트워크를 통해 호출하고 SDK는 코드에 import합니다. 그리고 내부적으로 SDK는 API 호출을 하고 있습니다.'
  - question: 'API의 유형에는 무엇이 있습니까?'
    answer: '대상별로는 공개(모든 개발자에게 개방), 파트너(계약된 기업과 공유), 내부(한 조직 안에서만 사용), 복합(여러 호출을 묶음)으로 나뉩니다. 스타일별로는 REST, GraphQL, gRPC, SOAP, WebSocket API가 있습니다. 그리고 웹 너머에는 라이브러리 API와 운영체제 API가 있습니다. 인터페이스는 HTTP가 실어 나르기 훨씬 전부터 존재했습니다.'
  - question: 'API 엔드포인트란 무엇입니까?'
    answer: 'API가 한 리소스에 대한 요청을 받는 특정 URL입니다. /users/42는 사용자 42의 엔드포인트입니다. 엔드포인트와 메서드가 합쳐져 하나의 작업을 정의합니다. GET /users/42는 읽고, DELETE /users/42는 삭제합니다. 엔드포인트는 인터페이스 전체에서 주소를 지정할 수 있는 표면입니다.'
  - question: 'API 키란 무엇입니까?'
    answer: '클라이언트가 모든 요청에 함께 보내는 생성된 문자열로, 제공업체가 호출자를 식별하고 사용량을 측정하며 제한이나 폐기를 적용할 수 있게 합니다. 인가(권한 부여)라기보다 식별에 가깝습니다. 프로덕션 API는 사용자별 권한을 위해 OAuth로 발급된 토큰 같은 실제 인증을 그 위에 겹쳐 둡니다.'
codeLanguages: [javascript, dart, swift, kotlin]
externalAuthorities:
  - name: 'API — MDN Web Docs glossary'
    url: 'https://developer.mozilla.org/en-US/docs/Glossary/API'
  - name: 'OpenAPI Specification'
    url: 'https://spec.openapis.org/oas/latest.html'
  - name: 'RFC 9110 — HTTP Semantics'
    url: 'https://www.rfc-editor.org/rfc/rfc9110'
  - name: 'RFC 6749 — OAuth 2.0 Authorization Framework'
    url: 'https://www.rfc-editor.org/rfc/rfc6749'
  - name: 'API — Wikipedia'
    url: 'https://en.wikipedia.org/wiki/API'
cta:
  title: '이미 API인 백엔드'
  text: 'Back4app에서 데이터 모델을 정의하면 플랫폼이 그에 맞는 REST와 GraphQL API를 생성합니다. 엔드포인트, 인증, 권한까지 포함되며, 모든 주요 플랫폼에서 이를 관용적으로 다루는 SDK가 함께 제공됩니다.'
  linkText: '무료로 시작하기'
  linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-10-27'
translationKey: api
---

**API는 한 애플리케이션이 다른 애플리케이션의 내부 코드를 알지 못해도 그 데이터와 기능을 요청할 수 있게 하는 규칙의 집합입니다.** 유명한 식당 비유(메뉴에서 주문하면 주방은 보이지 않는다)는 한 문장만큼의 가치가 있고 그 이상은 아닙니다. 실제 API를 보는 편이 비유보다 더 많은 것을 알려 주기 때문입니다. API는 *계약*이고, 계약은 정확합니다.

## 핵심 요약

| 질문 | 답변 |
| --- | --- |
| 정의 | 두 프로그램 사이에 정의된 요청/응답 계약 |
| 루프 | 엔드포인트 + 메서드 + 헤더 + 본문 → 상태 코드 + 응답 |
| 대상별 | 공개 · 파트너 · 내부 · 복합 |
| 스타일별 | REST · GraphQL · gRPC · SOAP · WebSocket |
| 현대의 계약 | 문서, 클라이언트, 목(mock)을 생성하는 기계가 읽을 수 있는 명세(OpenAPI) |

## HTTP API 요청과 응답의 해부

상위에 노출되는 설명 글 어디에도 실물이 없으니, 여기 API 호출 전체를 보입니다. 요청과 응답, 숨긴 것은 없습니다:

```text
POST /classes/Todo HTTP/1.1              ← 메서드 + 엔드포인트
Host: api.example-backend.com
X-Api-Key: app-7f2c…                     ← 호출하는 앱을 식별
Authorization: Bearer eyJhbGci…          ← 사용자를 인증
Content-Type: application/json

{ "title": "Ship the release", "done": false }

HTTP/1.1 201 Created                     ← 상태: 성공, 리소스 생성됨
Location: /classes/Todo/xKd91m
Content-Type: application/json

{ "objectId": "xKd91m", "createdAt": "2026-07-24T10:30:00Z" }
```

SDK를 통한 같은 호출입니다. SDK는 이 HTTP를 사용하는 언어의 관용구로 감싼 것에 지나지 않습니다:

**JavaScript:**

```javascript
// JavaScript / Node.js — Back4app JS SDK
// One API call: create a record via the auto-generated REST API
const todo = new Parse.Object('Todo');
todo.set('title', 'Ship the release');
todo.set('done', false);
await todo.save();
// Under the hood: POST /classes/Todo with a JSON body → 201 Created
console.log('Created with id', todo.id);
```

**Flutter:**

```dart
// Flutter / Dart — Back4app Flutter SDK
// One API call: create a record via the auto-generated REST API
final todo = ParseObject('Todo')
  ..set('title', 'Ship the release')
  ..set('done', false);
await todo.save();
// Under the hood: POST /classes/Todo with a JSON body → 201 Created
print('Created with id ${todo.objectId}');
```

**Swift:**

```swift
// iOS / Swift — Back4app Swift SDK
// One API call: create a record via the auto-generated REST API
var todo = Todo()
todo.title = "Ship the release"
todo.done = false
todo.save { result in
    // Under the hood: POST /classes/Todo with a JSON body → 201 Created
    if case .success(let saved) = result { print("Created with id \(saved.id ?? "")") }
}
```

**Kotlin:**

```kotlin
// Android / Kotlin — Back4app Android SDK
// One API call: create a record via the auto-generated REST API
val todo = ParseObject("Todo")
todo.put("title", "Ship the release")
todo.put("done", false)
todo.saveInBackground { e ->
    // Under the hood: POST /classes/Todo with a JSON body → 201 Created
    if (e == null) println("Created with id ${todo.objectId}")
}
```

## API 호출의 동작 방식

```mermaid
flowchart LR
  accTitle: API 요청과 응답 루프
  accDescr: 클라이언트 애플리케이션이 메서드, 엔드포인트, 헤더, 본문을 담은 요청을 API로 보내면, API는 이를 검증하고 인가한 뒤 백엔드 로직과 데이터를 호출하고, 상태 코드와 응답 본문을 클라이언트에 반환합니다.
  C["클라이언트 앱<br/>(웹, 모바일, 다른 서버)"] -->|"요청:<br/>메서드 + 엔드포인트 + 헤더 + 본문"| A["API<br/>검증 · 인가 · 라우팅"]
  A --> B["백엔드 로직<br/>+ 데이터베이스"]
  B --> A
  A -->|"응답:<br/>상태 코드 + JSON"| C
```

이 루프의 세 가지 속성이 API가 현대 스택을 움직이는 이유를 설명합니다. **추상화:** 호출자에게 필요한 것은 계약이지 구현이 아닙니다. 제공업체는 클라이언트 하나 깨뜨리지 않고 인터페이스 뒤의 모든 것을 다시 쓸 수 있습니다. **경계:** 검증과 [권한](/glossary/ko/data-layer-vs-application-layer-security/)은 인터페이스에 있습니다. 클라이언트가 [데이터베이스](/glossary/ko/nosql-vs-sql/)에 직접 말을 걸지 않고 API와 대화하는 이유입니다. API는 데이터베이스가 아니라 그 앞을 지키는 문지기입니다. **조합:** 모든 기능이 호출 가능하므로 애플리케이션은 서비스로 조립됩니다. 인증은 여기서, 결제는 저기서, 지도는 세 번째 서비스에서 가져오며, 점점 더 AI 에이전트도 같은 기반을 씁니다. 툴 호출은 모델이 요청을 결정하는 API 호출입니다.

## 계약: API가 실제로 약속하는 것

API를 "계약"이라 부르는 글은 많지만 계약을 실제로 보여 주는 글은 드뭅니다. 오늘날 계약은 기계가 읽을 수 있는 문서입니다. HTTP API의 표준은 [OpenAPI 명세](https://spec.openapis.org/oas/latest.html)로, 모든 엔드포인트, 파라미터, 스키마, 상태 코드를 나열합니다. 이 파일 하나에서 도구가 레퍼런스 문서, 클라이언트 라이브러리, 서버 스텁, 목 서버, 계약 테스트를 생성합니다.

계약이라는 틀이 힘을 갖는 이유는 *버전 관리*에 있습니다. 응답 필드를 추가해도 아무도 깨지지 않지만, 필드 이름을 바꾸거나 제거하면 모든 소비자가 소리 없이 깨집니다. 그래서 성숙한 API는 추가적 변경과 호환성을 깨는 변경을 구분하고, 표면에 버전을 붙이며(`/v1/` 또는 헤더), 지원 중단 기간을 공표합니다. 변경 정책이 없는 API는 조건 없는 계약입니다. 기술적으로는 약속이지만 실제로는 돌발 상황입니다.

## API의 유형

"API의 유형"은 그 자체로 자주 검색되는 질문이므로 검색 의도에 맞춰 답합니다. 분류 체계는 하나가 아니라 둘입니다.

**대상별:**

| 유형 | 소비자 | 주요 관심사 |
| --- | --- | --- |
| 공개(오픈) | 등록한 모든 개발자 | 키, 할당량, 문서 품질, 버전 관리 규율 |
| 파트너 | 계약된 기업 | 법적 계약, SLA, 더 엄격한 인증 |
| 내부(프라이빗) | 자사 팀과 서비스 | 마이크로서비스 계약, 더 빠른 변경 주기 |
| 복합 | 묶음이 필요한 클라이언트 | 한 번의 호출로 여러 호출을 조율. 왕복 횟수 감소 |

**스타일별:** [REST](/glossary/ko/rest-api/)(URL의 리소스, HTTP 메서드), GraphQL(엔드포인트 하나에서 클라이언트가 모양을 정하는 쿼리), gRPC(바이너리, 계약 우선, 서비스 간 통신), SOAP(XML 봉투, 엔터프라이즈/레거시 표준), WebSocket API([양방향, 지속 연결](/glossary/ko/websockets-real-time-sync/)). 다음 표에서 비교합니다.

그리고 웹 설명 글이 건너뛰는 한 단락입니다. 모든 API가 웹 API는 아닙니다. 언어의 표준 라이브러리, POSIX 시스템 호출, 브라우저 내장 `fetch`와 위치 정보 인터페이스는 모두 네트워크를 건너지 않는 API, 즉 프로그램 사이의 계약입니다. 웹 API는 그 계약을 URL 뒤에 두었을 뿐입니다.

## REST vs. GraphQL vs. gRPC vs. SOAP vs. WebSocket

| 스타일 | 전송 형식 | 모델 | 가장 강한 영역 | 주의할 점 |
| --- | --- | --- | --- | --- |
| REST | HTTP 위의 JSON | 리소스 + 메서드 | 공개 CRUD API, 캐시 가능성, 보편성 | 고정된 모양에서의 오버/언더페칭 |
| GraphQL | HTTP 위의 JSON | 클라이언트가 구성하는 쿼리 | 다양한 클라이언트, 중첩 데이터 | 캐싱 복잡성, 리졸버 N+1 |
| gRPC | HTTP/2 위의 Protobuf | 타입이 있는 프로시저 호출 | 내부 서비스 간 속도 | 브라우저 마찰, 바이너리 디버깅 |
| SOAP | XML 봉투 | 오퍼레이션 + WS-* 표준 | 레거시 엔터프라이즈, 공식 계약 | 장황함, 무거운 도구 |
| WebSocket | 소켓 하나 위의 프레임 | 양방향 메시지 | 실시간 푸시, 프레즌스 | 프로토콜을 직접 정의해야 함 |

## 일반적인 사용 사례

- **모바일과 웹 백엔드** – 모든 화면의 데이터가 API를 통해 도착하며, 프론트엔드는 데이터베이스를 건드리지 않습니다.
- **서드파티 연동** – 결제, ID, 메시징, 지도. 다시 만드는 대신 계약을 통해 빌리는 기능입니다.
- **마이크로서비스 통신** – 서비스가 독립적으로 배포되고 확장되게 하는 이음새로서의 내부 API.
- **자동화와 스크립팅** – API가 있는 것은 무엇이든 조율할 수 있습니다. CI 파이프라인, 인프라, 콘텐츠 워크플로.
- **AI 에이전트와 툴 호출** – 모델은 API를 호출해 행동합니다. 이제 잘 문서화된 계약은 SDK와 에이전트라는 두 종류의 기계가 소비합니다.

## 어떤 API 스타일을 선택해야 할까? 결정 매트릭스

| 상황 | 선택 |
| --- | --- |
| 리소스에 대한 공개 CRUD | REST. 공용어이고 캐시 친화적 |
| 클라이언트 유형이 많고 각각 다른 모양이 필요 | GraphQL 선택 집합 |
| 내부의 높은 처리량 서비스 메시 | gRPC 계약 |
| 실시간, 양방향, 상시 연결 | WebSocket(또는 그 위의 라이브 쿼리 계층) |
| WS-* 요건이 있는 엔터프라이즈 파트너 | SOAP. 계약상 요구되기 때문 |
| 화면 하나에 서비스 다섯 개 필요 | 복합 엔드포인트 또는 backend-for-frontend |

## 한계와 트레이드오프

- **계약은 제공업체도 구속합니다.** 공개된 모든 필드는 누군가가 의존하는 것이 됩니다. 진화는 조용한 수정이 아니라 버전 관리 규율을 통해 이루어집니다.
- **네트워크 API는 네트워크를 물려받습니다.** 지연 시간, 부분 실패, 재시도는 모든 원격 호출 의미론의 일부입니다. 로컬 함수 호출에는 타임아웃 정책이 필요한 적이 없었습니다.
- **추상화는 비용을 숨깁니다.** 평범해 보이는 호출 하나가 비싼 작업으로 퍼져 나갈 수 있습니다. 소비자는 메뉴를 볼 뿐 주방의 청구서는 보지 못하며, [속도 제한](/glossary/ko/api-rate-limiting-throttling/)과 할당량은 이를 위해 존재합니다.
- **보안 표면은 표면적에 비례해 커집니다.** 모든 엔드포인트는 문입니다. 키는 식별할 뿐 인가하지 않으므로, 실제 인증([OAuth 2.0](https://www.rfc-editor.org/rfc/rfc6749) 방식의 토큰, 사용자별 권한)과 입력 검증은 기본 조건입니다.
- **고정된 모양은 일부 소비자에게 맞지 않습니다.** 엔드포인트 설계의 오버페칭/언더페칭 트레이드오프는 별도의 주제이며, [관련 항목](/glossary/ko/overfetching-underfetching/)에서 다룹니다.

## Back4app에서의 API

Back4app은 관리형 데이터베이스, 자동 생성되는 REST 및 GraphQL API, 인증, 파일 스토리지, Cloud Code 서버리스 함수를 결합한 오픈소스 Backend as a Service(BaaS) 플랫폼입니다. 결정적인 차이는 API가 *구축되는 것이 아니라 생성된다*는 점입니다. 데이터 모델을 정의하면 플랫폼이 이를 즉시 [REST 엔드포인트와 GraphQL 스키마](/glossary/ko/auto-generated-database-apis/)로 노출하며(위에서 해부한 호출은 실제 Back4app 전송 형식입니다), 키, 사용자 토큰, 클래스 수준 권한이 경계에서 계약을 강제합니다. [SDK](/glossary/ko/backend-sdk/)는 모든 주요 플랫폼에서 그 API를 관용적으로 소비하고, 커스텀 작업은 Cloud Code 함수가 됩니다. 파일 하나로 새 엔드포인트가 생기고, 계약 규율은 그대로이며, 운영할 서버는 없습니다.