ASP.NET Core 면접 질문 25선: 미들웨어, DI, Minimal API 완벽 정리

ASP.NET Core는 현대 웹 개발에서 가장 널리 사용되는 프레임워크 중 하나로 자리잡았습니다. 기술 면접에서 미들웨어 파이프라인, 의존성 주입(DI), 그리고 Minimal API에 대한 깊이 있는 이해는 필수적입니다. 이 글에서는 ASP.NET Core 면접에서 자주 출제되는 25가지 핵심 질문을 체계적으로 정리하고, 각 질문에 대해 실무에서 바로 활용할 수 있는 답변을 제공합니다.

미들웨어 파이프라인 (질문 1-6)

1. ASP.NET Core의 미들웨어란 무엇이며, 요청 파이프라인에서 어떤 역할을 합니까?

미들웨어는 HTTP 요청과 응답을 처리하는 소프트웨어 구성 요소입니다. 각 미들웨어는 파이프라인에서 요청을 받아 처리한 후 다음 미들웨어로 전달하거나, 직접 응답을 생성하여 파이프라인을 단락(short-circuit)시킬 수 있습니다. 이 구조는 러시안 인형(마트료시카)과 유사한 형태로, 요청은 바깥에서 안쪽으로, 응답은 안쪽에서 바깥으로 흐릅니다. 인증, 로깅, 예외 처리, 정적 파일 제공 등 횡단 관심사(cross-cutting concerns)를 모듈화하는 데 핵심적인 역할을 합니다.

2. 미들웨어의 실행 순서가 중요한 이유는 무엇이며, 올바른 순서는 어떻게 됩니까?

미들웨어는 Program.cs에 등록된 순서대로 실행됩니다. 순서가 잘못되면 보안 취약점이 발생하거나 기능이 정상적으로 동작하지 않을 수 있습니다. 예를 들어, UseAuthentication이 UseAuthorization보다 뒤에 오면 인증되지 않은 사용자가 보호된 리소스에 접근할 수 있습니다.

var app = builder.Build();

app.UseExceptionHandler("/error");   // 1. Outermost: catches all exceptions
app.UseHsts();                        // 2. HTTP Strict Transport Security
app.UseHttpsRedirection();            // 3. Redirect HTTP to HTTPS
app.UseStaticFiles();                 // 4. Serve static files (short-circuits if found)
app.UseRouting();                     // 5. Match request to endpoint
app.UseAuthentication();              // 6. Identify the user
app.UseAuthorization();               // 7. Check permissions
app.MapControllers();                 // 8. Execute the matched endpoint

app.Run();

UseExceptionHandler가 가장 바깥에 위치하여 모든 예외를 포착하고, UseStaticFiles는 정적 파일 요청 시 나머지 파이프라인을 건너뛸 수 있도록 라우팅 전에 배치됩니다.

3. 커스텀 미들웨어는 어떻게 작성합니까?

커스텀 미들웨어는 RequestDelegate를 생성자에서 받고, InvokeAsync 메서드를 구현하는 클래스로 작성합니다. 생성자 주입을 통해 로거 등의 서비스를 주입받을 수 있으며, _next(context)를 호출하여 다음 미들웨어로 요청을 전달합니다.

public class RequestTimingMiddleware
{
    private readonly RequestDelegate _next;
    private readonly ILogger<RequestTimingMiddleware> _logger;

    public RequestTimingMiddleware(RequestDelegate next, ILogger<RequestTimingMiddleware> logger)
    {
        _next = next;
        _logger = logger;
    }

    public async Task InvokeAsync(HttpContext context)
    {
        var stopwatch = Stopwatch.StartNew();
        
        await _next(context);  // Call the next middleware
        
        stopwatch.Stop();
        _logger.LogInformation(
            "Request {Method} {Path} completed in {Elapsed}ms",
            context.Request.Method,
            context.Request.Path,
            stopwatch.ElapsedMilliseconds);
    }
}

// Registration in Program.cs
app.UseMiddleware<RequestTimingMiddleware>();

