API(Application Programming Interface, 애플리케이션 프로그래밍 인터페이스)는 서로 다른 소프트웨어 구성 요소가 규정된 규칙과 프로토콜을 통해 통신할 수 있도록 정의된 인터페이스다. 운영체제, 라이브러리, 웹 서비스 등 다양한 맥락에서 사용되며, 개발자는 내부 구현을 몰라도 API가 노출한 기능을 호출하여 원하는 결과를 얻을 수 있다. 오늘날 API는 모바일 앱, 클라우드 플랫폼, 마이크로서비스 아키텍처의 핵심 연결 수단으로 자리 잡아, 전 세계 소프트웨어 생태계를 잇는 사실상의 공용어 역할을 한다.[1]

1. 역사

API라는 개념의 뿌리는 1947년으로 거슬러 올라간다. 당시 Goldstine과 von Neumann은 서브루틴(subroutine) 개념을 제안하였고, 이는 프로그램 간 재사용 가능한 코드 단위를 정의하는 초기 형태의 인터페이스였다. 'API'라는 용어 자체는 1968년 컴퓨터 그래픽 관련 논문에서 처음 등장했으며, 이 시기에는 같은 컴퓨터 내 프로그램끼리의 소통 규약을 의미했다.[2]

웹 API의 시대는 1990년대 말~2000년대 초 SOA(Service-Oriented Architecture) 물결과 함께 열렸다. 초창기 웹 서비스는 XML 기반의 SOAP, WSDL, UDDI 표준을 사용하여 네트워크 너머의 서비스를 호출하는 방식을 표준화했다. 2000년 Roy Fielding이 REST 아키텍처 스타일을 박사 논문에서 제안한 이후, 간결한 HTTP 기반 API가 빠르게 주류로 자리 잡았다.

2010년대에 들어서면서 생태계가 더욱 다양해졌다. 2010년 Swagger가 출시되어 이후 OpenAPI 명세로 발전하였고, 2012년 Facebook이 내부 API 문제를 해결하기 위해 GraphQL을 개발하여 2015년 오픈소스로 공개하였다. 같은 해 Google은 내부 RPC 인프라를 기반으로 한 gRPC를 발표하며 고성능 마이크로서비스 간 통신의 새로운 선택지를 제공했다.

2. 주요 유형

2.1 REST

REST(Representational State Transfer)는 HTTP를 기반으로 자원(Resource)을 URI로 식별하고, GET·POST·PUT·DELETE 등의 메서드로 상태를 조작하는 아키텍처 스타일이다. 무상태(stateless) 원칙을 따르기 때문에 수평 확장이 용이하며, JSON을 주요 데이터 포맷으로 사용해 가독성이 높다. Twitter, GitHub, Google Maps 등 공개 API 대부분이 REST를 채택하고 있으며, 웹·모바일 서비스의 사실상 표준으로 자리 잡았다.

2.2 GraphQL

GraphQL은 2015년 Facebook이 공개한 쿼리 언어이자 런타임이다. 단일 엔드포인트에서 클라이언트가 필요한 데이터 구조를 직접 명시해 요청하므로, REST에서 발생하는 오버페칭(over-fetching)과 언더페칭(under-fetching) 문제를 줄인다. 스키마 기반의 강 타입 시스템을 갖추어 API 계약을 명확히 정의할 수 있으며, 복잡한 관계형 데이터를 한 번에 조회해야 하는 프론트엔드 중심 애플리케이션에 적합하다.

2.3 gRPC

gRPC는 Google이 2015년 오픈소스로 공개한 고성능 원격 프로시저 호출(RPC) 프레임워크다. Protocol Buffers(protobuf)를 인터페이스 정의 언어이자 직렬화 포맷으로 사용하여 JSON보다 훨씬 작은 페이로드와 빠른 처리 속도를 제공한다.[3] HTTP/2를 전송 계층으로 활용해 양방향 스트리밍을 지원하며, 서비스 간 지연이 중요한 마이크로서비스 내부 통신에 널리 쓰인다. Android framework나 Linux kernel 수준의 시스템 HAL 레이어처럼 엄격한 성능 요구 사항을 가진 환경에서도 gRPC 스타일 IPC가 점차 채택되고 있다.

2.4 SOAP

SOAP(Simple Object Access Protocol)은 XML 기반의 메시지 프로토콜로, WSDL로 서비스 계약을 명시하고 엄격한 스키마 검증과 WS-Security 표준을 통해 높은 보안성과 트랜잭션 무결성을 보장한다. 현대 웹 개발에서는 REST와 GraphQL에 비해 사용 빈도가 낮아졌으나, 금융·의료·공공 부문처럼 강력한 계약 이행과 감사 추적이 필요한 엔터프라이즈 환경에서는 여전히 유효한 선택지다.

3. 설계 원칙

좋은 API 설계에는 몇 가지 공통 원칙이 있다.[4]

  • 일관성: 명명 규칙, 오류 코드, 응답 포맷이 API 전반에 걸쳐 균일해야 한다. 예측 가능한 API는 개발자 경험을 높이고 통합 비용을 낮춘다.
  • 무상태성: REST에서 특히 강조되는 원칙으로, 서버는 클라이언트의 세션 상태를 보관하지 않는다. 각 요청은 처리에 필요한 모든 정보를 스스로 담아야 한다.
  • 버전 관리: 하위 호환성을 깨는 변경이 불가피할 때는 /v1/, /v2/ 같은 경로 버전 또는 헤더 버전을 통해 기존 클라이언트를 보호한다.
  • 멱등성(Idempotency): GET·PUT·DELETE 등 멱등 메서드는 동일 요청을 여러 번 보내도 결과가 같아야 한다. 이는 네트워크 장애 시 안전한 재시도를 가능하게 한다.
  • 최소 노출 원칙: 내부 구현 세부 정보를 외부에 노출하지 않는다. 추상화 수준을 유지함으로써 내부 변경이 외부 계약에 영향을 미치지 않도록 한다.

