API

웹 API는 인터넷을 통해 HTTP 프로토콜을 사용하여 기능이나 데이터를 제공하는 API이다. 주로 클라이언트-서버 모델에서 서버 측의 자원을 외부에 공개하는 데 사용되며, 웹 애플리케이션, 모바일 앱, 서비스 간 통합 등 다양한 시나리오에서 핵심적인 역할을 한다. 웹 API는 특정 아키텍처 스타일이나 프로토콜을 따르며, 그 중 가장 널리 사용되는 것은 REST, GraphQL, SOAP이다.

REST는 표현 상태 전달의 약자로, 자원을 URI로 식별하고 HTTP 메서드(GET, POST, PUT, DELETE 등)를 통해 해당 자원에 대한 작업을 정의하는 아키텍처 스타일이다. Stateless(무상태성) 원칙을 따르며, 일반적으로 JSON이나 XML 형식으로 데이터를 교환한다. RESTful API는 단순성, 확장성, 캐시 가능성 덕분에 현대 웹 서비스의 사실상 표준으로 자리 잡았다.

다른 주요 유형으로는 GraphQL과 SOAP가 있다. GraphQL은 페이스북(현 메타)이 개발한 쿼리 언어이자 런타임으로, 클라이언트가 정확히 필요한 데이터의 구조와 필드를 한 번의 요청으로 지정할 수 있게 한다. 이는 오버페칭이나 언더페칭 문제를 줄이고, 여러 번의 API 호출을 단일 요청으로 통합할 수 있는 효율성을 제공한다. 반면, SOAP는 XML 기반의 프로토콜로, WSDL을 통한 엄격한 계약과 WS-Security 같은 강력한 보안 표준을 포함하는 것이 특징이다. 주로 금융, 통신 등 높은 보안과 트랜잭션 신뢰성이 요구되는 엔터프라이즈 환경에서 사용된다.

이러한 웹 API 유형들은 각자의 장단점을 가지고 있으며, 시스템의 요구사항, 복잡도, 보안 수준, 개발 생태계에 따라 선택된다. 현대 개발 트렌드에서는 REST와 GraphQL이 새로운 서비스 구축에 더 많이 채택되는 반면, SOAP는 기존 엔터프라이즈 시스템을 유지보수하거나 특정 산업 표준을 준수해야 할 때 주로 활용된다.

라이브러리 API는 특정 기능을 제공하는 소프트웨어 라이브러리가 외부에 노출하는 인터페이스이다. 개발자는 이 API를 통해 라이브러리의 복잡한 내부 구현을 직접 다루지 않고도, 정의된 함수나 클래스, 메서드를 호출하여 필요한 기능을 사용할 수 있다. 예를 들어, 파이썬의 requests 라이브러리는 requests.get()과 같은 API를 제공하여 HTTP 요청을 쉽게 보낼 수 있게 한다. 프레임워크 API는 특정 애플리케이션 구조나 개발 패러다임을 제공하는 소프트웨어 프레임워크가 정의한 규칙과 후크(hook) 지점을 의미한다. 개발자는 프레임워크가 제공하는 라이프사이클에 맞춰 코드를 작성하고, 프레임워크가 정의한 API를 구현함으로써 애플리케이션의 동작을 제어한다.

라이브러리와 프레임워크 API의 주요 차이는 제어의 흐름에 있다. 라이브러리 API를 사용할 때는 애플리케이션 코드가 주체가 되어 필요할 때 API를 호출하는 방식이다. 반면, 프레임워크 API는 제어 반전 원칙을 따르는 경우가 많다. 즉, 프레임워크가 전체적인 실행 흐름을 제어하고, 개발자는 프레임워크가 요구하는 특정 인터페이스나 추상 클래스를 구현하여 코드를 "연결"한다. 대표적인 예로 자바의 스프링 프레임워크나 자바스크립트의 리액트, 앵귤러 등이 있다.

이러한 API는 일반적으로 SDK의 형태로 패키징되어 배포된다. 사용법은 공식 문서, API 문서화 도구를 통해 생성된 레퍼런스, 코드 예제, 그리고 통합 개발 환경의 인텔리센스 기능을 통해 알 수 있다. 잘 설계된 라이브러리/프레임워크 API는 직관적인 명명 규칙, 일관된 패턴, 그리고 명확한 에러 처리 방식을 갖추고 있어 개발자의 학습 곡선을 낮추고 생산성을 높이는 데 기여한다.

