박종명의 아름다운 개발 since 2010.06

클라이언트에 데이터를 저장하다
HTML 5 에는 웹 사이트의 데이터를 클라이언트에 저장할 수 있는 새로운 자료구조인
Web Storage(웹 스토로지) 스펙이 포함되었다

Web Storage 의 개념은 심플하다
'키/ 값' 쌍으로 데이터를 저장하고 키를 기반으로 데이터를 조회하는 패턴이다

그리고 영구저장소(localStorage) 와 임시저장소(sessionStorage)를 따로 두어
데이터의 지속성을 구분할 수 있어 응용 환경에 맞는 선택이 가능하다

Web Storage 는 기존 웹 환경의 쿠키(Cookie)와 매우 유사한 개념이다
사실 거의 차이가 없어 보이기도 하다. 다만 몇 가지 쿠키의 단점를 극복하는 개선점이 도입되었다

그럼 쿠키(Cookie)는?
쿠키는 여전히 유효하고 꽤 적절한 클라이언트 저장도구 이다
HTML 5 에서 Web Storage 스펙을 새로 추가했지만 쿠키를 배제하는 것은 아니다
HTML 5 환경에서도 여전히 쿠키를 이용할 수 있다
다만 어떤 것을 사용할 지는 사용자 선택의 몫이라 하겠다

Web Storage 차이점 (쿠키의 단점?)

- 쿠키는 매번 서버로 전송 된다
웹 사이트에서 쿠키를 설정하면 이후 모든 웹 요청은 쿠키정보를 포함하여 서버로 전송된다
Web Storage 는 저장된 데이터가 클라이언트에 존재할 뿐 서버로 전송은 이루어지지 않는다
이것은 네트워크 트래픽 비용을 줄여 준다는 주요한 장점이 되겠다

- 단순 문자열을 넘어 (스크립트) 객체정보를 저장할 수 있다
문자열 기반 데이터 이외에 체계적으로 구조화된 객체를 저장할 수 있다는 것은 개발 편의성을
제공해 주는 주요한 장점이 된다. 브라우저의 지원 여부를 확인해 봐야 하는 항목이다

- 용량의 제한이 없다
쿠키는 개수와 용량에 있어 제한을 걸어 두고 있다
하나의 사이트에서 저장할 수 있는 최대 쿠키 수는 20 개이다. 그리고 하나의 사이트에서 저장할 수 있는 최대 쿠키 크기는 4KB 로 제한되어 있다. Web Storage 는 이러한 제한이 없다
(그러나 쿠키도 하위키를 이용하면 이러한 제한을 일부 해소할 수 있다.
 그리고 대부분의 시나리오에서 쿠키의 제한으로 까지 데이터를 저장할 일이 없다)

- 영구 데이터 저장이 가능하다
쿠키는 만료일자를 지정하게 되어 있어 언젠가 제거된다.
만료일자로 지정된 날짜에 쿠키는 제거되는 것이다.(만료일자를 지정하지 않으면 세션 쿠키가 된다)
만일 영구 쿠키를 원한다면 만료일자를 굉장히 멀게 설정하여 해결하기도 하였다
(그러나 과연 수 년이 지나도록  쿠키가 유지되어야 할 필요가 있을까?)

WebStorage 는 만료기간의 설정이 없다. 즉 한번 저장한 데이터는 영구적으로 존재하는 것이다
이것이 특별히 장점이 되는지는 잘 모르겠지만 쿠키와의 차이점이라는 것은 분명하다
-----

쿠키와 WebStorage 의 차이점과 개선사항에 대해 알아 보았는데 개인적으로,
Web Storage 가 쿠키보다 훨씬 좋은 이유는 없다고 본다.
다만 한가지 매번 서버로 전송되지 않는다는 특징은 꽤나 유용해 보인다
(특히 경량 환경인 모바일에서는 더욱 더)

