Visual Studio를 사용하여 Azure Functions 개발

Visual Studio는 C# 클래스 라이브러리 함수를 개발, 테스트 및 Azure에 배포하는 방법을 제공합니다. 이 환경이 Azure Functions를 처음 사용하는 경우 Azure Functions 개요를 참조하세요.

바로 시작하려면 Visual Studio용 Functions 빠른 시작을 완료하는 것이 좋습니다.

이 문서에서는 Visual Studio를 사용하여 C# 클래스 라이브러리 함수를 개발하고 Azure에 게시하는 방법에 대한 자세한 정보를 제공합니다. C# 클래스 라이브러리 함수를 개발하기 위한 두 가지 모델, 즉 격리된 작업자 모델 과 in-process 모델이 있습니다.

이 문서의 격리된 작업자 모델 버전을 읽고 있습니다. 문서의 맨 위에서 원하는 모델을 선택할 수 있습니다.

이 문서의 진행 중인 모델 버전을 읽고 있습니다. 문서의 맨 위에서 원하는 모델을 선택할 수 있습니다.

중요

In-process 모델에 대한 지원은 2026년 11월 10일에 종료됩니다. 격리된 작업자 모델로 앱을 마이그레이션하는 것이 좋습니다.

별도로 언급하지 않는 한, 표시된 절차와 예제는 Visual Studio 2022에 대한 것입니다. Visual Studio 2022 릴리스에 대한 자세한 내용은 릴리스 정보 또는 미리 보기 릴리스 정보를 참조하세요.

필수 구성 요소

Visual Studio 2022(Azure 개발 워크로드 포함).
Azure Storage 계정과 같이 필요한 다른 리소스는 게시 프로세스 중에 구독에서 만들어 집니다.
Azure 계정이 없는 경우 시작하기 전에 체험 계정을 만듭니다.

Azure Functions 프로젝트 만들기

Visual Studio의 Azure Functions 프로젝트 템플릿은 Azure에서 함수 앱에 게시할 수 있는 C# 클래스 라이브러리 프로젝트를 만듭니다. 함수 앱을 사용하면 함수를 논리 단위로 그룹화하여 더 쉽게 리소스를 관리, 배포, 크기 조정 및 공유할 수 있습니다.

Visual Studio 메뉴에서 파일>새로 만들기>프로젝트를 차례로 선택합니다.
새 프로젝트 만들기 대화 상자에서 검색 상자에 함수를 입력하고, Azure Functions 템플릿을 선택한 다음, 다음을 선택합니다.
새 프로젝트 구성 대화 상자에서 프로젝트 이름에 프로젝트 이름을 입력하고 다음을 선택합니다. 함수 앱 이름은 C# 네임스페이스로 유효해야 하므로 밑줄, 하이픈 또는 기타 영숫자가 아닌 문자는 사용하지 마세요.

추가 정보 대화 상자에서 다음 표에 나열된 작업을 수행합니다.

설정	조치	설명
Functions 작업자	.NET 8.0 격리 모드(장기 지원)를 선택합니다.	Visual Studio는 격리된 작업자 프로세스에서 실행되는 함수 프로젝트를 만듭니다. 격리된 작업자 프로세스는 LTS(장기 지원)를 제공하지 않는 다른 버전의 .NET 및 .NET Framework도 지원합니다. 자세한 내용은 Azure Functions 런타임 버전 개요를 참조하세요.
Function	Http 트리거를 선택합니다.	Visual Studio는 HTTP 요청에 의해 트리거되는 함수를 만듭니다.
런타임 스토리지 계정에 Azurite 사용(AzureWebJobsStorage)	이 확인란을 선택합니다.	Azure의 함수 앱에는 스토리지 계정이 필요하기 때문에 Azure에 프로젝트를 게시할 때 할당되거나 생성됩니다. HTTP 트리거는 Storage 계정 연결 문자열을 사용하지 않습니다. 다른 모든 트리거 유형에는 유효한 Storage 계정 연결 문자열이 필요합니다.
권한 부여 수준	익명을 선택합니다.	이 권한 부여 설정을 사용하는 경우 모든 클라이언트는 키를 제공하지 않고 만든 함수를 트리거할 수 있습니다. 이 구성을 사용하면 새 함수를 쉽게 테스트할 수 있습니다. 자세한 내용은 권한 부여 수준을 참조하세요.

설정	조치	설명
Functions 작업자	.NET 8.0 In-process(장기 지원)를 선택합니다.	Visual Studio는 Functions 런타임 버전 4.x를 사용하여 In-Process를 실행하는 함수 프로젝트를 만듭니다. 자세한 내용은 Azure Functions 런타임 버전 개요를 참조하세요.
Function	Http 트리거를 선택합니다.	Visual Studio는 HTTP 요청에 의해 트리거되는 함수를 만듭니다.
런타임 스토리지 계정에 Azurite 사용(AzureWebJobsStorage)	이 확인란을 선택합니다.	Azure의 함수 앱에는 스토리지 계정이 필요하기 때문에 Azure에 프로젝트를 게시할 때 할당되거나 생성됩니다. HTTP 트리거는 Storage 계정 연결 문자열을 사용하지 않습니다. 다른 모든 트리거 유형에는 유효한 Storage 계정 연결 문자열이 필요합니다.
권한 부여 수준	익명 선택	이 권한 부여 설정을 사용하는 경우 모든 클라이언트는 키를 제공하지 않고 만든 함수를 트리거할 수 있습니다. 이 구성을 사용하면 새 함수를 쉽게 테스트할 수 있습니다. 자세한 내용은 권한 부여 수준을 참조하세요.