이 패턴은 요청 처리 시간을 측정하는 실용적인 예시입니다. _next 호출 전후로 로직을 배치하여 요청과 응답 양쪽 모두에서 작업을 수행할 수 있습니다.

4. 미들웨어에서 파이프라인을 단락(short-circuit)시키는 방법과 적절한 사용 시나리오는 무엇입니까?

_next(context)를 호출하지 않으면 파이프라인이 단락됩니다. 이 기법은 특정 조건에서 요청을 즉시 거부해야 할 때 유용합니다. 예를 들어, IP 차단 미들웨어에서 블랙리스트에 있는 IP의 요청을 즉시 403으로 응답하거나, 요청 빈도 제한(rate limiting) 미들웨어에서 제한을 초과한 요청에 429 상태 코드를 반환하는 경우가 있습니다. 단락은 불필요한 처리를 방지하여 성능을 향상시키지만, 남용하면 디버깅이 어려워지므로 신중하게 사용해야 합니다.

5. Map, MapWhen, UseWhen의 차이점은 무엇입니까?

Map은 특정 경로 접두사에 따라 파이프라인을 분기하며, 분기된 파이프라인은 기존 파이프라인과 완전히 분리됩니다. MapWhen은 요청의 특정 조건(헤더, 쿼리 스트링 등)에 따라 분기하며, 역시 독립적인 파이프라인을 생성합니다. 반면 UseWhen은 조건부로 미들웨어를 실행하되, 기존 파이프라인에 다시 합류합니다. 분기 후 메인 파이프라인으로 돌아와야 하는 경우에는 UseWhen을 사용하는 것이 적합합니다.

6. 미들웨어와 액션 필터(Action Filter)의 차이점은 무엇입니까?

미들웨어는 전체 HTTP 파이프라인 수준에서 동작하며 모든 요청에 적용됩니다. 액션 필터는 MVC/Razor Pages 파이프라인 내부에서 동작하며, 특정 컨트롤러나 액션 메서드에만 적용됩니다. 미들웨어는 라우팅 전에도 실행할 수 있지만, 액션 필터는 라우팅이 완료된 후에만 실행됩니다. 따라서 인증이나 로깅처럼 애플리케이션 전체에 적용되는 횡단 관심사는 미들웨어로, 모델 검증이나 특정 액션의 캐싱처럼 세밀한 제어가 필요한 경우에는 액션 필터로 구현하는 것이 바람직합니다.

의존성 주입 (질문 7-12)

7. ASP.NET Core에서 지원하는 서비스 생명주기 세 가지는 무엇입니까?

ASP.NET Core의 내장 DI 컨테이너는 세 가지 생명주기를 지원합니다. Transient는 요청할 때마다 새 인스턴스를 생성하며, 가벼운 무상태 서비스에 적합합니다. Scoped는 하나의 HTTP 요청(또는 스코프) 내에서 동일한 인스턴스를 공유하며, DbContext와 같이 요청 단위로 상태를 유지해야 하는 서비스에 사용합니다. Singleton은 애플리케이션 전체에서 단일 인스턴스를 유지하며, 구성 정보나 캐시처럼 공유 상태가 필요한 서비스에 적합합니다.

8. Scoped 서비스를 Singleton에 주입하면 어떤 문제가 발생합니까?

이를 종속 의존성(captive dependency) 문제라고 합니다. Singleton 서비스는 애플리케이션이 종료될 때까지 유지되므로, 그 안에 주입된 Scoped 서비스도 함께 유지됩니다. 결과적으로 Scoped 서비스가 의도된 것보다 훨씬 오래 살아남아, 메모리 누수나 동시성 문제, 오래된 데이터 사용 등의 심각한 버그가 발생할 수 있습니다.

builder.Services.AddScoped<IUserRepository, UserRepository>();
builder.Services.AddSingleton<ICacheService, CacheService>(); // CacheService takes IUserRepository

