Azure Logic Apps의 워크플로에서 외부 HTTP 또는 HTTPS 엔드포인트 호출

적용 대상: Azure Logic Apps(사용량 + 표준)

일부 시나리오에서는 HTTP 또는 HTTPS를 통해 다른 서비스 또는 시스템의 엔드포인트에 아웃바운드 요청을 보내는 논리 앱 워크플로를 만들어야 할 수 있습니다. 예를 들어 특정 일정에 따라 해당 엔드포인트를 확인하여 웹 사이트의 서비스 엔드포인트를 모니터링하려는 경우를 가정해 보겠습니다. 웹 사이트 가동 중단과 같은 특정 이벤트가 해당 엔드포인트에서 발생하면 해당 이벤트는 워크플로를 트리거하고 해당 워크플로에서 작업을 실행합니다.

비고

대신 인바운드 HTTPS 호출을 수신하고 응답하는 워크플로를 만들려면 Azure Logic Apps에서 HTTPS 엔드포인트를 사용하여 호출, 트리거 또는 중첩할 수 있는 워크플로 만들기를 참조하세요. 요청 기본 제공 트리거를 사용하려면 Azure Logic Apps의 워크플로에 대한 인바운드 HTTPS 호출 수신 및 응답을 참조하세요.

이 가이드에서는 워크플로가 다른 서비스 및 시스템에 아웃바운드 호출을 보낼 수 있도록 HTTP 트리거 및 HTTP 작업을 사용하는 방법을 보여 줍니다. 예를 들면 다음과 같습니다.

되풀이 일정에 따라 엔드포인트를 확인하거나 폴링하려면 워크플로의 첫 번째 단계로 HTTP라는 기본 제공 트리거를 추가합니다. 트리거가 엔드포인트를 검사할 때마다 트리거는 엔드포인트를 호출하거나 요청을 보냅니다. 엔드포인트의 응답은 워크플로가 실행되는지 여부를 결정합니다. 트리거는 엔드포인트 응답의 모든 콘텐츠를 워크플로의 작업에 전달합니다.
워크플로의 다른 위치에서 엔드포인트를 호출하려면 HTTP라는 기본 제공 작업을 추가합니다. 엔드포인트의 응답은 워크플로의 나머지 작업을 실행하는 방법을 결정합니다.

필수 조건

Azure 계정 및 구독 Azure 구독이 없는 경우 체험 Azure 계정에 등록합니다.
호출하려는 대상 엔드포인트의 URL입니다.
외부 엔드포인트를 호출하려는 워크플로가 있는 논리 앱 리소스입니다.

HTTP 트리거를 사용하여 워크플로를 시작하려면 빈 워크플로가 있어야 합니다. HTTP 작업을 사용하기 위해 워크플로는 시나리오에 가장 적합한 트리거로 시작할 수 있습니다. 이 문서의 예제 워크플로는 HTTP 트리거를 사용합니다.

논리 앱 리소스 및 워크플로가 없는 경우 원하는 논리 앱에 대한 단계를 수행하여 지금 만듭니다.
- 소비 논리 앱 워크플로 예 만들기
- 예제 표준 논리 앱 워크플로 만들기

커넥터 기술 참조

트리거 및 작업 매개 변수에 대한 기술 정보는 스키마 참조 가이드의 다음 섹션을 참조하세요.

HTTP 트리거 추가

이 기본 제공 트리거는 엔드포인트에 대해 지정된 URL에 대한 HTTP 호출을 수행하고 응답을 반환합니다.

표준
소비

Azure Portal에서 표준 논리 앱 리소스를 엽니다.
리소스 사이드바 메뉴의 워크플로에서 워크플로를 선택한 다음 빈 워크플로를 선택합니다.
워크플로 사이드바 메뉴의 도구에서 디자이너를 선택하여 워크플로를 엽니다.
트리거를 추가하는 일반적인 단계에 따라 HTTP 기본 제공 트리거를 워크플로에 추가합니다.

이 예제에서는 트리거의 이름을 HTTP 트리거 - 호출 엔드포인트 URL 로 변경하여 트리거에 보다 설명적인 이름을 지정합니다. 또한 이 예제는 나중에 HTTP 작업을 추가하고 워크플로의 작업 이름은 고유해야 합니다.
대상 엔드포인트 호출에 포함하려는 HTTP 트리거 매개 변수 에 대한 값을 제공합니다. 트리거가 대상 엔드포인트를 확인하는 빈도에 대해 되풀이를 설정합니다.
고급 매개 변수 목록에서 인증을 선택합니다.