그리고 쿠키는 더 상세한 설정이 가능해 어떤 환경에서는 더 적합해 보이기 까지 한다
쿠키에 대한 자세한 내용은 다음의 글을 참고하도록 하자
=> Cookie 제대로 알고 사용하자


로컬 스토로지(localStorage)와 세션 스토로지(SessionStorage)
Web Storgae 는 데이터의 지속성과 관련하여 두 가지 용도의 저장소를 제공한다

우선 기본적으로 Web Storage 는 쿠키와 마찬가지로 사이트의 도메인 단위로 접근이 제한된다
다시말해, A 도메인에서 저장한 데이터는 B 도메인에서 조회할 수 없다는 것이다
이것은 데이터의 보안적 측면에서 당연한 원칙이라 하겠다

- 로컬 스토로지
로컬 스토로지 저장한 데이터를 (명시적으로) 지우지 않는 이상 영구적으로 보관한다
앞서 말한대로, 도메인마다 별도로 로컬 스토로지가 생성된다
windows 전역 객체의 localStorage 라는 컬렉션을 통해 저장/조회가 이루어진다

- 세션 스토로지
세션스토로지는 데이터의 지속성과 액세스 범위에 특수한 제한이 존재한다
세션스토로지는 windows 전역 객체의 sessionStorage 라는 컬렉션을 통해 저장/조회가 이루어진다

데이터 유지 측면:
세션 스토로지는 데이터가 지속적으로 보관되지 않는다
이는 마치 브라우저 기반 세션 쿠키와 그 성질이 비슷한데, 현재 페이지가 브라우징 되고 있는
브라우저 컨텍스트 내에서만 데이터가 유지된다

로컬 스토로지는 브라우저를 종료해도 데이터는 보관되어 다음번 접속에도 그 데이터를
사용할 수 있는 반면, 세션 스토로지는 브라우저가 종료되면 데이터도 같이 지워진다.
즉 브라우저가 종료되면 세션 스토로지도 삭제된다는 것이다

데이터 범위 측면:
세션 스토로지 역시 Web Storage 의 기본 보안 처럼 도메인별로 별도로 생성된다
여기에 더불어 세션 스토로지는 같은 사이트의 같은 도메인이라 할지라도 브라우저가 다르면
서로 다른 영역이 된다(즉 브라우저 컨텍스트가 다르다)

탭 브라우징이나 브라우저를 하나 더 실행해서 같은 페이지를 실행했을 때,
이 두 페이지의 세션 스토로지는 각각 별개의 영역으로 서로 침범하지 못한다는 의미이다
(도메인만 같으면 전역적으로 공유 가능한 로컬스토로지와 구분되는 특징이라 하겠다)


브라우저 지원 현황
아래 표는 http://caniuse.com/ 에서 제공하는 브라우저(버전)별 Web Storage 지원 표이다
(데스크탑 용 브라우저 기준이다)

끌어다 놓기(드래그 앤 드롭, Drag & Drop)
끌어다 놓기는 사용자 편의성을 고려한 편리한 UI 기능이라 할 수 있는데,
아래 그림에서 보는 바와 같이 영역 A -> 영역 B로 특정 콘텐트를 마우스로 이동하는 것을 말한다

소스코드의 주석에 상세히 설명을 달았지만 간단히 전체적인 흐름을 설명하자면,
드래그 대상(Source)은 왼쪽 select 박스의 option 항목들이며,
드롭 대상(Target)은 오른쪽 select 박스이다

드래그 대상인 option 요소에 draggable="true" 속성을 부여해 드래그 가능한 상태로 설정하였다
그리고 dragstart 이벤트를 구현하여 드래그 액션이 시작될 때 dataTransfer 객체에
드래그 데이터(여기서는 option 의 ID)를 저장하고 있다