4. 인증과 보안

API 인증(Authentication)은 요청을 보낸 주체가 누구인지 확인하는 과정이며, 인가(Authorization)는 그 주체가 어떤 자원에 접근할 수 있는지를 결정한다.[5]

API 키는 가장 단순한 형태로, 서비스 제공자가 발급한 고유 식별자를 요청 헤더나 쿼리 파라미터로 전달한다. 구현이 쉽지만 개별 사용자를 구분하기 어려워 공개 API나 서버 간 통신에 주로 활용된다.

OAuth 2.0은 위임 인가를 위한 산업 표준 프로토콜로, Google·GitHub 등 대부분의 공개 플랫폼이 채택하고 있다. 사용자는 비밀번호를 제3자에게 공개하지 않고도 제한된 권한을 위임할 수 있다.

JWT(JSON Web Token)는 세 부분(헤더·페이로드·서명)으로 구성된 자기 서술적 토큰이다. 서버가 세션을 저장하지 않아도 서명 검증만으로 토큰 유효성을 확인할 수 있어 무상태 아키텍처와 잘 맞는다. OWASP는 모든 REST API 엔드포인트를 HTTPS로만 제공하고, JWT를 매 요청마다 서명·만료·발급자·대상 항목까지 검증하도록 권고한다. Application Sandbox나 시스템 서비스 같은 플랫폼 수준 격리 메커니즘도 API 보안의 중요한 보완 요소다.

5. 문서화 도구와 생태계

API 문서화의 현대적 표준은 OpenAPI 명세(구 Swagger)다.[6] 2015년 SmartBear가 Swagger 2.0을 Linux Foundation 산하 OpenAPI Initiative에 기증하면서 시작된 OpenAPI는 현재 3.x 버전까지 발전하였으며, Google·Microsoft·Amazon 등 주요 클라우드 제공사가 모두 지원한다. OpenAPI 파일 하나로 인터랙티브 문서 생성, 서버·클라이언트 코드 자동 생성, API 게이트웨이 설정까지 처리할 수 있다.

Postman은 API 개발·테스트·협업을 위한 대표적인 플랫폼으로, OpenAPI 파일 가져오기, 자동화 테스트, 모의 서버(Mock Server) 기능을 제공한다.

API 게이트웨이는 여러 백엔드 서비스 앞에 위치하여 인증, 속도 제한, 캐싱, 로깅, 라우팅을 일원화하는 인프라 컴포넌트다. AWS API Gateway, Google Cloud API Gateway, Kong 등이 대표적이며, 안드로이드 (운영체제) 생태계처럼 광범위한 플랫폼에서도 외부 서비스 연동에 API 게이트웨이 패턴이 활용된다.

AI 에이전트가 도구를 호출하는 방식도 API 계약에 기반하며, 2020년대 중반부터는 LLM(대형 언어 모델)을 위한 함수 호출(Function Calling) 명세와 MCP(Model Context Protocol) 같은 새로운 API 레이어가 등장하여 생태계의 범위를 더욱 넓히고 있다.

6. 관련 문서

  • Android framework - Android 플랫폼이 앱 개발자에게 노출하는 Java API 레이어
  • HAL - 하드웨어와 운영체제 사이의 추상화 인터페이스 레이어
  • Linux kernel - 시스템 콜(System Call)을 통해 사용자 공간에 API를 제공하는 커널
  • 안드로이드 (운영체제) - API 레벨 체계로 버전 호환성을 관리하는 모바일 운영체제
  • 시스템 서비스 - Android 플랫폼에서 Binder IPC를 통해 API를 노출하는 핵심 서비스

7. 인용 및 각주

[1] Red Hat, "An architect's guide to APIs: SOAP, REST, GraphQL, and gRPC," Wwww.redhat.com(새 탭에서 열림) REST, SOAP, GraphQL, gRPC 각 스타일의 개념과 적합한 사용 사례를 비교한다.

[2] Zylo Systems, "API의 역사: 서브루틴부터 OpenAPI, 그리고 AI 시대까지," Bblog.zylosystems.com(새 탭에서 열림) API 용어의 출현(1968)부터 현대 OpenAPI까지의 발전 과정을 서술한다.

[3] AltexSoft, "Comparing API Architectural Styles: SOAP vs REST vs GraphQL vs RPC," Wwww.altexsoft.com(새 탭에서 열림) gRPC의 Protocol Buffers 직렬화와 HTTP/2 기반 스트리밍 특성을 REST와 비교 분석한다.

[4] Strapi, "RESTful API Design Guide: Principles & Best Practices," Sstrapi.io(새 탭에서 열림) 일관성, 무상태성, 버전 관리, 멱등성 등 RESTful API 설계의 핵심 원칙을 다룬다.

[5] Postman, "What Is API Authentication? Benefits, Methods & Best Practices," Wwww.postman.com(새 탭에서 열림) API 키, OAuth 2.0, JWT 등 주요 인증 방식의 개념과 선택 기준을 정리한다.

[6] OWASP, "REST Security Cheat Sheet," Ccheatsheetseries.owasp.org(새 탭에서 열림) HTTPS 강제, JWT 검증, 속도 제한 등 REST API 보안의 필수 점검 목록을 제공한다.