권한 부여 수준을 익명으로 설정했는지 확인합니다. 함수의 기본 수준을 선택하는 경우 함수 엔드포인트에 액세스하려면 요청에 함수 키를 제공해야 합니다.

만들기를 선택하여 함수 프로젝트 및 HTTP 트리거 함수를 만듭니다.

Functions 프로젝트를 만든 후, 프로젝트 템플릿은 C# 프로젝트를 만들고 NuGet Microsoft.Azure.Functions.Worker 및 Microsoft.Azure.Functions.Worker.Sdk 패키지를 설치하고 대상 프레임워크를 설정합니다.

Functions 프로젝트를 만든 후 프로젝트 템플릿은 C# 프로젝트를 만들고, NuGet 패키지를 설치 Microsoft.NET.Sdk.Functions 하고, 대상 프레임워크를 설정합니다.

새 프로젝트에는 다음 파일이 포함됩니다.

host.json: 이 파일은 Functions 호스트를 구성하는 방법을 제공합니다. 이러한 설정은 로컬 및 Azure에서 실행할 때 모두 적용됩니다. 자세한 내용은 host.json 참조를 참조하세요.
local.settings.json: 이 파일은 함수를 로컬로 실행할 때 사용하는 설정을 유지 관리합니다. 이러한 설정은 앱이 Azure에서 실행되는 경우 사용되지 않습니다. 자세한 내용은 로컬에서 앱 설정 작업을 참조하세요.

중요

local.settings.json 파일에는 비밀이 포함될 수 있으므로 프로젝트 소스 제어에서 제외해야 합니다. 이 파일에 대한 속성 대화 상자에서 출력 디렉터리로 복사 설정이 최신인 경우 복사로 설정되어 있는지 확인합니다.

자세한 내용은 격리된 작업자 가이드의 프로젝트 구조를 참조하세요.

자세한 내용은 Functions 클래스 라이브러리 프로젝트를 참조하세요.

로컬에서 앱 설정 작업

함수 앱이 Azure에서 실행되면 함수에 필요한 설정이 앱 설정에 암호화되어 저장됩니다. 로컬 개발 중에 이러한 설정은 대신 Values 파일의 컬렉션에 추가됩니다. local.settings.json 파일에는 로컬 개발 도구에서 사용하는 설정도 저장됩니다.

Values 프로젝트의 local.settings.json 파일에 있는 컬렉션의 항목은 Azure에서 함수 앱의 애플리케이션 설정에 있는 항목을 미러링하기 위한 것입니다.

Visual Studio는 프로젝트를 게시할 때 local.settings.json 설정을 자동으로 업로드하지 않습니다. 이러한 설정이 Azure의 함수 앱에도 있는지 확인하려면 프로젝트를 게시한 후에 이를 업로드합니다. 자세한 내용은 함수 앱 설정을 참조하세요. 컬렉션의 ConnectionStrings 값은 게시되지 않습니다.

코드는 함수 앱 설정 값을 환경 변수로 읽을 수도 있습니다. 자세한 내용은 환경 변수를 참조하세요.

로컬 개발에 대한 프로젝트 구성

Functions 런타임은 내부적으로 Storage 계정을 사용합니다. 개발하는 동안 이 내부 계정에 유효한 Storage 계정을 사용하거나 Azurite 에뮬레이터를 사용할 수 있습니다.

HTTP 및 웹후크를 제외한 모든 트리거 형식의 Values.AzureWebJobsStorage 경우 local.settings.json 파일에서 키 값을 설정해야 합니다.

Storage 계정의 경우 스토리지 계정의 연결 문자열로 값을 설정합니다.
에뮬레이터의 경우 값을 UseDevelopmentStorage=true.로 설정합니다.

에뮬레이터를 사용하는 경우 배포 전에 이 설정을 실제 스토리지 계정 연결 문자열로 변경합니다. 자세한 내용은 로컬 스토리지 에뮬레이터를 참조하세요.

스토리지 계정 연결 문자열을 설정하려면 다음 단계를 수행합니다.

Azure Portal에 로그인한 다음 스토리지 계정으로 이동합니다.
보안 + 네트워킹>액세스 키를 선택합니다. key1에서 연결 문자열 값을 복사합니다.
Visual Studio 프로젝트에서 local.settings.json 파일을 엽니다. 키 값을 AzureWebJobsStorage 복사한 연결 문자열로 설정합니다.
이전 단계를 반복하여 함수에 필요한 다른 연결에 대한 Values 배열에 고유 키를 추가합니다.

프로젝트에 함수 추가

C# 클래스 라이브러리 함수에서 함수에서 사용하는 바인딩은 코드에 특성을 적용하여 정의됩니다. 제공된 템플릿에서 함수 트리거를 만들면 트리거 특성이 적용됩니다.

솔루션 탐색기에서 프로젝트 노드를 마우스 오른쪽 단추로 클릭하고 추가>새 Azure 함수를 차례로 선택합니다.
새 항목 추가 대화 상자에서 Azure Function을 선택한 다음 추가를 선택합니다.
트리거를 선택한 다음 필요한 바인딩 속성을 설정합니다. Storage 서비스 트리거를 선택하고 연결을 구성하려면 트리거 연결을 구성하기 위한 확인란을 선택합니다. 다음 예제에서는 Queue Storage 트리거 함수를 만들기 위한 설정을 보여 줍니다.
추가를 선택합니다. 이전 단계에서 스토리지 연결을 구성하기 위한 확인란을 선택하면 종속성에 연결 페이지가 나타납니다. Azurite 스토리지 에뮬레이터 또는 Azure Storage를 선택한 다음, 다음을 선택합니다.
- Azurite 스토리지 에뮬레이터를 선택하면 스토리지 Azurite 에뮬레이터에 연결 페이지가 나타납니다. 다음 단계를 수행합니다.
  1. 다음을 선택합니다.
  2. 변경 내용 요약 페이지에서 마침을 선택합니다. Visual Studio는 종속성을 구성하고 트리거 클래스를 만듭니다.