// This throws at startup in Development when ValidateScopes is enabled:
builder.Host.UseDefaultServiceProvider(options =>
{
    options.ValidateScopes = true;    // Catches captive dependencies
    options.ValidateOnBuild = true;   // Validates all registrations at startup
});

9. 키 기반 서비스(Keyed Services)란 무엇이며 어떻게 사용합니까?

.NET 8에서 도입된 키 기반 서비스는 동일한 인터페이스에 대해 여러 구현체를 등록하고 키로 구분하여 해석할 수 있는 기능입니다. 기존에는 팩토리 패턴이나 제3자 DI 컨테이너를 사용해야 했던 시나리오를 내장 DI 컨테이너만으로 해결할 수 있습니다.

builder.Services.AddKeyedSingleton<INotificationService, EmailNotification>("email");
builder.Services.AddKeyedSingleton<INotificationService, SmsNotification>("sms");
builder.Services.AddKeyedSingleton<INotificationService, PushNotification>("push");

// Resolving in a controller or service
public class OrderService
{
    public OrderService(
        [FromKeyedServices("email")] INotificationService emailService,
        [FromKeyedServices("sms")] INotificationService smsService)
    {
        // Each parameter gets its specific implementation
    }
}

[FromKeyedServices] 특성을 사용하여 생성자에서 특정 구현체를 명시적으로 요청할 수 있어 코드의 의도가 명확해집니다.

10. AddDbContext와 AddDbContextFactory의 차이점은 무엇입니까?

AddDbContext는 DbContext를 Scoped 서비스로 등록하여 요청당 하나의 인스턴스를 제공합니다. 대부분의 웹 애플리케이션에서 적합한 방식입니다. AddDbContextFactory는 DbContext를 직접 등록하는 대신 팩토리를 등록하여, 필요할 때마다 새 DbContext 인스턴스를 생성할 수 있게 합니다. 이는 Blazor Server처럼 긴 수명의 스코프를 가지거나, 백그라운드 서비스에서 여러 개의 DbContext를 병렬로 사용해야 하는 경우에 유용합니다. 팩토리를 사용하면 DbContext의 생명주기를 직접 제어할 수 있으므로 using 문으로 명시적으로 해제하는 것이 권장됩니다.

11. 데코레이터 패턴을 DI에서 어떻게 구현합니까?

ASP.NET Core의 내장 DI 컨테이너는 데코레이터 패턴을 직접 지원하지 않지만, 팩토리 오버로드를 활용하여 구현할 수 있습니다. 이 방식은 기존 서비스에 캐싱, 로깅, 재시도 등의 횡단 관심사를 추가할 때 유용합니다.

// Decorating IProductService with caching
builder.Services.AddScoped<ProductService>();
builder.Services.AddScoped<IProductService>(sp =>
{
    var inner = sp.GetRequiredService<ProductService>();
    var cache = sp.GetRequiredService<IMemoryCache>();
    return new CachedProductService(inner, cache);
});

CachedProductService는 IProductService를 구현하면서 내부적으로 실제 ProductService를 감싸, 캐시에 데이터가 있으면 캐시에서 반환하고 없으면 원본 서비스를 호출하는 방식으로 동작합니다.

12. IServiceProvider를 직접 주입하는 것이 왜 안티패턴입니까?

IServiceProvider를 직접 주입하는 것은 서비스 로케이터 패턴에 해당하며, 여러 문제점이 있습니다. 첫째, 클래스의 실제 의존성이 생성자 시그니처에 드러나지 않아 코드 가독성이 떨어집니다. 둘째, 컴파일 시점에 의존성 누락을 감지할 수 없어 런타임 오류의 위험이 높아집니다. 셋째, 단위 테스트에서 모킹이 복잡해집니다. 대신 필요한 서비스를 생성자를 통해 명시적으로 주입받는 것이 올바른 방식이며, 지연 초기화가 필요한 경우에는 Lazy<T>나 팩토리 패턴을 활용하는 것이 권장됩니다.

Minimal API (질문 13-18)

