ASP.NET 리드·아키텍트 프레임워크 면접
새 면접Q. ASP.NET Core의 요청 처리 파이프라인에서 Middleware와 Filter의 실행 순서 및 역할 차이를 설명하고, 각각을 사용해야 하는 적절한 시나리오를 제시해주세요. 특히 예외 처리와 인증/인가를 구현할 때 어떤 선택을 해야 하는지 설명해주세요.
파이프라인의 실행 순서와 MVC 컨텍스트의 유무를 중심으로 생각해보세요.
Middleware는 HTTP 파이프라인의 초기 단계에서 실행되며 모든 요청에 대해 동작하고, Filter는 MVC 파이프라인 내부에서 라우팅 이후에 실행됩니다. Middleware는 HTTP 컨텍스트만 접근 가능하지만, Filter는 MVC 컨텍스트(ModelState, ActionDescriptor 등)에 접근할 수 있습니다. 인증/인가는 라우팅 전에 처리해야 하므로 Middleware로 구현하고, 모델 검증이나 액션별 예외 처리는 Filter로 구현하는 것이 적합합니다. 전역 예외 처리는 UseExceptionHandler Middleware로, 컨트롤러별 예외 처리는 ExceptionFilter로 구현하여 계층을 분리합니다. 성능 관점에서 Middleware는 초기에 요청을 차단할 수 있어 불필요한 파이프라인 실행을 방지할 수 있습니다.
- • Middleware는 HTTP 파이프라인 초기, Filter는 MVC 파이프라인 내부에서 실행
- • Middleware는 HTTP 컨텍스트만, Filter는 MVC 컨텍스트 접근 가능
- • 인증/인가는 Middleware, 모델 검증/액션별 로직은 Filter 사용
레거시 ASP.NET MVC를 ASP.NET Core로 전환할 때 HttpModule을 Middleware로, ActionFilter 구조는 유지하며 마이그레이션하는 전략 수립에 활용됩니다.
대규모 마이크로서비스 환경에서 공통 인증 로직을 API Gateway와 개별 서비스 중 어디에 배치하는 것이 좋을까요?
Q. ASP.NET Core의 DI 컨테이너에서 Singleton, Scoped, Transient의 차이를 설명하고, 멀티스레드 환경에서 Singleton 서비스 내부에서 Scoped 서비스를 참조할 때 발생할 수 있는 문제와 해결 방법을 설명해주세요.
서비스 생명주기의 불일치와 Captive Dependency 문제를 고려해보세요.
Singleton은 애플리케이션 생명주기 동안 하나의 인스턴스만 생성되고, Scoped는 HTTP 요청당 하나, Transient는 요청할 때마다 새로운 인스턴스를 생성합니다. Singleton 내부에서 Scoped 서비스를 생성자 주입하면 Captive Dependency 문제가 발생하여 Scoped 서비스가 의도치 않게 Singleton처럼 동작하게 됩니다. 이는 DbContext 같은 스레드 안전하지 않은 객체에서 동시성 문제를 일으킬 수 있습니다. 해결 방법은 IServiceScopeFactory를 Singleton에 주입하고, 필요할 때마다 CreateScope()로 새로운 스코프를 생성하여 Scoped 서비스를 가져오는 것입니다. 백그라운드 서비스나 Hosted Service에서 DbContext를 사용할 때 이 패턴이 필수적입니다.
- • Singleton은 앱 전체, Scoped는 요청당, Transient는 매번 새 인스턴스 생성
- • Captive Dependency는 생명주기가 긴 서비스가 짧은 서비스를 포획하는 문제
- • IServiceScopeFactory로 명시적 스코프 생성하여 해결
대용량 배치 처리나 실시간 알림 서비스 같은 백그라운드 작업을 구현할 때 메모리 누수와 동시성 문제를 방지하는 데 필수적입니다.
IHostedService를 구현한 백그라운드 작업에서 Entity Framework DbContext를 안전하게 사용하는 패턴을 설명해주세요.
Q. ASP.NET Core에서 응답 캐싱(Response Caching), 메모리 캐싱(In-Memory Caching), 분산 캐싱(Distributed Caching)의 차이와 각각의 적절한 사용 시나리오를 설명해주세요. 특히 대규모 트래픽 환경에서 스케일 아웃 시 고려사항도 포함해주세요.
캐시의 저장 위치와 클라이언트/서버 역할, 그리고 서버 인스턴스 확장성을 중심으로 생각해보세요.
Response Caching은 HTTP 헤더 기반으로 클라이언트나 프록시에서 전체 HTTP 응답을 캐시하며, GET/HEAD 요청에만 적용되고 Cache-Control 헤더로 제어합니다. In-Memory Caching은 서버 메모리에 객체를 저장하여 데이터베이스 쿼리 결과나 계산 비용이 높은 데이터를 캐시하지만, 서버별로 독립적이어서 스케일 아웃 시 캐시 불일치가 발생할 수 있습니다. Distributed Caching은 Redis나 SQL Server를 사용하여 여러 서버 인스턴스가 동일한 캐시를 공유하므로 스케일 아웃 환경에 적합합니다. 정적 콘텐츠는 Response Caching, 단일 서버의 빠른 조회는 In-Memory, 다중 서버 환경의 세션이나 공유 데이터는 Distributed Caching을 사용합니다. 대규모 환경에서는 Redis Cluster와 캐시 무효화 전략을 함께 설계해야 합니다.
- • Response Caching은 HTTP 레벨 캐싱으로 클라이언트/프록시에서 동작
- • In-Memory는 빠르지만 서버별 독립적, Distributed는 공유 가능하지만 네트워크 오버헤드 존재
- • 스케일 아웃 환경에서는 Distributed Caching과 캐시 무효화 전략 필수
전국 규모의 이커머스 플랫폼에서 상품 정보 조회 성능을 개선하고, 쿠버네티스 기반 오토스케일링 환경에서 일관된 세션 관리를 구현할 때 활용됩니다.
Cache-Aside 패턴과 Write-Through 패턴의 차이를 설명하고, 각각 어떤 상황에 적합한지 말씀해주세요.
Q. ASP.NET Core에서 async/await를 사용할 때 ConfigureAwait(false)의 역할과 필요성을 설명하고, ASP.NET Core에서는 왜 ConfigureAwait(false)를 사용하지 않아도 되는지 ASP.NET Framework와 비교하여 설명해주세요.
SynchronizationContext와 실행 컨텍스트의 차이를 중심으로 생각해보세요.
ConfigureAwait(false)는 await 이후 코드가 원래의 SynchronizationContext로 돌아가지 않고 ThreadPool 스레드에서 계속 실행되도록 합니다. ASP.NET Framework는 AspNetSynchronizationContext를 사용하여 요청당 하나의 스레드만 사용하도록 제한했기 때문에, 라이브러리 코드에서 ConfigureAwait(false)를 사용하지 않으면 데드락이 발생할 수 있었습니다. ASP.NET Core는 SynchronizationContext가 null이며 요청 컨텍스트를 AsyncLocal로 관리하므로, await 후에도 자동으로 ThreadPool 스레드에서 실행되어 ConfigureAwait(false)가 불필요합니다. 다만 라이브러리 개발 시에는 여전히 ConfigureAwait(false)를 사용하는 것이 성능상 이점이 있고, 다양한 호스트 환경 호환성을 보장합니다. 실무에서는 애플리케이션 코드에서는 생략하고, 재사용 가능한 라이브러리에서만 명시적으로 사용하는 것이 권장됩니다.
- • ConfigureAwait(false)는 원래 컨텍스트로 돌아가지 않고 ThreadPool에서 계속 실행
- • ASP.NET Core는 SynchronizationContext가 null이라 자동으로 ThreadPool 사용
- • 라이브러리 코드에서는 여전히 ConfigureAwait(false) 사용 권장
레거시 ASP.NET MVC를 ASP.NET Core로 마이그레이션할 때 비동기 코드의 동작 차이를 이해하고, 기존 데드락 회피 코드를 정리하는 데 활용됩니다.
ValueTask와 Task의 차이를 설명하고, 어떤 경우에 ValueTask를 사용하는 것이 성능상 유리한지 말씀해주세요.
Q. ASP.NET Core에서 JWT 기반 인증을 구현할 때 Refresh Token 전략의 필요성과 구현 방식을 설명하고, Access Token과 Refresh Token의 저장 위치 및 보안 고려사항을 제시해주세요.
토큰의 수명 주기와 탈취 시나리오, 그리고 XSS와 CSRF 공격을 고려해보세요.
Access Token은 짧은 만료 시간(15-30분)으로 설정하여 탈취 시 피해를 최소화하고, Refresh Token은 긴 만료 시간(7-30일)으로 설정하여 사용자 편의성을 보장합니다. Access Token은 메모리나 sessionStorage에 저장하여 XSS 공격으로부터 보호하고, Refresh Token은 HttpOnly, Secure, SameSite 속성을 가진 쿠키에 저장하여 JavaScript 접근을 차단합니다. Refresh Token 엔드포인트에서는 토큰 재발급 시 Refresh Token도 함께 갱신하는 Rotation 전략을 적용하고, 사용된 Refresh Token을 블랙리스트에 등록하여 재사용을 방지합니다. 데이터베이스에 Refresh Token을 저장하여 강제 로그아웃이나 탈취 감지 시 무효화할 수 있도록 구현합니다. 대규모 시스템에서는 Redis를 활용하여 토큰 블랙리스트와 세션 관리를 효율적으로 처리합니다.
- • Access Token은 짧은 수명, Refresh Token은 긴 수명으로 분리
- • Access Token은 메모리, Refresh Token은 HttpOnly 쿠키에 저장
- • Refresh Token Rotation과 블랙리스트로 보안 강화
모바일 앱과 웹을 동시에 지원하는 서비스에서 보안과 사용자 경험을 모두 만족시키는 인증 시스템을 설계할 때 필수적입니다.
마이크로서비스 환경에서 각 서비스가 독립적으로 JWT를 검증할 때, 사용자 권한 변경이나 강제 로그아웃을 실시간으로 반영하는 방법을 설명해주세요.
Q. Entity Framework Core에서 N+1 쿼리 문제가 발생하는 원인과 해결 방법을 설명하고, Include, Select, AsSplitQuery의 차이와 각각의 트레이드오프를 설명해주세요. 특히 대용량 데이터 조회 시 성능 최적화 전략도 포함해주세요.
Lazy Loading과 Eager Loading의 차이, 그리고 Cartesian Explosion 문제를 고려해보세요.
N+1 문제는 부모 엔티티를 조회한 후 각 부모마다 자식 엔티티를 별도로 조회하여 발생하며, Lazy Loading 사용 시 흔히 발생합니다. Include는 Eager Loading으로 JOIN을 사용하여 한 번에 조회하지만, 다중 컬렉션 Include 시 Cartesian Explosion으로 중복 데이터가 증가합니다. AsSplitQuery는 각 컬렉션을 별도 쿼리로 분리하여 Cartesian Explosion을 방지하지만, 다중 쿼리로 인한 네트워크 오버헤드와 데이터 일관성 문제가 있습니다. Select를 사용한 프로젝션은 필요한 컬럼만 조회하여 가장 효율적이지만, DTO 매핑 코드가 필요합니다. 대용량 데이터는 AsNoTracking으로 변경 추적을 비활성화하고, 페이징과 필터링을 데이터베이스 레벨에서 처리하며, 읽기 전용 쿼리는 Dapper 같은 Micro-ORM 사용을 고려합니다.
- • N+1 문제는 Lazy Loading으로 인한 반복 쿼리 실행이 원인
- • Include는 JOIN 사용하지만 Cartesian Explosion 발생 가능, AsSplitQuery는 별도 쿼리로 분리
- • Select 프로젝션과 AsNoTracking으로 성능 최적화
수천만 건의 주문 데이터를 처리하는 이커머스 백오피스에서 복잡한 관계 조회의 성능을 개선하고, 데이터베이스 부하를 줄이는 데 활용됩니다.
CQRS 패턴을 적용할 때 Command와 Query에서 각각 어떤 데이터 접근 전략을 사용하는 것이 효율적일까요?
Q. 대규모 ASP.NET Framework 애플리케이션을 ASP.NET Core로 마이그레이션하는 전략을 수립할 때, Strangler Fig 패턴을 적용하는 방법과 단계별 마이그레이션 우선순위를 결정하는 기준을 설명해주세요. 특히 비즈니스 중단 없이 점진적으로 전환하는 방법을 포함해주세요.
리버스 프록시를 활용한 점진적 전환과 공유 세션 관리 전략을 고려해보세요.
Strangler Fig 패턴은 새로운 기능을 ASP.NET Core로 구현하고, 기존 기능을 점진적으로 교체하는 방식으로 리스크를 분산합니다. YARP나 Nginx 같은 리버스 프록시를 앞단에 배치하여 URL 경로별로 트래픽을 라우팅하고, 새 기능은 ASP.NET Core로, 기존 기능은 Framework로 전달합니다. 우선순위는 비즈니스 영향도가 낮고 의존성이 적은 모듈부터 시작하며, API 엔드포인트나 배치 작업 같은 독립적 컴포넌트를 먼저 마이그레이션합니다. 세션 공유는 SQL Server Session State나 Redis를 사용하여 두 프레임워크 간 호환성을 보장하고, 인증 쿠키도 Machine Key 설정으로 공유합니다. 모니터링과 로깅을 통합하여 양쪽 시스템의 성능과 오류를 추적하고, Feature Flag로 롤백 가능한 구조를 유지합니다. 전체 마이그레이션은 6-18개월 계획으로 수립하며, 각 단계마다 성능 테스트와 보안 검증을 수행합니다.
- • Strangler Fig 패턴으로 점진적 교체, 리버스 프록시로 트래픽 라우팅
- • 비즈니스 영향도 낮고 의존성 적은 모듈부터 우선 마이그레이션
- • 세션과 인증 공유, Feature Flag로 롤백 가능한 구조 유지
10년 이상 운영된 금융권 레거시 시스템을 무중단으로 현대화하고, 클라우드 네이티브 아키텍처로 전환하는 프로젝트에서 핵심 전략으로 활용됩니다.
마이그레이션 과정에서 .NET Framework 전용 라이브러리(예: System.Web)에 의존하는 코드를 어떻게 처리하시겠습니까?
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!