- Azure Storage를 선택하면 Azure Storage에 연결 페이지가 나타납니다. 다음 단계를 수행합니다.
  1. 스토리지 계정을 선택한 다음, 다음을 선택합니다. Visual Studio는 Azure 계정에 연결하고 엔드포인트를 검색하려고 시도합니다.
  2. 다음을 선택합니다.
  3. 변경 내용 요약 페이지에서 마침을 선택합니다. Visual Studio는 종속성을 구성하고 트리거 클래스를 만듭니다.
이 트리거 예제에서는 스토리지 연결에 대한 애플리케이션 설정을 QueueStorage라는 키와 함께 사용합니다. local.settings.json 파일에 저장된 이 키는 Azurite 에뮬레이터 또는 Storage 계정을 참조합니다.

새로 추가된 클래스를 검사합니다. 예를 들어 다음 C# 클래스는 기본 Queue Storage 트리거 함수를 나타냅니다.

Run() 메서드에 Function 특성이 지정됩니다. 이 특성은 메서드가 함수에 대한 진입점임을 나타냅니다.

using System;
using Azure.Storage.Queues.Models;
using Microsoft.Azure.Functions.Worker;
using Microsoft.Extensions.Logging;

namespace Company.Function;

public class QueueTriggerCSharp
{
    private readonly ILogger<QueueTriggerCSharp> _logger;

    public QueueTriggerCSharp(ILogger<QueueTriggerCSharp> logger)
    {
        _logger = logger;
    }

    [Function(nameof(QueueTriggerCSharp))]
    public void Run([QueueTrigger("PathValue", Connection = "ConnectionValue")] QueueMessage message)
    {
        _logger.LogInformation("C# Queue trigger function processed: {messageText}", message.MessageText);
    }
}

정적 Run() 메서드에 FunctionName 특성이 부여됩니다. 이 특성은 메서드가 함수에 대한 진입점임을 나타냅니다.

using System;
using Microsoft.Azure.WebJobs;
using Microsoft.Azure.WebJobs.Host;
using Microsoft.Extensions.Logging;

namespace Company.Function
{
    public class QueueTriggerCSharp
    {
        [FunctionName("QueueTriggerCSharp")]
        public void Run([QueueTrigger("PathValue", Connection = "ConnectionValue")]string myQueueItem, ILogger log)
        {
            log.LogInformation($"C# Queue trigger function processed: {myQueueItem}");
        }
    }
}

바인딩 고유 특성은 진입점 메서드에 적용되는 각 바인딩 매개 변수에 적용됩니다. 특성은 매개 변수로 바인딩 정보를 사용합니다.

앞의 코드에서 첫 번째 매개 변수에는 QueueTrigger Queue Storage 트리거 함수를 나타내는 특성이 적용되었습니다. 큐 이름 및 연결 문자열 설정 이름은 QueueTrigger 특성에 매개 변수로 전달됩니다. 수업에서 다음 작업을 수행합니다.

큐 이름 매개 변수는 트리거를 만들기 myqueue-items위해 이전 단계에서 사용하는 큐의 이름과 일치해야 합니다.
연결 문자열 설정 이름은 이전 단계에서 트리거를 만드는 데 사용한 이름(예: QueueStorage.)과 일치해야 합니다.

자세한 내용은 Azure Functions에 대한 Azure Queue Storage 트리거를 참조하세요.

이전 절차를 사용하여 함수 앱 프로젝트에 함수를 더 추가합니다. 프로젝트에서 각 함수는 다른 트리거를 가질 수 있지만 함수에는 정확히 하나의 트리거만 있어야 합니다. 자세한 내용은 Azure Functions 트리거 및 바인딩을 참조하세요.

바인딩 추가

트리거와 마찬가지로 입력 및 출력 바인딩이 바인딩 특성으로 함수에 추가됩니다. 함수에 바인딩을 추가하려면 다음 단계를 수행합니다.

로컬 개발에 대한 프로젝트를 구성했는지 확인합니다.
각 특정 바인딩에 적절한 NuGet 확장 패키지를 추가합니다. 바인딩 관련 NuGet 패키지 요구 사항은 바인딩에 대한 참조 문서를 참조하세요. 예를 들어 Azure Event Hubs 트리거에 대한 패키지 요구 사항은 Azure Functions에 대한 Azure Event Hubs 트리거 및 바인딩을 참조하세요.
패키지 관리자 콘솔에서 다음 명령을 사용하여 특정 패키지를 설치합니다.
```
Install-Package Microsoft.Azure.Functions.Worker.Extensions.<BINDING_TYPE> -Version <TARGET_VERSION>
```
```
Install-Package Microsoft.Azure.WebJobs.Extensions.<BINDING_TYPE> -Version <TARGET_VERSION>
```
이 코드에서 `<BINDING_TYPE>`를 바인딩 확장의 특정 이름으로 바꾸고, `<TARGET_VERSION>`를 패키지의 특정 버전으로, 예를 들어 `4.0.0`으로 바꿉니다. 유효한 버전은 NuGet.org의 개별 패키지 페이지에 나열되어 있습니다.
바인딩에 필요한 앱 설정이 있는 경우 Values의 컬렉션에 추가합니다.