운영체제 API는 응용 프로그램이 운영체제의 핵심 기능과 자원을 안전하게 활용할 수 있도록 제공하는 인터페이스이다. 이는 일반적으로 시스템 호출 또는 라이브러리 함수의 형태로 제공되며, 응용 프로그램이 하드웨어를 직접 제어하지 않고도 파일 시스템 조작, 메모리 할당, 프로세스 관리, 네트워크 통신 등의 작업을 수행할 수 있게 한다. 운영체제 API는 응용 프로그램과 커널 사이의 중개자 역할을 하여, 프로그램의 이식성을 높이고 시스템의 안정성과 보안을 유지하는 데 기여한다.

주요 운영체제별 API는 다음과 같은 특징을 가진다. 마이크로소프트 윈도우는 Win32 API와 최신 윈도우 런타임 API를 제공하며, GUI 생성, 레지스트리 접근, 보안 관리 등 광범위한 기능을 포함한다. 유닉스 계열 운영체제(리눅스, macOS 등)는 POSIX 표준을 따르는 시스템 호출과 C 표준 라이브러리를 주요 API로 사용한다. macOS는 추가적으로 코코아 및 카본 API를 통해 네이티브 애플리케이션 개발을 지원한다. 모바일 운영체제인 안드로이드는 자바 및 코틀린 기반의 안드로이드 SDK API를, iOS는 Objective-C 및 스위프트 기반의 코코아 터치 프레임워크를 제공한다.

이러한 API들은 일반적으로 다음과 같은 핵심 기능 영역을 추상화하여 제공한다.

운영체제 API의 설계는 하위 호환성 유지가 매우 중요하며, 오랜 기간 동안 수많은 응용 프로그램이 특정 API 버전에 의존해 왔다. 따라서 새로운 API가 도입되더라도 기존 API는 장기간 지원되는 경우가 많다. 또한, 가상 머신이나 컨테이너 환경에서는 게스트 운영체제의 API 호출이 호스트 시스템의 API로 변환되어 실행되는 방식으로 동작한다.

데이터베이스 API는 응용 프로그램이 데이터베이스 관리 시스템(DBMS)과 상호작용하여 데이터를 생성, 조회, 수정, 삭제(CRUD)할 수 있도록 하는 인터페이스이다. 이는 애플리케이션 로직과 데이터 저장소 사이의 추상화 계층을 제공하여, 개발자가 복잡한 SQL 문을 직접 작성하거나 데이터베이스의 내부 구조를 깊이 이해하지 않고도 데이터를 효율적으로 조작할 수 있게 한다.

주요 데이터베이스 API는 다음과 같은 유형으로 나눌 수 있다.

이러한 API를 사용함으로써 얻는 핵심 이점은 데이터베이스 독립성을 높일 수 있다는 점이다. 예를 들어, JDBC를 사용한 애플리케이션은 드라이버만 교체하면 MySQL에서 Oracle 데이터베이스로 비교적 쉽게 전환할 수 있다. 또한 ORM은 개발자가 객체 지향적인 코드를 작성하면서 내부적으로 적절한 SQL 쿼리를 생성해주어 생산성을 크게 향상시킨다. 그러나 ORM을 통한 복잡한 조인 쿼리나 대량 데이터 처리 시 성능 최적화가 필요할 수 있다는 점은 주의해야 한다.

현대의 애플리케이션 개발에서는 Spring Data JPA나 Django ORM과 같이 프레임워크에 통합된 고수준의 데이터 접근 계층(DAO)을 더 많이 사용한다. 이러한 도구들은 데이터베이스 API의 복잡성을 더욱 추상화하고, 반복적인 CRUD 코드 작성을 자동화하며, 선언적인 방식으로 데이터 접근 로직을 정의할 수 있게 지원한다.

RESTful 설계는 웹 API를 구축하기 위한 아키텍처 스타일로, REST 원칙을 따르는 것을 의미한다. 이 설계 방식은 자원 지향적이며, HTTP 프로토콜의 메서드를 명확한 의미로 사용하는 것을 핵심으로 한다. 주요 목표는 단순성, 확장성, 그리고 구성 요소 간의 독립성을 보장하는 것이다.

RESTful 설계의 핵심 원칙은 다음과 같다.

* 자원(Resource)과 URI: 모든 데이터나 서비스는 고유한 URI로 식별되는 자원으로 표현된다. URI는 명사형으로 구성되어야 하며, 동사나 액션을 포함하지 않는 것이 좋다. 예를 들어, /users는 사용자 목록 자원을, /users/123은 ID가 123인 특정 사용자 자원을 나타낸다.

