Developer Tooling | The .NET Blog

azd + GitHub Copilot: AI 기반 프로젝트 설정과 스마트 오류 해결

Emiliano Montesdeoca — Tue, 21 Apr 2026 00:00:00 +0000

이 글은 자동 번역되었습니다. 영어 원문은 여기에서 확인할 수 있습니다.

기존 앱을 Azure에 배포하려고 할 때, 빈 azure.yaml 파일을 보며 Express API가 Container Apps를 써야 할지 App Service를 써야 할지 떠올리려 했던 경험 있으신가요? 그런 순간이 이제 훨씬 짧아집니다.

Azure Developer CLI(azd)가 GitHub Copilot과 두 가지 방식으로 통합되었습니다: azd init 실행 시 AI 지원 프로젝트 스캐폴딩, 그리고 배포 실패 시 지능형 오류 트러블슈팅. 두 기능 모두 터미널 안에서 완전히 동작합니다 — 딱 원하는 방식입니다.

azd init에서 Copilot 설정

azd init을 실행하면 이제 “Set up with GitHub Copilot (Preview)” 옵션이 나타납니다. 선택하면 Copilot이 코드베이스를 분석하여 실제 코드를 기반으로 azure.yaml, 인프라 템플릿, Bicep 모듈을 생성합니다.

azd init
# 선택: "Set up with GitHub Copilot (Preview)"

필요한 것들:

azd 1.23.11 이상 — azd version으로 확인하거나 azd update로 업데이트
활성 GitHub Copilot 구독 (Individual, Business 또는 Enterprise)
GitHub CLI (gh) — 필요 시 azd가 로그인을 요청함

정말 유용한 점은 양방향으로 동작한다는 것입니다. 처음부터 빌드한다면? Copilot이 처음부터 올바른 Azure 서비스를 설정하도록 도와줍니다. 배포하고 싶은 기존 앱이 있다면? Copilot을 그쪽으로 지향하면 코드 구조를 바꾸지 않고도 설정을 생성해 줍니다.

실제로 무엇을 하나

PostgreSQL 의존성이 있는 Node.js Express API가 있다고 합시다. Container Apps와 App Service 중 무엇을 선택할지 수동으로 결정하고 Bicep을 처음부터 작성하는 대신, Copilot이 스택을 감지하고 다음을 생성합니다:

올바른 language, host, build 설정이 담긴 azure.yaml
Azure Container Apps를 위한 Bicep 모듈
Azure Database for PostgreSQL을 위한 Bicep 모듈

그리고 무언가를 변경하기 전에 사전 검사를 실행합니다 — git 작업 디렉토리가 깨끗한지 확인하고, MCP 서버 도구 동의를 미리 요청합니다. 무엇이 바뀌는지 정확히 알고 난 뒤에만 진행됩니다.

Copilot 기반 오류 트러블슈팅

배포 오류는 피할 수 없습니다. 누락된 파라미터, 권한 문제, SKU 가용성 문제 — 그리고 오류 메시지는 정작 필요한 것을 알려주지 않습니다: 어떻게 고치는가.

Copilot 없이는: 오류 복사 → 문서 검색 → 관련 없는 Stack Overflow 답변 3개 읽기 → az CLI 명령어 실행 → 다시 시도하며 기도. azd에 Copilot이 통합되면 이 루프가 사라집니다. azd 명령이 실패하면 즉시 4가지 옵션을 제공합니다:

Explain — 무엇이 잘못됐는지 알기 쉬운 설명
Guidance — 수정을 위한 단계별 지침
Diagnose and Guide — 완전한 분석 + Copilot이 수정 적용 (승인 후) + 선택적 재시도
Skip — 직접 처리

핵심: Copilot은 이미 프로젝트, 실패한 명령, 오류 세부 정보의 컨텍스트를 갖고 있습니다. 제안은 여러분의 상황에 맞게 구체적입니다.

기본 동작 설정

항상 같은 옵션을 선택한다면, 인터랙티브 프롬프트를 건너뛸 수 있습니다:

azd config set copilot.errorHandling.category troubleshoot

값: explain, guidance, troubleshoot, fix, skip. 자동 수정 및 재시도도 활성화할 수 있습니다:

azd config set copilot.errorHandling.fix allow

언제든지 인터랙티브 모드로 되돌리기:

azd config unset copilot.errorHandling.category

마무리

azd update로 최신 버전을 받고 다음 프로젝트에서 azd init을 써보세요. 진정한 가치를 주는 Copilot 통합입니다.

원문 발표를 여기서 읽어보세요.

C#와 .NET Native AOT로 Node.js 네이티브 애드온 작성하기

Emiliano Montesdeoca — Tue, 21 Apr 2026 00:00:00 +0000

이 글은 자동 번역되었습니다. 영어 원문은 여기에서 확인할 수 있습니다.

제가 좋아하는 시나리오입니다. .NET 도구를 개발하는 팀이 C++로 작성하고 node-gyp으로 컴파일하는 네이티브 Node.js 애드온을 사용하고 있었습니다. 동작했습니다. 하지만 팀원 누구도 직접 건드리지 않을 패키지를 빌드하기 위해 모든 개발자 기기에 Python(그것도 구버전)을 설치해야 했습니다.

