Azure Logic Apps에서 워크플로로 전송된 인바운드 HTTPS 호출 수신 및 응답

2025-07-23

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

이 가이드에서는 요청 기본 제공 트리거를 사용하여 다른 서비스에서 인바운드 HTTPS 요청을 수신하고 처리할 수 있는 논리 앱 워크플로를 만드는 방법을 보여 줍니다. 워크플로에서 이 트리거를 사용하는 경우 워크플로는 응답 기본 제공 작업을 사용하여 HTTPS 호출에 응답할 수 있습니다.

참고

응답 작업은 요청 트리거를 사용하는 경우에만 작동합니다.

예를 들어 요청 트리거 및 응답 작업을 사용할 때 워크플로에서 다음 작업을 수행할 수 있습니다.

온-프레미스 데이터베이스에서 데이터에 대한 HTTPS 요청을 수신하고 응답합니다.
다른 논리 앱 워크플로에서 전송된 HTTPS 요청을 수신하고 응답합니다.
외부 웹후크 이벤트가 발생하는 경우 워크플로 실행을 트리거합니다.

대신 나가는 또는 아웃바운드 요청을 전송하여 워크플로를 실행하려면 HTTP 기본 제공 트리거 또는 HTTP 기본 제공 작업을 사용합니다.

필수 구성 요소

Azure 계정 및 구독 구독이 없는 경우 Azure 체험 계정에 가입할 수 있습니다.

인바운드 HTTPS 요청을 수신하려는 워크플로가 있는 논리 앱 리소스입니다.

요청 트리거를 사용하여 워크플로를 시작하려면 빈 워크플로가 있어야 합니다. 응답 작업을 사용하려면 워크플로가 요청 트리거로 시작해야 합니다.

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

솔루션을 테스트하기 위해 HTTP 요청을 보낼 수 있는 도구를 설치하거나 사용합니다. 예를 들면 다음과 같습니다.
주의

자격 증명, 비밀, 액세스 토큰, API 키 및 기타 유사한 정보와 같은 중요한 데이터가 있는 시나리오의 경우 필요한 보안 기능으로 데이터를 보호하는 도구를 사용해야 합니다. 이 도구는 오프라인 또는 로컬로 작동하며 온라인 계정에 로그인하거나 데이터를 클라우드에 동기화할 필요가 없습니다. 이러한 특성을 가진 도구를 사용하면 중요한 데이터를 대중에게 노출할 위험을 줄일 수 있습니다.

요청 트리거 추가

요청 트리거는 HTTPS를 통한 인바운드 요청만 처리하는 수동으로 호출 가능한 엔드포인트를 만듭니다. 호출자가 이 엔드포인트에 요청을 보내면 요청 트리거가 발생하고 워크플로가 실행됩니다. 이 트리거를 호출하는 방법에 대한 자세한 내용은 Azure Logic Apps에서 HTTPS 엔드포인트를 사용하여 워크플로 호출, 트리거 또는 중첩을 참조하세요.

사용량
표준

Azure Portal에서 소비 논리 앱 리소스를 엽니다.
사이드바 메뉴의 개발 도구에서 디자이너를 선택하여 빈 워크플로를 엽니다.
워크플로에 요청 기본 제공 트리거인 HTTP 요청을 받을 때를 추가하려면 트리거를 추가하는 일반적인 단계를 따르십시오.

트리거 정보 상자가 나타나면 다음 정보를 제공합니다.

속성 이름	JSON 속성 이름	필수	설명
HTTP URL	{없음}	예	워크플로를 저장한 후 생성되고 워크플로를 트리거하는 요청을 보내는 데 사용되는 엔드포인트 URL입니다.
요청 본문 JSON 스키마	`schema`	아니요	들어오는 요청 본문의 속성 및 값을 설명하는 JSON 스키마입니다. 디자이너는 이 스키마를 사용하여 요청에서 속성에 대한 토큰을 생성합니다. 이렇게 하면 워크플로가 요청 트리거의 출력을 구문 분석하고, 사용하고, 워크플로로 전달할 수 있습니다. JSON 스키마가 없을 경우 샘플 페이로드를 사용하여 스키마 생성 기능을 사용하여 샘플 페이로드에서 스키마를 생성할 수 있습니다.