None 이외의 인증 유형을 선택하는 경우 인증 설정은 선택한 항목에 따라 다릅니다. HTTP에 사용할 수 있는 인증 유형에 대한 자세한 내용은 다음 문서를 참조하세요.
- 아웃바운드 호출에 인증 추가
- 관리 ID를 사용하여 리소스에 대한 액세스 인증
트리거가 실행되면 실행할 다른 작업을 추가합니다.
완료되면 워크플로를 저장합니다. 디자이너 도구 모음에서 저장을 선택합니다.

HTTP 작업 추가

이 기본 제공 작업은 HTTPS 또는 HTTP 호출을 엔드포인트의 지정된 URL로 보내고 응답과 함께 반환합니다.

표준
소비

Azure Portal에서 표준 논리 앱 리소스를 엽니다.
리소스 사이드바 메뉴의 워크플로에서 워크플로를 선택한 다음 워크플로를 선택합니다.
워크플로 사이드바 메뉴의 도구에서 디자이너를 선택하여 워크플로를 엽니다.

이 예제에서는 이전 섹션에 추가된 HTTP 트리거를 사용합니다.
작업을 추가하는 일반적인 단계에 따라 워크플로에 HTTP 기본 제공 작업을 추가합니다.

이 예제에서는 작업의 이름을 HTTP 작업- 호출 엔드포인트 URL 로 바꿔서 작업에 보다 설명적인 이름을 지정합니다. 또한 워크플로의 작업 이름은 고유해야 합니다.
대상 엔드포인트에 대한 호출에 포함하려는 HTTP 작업 매개 변수 의 값을 제공합니다.
고급 매개 변수 목록에서 인증을 선택합니다.

None 이외의 인증 유형을 선택하는 경우 인증 설정은 선택한 항목에 따라 다릅니다. HTTP에 사용할 수 있는 인증 유형에 대한 자세한 내용은 다음 문서를 참조하세요.
- 아웃바운드 호출에 인증 추가
- 관리 ID를 사용하여 리소스에 대한 액세스 인증
트리거가 실행되면 실행할 다른 작업을 추가합니다.
완료되면 워크플로를 저장합니다. 디자이너 도구 모음에서 저장을 선택합니다.

트리거 및 작업 출력

HTTP 트리거 또는 작업은 다음 정보를 출력합니다.

재산	유형	설명
`headers`	JSON 개체	요청의 헤더
`body`	JSON 개체	요청의 본문 콘텐츠가 포함된 개체
`status code`	정수	요청의 상태 코드

상태 코드	설명
200	그래
202	수락됨
400	잘못된 요청
401	권한 없음
403	금지
404	찾을 수 없음
500	내부 서버 오류. 알 수 없는 오류 발생.

아웃바운드 호출에 대한 URL 보안

TLS(전송 계층 보안), 자체 서명된 인증서 또는 Microsoft Entra ID Open Authentication과 같은 워크플로의 아웃바운드 호출에 대한 암호화, 보안 및 권한 부여에 대한 자세한 내용은 다른 서비스 및 시스템에 대한 아웃바운드 호출에 대한 액세스를 참조하세요.

단일 테넌트 환경에 대한 인증

단일 테넌트 Azure Logic Apps에 표준 논리 앱 리소스가 있고 다음 인증 유형 중 하나와 함께 HTTP 작업을 사용하려는 경우 해당 인증 유형에 대한 추가 설정 단계를 완료해야 합니다. 그러지 않으면 호출이 실패합니다.

TLS 인증서: 앱 설정을 WEBSITE_LOAD_ROOT_CERTIFICATES추가하고 TLS 인증서의 지문에 값을 설정합니다.
인증서 자격 증명 유형을 사용하는 클라이언트 인증서 또는 Microsoft Entra ID Open Authentication(Microsoft Entra ID OAuth): 앱 설정을 WEBSITE_LOAD_USER_PROFILE추가하고 값을 1로 설정합니다.

TLS 인증서 인증

