ASP.NET Core의 기본 구조 이해하기
최근 수집형 모바일 게임에서는 웹 API 서버 기반 아키텍처가 많이 사용되고 있다.
그 과정에서 ASP.NET Core를 접할 기회가 있었고, 이를 공부하면서 웹 API 서버 프레임워크가 내부적으로 어떤 구조로 동작하는지 정리해 보고 싶다는 생각이 들었다.
그동안은 주로 소켓을 사용해 직접 서버를 구현하는 방식에 익숙했기 때문에, 웹 API 서버 프레임워크의 동작 방식은 처음에는 조금 낯설게 느껴졌다. 특히 요청 처리 과정이 프레임워크 내부에 감춰져 있기 때문에 처음에는 전체 흐름이 명확하게 보이지 않는 부분도 있었다.
이 글은 이러한 구조를 이해하고 정리하기 위해 작성한 글이다.
자체 구현 소켓 서버 vs 웹 API 서버
보통 소켓을 이용해 직접 구현한 서버는 스테이트풀 서버로 만든다.
클라이언트가 서버와 연결을 맺으면 서버는 해당 연결을 세션 형태로 관리하고,
연결이 유지되는 동안 계속 송수신 할 수 있다.
즉 서버는 연결 상태를 기반으로 동작하며, 세션 객체가 중요한 역할을 한다.
웹 API 서버는 구조가 조금 다르다.
웹 API 서버의 요청 모델
웹 API 서버는 기본적으로 요청 단위로 동작한다. 클라이언트는 HTTP 요청을 보내고 서버는 그 요청에 대한 응답을 반환한다. 응답이 완료되면 해당 요청에 대한 처리는 종료된다.
이 구조에서는 연결 자체보다는 요청 하나가 하나의 작업 단위가 된다.
즉 서버는 특정 연결 상태를 오래 유지하기보다는 각 요청을 독립적으로 처리하는 방식으로 동작한다. 이러한 처리 방식을 흔히 stateless request processing 모델이라고 부른다.
요청 처리의 시작
모든 처리는 결국 TCP 데이터를 수신하는 것에서 시작된다.
프로토콜의 복잡성에서는 차이가 있다.
대부분의 자체 구현 서버는 비교적 단순한 프로토콜을 사용한다.
예를 들어 패킷 헤더와 길이 정보를 먼저 읽은 뒤 필요한 길이만큼 데이터를 수신하고,
해당 패킷을 디스패치하는 방식이다.
이러한 구조는 비교적 단순하며 프로토콜 설계를 개발자가 직접 통제할 수 있다는 장점이 있다.
웹 API 서버는 HTTP 프로토콜을 기반으로 동작한다.
HTTP 메시지는 단순한 바이너리 패킷 구조와 달리 텍스트 기반의 요청 라인과 여러 개의 헤더로 구성된다. 또한 다양한 헤더 규칙, chunked encoding, keep-alive 연결, 그리고 HTTP/2와 같은 추가적인 프로토콜 기능이 존재한다.
즉 HTTP 메시지를 직접 파싱하는 것은 생각보다 복잡한 작업이다.
미리 구현 된 웹 서버
소켓 서버를 자체 구현 할때, 세션 관리, IO 작업, 네트워크 이벤트 핸들링등 을 위한 코어 라이브러리를 만든다.
ASP.NET Core는 이러한 기반 웹 서버를 선택할 수 있다.
이 아마도 이런 코어 라이브러리의 역할을 한다고 보면 된다.
별 설정없이 기본적으로는 ASP.NET Core 는 Kestrel을 사용한다.
개발자는 복잡한 IO, HTTP 프로토콜의 세부적인 파싱 과정, 세션 관리등은 엔진에 맡기고,
비즈니스 로직 구현에 집중할 수 있다.
ASP.NET Core 요청 처리 흐름
웹 엔진(Kestrel 등)을 통해 HTTP 요청이 파싱되면 해당 요청은
ASP.NET Core의 요청 처리 파이프라인으로 전달된다.
이 단계에서 요청은 내부적으로 하나의 Dispatch 과정을 거치게 된다.
이 과정에서 다양한 미들웨어가 실행되며, 최종적으로 해당 요청을 처리할 Controller가 결정된다.
즉 ASP.NET Core에서 요청이 처리되는 과정은 크게 보면 HTTP 요청을 받아 내부 디스패치 과정을 거친 뒤 적절한 핸들러가 실행되는 구조라고 볼 수 있다.
Middleware란 무엇인가
Middleware는 요청 처리 과정에서 실행되는 일종의 필터 체인이라고 볼 수 있다.
웹 API 서버 구현을 하면 공통적으로 요구되는 기능들이 꽤 있다.
예를 들면 인증, 보안, 암호화, 압축, 캐싱 등...
당연히 이러한 기능을 최종 핸들러인 Controller에서 반복적으로 구현한다면 코드가 중복되고 구조가 복잡해진다.
그래서 Controller 에 도달하기 전 한번 거치고 오게끔 하고, 이걸 미들웨어라고 부른다.
ASP.NET Core에서는 애플리케이션 시작 시 미들웨어를 등록할 수 있으며,
등록된 순서대로 요청이 미들웨어를 통과하게 된다.
각 미들웨어는 요청을 검사하거나, 응답을 생성하거나, 혹은 다음 단계로 요청을 전달할 수 있다.
또한 특정 조건에서는 요청 처리를 중단하고 바로 응답을 반환할 수도 있다.
Controller란 무엇인가
Controller는 최종적으로 요청을 처리하는 핸들러이다.
ASP.NET Core에서는 HTTP 요청의 경로와 HTTP 메서드를 기반으로 어떤 Controller 메서드가 실행될지 결정된다.
예를 들어 특정 경로로 HTTP 요청이 들어오면 ASP.NET Core의 라우팅 시스템이 해당 요청을 처리할 Controller 메서드를 찾아 실행한다.
즉 Controller는 실제 애플리케이션 로직을 수행하는 요청 핸들러라고 볼 수 있다.
앞서 설명한 미들웨어가 자동으로 자신이 사용할 컨트롤러를 추가하기도 한다.
정리
ASP.NET Core의 요청 처리 과정은 다음과 같이 이해할 수 있다.
네트워크에서 TCP 데이터를 수신하고, 웹 서버 엔진(Kestrel) 이 이를 HTTP 요청으로 파싱한다.
이후 ASP.NET Core 내부의 디스패치 과정에서 미들웨어들이 실행되고,
마지막으로 해당 요청을 처리할 Controller가 실행된다.
IO 의 기반 부터 메시지 파싱, 미들웨어 까지 모두 편하게 커스텀이 가능하다.
ASP.NET Core는 HTTP 기반 요청 처리를 위한 서버 아키텍처를 프레임워크 형태로 제공하는 것이라고 볼 수 있다.
'ASP.NET' 카테고리의 다른 글
| ASP.NET Core 기본 예제 1 - 구글 OAuth 로그인 인증 (0) | 2026.03.06 |
|---|