Scent of Life

몇 년 전에 Classic ASP와 ASP.NET 비교 자료를 작성했었다. 공식적인 문서는 아니었으며, 개인적으로 정리한 글인데, 워드에 작성했던 내용을 그대로 복사하였다. 단, 원래 시스템의 이름은 "X 솔루션"으로 변경하였다.

１    개요

Microsoft의 Windows 플랫폼 상에서의 웹 응용 프로그램은 대세는 ASP.NET입니다. 기존 Classic ASP(Microsoft Active Server Pages)는 .Net 환경의 ASP.NET으로 Migration되고, 신규 개발 건은 대부분 ASP.NET으로 개발되고 있는 듯 합니다. 이런 상황에서 두 언어에 대한 차이점을 언급하는 것은 때늦은 감이 없지 않지만 현재 ASP 및 ASP.NET 웹 응용 프로그램이 공존하고 있는 “X 솔루션”을 유지 보수하고 신규 시스템들을 추가하는 시점에서 다시 한번 각 언어별 개발 효율과 서비스 품질에 대해서 짚고 넘어가는 것도 의미 있는 일이 될 것 같습니다.

기존 ASP는 웹 응용 프로그램에 있어서 오랫동안 수위를 고수하면서 광범위하게 적용되어 있고 개발자들에게 매우 친숙하며, 또한 scripting language로써 응용 프로그램을 빠르게 개발할 수 있는 장점에도 불구하고 여러 측면에서 볼 때 ASP.NET에 비해 한 수 뒤질 수 밖에 없습니다.

반면에 ASP.NET을 단순히 ASP의 업그레이드 버전으로 볼 수 없는 것이, ASP에 비해 ASP.NET은 보다 진보된 기술로 완전히 새로 작성되었으며 현격한 생산성의 향상을 가져왔습니다. ASP와 친숙한 형태의 요소들을 그대로 포함하면서 Web Forms, Web Services, 또는 Server Controls 들은 웹 응용 프로그램 개발에 강력하고 유연한 기능들을 제공하고 있습니다.

Classic ASP와 ASP.NET의 주요한 차이점들은 어떠한 것들이 있는지 간략히 살펴보고 왜 웹 응용 프로그램 개발에 있어서 ASP.NET에 무게가 실리는지에 대한 이유를 알아보겠습니다.

２    주요 차이점 간략 비교

Microsoft Active Server Pages (ASP)는 서버측(server-side) 스크립팅 기술입니다. Classic ASP로 만들어진 웹 응용 프로그램들은 주로 VB Script, COM(COM+), ADO 등의 기술 요소들을 사용하여 만들어집니다.

반면에 ASP.NET은 .Net Framework 환경에서 C#, VB.Net, ADO.Net 등을 사용해서 만들어집니다. ASP.NET은 개발자들이 Classic ASP에서 느꼈던 문제들에 대한 직접적인 응답으로 개발되었으며 또한 이미 광범위하게 적용되어 있는 Classic ASP를 위해 Microsoft는 ASP 스크립트가 .NET Framework가 탑재된 서버상에서 어떠한 수정도 없이 실행될 수 있도록 하였습니다. 따라서 .NET Framework을 설치해도 ASP 엔진, ASP.DLL 등은 수정되지 않으며, IIS는 동일 머쉰 상에서 ASP와 ASP.NET을 동시에 수용할 수 있습니다.

아래는 Classic ASP와 ASP.NET 간의 단순 비교표입니다 (한 라인이 반드시 동일한 주제를 나타내지는 않습니다).

가)   Classic ASP가 갖는 문제

①       인터프리트 코드(interpreted code), 느슨한 형 정의(Loosely-Typed) 코드

ASP는 주로 VBScript 또는 JScript와 같은 scripting code로 작성됩니다. ASP의 스크립트 엔진은 페이지가 불려질때마다 라인 단위로 코드를 해석(interpret)하는 방식으로 작동합니다. 또한 모든 변수들은 variant의 느슨한(loosely) 형식으로 코드가 실행되는 시점에만 특정 형식에 바인딩됩니다. 따라서 이러한 요소들은 성능에 있어서 부정적인 요인으로 작용하게 되며, 또한 형식의 지연 바인딩(late binding)은 코드 작성시 에러를 감지하기 힘들게 만들어 개발 효율도 떨어지게 됩니다.

②       비즈니스 로직(스크립팅 코드)과 레이아웃(HTML)의 혼재

ASP file은 코드(스크립트)와 HTML 코드가 혼재되어 있어 코드가 길어지고 가독성이 떨어집니다. 산재된 ASP 코드와 HTML은 business logic과 contents가 반드시 분리되어져야 하는 보다 큰 웹 응용프로그램에 있어서 문제가 될 수 있으며, 이러한 스파게티 코드는 개발팀원들의 코드 일관성을 저해하고 향후 전체 코드의 유지 보수가 어렵게 되는 잠재적인 문제를 안고 있습니다.