13. Minimal API란 무엇이며 기존 컨트롤러 방식과 어떤 차이가 있습니까?

Minimal API는 .NET 6에서 도입된 경량 HTTP API 구축 방식입니다. 컨트롤러, 액션 메서드, 라우팅 특성 없이 람다 표현식이나 메서드 그룹으로 엔드포인트를 직접 정의합니다. 컨트롤러 기반 방식에 비해 보일러플레이트 코드가 대폭 줄어들고 성능도 약간 우수합니다. 다만 필터 파이프라인이나 모델 바인딩 측면에서 컨트롤러만큼 풍부한 기능을 제공하지는 않으므로, 마이크로서비스나 간단한 API에 적합합니다.

14. Minimal API에서 엔드포인트를 체계적으로 구성하는 방법은 무엇입니까?

Program.cs에 모든 엔드포인트를 나열하면 코드가 비대해지므로, 확장 메서드를 활용하여 기능별로 엔드포인트를 분리하는 것이 좋습니다. MapGroup을 사용하면 경로 접두사, 인증 정책, 태그 등을 그룹 단위로 적용할 수 있습니다.

public static class ProductEndpoints
{
    public static void MapProductEndpoints(this WebApplication app)
    {
        var group = app.MapGroup("/api/products")
            .WithTags("Products")
            .RequireAuthorization();

        group.MapGet("/", GetAll);
        group.MapGet("/{id:int}", GetById);
        group.MapPost("/", Create);
    }

    private static async Task<IResult> GetAll(
        IProductService productService,    // Auto-resolved from DI
        CancellationToken cancellationToken)
    {
        var products = await productService.GetAllAsync(cancellationToken);
        return TypedResults.Ok(products);
    }

    private static async Task<IResult> GetById(
        int id,
        IProductService productService)
    {
        var product = await productService.GetByIdAsync(id);
        return product is null
            ? TypedResults.NotFound()
            : TypedResults.Ok(product);
    }

    private static async Task<IResult> Create(
        CreateProductRequest request,
        IProductService productService)
    {
        var product = await productService.CreateAsync(request);
        return TypedResults.Created($"/api/products/{product.Id}", product);
    }
}

// Program.cs — Clean registration
app.MapProductEndpoints();

이 구조는 기능별 폴더(Feature Folder) 패턴과 자연스럽게 어울리며, 각 도메인의 엔드포인트를 독립적으로 관리할 수 있습니다.

15. TypedResults와 Results의 차이점은 무엇입니까?

Results는 IResult를 반환하는 정적 팩토리 메서드를 제공합니다. TypedResults는 각 결과에 대한 구체적인 타입(예: Ok<T>, NotFound 등)을 반환합니다. TypedResults를 사용하면 OpenAPI(Swagger) 문서가 자동으로 올바른 응답 스키마를 생성하므로, API 문서화가 필요한 프로젝트에서는 TypedResults를 사용하는 것이 권장됩니다. 또한 반환 타입이 명확해져 컴파일 시점에 타입 안전성을 확보할 수 있습니다.

16. Minimal API에서 유효성 검사는 어떻게 구현합니까?

Minimal API에는 컨트롤러의 [ApiController]가 제공하는 자동 모델 검증 기능이 없으므로, 수동으로 구현해야 합니다. FluentValidation이나 System.ComponentModel.DataAnnotations를 엔드포인트 필터와 결합하여 사용하는 것이 일반적입니다. 엔드포인트 필터를 활용하면 유효성 검사 로직을 비즈니스 로직과 분리할 수 있어 코드의 재사용성과 유지보수성이 향상됩니다. .NET 8부터는 AddEndpointFilter를 통해 필터 체인을 구성할 수 있습니다.

17. Minimal API에서 라우트 그룹(Route Groups)의 장점은 무엇입니까?