* HTTP 메서드를 통한 행위 표현: 자원에 대한 행위는 HTTP 메서드(GET, POST, PUT, DELETE 등)로 정의한다. GET은 자원 조회, POST는 생성, PUT/PATCH는 갱신, DELETE는 삭제에 사용된다. 동일한 URI에 대해 다른 메서드를 사용함으로써 다양한 작업을 수행할 수 있다.

* 무상태성(Stateless): 각 클라이언트 요청은 서버에 처리되는 데 필요한 모든 정보를 포함해야 한다. 서버는 클라이언트의 세션 상태를 저장하지 않으며, 이는 확장성과 신뢰성을 높인다.

* 표현(Representation): 클라이언트와 서버는 자원의 실제 형태가 아닌, JSON이나 XML과 같은 표준 형식의 표현으로 데이터를 교환한다. 동일한 자원에 대해 여러 표현이 존재할 수 있다.

잘 설계된 RESTful API는 직관적이고 예측 가능한 엔드포인트 구조를 가진다. 아래는 사용자와 게시글 자원을 관리하는 기본적인 CRUD 작업의 예시이다.

이러한 설계는 캐싱 효율성을 높이고, 클라이언트와 서버의 결합도를 낮추며, 마이크로서비스 아키텍처와 같은 현대적 시스템에 잘 적합하다. 그러나 복잡한 연산이나 상태 기반의 상호작용을 표현하는 데는 한계가 있을 수 있어, GraphQL이나 gRPC 같은 대안이 등장하는 계기가 되기도 했다.

API의 명명 규칙과 일관성은 사용자 경험과 유지보수성을 결정하는 핵심 요소이다. 일관된 명명 규칙은 API를 직관적으로 이해하고 예측 가능하게 만들어, 개발자의 학습 곡선을 낮추고 오용을 줄인다. 일반적으로 RESTful API에서는 리소스를 중심으로 명사를 사용하며, HTTP 메서드를 통해 동작을 표현하는 것이 원칙이다. 예를 들어, 사용자 정보를 다루는 리소스는 /users 경로를 사용하고, 특정 사용자는 /users/{id}로 접근한다. 동작은 GET /users(조회), POST /users(생성), PUT /users/{id}(전체 수정), PATCH /users/{id}(일부 수정), DELETE /users/{id}(삭제)와 같은 HTTP 메서드에 의해 정의된다.

명명 시에는 소문자와 하이픈(-)을 사용하는 케밥 케이스(kebab-case, 예: /order-items)나 소문자와 언더스코어(_)를 사용하는 스네이크 케이스(snake_case)가 URL 경로에 흔히 적용된다. 반면, 요청이나 응답 본문의 JSON 필드 이름에는 주로 소문자로 시작하는 카멜 케이스(camelCase, 예: "orderItemId")가 널리 사용된다. 중요한 것은 하나의 API 내부에서 이러한 스타일을 일관되게 유지하는 것이다. /order-items 경로를 사용하면서 응답 필드로 order_item_id를 보내는 것은 혼란을 초래할 수 있다.

일관성은 단순한 문법 규칙을 넘어 전체 API 설계에 스며들어야 한다. 비슷한 수준의 리소스는 비슷한 구조의 엔드포인트를 가져야 하며, 오류 응답의 형식은 모든 엔드포인트에서 통일되어야 한다. 다음은 일반적인 명명 규칙과 적용 예시를 정리한 표이다.

잘 정의된 명명 규칙과 철저한 일관성은 API를 하나의 언어로 만든다. 이는 API 문서화를 용이하게 하고, 클라이언트 SDK 생성이나 API 게이트웨이를 통한 정책 적용을 자동화하는 데도 기여한다. 궁극적으로 이는 API의 생태계 전체의 품질과 개발 생산성을 높이는 기반이 된다.

API 버전 관리는 서비스의 진화 과정에서 하위 호환성을 유지하거나 의도적으로 변경을 도입할 때 필수적인 절차이다. 적절한 버전 관리 전략은 API 사용자에게 명확한 변경 사항을 알리고, 기존 클라이언트 애플리케이션이 중단 없이 작동할 수 있도록 보장한다. 일반적으로 버전을 표시하는 방법은 URI 경로, 요청 헤더, 또는 매개변수를 사용하는 방식으로 나뉜다.

주요 버전 관리 전략은 다음과 같이 구분된다.

