OWIN과 함께 춤을 – 시작하기

OWIN 개요

요즈음 .NET 기반 웹 개발에서 주목을 받고 있는 것은 ASP.NET MVC나 ASP.NET Web API가 아니라 사실 OWIN이 아닐까 생각합니다. OWIN은 Open Web Interface for .NET을 줄여서 쓴 말로 .NET Framework 기반의 웹 개발 프레임워크들을 더 다양하게 고르고 조합할 수 있도록 도와주는 표준화된 인터페이스를 말합니다. (http://owin.org/ 에서 자세한 정보를 볼 수 있습니다.)

왜 OWIN인가?

OWIN이 주목을 받는 이유는, 이전에 다루던 웹 응용프로그램 개발 환경과는 달리, 목적과 상황에 맞게 더 정밀하고 더 세세한 웹 프로그래밍이 가능하기 때문입니다. 이전의 ASP.NET 만을 사용하던 개발 환경에서 가장 큰 문제가 되었던 것은 의외로 단순한 부분들로부터 나타나는 것들이 많았는데, 예를 들어 파일 업로드에 대한 것이 가장 큰 문제였습니다.

인터넷 속도가 빠르지 않은 지역에서의 사용을 기준으로 잡혀있는 파일 업로드 제한과 공간 할당 정책이 기본값이었기 때문에, 대용량 파일 업로드가 필요한 때에는 이것을 처리하기 위해 ASP.NET의 파일 업로드 제한을 다시 정의할 수 밖에 없었고, 사실 이것은 면밀하지 못한 설정이 되어서 보안 리스크가 될 수 밖에 없었습니다. 그리고 .NET Framework 2.0 서비스팩 적용 이전까지는 놀랍게도 파일 업로드를 임시 저장소가 아닌 메모리 공간에 저장하는 방식이어서 대용량 파일 업로드를 할 경우 서버 자원이 고갈되는 (!) 문제까지 있었습니다.

지금은 임시 디스크에 저장한 후에 파일 업로드가 다 되었음을 알려주는 식이 되었지만, 여전히 세밀한 파일 업로드 제어는 하기 어려운 상태입니다. 그리고 제일 큰 문제는, 환경 설정에서 지원하는 최대 파일 업로드 크기가 여전히 부호있는 32비트 정수값 (.NET의 표준은 부호있는 정수 사용을 권합니다.)의 범위에 있어서 최대 업로드가 2GB 밖에 가능하지 않습니다. 이를 해소하기 위해서 청크 방식의 업로드 등을 이용해야 하지만 웹 브라우저가 지원하지 않으면 별도 클라이언트를 이용할 수 밖에 없는 상태입니다. 다시 말해, 간단한 파일 업로드를 필요로 한다면 ASP.NET이 여전히 편리하지만, 복잡해진 요구 사항을 맞추기 위해서는 턱없이 커스터마이징 변수가 부족한 것입니다.

비단 이 문제 뿐 아니라 ASP.NET이 편의를 위하여 제공하는 기능이 요즈음에 들어서는 오히려 복잡한 요구 사항 개발에 방해 요소가 되는 일이 많습니다. 그리고 이러한 요구 사항을 만족하기 위해 ASP.NET의 기본 설정을 변경하는 것 자체가 보안 리스크가 됨은 물론, ASP.NET 자체에 대한 강력한 커플링이 발생하여 유지 보수에 큰 문제가 되곤 합니다. 왜냐하면 커플링이 강력해질수록 ASP.NET에 사소한 업데이트나 패치 하나가 전체 프로그램에 큰 영향을 줄 개연성이나 확률이 더 높아지기 때문입니다. 그래서 기존 ASP.NET의 영역을 유지하면서, 안전하고 더 편리하게 복잡한 요구 사항을 쉽게 맞출 수 있는 방법이 필요해지게 되는데, OWIN이 여기에 대한 확실한 답이 됩니다.

OWIN의 기본 개념

OWIN 그 자체는 HTTP 요청을 받아들이고, 응답을 결정하는 행위를 규정하는 스펙을 .NET 4.0을 기반으로 제공하는 것이 전부이며, 모든 처리 과정은 미들웨어를 통해 이루어지는데, 미들웨어 간의 호출에 사용되는 것은 아주 단순한 Dictionary 자료 구조입니다. (http://owin.org/spec/owin-1.0.0.html)

OWIN-5

OWIN이 하는 일 자체는 위의 그림 (클릭하면 크게 볼 수 있습니다.)이 전부입니다. 여러 개의 미들웨어 구성 요소를 OWIN 프로그램을 시작할 때 등록하고, 미들웨어의 입장에서는 자신이 처리할 수 있는 요청인 경우에만 요청을 가로채고, 그 외에는 다음 미들웨어로 호출을 넘겨주는 것이 전부입니다. 만약 모든 미들웨어를 지나 끝까지 도착했음에도 불구하고 처리할 수 있는 미들웨어가 없다면, OWIN을 어떤 환경에서 사용하는지에 따라 다음 동작이 결정됩니다.

  • 만약 OWIN 그 자체를 바로 호스팅하는 베어본 서버 환경이라면 익히 알려진대로 404 오류 코드를 내보내거나 빈 응답을 반환할 수 있습니다.
  • 만약 ASP.NET 환경에서 OWIN을 얹어서 사용하는 형태라면, OWIN 환경 자체가 다른 ASP.NET 모듈보다 먼저 실행되는 ASP.NET 모듈이기 때문에, 다음 ASP.NET 모듈로 넘어가게 됩니다. 기존에 개발한 ASP.NET 웹 프로젝트 위에 OWIN을 추가 장착하게 되면 이런 형태가 됩니다.
  • 만약 ASP.NET Native Loader 위에서 OWIN을 얹어서 사용하는 형태라면, OWIN 환경 자체를 완전히 분리된 환경에서 실행하는 것을 의미합니다.

각각의 경우를 따로 설명하는 데에는 이유가 있습니다. 이어서 말씀드리면 다음과 같습니다.

세 가지 실행 환경과 가능성

첫 번째는 OWIN과 미들웨어들을 묶어서 어디에서든 웹 서비스를 시작할 수 있음을 말씀드리고 싶어서입니다. 즉, 정상적인 .NET Framework 실행 환경을 갖추고 클라이언트와 서버 사이의 연결을 정확하게 처리하도록 만들어주기만 한다면 서버 OS가 윈도우이든 리눅스이든 맥이든 상관이 없으며 (리눅스와 맥은 Mono 덕분이라고 할 수 있겠습니다.), 전혀 다른 형태로 구현된 웹 서버일지라도 OWIN으로 정확하게 연결을 전달할 수 있다면 이론상으로 .NET 기반이 아닌 서버 플랫폼 환경에서도 얼마든지 .NET 서버 응용프로그램을 호스팅할 수 있는 상태가 됩니다.

두 번째는 기존에 가지고 있던 ASP.NET 웹 프로젝트에 얼마든지 OWIN 응용프로그램을 추가 장착할 수 있음을 의미합니다. System.Web이라고 불리는 레거시 ASP.NET 웹 프레임워크의 종속성에서 완전히 벗어나지는 못하지만, 그 규칙 안에서라면 기존 ASP.NET의 기술과 완전히 무관하게 독자적인 미들웨어를 개발하고 수행하는 것이 가능하므로, 전송 프로토콜 수준에서 HTTP 응답을 재정의하는 것도 가능하고, 실시간으로 파일 업로드에 개입할 수도 있습니다. 기존 ASP.NET 웹 프로젝트를 해치지 않고 얼마든지 복잡한 기능을 쉽게 추가할 수 있음을 뜻합니다.

마지막 세 번째 방법은 기존의 ASP.NET 실행 환경을 사용하지 않고, IIS에 최소 버전의 .NET 실행 환경을 직접 주입하여 실행 속도를 획기적으로 개선하고, 기존의 System.Web 관련 설정을 모두 무시하는 방식입니다. 이것은 Project Helios라고 불리던 것을 제품화한 것으로, 실행 속도와 메모리 점유율을 획기적으로 개선하여 응답 성능을 비약적으로 개선시킬 수 있습니다. 기존 ASP.NET 프로젝트와 독립된 형태로 웹 프로젝트를 개발하면서 IIS 위에서 OWIN 프로그램을 실행하려는 경우 이 방식을 이용하여 성능을 극대화할 수 있습니다.

다음 아티클에서는 OWIN의 내부 구조와 미들웨어를 프로그래밍하는 방법을 몇 가지 살펴보도록 하겠습니다.

이미지 출처: http://byterot.blogspot.kr/2013_08_01_archive.html