1 Results for 'OOP'

  1. 2007.11.30 자바스크립트와 실버라이트.

아직 끝나지 않았지만, 몇 주간 정신이 없었네요. 요즘은 실버라이트 1.0을 하면서 자바스크립트와 씨름하고 있어요. :) 아주 오래전부터 JavaScript OOP에 대한 이야기가 나왔었지만 AJAX가 뜨면서 갑작스레 이슈가 된 것 같은 기분이 들어요. 저도 AJAX관련 세미나에서 처음 접했었고, 실버라이트 1.0을 하면서 다시 공부하게 되었네요. 몇 주간 작업하면서 느끼는 자바스크립트와 실버라이트에 대해 얘기해 볼께요.

JavaScript
몇 주간 다뤄본 소감으로는 자바스크립 자체는 생각보다 훨씬 더 깊이를 가진 언어지만 C#과 같은 언어만큼 쾌적한 코딩 환경이 갖춰지지 않아서 꽤 괴롭더군요.
뭐랄까 C++이나 C#으로 OOP를 배웠던 저로선 자바스크립트가 '에뮬레이트'하는 OOP는 썩 매력있지 않아요.

제가 자바스크립트 OOP를 '에뮬레이트'라고 한 것은 자바스크립트가 OOP의 기본적인 기능feature들을 명시적으로 지원하지는 않기 때문이에요.
function도 object로 취급하고 유연한 확장성을 가진 prototype 등의 언어적 특성을 제공하기 때문에 클래스를 만들고 멤버를 은폐하거나 노출하고 클래스를 상속하는 등의 기능을 구현할 수는 있지만 너무나 높은 자유도 탓에 타입은 불안정하고 이것은 작은 코드 조각들을 재활용하여 곳곳에서 분산하여 사용하게 되는 OOP 특성상 사람이 실수할 여지를 더 크게 만드는 것 같아요.

물론, 타입 안정성과 관련된 문제는 분명히 코딩/설계 미스 때문에 문제가 생기는 것이지 제대로만 해줄 경우엔 매우 훌륭하게 동작하기 때문에 언어 자체의 문제는 아닐거에요. 하지만, 설계를 제외한 코딩 단계에서 가장 오래 걸리는 건 디버깅이 아닐까요? 사소한 오타나 클래스의 멤버를 착각하여 작성한 코드가 그 즉시 검출되지 않기 때문에 코드가 호출되기 전까지는 문제를 발견하는건 거의 불가능이죠. 그리고 그런 녀석들이 암세포가 되어 잠복하고 있다가 프로젝트 말기에 폭발하는거죠. BOOM!! :)

자바스크립트 OOP는 C#이나 다른 컴파일 언어에서 사용하는 것보다 몇 배는 더 주의 깊게 다뤄야 할 것 같고 그렇기 때문에 절대로 초보자에게 적합한 방법은 아닌 것 같아요. 차라리 C#등의 언어에서는 아주 사소하지만 정말 자주 실수하는 문제들은 대부분 사전에 걸러지기 때문에 비록 코드의 논리가 형편없더라도 높은 생산성과 심지어 좋은 성능까지도 얻을 수 있는게 아닐까 생각해봐요.

그렇지만, 현재 웹 클라이언트 언어는 사실상 자바스크립트가 유일하고 현재 상황에 웹 프로그래밍을 한다면 어떤 식으로든 자바스크립트를 해야 하겠죠. 이 상황에서 자바스크립트 OOP 스타일을 사용한다면 그나마 훨씬 나은 환경을 구축할 수 있다는 건 확실한 것 같아요. 분명히 자바스크립트에 대한 풍부한 경험과 OOP에 대한 명확한 지식과 통찰이 있는 분이라면 자바스크립트 OOP스타일로 지금 당장 보이는 웹에 많은 일을 보다 효율적으로 할 수 있을거에요.

Silverlight
저는 실버라이트 1.1과 그 이후의 실버라이트가 지금의 플래시에 근접하는 저변을 확보한다면 자바스크립트가 유일한 대안이었던 클라이언트 언어에 C#이라는 강력한 생산성을 제공하는 언어도 선택할 수 있지 않을까 기대해봐요.

