프레임워크에 대해(1): RJS, RHTML, 마이그레이션
소소하지 않은 일상 / 2007/11/25 18:53
프로토타입이란 말은 특히 웹 프로젝트에서 다양한 용도로 많이 사용된다. 프로덕트 기획단계에서 사용하는 페이퍼 프로토타입도 있고, 사업성과 구현 가능성을 검토해보기 위해 알파/베타 버전 이전에 만들어보는 시제품을 프로토타입이라 한다. 이 글에서 말하려는 프로토타입은 prototype.js 자바스크립트 프레임워크이다. 본래는 자바스크립트에서 객체를 확장하는 prototype 프러퍼티와 구분하기 위해 prototype.js라고 영문 및 확장자를 모두 표기해주곤 하지만, 이 글과 이 다음 글에서는 prototype.js만을 언급하므로 편의상 prototype.js를 프로토타입이라고 바꿔서 칭하겠다.
프로토타입은 자바스크립트 프레임워크 중 가장 많이 쓰이고 있다. 특히 레일스에서는 프로젝트 생성과 동시에 프로토타입(1.5.0 버전)과 스크립타큘러스(중 일부) 파일을 프로젝트 안(#{RAILS_APP}/public/javascripts/...)에 함께 만들어내기 때문에, 사용하지 않으려면 그냥 냅두거나, 삭제하거나, 극단적인 사람이라면 생성 시에 Opt-out 시켜줄 수도 있다(아마도 Rake에서).
레일스는 RJS 덕분에 프로토타입을 프로젝트에 내장시킬 명분을 찾았다. 자바스크립트를 직접 건드리지 않아도 루비코드만으로 몇 가지 DOM 스크립팅과 AJAX 개발이 가능하다는 점은 자바스크립트에 익숙지 않은 서버 개발자들에게 매력적일 수 있다. 하지만 이런 정황 때문에 프로토타입이 RJS를 위한 모듈 정도로 전락한 것 같아 아쉽다. 프로토타입을 잘 알지 못할 때의 나 역시 그 정도로 생각했기 때문에.
ASP.NET AJAX 역시 이런 접근 방법으로 마케팅을 했다. ASP.NET AJAX 에서 제공하는 테그를 코드에 삽입하면 AJAX 인터페이스가 된다. 자바스크립트를 몰라도 된다. ASP.NET의 특성상 프리젠테이션과 비즈니스 로직, 데이터셋이 애매하게 결합되어 있고 컴파일 시에 분리되기 때문에 밑에서 일어나는 일은 더더욱 감추어진다. 감추어지기 때문에 매력적일 수 있지만, 감추어지기 때문에 아무 것도 알 수가 없다. ASP.NET AJAX에 익숙해질 수록 ASP.NET에 묶이게 된다. AJAX 튜토리얼이 아니라, ASP.NET AJAX 튜토리얼이 제공된다.
레일스 역시 자바스크립트 튜토리얼 대신 RJS 핼퍼 메서드 레퍼런스를 제공한다. 레일스 커뮤니티이니 자바스크립트 튜토리얼을 제공해줄 의무 보다는 자체 핼퍼 메서드 튜토리얼을 제공할 의무가 있었을 것이고, 이는 레일스 입문자가 자바스크립트 보다는 RJS에 익숙해지도록 유도할 가능성이 있다. 레일스 커뮤니티 내에서는 RJS에 대해 찬반 논란이 있겠지만, 논란을 접하지 않은 입문자가 느끼기에는 RJS가 AJAX의 가장 좋은 대안이라고 착각할 수 있다. 실상은 RJS만 가지고 할 수 있는 것은 정말 별로 없다.
프로토타입 프레임워크를 자바스크립트와 함께 직접 사용하고 코드 내부를 들여다보는 과정은 학습에 도움이 된다. 자바스크립트를 더 잘 이해하게 되고 객체지향적 사고를 하는데 도움을 준다. 반면 RJS 헬퍼 메서드를 외워서 익숙해진다 해도 자바스크립트에는 익숙해지지 못한다. 형태는 루비코드이지만 루비나 레일스의 구동과 상관이 없고 자바스크립트를 만들어내지만 자바스크립트의 형태와 철학과도 거리가 멀다. 변환기 또는 메타 프로그래밍의 역할만을 하는 변종 언어인 셈이다.
자바스크립트가 0과 1로 된 기계어도 아니고 어셈블리도 아닌데, 자바스크립트를 배우기 싫다고 루비와도 별 관계 없는 또 다른 변종 언어를 별도로 익히는 것은 현명하지 못하다. 자바로 자바스크립트를 만들어내는 구글의 웹툴킷이나 ASP.NET AJAX도 마찬가지이다. 이들의 흥미로운 접근에 대해 관심을 가질 필요는 있고 이들이 어떤 방식으로 어떤 자바스크립트 코드를 만들어내는지 파악해보는 것은 좋지만 그 이상의 애착은 좋지 않다.
이런 관점의 연장선상에서, 나는 레일스 RHTML에서 HTML 테그를 만들어내는 헬퍼 메서드도 별로 좋아하지 않는다. 레일스에서 제공하는 튜토리얼과 레일스 관련 서적에서는 링크나 폼 등의 테그에 대해 헬퍼 메서드를 기준으로 설명한다. 특히 remote가 포함된 헬퍼 메서드는 RJS와 쌍으로 언급된다. 교과서적인 구현 목표에 대해서는 순조롭지만, 만들고자 하는 것이 예제와 조금만 달라져도 막막해진다.
이런 상황에서는 고민한다고 해서 진행되지 않으며 헬퍼 메서드에 대한 레퍼런스를 찾아야만 하고 그것을 암기해야 한다. 자바스크립트 로직이나 DOM을 기준으로 생각하면 아무 것도 아닌데, RJS나 RHTML의 헬퍼 메서드를 기준으로 생각하다보면 그것의 정확한 옵션들과 세부 설정사항들을 알지 않으면 구현할 수 없다. remote_form_for나 link_to_remote는 여러번 써봐도 그 옵션들이 익숙해지지 않는다. 그냥 HTML 테그를 사용하고, 발생되는 이벤트를 이벤트 핸들러나 이벤트 리스너, 그리고 DOM 스크립트로 처리하는 게 좋다. 그래야 뭐가 어떻게 돌아갈지 알겠다.
뭔가를 학습하는 방식을 크게 '사고'와 '암기'로 나눈다면, 기존 헬퍼 메서드의 사용은 암기적인 학습을 요구한다. 차라리 자바스크립트 코어의 가장 원초적인 함수만 가지고 이리 저리 필요한 기능을 구현하는 것은 사고력에 도움이 된다. 만약 동일한 기능을 구현할 수 있는 좀더 저수준의 방법이 있고, 그것이 고수준의 것보다 특별히 어렵거나 복잡하지 않다면, 저수준을 직접 다루는 것이 낫다.
반복적인 요소에 대해 자신이 직접 헬퍼 메서드를 구현해 사용하는 것은, 이미 자바스크립트나 HTTP, 그리고 레일스에 대해 잘 파악하고 있는 것이므로 개인적인 사용 시에는 괜찮아 보인다. 하지만 협업 시에는 별도의 문서화나 커뮤니케이션이 필요하고 헬퍼 메서드 구현자가 아닌 다른 사람의 경우, 결국 헬퍼 메서드의 동작과 옵션을 익혀야 하므로 암기적 학습이 요구된다.
내부 구현을 잘 알고 사용하는 것이라면 헬퍼 메서드이건 라이브러리이건 프레임워크건 좋은 도구이자 좋은 학습 대상이 된다. 이런 관점을 RHTML, RJS보다 넓게 확장하면, 레일스 프레임워크와 프로토타입 프레임워크에도 적용해볼 수 있다.
RJS, RHTML, ASP.NET AJAX 등의 보조 기술, 그리고 프로토타입이나 레일스 등의 프레임워크는 모두, 초기 학습장벽을 낮춰준다는 이점이 있다. 지나치게 추종하면 불필요한 신앙심과 함께 그 기술에 묶일 가능성이 있지만 객관성을 유지하면서 접근한다면, 해당 기술이 가진 많은 것들을 구현해볼 수 있고 그 기술의 구현 방식을 잘 설계된 예제를 통해 학습할 수 있다.
다른 서버 프로그래밍 언어를 배우더라도, 그 언어의 대표적인 프레임워크에서 부터 접근해야겠다는 생각을 하게 되었다. 해당 언어가 가장 교과서적으로 설계된 프레임워크를 익히면 그 언어의 철학과 관습을 빨리 접할 수 있다. 처음에는 그것을 사용하게 될 것이고, 점차 그것에 익숙해져 내부 구현사항을 알아갈 것이고, 곧 그것을 직접 수정하거나 일부를 구현해 의존도를 낮추게 되어, 최종적으로는 직접 최적화된 프레임워크를 만들 수 있게 될 것이다. 즉 초반에는 적극적으로 프레임워크를 도입하되, 결국 프레임워크에 의지하지 않는 것이 최종 목표가 되는 것이다.
어떤 기술을 객관적으로 판단하려면 그 기술을 세밀하게 학습해야 한다. 학습하기 전에는 그것의 장단점을 제대로 판단할 수 없다. 이는 딜레마를 야기하는데, 기술을 객관적으로 평가하려면 감정적인 애착이 방해가 되지만 기술을 효율적으로 학습하려면 감정적인 애착이 도움이 된다. 나 같은 경우는 효율적으로 학습하기 위해 그 기술의 좋은 점들을 잔뜩 생각해서 스스로도 되뇌이고 주변에도 말하고 다닌다. 어느 정도 학습하고 나면 그 기술의 구린 면들을 알게 되니 기술의 단점들을 생각하고 말하기 시작한다. 나 스스로에게는 변덕쟁이가 되고 주위 사람들에게는 구라쟁이가 되어버리니 이것이 딜레마다.
레일스 마이그레이션, 프로토타입에 대해서도 이런 과정을 거치고 있고, 아마도 곧 전체 레일스 프레임워크에 대해서도 그렇게 생각하게 될 지 모른다. 마이그레이션도 RJS에서 느낀 바와 비슷하다. 쿼리문을 몰라도 루비로 된 데이터베이스 설계 코드를 작성할 수 있다니, 게다가 데이터베이스 설계별 버전까지 관리할 수 있다니 이 얼마나 멋져보이는 일인가. 나는 정말 착실하게 마이그레이션을 사용해왔다.(RJS처럼)
쿼리문을 직접 다루는 것에 비해 마이그레이션 코드로 할 수 있는 것이 별로 없고, 마이그레이션의 버전관리는 소스코드 버전관리처럼 명쾌하지도 치밀하지도 않아 마이그레이션 에러 한 방에 데이터베이스 전체가 엉킬 수 있다. 우선 고수준 보다는 저수준이 낫다는 관점과 연결되어 RJS보다 자바스크립트가 나은 것처럼 마이그레이션보다 쿼리문을 익히는 것이 더 낫다.
또 소스코드 버전관리는 안전성을 위해서 사용하지만 마이그레이션의 버전관리는 사람이 인지하고 생각하기 편하려고 사용하며 안전성을 돕기는 커녕 해칠 가능성이 크다. 새 애플리케이션을 개발하여 최초로 배치할 경우나, 프로토타입을 만드는 경우, 이런 저런 라이브러리의 예제를 신속하게 구현해 보거나 할 때 드물게 마이그레이션을 써볼 기회가 있을 것이다.
서버 프로그래밍 자체를 레일스를 통해 처음 접하는 사람은 RJS나 마이그레이션이 있기 때문에 그나마 단기간에 웹 페이지를 만들어낼 수 있었다. 이런 것들이 없었다면 웹 개발이란 게 대체 뭔지 상상하는 것 조차 힘겨웠을지 모른다. 레일스 덕분에 웹 개발의 대중화가 일어날 수 있었다. 이런 고수준의 처리 덕분에 웹 개발을 쉽게 시작하게 되었다면 이제 주머니 밖으로 나와 저수준을 공략해야 한다. RJS 대신 자바스크립트를, 마이그레이션 대신 데이터베이스 쿼리를, RHTML 헬퍼 메서드 대신 테그와 프러퍼티를 공략해야 한다.
개발자들이 보기에 너무 당연하고 유치한 글을 적은 것 같아 마음이 아프지만 나와 같은 과정을 겪고 있는 사람들에겐 공감이 될까 싶어 적어보았다. 다음 글엔 프로토타입 프레임워크의 장단점과 활용 방법 등에 대한 주관적인 글을 적어보려 한다.
프로토타입은 자바스크립트 프레임워크 중 가장 많이 쓰이고 있다. 특히 레일스에서는 프로젝트 생성과 동시에 프로토타입(1.5.0 버전)과 스크립타큘러스(중 일부) 파일을 프로젝트 안(#{RAILS_APP}/public/javascripts/...)에 함께 만들어내기 때문에, 사용하지 않으려면 그냥 냅두거나, 삭제하거나, 극단적인 사람이라면 생성 시에 Opt-out 시켜줄 수도 있다(아마도 Rake에서).
레일스는 RJS 덕분에 프로토타입을 프로젝트에 내장시킬 명분을 찾았다. 자바스크립트를 직접 건드리지 않아도 루비코드만으로 몇 가지 DOM 스크립팅과 AJAX 개발이 가능하다는 점은 자바스크립트에 익숙지 않은 서버 개발자들에게 매력적일 수 있다. 하지만 이런 정황 때문에 프로토타입이 RJS를 위한 모듈 정도로 전락한 것 같아 아쉽다. 프로토타입을 잘 알지 못할 때의 나 역시 그 정도로 생각했기 때문에.
ASP.NET AJAX 역시 이런 접근 방법으로 마케팅을 했다. ASP.NET AJAX 에서 제공하는 테그를 코드에 삽입하면 AJAX 인터페이스가 된다. 자바스크립트를 몰라도 된다. ASP.NET의 특성상 프리젠테이션과 비즈니스 로직, 데이터셋이 애매하게 결합되어 있고 컴파일 시에 분리되기 때문에 밑에서 일어나는 일은 더더욱 감추어진다. 감추어지기 때문에 매력적일 수 있지만, 감추어지기 때문에 아무 것도 알 수가 없다. ASP.NET AJAX에 익숙해질 수록 ASP.NET에 묶이게 된다. AJAX 튜토리얼이 아니라, ASP.NET AJAX 튜토리얼이 제공된다.
레일스 역시 자바스크립트 튜토리얼 대신 RJS 핼퍼 메서드 레퍼런스를 제공한다. 레일스 커뮤니티이니 자바스크립트 튜토리얼을 제공해줄 의무 보다는 자체 핼퍼 메서드 튜토리얼을 제공할 의무가 있었을 것이고, 이는 레일스 입문자가 자바스크립트 보다는 RJS에 익숙해지도록 유도할 가능성이 있다. 레일스 커뮤니티 내에서는 RJS에 대해 찬반 논란이 있겠지만, 논란을 접하지 않은 입문자가 느끼기에는 RJS가 AJAX의 가장 좋은 대안이라고 착각할 수 있다. 실상은 RJS만 가지고 할 수 있는 것은 정말 별로 없다.
프로토타입 프레임워크를 자바스크립트와 함께 직접 사용하고 코드 내부를 들여다보는 과정은 학습에 도움이 된다. 자바스크립트를 더 잘 이해하게 되고 객체지향적 사고를 하는데 도움을 준다. 반면 RJS 헬퍼 메서드를 외워서 익숙해진다 해도 자바스크립트에는 익숙해지지 못한다. 형태는 루비코드이지만 루비나 레일스의 구동과 상관이 없고 자바스크립트를 만들어내지만 자바스크립트의 형태와 철학과도 거리가 멀다. 변환기 또는 메타 프로그래밍의 역할만을 하는 변종 언어인 셈이다.
자바스크립트가 0과 1로 된 기계어도 아니고 어셈블리도 아닌데, 자바스크립트를 배우기 싫다고 루비와도 별 관계 없는 또 다른 변종 언어를 별도로 익히는 것은 현명하지 못하다. 자바로 자바스크립트를 만들어내는 구글의 웹툴킷이나 ASP.NET AJAX도 마찬가지이다. 이들의 흥미로운 접근에 대해 관심을 가질 필요는 있고 이들이 어떤 방식으로 어떤 자바스크립트 코드를 만들어내는지 파악해보는 것은 좋지만 그 이상의 애착은 좋지 않다.
이런 관점의 연장선상에서, 나는 레일스 RHTML에서 HTML 테그를 만들어내는 헬퍼 메서드도 별로 좋아하지 않는다. 레일스에서 제공하는 튜토리얼과 레일스 관련 서적에서는 링크나 폼 등의 테그에 대해 헬퍼 메서드를 기준으로 설명한다. 특히 remote가 포함된 헬퍼 메서드는 RJS와 쌍으로 언급된다. 교과서적인 구현 목표에 대해서는 순조롭지만, 만들고자 하는 것이 예제와 조금만 달라져도 막막해진다.
이런 상황에서는 고민한다고 해서 진행되지 않으며 헬퍼 메서드에 대한 레퍼런스를 찾아야만 하고 그것을 암기해야 한다. 자바스크립트 로직이나 DOM을 기준으로 생각하면 아무 것도 아닌데, RJS나 RHTML의 헬퍼 메서드를 기준으로 생각하다보면 그것의 정확한 옵션들과 세부 설정사항들을 알지 않으면 구현할 수 없다. remote_form_for나 link_to_remote는 여러번 써봐도 그 옵션들이 익숙해지지 않는다. 그냥 HTML 테그를 사용하고, 발생되는 이벤트를 이벤트 핸들러나 이벤트 리스너, 그리고 DOM 스크립트로 처리하는 게 좋다. 그래야 뭐가 어떻게 돌아갈지 알겠다.
뭔가를 학습하는 방식을 크게 '사고'와 '암기'로 나눈다면, 기존 헬퍼 메서드의 사용은 암기적인 학습을 요구한다. 차라리 자바스크립트 코어의 가장 원초적인 함수만 가지고 이리 저리 필요한 기능을 구현하는 것은 사고력에 도움이 된다. 만약 동일한 기능을 구현할 수 있는 좀더 저수준의 방법이 있고, 그것이 고수준의 것보다 특별히 어렵거나 복잡하지 않다면, 저수준을 직접 다루는 것이 낫다.
반복적인 요소에 대해 자신이 직접 헬퍼 메서드를 구현해 사용하는 것은, 이미 자바스크립트나 HTTP, 그리고 레일스에 대해 잘 파악하고 있는 것이므로 개인적인 사용 시에는 괜찮아 보인다. 하지만 협업 시에는 별도의 문서화나 커뮤니케이션이 필요하고 헬퍼 메서드 구현자가 아닌 다른 사람의 경우, 결국 헬퍼 메서드의 동작과 옵션을 익혀야 하므로 암기적 학습이 요구된다.
내부 구현을 잘 알고 사용하는 것이라면 헬퍼 메서드이건 라이브러리이건 프레임워크건 좋은 도구이자 좋은 학습 대상이 된다. 이런 관점을 RHTML, RJS보다 넓게 확장하면, 레일스 프레임워크와 프로토타입 프레임워크에도 적용해볼 수 있다.
RJS, RHTML, ASP.NET AJAX 등의 보조 기술, 그리고 프로토타입이나 레일스 등의 프레임워크는 모두, 초기 학습장벽을 낮춰준다는 이점이 있다. 지나치게 추종하면 불필요한 신앙심과 함께 그 기술에 묶일 가능성이 있지만 객관성을 유지하면서 접근한다면, 해당 기술이 가진 많은 것들을 구현해볼 수 있고 그 기술의 구현 방식을 잘 설계된 예제를 통해 학습할 수 있다.
다른 서버 프로그래밍 언어를 배우더라도, 그 언어의 대표적인 프레임워크에서 부터 접근해야겠다는 생각을 하게 되었다. 해당 언어가 가장 교과서적으로 설계된 프레임워크를 익히면 그 언어의 철학과 관습을 빨리 접할 수 있다. 처음에는 그것을 사용하게 될 것이고, 점차 그것에 익숙해져 내부 구현사항을 알아갈 것이고, 곧 그것을 직접 수정하거나 일부를 구현해 의존도를 낮추게 되어, 최종적으로는 직접 최적화된 프레임워크를 만들 수 있게 될 것이다. 즉 초반에는 적극적으로 프레임워크를 도입하되, 결국 프레임워크에 의지하지 않는 것이 최종 목표가 되는 것이다.
어떤 기술을 객관적으로 판단하려면 그 기술을 세밀하게 학습해야 한다. 학습하기 전에는 그것의 장단점을 제대로 판단할 수 없다. 이는 딜레마를 야기하는데, 기술을 객관적으로 평가하려면 감정적인 애착이 방해가 되지만 기술을 효율적으로 학습하려면 감정적인 애착이 도움이 된다. 나 같은 경우는 효율적으로 학습하기 위해 그 기술의 좋은 점들을 잔뜩 생각해서 스스로도 되뇌이고 주변에도 말하고 다닌다. 어느 정도 학습하고 나면 그 기술의 구린 면들을 알게 되니 기술의 단점들을 생각하고 말하기 시작한다. 나 스스로에게는 변덕쟁이가 되고 주위 사람들에게는 구라쟁이가 되어버리니 이것이 딜레마다.
레일스 마이그레이션, 프로토타입에 대해서도 이런 과정을 거치고 있고, 아마도 곧 전체 레일스 프레임워크에 대해서도 그렇게 생각하게 될 지 모른다. 마이그레이션도 RJS에서 느낀 바와 비슷하다. 쿼리문을 몰라도 루비로 된 데이터베이스 설계 코드를 작성할 수 있다니, 게다가 데이터베이스 설계별 버전까지 관리할 수 있다니 이 얼마나 멋져보이는 일인가. 나는 정말 착실하게 마이그레이션을 사용해왔다.(RJS처럼)
쿼리문을 직접 다루는 것에 비해 마이그레이션 코드로 할 수 있는 것이 별로 없고, 마이그레이션의 버전관리는 소스코드 버전관리처럼 명쾌하지도 치밀하지도 않아 마이그레이션 에러 한 방에 데이터베이스 전체가 엉킬 수 있다. 우선 고수준 보다는 저수준이 낫다는 관점과 연결되어 RJS보다 자바스크립트가 나은 것처럼 마이그레이션보다 쿼리문을 익히는 것이 더 낫다.
또 소스코드 버전관리는 안전성을 위해서 사용하지만 마이그레이션의 버전관리는 사람이 인지하고 생각하기 편하려고 사용하며 안전성을 돕기는 커녕 해칠 가능성이 크다. 새 애플리케이션을 개발하여 최초로 배치할 경우나, 프로토타입을 만드는 경우, 이런 저런 라이브러리의 예제를 신속하게 구현해 보거나 할 때 드물게 마이그레이션을 써볼 기회가 있을 것이다.
서버 프로그래밍 자체를 레일스를 통해 처음 접하는 사람은 RJS나 마이그레이션이 있기 때문에 그나마 단기간에 웹 페이지를 만들어낼 수 있었다. 이런 것들이 없었다면 웹 개발이란 게 대체 뭔지 상상하는 것 조차 힘겨웠을지 모른다. 레일스 덕분에 웹 개발의 대중화가 일어날 수 있었다. 이런 고수준의 처리 덕분에 웹 개발을 쉽게 시작하게 되었다면 이제 주머니 밖으로 나와 저수준을 공략해야 한다. RJS 대신 자바스크립트를, 마이그레이션 대신 데이터베이스 쿼리를, RHTML 헬퍼 메서드 대신 테그와 프러퍼티를 공략해야 한다.
개발자들이 보기에 너무 당연하고 유치한 글을 적은 것 같아 마음이 아프지만 나와 같은 과정을 겪고 있는 사람들에겐 공감이 될까 싶어 적어보았다. 다음 글엔 프로토타입 프레임워크의 장단점과 활용 방법 등에 대한 주관적인 글을 적어보려 한다.
