Taeyo's ASP.NET
|
|
강좌 최초 작성일 : 2004년 11월 22일|
강좌 전 태오의 잡담>
이 강좌는 월간 마이크로소프트 12월에 기획기사로 작성했던 것을 정리한 것입니다. ASP.NET Beta 1을 대상으로
작성된 것이기에, 차후 정식버전의 내용과는 다소의 차이가 존재할 수 있습니다. ^^;
ASP.NET 2.0, 웹 애플리케이션 개발의 진화
글쓴이 : 김태영 (Taeyo) 이번 컬럼에서는 Microsoft .NET Framework 2.0 중 웹 어플리케이션 개발을 위한 플랫폼인 ASP.NET 2.0에 대한 기술에 대해서 알아보도록 하겠다. ASP.NET 2.0. 또 한번의 놀라운 진화. Active Server Pages 1.0이 세상에 처음 모습을 드러냈을 때, 개발자들의 반응은 냉담했었다. ASP라는 기술은 그다지 주목받지 못했으며, 그 기술이 훗날 전 세계에서 가장 폭넓게 사용되는 웹 개발 기술이 될 것이라고는 누구도 예상하지 못했다. 그리고, 얼마간의 시간이 흐른 뒤, 웹 프로그래밍 계에 한 획을 긋게 될 ASP 2.0이 드디어 세상에 그 모습을 드러냈다. 그 시기는 인터넷이라는 것이 서서히 일상의 문화로서 한 자리를 찾아가는 시기이기도 했다. 전자상거래가 화두로 떠오르면서 전 세계의 웹 개발자들은 기존 버전과는 달리 막강하게 변모한 ASP 2라는 기술에 관심을 보이기 시작했고, 눈 깜짝할 사이에 ASP는 세계에서 가장 효과적인 웹 어플리케이션 개발 기술로서 인정받게 되었다. 그리고, 기술은 계속 진화하여 ASP 3까지 발전하였으며, 종국에는 ASP와 .NET 기술이 결합하여 ASP.NET까지 등장하게 되었다. ASP.NET 1.0이 처음 ASP 개발자들에게 그 모습을 드러냈을 때, 사실 평가는 그다지 좋은 편이 아니었다. 그만큼 기대가 컸기 때문일까? 획기적인 개발 편의성을 기대했던 개발자들에게 ASP.NET은 단지 이벤트 지향 프로그래밍 방식으로 코드를 작성할 수 있다는 부분 이외에는 크게 눈길을 끄는 부분이 없어 보였다. 게다가, 포스트백(Postback)이라는 새로운 페이지 처리 방식과 다소 복잡하게 느껴지는 코드 비하인드 모델에 몇몇 개발자들은 오히려 혼란스러움을 느끼기도 하였다. 이는 대부분의 국내 웹 개발자들이 OOP언어와 함께 프로그래밍을 시작하기 보다는 스크립트 언어와 함께 프로그래밍을 배웠기에 일어나게 된 어쩌면 자연스러운 불만일 수 있다. 사실, 개체 지향적인 프로그래밍 방식에 대한 이해와 웹 프로그래밍의 처리방식에 대한 이해를 모두 가져야만 제대로 이해할 수 있는 것이 ASP.NET이다. 둘 중 하나라도 지식이 부족하면, 이 기술은 단지 쉬운 기술을 복잡하게 꼬아놓은 것으로 밖에 보이지 않을 수 있다. 그렇기에, ASP.NET이 인정을 받기 시작하는 데에는 그만한 시간이 필요했다. 개발자들이 ASP.NET을 더 이상 ASP와 비교하지 않게 되자, 제대로 된 ASP.NET의 모습을 이해할 수 있게 되었고, ASP.NET은 서서히 주변에 쓸만한 기술이라는 입 소문을 내게 되었다. 하지만, 기술 자체는 획기적이었지만, 아무래도 1.0 버전의 새내기 기술은 기존 웹 개발자들이 기대한 만큼의 만족은 주지 못했던 것이 사실이다. 버전 1.0이 나온 이후 4년. 상당히 오랜 기간이 흘러왔다. 그리고, 아직 의견은 분분하지만 개발자들의 은근한 기대 속에서(다음 버전에 대한 기대) 그 사이 ASP.NET도 어느 정도 자신만의 자리를 차지하기 시작했다. 그리고, 이러한 상황을 아는지 모르는지 ASP.NET 2.0이 드디어 그 모습을 드러내고 있다. 기대 반, 우려 반 속에서 말이다. ASP.NET 2.0 알파, 베타 1 버전을 만나보고 난 필자의 느낌을 날씨로 이야기하라면 ‘해 뜸’이라고 표현하고 싶다. 대부분의 ASP.NET 개발자들이 서운해했던 부분들에 대한 보완과 개선이 상당부분 이루어져 있었기 때문이다(이번 버전을 준비하면서 아마도 MS 본사의 ASP.NET 팀은 웹 개발자들의 목소리에 귀를 상당히 많이 기울인 것 같다). 그리고, 각 기능에 대한 구체적인 내용들을 살펴보면서는 다소 흥분되기 시작했다. “이건 뭐야? 개발자들을 다 없애버릴 작정인 건가?”라는 말이 나올 정도였으니 말이다. 그렇다. 진지하게 그렇게 생각했었다. 데이터베이스와 연동되는 그리드(일종의 게시판)를 작성하고, 사용자 로그인/로그아웃을 처리하고, 비밀번호 복구 및 사용자 추가/관리 기능, 사이트 탐색 메뉴 기능과 입력 값의 유효성 검사, 사이트의 테마와 스킨 등 기본적인 웹 사이트에서 필요한 공통 기능들을 프로그래밍 코드 한 줄 작성할 필요 없이 이룰 수 있다면, 여러분은 그런 생각이 들지 않겠는가? ASP.NET 2.0이 제공하는 새로운 기능들이 놀랍게도 바로 그러하다. ASP.NET 2.0이 새롭게 제시하는 프로바이더 디자인 모델 패턴(Provider Design Model Pattern)과 그와 관련된 API들, 그리고 기존의 2배가 넘는 서버 컨트롤들의 지원은 웹 개발 플랫폼의 또 한번의 진화라는 말이 무색하지 않을 정도로 획기적이라 할 수 있다. 더욱 놀라운 것은 그 기능적인 발전이 ‘기존 ASP에서 ASP.NET으로의 진화’에 필적할만한 수준임에도 불구하고, 학습하기에 그리 많은 비용(시간과 노력)을 요구하지 않는다는 점이다. ASP.NET 2.0은 그러한 혁신적인 기능들을 익히기 위해서 개발자에게 많은 시간을 요구하지 않는다(이는 다소 주관적인 판단일 수 있음을 밝힌다). 특정 기술의 새로운 버전이 나올 때마다 수 많은 새로운 것들을 익혀야 한다는 압박 속에서 힘겨워했던 개발자들 입장에서 보면 이는 매우 기쁜 소식일 것이다. ASP.NET 2.0과 처음 인사를 나누게 되면, 개발자들은 그 대단한 기능들에 감탄함과 동시에, 그 간결한 사용법에 대해서도 감탄을 하게 된다. ASP.NET 2.0의 개발 코드 중의 하나가 Codeless(코드가 필요없는 개발)라는 것을 안다면, Microsoft의 ASP.NET 팀이 얼마나 개발자 편리성에 중점을 두어 ASP.NET 2.0을 준비하고 있는지를 간접적으로나마 느낄 수 있을 것이다. 본론을 시작하기에 앞서, 다소 안타까운 부분은 이번 컬럼에서 ASP.NET 2.0의 모든 기능들을 세세하게 들여다보기는 어려울 것 같다는 것이다. 지면의 압박이 있기에 그렇기도 하지만, ASP.NET 2.0은 현재 기준 Beta 1 버전이어서 차후 일부 변경될 소지도 있기에 그러하다. 해서, 이번 컬럼에서는 개별적이고 세세한 기능적인 부분에 대한 논의 보다는 전반적인 ASP.NET 2.0의 모습을 살펴보는 쪽으로 진행하도록 하겠다. ASP.NET 개발자 입장에서 보았을 때, 눈길을 크게 끄는 기능들을 중심으로 해서 말이다. (ASP.NET 2.0에서 제공하는 새로운 기술들을 더욱 구체적으로 알아보고 싶다면 다음 링크를 참고해 보기 바란다. 이는 ASP.NET 2.0의 새로운 기능들을 일목요연하게 정리해 놓은 MSDN의 컬럼 구역이다. (그림 1-1)
ASP.NET 2.0의 새로운 기능들 ASP.NET 2.0 버전은 모든 기능측면에 있어서 비약적인 발전과 강화가 있었다. 웹 페이지 개발 측면에서 바라보면, ASP.NET 2.0은 기능적으로 강화된 새로운 컨트롤들을 제공하고 있어서, 기존에 반복적으로 작성해야 했던 로직 및 기능들을 반복해서 작성함 없이 매우 간단하게 ASP.NET 페이지에 그러한 기능들을 추가할 수 있게 한다. 예를 들면, 인증 처리와 관련된 Login, PasswordRecovery, ChangePassword 컨트롤을 비롯하여, 다양한 스킨을 지원하는 Treeview 컨트롤, 사이트 메뉴 컨트롤, 데이터베이스 관련 작업을 위한 GridView, DetailView 컨트롤 등등이 그것이다. 게다가, 지금 나열한 이러한 컨트롤들은 자체 처리 기능까지 내장하고 있어서, 단 한 줄의 코드 작성 없이도 자신의 역할을 수행해낸다. 예를 들면, Login 컨트롤은 단 한 줄의 코드도 없이 사용자 인증 처리를 스스로 처리하며, GridView 컨트롤도 웹 페이지 상에서 데이터를 쉽게 출력하고, 편집할 수 있는 기능을 단 한 줄의 코드 작성 없이도 가능하게 한다. 이러한 편의성의 이면에는 프로바이더 디자인 모델 패턴(Provider Design Model Pattern)이라는 추상적인 패턴의 도입이 있다. 프로바이더 개념은 처음에는 다소 어려운 개념처럼 느껴질 수 있지만, 알고 보면 사실 크게 어렵지 않은 내용이며, 이미 대부분의 개발자들이 알고 있어왔던 개념이기도 하다. 하지만, 프로바이더라는 개념에 대한 이해가 없어도 그를 이용하여 ASP.NET 웹 어플리케이션을 개발하는 데에는 전혀 문제가 없다. 이는 마치 기존에 OLEDB 프로바이더에 대한 지식이 없어도 그를 이용해서 데이터베이스를 대상으로 맘껏 쿼리를 실행할 수 있었던 것과 같다. 프로바이더 디자인 모델 패턴은 기술적인 복잡함을 추상화하고 있기에 개념자체는 다소 복잡하게 보일지 몰라도 사용하는 측면에서 보면 상당히 쉽고, 편리하다. (그림 1-2)
예를 들면, ASP.NET 2.0에서는 사용자 인증 및 관리를 위한 보안 관련 서버 컨트롤들이 새롭게 제공되는데, 이 컨트롤들은 프로바이더 디자인 모델 패턴과 Membership이라는 API를 통해서 실제 인증처리에 관한 모든 로직을 자체 제공 및 처리한다. 쉽게 말하자면, Login, LoginView, CreateUserWizard, ChangePassword 등의 컨트롤이 보안과 관련된 대표적인 컨트롤인데, 이러한 컨트롤들은 내부적으로 Access 데이터베이스를 자동으로 생성하여 그를 기반으로 인증을 처리한다는 것이다. 기본적으로 ASP.NET 2.0은 Microsoft Access 데이터베이스 파일을 인증 관련 요청이 처음 접수되는 경우, 동적으로 데이터베이스 파일을 만들어서(이미 존재하지 않을 경우에만) 그곳에 데이터를 저장하고, 그곳으로부터 필요한 데이터를 불러온다. 이러한 내부적인 처리 프로세스는 이미 해당 컨트롤과 API 그리고 프로바이더를 통해서 구현되어져 있기에, 개발자는 코드 한 줄 작성할 필요없이 적절한 서버 컨트롤을 사용하여 새로운 사용자를 추가하거나, 인증, 관리할 수 있는 것이다. 물론, 원한다면 데이터베이스 서버의 종류를 바꿀 수도 있다. 예를 들면, SQL 서버 등으로 말이다. ASP.NET 2.0이 기본적으로 제공해주는 프로바이더에는 AspNetAccessProvider와 AspNetSQLProvider가 있지만, 정식 버전에서는 조금 더 늘어날 수도 있을 것 같다. 만일, 정식 버전에서 여러분이 사용해야 하는 특정 데이터베이스 서버에 대한 프로바이더가 지원되지 않는다해도 크게 걱정할 것은 없다. 필요하다면 오라클이나, 인포믹스등의 데이터베이스 서버를 이용하게끔 직접 설정할 수 있기 때문이다. 이를 위해서는 단지 별도로 프로바이더를 제작해주기만 하면 된다. (별도의 작업이 요구되긴 하지만, 그리 어려운 작업이 아니다) 하지만, 대부분의 경우 개발자가 프로바이더들을 직접적으로 건드릴 일은 없을 것이다. 개발자들은 그보다는 주로 ASP.NET 2.0에서 새롭게 제공하는 편리한 API들을 즐기는 것으로 시간을 보내게 될 것이다. 그리고, 무엇보다 ASP.NET 개발자들이 기뻐할만한 소식은 UI 페이지 디자인 측면에서의 획기적인 지원, 마스터 페이지의 도입 소식이다. 마스터 페이지 기능은 기존 ASP.NET 1.x에서는 사용자 정의 컨트롤과 같은 것을 이용해서 다소 복잡하게 처리해야 했던 공통 UI의 재 사용을 획기적으로 개선한 것으로, 웹 폼에서 비주얼 상속(Visual Inheritance)을 가능하게 하는 기술이다. 마스터 페이지의 논리적인 모습은 그림 1-3을 보면 이해가 쉬울 것이다.
그림1-3에서 보이는 것처럼, 마스터 페이지는 최종 UI 페이지에 반복적으로 재사용하게 될 내용들을 별도의 파일로써 정의해 둔 페이지를 말한다. 이렇게 마스터 페이지로 작성해 두고, 각각의 최종 UI에서 이러한 마스터 페이지를 이용한다면 공통적인 UI를 그대로 물려받게 됨으로써 개발 생산성이 크게 향상될 수 있다. 이는 마치 Microsoft Powerpoint 에서의 마스터 슬라이드를 연상하면 쉽게 이해가 될 것이다. 그림 1-4는 Visual Studio .NET 2005에서 마스터 페이지를 사용하여 페이지를 개발하고 있는 모습이다.
ASP.NET 2.0의 또 다른 진화는 바로 향상된 코드 비하인드 모델이다. 코드 비사이드(code-beside)라고도 불리는 이 기술은 Partial이라는 새로운 확장 클래스 개념을 통해서 코드 비하인드 클래스가 System.Web.UI.Page를 직접적으로 상속하지 않고, Page 클래스를 별도로 확장하는 개념을 적용하고 있다. (그림 1-5 참고)
이러한 변경으로 인해, 기존 ASP.NET 1.x에서 개발자의 실수로 간혹 발생하곤 했던 런타임 시의 타입 불일치 문제는 명쾌하게 해결할 수가 있게 된다. 예를 들면, 그러한 문제의 전형적인 시나리오는 다음과 같다. 기존 ASP.NET 1.x 시절에는 UI 페이지와 코드 비하인드 페이지가 명시적으로 연계된 구성을 가지고 있었다. 즉, UI 페이지에 서버 컨트롤이 추가되면 그에 따라 코드 비하인드 페이지에도 해당 컨트롤의 개체 선언이 추가되어야 해당 개체를 인식할 수 있는 구조로 되어져 있었으며, 빌드 및 배포 후에 컨트롤의 ID가 변경된다거나 UI 단에서 서버와의 연계성을 가진 특정 값들에 변경이 일어나면 서버에서 “예기치 않은 오류”가 발생할 수 있는 구조를 가지고 있었다. ASP.NET 2.0은 이러한 문제를 원천적으로 해결하기 위해서 코드 비하인드 파일을 상속되는 형식이 아닌 확장되는 형식으로 바꿈으로써 UI 페이지의 서버 컨트롤과 코드 비하인드의 실제 코드간의 연결이 ASP.NET 런타임에 의해서 실제 런타임 시에 관리되도록 내부 구조를 변경하였다. 그 결과, 개발자가 작성해야 할 코드(VS.NET이 자동으로 생성해주는 코드를 포함하여)도 혁신적으로 줄어들게 되었으며, 안전성 및 개발 생산성 측면에서도 상당한 진일보를 이룰 수 있게 되었다. 리스트 1과 2는 각각 ASP.NET 1.x 시절의 코드 비하인드 파일과 ASP.NET 2.0 버전의 코드 비하인드 파일의 일반적인 소스를 보여주고 있다. 두 리스트는 모두 페이지가 로드될 때, Label 컨트롤에 인사 메시지를 출력하는 코드를 포함하고 있다. 두 코드를 비교해 봄으로써 코드 비하인드의 내부적인 처리 구조 변화가 어떻게 개발 생산성을 높여주는 지 확인해 보기 바란다.
리스트 1. ASP.NET 1.x의 코드 비하인드 파일
리스트 2. ASP.NET 2.0의 코드 비하인드 파일
ASP.NET 2.0에서 눈에 띄게 개선된 또 다른 기능은 바로 캐싱(Caching)이다. 기존의 캐싱 기능들을 성능적으로 개선한 것에 더하여, 캐시를 위한 새로운 방안들도 추가되었는데, 이 들 중 개발자들의 눈길을 가장 크게 끄는 기능은 바로 SQL 서버 데이터베이스의 테이블에 캐시 종속성을 지정할 수 있는 기능이다. 이 기능을 이용하면 개발자는 테이블의 데이터가 변경되는 그 즉시 캐시가 갱신되도록 캐싱 정책을 세울 수가 있게 된다. 또한, ASP.NET 2.0에서는 개발자가 다양한 방식으로 웹 사이트와 웹 페이지를 사용자 정의 할 수 있다. ASP.NET 2.0에서 제공하는 Profile API를 사용하면 개별 사용자용 속성 값들을 자동적으로 할당 및 추적할 수 있는 기능을 제공할 수 있기 때문이다. Profile 클래스는 기존 Session 변수의 역할과 다소 비슷하다고 생각하면 이해가 용이하다. 하지만, Session에 비해 성능적으로도 뛰어나고, 개발자가 다루기에도 훨씬 직관적이기에 더욱 매력적으로 느껴질 것이다. Profile 클래스는 또한 ASP.NET 사용자 개별화(Personalization)의 일부이기에 이를 적절히 이용하면, ASP.NET 2.0에서 새롭게 제공되는 포탈 프레임워크 기능인 Web Parts와 연계할 경우 놀랄만한 사용자 정의 기능을 제공할 수 있게 된다(이 기능은 진실로 놀랍다). 즉, ASP.NET 2.0의 Profile과 Web Parts를 이용하여 사이트를 제작할 경우에는, 사용자가 브라우저 내에서 그들만의 페이지 구성 및 레이아웃을 꾸밀 수 있게끔 웹 어플리케이션을 구성할 수 있다는 이야기이다. 별로 놀랍지 않은가? 아마도 그럴 것이다. 그렇게 작성된 결과가 구체적으로 어떤 모습일지가 머리 속에 잘 그려지지 않았을 테니 말이다. 그렇다면, 백문이 불여일견이다. 그렇게 꾸며진 사이트를 직접 눈으로 본다면 아마 이해하기가 더 쉬울 것이다. 마이크로소프트의 MSN 사이트에 접속하여, My MSN 기능을 이용해보라. 바로 그와 동일한 기능을 ASP.NET 포탈 프레임워크와 Profile을 이용하면 대단히 쉽게 제작할 수 있다는 것이니 말이다(그림 1-6)
www.msn.com에서 로긴을 하고, My MSN으로 가면 각 사용자는 자신이 원하는 대로 컬럼 창을 추가하거나, 위치시킬 수 있다. 뿐만 아니라, 각 창을 드래그 앤 드롭으로 이동시킬 수도 있다(이 부분에서 많은 감동들을 받는다 ^^). 클라이언트 스크립트를 즐겨 다루는 이들은 알겠지만 이 기능은 직접 개발자가 작성할 경우, 스크립트로 상당히 복잡한 로직을 작성해서 처리해야만 한다. 해서, 스크립트를 상당히 잘 다루지 못 한다면 구현하기가 대단히 어려운 기능이기에 개발중인 웹 어플리케이션에 이러한 기능을 적용한다는 것은 대부분의 경우 마음만인 경우가 많았을 것이다. ASP.NET 2.0의 포탈 프레임워크와 Personalization 기능을 이용하면 이 또한 쉽게 구현이 가능하다. 뒷단에 존재하고 있을 수 많은 클라이언트 스크립트 기법과 기반 구조를 이해하지 않고서도 말이다. 이를 위한 기반구조를 제공해 주는 것이 ASP.NET 포탈 프레임워크이며, 그 중 사용자마다의 설정을 유지할 수 있도록 도와주는 기능이 Personalization의 Profile 클래스이다. 앞에서도 잠깐 이야기했지만, Profile 클래스가 제공하는 기능은 기존에 Session 개체를 통해서 개발자가 각 개인의 정보를 유지했던 것과 유사한 것이라 할 수 있다. 하지만, 성능적으로나 사용성 측면에서 보았을 때 Session을 이용하는 것보다 상당히 낫다(물론, 이 부분은 논란이 있을 수 있으므로, 상황에 따라 다를 수도 있다는 전제를 추가적으로 덧붙여 두도록 하겠다) ASP.NET 2.0에서는 또한 상당히 많은 신인 컨트롤들이 새로이 데뷰하고 있기도 하다. 그 중 우리의 눈길을 끄는 대표적인 컨트롤로는 트리뷰(TreeView) 컨트롤과 메뉴 컨트롤이 있는데, 이들은 사용하기도 매운 쉬울 뿐만 아니라, 자체 스타일 기능이 내장되어져 있어서 꾸미기에도 매우 쉽다는 장점을 갖고 있다. 트리뷰의 경우는 [자동 속성] 기능을 이용해서 디자인을 최신의 MS 스타일로 쉽게 작성할 수 있으며, 메뉴 컨트롤의 경우는 클라이언트 스크립트에 대한 부담없이 쉽게 동적으로 나타나는 메뉴를 구성할 수 있다(그림 1-7). 모든 복잡한 내부처리는 ASP.NET 2.0이 대신해 주고 있는 것이다.
ASP.NET 2.0에서 개발자들이 반가워할 만한 또 다른 소식은 2.0에서부터는 다른 페이지로의 전송(페이지 교차 포스팅, Cross-Page Posting)이 가능하게 된다는 것이다. 물론, ASP.NET 1.x 버전에서도 다른 페이지로 데이터를 전송하는 것이 불가능하지는 않았었다. 웹 폼을 이용하지 않고 Html 폼을 이용한다면 말이다. 하지만, 그렇게 하게 되면 ASP.NET의 기반 서비스를 전혀 이용하지 않는 것이 되므로 (ASP.NET을 도입하는 의미가 전혀 없게 되기에) 사용이 권장되지 않았다. 해서, 특별한 이유가 있지 않은 한 ASP.NET 1.x에서는 기본적으로 웹 폼은 포스트백(자기 자신 페이지로의 전송)을 기본 원칙으로 했다. 이는 ASP.NET 2.0에서도 달라지지 않았지만, 2.0은 개발자의 목소리에 경청을 한 덕분인지, 추가적으로 교차 페이지 전송도 지원을 한다. 이로써, 웹 개발자는 여러 페이지에 걸쳐서 어떤 프로세스를 수행할 수 있게 된 것이다. 페이지 교차 포스팅을 하기 위한 간단한 방법은 버튼 컨트롤의 PostBackUrl 속성을 이용하는 것이다. 버튼의 PostBackUrl 속성에 이동할 페이지 명을 지정하면, 해당 버튼이 클릭될 경우에는 그 페이지로 교차 전송이 일어나게 된다. 리스트 1.3은 페이지 교차 포스팅을 요청하는 버튼 컨트롤의 소스를 보여주고 있다. 소스 코드 중 굵은 부분에 주목하라. (샘플에서의 현재 페이지 이름은 PageOne.aspx 이다)
리스트 1-3. PageOne.aspx
페이지 교차 포스팅의 대상이 되는 페이지(샘플의 경우 PageTwo.aspx)는 반드시 지시문(Directive) 구역에 @PreviousPage를 지정해 주어야 한다. 자신이 참조할 이전 페이지의 형식이나 경로를 지정해 줘야만 현재의 페이지에서 이전 페이지의 멤버들에 접근이 가능하게 되기 때문이다. 리스트 1.4는 @PreviousPage 지시문을 추가적으로 설정하고 있는 두 번째 페이지의 HTML 소스를 보여주고 있다.
리스트 1-4. PageTwo.aspx
그리고, 리스트 1-5는 두 번째 페이지(PageTwo.aspx)의 코드 비하인드에서 어떻게 이전 페이지(PageOne.aspx)의 DropDownList 컨트롤에 접근하는 지 그 방법을 보여주고 있는데, 이는 Page 개체의 PreviousPage 속성 개체를 통해서 가능하다. 그림 1-8은 이러한 동작의 결과를 보여준다.
리스트 1-5. PageTwo.aspx의 코드 비하인드 소스
ASP.NET 2.0이 제공하는 편리함은 개발 측면에만 한정된 것이 아니다. 관리적인 측면에서도 ASP.NET은 진보된 편리성을 제공하는데, 이전 ASP.NET 1.x 버전의 경우는 웹 어플리케이션 관리를 위해서 Web.config라는 XML 파일을 직접적으로 변경하여야 했던 반면, ASP.NET 2.0에서는 IIS 내에 ASP.NET 설정 구성을 위한 UI가 포함됨으로써 더욱 쉽게 사이트를 관리할 수가 있게 되었다.(그림 1-9 참고)
또한, Web Administration Tool이라는 웹 어플리케이션 관리 사이트를 제공해 줌으로써 여러가지 웹 사이트 관련 관리를 용이하게 해 준다. 여기서 제어할 수 있는 것들로는 Security, Profile , Application Configuration, Provider Configuration 등이 있다. (그림 1-10 참고)
지금까지 간략하게 ASP.NET 2.0의 몇몇 특징들을 살펴보았는데, 위에서 설명한 많은 기능들은 ASP.NET 2.0에서 제공되는 진보된 기능들의 일부에 불과할 뿐이다. 지금까지의 이야기로 새로운 기술에 대한 기대감과 반가움이 교차하는 분들은 이 컬럼을 모두 읽은 뒤에 MSDN 사이트로 이동하여, 그 멋진 모습들을 더 구체적으로 살펴보길 권한다. 비록 영어의 압박이 느껴진다해도, 내용 자체는 매우 재미있을 것이다. 필자가 꼭 읽어보라고 권하고 싶은 컬럼은 ASP.NET Internals 이다.
현재 필자는 이 컬럼을 작성하는 것에 더하여, 11월과 12월에 걸쳐 MSDN 세미나를 통해서 ASP.NET 2.0에 대한 내용을 발표하고 있기도 하다. 세미나에서는 이 컬럼에서는 간략하게 소개할 수 밖에 없었던 내용들을 실제 데모와 함께 조금은 구체적으로 파고 들어 진행했는데, 세미나를 경청한 개발자들 대부분의 피드백은 “기대가 된다” 였다. 그리고, ASP.NET 2.0의 이러한 진보에 맞춰 Visual Studio .NET은 어떤 편리한 기능들을 제공하려고 준비 중에 있는지 궁금해 하는 분들이 많았다. 해서, 그 부분에 대한 이야기도 이 자리에서 조금 같이 나누어 볼까 한다. 최고의 집을 짓기 위한 자재와 기반은 ASP.NET 2.0이 모두 준비해 주었다. 그렇다면 이제 개발자의 입장에서 남은 것은 어떤 도구로 집을 지을 것인가 일 것이다. 맨 손으로 집을 짓는 것은 아무래도 무모해 보인다. 그렇게 여유로운 프로젝트는 사실 현실 세계에서는 존재하지 않을 테니 말이다. 그러한 이유로 많은 개발자들이 .NET(ASP.NET 포함) 프로그래밍을 위해서 Visual Studio .NET(이하 VS.NET)을 선택해 왔다. MS의 제품이긴 하지만 자타가 공인하는 최고의 툴임은 틀림 없으니 말이다. VS.NET의 새로운 버전은 2005로써 ASP.NET 2.0의 등장과 발 맞추어 출시될 예정에 있다. 현재는 베타 버전이 인터넷을 통해서 배포되고 있다. VS.NET 2005에서도 웹 개발자들을 위한 많은 보강이 있었다. 개발자들이 불편하다고 생각했던 많은 부분들이 개선되었으며, 개발자 각각이 자신의 취향에 맞게 툴을 설정할 수 있는 옵션들도 상당히 많이 제공되고 있다. 무엇보다 가장 크게 눈에 띄는 부분은 더 이상 VS.NET이 웹 서버에 의존적이지 않다는 부분이다. VS.NET은 웹 페이지 실행 시 자체적으로 보유하고 있는 가상 웹 서버(이전 버전의 Cassini와 유사)를 먼저 구동시키고 그 가상 서버에서 웹 페이지를 실행하게 한다. 그리고, 가상 웹 서버는 VS.NET을 닫는 순간 모두 같이 해제된다. 이것은 큰 의미를 지닌다. 왜냐하면, 이제 개발자는 더 이상 IIS에 의존적이지 않아도 되며, 그에 따라 웹 파일들의 관리도 상당히 간단, 용이해지기 때문이다. 예전에는 프로젝트 파일과 실제 웹 파일들이 서로 다른 폴더에 형성됨으로 해서(설정을 바꾸지 않았다면, 웹 파일들은 VS.NET에 의해 자동적으로 C:\inetpub\wwwroot에 놓여진다), 관리 측면에서 다소 혼란스러움이 있었지만, 이제는 반드시 가상 웹 어플리케이션으로 특정 디렉터리를 설정하지 않아도 특정 폴더를 웹 폴더처럼 만들어 개발할 수 있게 되었기 때문에, 더 이상 웹 어플리케이션을 위한 파일들을 C:\inetpub\wwwroot에 올릴 필요도, 각 파일들을 관리하기 위해서 폴더를 이리 저리 돌아다닐 필요도 없게 되었다(그림 1-11 참고).
또한, 초보 개발자를 위해서 Starter kit 사이트가 템플릿으로 제공되는데, 그림 1-12에서 보이는 것처럼 [새 웹 사이트] 마법사에서 [Personal Web Site Starter Kit]을 선택하면 자동으로 자신의 소개 및 이미지 갤러리를 제공하는 심플한 수준의 웹 사이트가 자동으로 생성된다. 겉으로 보기엔 단순해 보일 수 있지만, 기능적으로는 제법 쓸만하게도 사용자 가입, 인증, 보안처리까지 다 되어있는 훌륭한 사이트이다. 자동 생성된 사이트의 소스를 살펴보면서 소스 분석을 해보는 것은 초보자에게 상당한 도움이 될 것이다. 장담컨대, 소스 분석을 하다 보면 여러분은 반드시 놀라게 될 것이다. 왜냐하면, 갖출 것은 어느 정도 갖춘 규모의 개인 사이트임에도 전체 소스 코드는 단 30 줄도 안되기 때문이다. Personal Web Site Starter Kit은 ASP.NET 2.0팀의 Codeless 목표가 ASP.NET 전반적으로 상당 부분 녹아있음을 입증해 주는 좋은 예이다.
또한, VS.NET 2005부터는 하나의 프로젝트에서 다중 언어를 사용하는 것도 지원된다(사실, 하나의 어플리케이션에서 다중 언어를 사용하는 것은 이전 1.x 버전에서도 가능하였다. 단지, VS.NET이 그것을 지원하지 않았을 뿐이다). 뿐만 아니라, 프로젝트에서 페이지 단위로 컴파일을 하는 것도 가능하다. 하나의 프로젝트는 반드시 하나의 DLL로 빌드 되었던 이전의 불합리함을 완전히 개선한 것이다. 디자이너 측면에서도 많은 부분이 보완되었는데, VS.NET 2005는 더 이상 개발자가 작성해 놓은 HTML을 자동으로 재 정렬하여서, 기껏 들여쓰기를 한 개발자의 마음을 더 이상 아프게 하지 않는다. 또한, [도구 상자]로부터 컨트롤을 드래그 앤 드롭 하여 웹 폼에 컨트롤을 올려놓는 방식이 코드 뷰에서도 가능하게 되었다는 점도 재미있다. 또한, 기쁜 소식은 VS.NET 2005에서는 인텔리센스 기능이 완전하게 제공된다는 것이다. HTML 뷰에서도, Web.Config에서도 이제는 인텔리센스 기능이 지원된다. ASP.NET 1.x 시절에는 많은 개발자들이 이러한 부분에서 인텔리센스 기능이 지원되지 않아 불편해 했었다. 해서, 심지어는 인텔리센스 기능이 지원되도록 직접 작업을 한 개발자들도 있었다. 그들에게는 미안하지만, 이제는 인텔리센스와 관해서는 더 이상 고민하지 않아도 된다. 또한, VS.NET 2005에서는 웹 어플리케이션의 쉬운 복사 및 배포를 위한 기능들도 제공된다. 그림 1-13과 1-14에서 볼 수 있듯이, 로컬 파일 시스템이나 FTP, IIS, 원격 웹 사이트로의 배포가 클릭만으로 가능하도록 편리한 방법들을 제공하고 있는 것이다.
그 외에도 소스 작성과 관계되어 수많은 편리한 기능들을 VS.NET 2005는 제공하고 있지만, 세세한 부분은 차후 정식 버전이 발표된 다음에 알아보는 것이 좋을 듯 하여 말을 아끼려 한다. 아직은 베타 1 버전이기에 베타 2와 RTM을 거치면서 사소한 기능적인 변경이 있을 수 있기 때문이다.
ASP.NET 2.0은 다소 불안하게 느껴지기도 했던 ASP.NET의 미래에 대한 확실한 청 사진을 제시하고 있다. 스마트 클라이언트가 세상을 지배하고 곧 ASP.NET은 사라지게 될 것이라는 루머 속에서 자신의 강화된 모습을 제시하여 ASP.NET의 역할이 어떤 것인지를 강하게 피력하고 있는 것이다. 인터넷을 하기 위해서 브라우저를 사용하고, 인터넷을 위한 데이터 기반이 HTML인 이상 ASP.NET은 웹 어플리케이션 개발에서 빠질 수 없는 기술이다. 그리고, 그러한 자신의 위치에서 모든 웹 개발자들이 필요로 했던 대부분의 공통적인 기능들을 ASP.NET 2.0은 제공하고 있다. 어쩌면 웹 개발자들이 해야할 일이 없어지는 것은 아닐까 우려하는 목소리도 나오겠지만, 그것은 우려해야 할 소식이 아니라 기뻐해야 할 소식이다. 반복적인 UI 작업으로 인해, 자신이 코더인지, 개발자인지에 대한 정체성 혼란을 한번이라도 느껴봤던 개발자라면 이번 ASP.NET 2.0을 통해서 진정한 개발자로 거듭날 수 있는 기회를 붙잡게 된 것이다. 물론, 모든 것은 자신의 마음에 달려있고, 자신이 많은 부분을 노력해야 하겠지만, 이젠 페이지의 UI, 컨트롤의 특정 기능지원 여부로 끙끙대는 시간보다는 비즈니스 로직의 개발 및 클래스 설계, 패턴 분석 쪽으로 더 많은 시간을 가질 수 있게 될 것이다. 코더의 역할은 ASP.NET 2.0이 상당부분 책임져 줄 것이기 때문이다. 다만, ASP.NET 2.0이 제공하는 편리함이 오히려 개발자를 나태하게 만들 수도 있다는 부분은 다소 우려스러운 부분이다. 해서, 우리는 나태한 개발자가 되지 않도록 노력해야 한다. 기술의 편리함, 도구의 편리함은 인간을 돕기도 하지만, 그만큼이나 게으르게도 하니 말이다. 꾸준한 노력을 마음에 품고, 시야를 조금씩 더 넓혀 나가자. ASP.NET 2.0은 웹 개발자에게 그러한 시야를 가질 수 있도록 도와줄 것이다. 그리고, 기술적인 고민의 시간들을 통해서 여러분은 진정한 개발자로 거듭날 수 있을 것이다.
|
