.NET Execution Model
그렇다면 먼저 .NET 코드의 실행 모델을 그림으로 우선 만나보자.
위의 그림은 코드 실행의 구조를 아주 잘 나타내 주고 있다. 모든 .NET 언어로 작성된 소스 코드는 언어에 따르는 컴파일러를 통해서 MSIL 이라는 중간언어로 만들어 진다. 여기까지를 우리는 Compilation 단계라고 부른다. 이 단계의 결과물로는 중간 언어인 MSIL과 그 중간 언어에 대한 여러가지 정보를 가지고 있는 MetaData 라는 것이 생긴다. 중간 언어로 존재한다고 하더라도 우리 눈에 보여지는 이 결과 파일의 확장자는 DLL 이나 EXE 이다. 조심할 것은 이 확장자로 인해 이 파일이 라이브러리 파일이거나 실행파일이라고 착각하는 것이다. 안타깝게도 이들은 단지 그러한 확장자를 가진 중간언어이다. CLR의 도움 없이는 아무것도 할 수 없는...
이러한 중간적인 상태로 존재하던 파일들이 이제 실행시점에 들어가게 되면 CLR 내의 JIT(Jitter 라고도 호칭함)라는 컴파일러에 의해 다시금 컴파일되고, 그 결과 실제로 실행가능한 플랫폼 기반의 Native Code 가 생성되어지게 된다. 여기까지의 단계를 Execution 단계라고 부른다.
모든 .NET 코드들은 위와 같은 단계를 거쳐서 실행을 하게 된다. .NET 이전의 Windows 시절의 방식과 비교했을 경우에 오히려 거추장스러우면서, 성능의 저하를 가져올 것처럼 느껴지는 단계들이 존재한다고 보일 수도 있다. 하지만, 자못 그렇게 보일 수 있는 단계들이 .NET으로 하여금 여러가지의 막대한 잇점을 갖게 하는데, 그것은 언어 독립성, 교차 언어의 상속가능, 플랫폼 기반의 최적화된 코드의 생성등이다. 어떠한 점이 잇점인지, 그 외에 더 얼마나 많은 잇점을 제공해주기에 이러한 실행구조를 .NET이 갖는지등에 대한 더욱 구체적인 이야기들은 MSDN의 .NET Framework의 소개나, 여러 .NET 관련 언어 서적을 통해서 얻을 수 있을 것이다. .NET 구성과 관계된 서적을 한권쯤은 꼭 정독하여 Microsoft가 .NET이라는 것을 얼마나 면밀히 계획했는지 살며시 들여다보는 것도 개발에 도움이 되리라 생각한다. (태오의 개인적인 추천서적으로는 2002년 4월에 번역 출간되는 Wrox의 PROFESSIONAL .NET FRAMEWORK을 추천한다. 물론, Ms Press의 것은 말할 것도 없다.)
.NET의 실행 모델은 사실상 Java 것과도 비슷하다고도 볼 수 있지만, 진화된 환경이란 이전 환경의 좋은 점들을 모두 추출하여, 그 것을 기반으로 발전시켜 나가는 것이라고 볼 때, .NET은 Java의 진화 발전형이라고 볼 수도 있을 것이다.
위의 실행 모델은 ASP.NET 뿐 아니라 모든 .NET의 코드들에 적용된다. 사실 ASP.NET의 경우는 위의 기본적인 모델을 따르면서 약간은 자신만의 단계들이 존재하고 있지만, 여전히 기본은 위의 모델이다.
위에서 Execution 단계를 관할하는 것이 바로 CLR 이다. CLR은 누누히 강조했지만, 위처럼 코드의 실행을 관리하는 역할을 한다. 그래서 CLR이 .NET 프레임워크의 가장 중요한 부분중의 하나라고 이야기 했던 것이다. (사실, .NET 프레임워크의 가장 중요한 다른 하나는 .NET 프레임워크 클래스 라이브러리이지만, 이 둘이 바로 .NET 프레임워크 이니... CLR이 가장 중요하네~ 라는 식의 말은 강조를 위한 말장난같아 보일 수 있음을 인정한다. ^^)
실행 모델의 간단한 구성에 대해서 알아보았다. 그러나, 역시 뭔가 부족한 느낌이 있다. 그렇다면, 조금 더 세분화하여 실행모델을 구체적으로 살펴보도록 하자. 이 실행 모델을 이해하는 것은 매우 중요하다. 지금 이를 확인하지 않고 넘어갈 수는 있겠지만, 그렇게 되면 차후에 쓸쓸히, 아주 외롭게 남들은 중급적인 내용을 공부할 때, 자신만이 다시 이 자리로 돌아와서 실행 모델을 확인하게 될지도 모른다.
다음은 구체적인 Execution Model 이다.
어떤가? 이전 그림보다는 구체적이다.
그럼 그림을 하나하나 살펴보도록 하자. 흐름은 좌측 상단에서부터 시작하여 우측 하단으로 흐른다. 먼저 소스코드가 컴파일러와 메타 데이터 엔진에 의해 중간언어인 IL 과 또한 그 IL을 설명하는 메타 데이터로 구성되는 것을 볼 수가 있다. 그렇게 구성되어진 MSIL 은 그 파일과 연결된 다른 어셈블리들이 있을 경우, Linker 라는 것을 통해서, 하나의 EXE 나 DLL 로 만들어지게 되며, 이것이 이전에 말했던 관리 코드이다.
좋다. 여기까지가 컴파일 단계이다.
|
이는 컴파일된 관리 코드들이 저장되는 단위로써, 기존의 EXE 나 DLL 파일과 비슷하다고 볼 수 있지만, 어셈블리는 이전 EXE, DLL 과는 다르게 자신을 설명하는 메타 데이터를 가지고 있다. 이것이 중요한 차이점이다. |
어셈블리 (Assembly)란?그리고, 하나의 EXE 나 DLL 로써 존재하고 있던 관리 코드들은 실행시가 되면 이제 CLR에 의해서 실행 파일이 되기 위한 다시 한번의 컴파일 과정을 거치기 위한 준비들을 하는데, 그 첫번째가 바로 CLR의 Class Loader 에 의해 클래스의 레이아웃이 잡히고, 로드되는 단계이다. 이 때, Base Class Library 로부터 여러가지 기본적인 클래스들도 같이 로드하는 것을 볼 수 있다. 이렇게 클래스가 로드되면 그것을 Jitter('지터'라고 발음함) 로 컴파일을 하게 되고 그로인해 원시코드는 탄생하게 되는 것이다. 그리고, 즉시 실행을 시작한다. 여기까지가 실행 단계이다.
이제 여러분은 .NET 언어로 제작한 특정 파일이 두번의 컴파일 단계를 거친다는 사실과, 전체적인 실행 구조에 대해서 알아보았다. 이 지식이 지금 당장 여러분에게 눈에 보이는 어떤 도움이 될 것으로 기대되지는 않지만, 차후 분명 도움이 될 지식임은 자명하다. 이해가 가지 않는다고 하더라도 가급적 기억은 하고 있기를 바란다.
ASP.NET Execution Model
자. 이제 ASP.NET으로 고개를 돌려보자. 그렇다고 지금 ASP.NET 코드를 작성해 보자는 의미는 아니다. 아직 우리는 ASP.NET 이라는 새로운 기술을 제대로 시작하기 위한 준비를 하고 있는 단계에 있다. 그렇다면, ASP.NET의 어떠한 것을 이야기하고자 하는 것인가? 바로 ASP.NET의 실행 모델이다.
다음 그림은 ASP.NET의 실행 구조를 나타내고 있는 그림이다.
호오. 좀 복잡하게 보인다. 하지만, 이전 .NET의 실행 모델을 머리속에 두고 생각해 보면, 이 흐름이 그리 어렵게 느껴지지 않을 것이다. 그럼 이전 지식들을 뇌의 메모리에 올린 다음에 태오와 같이 이 흐름에 대해서 알아보도록 하자.
먼저, 클라이언트는 서버로 특정 aspx (ASP.NET 페이지)를 호출한다. taeyo.aspx 라는 페이지를 달라는 클라이언트의 호출을 받은 웹 서버는 이 파일을 찾고, 이 파일의 확장자를 확인한다.
만일, 이 파일의 확장자가 htm 이라면 서버는 찾은 파일을 클라이언트에게 넘겨주기만 하는 역할일 뿐이겠지만, 파일의 확장자가 aspx 라는 것을 확인하면, 서버는 이 확장자와 연결되어져 있는 DLL (ASP.NET) 에게 이 파일의 처리를 의뢰한다. (ASP 때 그러하였던 것처럼 말이다)
ASP.NET은 이 파일을 받아서 일단 파싱하는 작업을 한다. 라인 단위의 파싱작업을 끝낸 다음에 이 파일은 서버에 의해서 일단 컴파일이 되어진다. 그림으로는 현재 우측 상단까지 진행되어 온 것이다. 컴파일이 되어지면 MSIL과 MetaData로 만들어지고, 이는 관리 코드인 Assembly IL 이라는 것으로 만들어 진다. 확장자는 DLL 이나 EXE 가 될 것이다. 나중에 실제 이렇게 만들어져 있는 어셈블리 IL을 확인해 볼 것이다.
일단, 관리 코드로 만들어진 것들은 어셈블리 캐쉬라는 공간에 쌓여지게 된다. 이 부분은 기존의 .NET 실행 모델과는 조금 다른데, 이것은 ASP.NET 이라는 웹 프로그래밍의 특성으로 인해 제공되는 것이다. 즉, 일단 컴파일되어진 aspx 페이지들은 그 중간완성품을 캐쉬에 저장해 놓고, 이후 여러 사용자들이 같은 aspx 페이지를 요청할 경우, 새롭게 컴파일을 해서 IL을 만들어 내는 것이 아니라, 이 캐쉬에 이미 존재하는 IL을 재사용하게 하는 것이다. 이로 인해 상당한 속도의 증가효과를 얻어낼 수 있다는 감이 마구 올 것이다.
일단, 어셈블리 캐쉬에 올라와 있는 IL 들은 요청에 대한 응답을 기다리고 있는 사용자들에게 결과물을 건네어주어야 하기에 실행을 실시한다. 캐쉬에 있던 IL 은 메모리로 올라가게 되고, 이것은 CLR의 Jitter 에 의해 다시 한번 컴파일되어지며, 그 결과 만들어지는 결과물들(대부분의 경우 동적으로 생성된 HTML)을 클라이언트의 브라우저에게 넘겨주게 되는 것이다.
중요한 것은 사용자들은 서버에서 어떠한 일이 일어나는지 모른다는 것이다. 여러분도 이 강의를 듣기전에는 전혀 알지 못했다. (물론, 예습을 통해서 알고 있었던 분도 있을 것이기는 하다) 사용자는 단지 aspx 페이지를 요청했고, 그 요청에 의해 결과로 HTML을 돌려받았다. 그게 전부이다. 사용자는 단순하다. 사용자가 요청한 결과만 주면, 그것으로 충분히 만족한다.
하지만, 이러한 흐름을 다루어야 할 여러분, 개발자들은 다르다. 서버측에서 발생하는 모든 흐름에 대해 이해하고 있어야만 하고, 그 흐름에 맞추어 프로그램을 작성해야만 한다. 이것이 ASP.NET의 실행구조를 이해해야만 하는 이유이며, .NET 이라는 기술을 이해해야만 하는 이유이다.
자. 정리해 보자. 위의 그림은 어떤 특정 페이지를 사용자가 처음 요청했을 경우의 모습을 보여주고 있다. 혼동해서는 안되는 것중 하나는 이러한 컴파일과정이 매번 사용자마다 발생하는 것은 아니라는 것이다. 우리 서버에는 taeyo.aspx 라는 파일이 존재하고 있고, 이 파일을 요청하는 사용자는 수십명에서 수천만명에 이르를 수 있다. 위의 코드 컴파일, Jit 컴파일은 매 사용자마다 발생하는 작업이 아니다. taeyo.aspx 라는 페이지를 처음 요청한 사용자의 의해 이는 코드 컴파일이 이루어지게 되고, 그 결과 관리코드가 어셈블리 캐쉬에 올라가게 된다. 그리고 나면, 다른 수백만명의 사용자가 taeyo.aspx 페이지를 요청할 경우, 어셈블리 캐쉬에 이미 존재하고 있는 관리 코드를 가져다가 사용하게 되는 것이다.
고로, 서버의 모든 aspx 페이지는 누군가가 처음 요청할 경우만 코드 파싱, 컴파일을 수행하고 그 후 어셈블리 캐쉬에 존재하게 하기에 처음 페이지를 요청한 사용자는 조금 느리게 결과물을 받을 수 있겠지만, 그 이후의 사용자들은 대단히 빠르게 어셈블리 캐쉬에 이미 존재하는 관리코드를 통해서 결과를 확인할 수 있다는 것이다.
다음 그림은 첫 요청에 의해 aspx 페이지가 어셈블리 캐쉬에 올라가 있어, 그 이후의 요청에는 빠르게 응답할 수 있는 바로 그러한 실행 흐름을 보여준다.
그림에서 볼 수 있다시피, 일단 첫 요청에 의해 어셈블리 캐쉬에 관리 코드가 존재하게 되면, 두번째 요청부터는 캐쉬로부터 빠르게 응답을 해 줄 수 있게 된다. 이것이 .NET의 장점인 것이다.
그렇다면, 만일 taeyo.aspx 페이지의 소스를 개발자가 수정하였다면 어떻게 될까? taeyo.aspx 라는 것의 컴파일된 관리 코드가 이미 어셈블리 캐쉬에 있는데, 원본 소스는 수정되었다. 이럴 경우 사용자는 수정된 소스에 의한 결과가 아닌 수정되기 이전의 결과를 볼 수 있다는 이야기인가?
그럴 경우, 현명한 ASP.NET은 수정사항을 감지하고, 어셈블리 캐쉬에 있던 해당 IL을 삭제하게 된다. 그리고, 수정된 taeyo.aspx 페이지의 첫 요청시 다시 처음부터 흐름을 시작하게 된다. 즉, 컴파일 단계를 다시금 거쳐서 어셈블리 캐쉬에 수정된 IL을 다시 올려놓는다는 이야기이다.
이 얼마나 현명한 ASP.NET 인가?
단, 만일 aspx 페이지가 코드 비하인드로 구성되어진다면, 그러한 경우, 클래스 파일이 수정될 경우는 개발자가 직접 그 클래스 파일을 컴파일해야 한다. 코드 비하인드에 대해서는 이후 자세하게 이야기할 것이니 지금은 그런 경우도 있다는 것만 알아두도록 하자.
결과적으로, 대부분의 aspx 페이지의 첫 요청은 개발자인 여러분들이 결과를 확인하면서 이루어질 것이다. 고로, 다른 일반 사용자들은 언제나 어셈블리 캐쉬에 있는 관리코드를 사용하게 될 것이고, 상당히 빠르게 결과를 받아볼 수 있게 될 것이다. 이것이 ASP.NET 이 빠르다는 근거인 것이다.
물론, 위의 실행 구조에서 빠진 부분이 하나 있다. 그것은 Output Cache 라는 것인데, 이는 위의 흐름보다 더욱 빠르게 사용자에게 응답을 해주기 위한 방법이다. Output Cache도 한 챕터를 차지할 만큼의 분량이기에 여기서 자세하게 이야기하기에는 무리가 따르지만, 간략히 설명하자면, 이는 사용자에게 최종으로 넘겨줄 두번째 컴파일 버전의 결과물을 캐쉬에 저장해 두는 방법이다. Output Cache 라는 특별한 캐쉬구역에 저장해 두게 되면, 사용자의 요청은 파싱, 코드 컴파일 단계, 런타임 컴파일 단계등을 거치지 않고, Output Cache 구역에 존재하고 있는 결과물로써 대단히 빠르게 응답해 줄 수 있게 된다. 그림으로 설명하자면 다음과 같은 흐름을 가지게 된다.
자. 이제 ASP.NET의 Execution Model 에 대한 이야기도 여러분이 충분히 이해한 것 같다. 물론, 여러분이 빨리 ASP.NET 코드를 작성하고 싶어하는 마음은 때오도 알고 있다. 하지만, 누누히 강조하였지만 이러한 기본적인 지식이 없이는 반쪽짜리 프로그램밖에 작성할 수 없다는 사실을 인지하기 바라는 마음이다.
ASP.NET Development Model
ASP.NET의 실행 구조를 알아보았으니, 이번에는 개발 흐름에 대해서 알아보도록 하자. 사실 대단한 것은 없다. 위의 실행 흐름을 이해했다면, 개발 흐름도 아주 쉽게 받아들여질 것이다.
이를 위해 먼저 이전 ASP.NET이었던 ASP 경우의 개발 흐름을 한번 보도록 하자. 만일, ASP 를 전혀 모르는 사용자라면 한번 그랬었구나 하는 마음으로 보아도 좋을 것이다.
ASP 때의 경우는 컴파일 언어가 아닌 인터프리트 언어를 사용했었기에, 컴파일이라는 단계가 필요하지 않았다. 단지 개발자의 몫은 단지 ASP 소스 코드를 수정하고 그냥 놔두기만 하면 되었다. 모든 ASP 페이지는 사용자의 요청시 서버에서 매번 인터프리트되었고, 그 결과를 클라이언트에게 건네어 주었다. 그로 인해, 매 페이지는 매번 파싱, 인터프리트 단계를 거치는 불합리함이 있었다. 하지만, 개발자의 입장에서는 단지 해당 소스만을 수정하면 그것으로 전부였기에 개발하기는 상당히 편리하였다.
ASP.NET으로 들어서면 이제는 컴파일 단계가 요구되어진다. 그것도 2번이나. 코드 컴파일 단계와 런타임 컴파일 단계를 거치고, 코드 컴파일이 되어진 관리 코드는 어셈블리 캐쉬에 올라가게 되어 이후 더욱 빠르게 서비스를 제공할 수 있게 된다. 해서 ASP.NET에서의 개발 흐름은 다음과 같은 모습을 띄게 된다.
이미 ASP.NET Execution Model을 이해하고 난 여러분은 개발상의 흐름을 이해하는 것이 전혀 어렵지 않다. 그렇지 않은가? 좋다. 이제 얼마남지 않았다. 여러분은 이제 곧 멋진 ASP.NET 의 코드들을 지겹도록 만나게 될 것이다.
출처 : (Taeyo.pe.kr)
