# API Gateway에서 응답 스트리밍 관련 문제 해결
다음 문제 해결 지침은 응답 스트리밍을 사용하는 API 문제를 해결하는 데 도움이 될 수 있습니다.
## 일반 문제 해결
[TestInvokeMethod](https://docs.aws.amazon.com/apigateway/latest/api/API_TestInvokeMethod.html) 또는 콘솔의 테스트 탭을 사용하여 스트림 응답을 테스트할 수 있습니다. 다음 고려 사항은 응답 스트리밍을 위한 테스트 간접 호출 사용에 영향을 미칠 수 있습니다.
+ 메서드를 테스트하면 API Gateway가 스트리밍된 응답 페이로드를 버퍼링합니다. 다음 조건 중 하나라도 충족되면 API Gateway는 버퍼링된 페이로드를 포함하는 일회성 응답을 반환합니다.
+ 요청이 완료됨
+ 35초 경과
+ 1MB 이상의 응답 페이로드가 버퍼링되었습니다.
+ 메서드가 HTTP 응답 상태와 모든 헤더를 반환하기 전에 35초 이상이 경과하면 TestInvokeMethod에서 반환된 응답 상태는 0입니다.
+ API Gateway는 실행 로그를 생성하지 않습니다.
API를 배포한 후 curl 명령을 사용하여 스트림 응답을 테스트할 수 있습니다. `-i` 옵션을 사용하여 출력에 프로토콜 응답 헤더를 포함하는 것이 좋습니다. 응답 데이터가 도착하면 보려면 curl 옵션 `--no-buffer`를 사용합니다.
## cURL 오류 해결
통합을 테스트 중이고 `curl: (18) transfer closed with outstanding read data remaining` 오류가 발생하는 경우 통합 제한 시간이 충분히 긴지 확인합니다. Lambda 함수를 사용하는 경우 Lambda 함수의 응답 제한 시간을 업데이트해야 합니다. 자세한 내용은 [Lambda 함수 제한 시간 구성](https://docs.aws.amazon.com/lambda/latest/dg/configuration-timeout.html)을 참조하세요.
## 액세스 로깅 사용 문제 해결
REST API 스테이지에 대한 액세스 로그를 사용하여 응답 스트림을 로깅하고 문제를 해결할 수 있습니다. 기존 변수 외에도 다음 액세스 로그 변수를 사용할 수 있습니다.
`$context.integration.responseTransferMode`
통합의 응답 전송 모드입니다. 이는 `BUFFERED` 또는 `STREAMED`일 수 있습니다.
`$context.integration.timeToAllHeaders`
API Gateway가 통합 연결을 설정하는 시점부터 클라이언트로부터 모든 통합 응답 헤더를 수신하는 시점까지의 시간입니다.
`$context.integration.timeToFirstContent`
API Gateway가 통합 연결을 설정하는 시점부터 첫 번째 콘텐츠 바이트를 수신하는 시점까지의 시간입니다.
`$context.integration.latency` 또는 `$context.integrationLatency`
API Gateway가 통합 연결을 설정하는 시간부터 통합 응답 스트림이 완료되는 시간까지입니다.
다음 그림은 이러한 액세스 로그 변수가 응답 스트림의 다양한 구성 요소를 나타내는 방법을 보여 줍니다.
![\[API Gateway에서 응답 스트리밍을 위한 액세스 로그 변수\]](http://docs.aws.amazon.com/ko_kr/apigateway/latest/developerguide/images/response-streaming-figure.png)
액세스 로그에 대한 자세한 내용은 [API Gateway에서 REST API에 대한 CloudWatch 로깅 설정](set-up-logging.md) 단원을 참조하십시오. X-Ray를 사용하여 응답 스트림을 모니터링할 수도 있습니다. 자세한 내용은 [API Gateway에서 X-Ray를 사용하여 REST API에 대한 사용자 요청 추적](apigateway-xray.md) 섹션을 참조하세요.