혹은 한창 주가를 올리고 있는 루비나 이제는 VB의 아성을 거의 쫒아온 파이쏜이 웹 브라우저들에서 표준지원되게 될지도 모르죠. 실버라이트는 만약 그런 상황이 온다고 해도 C#뿐만 아니라 IronRuby와 IronPython을 제공하기 때문에 여전히 매력적인 것 같아요.

전에 Taeyo님과 대화할 기회가 있었는데 실버라이트가 브라우저 플러그인이기 때문에 실버라이트의 코드로 DOM을 제어할 경우 브라우저-플러그인간 Interop이 발생하고 여기에서 오는 손실이 크다...라는 얘기를 들었어요. 정확한 통찰이라고 생각해요.

하지만 저는 몇가지 이유로 대부분의 상황에서 향후 실버라이트가 자바스크립트를 대체할 수 있는 클라이언트 언어로써 선택될 수 도 있다고 생각해요.
1. 언어에서 성능적인 기대를 한다면 아마도 암호화/문자열 파싱 같은 고도의 연산 작용을 의미할텐데 Interop, 즉 브라우저-플러그인간 호출과 반환 작용을 제외한 순수 연산 능력은 C#이 더 좋다.
2. Interop때문에 성능 저하가 있다고 해도 그 Interop이 Move 이벤트 같이 잦은 빈도로 발생하기보다는 클릭/In/Out과 같은 일반적으로 더 많이 사용되는 이벤트라면 전체적인 성능차는 크지 않다.
3. 심지어 Interop으로 인해 성능이 더 떨어진다고 해도 일반적인 상황과 동일한 숙련도를 가진 개발자에게 C#이 자바스크립트에 비해 더 높은 생산성을 부여할 수 있다.
4. 향후 기술적인 진보의 속도가 실버라이트 쪽이 월등히 빠르다.

뭐 그냥 좋은 말만 써놓은 것 같지만, 어디까지나 이렇게 대체될 수 있으면 좋겠다란 생각이고요. 아직은 실버라이트 1.1이 제공하는 HtmlPage 클래스와 BrowserHost 클래스가 자바스크립트와 HTML DOM의 모든 영역을 커버하지 못하기 때문에 제 생각대로의 시나리오가 만들어진다고 해도 여전히 자바스크립트는 간단한 Interop을 위해 사용되겠죠. 지금의 Scriptable처럼.

자바스크립트가 정말로 훌륭하고 쿨하게 OOP를 지원한다고 해도 스크립트는 스크립트답게 간단하게 쓰는게 최고 아닌가요? 우리는 예전부터 alert 하나만으로 많은걸 해왔잖아요? 스크립트는 alert스럽게, 그리고 복잡해진 코드는 관리되는Managed 코드에게 넘겨주자구요.

남정현님의 포스팅을 읽다가 문득 지금의 생각을 정리하고 싶어서 달려봤습니다. :)
쓰다보니 세시간이 훌쩍 지나갔네요. 후우 내일 일은 내일 생각해야죠.

노파심스.
1. 자바스크립트에 대한 저의 생각은 살얼음판 위에 놓인 돌덩어리에 지나지 않습니다. 제가 모르고 있거나 오해하고 있는 부분에 대해 알려주시면 정말 고맙겠습니다.
2. 쓰다보니 브라우저-플러그인간 Interop이 제가 이해하고 있는게 맞는지 잘 확신이 안갑니다. 실버라이트 1.1의 Managed코드는 최종적으로 각 OS에 특화된 플러그인을 통해 네이티브 코드를 호출하게 되는데 이것도 일종의 Interop이겠지만 브라우저를 통해 실행되는 자바스크립트에 비해 호출 효율이 떨어지지 않을 거라고 어설프게 낙관하고 있습니다. 본문에서 제가 얘기한 Interop은 실버라이트가 HTML DOM개체를 접근할 때 발생하는 플러그인-브라우저간 Interop을 말합니다.
3. C#의 성능이 좋다는 점에 관해서는 실제로 증명할만한 테스트를 하진 않았습니다만 "몰라요, 울 거쓰리 아저씨가 그랬쪄염 뿌우~'ㅅ'a" 되겠습니다.

신고
Posted by gongdo


티스토리 툴바