MapGroup을 사용하면 공통 경로 접두사, 필터, 메타데이터를 그룹 단위로 적용할 수 있습니다. 이를 통해 코드 중복을 줄이고, 인증 정책이나 CORS 설정을 그룹별로 다르게 구성할 수 있습니다. 그룹은 중첩이 가능하여 /api/v1/products와 같은 버전별 경로 구조도 깔끔하게 표현할 수 있습니다. 또한 그룹에 적용된 설정은 하위 모든 엔드포인트에 자동으로 상속되므로 일관성 유지가 용이합니다.

18. Minimal API와 gRPC, SignalR를 함께 사용할 수 있습니까?

가능합니다. ASP.NET Core는 하나의 호스트에서 Minimal API, gRPC, SignalR을 모두 실행할 수 있습니다. 각 프로토콜은 별도의 엔드포인트로 매핑되며, 미들웨어 파이프라인을 공유합니다. 예를 들어, REST API는 Minimal API로, 실시간 통신은 SignalR로, 서비스 간 통신은 gRPC로 구현하는 복합 아키텍처가 가능합니다. 인증 미들웨어와 같은 횡단 관심사는 모든 프로토콜에 공통으로 적용됩니다.

심화 질문 (질문 19-25)

19. 미들웨어를 단위 테스트하는 방법은 무엇입니까?

미들웨어는 DefaultHttpContext를 사용하여 가짜 HTTP 컨텍스트를 생성하고, 터미널 대리자를 제공하여 테스트할 수 있습니다. 로거와 같은 의존성은 테스트 더블(fake, mock)을 주입합니다.

[Fact]
public async Task Middleware_LogsElapsedTime()
{
    var logger = new FakeLogger<RequestTimingMiddleware>();
    var middleware = new RequestTimingMiddleware(
        next: (ctx) => Task.CompletedTask,  // Terminal delegate
        logger: logger);

    var context = new DefaultHttpContext();
    context.Request.Method = "GET";
    context.Request.Path = "/api/products";

    await middleware.InvokeAsync(context);

    Assert.Single(logger.LogEntries);
    Assert.Contains("completed in", logger.LogEntries[0].Message);
}

next 매개변수에 Task.CompletedTask를 반환하는 터미널 대리자를 전달하여 파이프라인의 나머지 부분을 시뮬레이션합니다. 이 방식으로 미들웨어를 격리하여 독립적으로 검증할 수 있습니다.

20. IHostedService와 BackgroundService의 차이점은 무엇입니까?

IHostedService는 StartAsync와 StopAsync 두 메서드를 정의하는 인터페이스입니다. BackgroundService는 IHostedService를 구현한 추상 클래스로, ExecuteAsync 메서드만 오버라이드하면 됩니다. 단순한 백그라운드 작업에는 BackgroundService가 편리하고, 시작/종료 시 복잡한 초기화나 정리 작업이 필요한 경우에는 IHostedService를 직접 구현하는 것이 적합합니다. 두 방식 모두 DI 컨테이너에 AddHostedService로 등록하며, Scoped 서비스를 사용하려면 IServiceScopeFactory를 주입받아 수동으로 스코프를 생성해야 합니다.

21. 옵션 패턴(Options Pattern)이란 무엇이며 어떻게 사용합니까?

옵션 패턴은 구성 값을 강력한 타입의 클래스로 바인딩하는 ASP.NET Core의 권장 방식입니다. IOptions<T>는 싱글톤으로 한 번만 읽히고, IOptionsSnapshot<T>는 요청마다 갱신되며, IOptionsMonitor<T>는 실시간으로 변경 사항을 감지합니다. DataAnnotation을 사용한 유효성 검사를 ValidateDataAnnotations()와 ValidateOnStart()로 연결하면, 잘못된 구성을 애플리케이션 시작 시점에 감지할 수 있어 운영 환경의 안정성이 크게 향상됩니다.

22. Health Check는 어떻게 구현하며 왜 중요합니까?

