ASP.NET 미드레벨 프레임워크 기술면접

ASP.NET Core의 미들웨어는 요청 파이프라인을 구성하는 컴포넌트로, Use 메서드로 등록된 순서대로 체인 형태로 실행됩니다. 각 미들웨어는 next() 호출을 통해 다음 미들웨어로 제어를 넘기며, 응답 시에는 역순으로 처리됩니다. Middleware는 애플리케이션 전역에서 동작하며 모든 HTTP 요청에 적용되는 반면, Filter는 MVC 파이프라인 내에서만 동작하고 컨트롤러/액션 단위로 적용됩니다. 인증, 로깅, 에러 핸들링처럼 전역적인 처리는 Middleware로, 특정 컨트롤러의 권한 검증이나 모델 검증은 Filter로 구현하는 것이 적절합니다. Filter는 ActionFilter, ExceptionFilter, AuthorizationFilter 등 타입별로 세분화되어 있어 MVC 컨텍스트에 접근할 수 있다는 장점이 있습니다.

Transient는 요청할 때마다 새 인스턴스를 생성하고, Scoped는 HTTP 요청당 하나의 인스턴스를 공유하며, Singleton은 애플리케이션 생명주기 동안 하나의 인스턴스만 사용합니다. DbContext는 스레드 안전하지 않으며 동시성 문제를 방지하기 위해 설계된 것이 아니기 때문에 Singleton으로 등록하면 안 됩니다. Singleton으로 등록 시 여러 요청이 동시에 같은 DbContext 인스턴스를 사용하게 되어 데이터 불일치, 예외 발생, 메모리 누수 등의 문제가 발생합니다. DbContext는 변경 추적기(ChangeTracker)를 내부적으로 관리하므로, 요청별로 독립적인 인스턴스가 필요하여 Scoped로 등록해야 합니다. Scoped 등록을 통해 각 HTTP 요청마다 새로운 DbContext가 생성되고 요청 종료 시 자동으로 Dispose되어 리소스가 적절히 해제됩니다.

ConfigureAwait(false)는 await 이후 코드를 원래의 동기화 컨텍스트로 돌아가지 않고 스레드 풀의 아무 스레드에서나 실행하도록 합니다. ASP.NET Framework에서는 각 요청마다 SynchronizationContext가 있어 컨텍스트 전환 비용이 발생하므로, 라이브러리 코드에서 ConfigureAwait(false)를 사용해 성능을 개선했습니다. 반면 ASP.NET Core는 SynchronizationContext가 없는 구조로 설계되어 기본적으로 스레드 풀에서 continuation이 실행되므로 ConfigureAwait(false)가 불필요합니다. async void는 예외가 발생했을 때 호출자가 catch할 수 없고 SynchronizationContext에 직접 던져져 애플리케이션이 크래시될 수 있습니다. 또한 async void 메서드는 완료를 기다릴 수 없어 테스트가 어렵고, 여러 비동기 작업의 조율이 불가능합니다. 이벤트 핸들러를 제외하고는 항상 async Task를 사용해야 하며, 반환값이 없어도 Task를 반환하여 예외 처리와 작업 완료 대기를 가능하게 해야 합니다.

Model Binding은 HTTP 요청에서 데이터를 추출하여 액션 메서드의 파라미터나 모델 객체에 자동으로 매핑하는 프로세스입니다. FromBody는 요청 본문의 JSON/XML을 역직렬화하여 바인딩하며 주로 POST/PUT에서 사용하고, FromQuery는 쿼리 스트링에서, FromRoute는 URL 경로에서, FromForm은 폼 데이터에서 값을 추출합니다. RESTful API에서는 리소스 식별자는 FromRoute로, 필터링/페이징 조건은 FromQuery로, 생성/수정할 데이터는 FromBody로 받는 것이 일반적입니다. 커스텀 모델 바인더는 쉼표로 구분된 문자열을 List로 변환하거나, 암호화된 ID를 복호화하여 객체로 변환하는 등 기본 바인더가 처리하지 못하는 복잡한 변환 로직이 필요할 때 구현합니다. IModelBinder 인터페이스를 구현하고 ModelBinderAttribute로 적용하거나 ModelBinderProvider를 통해 전역으로 등록할 수 있습니다.

ASP.NET Core의 Configuration은 여러 소스에서 키-값 쌍을 로드하여 계층적으로 병합하는 시스템입니다. 기본적으로 appsettings.json이 먼저 로드되고, appsettings.{Environment}.json, 환경 변수, 커맨드 라인 인수 순으로 로드되며 나중에 로드된 값이 이전 값을 덮어씁니다. appsettings.json은 기본 설정과 개발 환경 설정에 사용하고, 민감하지 않은 구성 정보를 저장합니다. User Secrets는 개발 단계에서 연결 문자열, API 키 등 민감한 정보를 소스 코드 저장소에 커밋하지 않고 관리할 때 사용합니다. 환경 변수는 컨테이너나 클라우드 환경에서 배포별 설정을 주입할 때 유용하며, Azure Key Vault는 프로덕션 환경에서 암호화 키, 인증서, 연결 문자열 등 중요한 비밀을 안전하게 관리할 때 사용합니다. IOptions 패턴을 통해 강타입으로 구성을 주입받아 사용하면 타입 안전성과 유효성 검증이 가능합니다.