③       제한적인 개발 및 디버깅 도구

ASP 프로그래머의 생산성 증대를 위하여 그래픽 개발 환경을 제공하는 몇몇 툴(Microsoft Visual InterDev, Macromedia Visual UltraDev 등)들이 있지만 여전히 제약적입니다. 많은 ASP 개발자들은 아직까지 텍스트 에디터(제 경우 Ultra Edit를 사용)에 의존하여 힘들게 작업하고 있습니다. 또한 소프트웨어 개발 프로세스에 있어서 디버깅은 피할 수 없는 부분이지만 ASP의 디버깅 툴은 제약적입니다. 대부분의 개발자들이 디버깅을 위해 코드 사이에 Response.Write 와 같은 trace를 위한 문장을 삽입하고 있습니다..

④       진정한 상태 관리의 부재

ASP의 세션은 클라이언트 브라우저가 쿠키를 지원할 때만 관리됩니다. 세션 정보는 ASP 세션 객체에만 의존하며, 사용자 확인 등을 위해서 추가적인 코드를 구현해야만 합니다. 따라서 웹 서버 사이에서 세션을 공유하기가 힘들어집니다.

⑤       서버 중지 상태에서의 프로그램 갱신

웹 응용 프로그램이 컴포넌트(COM, COM+ 객체)로 구성되어 있다면 갱신된 응용 프로그램 파일을 복사(배포)할 때 등록된 컴포넌트가 사용 중이거나 잠김 상태일 수 있으므로 서버를 중지시켜야만 합니다. 이것은 신속한 프로그램 배포에 있어서 문제가 될 수 있습니다.

⑥       분명하지 않은 환경 설정

ASP 웹 응용 프로그램을 위한 환경 설정 정보는 IIS 메타베이스(metabase)에 저장됩니다.     metabase는 IIS의 독립적 포맷으로 저장되기 때문에 서버 머쉰 상에서 Internet Service Manager와 같은 유틸리티로만 수정이 가능합니다. 환경 세팅에 대한 프로그램적인 조정의 제한으로 ASP 응용 프로그램을 다른 서버로 이전하는 것은 매우 번거롭고 까다로운 작업이 될 수 있습니다.

나)   ASP.NET의 강점

①       HTML과 코드의 분리

ASP.NET을 사용함으로써 business logic과 layout을 완전하게 분리(Code behind)하는 것이 가능해졌습니다. 이로 인해 프로그래머들과 디자이너가 보다 효과적으로 협력하여 작업하는 것이 가능해졌습니다.

②       컴파일되는 언어(compiled language)를 지원

개발자들은 C#이나 VB.NET 등을 사용하므로 OOP(object-oriented programming) 및 강력한 형 정의(strong type)가 가능해졌습니다. 또한 이 같은 컴파일되는 언어를 사용한다는 것은 ASP.NET 페이지의 코드를 번역함으로써 발생하는 성능상의 손실을 배제할 수 있습니다. ASP.NET 페이지는 첫번째 요청이 있을 때 바이트 코드(byte-code)로 미리 컴파일(precompile)되고 JIT(Just In Time) 컴파일 됩니다. 그 이후의 요청에 대해서는 (소스의 변경이 있기 전까지는) 캐쉬된 형태의 완전 컴파일된 코드로 바로 유도됩니다..

③       .NET Framework에서 제공되는 서비스의 사용

.NET Framework는 응용 프로그램에서 사용할 수 있는 클래스 라이브러리를 제공합니다. 여기에는 입/출력, 시스템 서비스, 데이터 접근, 이벤트, 디버깅 등의 유용한 핵심 클래스가 있습니다.

④       그래픽 개발 환경

Visual Studio .NET은 웹 개발을 위한 매우 다양한 기능을 갖는 그래픽 환경을 제공합니다.  Visual Basic 6와 같이 컨트롤을 "drag and drop"할 수 있고 속성을 편집할 수 있습니다. 코드 뿐만 아니라 HTML 및 XML에 대한 IntelliSense(자동 완성) 기능이 또한 지원됩니다.

이러한 비주얼하고 강력한 편집 기능은 개발 효율을 높여줍니다(개인적으로도 처음 ASP.NET을 접했을 때 Visual Studio .NET 개발 환경에 강한 인상을 받았습니다).

⑤       상태 관리(State management)

ASP의 상태 관리에 대하여 언급한 문제점을 보완하여, ASP.Net은 세션과 응용 프로그램의 상태관리에 대한 해법을 제시하고 있습니다. 세션 상태 정보는 메모리 혹은 데이타베이스에 저장될 수 있으며 웹 팜 환경에서의 공유가 가능하게 되었습니다. 또한 상태 정보는 클라이언트의 연결이 끊기거나 서버 작업이 실패한다 해도 복구될 수 있도록 디자인되었습니다.

⑥       서버 활성화 상태에서의 프로그램 갱신