드롭 대상인 오른쪽 select 박스에는 dragenter, dragover, drop 이벤트를 구현하여
preventDefault 함수 호출로 select 박스가 드롭이 가능하도록 설정하였으며
dataTransfer 객체에서 드래그 데이터(여기서는 option 의 ID)를 꺼내온다
이렇게 꺼내온 드래그 데이터를  문서객체에서 조회하여 드래그 대상에서는 제거하고 드롭 대상에
추가하는 로직으로 구성되어 있다

그리고 추가로 드래그 관련 이벤트의 호출 순서를 보기 위한 코드가 각 이벤트에 추가되어 있다

아래는 데모의 실행 화면이다. 먼저 드래그가 중에 캡쳐한 화면이며,

HTML 5 는 위치 정보와 관련한 Geolocation 스펙을 포함하고 있다
(엄밀히 말하자면 이 스펙은 HTML Working Group 과 분리되어 있는  Geolocation Working Group
에 의해 표준화가 진행되고 있다고 한다)

Geolocatoin API를 이용하면
현재 웹 페이지가 실행되는 단말의 위도, 경도와 같은 위치 정보를 얻어 올 수 있다

Geolocation 지원 브라우저 현황
현재 IE를 제외한 대부분의 최신 웹브라우저에서 Geolocation을 지원하고 있다
아래 표는 http://caniuse.com/ 에서 제공하는 브라우저(버전)별 Geolocation 지원 표이다
(데스크탑 용 브라우저 기준이다)

MS IE 9 가 unknown 이라고 되어 있지만 아마 지원하게 될 것이다.
MS 가 HTML 5 지원을 강력히 표명하고 있기 때문이다

그리고 이 코드를 파이어폭스에서 실행한 결과 화면이다
(데스크탑 브라우저에서 테스트 해 봤는데, 구글 크롬과 사파리의 경우 지원은 되는데 위도,경도
 정보가 불러와 지지가 않는다. 파이어폭스와 오페라, 아이폰 사파리에서 정상 동작 확인 함 )

HTML 5 의 많은 기능 중 웹 페이지가 단순 문서 표현을 넘어 응용프로그램과 같이 동작할 수 있도록
하는 주요한 기능 중 하나가 바로 Web Workders 이다

요즘 웬만한 응용프로그램들은 멀티 프로세스, 멀티 쓰레드를 구현하고 있다
웹 페이지도 이러한 멀티 쓰레드 구현이 가능하게 된 것이다

그간 웹 페이지는 단일 쓰레드 모드에서 수행될 수 밖에 없었다
만일 값을 반환하기까지 작업이 오래 걸리는 스크립트를 수행한다면 다른 UI 작업을
스크립트 작업이 종료될 때 까지 대기해야만 했다

그러나 HTML 5 에는 Web Worker 라는 스펙을 추가 했으며 브라우저에서는 이 스펙을 기반으로
멀티 쓰레드 구동이 가능하도록 브라우저를 설계하기에 이르렀다


롱~타임(Long~ Time) 작업은 워커에게 맡기기
이제 스크립트 작업이 오래 걸린다고 해서 페이지를 멈추고 기다릴 필요가 없어졌다
웹 워커는 자바스크립트 코드를 UI 쓰레드와는 별도인 백그라운드에서 수행될 수 있도록 하는 표준적인 방법을 제공하기 때문에 웹 페이지를 가로막지 않고 스크립트를 돌릴 수 있게 되었다

다음과 같은 롱~타임 스크립트 작업에 웹워커는 안성맞춤 일 것이다
- 매우 복잡한 수학적 계산 작업
- 원격지에 있는 리소스에 대한 액세스 작업(또는 로컬 스토로지를 액세스 하는 경우)
- 백그라운드에서 조용히(?) 오랜시간 작업해야 하는 경우
- UI 쓰레드에 방해 없이 지속적으로 수행해야 하는 작업 등

사실 웹 워커 만의 지침은 없다. 일반적인 응용프로그램의 백그라운드 작업을 연상하면 된다


