웹후크란?

웹후크는 2개의 애플리케이션 프로그래밍 인터페이스(API) 간에 경량화 이벤트 기반 통신을 가능케 하는 HTTP 기반 콜백 기능입니다. 웹후크는 다양한 웹 애플리케이션이 다른 애플리케이션에서 소량의 데이터를 수신하기 위해 사용하지만 GitOps 환경에서 자동화 워크플로우를 트리거하는 데 사용될 수도 있습니다.

API란?

API는 애플리케이션 소프트웨어를 구축하고 통합하기 위한 정의 및 프로토콜 세트로, 때때로 API 간 통신은 정보 사용자와 정보 제공자 간의 계약으로 지칭되며 소비자에게 필요한 콘텐츠(호출)와 생산자에게 필요한 콘텐츠(응답)를 구성합니다. 이러한 관계는 서버 앱을 호출하는 클라이언트 앱이라고도 하지만 이러한 역할은 특정 상황에서 애플리케이션이 요청하는 데이터에 따라 뒤바뀔 수 있습니다.  

웹 API는 일반적으로 HTTP를 사용해 다른 애플리케이션에게 데이터를 요청하며 일반적으로 XML 또는 JSON 파일 형식인 응답 메시지의 구조를 정의합니다. 다른 애플리케이션이 쉽게 조작할 수 있는 방식으로 데이터를 표시하므로 XML과 JSON 둘 다 자주 사용됩니다. 

클라이언트 API는 서버 API에게 데이터를 요청할 때 특정 이벤트가 발생했는지, 즉 서버의 데이터가 클라이언트에게 유용한 방식으로 변경되었는지 확인하기 위해 호출합니다. 이 프로세스(폴링이라고 함) 중에 고객은 서버의 API가 관련 데이터(때로 이를 페이로드라고 함)를 전송할 때까지 규칙적인 간격으로 HTTP 요청을 전송합니다. 

클라이언트 애플리케이션은 서버 애플리케이션의 상태를 알지 못하므로 업데이트를 위해 서버의 API를 폴링(특정 이벤트가 발생할 때까지 반복적으로 호출)하지만 서버는 해당 정보가 제공되면 요청된 데이터만 전송합니다. 클라이언트 앱은 관련 이벤트가 발생할 때까지 계속해서 업데이트를 요청하면서 대기해야 합니다.

웹후크의 특징과 차이점

웹후크를 설정하기 위해 클라이언트는 서버 API에 고유한 URL을 부여하고 알고자 하는 이벤트를 지정합니다. 웹후크가 설정되면 클라이언트는 더 이상 서버를 폴링할 필요가 없습니다. 서버는 지정된 이벤트가 발생하면 클라이언트의 웹후크 URL에 관련 페이로드를 전송합니다. 

웹후크는 통신의 책임을 클라이언트가 아닌 서버에 부과하므로 종종 리버스 API 또는 푸시 API라고 불립니다. 서버가 응답할 때까지 데이터를 요청하는 HTTP 요청을 전송하는 클라이언트 대신에 서버는 데이터가 제공되자마자 단일 HTTP POST 요청을 클라이언트에 전송합니다. 웹후크는 닉네임이 있지만 API가 아니며 상호 협력합니다. 웹후크를 사용하려면 애플리케이션에 API가 있어야 합니다. 

웹후크라는 이름은 HTTP 기반 통신을 가리키는 웹과 앱이 관심 있는 호출 또는 기타 이벤트를 가로챌 수 있게 해주는 후킹 프로그래밍 기능을 조합한 것입니다. 웹후크는 서버 앱에서 발생하는 이벤트를 후킹하며 서버가 웹을 통해 클라이언트에 페이로드를 전송하도록 유도합니다. Jeff Lindsay는 2007년 자신의 블로그 포스트 “웹에 혁신을 가져오는 웹후크”를 통해 이 개념의 대중화에 일조하였습니다.

IT 팀은 웹후크를 통해 통신하는 애플리케이션을 보호하기 위해 다양한 방법을 사용합니다. 대부분의 웹후크 지원 애플리케이션은 페이로드의 요청 헤더에 보안 키를 추가하므로 클라이언트가 서버의 Identity를 확인할 수 있습니다. 웹후크는 페이로드가 전송되기 전에 클라이언트와 서버를 모두 검증하는 mTLS(mutual Transport Layer Security) 인증으로 보호되는 경우가 많습니다. 또한 전송된 데이터가 프라이빗으로 유지되도록 클라이언트 애플리케이션이 웹후크 URL에 SSL 암호화를 사용하는 것이 일반적입니다.

웹후크는 두 애플리케이션 간 통신을 간소화하는 데 가장 흔히 사용되지만 코드형 인프라(IaC) 워크플로우를 자동화하고 GitOps 사례를 지원하는 데도 사용될 수 있습니다.

코드형 인프라(IaC)란? 