함수는 로컬로 실행될 때 이러한 값을 사용합니다. 함수가 Azure의 함수 앱에서 실행될 때 함수 앱 설정이 사용됩니다. Visual Studio를 사용하면 로컬 설정을 Azure에 손쉽게 게시할 수 있습니다.

메서드 서명에 적절한 바인딩 특성을 추가합니다. 다음 코드에서 큐 메시지는 함수를 Run 트리거합니다. 그런 다음 출력 바인딩은 다른 큐에 동일한 텍스트를 사용하여 새 큐 메시지를 만듭니다.

 public class QueueTrigger
{
    private readonly ILogger _logger;

    public QueueTrigger(ILoggerFactory loggerFactory)
    {
        _logger = loggerFactory.CreateLogger<QueueTrigger>();
    }

    [Function("CopyQueueMessage")]
    [QueueOutput("myqueue-items-destination", Connection = "QueueStorage")]
    public string Run([QueueTrigger("myqueue-items-source", Connection = "QueueStorage")] string myQueueItem)
    {
        _logger.LogInformation($"C# Queue trigger function processed: {myQueueItem}");
        return myQueueItem;
    }
}

QueueOutput 특성은 메서드에 대한 바인딩을 정의합니다. 여러 출력 바인딩의 경우 이 특성을 반환된 개체의 문자열 속성에 배치합니다. 자세한 내용은 여러 출력 바인딩을 참조하세요.

public static class SimpleExampleWithOutput
{
    [FunctionName("CopyQueueMessage")]
    public static void Run(
        [QueueTrigger("myqueue-items-source", Connection = "QueueStorage")] string myQueueItem, 
        [Queue("myqueue-items-destination", Connection = "QueueStorage")] out string myQueueItemCopy,
        ILogger log)
    {
        log.LogInformation($"CopyQueueMessage function processed: {myQueueItem}");
        myQueueItemCopy = myQueueItem;
    }
}

Queue 매개 변수의 out 특성은 출력 바인딩을 정의합니다.

Queue Storage에 대한 연결은 QueueStorage 설정에서 획득됩니다. 자세한 내용은 특정 바인딩에 대한 참조 문서를 참조하세요.

Functions에서 지원되는 바인딩의 전체 목록은 지원되는 바인딩을 참조하세요. 이 시나리오보다 완전한 예를 보려면 Visual Studio를 사용하여 Azure Storage에 함수 연결을 참조하세요.

로컬로 함수 실행

Azure Functions Core Tools를 사용하여 로컬 개발 컴퓨터에서 Functions 프로젝트를 실행할 수 있습니다. F5를 선택하여 Functions 프로젝트를 디버그하면 로컬 Functions 호스트(func.exe)가 로컬 포트(일반적으로 7071)에서 수신 대기하기 시작합니다. 호출 가능한 모든 함수 엔드포인트는 출력에 기록되며, 이러한 엔드포인트를 사용하여 함수를 테스트할 수 있습니다. 자세한 내용은 Core Tools를 사용하여 로컬로 Azure Functions 개발을 참조하세요. Visual Studio에서 처음으로 함수를 시작할 때 이러한 도구를 설치하라는 메시지가 표시됩니다.

중요

Core Tools 버전 4.0.6517부터 In Process 모델 프로젝트는 버전 4.5.0 이상Microsoft.NET.Sdk.Functions을 참조해야 합니다. 이전 버전을 func start 사용하는 경우 명령은 오류를 생성합니다.

디버그 모드에서 Visual Studio에서 함수를 시작하려면 다음 단계를 수행합니다.

F5 키를 선택합니다. 메시지가 표시되면 Visual Studio의 요청에 동의하여 Azure Functions Core Tools를 다운로드하고 설치합니다. 도구에서 HTTP 요청을 처리할 수 있도록 방화벽 예외를 설정해야 할 수도 있습니다.
프로젝트가 실행되면 배포된 함수를 테스트하는 것과 동일한 방식으로 코드를 테스트합니다.

디버그 모드에서 Visual Studio를 실행하면 중단점이 예상대로 적중됩니다.

Visual Studio를 사용하는 보다 자세한 테스트 시나리오는 이 문서의 뒷부분에 있는 테스트 함수를 참조하세요.

Azure에 게시

Functions 프로젝트를 Azure에 게시할 때 Visual Studio는 zip 배포 를 사용하여 프로젝트 파일을 배포합니다. 가능하면 프로젝트가 배포(.zip) 패키지에서 실행되도록 패키지 파일에서 실행을 선택해야 합니다. 자세한 내용은 Azure의 패키지 파일에서 함수 실행을 참조하세요.

웹 배포(msdeploy)를 사용하여 Functions에 배포하지 마세요.

다음 단계를 사용하여 Azure의 함수 앱에 프로젝트를 게시합니다.

솔루션 탐색기에서 프로젝트를 마우스 오른쪽 단추로 클릭한 다음 게시를 선택합니다.
게시 페이지에서 다음을 선택합니다.
- 대상에서 Azure를 선택한 다음, 다음을 선택합니다.
- 특정 대상에서 Azure Function App을 선택한 다음, 다음을 선택합니다.
- Functions 인스턴스에서 새로 만들기를 선택합니다.

다음 표에 지정된 값을 사용하여 새 인스턴스를 만듭니다.