브라우저가 Web Worker 를 지원하나요?
HTML 5 가 아직 산업 표준이 완료된 것이 아니기에 브라우저별로 지원 여부가 상이할 수 있다
그리고 브라우저 버전별로도 지원 유/무가 다르기도 하다

따라서 웹 페이지에 웹 워커를 동작시키기 전에, 현재 페이지를 랜더링 하고 있는 브라우저가
웹 워커를 지원하는지 체크하는 것이 필수이다 (이것은 하위 호환성을 위해서도 중요하다)

브라우저의 웹 워커 지원 유/무 체크는 매우 간단한 방법으로 할 수 있다
전역 윈도우 객체의 워커(Worker) 속성을 살펴보면 된다. 아래는 샘플 코드이다

if(!!window.Worker){
      alert("이 브라우저는 웹 워커를 지원합니다")
}
else{
      alert("이 브라우저는 웹 워커를 지원하지 않습니다")
 }


Web Workers 개념도
웹 워커는 HTML 페이지에서 Worker 라는 객체를 통해 실행된다
HTML 페이지에 Worker 객체를 생성하기 위해서는 워커의 작업을 정의한 자바스크립트파일(.js)
을 Worker 객체 생성 시 전달해 줘야 한다
ex) var worker = new Worker("worker.js")

이후 롱~타임 작업은 .js 파일에 정의된 스크립트로 수행되며,
HTML 페이지와는 서로 데이터를 주고 받을 수 있는 매커니즘이 제공되는 것이다

양쪽 모두 상대에게 데이터를 송신할 때는 postMessage 라는 메서드를 이용하며
데이터를 수신할 때는 onmessage 이벤트를 통해 전달 받는다

아래 그림은 기본적인 (단일) 워커와 HTML 페이지 간 데이터 송/수신 개념도 이다

function sleep(milliSeconds){ 
  var startTime = new Date().getTime(); // get the current time  
  while (new Date().getTime() < startTime + milliSeconds); // hog cpu
}

- HTML 페이지
이제 이 워커(파일)을 이용하는 HTML 페이지를 아래와 같이 작성한다
앞서 정의한 worker.js 파일을 기반으로 Worker 객체를 생성하고 postMessage 메서드를 통해
워커로 메시지를 전달한다. 또한 onmessage 이벤트를 정의하여 워커로 부터 전달되는 메시지를
받을 수 있도록 한다. 그리고 워커의 작업을 중지시키려면 terminate 메서드를 호출하면 된다

<!DOCTYPE html>
<html>
  <head>
    <script type="text/javascript">             
      var worker;     
      function callWorker(){     
        if(!!window.Worker){ //브라우저가 웹 워커를 지원하는지 검사한다   
           
          if(worker) worker.terminate();      //워커가 이미 존재하면 종료시킨다                    
          worker = new Worker("worker.js");  //새로운 워커(객체)를 생성한다      
                      
          worker.onmessage = function(event){ //워커로부터 전달되는 메시지를 받는다
            alert(event.data);
          };
                           
          worker.postMessage("워커야! 깨어나라!"); //워커에게 메시지를 전달한다       
        }
        else{
          alert("현재 브라우저는 웹 워커를 지원하지 않습니다")
        }
      }
               
      function stopWorker(){
        if(worker){
          worker.terminate();
          alert("워커 작업이 중지되었습니다");
        }
      }
    </script>
  </head>
  <body>
    <button onclick="callWorker()">웹워커 호출</button>
    <button onclick="stopWorker()">웹워커 중지</button>   
    <br>   
    <input type="text">
  </body>
</html>

- 실행 화면
HTML 파일을 웹 브라우저(데스크 탑 사파리)에서 실행하면 10초 후에 메시지가 나타난다
또한 워커를 사용했기 때문에 브라우저가 얼어 버리는 일은 없다
즉 10초라는 대기 시간 동안에도 브라우저를 움직이거나 텍스트 상자에 글을 입력할 수 있게 되는 것이다

