기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

# HTTP 인터셉터
<a name="interceptors"></a>

 인터셉터를 사용하여 API 요청 및 응답 실행에 연결할 수 있습니다. 인터셉터는 SDK가 요청/응답 수명 주기에 동작을 주입하기 위해 작성하는 코드를 호출하는 개방형 메커니즘입니다. 이 방법으로 진행 중인 요청 수정, 요청 처리 디버그, 예외 보기 등의 작업을 수행할 수 있습니다.

## 인터셉터와 미들웨어 비교
<a name="interceptors-vs-middleware"></a>

 AWS SDK for Go v2는 요청 처리를 사용자 지정하기 위한 인터셉터와 미들웨어를 모두 제공합니다. 둘 다 목적이 비슷하지만 다양한 대상과 사용 사례에 맞게 설계되었습니다.
+  **인터셉터**는 간단한 HTTP 중심 API를 사용하여 요청/응답 처리를 사용자 지정하려는 SDK 사용자를 위해 설계되었습니다. 요청 수명 주기에서 특정 후크 포인트를 제공하고 HTTP 요청 및 응답과 직접 작동합니다.
+  **미들웨어**는 전송에 구애받지 않는 고급 시스템으로, 주로 SDK에서 내부적으로 사용됩니다. 미들웨어는 강력하지만 SDK 내부 기능에 대한 심층적인 지식이 요구되며 더 복잡한 인터페이스가 필요합니다.

 일반적인 사용 사례에서 미들웨어 대비 인터셉터의 주요 이점은 다음과 같습니다.
+  **HTTP 중심**: 인터셉터는 HTTP 요청 및 응답에서 직접 작동하므로 미들웨어에 필요한 전송 유형을 확인할 필요가 없습니다.
+  **더 간단한 인터페이스**: 각 인터셉터 후크에는 일반 미들웨어 패턴이 아닌 특정 집중 인터페이스가 있습니다.
+  **더 명확한 실행 모델**: 인터셉터는 미들웨어 스택 주문에 대한 지식 없이 요청 수명 주기의 잘 정의된 지점에서 실행됩니다.

**참고**  
 인터셉터는 기존 미들웨어 시스템을 기반으로 구축되므로 둘 다 동일한 애플리케이션에서 공존할 수 있습니다. 미들웨어는 전송에 구애받지 않는 동작이나 복잡한 스택 조작이 필요한 고급 사용 사례에 계속 사용할 수 있습니다.

## 사용 가능한 인터셉터 후크
<a name="interceptor-hooks"></a>

 AWS SDK for Go v2는 요청 수명 주기의 다양한 단계에서 인터셉터 후크를 제공합니다. 각 후크는 구현할 수 있는 특정 인터페이스에 해당합니다.
+  `BeforeExecution` - 작업 실행 중에 직접 호출된 첫 번째 후크 
+  `BeforeSerialization` - 입력 메시지가 전송 요청으로 직렬화되기 전 
+  `AfterSerialization` - 입력 메시지가 전송 요청으로 직렬화된 후 
+  `BeforeRetryLoop` - 재시도 루프를 입력하기 전 
+  `BeforeAttempt` - 재시도 루프 내에서 직접 호출된 첫 번째 후크 
+  `BeforeSigning` - 전송 요청에 서명하기 전 
+  `AfterSigning` - 전송 요청에 서명한 후 
+  `BeforeTransmit` - 전송 요청이 전송되기 전 
+  `AfterTransmit` - 전송 응답을 수신한 후 
+  `BeforeDeserialization` - 전송 응답이 역직렬화되기 전 
+  `AfterDeserialization` - 전송 응답의 마샬링 해제 후 
+  `AfterAttempt` - 재시도 루프 내에서 직접 호출된 마지막 후크 
+  `AfterExecution` - 작업 실행 중에 직접 호출된 마지막 후크 

 단일 인터셉터에서 여러 인터페이스를 구현하여 요청 수명 주기의 여러 단계에 연결할 수 있습니다.

## 인터셉터 등록
<a name="interceptor-registration"></a>

 서비스 클라이언트를 구성하거나 특정 작업에 대한 구성을 재정의할 때 인터셉터를 등록합니다. 등록은 인터셉터를 클라이언트의 모든 작업에 적용할지 아니면 특정 작업에만 적용할지에 따라 달라집니다.

 인터셉터는 인터셉터를 추가 및 제거하는 방법을 제공하는 인터셉터 레지스트리를 통해 관리됩니다. 다음 예제는 서명 프로세스 전에 발신 요청에 AWS X-Ray 트레이스 ID 헤더를 추가하는 간단한 인터셉터를 보여줍니다.

```
type recursionDetection struct{}

func (recursionDetection) BeforeSigning(ctx context.Context, in *smithyhttp.InterceptorContext) error {
    if traceID := os.Getenv("_X_AMZN_TRACE_ID"); traceID != "" {
        in.Request.Header.Set("X-Amzn-Trace-Id", traceID)
    }
    return nil
}

// use it on the client
svc := s3.NewFromConfig(cfg, func(o *s3.Options) {
    o.Interceptors.AddBeforeSigning(recursionDetection{})
})
```

 인터셉터 레지스트리는 클라이언트 옵션에 추가되어 작업별 인터셉터 구성을 활성화합니다.

```
// ... or use it per-operation
s3.ListBuckets(context.Background(), &s3.ListBucketsInput{
}, func(o *s3.Options) {
   o.Interceptors.AddBeforeSigning(recursionDetection{})
})
```

## 글로벌 인터셉터 구성
<a name="interceptor-global-config"></a>

 각 인터셉터 유형에 적합한 `With*` 옵션과 함께 `config.LoadDefaultConfig` 함수를 사용하여 인터셉터를 전역적으로 등록할 수도 있습니다. 이렇게 하면 해당 구성에서 생성된 모든 AWS 서비스 클라이언트에 인터셉터가 적용됩니다.

```
type myExecutionInterceptor struct{}

func (*myExecutionInterceptor) AfterExecution(ctx context.Context, in *smithyhttp.InterceptorContext) error {
    // Add your custom logic here
    return nil
}

cfg, err := config.LoadDefaultConfig(context.Background(),
    config.WithAfterExecution(&myExecutionInterceptor{}))
if err != nil {
    panic(err)
}

// every service client created from the above config
// will include this interceptor
svc := s3.NewFromConfig(cfg)
```