설정	값	설명
이름	전역적으로 고유한 이름	이름은 새 함수 앱을 고유하게 식별해야 합니다. 제안된 이름을 그대로 사용하거나 새 이름을 입력합니다. 다음과 같은 문자가 유효합니다. `a-z0-9-`
구독 이름	구독의 이름	함수 앱은 Azure 구독에서 만들어집니다. 기본 구독을 적용하거나 목록에서 다른 구독을 선택합니다.
리소스 그룹	리소스 그룹의 이름	함수 앱은 리소스 그룹에 만들어집니다. 새로 만들기를 선택하여 새 리소스 그룹을 만듭니다. 목록에서 기존 리소스 그룹을 선택할 수도 있습니다.
플랜 유형	Flex 사용량	Flex Consumption 계획에서 실행되는 함수 앱에 프로젝트를 게시하는 경우 함수 앱의 실행에 대해서만 비용을 지불할 수 있습니다. 다른 호스팅 계획에는 더 높은 비용이 발생할 수 있습니다. 중요: Flex 소비 계획을 만들 때 먼저 App Service 계획을 선택한 다음 Flex Consumption 를 다시 선택하여 대화 상자의 문제를 해결해야 합니다.
운영 체제	리눅스	Flex 소비 계획에는 현재 Linux가 필요합니다.
위치	앱 서비스의 위치	Flex 소비 계획에서 지원하는 Azure 지역의 위치를 선택합니다. 지원되지 않는 지역을 선택하면 만들기 단추가 회색으로 표시됩니다.
인스턴스 메모리 크기	2048	앱 이 실행되는 가상 머신 인스턴스의 메모리 크기 는 Flex Consumption 계획에 고유합니다.
Azure Storage	범용 스토리지 계정	Functions 런타임에는 Storage 계정이 필요합니다. 새로 만들기를 선택하여 범용 스토리지 계정을 구성합니다. 스토리지 계정 요구 사항을 충족하는 기존 계정을 사용할 수도 있습니다.
Application Insights	"Application Insights" 인스턴스	함수 앱에 Application Insights 통합을 설정해야 합니다. 새로 만들기를 선택하여 새 Log Analytics 작업 영역이나 기존 Log Analytics 작업 영역에서 새 인스턴스를 만듭니다. 기존 인스턴스를 사용할 수도 있습니다.

함수 앱 새로 만들기 대화 상자의 스크린샷. 이름, 구독, 리소스 그룹, 계획 및 기타 설정에 대한 필드가 채워졌습니다.

만들기를 선택하여 Azure에서 함수 앱 및 관련된 리소스를 만듭니다. 리소스 만들기 상태가 창의 왼쪽 하단에 표시됩니다.
완료를 선택합니다. 게시 프로필 생성 진행률 창이 나타납니다. 프로필을 만들 때 닫기를 선택합니다.
게시 프로필 페이지에서 게시 를 선택하여 프로젝트 파일이 포함된 패키지를 Azure의 새 함수 앱에 배포합니다.

배포가 완료되면 Azure에서 함수 앱의 루트 URL이 게시 프로필 페이지에 표시됩니다.
게시 프로필 페이지에서 호스팅 섹션으로 이동합니다. 줄임표(...)를 선택한 다음 , Azure Portal에서 열기를 선택합니다. Azure Portal에서 새로운 함수 앱 Azure 리소스가 열립니다.

함수 앱 설정

Visual Studio는 프로젝트를 게시할 때 앱 설정을 자동으로 업로드하지 않습니다. local.settings.json 파일에 설정을 추가하는 경우 Azure의 함수 앱에도 설정을 추가해야 합니다.

Azure에서 함수 앱에 필요한 설정을 업로드하는 가장 쉬운 방법은 Visual Studio에서 관리하는 것입니다. 게시 프로필 페이지에서 호스팅 섹션으로 이동합니다. 줄임표(...)를 선택한 다음 , Azure App Service 설정 관리를 선택합니다.

이 옵션을 선택하면 함수 앱에 대한 애플리케이션 설정 대화 상자가 열립니다. 이 대화 상자를 사용하여 애플리케이션 설정을 추가하거나 기존 설정을 수정할 수 있습니다.

다양한 설정에 대한 로컬 및 원격 값과 값 추가 및 편집을 위한 컨트롤을 보여 주는 애플리케이션 설정 대화 상자의 스크린샷

각 설정에 대해 로컬 값은 local.settings.json 파일의 값이고 원격 값은 Azure의 함수 앱에 있는 값입니다.

앱 설정을 만들려면 설정 추가를 선택합니다.
로컬 필드에서 원격 필드로 설정 값을 복사하려면 로컬에서 값 삽입을 선택합니다.

확인을 선택하면 보류 중인 변경 내용이 로컬 설정 파일 및 함수 앱에 기록됩니다.

참고

기본적으로 local.settings.json 파일은 소스 제어에 체크 인되지 않습니다. 따라서 소스 제어에서 로컬 Functions 프로젝트를 복제하는 경우 프로젝트에 local.settings.json 파일이 없습니다. 애플리케이션 설정 대화 상자가 예상대로 작동하도록 프로젝트 루트에 local.settings.json 파일을 수동으로 만들어야 합니다.

또한 다음 다른 방법 중 하나로 애플리케이션 설정을 관리할 수도 있습니다.

Azure Portal을 사용합니다.
--publish-local-settings Azure Functions 핵심 도구에서 게시 옵션을 사용합니다.
Azure CLI를 사용합니다.

원격 디버깅

함수 앱을 원격으로 디버그하려면 프로젝트의 디버그 구성을 게시해야 합니다. 또한 Azure의 함수 앱에서 원격 디버깅을 설정해야 합니다.

이 섹션에서는 함수 앱에 대한 디버그 구성이 게시되었다고 가정합니다.

원격 디버깅 고려 사항