HTML5 로 제작된 멋진 데모들을 제공하는 사이트이다
음.. 놀랍군.

이건 뭐.. 그럴싸한 HTML5 어플만들려면 자바스크립트를 자유자재로 다룰 수 있어야 겠구만!!

http://www.aplossystems.co.uk/articles/look_at_html_5_canvas/

자바스크립트의 영역이 이렇게 커질(?)줄 몰랐다. 아오~

우리 프로젝트에도 멋진 자바스크립트 개발자가 있어야 하겠지...

HTML5에 대한 개괄적인 내용들을 정리해 보았다
이 문서는 HTML5 & API 입문 이라는 책과 관련 블로그 및 온라인 자료를 바탕으로 작성되었다

따라서 순수 창작물이 아니라 정리 및 요약을 목적으로 작성되었으며 일부 개인적 의견이
덧붙여지기도 하였음을 밝혀둔다

HTML5 개요와 기술적 특징

2010.06.14

근래 HTML5에 대한 관심이 뜨겁다. 웹이 더 이상 문서 공유나 문서 표현만을 위한 것이 아니라 하나의 응용프로그램으로써의 면모를 점점 갖추어 나가고 있다. 플러그인 기술과 스크립트의 조화로 웹이 응용프로그램화 되어 왔지만 이는 표준적인 HTML 스펙을 벗어나는 기술의 복잡한 결합으로 가능한 것이었다

HTML5는 웹을 둘러싼 난무한 비 표준을 지양하고 지능적이고 실행가능 한 웹 구현을 위해 탄생한 차세대 웹 표준 기술이다. 본 문서에서는 현재 이슈가 되고 있는 HTML5의 개요와 기술적 특징에 대해 기술한다

HTML5 등장 배경

웹 문서에서 웹 응용프로그램으로의 진화

웹에서 문서를 표현하고 문서간 연결(하이퍼링크)을 주 목적으로 탄생한 HTML은 웹 환경이 보편화되고 발전함에 따라 표준적인 방식으로 구현되는 웹 응용프로그램 수준을 요구하는 시대적 흐름에 의해 탄생하게 되었다. 또한 방대하게 퍼져있는 웹 문서를 의미 있게 구조화하고 효과적으로 탐색, 해석 할 수 있는 시멘틱(semantic) 웹 실현을 위한 표준이기도 하다

HTML5 정의

HTML5는 HTML의 차기 주요 제안으로써 HTML 4.01, XHTML 1.0, DOM Level 2 HTML에 대한 차세대 표준안이다. 플래시나 실버라이트와 같은 별도의 플러그인 없이 웹에서 표준적인 방식으로 멀티미디어를 재생하고 로컬 자원을 이용하는 등의 응용프로그램 수준의 웹을 개발하기 위한 기술의 총칭이다

현재 W3C를 주축으로 한 애플, 모질라, 구글, 오페라, 마이크로소프트 등 모든 웹 브라우저 벤더가 참여하고 있는 산업 표준이기도 하다

HTML History

HTML은 1990년 초부터 지속적으로 업그레이드 되어 왔다