논리 앱 리소스의 앱 설정에서 WEBSITE_LOAD_ROOT_CERTIFICATES이라는 앱 설정을 추가하거나 업데이트합니다. 특정 단계는 앱 설정 관리 - local.settings.json.를 참조하세요.
설정 값의 경우 TLS 인증서의 지문을 신뢰할 루트 인증서로 제공합니다.

"WEBSITE_LOAD_ROOT_CERTIFICATES": "<thumbprint-for-TLS-certificate>"

예를 들어 Visual Studio Code에서 작업하는 경우 다음 단계를 수행합니다.

논리 앱 프로젝트의 local.settings.json 파일을 엽니다.

ValuesJSON 개체에서 설정을 추가하거나 업데이트WEBSITE_LOAD_ROOT_CERTIFICATES합니다.

{
   "IsEncrypted": false,
   "Values": {
      <...>
      "AzureWebJobsStorage": "UseDevelopmentStorage=true",
      "WEBSITE_LOAD_ROOT_CERTIFICATES": "<thumbprint-for-TLS-certificate>",
      <...>
   }
}

비고

지문을 찾으려면 다음 단계를 수행합니다.

논리 앱 리소스 메뉴의 설정에서 인증서를 선택합니다.
직접 제공하는 인증서(.pfx) 또는 공개 키 인증서(.cer)를 선택하세요.
사용할 인증서를 찾고 지문을 복사합니다.

자세한 내용은 지문 찾기 - Azure App Service를 확인하세요.

자세한 내용은 앱 설정 관리 - local.settings.json.를 참조하세요.

클라이언트 인증서 또는 Microsoft Entra ID OAuth를 인증서 자격 증명 유형으로 인증합니다.

논리 앱 리소스의 앱 설정에서 WEBSITE_LOAD_USER_PROFILE이라는 앱 설정을 추가하거나 업데이트합니다. 특정 단계는 앱 설정 관리를 참조하세요. - local.settings.json
설정 값에 대해 1를 입력합니다.

"WEBSITE_LOAD_USER_PROFILE": "1"

예를 들어 Visual Studio Code에서 작업하는 경우 다음 단계를 수행합니다.

논리 앱 프로젝트의 local.settings.json 파일을 엽니다.

ValuesJSON 개체에서 설정을 추가하거나 업데이트WEBSITE_LOAD_USER_PROFILE합니다.

{
   "IsEncrypted": false,
   "Values": {
      <...>
      "AzureWebJobsStorage": "UseDevelopmentStorage=true",
      "WEBSITE_LOAD_USER_PROFILE": "1",
      <...>
   }
}

Azure Portal에서 작업하는 경우 논리 앱을 엽니다. 사이드바 메뉴의 설정 에서 환경 변수를 선택합니다. 앱 설정에서 설정을 추가하거나 편집합니다.

다중 파트/양식 데이터 형식의 콘텐츠

HTTP 요청에서 multipart/form-data 유형의 콘텐츠를 처리하려면, 이 형식을 사용하여 HTTP 요청 본문에 $content-type 및 $multipart 특성을 포함하는 JSON 객체를 추가할 수 있습니다.

"body": {
   "$content-type": "multipart/form-data",
   "$multipart": [
      {
         "body": "<output-from-trigger-or-previous-action>",
         "headers": {
            "Content-Disposition": "form-data; name=file; filename=<file-name>"
         }
      }
   ]
}

예를 들어, Excel 파일을 multipart/form-data 형식으로 지원하는 해당 사이트의 API를 사용하여 웹사이트에 HTTP POST 요청을 보내는 워크플로가 있다고 가정해 보겠습니다. 다음 샘플에서는 이 작업이 표시되는 방법을 보여 줍니다.

기본 워크플로 정의에서 HTTP 작업의 JSON 정의를 보여 주는 동일한 예제는 다음과 같습니다.

"HTTP_action": {
   "inputs": {
      "body": {
         "$content-type": "multipart/form-data",
         "$multipart": [
            {
               "body": "@trigger()",
               "headers": {
                  "Content-Disposition": "form-data; name=file; filename=myExcelFile.xlsx"
               }
            }
         ]
      },
      "method": "POST",
      "uri": "https://finance.contoso.com"
   },
   "runAfter": {},
   "type": "Http"
}

application/x-www-form-urlencoded 형식의 콘텐츠

