요 근래 회사 업무와 연관되어있는, 개인 프로젝트를 진행하고 있다. ESB 모니터링 솔루션인데 UI쪽을 Ajax로 개발하고 있다. 원체 자바스크립트 언어를 싫어했던 데다가 그런 선입관으로 인해 처음 이틀정도는 잘못된 선택이다 싶어서 엄청 짜증이 나기도 했건만 조금씩 익숙해지다보니 Ajax기술 이거 상당히 매력적인 놈이다.
어떤 기술을 선택할 때 calmglow는 쉽게 호감을 보이지 않는다. calmglow는 때때로 어떤 기술은 누구보다도 먼저 그 가치를 발견하기도 한다. 아마도 국내에서 ant를 사용하고 관련 문서를 공개한 사람은 calmglow가 최초 혹은 상당히 처음이 아니었을까 싶은데, '이거다!'싶은 놈을 찾는 데 있어 calmglow는 꽤 별다른 관점을 가지고 있다. 특히 UI쪽 프레임워크를 선택할 때는 정말 신중한 편인데, 지금까지 나온 자바의 UI기술에 대해 딱히 '이거다!'싶은 놈을 이제까지 만나지 못했다. JSP는 물론이고 Struts나 JSF 역시 calmglow의 눈에는 탐탁치 않게 여겨졌었다. 어쩌면 복잡하다 싶은 놈들은 죄다 싫어하는 지도 모르겠다. 그 인기있는 Hibernate 역시 단순한 calmglow의 입장에서 보면 좀 짜증도 나고 과연 실전에서 얼마나 잘 쓰일까 싶은 놈인데 이 아키텍처가 JEE 5에 들어간다고 하니 할 말은 없다. 아무튼 좀 유별난 calmglow의 눈에 처음으로 맘에 드는 UI관련 기술을 만났으니 그게 바로 Ajax다!
무엇보다 스크립트 기반의 언어를 사용한다는 점이 가장 유동성이 중요한 UI에서 맘에 드는 점이다. JSF나 Struts는 presentation logic과 biz logic의 분리를 가능케 하고 더구나 IDE의 사용을 통한 개발의 용이성을 준다는 점에서 박수를 받을만한 아키텍처이기는 하지만 보다 유동적이고 사용자 친화적인 UI를 구현하는 데 있어서는 JSP에서 한발짝도 더 나아가지 못했다고 생각한다. 반면에 Ajax를 사용하게 되면 스크립트 언어 기반이기에 개발에 드는 생산성을 보다 높일 수 있다. 테스트 속도도 서버와 분리된 클라이언트 영역만을 따로 테스트할 수 있으므로 빠르다.
또한 REST 방식의 서버와의 통신을 적용할 경우 완벽한 클라이언트와 서버 로직의 분리가 가능해진다. 이제까지 jsp나 JSF, Struts 등이 어떻게든 UI로직과 biz로직을 분리하기 위해 많은 노력을 해왔지만 다양한 사용자 요구사항을 만족시키기 위해서는 결국 어쩔 수 없이 일반 jsp에 스크립트릿이 들어가기 일쑤였고 개발자들 마다 서로 다른 개발 스타일에 의해 때로 완벽한 분리에 의한 구현은 언제나 지켜지기 어려웠던 것이 사실이지만 Ajax를 사용하게 되면서 완벽한 분리가 가능해진다는 점이다.
더구나 생각보다 매우 다양한 Ajax관련 라이브러리들로 인해 꽤나 생산성이 높다는 것도 장점이다. 마치 예전 CS 환경에서의 개발을 하듯 쉽고 즐겁게 개발하는 것이 가능해졌다.
이전에 생각했던 Ajax의 단점인 디버깅의 불편함도 실제로는 다양한 방법들이 존재했다.
그럼에도 불구하고 아직 Ajax가 지니는 문제는 아마도 다양한 브라우저를 지원해야하는 부담으로 인해 지금 구현된 것이 나중에 어떠한 외부 변화로 인해 작동하지 않을 수도 있음을 고려해야 한다는 것이다. 또한 여전히 IE와 FireFox간의 호환되지 않는 몇몇 부분들로 인해 크로스 브라우저 지원의 Ajax 관련 라이브러리를 사용하지 않고 calmglow처럼 맨땅에 헤딩 식으로 개발을 하다보면 상당한 어려움에 봉착할 수도 있다.
어찌되었건 이전의 포스트에서 상당히 ajax에 대하여 폄하했던 것을 물러야할 것 같고, Ajax가 기존의 웹기반 UI기술 모두를 대체할 수 있는 기술은 아니지만 적어도 상당히 오랜 기간동안 사람들에게 사랑받을 기술로 남으리라고 결론내리게 되었다. 혹시 아직까지 ajax에 대하여 의심의 눈초리를 보내고 있는 개발자들이 있다면, 혹은 기존의 삽질의 기억만을 간직한 채 웹 UI개발의 세계에서 떠난 이들이 있다면 한번쯤 권해보고 싶은 기술이다. Ajax!
어떤 기술을 선택할 때 calmglow는 쉽게 호감을 보이지 않는다. calmglow는 때때로 어떤 기술은 누구보다도 먼저 그 가치를 발견하기도 한다. 아마도 국내에서 ant를 사용하고 관련 문서를 공개한 사람은 calmglow가 최초 혹은 상당히 처음이 아니었을까 싶은데, '이거다!'싶은 놈을 찾는 데 있어 calmglow는 꽤 별다른 관점을 가지고 있다. 특히 UI쪽 프레임워크를 선택할 때는 정말 신중한 편인데, 지금까지 나온 자바의 UI기술에 대해 딱히 '이거다!'싶은 놈을 이제까지 만나지 못했다. JSP는 물론이고 Struts나 JSF 역시 calmglow의 눈에는 탐탁치 않게 여겨졌었다. 어쩌면 복잡하다 싶은 놈들은 죄다 싫어하는 지도 모르겠다. 그 인기있는 Hibernate 역시 단순한 calmglow의 입장에서 보면 좀 짜증도 나고 과연 실전에서 얼마나 잘 쓰일까 싶은 놈인데 이 아키텍처가 JEE 5에 들어간다고 하니 할 말은 없다. 아무튼 좀 유별난 calmglow의 눈에 처음으로 맘에 드는 UI관련 기술을 만났으니 그게 바로 Ajax다!
무엇보다 스크립트 기반의 언어를 사용한다는 점이 가장 유동성이 중요한 UI에서 맘에 드는 점이다. JSF나 Struts는 presentation logic과 biz logic의 분리를 가능케 하고 더구나 IDE의 사용을 통한 개발의 용이성을 준다는 점에서 박수를 받을만한 아키텍처이기는 하지만 보다 유동적이고 사용자 친화적인 UI를 구현하는 데 있어서는 JSP에서 한발짝도 더 나아가지 못했다고 생각한다. 반면에 Ajax를 사용하게 되면 스크립트 언어 기반이기에 개발에 드는 생산성을 보다 높일 수 있다. 테스트 속도도 서버와 분리된 클라이언트 영역만을 따로 테스트할 수 있으므로 빠르다.
또한 REST 방식의 서버와의 통신을 적용할 경우 완벽한 클라이언트와 서버 로직의 분리가 가능해진다. 이제까지 jsp나 JSF, Struts 등이 어떻게든 UI로직과 biz로직을 분리하기 위해 많은 노력을 해왔지만 다양한 사용자 요구사항을 만족시키기 위해서는 결국 어쩔 수 없이 일반 jsp에 스크립트릿이 들어가기 일쑤였고 개발자들 마다 서로 다른 개발 스타일에 의해 때로 완벽한 분리에 의한 구현은 언제나 지켜지기 어려웠던 것이 사실이지만 Ajax를 사용하게 되면서 완벽한 분리가 가능해진다는 점이다.
더구나 생각보다 매우 다양한 Ajax관련 라이브러리들로 인해 꽤나 생산성이 높다는 것도 장점이다. 마치 예전 CS 환경에서의 개발을 하듯 쉽고 즐겁게 개발하는 것이 가능해졌다.
이전에 생각했던 Ajax의 단점인 디버깅의 불편함도 실제로는 다양한 방법들이 존재했다.
그럼에도 불구하고 아직 Ajax가 지니는 문제는 아마도 다양한 브라우저를 지원해야하는 부담으로 인해 지금 구현된 것이 나중에 어떠한 외부 변화로 인해 작동하지 않을 수도 있음을 고려해야 한다는 것이다. 또한 여전히 IE와 FireFox간의 호환되지 않는 몇몇 부분들로 인해 크로스 브라우저 지원의 Ajax 관련 라이브러리를 사용하지 않고 calmglow처럼 맨땅에 헤딩 식으로 개발을 하다보면 상당한 어려움에 봉착할 수도 있다.
어찌되었건 이전의 포스트에서 상당히 ajax에 대하여 폄하했던 것을 물러야할 것 같고, Ajax가 기존의 웹기반 UI기술 모두를 대체할 수 있는 기술은 아니지만 적어도 상당히 오랜 기간동안 사람들에게 사랑받을 기술로 남으리라고 결론내리게 되었다. 혹시 아직까지 ajax에 대하여 의심의 눈초리를 보내고 있는 개발자들이 있다면, 혹은 기존의 삽질의 기억만을 간직한 채 웹 UI개발의 세계에서 떠난 이들이 있다면 한번쯤 권해보고 싶은 기술이다. Ajax!
덧글