코드형 인프라(IaC)는 수동 프로세스가 아닌 코드를 통해 인프라를 관리하고 프로비저닝하는 것을 말합니다. 버전 제어는 IaC의 중요한 부분입니다. 다른 소프트웨어 소스 코드 파일과 마찬가지로 구성 파일도 소스 제어가 필요합니다. 코드로 인프라를 배포한다는 것은 인프라를 모듈식 구성 요소로 분할하고 자동화를 통해 다양한 방식으로 결합할 수 있다는 뜻이기도 합니다.

IaC로 인프라 프로비저닝을 자동화하면 애플리케이션을 개발하거나 배포할 때마다 개발자가 직접 서버, 운영 체제, 스토리지, 기타 인프라 구성 요소를 수동으로 프로비저닝하고 관리할 필요가 없어집니다. 인프라 코드화는 프로비저닝을 위해 따라야 할 템플릿을 제공합니다. 수작업으로 할 수도 있지만 이 프로세스는 Red Hat® Ansible Automation® Platform과 같이 엔터프라이즈급 원하는 상태 엔진으로 자동화할 수 있습니다.

GitOps란?

종종 IaC가 진화한 형태로 간주되는 GitOps는 제어 시스템의 오픈소스 버전인 Git를 사용한 인프라 및 애플리케이션 구성 관리를 위한 전략적 접근 방식입니다. 개발자는 GitOps 사례에 따라 Git를 선언적 인프라 및 애플리케이션을 위한 단일 정보 소스로 사용하며, Git 풀 요청을 사용해 인프라 프로비저닝 및 배포를 자동으로 관리합니다. Git 리포지토리에는 시스템의 전체 상태가 포함되어 있어 변경 기록을 확인하고 감사할 수 있습니다. 

웹후크 사용 환경

웹후크는 git 중심 배포 파이프라인을 구현하고 관리하는 데 필요한 단계를 줄여줍니다. 또한 웹후크를 사용해 전체 IaC 워크플로우를 자동으로 시작할 수 있습니다. GitOps 환경에서 웹후크는 두 애플리케이션 사이에서 하는 역할을 그대로 수행합니다. 즉, 지정된 이벤트에 의해 트리거되면 한 API가 다른 API로 페이로드를 전송합니다. 단, 웹후크를 트리거하는 이벤트의 유형과 수신자가 페이로드로 하는 일에 차이가 있습니다.

이러한 맥락에서 Git 리포지토리는 서버 애플리케이션의 역할을 수행하는 반면, 인프라의 상태를 관리하는 원하는 상태 엔진은 클라이언트 애플리케이션의 역할을 합니다. 리포지토리가 변경될 때마다 통신을 트리거하도록 웹후크를 설정할 수 있습니다. 예를 들어, 일부 코드가 업데이트되어 Git 리포지토리로 푸시되면 이 이벤트가 웹후크를 트리거합니다. 그러면 리포지토리는 원하는 상태 엔진의 웹후크 주소로 페이로드를 자동 전송하여 코드가 변경되었음을 알립니다.

이러한 방식으로 웹후크를 사용하면 원하는 상태 엔진이 리포지토리를 적극적으로 모니터링하지 않고도 모든 인프라 변경 사항을 감시할 수 있습니다. 원하는 상태 엔진이 자동화도 지원하는 경우 웹후크를 사용해 IaC 워크플로우를 트리거할 수 있습니다. 예를 들어, 시스템 관리자는 Red Hat Ansible Automation Platform과 같은 엔터프라이즈급의 원하는 상태 엔진과 함께 웹후크를 사용해 관리형 호스트에 최신 변경 사항을 자동으로 배포할 수 있습니다.

Red Hat® Ansible® Automation Platform에는 IaC 및 GitOps 사례를 지원하기 위해 오토메이션 웹후크가 내장되어 있습니다. 웹후크는 GitHub 또는 GitLab과 같은 서비스를 통해 Git 리포지토리를 Ansible Automation Platform과 네이티브 통합할 수 있도록 지원합니다. 리포지토리 링크가 설정되면 Ansible Automation Platform은 Git 시스템에서 Git 커밋을 포착하고, 이 이벤트를 사용해 자동화 작업을 트리거함으로써 프로젝트를 업데이트하고, 인벤토리를 관리하고, 배포를 수행합니다.

오토메이션 웹후크를 사용하면 소스 제어 시스템에 이벤트가 발생했을 때 자동화 워크플로우를 자동으로 활성화할 수 있습니다. 따라서 변경 사항 발생 시 리포지토리를 모니터링하고 자동화 작업을 시작하기 위한 추가 CI/CD 툴이 필요 없어 GitOps 워크플로우가 단순화되고 운영이 간소화됩니다. Red Hat Ansible Automation Platform은 다양한 개발 및 배포 툴과 연동되므로 GitOps 워크플로우를 선호하는 툴 및 프로세스에 맞춰 조정할 수 있습니다.