# 웹후크 사용에 대한 모범 사례

웹후크를 사용할 때 보안 및 성능을 향상시키려면 다음 모범 사례를 따릅니다.

## 최소 이벤트 수 구독

필요한 웹후크 이벤트만 구독해야 합니다. 그러면 서버에서 수행해야 하는 작업의 양이 줄어듭니다. 이벤트 구독에 대한 자세한 내용은 [웹후크 만들기](/ko/webhooks/creating-webhooks) 및 [웹후크 편집하기](/ko/webhooks/using-webhooks/editing-webhooks)을(를) 참조하세요.

## 웹후크 비밀 사용

> \[!WARNING]
> 중요한 정보가 실수로 노출되지 않도록 하려면 페이로드 URL에 중요한 정보를 포함하지 **않도록** 주의하세요.
> 여기에는 사용자 고유의 API 키 및 기타 인증 자격 증명이 포함됩니다. 대신, GitHub에서 웹훅 전송이 제대로 이루어졌고 변조되지 않았음을 검증하려면 웹훅 비밀을 사용하세요. 자세한 내용은 [웹후크 제공 유효성 검사하기](/ko/webhooks/using-webhooks/validating-webhook-deliveries)을(를) 참조하세요.

웹후크 비밀은 엔트로피가 높은 임의의 텍스트 문자열이어야 합니다. 서버에서 액세스할 수 있는 방식으로 웹후크 비밀을 안전하게 저장해야 합니다.

## HTTPS 및 SSL 확인 사용

서버에서 HTTPS 연결을 사용하는지 확인해야 합니다. 기본적으로 GitHub 웹후크를 배달할 때 SSL 인증서를 확인합니다.
GitHub 는 SSL 확인을 활성화된 상태로 유지할 것을 권장합니다.

##

```
          GitHub'의 IP 주소 허용
```

서버에 대한 IP 허용 목록을 설정하고 웹후크 배달에 사용하는 IP 주소를 GitHub 추가할 수 있습니다. 이를 통해 서버에 대한 스푸핑된 요청을 차단할 수 있습니다.

```
          `GET /meta` 엔드포인트를 사용하여 GitHub의 현재 IP 주소 목록을 찾을 수 있습니다. 자세한 내용은 [AUTOTITLE](/rest/meta/meta#get-github-meta-information)을(를) 참조하세요. 
          GitHub IP 주소를 가끔 변경하므로 IP 허용 목록을 주기적으로 업데이트해야 합니다.
```

자세한 내용은 [GitHub IP 주소 정보](/ko/authentication/keeping-your-account-and-data-secure/about-githubs-ip-addresses)을(를) 참조하세요.

##

```
          1030초 이내에 응답
```

서버는 웹후크 배달을 받은 후 10 302XX 응답으로 응답해야 합니다. 서버가 응답하는 데 시간이 오래 걸리면 GitHub 연결을 종료하고 이로 인해 배달이 실패한 것으로 간주합니다.

적시에 응답하기 위해 웹후크 페이로드를 비동기적으로 처리하도록 큐를 설정할 수 있습니다. 서버는 웹후크를 받을 때 응답한 다음 이후 웹후크 제공을 차단하지 않고 백그라운드에서 페이로드를 처리할 수 있습니다. 예를 들어 [Hookdeck](https://hookdeck.com) 같은 서비스 또는 [Resque](https://github.com/resque/resque/)(Ruby)와 같은 라이브러리를 사용할 수 있습니다. ), [RQ](http://python-rq.org/)(Python) 또는 [RabbitMQ](http://www.rabbitmq.com/)(Java).

## 이벤트를 처리하기 전에 이벤트 유형 및 작업 확인

여러 가지 웹후크 이벤트 유형이 있으며, 많은 이벤트에 다양한 작업 유형이 있을 수 있습니다.
GitHub 에서는 기존 이벤트 형식에 새 이벤트 유형 및 새 작업을 계속 추가합니다. 애플리케이션은 페이로드를 처리하기 전에 웹후크 페이로드의 이벤트 유형 및 작업을 확인합니다. 이벤트 유형을 확인하려면 `X-GitHub-Event` 요청 헤더를 사용할 수 있습니다. 작업 유형을 확인하기 위해 이벤트 페이로드에서 최상위 `action` 키를 사용할 수 있습니다.

## 누락된 제공 다시 제공하기

서버가 다운된 경우 서버가 백업되면 누락된 웹후크를 다시 제공해야 합니다. 자세한 내용은 [웹후크 다시 제공](/ko/webhooks/testing-and-troubleshooting-webhooks/redelivering-webhooks)을(를) 참조하세요.

##

```
          `X-GitHub-Delivery` 헤더 사용
```

리플레이 공격에서는 악의적인 주체가 웹후크 전송을 가로채 해당 전송을 다시 보냅니다. 재생 공격으로부터 보호하기 위해 `X-GitHub-Delivery` 헤더를 사용하여 각 배달이 이벤트별로 고유하도록 할 수 있습니다.

> \[!NOTE]
> 다시 배달을 요청하는 경우 `X-GitHub-Delivery` 헤더는 원래 배달과 동일합니다.

## 추가 참고 자료

* [REST API 사용에 대한 모범 사례](/ko/rest/guides/best-practices-for-integrators)
* [GitHub 앱을 만들기 위한 모범 사례](/ko/apps/creating-github-apps/about-creating-github-apps/best-practices-for-creating-a-github-app)