원격 디버깅은 프로덕션 서비스에서 권장되지 않습니다.
원격 디버깅을 사용하려면 프리미엄 또는 App Service 계획에서 함수 앱을 호스트해야 합니다.
원격 디버깅은 현재 Windows에서 C# 앱을 실행할 때만 지원됩니다.
Visual Studio에서 내 코드만 기능을 설정한 경우 해제합니다. 지침은 내 코드만 사용 또는 비활성화를 참조하세요.
원격 디버깅을 사용하는 경우 중단점에서 긴 중지를 방지합니다. 프로세스가 몇 분 이상 중지되면 Azure는 응답하지 않는 프로세스로 처리하고 종료합니다.
디버깅하는 동안 서버는 대역폭 요금에 영향을 줄 수 있는 데이터를 Visual Studio로 보냅니다. 대역폭 요금에 대한 자세한 내용은 가격 계산기를 참조하세요.
48시간 후에 함수 앱에서 원격 디버깅이 자동으로 꺼집니다. 이 시점 이후에는 원격 디버깅을 다시 설정해야 합니다.

디버거 연결

격리된 작업자 프로세스 앱을 디버그하는 경우 현재 원격 디버거를 별도의 .NET 프로세스에 연결해야 합니다. 다른 몇 가지 구성 단계도 필요합니다.

Functions 호스트와 별도로 프로세스에서 실행되는 함수 앱에 원격 디버거를 연결하려면 다음 단계를 수행합니다.

게시 프로필 페이지에서 호스팅 섹션으로 이동합니다. 줄임표(...)를 선택한 다음 , 디버거 연결을 선택합니다.

Visual Studio는 함수 앱에 연결하고 원격 디버깅이 아직 켜지지 않은 경우 이를 활성화합니다.

참고

원격 디버거가 호스트 프로세스에 연결할 수 없으므로 오류 메시지가 나타날 수 있습니다. 어쨌든 로컬 디버거는 중단점에 액세스하거나 변수를 검사하거나 코드를 단계별로 실행할 수 있는 방법을 제공할 수 없습니다.
Visual Studio 디버그 메뉴에서 프로세스에 연결을 선택합니다.
프로세스에 연결 대화 상자에서 다음 단계를 수행합니다.
1. 연결 유형 옆에 있는 Microsoft Azure App Services를 선택합니다.
2. 연결 대상 옆에 있는 찾기를 선택합니다.
Azure 프로세스에 연결 대화 상자에서 함수 앱을 검색하여 선택한 다음 확인을 선택합니다.
메시지가 표시되면 Visual Studio에서 로컬 방화벽을 통해 액세스할 수 있도록 허용합니다.
프로세스에 연결 대화 상자로 돌아가서 모든 사용자에 대한 프로세스 표시를 선택합니다. dotnet.exe선택한 다음 연결을 선택합니다.

작업이 완료되면 격리된 작업자 프로세스에서 실행되는 C# 클래스 라이브러리 코드에 연결됩니다. 이 시점에서 함수 앱을 정상적으로 디버그할 수 있습니다.

Functions 호스트를 사용하여 In-process를 실행하는 함수 앱에 원격 디버거를 연결하려면 다음 단계를 수행합니다.

게시 프로필 페이지에서 호스팅 섹션으로 이동합니다. 줄임표(...)를 선택한 다음 , 디버거 연결을 선택합니다.

Visual Studio는 함수 앱에 연결하고 원격 디버깅이 아직 켜지지 않은 경우 이를 활성화합니다. 또한 디버거를 찾아서 앱의 호스트 프로세스에 연결합니다. 이 시점에서 함수 앱을 정상적으로 디버그할 수 있습니다.

디버깅을 마치면 원격 디버깅을 해제해야 합니다.

원격 디버깅 끄기

코드의 원격 디버깅을 완료하면, Azure portal에서 원격 디버깅을 꺼야 합니다. 잊은 경우 원격 디버깅은 48시간 후에 자동으로 꺼집니다.

게시 프로필 페이지에서 호스팅 섹션으로 이동합니다. 줄임표(...)를 선택한 다음 , Azure Portal에서 열기를 선택합니다. Azure Portal에서 프로젝트가 배포된 함수 앱이 열립니다.
함수 앱에서 설정>구성을 선택한 다음 일반 설정 탭으로 이동합니다. 원격 디버깅 옆에 있는끄기를 선택합니다. 저장을 선택한 다음 계속을 선택합니다.

함수 앱이 다시 시작되면 더 이상 원격 프로세스에 원격으로 연결할 수 없습니다. Azure Portal에서 이 동일한 탭을 사용하여 Visual Studio 외부에서 원격 디버깅을 켤 수 있습니다.

모니터 기능

함수를 모니터링하는 권장 방법은 함수 앱을 Application Insights와 통합하는 것입니다. Visual Studio 게시 중에 함수 앱을 만들 때 이 통합을 켜야 합니다.

어떤 이유로 인해 게시하는 동안 통합이 설정되지 않은 경우에도 Azure의 함수 앱에 대한 Application Insights 통합 을 켜야 합니다.

모니터링에 Application Insights를 사용하는 방법에 대한 자세한 내용은 Azure Functions의 실행 모니터링을 참조하세요.

테스트 함수

이 섹션에서는 .NET용 오픈 소스 단위 테스트 도구인 xUnit을 사용하여 테스트할 수 있는 C# 프로세스 내 모델 프로젝트를 만드는 방법을 설명합니다.

1단계: 설정

다음 단계에 따라 테스트를 지원하는 데 필요한 앱 프로젝트 및 함수를 포함하여 환경을 구성합니다.