Health Check는 애플리케이션의 상태를 외부 시스템(로드 밸런서, Kubernetes 등)에 노출하는 메커니즘입니다. AddHealthChecks()로 서비스를 등록하고 MapHealthChecks()로 엔드포인트를 매핑합니다. 데이터베이스 연결, 외부 API 접근성, 디스크 공간 등을 검사하는 커스텀 Health Check를 IHealthCheck 인터페이스를 구현하여 추가할 수 있습니다. Kubernetes 환경에서는 liveness probe와 readiness probe를 분리하여 구성하는 것이 일반적입니다.

23. Rate Limiting 미들웨어는 어떻게 구성합니까?

.NET 7에서 도입된 내장 Rate Limiting 미들웨어는 네 가지 알고리즘을 지원합니다. Fixed Window는 고정 시간 창 내에서 요청 수를 제한하고, Sliding Window는 이동 시간 창을 사용하여 더 균일하게 제한합니다. Token Bucket은 토큰 기반으로 요청을 허용하고, Concurrency는 동시 요청 수를 제한합니다. AddRateLimiter로 정책을 등록하고 UseRateLimiter로 미들웨어를 추가하며, 특정 엔드포인트에 RequireRateLimiting("정책명")으로 정책을 적용합니다.

24. Output Caching과 Response Caching의 차이점은 무엇입니까?

Response Caching은 HTTP 캐시 헤더(Cache-Control, Vary)를 기반으로 동작하며, 주로 클라이언트 측 또는 CDN에서 캐싱이 이루어집니다. Output Caching은 .NET 7에서 도입된 서버 측 캐싱 메커니즘으로, 서버 메모리에 응답을 저장합니다. Output Caching은 캐시 무효화를 태그 기반으로 세밀하게 제어할 수 있고, 인증된 요청에 대해서도 캐싱이 가능하다는 장점이 있습니다. 두 방식을 적절히 조합하면 서버 부하를 크게 줄이면서도 데이터의 신선도를 유지할 수 있습니다.

25. AOT(Ahead-of-Time) 컴파일이 Minimal API에 미치는 영향은 무엇입니까?

.NET 8부터 Minimal API는 Native AOT 컴파일을 지원합니다. AOT는 애플리케이션을 네이티브 바이너리로 컴파일하여 시작 시간을 대폭 단축하고 메모리 사용량을 줄입니다. 그러나 리플렉션에 의존하는 기능(동적 JSON 직렬화, 일부 DI 패턴 등)은 제한됩니다. AOT 환경에서는 JsonSerializerContext를 사용한 소스 생성 직렬화, [JsonSerializable] 특성 활용이 필수적입니다. 컨트롤러 기반 API는 현재 AOT를 완전히 지원하지 않으므로, AOT가 필요한 프로젝트에서는 Minimal API를 선택하는 것이 유리합니다.

결론

ASP.NET Core 면접을 성공적으로 준비하기 위해 핵심적으로 파악해야 할 사항을 정리하면 다음과 같습니다.

• 미들웨어 파이프라인: 실행 순서의 중요성, 커스텀 미들웨어 작성법, 단락 메커니즘, 분기 전략을 확실히 이해해야 합니다.
• 의존성 주입: Transient, Scoped, Singleton 생명주기의 차이와 종속 의존성 문제, 키 기반 서비스, 데코레이터 패턴 등 실무에서 자주 마주치는 패턴을 숙지해야 합니다.
• Minimal API: 엔드포인트 구성 전략, TypedResults 활용, 라우트 그룹, AOT 호환성 등 최신 API 구축 방식에 대한 이해가 필요합니다.
• 심화 주제: Health Check, Rate Limiting, Output Caching, 옵션 패턴 등 운영 환경에서 필수적인 기능들을 실제로 구현해볼 수 있어야 합니다.

이 25가지 질문은 ASP.NET Core의 핵심 영역을 포괄적으로 다루고 있습니다. 각 질문의 답변을 단순히 암기하기보다는 원리를 이해하고, 실제 코드로 구현해보면서 체화하는 것이 중요합니다. SharpSkill에서 ASP.NET Core 관련 기술 면접 문제를 실전처럼 연습하며 부족한 부분을 체계적으로 보완할 수 있습니다.