버전 변경의 유형은 주로 메이저(Major), 마이너(Minor), 패치(Patch)로 구분된다. 하위 호환성을 깨는 변경(예: 필드 삭제, 응답 구조 변경)은 메이저 버전을 올려 표시한다. 새로운 기능 추가와 같이 하위 호환성을 유지하는 변경은 마이너 버전을, 버그 수정은 패치 버전을 올리는 것이 일반적이다. 또한, 새로운 버전 출시와 함께 기존 버전에 대한 지원 종료(EOL) 정책과 마이그레이션 가이드를 명시적으로 공지하는 것이 중요하다. 이를 통해 사용자는 안정적인 서비스를 기대할 수 있고, 서비스 제공자는 기술 부채를 체계적으로 관리할 수 있다.

API 보안에서 인증은 사용자나 애플리케이션의 신원을 확인하는 과정이며, 권한 부여는 인증된 주체가 특정 자원에 접근하거나 작업을 수행할 수 있는 권한을 결정하는 과정이다. 이 두 개념은 API가 안전하게 운영되기 위한 핵심 요소이다.

가장 일반적인 인증 방식으로는 API 키와 OAuth가 있다. API 키는 클라이언트가 API 요청 시 제공하는 고유한 문자열 토큰으로, 서버는 이를 통해 호출자를 식별한다. 이 방식은 구현이 간단하지만, 키가 노출될 경우 보안 위험이 따르므로 HTTPS를 통한 전송이 필수적이다. 반면, OAuth는 제3자 애플리케이션에게 사용자의 자원에 대한 제한된 접근 권한을 부여하는 위임 표준 프로토콜이다. 사용자는 비밀번호를 제3자에게 직접 제공하지 않고도 안전하게 권한을 부여할 수 있으며, 액세스 토큰과 리프레시 토큰을 활용해 보안성을 높인다.

인증 및 권한 부여를 구현할 때는 세부 정책을 명확히 설정해야 한다. 접근 권한은 최소 권한의 원칙에 따라 필요한 최소한의 범위로 제한하는 것이 바람직하다. 또한, 발급된 토큰이나 키에는 유효 기간을 설정하고, 민감한 작업에 대해서는 다중 인증 요소를 요구하는 것이 좋다. 이러한 조치는 자격 증명이 유출되더라도 피해를 최소화하는 데 도움이 된다.

암호화는 API 통신에서 전송되는 데이터의 기밀성과 무결성을 보장하는 핵심 수단이다. HTTPS(Hypertext Transfer Protocol Secure)는 HTTP에 TLS(Transport Layer Security) 또는 그 전신인 SSL(Secure Sockets Layer) 암호화 계층을 추가한 프로토콜로, 클라이언트와 서버 간의 모든 데이터 교환을 암호화한다. 이를 통해 민감한 API 키, 사용자 인증 정보, 개인 데이터 등이 네트워크 상에서 제3자에 의해 탈취되거나 변조되는 것을 방지한다. 현대의 API 보안에서는 HTTPS를 기본 요구사항으로 간주하며, 암호화되지 않은 HTTP 연결을 통한 API 호출은 보안 위험으로 판단한다.

HTTPS 구현은 단순히 프로토콜 전환을 넘어서 올바른 인증서 관리와 강력한 암호화 스위트 설정을 포함한다. 서버는 신뢰할 수 있는 인증 기관(CA)으로부터 발급받은 디지털 인증서를 설치해야 하며, 이 인증서는 서버의 신원을 클라이언트에게 증명하는 역할을 한다. 또한, 오래되거나 취약한 것으로 알려진 암호화 알고리즘과 프로토콜 버전(예: SSL 2.0/3.0, TLS 1.0)의 사용을 중단하고, TLS 1.2 또는 TLS 1.3과 같은 최신 보안 프로토콜을 강제해야 한다.

효과적인 API 암호화 전략은 종단간 암호화를 고려할 수도 있다. 이는 데이터가 최종 수신자에 도달할 때까지 암호화 상태를 유지하도록 하여, 전송 중뿐만 아니라 중간 서버나 API 게이트웨이에서도 데이터가 평문으로 노출되지 않게 한다. 또한, 정기적인 보안 감사와 취약점 스캔을 통해 인증서 만료, 잘못된 구성, 새로운 취약점 등을 사전에 탐지하고 조치하는 것이 중요하다.