Visual Studio에서 Functions라는 Azure Functions 프로젝트를 만듭니다.
템플릿에서 HTTP 함수를 만듭니다.
1. 솔루션 탐색기에서 Functions 프로젝트를 마우스 오른쪽 단추로 클릭한 다음새 Azure 함수>를 선택합니다.
2. 새 항목 추가 대화 상자에서 Azure Function을 선택한 다음 추가를 선택합니다.
3. Http 트리거를 선택한 다음 추가를 선택합니다.
4. 새 클래스 MyHttpTrigger의 이름을 바꿉니다.
템플릿에서 타이머 함수를 만듭니다.
1. 솔루션 탐색기에서 Functions 프로젝트를 마우스 오른쪽 단추로 클릭한 다음새 Azure 함수>를 선택합니다.
2. 새 항목 추가 대화 상자에서 Azure Function을 선택한 다음 추가를 선택합니다.
3. 타이머 트리거를 선택한 다음 추가를 선택합니다.
4. 새 클래스 MyTimerTrigger의 이름을 바꿉니다.
솔루션에서 xUnit 테스트 앱을 만듭니다.
1. 솔루션 탐색기에서 Functions 프로젝트가 포함된 솔루션을 마우스 오른쪽 단추로 클릭한 다음 새프로젝트>를 선택합니다.
2. xUnit 테스트 프로젝트 템플릿을 선택한 다음, 다음을 선택합니다.
3. Project Functions.Tests의 이름을 지정합니다.
Functions.Tests 프로젝트에서 기본 테스트 파일을 제거합니다.
NuGet을 사용하여 테스트 앱의 참조를 Microsoft.AspNetCore.Mvc에 추가합니다. 패키지 관리자 콘솔을 사용하거나 다음 단계를 수행할 수 있습니다.
1. 솔루션 탐색기에서 Functions.Tests 프로젝트를 마우스 오른쪽 단추로 클릭한 다음 NuGet 패키지 관리를 선택합니다.
2. Microsoft.AspNetCore.Mvc를 검색하여 설치합니다.
Functions.Tests 앱에서 Functions 앱에 대한 참조를 추가합니다.
1. 솔루션 탐색기에서 Functions.Tests 프로젝트를 마우스 오른쪽 단추로 클릭한 다음프로젝트 참조>를 선택합니다.
2. Functions 프로젝트를 선택한 다음 확인을 선택합니다.

2단계: 테스트 클래스 만들기

이 섹션에서는 자동화된 테스트를 실행하는 데 사용하는 클래스를 만듭니다.

각 함수는 메시지 로깅을 처리하는 구현 ILogger 을 사용합니다. 일부 테스트에서는 메시지가 기록되지 않거나 로깅이 구현되는 방식은 중요하지 않습니다. 다른 테스트는 기록된 메시지를 평가하여 테스트가 통과해야 하는지 여부를 확인해야 합니다.

Functions.Tests 프로젝트에 이름이 지정된 NullScope 클래스를 만들고 다음 코드를 추가합니다. 이 클래스는 모의 범위를 제공합니다. 이후 단계에서는 이 범위를 사용하는 구현 ILogger 을 만듭니다.
```
using System;

namespace Functions.Tests
{
    public class NullScope : IDisposable
    {
        public static NullScope Instance { get; } = new NullScope();

        private NullScope() { }

        public void Dispose() { }
    }
}
```
Functions.Tests 프로젝트에 이름이 지정된 ListLogger 클래스를 만들고 다음 코드를 추가합니다. 이 클래스는 테스트 중에 평가할 메시지의 내부 목록을 유지 관리합니다. 필요한 ILogger 인터페이스를 구현하기 위해 클래스는 NullScope 클래스의 모의 스코프를 사용합니다. 테스트 사례는 모의 범위를 클래스에 전달합니다 ListLogger .
```
using Microsoft.Extensions.Logging;
using System;
using System.Collections.Generic;
using System.Text;

namespace Functions.Tests
{
    public class ListLogger : ILogger
    {
        public IList<string> Logs;

        public IDisposable BeginScope<TState>(TState state) => NullScope.Instance;

        public bool IsEnabled(LogLevel logLevel) => false;

        public ListLogger()
        {
            this.Logs = new List<string>();
        }

        public void Log<TState>(LogLevel logLevel,
                                EventId eventId,
                                TState state,
                                Exception exception,
                                Func<TState, Exception, string> formatter)
        {
            string message = formatter(state, exception);
            this.Logs.Add(message);
        }
    }
}
```
ListLogger 클래스는 ILogger 인터페이스에서 정의한 대로 다음 멤버들을 구현합니다.
- BeginScope: 스코프는 로그에 문맥을 추가합니다. 이 경우 테스트는 클래스의 정적 인스턴스를 NullScope 가리키며 테스트가 작동할 수 있도록 합니다.
- IsEnabled: 기본값 false 이 제공됩니다.
- Log: 이 메서드는 제공된 함수를 formatter 사용하여 메시지의 서식을 지정합니다. 그런 다음, 메서드는 결과 텍스트를 컬렉션에 추가합니다 Logs .
Logs 컬렉션은 List<string>의 인스턴스이고 생성자에서 초기화됩니다.
LoggerTypes.cs Functions.Tests 프로젝트에 코드 파일을 만들고 다음 코드를 추가 합니다.
```
namespace Functions.Tests
{
    public enum LoggerTypes
    {
        Null,
        List
    }
}
```
이 열거형은 테스트에서 사용하는 로거 유형을 지정합니다.

Functions.Tests 프로젝트에서 명명된 TestFactory 클래스를 만들고 다음 코드를 추가합니다.