특히 시멘틱 웹의 실현을 목적으로 한 XHTML 추진과 HTML5로의 방향전환이 주목할 만한 업계의 트랜드를 말해 준다

 

	1990년 웹 창시자인 팀 버너스리에 의해 설계 및 개발 시작
	1993년 6월 IETF에 의해 버전 1.0 표준 채택
	1995년 11월 버전 2.0 RFC 표준화
	1997년 1월 W3C 버전 3.2 권고
	1997년 12월 W3C 버전 4.0 권고
	1999년 12월 W3C 버전 4.01 권고 (이후 W3C에서 HTML을 더 이상 업데이트 하지 않을 것을 선언)
	2000년 1월 ~ W3C 시멘틱 웹 실현을 위한 XHTML 1.0 개발추진. 이후 XHTML2 개발 2009년 7월 XHTML2 사양 제정 중지 선언
	2004년 6월 XHTML 보급 실패와 시대 흐름에 부응하기 위한 HTML 업데이트 제안 애플, 모질라, 오페라 제안 -> W3C 거절 -> WHATWG 결성 -> 웹 어플리케이션 1.0이라는 이름으로 세부 명세 작업 시작
	2007년 W3C에서 HTML W/G를 결성하고 WHATWG와 공동작업 시작 2008년 1월 W3C에 의해 HTML5 초안 공개 2009년 5월 Google I/O 개발자 콘퍼런스, ‘차세대 웹 표준’ 으로 적극 추천됨. (전 세계 개발자들의 주목을 받기 시작함) 2009년 10월 WHATWG가 최종심사청구를 선언하고 표준화 작업을 W3C로 넘김 W33C: HTML5 표준화 작업 진행 WHATWG: HTML 업데이트 작업 계속 진행 2010년 6월 현재 W3C의 표준화 프로세스 중 최종 초안 상태 2012년경 권고 후보 예정(실제 브라우저에 표준 전체 기능 적용 요청) 이후 정식 권고

브라우저 및 호환성

현재 HTML5가 초안(Working Draft) 상태이기는 하지만 많은 브라우저 업체들이 이미 HTML5 기능들을

지원하고 있다

2010년 현재 지원되는 브라우저 목록

파이어폭스 3.5 이상, 크롬 3.0 이상, 사파리 3 이상, 오페라 10.0 이상, IE 9 이상

미 지원 브라우저 처리

HTML5는 자체적으로 이 기술을 지원하지 않는 브라우저를 위해 Fall Back 장치를 두고 있다

(태그 무시, 대안 텍스트 표시)

브라우저 호환성 확인:

지원되는 브라우저 내에서도 HTML5 세부 지원 여부가 조금씩 상이하다. 다음의 URL에서 상세한
브라우저 호환성 확인이 가능하다 (참고: http://caniuse.com/)

HTML5 현황

전 세계적인 브라우저 업체들이 이미 HTML5 개발에 협력하고 있으며 자사의 브라우저에 HTML5를

지원하고 있다. 경쟁 기술인 실버라이트를 먼저 선보인 마이크로소프트에서도 HTML5 지원에 동참하고 있는 실정이다. 또한 플래시 개발사인 어도비에서도 자사의 웹 저작도구인 드림위버 신제품에 HTML5
편집 기능을 포함시켰다. 아래는 HTML5에 대한 업계의 관심과 공식적 행보의 예이다

애플: W3C HTML WG의 공동의장으로 활동하면서 HTML5 표준화에 적극 동참.

자사 제품에 플래시 배제. HTML5 적극 지원

사파리개발자센터를 통해 HTML5 데모 및 가이드 제공   

구글: 구글 기어스(Google Gears) 포기, HTML5 집중 선언, HTML5 기반 유투브 서비스 시작

마이크로소프트: IE9에 HTML5 지원 발표. IE3의 TestDrive 사이트에 HTML5 영역 제공

오페라: 오페라 개발자 센터를 통해 HTML5 데모 및 가이드 제공

사례 및 데모

퀘이크 2: http://www.youtube.com/watch?v=XhMN0wlITLk (플레이 동영상)

HTML5의 Canvas와 Audio 및 LocalStorage , WebSocket, WebGL등의 기술을 이용해
GWT(Google Web Tookit)팀에서 퀘이크 2를 HTML5로 포팅하여 에뮬레이션 한 것
 (웹 브라우저에서 초당 60프레임까지 가능)

오픈 소스: http://code.google.com/p/quake2-gwt-port/

이미지 편집기: http://mugtug.com/darkroom/
포토샵과 유사한 기능 제공. HTML5 Canvas 사용

HTML5는 2012년경 그 모습이 완성되어 나갈 것으로 예상되며 많은 기업에서 이를 기반으로 한 웹 응용프로그램을 출시하여 기술이 본격적으로 활성화 될 것으로 보인다

내가 본, HTML5를 주제로 한 첫번째 책이다
그간 온라인을 통해서만 HTML5 기술을 습득해 왔는데, 책이 나왔다길래 바로 구입했다
모바일 플랫폼 중 1차로 모바일 웹 부분을 담당하게 될 것 같고 관심도 있고 해서 보게 되었다

HTML5은 차세대 웹 표준으로 자리를 잡겠지만 현재까지는 표준안이 완성된 것은 아니다
따라서 각 브라우저에서 HTML5의 각종 태그와 API에 대한 지원이 서로 상이하다

http://www.html5test.com/ 에서는 현재 브라우저가 HTML5를 얼마나 지원하는지 검사해 준다
HTML5의 각 세부 요소별로 점수를 계산하여 300점 만점 기준으로 종합 점수를 보여준다

아래는 내 PC에 설치된 IE, 크롬, 사파리, 파이어폭스를 검사 해 본 결과이다

IE 8.0                   :  27 점
크롬 5.0                : 197점   
파이어폭스 3.6.6   : 139점
오페라 10.60         : 159점
사파리 5.0             : 207점

사파리가 가장 좋은 점수를 받았다
역시 플래시를 거부하고 HTML5 를 적극지원하겠다던 애플다운 행보인 것 같다
구글의 크롬 역시 높은 점수를 기록했으며 파이어폭스나 오페라는 그저그런 수준인 듯...
(뭐얌.. 지원할 꺼면 언능언능 지원하던지 않구선.. )

마이크로소프트의 경우 다음버전인 IE9에서는 HTML58를 전폭 지원한다고 했으니 다음에 검사한번
해 봐야 겠다

모바일 웹 사이트 개발을 위해 HTML5를 선택하기로 했지만, 이는 클라이언트 기술일 뿐 막상
서버측 기술은 어떤걸 쓰야 할지 고민이다

문제는 웹 표준이다. 모든 모바일 장비에서 원활히 돌아가야 하기에 표준을 준수하는게 중요하다

ASP.NET 을 사용하자니 각종 서버 컨트롤과 웸폼, 뷰스테이트, 포스트백 등의 매커니즘을 위해
닷넷 프레임워크 차원에서 자동 생성하는 HTML 태그들이 마음에 걸린다.
아직 상세히 테스트를 해 보진 않았지만 예상하기에 대략 호환성에 문제가 있지 않을까 싶다

그러면 ASP냐? 이건 뭐.. MS 자체에서도 기술지원을 그만 둔 과거 기술이기에 시대를 거스르고
싶진 않다. 그러면 JSP, PHP? 이건 내가 잘 모르는 기술이다. 물론 이 환경이 꼭 필요하다면 개발자를
채용해서 담담하도록 하면 되지만, 이 기술들이 필수로 필요하다는 이유가 없다

그러면 ASP.NET 을 ASP 처럼 구현한다?
즉 서버 컨트롤이나 자동 바인딩, 포스트 백 등등 ASP.NET 웹폼 기술은 전혀 사용하지 않고 요청에 대한 처리만 담당하고 프리젠테이션 부문의 디스플레이는 일일이 수동으로 하는 것이다

뭐, 대략 가능은 하겠으나 그리 땡기지는 않는다

우연히 회사 동료랑 예기하다가 MVC 패턴을 고려하게 되었다
닷넷에서도 MVC 프레임워크를 철저히(?) 제공해 주며 이전 서버컨트롤의 난무함(?)이 없다고 하니
일단은 가장 적합한 모델이지 않나 싶다

닷넷이 제공하는 MVC 프레임워크에서 프리젠테이션 컨트롤들과 데이터 연동을 어떤 식으로 하는지
확인해 봐야 겠다