속도 제한은 API 서버가 특정 시간 내에 클라이언트로부터 받아들일 수 있는 요청의 수를 제한하는 메커니즘이다. 이는 주로 두 가지 목적을 위해 사용된다. 첫째, 서버 자원을 공정하게 분배하고, 한 사용자나 애플리케이션이 과도한 요청으로 인해 다른 합법적인 사용자의 서비스 품질을 저하시키는 것을 방지한다. 둘째, DDoS 공격과 같은 악의적인 트래픽 폭주로부터 시스템을 보호하는 기본적인 방어 수단 역할을 한다. 일반적인 구현 방식으로는 특정 시간 창(예: 1초, 1분, 1시간) 내에 허용되는 최대 요청 횟수를 정의하는 토큰 버킷 또는 누출 버킷 알고리즘이 사용된다.

DDoS 공격은 다수의 출처로부터 엄청난 양의 요청을 집중적으로 보내어 API 서버나 기반 인프라를 마비시키는 것을 목표로 한다. 속도 제한만으로는 대규모 분산 공격을 완전히 차단하기 어렵기 때문에, 다층적인 방어 전략이 필요하다. API 게이트웨이는 이러한 방어의 최전선에서 중앙 집중식으로 속도 제한 정책을 적용하고, 의심스러운 트래픽 패턴을 필터링하는 역할을 한다.

효과적인 속도 제한 및 DDoS 방어를 위해서는 다음과 같은 조치들이 종합적으로 고려되어야 한다.

이러한 조치들은 단순히 공격을 막는 것을 넘어서, API의 가용성과 안정성을 보장하며, 서비스 제공자와 소비자 간의 신뢰를 유지하는 데 기여한다.

API 문서화는 개발자가 API를 효과적으로 이해하고 사용할 수 있도록 돕는 필수적인 과정이다. 문서화 도구는 이 과정을 자동화하고 표준화하여 일관된 형식의 문서를 생성하고 유지 관리하는 데 기여한다. 이 중 Swagger와 OpenAPI는 웹 API를 설명하고 문서화하기 위한 사실상의 표준으로 자리 잡았다.

Swagger는 원래 SmartBear Software가 개발한 오픈 소스 도구 세트의 이름이었으나, 현재는 OpenAPI Specification(OAS)이라는 공식 표준 명세와 이를 구현하는 도구 생태계를 포괄하는 용어로 사용된다. OpenAPI 명세는 RESTful API를 설명하기 위한 YAML 또는 JSON 형식의 언어 중립적인 표준이다. 이 명세 파일을 기반으로 Swagger 도구들은 대화형 문서, 클라이언트 및 서버 코드 생성, 테스트 등을 자동으로 수행할 수 있다. 주요 도구로는 API 설계를 위한 Swagger Editor, 대화형 문서를 생성하는 Swagger UI, 그리고 명세 파일을 기반으로 다양한 언어의 서버/클라이언트 스텁(stub) 코드를 생성하는 Swagger Codegen 등이 있다.

이러한 도구를 사용하는 일반적인 워크플로우는 다음과 같다. 먼저, 개발자는 OpenAPI 명세 파일을 작성하거나, 어노테이션을 통해 소스 코드에서 자동 생성한다. 그 후 Swagger UI는 이 명세를 읽어 각 엔드포인트, 요청/응답 형식, 매개변수, 인증 방법 등을 시각적으로 보여주는 웹 페이지를 생성한다. 이 문서는 단순한 참고 자료를 넘어서, 사용자가 브라우저에서 직접 API를 호출해볼 수 있는 대화형 기능을 제공한다. 이는 개발 경험을 크게 향상시키고, API 통합 시간을 단축시킨다.

OpenAPI 생태계의 장점은 문서와 코드, 그리고 실제 API 구현 사이의 일관성을 유지할 수 있다는 점이다. 명세가 단일 진실 공급원(SSOT) 역할을 하여, 문서가 구식이 되는 문제를 줄인다. 또한, Postman이나 Insomnia 같은 API 클라이언트 도구들도 OpenAPI 명세를 가져오는 기능을 지원하여, 개발 도구 간의 호환성을 높인다.

API 테스트는 소프트웨어 개발 과정에서 API의 기능성, 신뢰성, 성능, 보안을 검증하는 중요한 활동이다. 주로 통합 테스트 단계에서 수행되며, 단위 테스트와 시스템 테스트 사이의 격차를 메우는 역할을 한다. 주요 목표는 엔드포인트 간의 상호작용이 명세대로 작동하는지, 요청과 응답이 올바른지, 오류 처리가 적절한지 확인하는 것이다.