HTTP 요청에 대해 form-urlencoded 데이터를 본문에 제공하려면 application/x-www-form-urlencoded 콘텐츠 형식을 포함하는 데이터를 지정해야 합니다. HTTP 트리거 또는 작업에서 헤더를 추가합니다 content-type . 헤더 값을 .로 application/x-www-form-urlencoded설정합니다.

예를 들어, application/x-www-form-urlencoded 형식을 지원하는 웹 사이트에 HTTP POST 요청을 보내는 논리 앱이 있다고 가정해 보겠습니다. 이 작업은 다음과 같이 보일 수 있습니다.

비동기 요청-응답 동작

다중 테넌트 및 단일 테넌트 Azure Logic Apps의 상태 저장 워크플로의 경우 모든 HTTP 기반 작업은 표준 비동기 작업 패턴을 기본 동작으로 따릅니다. 이 패턴은 HTTP 작업이 엔드포인트, 서비스, 시스템 또는 API에 요청을 호출하거나 보낸 후 수신자가 즉시 202 ACCEPTED 응답을 반환하도록 지정합니다. 이 코드는 수신기가 요청을 수락했지만 처리가 완료되지 않았음을 확인합니다. 응답에는 수신자가 처리를 중지하고 location 성공 응답 또는 기타 비 202 응답을 반환할 때까지 호출자가 비동기 요청을 폴링하거나 확인하는 데 사용할 수 있는 URI 및 새로 고침 ID를 지정하는 헤더가 포함될 수 있습니다. 하지만 호출자가 요청 처리가 완료될 때까지 기다릴 필요가 없고 계속 다음 작업을 실행할 수 있습니다. 자세한 내용은 동기 및 비동기 메시징을 참조하세요.

단일 테넌트 Azure Logic Apps의 상태 비스테이스 워크플로의 경우 HTTP 기반 작업은 비동기 작업 패턴을 사용하지 않습니다. 대신 동기적으로만 실행하고, 202 ACCEPTED 응답 as-is반환하고, 워크플로 실행의 다음 단계로 진행합니다. 응답에 헤더가 location 포함된 경우 상태 없는 워크플로는 지정된 URI를 폴링하여 상태를 확인하지 않습니다. 표준 비동기 작업 패턴을 따르려면 상태 저장 워크플로를 대신 사용합니다.

HTTP 작업의 기본 JSON 정의는 비동기 작업 패턴을 암시적으로 따릅니다.
트리거가 아닌 HTTP 작업에는 기본적으로 사용하도록 설정되는 비동기 패턴 설정이 있습니다. 이 설정은 호출자가 처리가 완료될 때까지 기다리지 않고 다음 작업으로 이동할 수 있지만 처리가 중지될 때까지 상태를 계속 확인하도록 지정합니다. 이 설정이 사용하지 않도록 설정되면 호출자에서 처리가 완료될 때까지 기다린 후에 다음 작업으로 이동하도록 지정합니다.

비동기 패턴 설정을 찾으려면 다음을 수행합니다.
1. 워크플로 디자이너에서 HTTP 작업을 선택합니다.
2. 열리는 정보 창에서 설정을 선택합니다.
3. 네트워킹 아래에서 비동기 패턴 설정을 찾습니다.

비동기 작업 사용 안 함

예를 들어 다음과 같은 특정 시나리오에서 HTTP 동작의 비동기 동작을 사용하지 않도록 설정할 수 있습니다.

장기 실행 작업에 대한 HTTP 시간 제한 방지
위치 헤더 확인을 사용하지 않도록 설정

비동기 패턴 설정 끄기

워크플로 디자이너에서 HTTP 작업을 선택하고 열리는 정보 창에서 설정을 선택합니다.
네트워킹 아래에서 비동기 패턴 설정을 찾습니다. 설정된 경우 설정을 끄 기로 설정합니다.

작업의 JSON 정의에서 비동기 패턴을 사용하지 않도록 설정

HTTP 작업의 기본 JSON 정의에서 작업 정의에 작업 옵션을 추가하여 DisableAsyncPattern 작업이 동기 작업 패턴을 대신 따르도록 합니다. 자세한 내용은 동기 작업 패턴의 작업 실행도 참조하세요.

장기 실행 작업에 대한 HTTP 시간 제한 방지

HTTP 요청에는 시간 제한 제한이 있습니다. 이 제한으로 인해 시간이 초과되는 장기 실행 HTTP 작업이 있는 경우 다음 옵션이 있습니다.