다음 예제에서는 샘플 JSON 스키마를 보여 줍니다.

다음 예제에서는 전체 샘플 JSON 스키마를 보여 줍니다.

{
   "type": "object",
   "properties": {
      "account": {
         "type": "object",
         "properties": {
            "name": {
               "type": "string"
            },
            "ID": {
               "type": "string"
            },
            "address": {
               "type": "object",
               "properties": {
                  "number": {
                     "type": "string"
                  },
                  "street": {
                     "type": "string"
                  },
                  "city": {
                     "type": "string"
                  },
                  "state": {
                     "type": "string"
                  },
                  "country": {
                     "type": "string"
                  },
                  "postalCode": {
                     "type": "string"
                  }
               }
            }
         }
      }
   }
}

JSON 스키마를 입력하면 디자이너가 요청에 Content-Type 헤더를 포함하고 해당 헤더 값을 application/json로 설정하라는 미리 알림을 표시할 수 있습니다. 자세한 내용은 콘텐츠 유형 처리를 참조하세요.

다음 예제에서는 헤더가 Content-Type JSON 형식으로 표시되는 방법을 보여 줍니다.

{
   "Content-Type": "application/json"
}

예상 페이로드(데이터)를 기반으로 하는 JSON 스키마를 생성하려면 json-schema.org 같은 도구를 사용하거나 다음 단계를 수행할 수 있습니다.

요청 트리거에서 샘플 페이로드를 사용하여 스키마 생성을 선택합니다.

샘플 페이로드를 입력하고 완료를 선택합니다.

다음 예제에서는 샘플 페이로드를 보여 줍니다.

{
   "account": {
      "name": "Contoso",
      "ID": "12345",
      "address": {
         "number": "1234",
         "street": "Anywhere Street",
         "city": "AnyTown",
         "state": "AnyState",
         "country": "USA",
         "postalCode": "11111"
      }
   }
}

인바운드 호출에 특정 스키마와 일치하는 요청 본문이 있는지 확인하려면 다음 단계를 수행합니다.
1. 인바운드 메시지가 스키마에서 설명하는 것과 동일한 필드를 갖도록 하려면 스키마에서 required 속성을 추가하고 필수 필드를 지정합니다. additionalProperties 속성을 추가하고 값을 false로 설정합니다.
  
  예를 들어 다음 스키마는 인바운드 메시지에 다른 필드가 아닌 msg 필드가 있어야 한다고 지정합니다.
```
{
   "properties": {
     "msg": {
        "type": "string"
     }
   },
   "type": "object",
   "required": ["msg"],
   "additionalProperties": false
}
```
2. 디자이너에서 요청 트리거를 선택합니다. 열리는 정보 창에서 설정 탭을 선택합니다.
3. 데이터 처리를 확장하고 스키마 유효성 검사를 켜기로 설정합니다.
  
  인바운드 호출의 요청 본문이 스키마와 일치하지 않는 경우 트리거가 HTTP 400 잘못된 요청 오류를 반환합니다.
메서드 목록에서 트리거에서 인바운드 요청이 사용할 것으로 예상되는 메서드를 선택합니다.
트리거에 대한 다른 매개 변수가 있는 경우 고급 매개 변수 목록을 열고 원하는 매개 변수를 선택합니다.
준비되면 워크플로를 저장합니다. 디자이너 도구 모음에서 저장을 선택합니다.

이 단계에서는 워크플로를 트리거하는 요청을 전송하는 데 사용할 수 있는 URL을 생성합니다.
생성된 URL을 복사하려면 URL 옆에 있는 복사 아이콘을 선택합니다.

참고