테스트 방법론은 크게 블랙박스 테스트와 화이트박스 테스트로 구분된다. 블랙박스 테스트는 API의 내부 구현을 알지 못한 상태로 입력값에 대한 출력값만을 검증하는 방식이다. 반면 화이트박스 테스트는 내부 로직과 코드 경로를 이해하고 이를 기반으로 테스트 케이스를 설계한다. 또한, 부하 테스트와 스트레스 테스트를 통해 동시 사용자 수나 초당 요청 수를 늘려 성능 한계점과 안정성을 확인한다. 보안 테스트는 인증과 권한 부여 메커니즘, 데이터 유효성 검사, SQL 삽입과 같은 일반적인 취약점을 점검한다.

다양한 도구들이 API 테스트를 자동화하고 효율화하는 데 사용된다. 대표적인 도구는 다음과 같다.

효과적인 API 테스트는 단순한 기능 검증을 넘어 상태 코드, 응답 헤더, 데이터 형식 (예: JSON, XML), 비즈니스 로직을 포괄적으로 점검해야 한다. 또한 모의 서버를 활용해 외부 의존성이 있는 API를 독립적으로 테스트하거나, CI/CD 파이프라인에 테스트를 통합하여 지속적인 품질 관리를 실현한다.

API 게이트웨이는 클라이언트와 하나 이상의 백엔드 마이크로서비스 사이에 위치하는 중간 서버 또는 서비스 계층이다. 모든 클라이언트 요청은 먼저 API 게이트웨이를 통과하며, 게이트웨이는 적절한 내부 서비스로 요청을 라우팅하고 응답을 집계하여 클라이언트에 반환한다. 이는 마이크로서비스 아키텍처에서 필수적인 구성 요소로, 클라이언트가 개별 서비스의 위치와 구현 세부 사항을 알 필요 없이 통합된 진입점을 제공한다.

주요 기능은 다음과 같다.

API 게이트웨이를 도입하면 여러 이점이 있다. 클라이언트와 백엔드 서비스 간의 결합도를 낮추어 서비스의 독립적인 배포와 확장을 용이하게 한다. 또한 인증, 로깅, 속도 제한과 같은 공통 관심사를 게이트웨이에서 일괄 처리함으로써 각 마이크로서비스의 코드를 단순화하고 개발 생산성을 높인다. 대표적인 구현체로는 Kong, Apigee, AWS API Gateway, Spring Cloud Gateway 등이 있다.

WebSocket은 TCP 연결을 기반으로 하는 양방향 통신 프로토콜이다. 이는 HTTP의 요청-응답 모델과 달리, 한 번 연결이 수립되면 서버와 클라이언트가 언제든지 데이터를 주고받을 수 있는 지속적인 채널을 제공한다. 이는 실시간 채팅, 주식 시세 표시, 협업 편집 도구, 실시간 알림과 같이 즉각적인 데이터 전달이 필요한 애플리케이션에 적합하다. WebSocket 연결은 HTTP 업그레이드 핸드셰이크를 통해 시작되며, 이후 별도의 프로토콜로 전환되어 낮은 지연 시간과 오버헤드로 통신한다.

반면, Webhook은 이벤트 기반의 단방향 통신 메커니즘이다. 특정 이벤트(예: 결제 완료, 코드 푸시, 새 주문 등)가 발생하면 서버가 미리 등록된 URL(콜백 URL)로 HTTP POST 요청을 보내 알린다. 이는 클라이언트가 지속적으로 폴링(polling)할 필요 없이, 서버에서 직접 이벤트 발생을 통보하는 '역방향 API' 방식으로 작동한다. Webhook은 CI/CD 파이프라인, 결제 상태 알림, SNS 연동 등 비동기적 이벤트 처리를 간소화하는 데 널리 사용된다.

두 기술은 실시간성을 제공하지만 그 접근 방식이 근본적으로 다르다. WebSocket은 지속적인 연결을 통해 실시간 양방향 대화를 가능하게 하는 반면, Webhook은 사전 정의된 이벤트에 대한 일회성 알림을 전달한다. 현대 애플리케이션에서는 상황에 맞게 두 기술을 혼합하여 사용하기도 한다. 예를 들어, 실시간 대시보드는 WebSocket을 통해 실시간 데이터 스트림을 받으면서, 시스템의 중요한 상태 변화는 Webhook을 통해 외부 서비스에 알릴 수 있다.