작업이 요청 상태를 지속적으로 폴링하거나 확인하지 않도록 HTTP 작업의 비동기 작업 패턴을 사용하지 않도록 설정합니다. 대신 작업은 요청이 처리를 완료한 후 수신기가 상태 및 결과로 응답할 때까지 기다립니다.
HTTP 동작을 HTTP 웹후크 작업으로 바꿉니다. 이 작업은 요청이 처리를 완료한 후 수신기가 상태 및 결과로 응답할 때까지 기다립니다.

Retry-After 헤더를 사용하여 다시 시도 간 간격 설정

재시도 사이의 시간(초)을 지정하려면 HTTP 작업 응답에 Retry-After 헤더를 추가할 수 있습니다. 예를 들어 대상 엔드포인트가 상태 코드를 반환하는 429 - Too many requests 경우 재시도 사이에 더 긴 간격을 지정할 수 있습니다. Retry-After 헤더는 202 - Accepted 상태 코드와도 작동합니다.

다음은 다음을 포함하는 HTTP 작업 응답을 보여 주는 동일한 예제입니다.Retry-After

{
    "statusCode": 429,
    "headers": {
        "Retry-After": "300"
    }
}

페이지 매김 지원

경우에 따라 대상 서비스는 결과를 한 번에 한 페이지씩 반환하여 응답합니다. 응답이 nextLink 또는 @odata.nextLink 속성으로 다음 페이지를 지정하는 경우, HTTP 작업에서 페이지네이션 설정을 켤 수 있습니다. 이 설정을 사용하면 HTTP 작업이 자동으로 이러한 링크를 따라 다음 페이지를 가져옵니다. 그러나 응답이 다른 태그가 있는 다음 페이지를 지정하는 경우 워크플로에 루프를 추가해야 할 수 있습니다. 이 루프가 해당 태그를 따르고 태그가 null이 될 때까지 각 페이지를 수동으로 가져옵니다.

위치 헤더 확인 사용 안 함

일부 엔드포인트, 서비스, 시스템 또는 API는 202 ACCEPTED 헤더가 없는 location 응답을 반환합니다. 헤더가 없을 때 location HTTP 작업이 요청 상태를 지속적으로 확인하지 않도록 하려면 다음 옵션을 사용할 수 있습니다.

작업이 요청 상태를 지속적으로 폴링하거나 확인하지 않도록 HTTP 작업의 비동기 작업 패턴을 사용하지 않도록 설정합니다. 대신 작업은 요청이 처리를 완료한 후 수신기가 상태 및 결과로 응답할 때까지 기다립니다.
HTTP 동작을 HTTP 웹후크 작업으로 바꿉니다. 이 작업은 요청이 처리를 완료한 후 수신기가 상태 및 결과로 응답할 때까지 기다립니다.

알려진 문제

생략된 HTTP 헤더

HTTP 트리거 또는 작업에 이러한 헤더가 포함된 경우 Azure Logic Apps는 경고 또는 오류를 표시하지 않고 생성된 요청 메시지에서 이러한 헤더를 제거합니다.

Accept-*을 제외한 Accept-version 헤더
Allow
Content-*, Content-Disposition 및 Content-Encoding을 제외한 Content-Type 헤더이며, POST 및 PUT 작업을 사용할 때 적용됩니다. 그러나 Azure Logic Apps는 GET 작업을 사용할 때 이러한 헤더를 삭제합니다.
Cookie 헤더이지만, Azure Logic Apps는 Cookie 속성으로 지정한 값을 그대로 적용합니다.
Expires
Host
Last-Modified
Origin
Set-Cookie
Transfer-Encoding

Azure Logic Apps에서 HTTP 트리거 또는 동작을 사용하는 논리 앱을 이러한 헤더와 함께 저장하는 것을 막지는 못하지만 Azure Logic Apps는 이러한 헤더를 무시합니다.

응답 콘텐츠가 예상 콘텐츠 형식과 일치하지 않음

HTTP 동작은 헤더가 애플리케이션/json으로 Content-Type 설정된 백 엔드 API를 호출하지만 백 엔드의 응답에 실제로 JSON 형식의 콘텐츠가 포함되어 있지 않아 내부 JSON 형식 유효성 검사가 실패하는 경우 BadRequest 오류가 발생합니다.

피드백

이 페이지가 도움이 되었나요?

Last updated on 2025-07-23