프로토타입이란 말은 특히 웹 프로젝트에서 다양한 용도로 많이 사용된다. 프로덕트 기획단계에서 사용하는 페이퍼 프로토타입도 있고, 사업성과 구현 가능성을 검토해보기 위해 알파/베타 버전 이전에 만들어보는 시제품을 프로토타입이라 한다. 이 글에서 말하려는 프로토타입은 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 헬퍼 메서드 대신 테그와 프러퍼티를 공략해야 한다.
개발자들이 보기에 너무 당연하고 유치한 글을 적은 것 같아 마음이 아프지만 나와 같은 과정을 겪고 있는 사람들에겐 공감이 될까 싶어 적어보았다. 다음 글엔 프로토타입 프레임워크의 장단점과 활용 방법 등에 대한 주관적인 글을 적어보려 한다.
댓글을 달아 주세요
RJS나 RHTML에 대해서 비스켓님 의견에 동의합니다. 그래도 어느 정도 AJAX의 진입장벽을 낮게 했다는 점에서 그 가치는 인정해야겠지요(저도 처음에는 와우~를 연신 외치며 열광했던 1인이라 ^^).
2007/11/26 00:48그런데, 마이그레이션은 아직 어떤 단점이 있는지 모르겠습니다. 개발 중에는 모르겠으나 실제 서비스가 Production 환경에 올라가면, 스키마를 점진적으로 변화해가는 마이그레이션이 큰 도움이 되더군요. 그 전에는 서비스의 DB 스키마를 변경하는 일이 몇차례 회의를 거치고도 꽤 긴장해야하는 일이었는데, 마이그레이션을 통해 관리가 되는 느낌이 들고 또 개발환경, 스테이지에서 그 스크립트가 검증이 되서 부담이 좀 줄어들었습니다.
아, SQL 대신 루비로 정의한 스키마가 안 좋은거라고 말씀하시는 거라면 저도 마이그레이션에서는 SQL을 직접 쓰는 일이 많습니다. 특히나 바뀐 스키마에 맞게 데이터도 변형해줘야하는 경우는 답이 없죠. 마이그레이션에서 모델 코드를 쓰는 것 또한 그리 추천할만한 방법은 아니더군요.
재미있는 주제, 공감가는 내용이라 지나가다 글을 남겨봅니다 ^^
deepblue님 안녕하세요! 마이그레이션에 대해서는 제가 생각이 짧았던 것 같습니다. 제가 개발환경(사용자 데이터가 쌓인 상황이 아닌)에서 마이그레이션의 업/다운을 빈번하게 사용하여 종종 마이그레이션이 실패하는 경우가 생겼는데, 그럴 땐 수정해가면서 마이그레이션을 완료시키기 보단 데이터베이스를 드롭하고 다시 만들어주곤 했었습니다.
2007/11/26 09:59그러다보니 실전 환경에서 마이그레이션을 얼마나 신중하게 다룰지 미처 상상하지 못했던 것 같습니다. 쿼리를 개발DB가 아닌 실전DB에 날릴 때 필요한 신중함을 가지고 마이그레이션 파일을 작성하면 마이그레이션이 실패할 리가 없을 것 같습니다. 말씀하신데로 마이그레이션을 통해 스키마 변경 계획을 명시하고 검토해서, 쿼리를 직접 날리는 것보다 안전하게 관리할 수 있을 것 같네요. 개발 단계와 실전 단계에서 마이그레이션을 대하는 신중함의 차이가 중요한 변수인 것 같습니다.
저 역시 마이그레이션을 너무 즐겁게 잘 사용해오고 있어서 좀 과격하게 이런 저런 단점을 생각해봤습니다. 마이그레이션을 'SVN처럼 빈번하고 가볍게 사용할 수 있는 버전관리 도구'라고 오해하지만 않으면 좋은 도구가 될 수 있을 것 같습니다. 저도 앞으로도 애용해야겠어요. deepblue님이 지적해주셔서 다행입니다. 루비 세미나에서 뵈요^-^
아..여기 고수분 두분이 있었네요..Flying Mate님의 글을 읽으면서 정말 공감했습니다. 지금 루비와 레일스를 동시에 공부를 하면서 뭔가를 만들어보겠다고 열심히 하고 있는데.. 마이그레이션은 정말 한번 뻑나면 수정하기가 힘들더군요.(개발모드에서) 아직 배포는 해본적이 없어서..그런지 모르겠습니다..
2007/12/04 17:00하여튼 저 또한 처음에 RJS 정말 와우~~ 할 정도로 이거 편하네.. 그렇게 생각하고 사용을 했지만..실질적으로 적용할 수 있는 부분이 폭이 좁더군요. 자바스크립트 처럼 맘대로 사용할 수 없었습니다. 아직 제가 초보라서 그런지..
루비에서 엑티브레코드에서 여러게 조인을 하는 경우는 정말.. sQL를 사용하는게 훨씬 편하더군요.
어째든 루비에 대한 매력은 충분히 느끼고 있습니다.
세미나에 참석해서 많은 배우고 싶은 욕심은 잔뜩 있지만, 여기는 부산이라. 가기가 싶지가 않네요..그리고 부산에서 루비를 하는 사람은 거의 없네요.
전무하다..이말 딱 맞을 듯....
다음에 또 들리도록 하겠습니다. 꾸벅 ^^
이노메이커님 안녕하세요. deepblue님은 진정 고수이시지만 저는 열심히 쫓아가는 하수입니다. 저도 잘 부탁드립니다.
2007/12/05 10:10