요청 트리거를 호출할 때 URI에 해시 또는 파운드 기호(#)를 포함하고자 하는 경우 대신 인코딩된 버전(%25%23)을 사용합니다.

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

트리거 정보 상자가 나타나면 필요에 따라 다음 정보를 제공합니다.

속성 이름	JSON 속성 이름	필수	설명
HTTP URL	{없음}	예	워크플로를 저장한 후 생성되고 워크플로를 트리거하는 요청을 보내는 데 사용되는 엔드포인트 URL입니다.
요청 본문 JSON 스키마	`schema`	아니요	들어오는 요청 본문의 속성 및 값을 설명하는 JSON 스키마입니다. 디자이너는 이 스키마를 사용하여 요청에서 속성에 대한 토큰을 생성합니다. 이렇게 하면 워크플로가 요청 트리거의 출력을 구문 분석하고, 사용하고, 워크플로로 전달할 수 있습니다. JSON 스키마가 없을 경우 샘플 페이로드를 사용하여 스키마 생성 기능을 사용하여 샘플 페이로드에서 스키마를 생성할 수 있습니다.

다음 예제에서는 샘플 JSON 스키마를 보여 줍니다.

다음 예제에서는 전체 샘플 JSON 스키마를 보여 줍니다.

{
   "type": "object",
   "properties": {
      "account": {
         "type": "object",
         "properties": {
            "name": {
               "type": "string"
            },
            "ID": {
               "type": "string"
            },
            "address": {
               "type": "object",
               "properties": {
                  "number": {
                     "type": "string"
                  },
                  "street": {
                     "type": "string"
                  },
                  "city": {
                     "type": "string"
                  },
                  "state": {
                     "type": "string"
                  },
                  "country": {
                     "type": "string"
                  },
                  "postalCode": {
                     "type": "string"
                  }
               }
            }
         }
      }
   }
}

JSON 스키마를 입력하면 디자이너에서 요청에 Content-Type 헤더를 포함하고 그 헤더 값을 application/json로 설정하라는 알림을 표시할 수 있습니다. 자세한 내용은 콘텐츠 유형 처리를 참조하세요.

다음 예제에서는 헤더가 Content-Type JSON 형식으로 표시되는 방법을 보여 줍니다.

{
   "Content-Type": "application/json"
}

예상 페이로드(데이터)를 기반으로 하는 JSON 스키마를 생성하려면 json-schema.org 같은 도구를 사용하거나 다음 단계를 수행할 수 있습니다.

요청 트리거에서 샘플 페이로드를 사용하여 스키마 생성을 선택합니다.

샘플 페이로드를 입력하고 완료를 선택합니다.

다음 예제에서는 샘플 페이로드를 보여 줍니다.

{
   "account": {
      "name": "Contoso",
      "ID": "12345",
      "address": {
         "number": "1234",
         "street": "Anywhere Street",
         "city": "AnyTown",
         "state": "AnyState",
         "country": "USA",
         "postalCode": "11111"
      }
   }
}

인바운드 호출에 특정 스키마와 일치하는 요청 본문이 있는지 확인하려면 다음 단계를 수행합니다.
1. 인바운드 메시지가 스키마에서 설명하는 것과 동일한 필드를 갖도록 하려면 스키마에서 required 속성을 추가하고 필수 필드를 지정합니다. additionalProperties 속성을 추가하고 값을 false로 설정합니다.
  
  예를 들어 다음 스키마는 인바운드 메시지에 다른 필드가 아닌 msg 필드가 있어야 한다고 지정합니다.
```
{
   "properties": {
     "msg": {
        "type": "string"
     }
   },
   "type": "object",
   "required": ["msg"],
   "additionalProperties": false
}
```
2. 디자이너에서 요청 트리거를 선택합니다. 열리는 정보 창에서 설정 탭을 선택합니다.
3. 데이터 처리를 확장하고 스키마 유효성 검사를 켜기로 설정합니다.
  
  인바운드 호출의 요청 본문이 스키마와 일치하지 않는 경우 트리거가 HTTP 400 잘못된 요청 오류를 반환합니다.
메서드 목록에서 트리거에서 인바운드 요청이 사용할 것으로 예상되는 메서드를 선택합니다.
트리거에 대한 다른 매개 변수가 있는 경우 고급 매개 변수 목록을 열고 원하는 매개 변수를 선택합니다.
트리거에 대한 다른 매개 변수가 있는 경우 고급 매개 변수 목록을 열고 원하는 매개 변수를 선택합니다.
준비되면 워크플로를 저장합니다. 디자이너 도구 모음에서 저장을 선택합니다.

이 단계에서는 워크플로를 트리거하는 요청을 전송하는 데 사용할 수 있는 URL을 생성합니다.
생성된 URL을 복사하려면 URL 옆에 있는 복사 아이콘을 선택합니다.

참고

요청 트리거를 호출할 때 URI에 해시 또는 파운드 기호(#)를 포함하려면 이 인코딩된 버전을 대신 사용합니다. %25%23

요청 트리거의 URL은 워크플로의 스토리지 계정과 연결됩니다. 스토리지 계정이 변경되면 이 URL도 변경됩니다. 예를 들어 표준 논리 앱을 사용하면 스토리지 계정을 수동으로 변경하고 워크플로를 새 스토리지 계정에 복사하는 경우 요청 트리거의 URL도 새 스토리지 계정을 반영하도록 변경됩니다. 동일한 워크플로에 다른 URL이 있습니다.

상태 비저장 워크플로에 대한 스키마 유효성 검사

상태 비저장 워크플로에 대한 스키마 유효성 검사를 사용하도록 설정하려면 논리 앱 리소스 또는 프로젝트의 host.json 파일에 다음 호스트 설정이 있는지 확인헤야 합니다.

"extensions": {
   "workflow": {
      "Settings": {
         "Runtime.StatelessFlowEvaluateTriggerCondition": "true"
      }
   }
}

이제 다음 단계로 다른 작업을 추가하여 워크플로를 계속 빌드합니다. 예를 들어 사용자 지정된 응답을 반환하는 데 사용할 수 있으며 이 문서의 뒷부분에서 설명하는 응답 작업을 추가하여 요청에 응답할 수 있습니다.

참고

워크플로는 제한된 시간 동안만 인바운드 요청을 열어 둡니다. 워크플로에 응답 작업도 포함되어 있다고 가정하고, 이 시간이 만료된 후 워크플로가 호출자에게 응답을 반환하지 않으면 워크플로는 504 게이트웨이 시간 초과 상태를 호출자에게 반환합니다. 워크플로에 응답 작업이 포함되지 않은 경우 워크플로는 호출자에게 202 수락됨 상태를 즉시 반환합니다.

TLS(전송 계층 보안), Microsoft Entra ID를 사용하는 OAuth, SAS(공유 액세스 서명), Azure API Management를 사용하여 논리 앱 리소스 노출 또는 인바운드 호출을 시작하는 IP 주소 제한과 같은 워크플로에 대한 인바운드 호출에 대한 보안, 인증 및 암호화에 대한 자세한 내용은 요청 기반 트리거에 대한 인바운드 호출에 대한 Access를 참조하세요.

트리거 출력

다음 표에서는 요청 트리거의 출력을 나열합니다.

JSON 속성 이름	데이터 형식	설명
`headers`	객체	요청의 헤더를 설명하는 JSON 개체입니다.
`body`	객체	요청의 본문 콘텐츠를 설명하는 JSON 개체입니다.

응답 작업 추가

요청 트리거를 사용하여 인바운드 요청을 수신하는 경우 요청 트리거에서만 작동하는 응답 기본 제공 작업을 사용하여 응답을 모델링하고 페이로드 결과를 호출자에게 다시 보낼 수 있습니다. 요청 트리거 및 응답 작업과 이 조합은 요청-응답 패턴을 만듭니다. 각 루프 및 Until 루프 및 병렬 분기 내부를 제외하고 워크플로의 아무 곳이나 응답 작업을 추가할 수 있습니다.

중요합니다

응답 작업에 다음 헤더가 포함된 경우 Azure Logic Apps는 경고 또는 오류를 표시하지 않고 생성된 응답 메시지에서 이러한 헤더를 자동으로 제거합니다. Azure Logic Apps는 이러한 헤더를 포함하지 않지만 서비스에서 이러한 헤더를 사용하여 응답 작업이 있는 워크플로를 저장하는 것을 막지는 못합니다.
- Allow
- Content-* 헤더는 Content-Disposition, Content-Encoding, Content-Type를 제외하고 POST 및 PUT 작업에서는 사용되지만, GET 작업에는 포함되지 않습니다.
- Cookie
- Expires
- Last-Modified
- Set-Cookie
- Transfer-Encoding
분기가 있는 복잡한 워크플로에 하나 이상의 응답 작업이 있는 경우 워크플로가 런타임 중에 하나 이상의 응답 작업을 처리하는지 확인합니다. 그렇지 않고 모든 응답 작업을 건너뛰면 워크플로가 성공적으로 완료되더라도 호출자는 502 잘못된 게이트웨이 오류를 수신합니다.
표준 논리 앱 상태 비저장 워크플로에서 응답 작업은 워크플로에 마지막으로 표시되어야 합니다. 작업이 다른 곳에 표시되면 Azure Logic Apps는 다른 모든 작업의 실행이 완료될 때까지 작업을 실행하지 않습니다.

사용량
표준

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

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

작업 정보 상자에 응답 메시지에 필요한 값을 추가합니다.

속성 이름	JSON 속성 이름	필수	설명
상태 코드	`statusCode`	예	응답에 반환할 상태 코드
헤더	`headers`	아니요	응답에 포함할 하나 이상의 헤더를 설명하는 JSON 개체입니다.
본문	`body`	아니요	응답 본문

텍스트 필드 내에서 선택하면 동적 콘텐츠 목록(번개 아이콘) 또는 식 편집기(함수 아이콘)를 여는 옵션이 표시됩니다. 동적 콘텐츠 목록을 선택하면 워크플로의 이전 단계에서 사용할 수 있는 출력을 선택할 수 있습니다. 요청 트리거에서 스키마를 지정한 경우 스키마 속성도 동적 콘텐츠 목록에 표시되며 워크플로에서 사용할 수 있습니다.

예를 들어 헤더 필드에서 Content-Type 을 키 이름으로 사용하고 이 문서의 앞부분에서 설명한 대로 키 값을 application/json 으로 설정합니다. 본문 상자의 경우 동적 콘텐츠 목록을 열고 트리거 본문 출력을 선택할 수 있습니다.

헤더를 JSON 형식으로 보려면 텍스트 뷰로 전환를 선택합니다.

작업에 대한 다른 매개 변수가 있는 경우 고급 매개 변수 목록을 열고 원하는 매개 변수를 선택합니다.
완료되면 워크플로를 저장합니다. 디자이너 도구 모음에서 저장을 선택합니다.

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

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

작업 정보 상자에 응답 메시지에 필요한 값을 추가합니다.

속성 이름	JSON 속성 이름	필수	설명
상태 코드	`statusCode`	예	응답에 반환할 상태 코드
헤더	`headers`	아니요	응답에 포함할 하나 이상의 헤더를 설명하는 JSON 개체입니다.
본문	`body`	아니요	응답 본문

헤더를 JSON 형식으로 보려면 텍스트 뷰로 전환를 선택합니다.

작업에 대한 다른 매개 변수가 있는 경우 고급 매개 변수 목록을 열고 원하는 매개 변수를 선택합니다.
완료되면 워크플로를 저장합니다. 디자이너 도구 모음에서 저장을 선택합니다.

워크플로 테스트

워크플로를 트리거하려면 HTTP 요청 도구 및 해당 지침을 사용하여 요청 트리거가 예상하는 메서드를 포함하여 요청 트리거에 대해 생성된 URL로 HTTP 요청을 보냅니다.

트리거의 기본 JSON 정의 및 이 트리거를 호출하는 방법에 대한 자세한 내용은 Azure Logic Apps에서 HTTP 엔드포인트를 사용하여 트리거 유형 요청 및 호출, 트리거 또는 중첩 워크플로를 참조하세요.

보안 및 인증

요청 트리거(웹후크 트리거 아님)로 시작하는 표준 논리 앱 워크플로에서는 관리 ID를 사용하여 해당 트리거에서 만든 엔드포인트로 전송된 인바운드 호출을 인증하기 위해 Azure Functions 프로비저닝을 사용할 수 있습니다. 이 프로비저닝을 Easy Auth라고도 합니다. 자세한 내용은 간편한 인증을 사용하는 표준 논리 앱의 트리거 워크플로를 참조하세요.

TLS(전송 계층 보안), Microsoft Entra ID OAuth(Microsoft Entra ID OAuth)와 같은 논리 앱 워크플로에 대한 인바운드 호출에 대한 보안, 권한 부여 및 암호화에 대한 자세한 내용은 Azure API Management를 사용하여 논리 앱을 노출하거나 인바운드 호출을 시작하는 IP 주소를 제한하는 경우 요청 기반 트리거에 대한 인바운드 호출에 대한 Access를 참조하세요.