클라이언트가 연결되거나 서버가 활성화 상태에서 프로그램 컴포넌트(파일)를 갱신시킬 수 있습니다. Framework는 새로운 버전의 컴포넌트를 가능한 빨리 응용 프로그램에 카피합니다. 이때, 삭제되거나 구 버전의 컴포넌트는 클라이언트의 연결이 끊길 때 까지 메모리 상에 위치되어 사용됩니다. 이후에는 새로운 버전의 컴포넌트가 로드됩니다.

⑦       XML에 기반한 환경 설정

ASP.NET에서의 환경 설정은 읽거나 수정하기 쉬운 XML 파일(Web.config)에 저장됩니다.이 파일은 확장 가능하며 다른 서버에 이식하기도 용이합니다. 다른 서버로 이전 시 단지 응용 프로그램 파일과 함께 XML 환경 구성 파일을 복사는 것으로 작업이 끝납니다.

３     정리

ASP는 많이 사용되어왔고 VB Script를 사용하여 많은 개발자들이 쉽게 익힐 수 있습니다. 많이 사용된 만큼 안정적이며 개발하기도 쉬워 빠르게 시스템을 구축할 수 있는 강점도 있습니다. 하지만 현재의 개발 패턴과 흐름에 부합되지 못하는 부분과 내포하고 있는 적지 않은 문제점들이 존재합니다.

이러한 문제들에 대한 해법을 제시하며 출시된 것이 .Net 플랫폼의 ASP.NET으로 기존 Classic ASP가 갖는 확장성 부족, 성능상의 문제, 보안 구성의 어려움, 유지보수의 어려움 등 많은 문제들에 대한 진보된 매커니즘을 보여주고 있습니다.

또한 ASP.NET 응용 프로그램을 위한 Visual Studio .NET 개발 환경은 개발 효율을 극대화 할 수 있는 방향으로 디자인되어 있습니다.

ASP를 구시대의 유물로 치부해 버릴 수는 없습니다. 좁은 의미에서 ASP.NET은 ASP의 확장된 버전입니다. 이것은 ASP.NET은 기존 Classic ASP에 대한 호환성을 유지하고 있다는 말입니다. 단, 스크립트 기반의 Classic ASP를 고수하는 것보다는 .Net 플랫폼 상의 ASP.NET으로 전환하는 것이 웹 응용 프로그램의 개발, 품질, 유지보수에 있어서 보다 많은 잇점이 있을 것입니다.

이 문서는 “ASP vs ASP.NET”에 초점이 맞춰져 있습니다. 정리를 마무리하기 전에 “X 솔루션 Upgrade와 관련한 ASP vs ASP.NET”에 관한 부분을 첨언해볼까 합니다.

“X 솔루션”의 경우 기존 시스템은 Classic ASP로 COM+을 사용하며, 신규 개발된 시스템의 경우 최신 ASP.NET으로 개발되어 있습니다. ASP와 ASP.NET의 비교 자료에 대한 이해로 볼 때 현재 “X 솔루션” 업그레이드를 고려함에 있어서, 기존 ASP 응용 프로그램의 ASP.NET으로의 Migration은 당연한 고민의 대상이 될 것입니다. 일전의 ACT Stress Test의 결과에서도 RPS(초당 요청 수)를 제외하고 User Connection과 CPU 점유율에 있어서 비교적 최근에 개발된 ASP.NET 응용 프로그램이 좀 더 안정적인 결과를 보여주고 있습니다(RPS에 대한 부분을 포함하여 ACT 테스트를 재검증 해볼 필요가 있습니다).

“X 솔루션”의 기존 ASP를 ASP.NET으로 Migration한다고 할 때, “X 솔루션” 업그레이드 여건(비용, 기간, 인력)을 고려하여 적절한 범위를 산정해야 할 것입니다. 또는 기존 ASP를 그대로 살리면서 각 시스템 내의 핵심 업무와 레포팅 서비스 부분 등을 따로 추출하여 여건에 맞는 범위를 설정한 후 ASP.NET으로 신규 개발 하는 것도 하나의 방법이 될 것입니다. Migration의 범주는 아니지만 Migration이 여의치 않을 경우, IIS 및 ASP 튜닝을 통해 시스템 성능을 최적화 하는 것도 “X 솔루션” 업그레이드에 있어서 하나의 대안이 될 수도 있습니다.

개인적인 생각이지만, 현재 “X 솔루션”의 서브 시스템들을 포괄하는 전체 범위에서 아키텍쳐, 코드 등 제반 사항에 대한 표준화와 정비는 필연적이고 궁극적인 부분이라 생각합니다. 현재 “X 솔루션” 업그레이드 계획을 차치하고, 적어도 “X 솔루션” 내의 각 서브 시스템들이 일관된 표준을 유지하고 유기적으로 연동되면 세션 및 상태 공유가 원활할 수 있도록, 보다 장기적인 안목에서 전체 시스템에 대한 업그레이드 계획을 수립한 후 단계적인 실행 절차를 밟아나가야 할 필요성이 있다고 생각합니다.