2008년 04월 21일
웹의 미래
현재 웹이 더러운 이유는 문서와 인터페이스를 같이 수용하려 하기 때문이다.
정보와 실행을 같은 규격 안에 담으려 하기 때문에 문제가 발생한다.
웹의 원 목적은 HTML을 통한 문서 저장이었다. 문서 단위로 쪼개지는 특정 형식의 정보를 개별적으로 쌓고, 이들을 링크하는 것이 웹의 원조이다.
하지만 웹 초창기 무지한 대중에게 HTML이 알려지면서 HTML의 비주얼한 부분만 알려지고, 이러한 내부 구조는 전혀 알려지지 않아, 구조를 무시한 비주얼 페이지들이 대거 양산되었고, 아직까지 해법이 없다.
그러면서 W3C는 HTML의 본분을 잊고 유저들의 요구에 따른다는 이유로 HTML규격에 인터페이스 기능들을 추가하기 시작했다. 이러한 HTML 인터페이스화의 가장 큰 원인은 Netscape 브라우저이다. JavaScript를 탑재해 당시로서는 요구되던 기능을 제공했지만, 결국 HTML의 인터페이스화를 불러오게 된다. 정적 문서를 위해 디자인된 HTML을 실행 기반의 인터페이스로 전환하려 하니 잘 될리가 없고, 이 문제 또한, 아직까지 해법이 없다.
그런데 왜 좋은 인터페이스 API 들을 두고 사용자들이 굳이 전혀 적합하지 않은 HTML을 선택한 것일까. 그것은 HTML이 매우 쉽고 간단한 유일한 크로스플랫폼 솔루션이었기 때문이다. 매우 쉬웠기 때문에 많이 사용되고, 덕분에 더 큰 호환성을 보장받았다. 기능이 부족한것은 문제되지 않았다. 기능을 만들면 되고 그것을 위해 W3C가 있었으니까.
이제 과거는 그렇다치고, 현재의 문제는 무엇인가.
현재 HTML은 정보와 인터페이스가 한데 섞여 있다는 것이다.
사실 이것은 대부분의 사용자들에게는 아무 문제가 되지 않는다. 엔드 유저는 항상 정보와 인터페이스를 같이 경험하기 때문이다. 하지만 엔드 유저를 벗어나, 제작자들에게는 문제가 된다. 이 정보를 만들고, 가공하고 재활용하려는 사람들 말이다. HTML에 정보기능만 있었다면 문제가 없었겠지만, 인터페이스 기능이 존재하므로 무지한 대중들은 이것을 최대한 응용해 작성한다. 하지만 이것은 정보와 인터페이스를 섞어 분리할 수 없게 만든다. 그래서 HTML페이지는 정보로서도 인터페이스로서도 재활용이 불가능하고, 일회용의 화면 역할만 할 수 있게 된다. 최악의 경우에는 HTML에서 정보를 분리해내는 것은 거의 불가능에 가깝다.
하지만 HTML은 반드시 정보가 분리되어야 한다. 왜냐하면 인터넷이 너무 크기 때문이다. 전지구적인 글로벌 커뮤니케이션인 인터넷은 전세계인들의 정보를 보유하기 때문에 자료가 너무 많고, 제대로 사용하기 위해서는 검색이 필수적이다. 그런데 검색은 대표적인 정보 재활용 기능이다. HTML에서 정보를 분리해내지 못하면 검색은 불가능하다.
이것을 분리하기 위한 노력이 있었다. CSS가 그것이고 XML이 그것이다. 하지만 둘 다 처참히 실패했다. 물론 CSS는 지금도 많이 쓰이고 있지만, 단지 인터페이스 구현을 단순화하기 위한 툴로 쓰일 뿐이다. CSS는 로직을 담을 수 없다. 그래서 인터페이스로 쓰일 수가 없었다. 인터페이스는 비주얼만으로 이뤄지는 게 아니니까. XML은 규격 자체로는 성공적이다. 현재도 가장 호환성 높은 정보 전달 규격으로 인정받고 있다. 하지만 HTML을 정보와 인터페이스로 나누기 위한 시도로서는 실패했다. 이를 담을만한 인터페이스가 존재하지 않았기 때문이다. 당시 HTML은 XML을 처리할 수 있는 능력이 없었고, CSS는 인터페이스 구현 능력이 없었으니까.
이제 여기에 더욱 큰 문제들이 가세하고 있다. 상황이 이정도로 나쁘지만 그래도 더 이상의 해법이 나오지 않는 것은 HTML이 정적이기 때문이다. 그래서 정보와 인터페이스가 섞여 있더라도 태그를 분리해내면 어느정도 쓸만한 텍스트들을 추려낼 수 있다. 하지만 이제 상황이 달라졌다. AJAX와 Flash 때문이다. 이들은 대표적인 동적 인터페이스 구현 방법이다. 둘의 중요한 차이는 HTML기반이냐 아니냐이지만, 문제는 둘다 적극적인 상태 변화를 사용한다는 점이다. 즉, 하나의 페이지의 내용이 바뀔 수 있는 것이다. 인터페이스가 발전되면 결국 이렇게 가는 것이 맞다. 하지만 이제 하나의 링크가 더 이상 하나의 정보를 가리킬 수 없게 된다. 링크는 오로지 하나의 인터페이스만 가리키게 되고, 정보는 사용자 입력에 의해 계속 바뀌므로 자동검색 엔진은 더 이상 정보를 추려낼 수 없게 된다. 그나마 이것은 AJAX의 이야기이고 플래시는 아예 브라우저 접근이 차단되어 있다. 정보가 너무 많기 때문에 검색이 불가능한 정보는 인지되지 않고, 인지되지 않으면 존재하지 않는 것이나 마찬가지이다.
이렇게 되면 HTML의 원래 목적에서 남는 것은 포인팅 기능을 수행하는 링크밖에 없다.
웹이 연결 가능한 분리된 정보의 집합이라는 초기 컨셉을 벗어나고 있다. 왜냐면 대중이 인터페이스를 원하기 때문이다. 하지만 인터페이스로만 가다가는 그 인터페이스가 담을 정보가 사라지고 만다. 하지만 한 규격 안에 인터페이스와 정보를 섞을 수 있게 하면 무지한 대중과 최대 호환성을 확보하려는 브라우저 때문에 둘을 추려낼 수 없게 된다. 그래서 우리는 분리된 정보와 인터페이스 규격이 필요하다. 그리고 이 정보들은 연결될 수 있어야 한다.
HTML페이지는 결국 인터페이스가 될 것이다. 이것은 정보를 담기에는 너무 더럽다. 인터페이스 기능은 미약하다. 하지만 계속 발전하고 있으며, 인터페이스 구현은 발전으로 가능할 것이다. 하지만 정보를 담기 위해서 더러운 것을 닦아내야 하는데, 더러운 것이 한번 퍼지면 닦아낼 수가 없다.
그리고 정보는 분리될 것이다. 정보만 담긴 문서들이 제공되고 그들이 서로 연결되게 될 것이다. XML이 있기에 이것이 가능하다. 또한, 이것의 가장 유력한 후보는 RSS이다. 이것은 XML위에 구축된 얇은 데이터 폼인데, 순수 데이터만 담은 정보를 제공할 수 있다.
데이터가 인터페이스에서 분리되면, 진정한 브라우저 독립을 이룰 수 있게 된다. 이는 진정한 플랫폼 독립도 가져온다.
그 안에는 HTML에서의 독립도 포함되어 있다.*
하지만 여기에 걸림돌이 되는 것이 하나 있다. 하나의 인터페이스로 모든 종류의 정보를 적합하게 표현할 수 있는 폼을 만들 수 없다는 점이다. 인터페이스를 통해 아이덴티티를 확보하고 기능을 제공하는 웹 서비스 업자의 경우 특히 그러하다. 이들의 경우, 인터페이스 자체가 비즈니스의 핵심인 경우도 있다. 인터페이스를 통해 기능을 제공할 수 있게 하려면 표준적인 인터페이스 프레임이 필요하다.
지금 이 자리를 두고 싸우고 있는 것이 AJAX, Flash, Silverlight 등의 RIA 프레임이다. 이들은 HTML 위에 씌워지는 레이어라는 문제가 있다. 여기에 어도비가 야심차게 내놓은 것이 AIR로 이것은 미래 웹의 한 단면을 보여준다.* 하지만 아직 다른 사이트로 연결할 수 있는 방법이 없다.
웹은 링크로 시작한다. 미래 웹은 크게 두 가지 링크를 가질 것이다. 서비스에 대한 링크와 데이터에 대한 링크이다. 사이트는 이러한 링크를 여러개 가질 수 있을 것이다. 서비스 링크는 인터페이스를 제공한다. 데이터 링크는 RSS같이 데이터만 제공한다. 서비스에서 제공된 인터페이스는 어느 사이트의 데이터라도 모두 접근할 수 있다. 실제로 데이터의 스키마에 맞는 개별적인 전용 브라우저가 되는 것이다. RSS브라우저를 각 사이트에서 제공한다고 생각하면 된다. 원하면 다른 인터페이스로 쉽게 바꿀 수 있다. 데이터 스키마를 자기 사이트 전용으로 새로 정의할 수도 있을 것이다. 대부분의 특징적인 서비스는 전용의 데이터 표현을 필요로 한다.
예를 들어 웹하드 같은 서비스를 생각해보자. 보통 웹하드 업체의 인터페이스는 그다지 좋지 않다. 사이트는 파일 목록과 파일 데이터를 가진다. 파일 목록 데이터는 공개 스키마이다, 어느 인터페이스든지 접근할 수 있다.
자기 사이트에서만 데이터에 접근할 수 있도록 제한할 수도 있지만, 상호운용의 장점을 제공하지 못하고도 살아남을 수 있다면 다행이다.
------------------------
일반적으로 사이트 루트는 서비스 링크이고, 하위 기능마다 데이터 링크를 포함할 것이다. 데이터는 XML로 표현되고, 해당 데이터의 의미를 제공하는 스키마가 정의된다. 스키마는 공개이거나 비공개일 수도 있다. 공개된 스키마를 가진 데이터는 어떤 인터페이스로든지 브라우즈할 수 있다. 독점 방식의 데이터는 전용 인터페이스를 사용해야 한다. 이러한 인터페이스를 제공하는 것이 중요한 비즈니스가 될 수 있다. 인터넷의 특성상 독점 인터페이스가 일반유저들에게 서비스되기는 힘들 것이다.
두가지 사이트로 나뉜다. 서비스를 제공하는 사이트와 데이터를 제공하는 사이트이다. 사이트 하나에서 이 두 부분을 모두 제공할 수도 있을 것이다. 브라우저는 링크를 탐색할 때
사이트, 데이터, 인터페이스로 나뉠 것이다. 하나의 사이트는 하나의 서비스를 제공한다.
사이트는 데이터를 보유하고 이는 표준 형식인 XML로 표현된다. 여기에 RSS같이 구체화된 시맨틱 요소가 존재할 것이다. 이는 RSS같이 표준적이거나 사이트 전용의 것일 수 있다.
그리고 표준적인 인터페이스 표현 언어가 존재해 해당 사이트에 맞는 인터페이스를 출력하게 한다. 사이트 전체는 이 인터페이스로 표시된다. 핵심은 링크가 사이트상의 데이터를 가리킨다는 것이다. 데이터가 사이트상의 데이터로 포인트될 수 있으며, 한 종류의 데이터는 다른 데이터로의 링크를 포함하며
*현재 HTML이 인터페이스 프레임으로 적합하지 않은 이유.
표현력이 좋지 않다. 크로스플랫폼을 표방하고 있지만, 사실 하나의 플랫폼 안에서도 브라우저마다 출력이 모두 다르다. CSS로 정밀한 레이아웃 기능을 보유하지만, 표준이 애매하고 구현이 너무 복잡한 나머지 브라우저 표현이 모두 달라서 결국 사용할 수 없는 기능이 되었다. 예를 들면 비디오 같은 것을 들 수 있다. 또한, 화면이 페이지 단위로 나뉘어 지속적인 인터액션이 불가능하다. 로직을 구성하기도 힘들다. 제대로 된 툴도 없다. 많은 HTML 페이지 저작도구가 나와 있지만, 다 컨셉에 맞지 않거나 비표준 코드를 양산한다. 단지 인터페이스적인 측면에서 보자면 이것이 그리 나쁜것만은 아니지만, 애매한 표준으로 인한 브라우저 비호환성은 해결하기 힘든 문제이다. 무엇보다도 이 코드 베이스로 더러운 것들이 잔뜩 퍼져 있기 때문에 호환성이란 미명하에 깔끔하고 강력한 인터페이스로 프레임으로 거듭나기 힘들다는 문제가 있다.
*웹의 데이터/인터페이스 분리에 대해 잘 모른다면 이것이 왜 미래 웹의 단면인지 알기 힘들 것이다.
정보와 실행을 같은 규격 안에 담으려 하기 때문에 문제가 발생한다.
웹의 원 목적은 HTML을 통한 문서 저장이었다. 문서 단위로 쪼개지는 특정 형식의 정보를 개별적으로 쌓고, 이들을 링크하는 것이 웹의 원조이다.
하지만 웹 초창기 무지한 대중에게 HTML이 알려지면서 HTML의 비주얼한 부분만 알려지고, 이러한 내부 구조는 전혀 알려지지 않아, 구조를 무시한 비주얼 페이지들이 대거 양산되었고, 아직까지 해법이 없다.
그러면서 W3C는 HTML의 본분을 잊고 유저들의 요구에 따른다는 이유로 HTML규격에 인터페이스 기능들을 추가하기 시작했다. 이러한 HTML 인터페이스화의 가장 큰 원인은 Netscape 브라우저이다. JavaScript를 탑재해 당시로서는 요구되던 기능을 제공했지만, 결국 HTML의 인터페이스화를 불러오게 된다. 정적 문서를 위해 디자인된 HTML을 실행 기반의 인터페이스로 전환하려 하니 잘 될리가 없고, 이 문제 또한, 아직까지 해법이 없다.
그런데 왜 좋은 인터페이스 API 들을 두고 사용자들이 굳이 전혀 적합하지 않은 HTML을 선택한 것일까. 그것은 HTML이 매우 쉽고 간단한 유일한 크로스플랫폼 솔루션이었기 때문이다. 매우 쉬웠기 때문에 많이 사용되고, 덕분에 더 큰 호환성을 보장받았다. 기능이 부족한것은 문제되지 않았다. 기능을 만들면 되고 그것을 위해 W3C가 있었으니까.
이제 과거는 그렇다치고, 현재의 문제는 무엇인가.
현재 HTML은 정보와 인터페이스가 한데 섞여 있다는 것이다.
사실 이것은 대부분의 사용자들에게는 아무 문제가 되지 않는다. 엔드 유저는 항상 정보와 인터페이스를 같이 경험하기 때문이다. 하지만 엔드 유저를 벗어나, 제작자들에게는 문제가 된다. 이 정보를 만들고, 가공하고 재활용하려는 사람들 말이다. HTML에 정보기능만 있었다면 문제가 없었겠지만, 인터페이스 기능이 존재하므로 무지한 대중들은 이것을 최대한 응용해 작성한다. 하지만 이것은 정보와 인터페이스를 섞어 분리할 수 없게 만든다. 그래서 HTML페이지는 정보로서도 인터페이스로서도 재활용이 불가능하고, 일회용의 화면 역할만 할 수 있게 된다. 최악의 경우에는 HTML에서 정보를 분리해내는 것은 거의 불가능에 가깝다.
하지만 HTML은 반드시 정보가 분리되어야 한다. 왜냐하면 인터넷이 너무 크기 때문이다. 전지구적인 글로벌 커뮤니케이션인 인터넷은 전세계인들의 정보를 보유하기 때문에 자료가 너무 많고, 제대로 사용하기 위해서는 검색이 필수적이다. 그런데 검색은 대표적인 정보 재활용 기능이다. HTML에서 정보를 분리해내지 못하면 검색은 불가능하다.
이것을 분리하기 위한 노력이 있었다. CSS가 그것이고 XML이 그것이다. 하지만 둘 다 처참히 실패했다. 물론 CSS는 지금도 많이 쓰이고 있지만, 단지 인터페이스 구현을 단순화하기 위한 툴로 쓰일 뿐이다. CSS는 로직을 담을 수 없다. 그래서 인터페이스로 쓰일 수가 없었다. 인터페이스는 비주얼만으로 이뤄지는 게 아니니까. XML은 규격 자체로는 성공적이다. 현재도 가장 호환성 높은 정보 전달 규격으로 인정받고 있다. 하지만 HTML을 정보와 인터페이스로 나누기 위한 시도로서는 실패했다. 이를 담을만한 인터페이스가 존재하지 않았기 때문이다. 당시 HTML은 XML을 처리할 수 있는 능력이 없었고, CSS는 인터페이스 구현 능력이 없었으니까.
이제 여기에 더욱 큰 문제들이 가세하고 있다. 상황이 이정도로 나쁘지만 그래도 더 이상의 해법이 나오지 않는 것은 HTML이 정적이기 때문이다. 그래서 정보와 인터페이스가 섞여 있더라도 태그를 분리해내면 어느정도 쓸만한 텍스트들을 추려낼 수 있다. 하지만 이제 상황이 달라졌다. AJAX와 Flash 때문이다. 이들은 대표적인 동적 인터페이스 구현 방법이다. 둘의 중요한 차이는 HTML기반이냐 아니냐이지만, 문제는 둘다 적극적인 상태 변화를 사용한다는 점이다. 즉, 하나의 페이지의 내용이 바뀔 수 있는 것이다. 인터페이스가 발전되면 결국 이렇게 가는 것이 맞다. 하지만 이제 하나의 링크가 더 이상 하나의 정보를 가리킬 수 없게 된다. 링크는 오로지 하나의 인터페이스만 가리키게 되고, 정보는 사용자 입력에 의해 계속 바뀌므로 자동검색 엔진은 더 이상 정보를 추려낼 수 없게 된다. 그나마 이것은 AJAX의 이야기이고 플래시는 아예 브라우저 접근이 차단되어 있다. 정보가 너무 많기 때문에 검색이 불가능한 정보는 인지되지 않고, 인지되지 않으면 존재하지 않는 것이나 마찬가지이다.
이렇게 되면 HTML의 원래 목적에서 남는 것은 포인팅 기능을 수행하는 링크밖에 없다.
웹이 연결 가능한 분리된 정보의 집합이라는 초기 컨셉을 벗어나고 있다. 왜냐면 대중이 인터페이스를 원하기 때문이다. 하지만 인터페이스로만 가다가는 그 인터페이스가 담을 정보가 사라지고 만다. 하지만 한 규격 안에 인터페이스와 정보를 섞을 수 있게 하면 무지한 대중과 최대 호환성을 확보하려는 브라우저 때문에 둘을 추려낼 수 없게 된다. 그래서 우리는 분리된 정보와 인터페이스 규격이 필요하다. 그리고 이 정보들은 연결될 수 있어야 한다.
HTML페이지는 결국 인터페이스가 될 것이다. 이것은 정보를 담기에는 너무 더럽다. 인터페이스 기능은 미약하다. 하지만 계속 발전하고 있으며, 인터페이스 구현은 발전으로 가능할 것이다. 하지만 정보를 담기 위해서 더러운 것을 닦아내야 하는데, 더러운 것이 한번 퍼지면 닦아낼 수가 없다.
그리고 정보는 분리될 것이다. 정보만 담긴 문서들이 제공되고 그들이 서로 연결되게 될 것이다. XML이 있기에 이것이 가능하다. 또한, 이것의 가장 유력한 후보는 RSS이다. 이것은 XML위에 구축된 얇은 데이터 폼인데, 순수 데이터만 담은 정보를 제공할 수 있다.
데이터가 인터페이스에서 분리되면, 진정한 브라우저 독립을 이룰 수 있게 된다. 이는 진정한 플랫폼 독립도 가져온다.
그 안에는 HTML에서의 독립도 포함되어 있다.*
하지만 여기에 걸림돌이 되는 것이 하나 있다. 하나의 인터페이스로 모든 종류의 정보를 적합하게 표현할 수 있는 폼을 만들 수 없다는 점이다. 인터페이스를 통해 아이덴티티를 확보하고 기능을 제공하는 웹 서비스 업자의 경우 특히 그러하다. 이들의 경우, 인터페이스 자체가 비즈니스의 핵심인 경우도 있다. 인터페이스를 통해 기능을 제공할 수 있게 하려면 표준적인 인터페이스 프레임이 필요하다.
지금 이 자리를 두고 싸우고 있는 것이 AJAX, Flash, Silverlight 등의 RIA 프레임이다. 이들은 HTML 위에 씌워지는 레이어라는 문제가 있다. 여기에 어도비가 야심차게 내놓은 것이 AIR로 이것은 미래 웹의 한 단면을 보여준다.* 하지만 아직 다른 사이트로 연결할 수 있는 방법이 없다.
웹은 링크로 시작한다. 미래 웹은 크게 두 가지 링크를 가질 것이다. 서비스에 대한 링크와 데이터에 대한 링크이다. 사이트는 이러한 링크를 여러개 가질 수 있을 것이다. 서비스 링크는 인터페이스를 제공한다. 데이터 링크는 RSS같이 데이터만 제공한다. 서비스에서 제공된 인터페이스는 어느 사이트의 데이터라도 모두 접근할 수 있다. 실제로 데이터의 스키마에 맞는 개별적인 전용 브라우저가 되는 것이다. RSS브라우저를 각 사이트에서 제공한다고 생각하면 된다. 원하면 다른 인터페이스로 쉽게 바꿀 수 있다. 데이터 스키마를 자기 사이트 전용으로 새로 정의할 수도 있을 것이다. 대부분의 특징적인 서비스는 전용의 데이터 표현을 필요로 한다.
예를 들어 웹하드 같은 서비스를 생각해보자. 보통 웹하드 업체의 인터페이스는 그다지 좋지 않다. 사이트는 파일 목록과 파일 데이터를 가진다. 파일 목록 데이터는 공개 스키마이다, 어느 인터페이스든지 접근할 수 있다.
자기 사이트에서만 데이터에 접근할 수 있도록 제한할 수도 있지만, 상호운용의 장점을 제공하지 못하고도 살아남을 수 있다면 다행이다.
------------------------
일반적으로 사이트 루트는 서비스 링크이고, 하위 기능마다 데이터 링크를 포함할 것이다. 데이터는 XML로 표현되고, 해당 데이터의 의미를 제공하는 스키마가 정의된다. 스키마는 공개이거나 비공개일 수도 있다. 공개된 스키마를 가진 데이터는 어떤 인터페이스로든지 브라우즈할 수 있다. 독점 방식의 데이터는 전용 인터페이스를 사용해야 한다. 이러한 인터페이스를 제공하는 것이 중요한 비즈니스가 될 수 있다. 인터넷의 특성상 독점 인터페이스가 일반유저들에게 서비스되기는 힘들 것이다.
두가지 사이트로 나뉜다. 서비스를 제공하는 사이트와 데이터를 제공하는 사이트이다. 사이트 하나에서 이 두 부분을 모두 제공할 수도 있을 것이다. 브라우저는 링크를 탐색할 때
사이트, 데이터, 인터페이스로 나뉠 것이다. 하나의 사이트는 하나의 서비스를 제공한다.
사이트는 데이터를 보유하고 이는 표준 형식인 XML로 표현된다. 여기에 RSS같이 구체화된 시맨틱 요소가 존재할 것이다. 이는 RSS같이 표준적이거나 사이트 전용의 것일 수 있다.
그리고 표준적인 인터페이스 표현 언어가 존재해 해당 사이트에 맞는 인터페이스를 출력하게 한다. 사이트 전체는 이 인터페이스로 표시된다. 핵심은 링크가 사이트상의 데이터를 가리킨다는 것이다. 데이터가 사이트상의 데이터로 포인트될 수 있으며, 한 종류의 데이터는 다른 데이터로의 링크를 포함하며
*현재 HTML이 인터페이스 프레임으로 적합하지 않은 이유.
표현력이 좋지 않다. 크로스플랫폼을 표방하고 있지만, 사실 하나의 플랫폼 안에서도 브라우저마다 출력이 모두 다르다. CSS로 정밀한 레이아웃 기능을 보유하지만, 표준이 애매하고 구현이 너무 복잡한 나머지 브라우저 표현이 모두 달라서 결국 사용할 수 없는 기능이 되었다. 예를 들면 비디오 같은 것을 들 수 있다. 또한, 화면이 페이지 단위로 나뉘어 지속적인 인터액션이 불가능하다. 로직을 구성하기도 힘들다. 제대로 된 툴도 없다. 많은 HTML 페이지 저작도구가 나와 있지만, 다 컨셉에 맞지 않거나 비표준 코드를 양산한다. 단지 인터페이스적인 측면에서 보자면 이것이 그리 나쁜것만은 아니지만, 애매한 표준으로 인한 브라우저 비호환성은 해결하기 힘든 문제이다. 무엇보다도 이 코드 베이스로 더러운 것들이 잔뜩 퍼져 있기 때문에 호환성이란 미명하에 깔끔하고 강력한 인터페이스로 프레임으로 거듭나기 힘들다는 문제가 있다.
*웹의 데이터/인터페이스 분리에 대해 잘 모른다면 이것이 왜 미래 웹의 단면인지 알기 힘들 것이다.
이 글과 관련있는 글을 자동검색한 결과입니다 [?]
- RIA(Rich Internet Application), 그들이 온다!! by 티티
- 유저빌리티 (Usability) 체크 포인트 11가지 by 티티
- 플렉스(Adobe Flex) 계륵론 by 마음속폭풍
- FISH - P2P 방식의 RSS 리더 클라이언트 어플리케이션 by 티티
- 웹페이지 리버스 엔지니어링.. by 미친병아리
# by | 2008/04/21 17:41 | 웹스타일 | 트랙백 | 덧글(0)




☞ 내 이글루에 이 글과 관련된 글 쓰기 (트랙백 보내기) [도움말]