그래서 매우 합리적인 질문을 했습니다: .NET SDK가 이미 설치되어 있는데, 왜 C++를 쓰는 걸까요?

답은 Native AOT였고, 결과는 정말 우아합니다.

기본 아이디어

Node.js 네이티브 애드온은 Node.js가 런타임에 로드할 수 있는 공유 라이브러리(Windows의 .dll, Linux의 .so, macOS의 .dylib)입니다. 인터페이스는 N-API—안정적이고 ABI 호환 가능한 C API입니다. N-API는 라이브러리가 어떤 언어로 만들어졌는지 신경 쓰지 않고, 올바른 심볼을 내보내는지만 확인합니다.

.NET Native AOT는 정확히 그것을 만들 수 있습니다. C# 코드를 임의의 진입점을 가진 네이티브 공유 라이브러리로 미리 컴파일합니다. 이것이 전부입니다.

프로젝트 설정

프로젝트 파일은 최소화됩니다:

<Project Sdk="Microsoft.NET.Sdk">
 <PropertyGroup>
 <TargetFramework>net10.0</TargetFramework>
 <PublishAot>true</PublishAot>
 <AllowUnsafeBlocks>true</AllowUnsafeBlocks>
 </PropertyGroup>
</Project>

PublishAot은 dotnet publish 시 공유 라이브러리를 생성하도록 SDK에 지시합니다. AllowUnsafeBlocks는 함수 포인터와 고정 버퍼를 사용하는 N-API interop에 필요합니다.

진입점 내보내기

Node.js는 라이브러리가 napi_register_module_v1을 내보낼 것을 기대합니다. C#에서는 [UnmanagedCallersOnly]가 정확히 그 역할을 합니다:

public static unsafe partial class RegistryAddon
{
 [UnmanagedCallersOnly(
 EntryPoint = "napi_register_module_v1",
 CallConvs = [typeof(CallConvCdecl)])]
 public static nint Init(nint env, nint exports)
 {
 Initialize();
 RegisterFunction(env, exports, "readStringValue"u8, &ReadStringValue);
 return exports;
 }
}

주목할 점들: nint는 네이티브 크기 정수로 intptr_t의 관리형 등가물입니다. u8 접미사는 UTF-8 문자열 리터럴을 담은 ReadOnlySpan<byte>를 생성하여 인코딩 할당 없이 N-API에 직접 전달됩니다. [UnmanagedCallersOnly]는 Node.js가 찾는 정확한 진입점 이름으로 메서드를 내보냅니다.

N-API를 호스트 프로세스에 대해 해석하기

N-API 함수는 별도의 라이브러리가 아닌 node.exe 자체에서 내보냅니다. 따라서 무언가에 링크하는 대신, 시작 시 실행 중인 프로세스에 대해 해석합니다:

private static void Initialize()
{
 NativeLibrary.SetDllImportResolver(
 System.Reflection.Assembly.GetExecutingAssembly(),
 ResolveDllImport);

 static nint ResolveDllImport(
 string libraryName, Assembly assembly, DllImportSearchPath? searchPath)
 {
 if (libraryName is not "node") return 0;
 return NativeLibrary.GetMainProgramHandle();
 }
}

이를 통해 P/Invoke 선언이 [LibraryImport]와 소스 생성 마샬링으로 올바르게 동작합니다.

실제 내보낸 함수

그들이 구현한 레지스트리 읽기 함수:

[UnmanagedCallersOnly(CallConvs = [typeof(CallConvCdecl)])]
private static nint ReadStringValue(nint env, nint info)
{
 try
 {
 var keyPath = GetStringArg(env, info, 0);
 var valueName = GetStringArg(env, info, 1);

 if (keyPath is null || valueName is null)
 {
 ThrowError(env, "Expected two string arguments: keyPath, valueName");
 return 0;
 }

 using var key = Registry.CurrentUser.OpenSubKey(keyPath, writable: false);

 return key?.GetValue(valueName) is string value
 ? CreateString(env, value)
 : GetUndefined(env);
 }
 catch (Exception ex)
 {
 ThrowError(env, $"Registry read failed: {ex.Message}");
 return 0;
 }
}

try/catch에 대한 중요한 참고사항: [UnmanagedCallersOnly] 메서드에서 처리되지 않은 예외는 호스트 프로세스를 충돌시킵니다. 항상 예외를 잡아 ThrowError를 통해 JavaScript에 전달하세요.

TypeScript에서 호출하기

const registry = require('./native/win32-x64/RegistryAddon.node') as RegistryAddon;
const sdkPath = registry.readStringValue(
 'SOFTWARE\\dotnet\\Setup\\InstalledVersions\\x64\\sdk', 'InstallLocation');

TypeScript → C#, Python 없음, C++ 없음.

얻은 것

즉각적인 승리는 기여자 경험이었습니다: 특정 Python 버전이 더 이상 필요 없고, yarn install은 Node.js와 .NET SDK만으로 동작합니다. CI 파이프라인도 단순해졌습니다. 성능은 C++ 구현과 비슷했습니다.

마무리

C# Dev Kit 팀은 Python/C++ 복잡성을 팀 모두가 이미 작성하고 디버그할 줄 아는 깔끔한 C# 코드로 대체했습니다. 모든 문자열 마샬링 헬퍼를 포함한 전체 안내는 .NET 블로그 원문을 참고하세요.