원 트랙백 주소 : http://minorblog.hosting.paran.com
제가 쓰는 브라우저는 익스플로러 7.0입니다. 원래 6.0을 쓰고 있었습니다만, 귀찮아서 최근까지 업데이트도 안하고 있었던 베드 유저(Bad User)입니다. 6.0이 웹 프로그래머나 코더들에게는 매우 쥐약인 브라우저니까요. 표준 개념도 모호하고... 여튼.
그럼에도 불구하고, 나쁜 사용자 치고 전 가끔 일탈을 즐기기도 합니다. 그럼 익스 말고 파폭이라도 쓰냐, 아니 그건 아니고요. 제가 연구 주제로 나름 팠던 것들 중 하나가 브라우저 라이브러리인 웹킷 성능 향상과 관련된 것이었기 때문에 심심하면 직접 브라우저를 만드는 수준에 이르렀기에 그걸 직접 쓰기도 한다는 겁니다. (...) 저 만의 사파리를 쓰기도 하고 뭐 그렇습니다. 물론 속도는 더 느려터진 경우가 많지만요.
가끔 웹에서 크롬이 빠르네, 익스플로러가 빠르네, 사파리가 빠르네, 오페라가 빠르네하면서 주기적으로 유저들끼리 떡밥 논쟁을 벌이던데요. 사실 이게 다 트레이드 오프(Trade off)가 있는 거라서 신속함을 기준으로 어떤 브라우저가 더 좋다고 선뜻 말씀드리기가 껄끄럽습니다. 즉, 빠르다고 다 좋은 브라우저는 아니라는 거지요. 그 브라우저가 빠르다는 것은 유감스럽게도 반드시 어딘가가 빵꾸가 나게 설계되어 있다는 것을 뜻합니다.
물론 가끔은 웹킷의 자바스크립트코어처럼, 진보된 형태의 알고리듬을 통해 성능을 향상시키는 케이스가 더러 있기는 하지만(마소 익스에 최근에 붙은 차크라가 그것과 유사한 기능을 합니다. 그래봐야 goto구문이 남발된 매우 더러운 구조를 띄고 있긴 합니다만...)대개는 네트워크 환경, 혹은 개발자 및 코더를 얼마만큼 배려하는 정도에 주로 의존적입니다. 다시 말하자면, 라이브러리 개발자들의 코딩 실력과는 별개의 케이스인 경우가 많다는 거지요.
네트워크 환경이 좋지 않아서 매우 불규칙한 자료 전송이 이루어지고 있다면, 웹 라이브러리 측에서는 이들의 처리를 실시간화시키기 위해, 혹은 자료의 전송을 지속적으로 유지시키기 위해 많은 노력을 합니다. 그런데 이들의 케이스들을 다 고려해주다보면 필연적으로 라이브러리 내의 함수가 수시로 재귀 형태를 띄게 되거나 쓸데없는 반복 과정을 거치게 됩니다. 어디까지나 실시간으로 굴러가는 엔진이기 때문에 루틴이 도는 순간순간에도 플래그를 올렸다 내렸다하면서 쉴새없이 처리를 해야하기 때문이죠. 성능을 하락시키는 데에 일조하는 주범 중 하나입니다. 네트워크 엔지니어 측에서는 이를 방지하기 위해 패킷 전송의 표준을 재정립하자는 의견도 있었습니다만... 이게 어디 쉬운 일인가요.
개발자나 코더들의 더러운 웹 코딩 습관(?)도 브라우저를 느리게 만드는 데에 일조합니다. 주로 라이브러리 내의 파서(Parser)부분에서 로드를 야기하는 문제입니다. Overflow나 Anonymous Block 등등의 불필요한 케이스들을 다량으로 양산하게 만드는 불안정한 코딩은 네트워크 환경이 양호한 유선에서는 크게 상관이 없지만 무선 모바일 환경에서는 치명적으로 작용하게 되죠. 이 때 브라우저를 개발하는 측에서는 다음과 같이 생각하게 됩니다. 저 수많은 코더들을 구제 불능으로 만들까, 아니면 넓은 마음으로 포용할까?
전자를 택했다면, 브라우저 속도는 무지 빨라질 수 있습니다. 다만, 지금까지 개발자나 코더의 탈을 쓴 많은 사람들이 밀려날 수도 있습니다. 문법의 난이도를 높일 수록, 다시 말해 웹킷 내의 컴파일러 기능을 단순화시킬수록 속도 향상은 필연적이지만, 웹 코딩은 그만큼 어려운 작업이 될 수도 있다는 뜻입니다. 후자를 택했다면, 브라우저 속도는 크게 느려질 것입니다. 하지만, 개발에 참여하는 수많은 사람들은 이 느려터진 브라우저 덕분에 자신의 위치를 지켜나갈 수 있을 것입니다.
개인적으로 보기에는, 일반적으로 스놉 대중들에게 제일 구리다고 판명받은 브라우저 중 하나인 익스야말로 역설적으로는 참으로 고민을 많이 한 브라우저가 아닌가 생각됩니다. 앞서 말씀드렸듯 어디까지나 트레이드 오프니까요. 물론 알고리즘의 문제가 전혀 없이 순수히 트레이드 오프의 문제냐고 물으신다면 반드시 그것은 아닙니다만, 생각 외로 알고리즘과의 상관성은 크지 않은 것 같습니다. 쓰다보니 말이 길어졌네요. 에그에게 낚여줬다고 정신승리하는 것을 끝으로 마무리 하겠습니다.
바톤은 아무나 받아가시면 됩니다. 'ㅅ'~
그럼에도 불구하고, 나쁜 사용자 치고 전 가끔 일탈을 즐기기도 합니다. 그럼 익스 말고 파폭이라도 쓰냐, 아니 그건 아니고요. 제가 연구 주제로 나름 팠던 것들 중 하나가 브라우저 라이브러리인 웹킷 성능 향상과 관련된 것이었기 때문에 심심하면 직접 브라우저를 만드는 수준에 이르렀기에 그걸 직접 쓰기도 한다는 겁니다. (...) 저 만의 사파리를 쓰기도 하고 뭐 그렇습니다. 물론 속도는 더 느려터진 경우가 많지만요.
가끔 웹에서 크롬이 빠르네, 익스플로러가 빠르네, 사파리가 빠르네, 오페라가 빠르네하면서 주기적으로 유저들끼리 떡밥 논쟁을 벌이던데요. 사실 이게 다 트레이드 오프(Trade off)가 있는 거라서 신속함을 기준으로 어떤 브라우저가 더 좋다고 선뜻 말씀드리기가 껄끄럽습니다. 즉, 빠르다고 다 좋은 브라우저는 아니라는 거지요. 그 브라우저가 빠르다는 것은 유감스럽게도 반드시 어딘가가 빵꾸가 나게 설계되어 있다는 것을 뜻합니다.
물론 가끔은 웹킷의 자바스크립트코어처럼, 진보된 형태의 알고리듬을 통해 성능을 향상시키는 케이스가 더러 있기는 하지만(마소 익스에 최근에 붙은 차크라가 그것과 유사한 기능을 합니다. 그래봐야 goto구문이 남발된 매우 더러운 구조를 띄고 있긴 합니다만...)대개는 네트워크 환경, 혹은 개발자 및 코더를 얼마만큼 배려하는 정도에 주로 의존적입니다. 다시 말하자면, 라이브러리 개발자들의 코딩 실력과는 별개의 케이스인 경우가 많다는 거지요.
네트워크 환경이 좋지 않아서 매우 불규칙한 자료 전송이 이루어지고 있다면, 웹 라이브러리 측에서는 이들의 처리를 실시간화시키기 위해, 혹은 자료의 전송을 지속적으로 유지시키기 위해 많은 노력을 합니다. 그런데 이들의 케이스들을 다 고려해주다보면 필연적으로 라이브러리 내의 함수가 수시로 재귀 형태를 띄게 되거나 쓸데없는 반복 과정을 거치게 됩니다. 어디까지나 실시간으로 굴러가는 엔진이기 때문에 루틴이 도는 순간순간에도 플래그를 올렸다 내렸다하면서 쉴새없이 처리를 해야하기 때문이죠. 성능을 하락시키는 데에 일조하는 주범 중 하나입니다. 네트워크 엔지니어 측에서는 이를 방지하기 위해 패킷 전송의 표준을 재정립하자는 의견도 있었습니다만... 이게 어디 쉬운 일인가요.
개발자나 코더들의 더러운 웹 코딩 습관(?)도 브라우저를 느리게 만드는 데에 일조합니다. 주로 라이브러리 내의 파서(Parser)부분에서 로드를 야기하는 문제입니다. Overflow나 Anonymous Block 등등의 불필요한 케이스들을 다량으로 양산하게 만드는 불안정한 코딩은 네트워크 환경이 양호한 유선에서는 크게 상관이 없지만 무선 모바일 환경에서는 치명적으로 작용하게 되죠. 이 때 브라우저를 개발하는 측에서는 다음과 같이 생각하게 됩니다. 저 수많은 코더들을 구제 불능으로 만들까, 아니면 넓은 마음으로 포용할까?
전자를 택했다면, 브라우저 속도는 무지 빨라질 수 있습니다. 다만, 지금까지 개발자나 코더의 탈을 쓴 많은 사람들이 밀려날 수도 있습니다. 문법의 난이도를 높일 수록, 다시 말해 웹킷 내의 컴파일러 기능을 단순화시킬수록 속도 향상은 필연적이지만, 웹 코딩은 그만큼 어려운 작업이 될 수도 있다는 뜻입니다. 후자를 택했다면, 브라우저 속도는 크게 느려질 것입니다. 하지만, 개발에 참여하는 수많은 사람들은 이 느려터진 브라우저 덕분에 자신의 위치를 지켜나갈 수 있을 것입니다.
개인적으로 보기에는, 일반적으로 스놉 대중들에게 제일 구리다고 판명받은 브라우저 중 하나인 익스야말로 역설적으로는 참으로 고민을 많이 한 브라우저가 아닌가 생각됩니다. 앞서 말씀드렸듯 어디까지나 트레이드 오프니까요. 물론 알고리즘의 문제가 전혀 없이 순수히 트레이드 오프의 문제냐고 물으신다면 반드시 그것은 아닙니다만, 생각 외로 알고리즘과의 상관성은 크지 않은 것 같습니다. 쓰다보니 말이 길어졌네요. 에그에게 낚여줬다고 정신승리하는 것을 끝으로 마무리 하겠습니다.
바톤은 아무나 받아가시면 됩니다. 'ㅅ'~
덧글
익스6의 종말은 진정 XP SP3 지원 끝나는 2014년은 되어야 하는겐가 OTL