using Microsoft.AspNetCore.Http;
using Microsoft.AspNetCore.Http.Internal;
using Microsoft.Extensions.Logging;
using Microsoft.Extensions.Logging.Abstractions;
using Microsoft.Extensions.Primitives;
using System.Collections.Generic;

namespace Functions.Tests
{
    public class TestFactory
    {
        public static IEnumerable<object[]> Data()
        {
            return new List<object[]>
            {
                new object[] { "name", "Bernardo" },
                new object[] { "name", "Ananya" },
                new object[] { "name", "Vlad" }

            };
        }

        private static Dictionary<string, StringValues> CreateDictionary(string key, string value)
        {
            var qs = new Dictionary<string, StringValues>
            {
                { key, value }
            };
            return qs;
        }

        public static HttpRequest CreateHttpRequest(string queryStringKey, string queryStringValue)
        {
            var context = new DefaultHttpContext();
            var request = context.Request;
            request.Query = new QueryCollection(CreateDictionary(queryStringKey, queryStringValue));
            return request;
        }

        public static ILogger CreateLogger(LoggerTypes type = LoggerTypes.Null)
        {
            ILogger logger;

            if (type == LoggerTypes.List)
            {
                logger = new ListLogger();
            }
            else
            {
                logger = NullLoggerFactory.Instance.CreateLogger("Null Logger");
            }

            return logger;
        }
    }
}

TestFactory 클래스는 다음 멤버를 구현합니다.

Data: 이 속성은 샘플 데이터의 IEnumerable 컬렉션을 반환합니다. 키-값 쌍은 쿼리 문자열에 전달되는 값을 나타냅니다.
CreateDictionary: 이 메서드는 키-값 쌍을 인수로 허용합니다. 쿼리 문자열 값을 나타내는 인스턴스를 만드는 데 사용되는 새 인스턴스 DictionaryQueryCollection 를 반환합니다.
CreateHttpRequest: 이 메서드는 지정된 쿼리 문자열 매개 변수를 사용하여 초기화된 HTTP 요청을 만듭니다.
CreateLogger: 이 메서드는 테스트에 사용되는 구현 ILogger 을 반환합니다. 구현은 ILogger 지정된 로거 형식에 따라 달라집니다. 목록 유형을 지정 ListLogger 하면 인스턴스는 테스트에서 평가에 사용할 수 있는 기록된 메시지를 추적합니다.

Functions.Tests 프로젝트에서 명명된 FunctionsTests 클래스를 만들고 다음 코드를 추가합니다.

using Microsoft.AspNetCore.Mvc;
using Microsoft.Extensions.Logging;
using Xunit;

namespace Functions.Tests
{
    public class FunctionsTests
    {
        private readonly ILogger logger = TestFactory.CreateLogger();

        [Fact]
        public async void Http_trigger_should_return_known_string()
        {
            var request = TestFactory.CreateHttpRequest("name", "Bernardo");
            var response = (OkObjectResult)await MyHttpTrigger.Run(request, logger);
            Assert.Equal("Hello, Bernardo. This HTTP triggered function executed successfully.", response.Value);
        }

        [Theory]
        [MemberData(nameof(TestFactory.Data), MemberType = typeof(TestFactory))]
        public async void Http_trigger_should_return_known_string_from_member_data(string queryStringKey, string queryStringValue)
        {
            var request = TestFactory.CreateHttpRequest(queryStringKey, queryStringValue);
            var response = (OkObjectResult)await MyHttpTrigger.Run(request, logger);
            Assert.Equal($"Hello, {queryStringValue}. This HTTP triggered function executed successfully.", response.Value);
        }

        [Fact]
        public void Timer_should_log_message()
        {
            var logger = (ListLogger)TestFactory.CreateLogger(LoggerTypes.List);
            new MyTimerTrigger().Run(null, logger);
            var msg = logger.Logs[0];
            Assert.Contains("C# Timer trigger function executed at", msg);
        }
    }
}

이 클래스는 다음 멤버를 구현합니다.

Http_trigger_should_return_known_string: 이 테스트는 쿼리 문자열 값을 name=Bernardo 사용하여 HTTP 함수에 대한 요청을 만듭니다. 이 테스트는 예상 응답이 반환되는지 확인합니다.
Http_trigger_should_return_string_from_member_data: 이 테스트는 xUnit 특성을 사용하여 HTTP 함수에 샘플 데이터를 제공합니다.
Timer_should_log_message: 이 테스트는 인스턴스 ListLogger 를 만들어 타이머 함수에 전달합니다. 함수가 실행되면 로그가 확인되어 예상 메시지가 있는지 확인합니다.

테스트의 애플리케이션 설정에 액세스하려면 모의 환경 변수 값을 사용하여 구현을 함수에 IConfiguration할 수 있습니다.

3단계: 테스트 실행

Visual Studio에서 테스트를 실행하려면테스트 탐색기> 선택합니다. 테스트 탐색기에서보기에서 모든 테스트 실행을> 선택합니다.

Visual Studio의 스크린샷. 테스트 탐색기는 5개의 테스트가 통과되었음을 보여 줍니다. 솔루션 탐색기에서 Functions 및 Functions.Test 프로젝트가 표시됩니다.

4단계: 테스트 디버그

테스트를 디버그하려면 테스트에 중단점을 설정합니다. 테스트 탐색기에서마지막으로 디버그 실행을> 선택합니다.

Core Tools를 사용하여 로컬로 Azure Functions 개발

C# In Process 모델 가이드

C# 격리 작업자 모델 가이드

피드백

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

Last updated on 2025-09-23