본문 바로가기

카테고리 없음

루비의 비밀 (레일스 VS 자바)

제가 한창 프레임워크에 관심을 가질 때 였습니다. 그때 회사에서 운좋게 두어가지 프레임워크를 만들고 있었죠. 회사에서 몇개 개발할 웹사이트에 쓰일 가벼운 프레임워크도 만들었습니다.

그때의 웹프레임워크는 스프링MVC의 기능을 이용해 만들었고 그럭저럭 잘 쓰고 있었습니다. 그러나 왠지 모르게 쓰기 불편하기도 했습니다. 질질 끄는 느낌이라고 할까요. 뭘 하나 수정하면 JSP, 클래스, XML파일등 여러 파일을 고쳐야 하니 지겹기도 했고, 특히 기억에 남는 점은 클래스 고치면 리로딩, XML 고치면 리스타트를 했는데 이때가 참 번거럽고 귀찮더군요.

진짜 좋은 프레임워크 구성 방식은 없을까, 웹 개발은 항상 짜증만 나야 하나, 이런 고민을 많이 했습니다. 그때 귀가 솔깃한 수식어를 단 어느 언어가 등장하더군요. 루비와 레일스 입니다. 아시다시피 루비는 언어이고 레일스는 루비로 구현한 웹 개발 프레임워크 입니다.

루비 앤 레일스의 수식어 입니다. “즐겁고 빠른 웹개발이 가능하다.” 정말이야? 저는 엄청난 의문을 품었습니다. 이 지겨운 웹개발을 즐겁게 해주고, 이 질질 끄는 웹개발을 빠르게 해준단 말이야 정말이야~?

저는 이 루비와 레일스도 거창한 수식어를 들고나온 탁상공론 기술이지 않을까 의심을 품었습니다. 그런데 거외 감이란게 있잖아요. 왠지 루비와 레일스는 정말 그 꿈의 수식어대로 뭔가 있어보이는 거에요. 그래서 저는 한번 루비와 레일스가 왜 즐겁고 빠른 웹개발이 가능하게 하는지 꼭 분석해야 겠다고 다짐했습니다.

그 뒤 1년이 훌쩍 지났습니다. 다짐만하고 실천이 안되는군요. 근데 이번에 다시 프레임워크 관련 기술에 관심을 가지면서 이번엔 기필코 루비와 레일스의 비밀을 파고들어야 겠다고 다짐했습니다.

정석으로 따지면 한번 제가 제대로 실습해보고 결론을 내려야 겠지만 시간이 없는 관계로 루비 온 레일스 책을 읽어보았습니다. 이제 루비와 루비 앤 레일스가 웹개발을 어떻게 즐겁고 빠르게 도와주는지 그 비밀을 파헤쳐 보자고요~!

[루비가 정말 루비야?]


루비 앤 레일스를 만드는 사람은 이런 질문으로부터 루비 앤 레일스를 만들었다고 해요. “모든 웹 개발에는 규칙적으로 반복되는 코딩 패턴이 존재한다. 이렇게 반복되는 코딩 작업을 프로그래밍으로 자동화할 수는 없을까?” 루비 앤 레일스의 가장 중요한 원칙은 DRY(반복적인 코딩 작업은 피하시오,Don’t Repeat Yourself) 입니다. 이 질문과 원칙에 따라 루비 앤 레일스에는 여러 기법들이 들어가 있습니다.


+ 설정보다는 관례가 편리하다.
이말은 프로젝트의 디렉토리, 네이밍 규칙을 프로젝트마다 개발자마다 내맘대로 결정하는게 아니라 루비 앤 레일스 프레임워크를 쓸 경우 그 규칙들이 강제로 정해져 있다는 뜻입니다.

첫번째로, 모든 루비 앤 레일스 프로젝트에는 디렉토리 구조를 동일하게 가야 합니다. 동일한 디렉토리 구조로 갈 경우 JSP는 어디다가 두고 XML 설정 파일은 저기에다 두어야 할지를 별도로 설정할 필요가 없는것 자체가 큰 장점입니다 .

근데 루비 앤 레일스의 디렉토리 구조를 동일하게 가는 특징은 자바에서 메이븐을 썼을 경우도 비스무리해 집니다. 메이븐도 디렉토리 구조를 관례적으로 정하고 있습니다. 그럼 루비 앤 레일스의 디렉토리 구조 관례화 특징을 자바에서 사용 하고 싶다면 메이븐을 쓰면 된다..고 하고요.

두번째로, 루비 앤 레일스에서는 네이밍 규칙이 관례적으로 정해져 있습니다. 예를들어 URL규칙에 따라 컨트롤러 이름, 파일이름, 메소드 이름까지 통일이 되어 있는 것이죠.

예를 들면 이렇습니다.
URL http://mysite.co.kr/album/list
클래스이름 AlbumController
파일 app/controller/album_controller.rb
액션 메소드 이름 list

만약 자바를 쓴다면 URL, 클래스, 파일마다 이름을 다르게 줄수도 있거나, 스프링의 나름 관례화된 규칙을 이용하여 저 루비 앤 레일스와 비슷한 효과를 가져올수 있습니다.

자바도 비슷하게 쓸수 있습니다. 그러나 루비 앤 레일스는 꽤 강제적입니다. 자바는 프레임워크단에서 저정도로 강제화 하지 않기 때문에 보통 ‘프로젝트 개발자 코딩 규칙’ 문서에 개발자가 알아서 따라줄것을 독려할 뿐입니다. 그러나 개발자가 개발하다보면 네이밍 규칙을 신경써서 지키기가 꽤 힘듭니다. 루비 앤 레일스는 따로 신경쓸 필요 없이 저절로 개발할수 있고요. 루비 앤 레일스가 표준화 면에서 더 좋은 장점을 가지는 것이죠.


+ 데이터베이스 버전 관리
우리가 프로젝트 하다보면 놓치는 부분이 데이터베이스 관리 입니다. 스키마를 변경하고 테스트 데이터를 넣었다 지웠다고 하는등 여러가지 관리할 것들이 있잖아요.


그런데 우리가 데이터베이스 관리를 잘하지 않는 이유는, 데이터베이스 관리하기가 싫어서가 아니라 그쪽 DB 관리하기가 꽤 어렵기 때문일것입니다. 스키마 변경, 테스트 데이터 넣는것 등의 작업들은 대개 직접 DB툴로 접근해서 수작업으로 해줘야 하니깐요.

루비 앤 레일스에서는 이런 데이터베이스 버전관리 기능을 프레임워크단에서 제공하고 있습니다. 한방에 스키마를 쉽게 조작할 수 있고, 얼마든지 예전버전으로 돌아갈수도 있고, 그 조작 명령어도 간편한것 같습니다.

이것과 비슷한 기능이 자바에도 있습니다. 지속적인 통합이란 책에 DB도 빌드 과정에 한방으로 관리해야 한다를 강조하고요. 메이븐에서 한방에 DB를 관리할수 있는 기능이 존재합니다.


+ 서버 구동모드 관리
내가 작은 웹 프레임워크를 만들고 프로젝트 하면서 가장 짜증났던 점은 바로 개발의 흐름을 끊어버리는 서버 리스타트 문제 였습니다. 사실 클래스는 잠깐 리로딩 하면 되긴 하는데 그 리로딩 하는 시간조차 무척 싫었습니다.

루비 앤 레일스도 크게 다르진 않을것 같긴 하지만, 루비 앤 레일스에서는 개발모드, 테스트 모드, 프로덕션 모드를 제공하면서 서버 리로링에 탄력적으로 대응이 가능하다고 합니다.

사실 리로딩 관련 기능은 자바 진영에서도 여러 기술이 나오고 있죠.


+ 액티브 레코드라는 ORM 맵핑 기술
루비 앤 레일스에서는 거의 관례적/의무적으로 액티브 레코드라는 ORM을 사용하는 듯 합니다. 자바의 하이버네이트, 아이바티스랑 비슷합니다.

그런데 역시 자바의 루비 앤 레일스의 차이점은 루비 앤 레일스가 강제성에 따른 표준화와 일관성이 더 높다는 점이죠. 예를 들어 자바에서는 ORM 좋긴 하지만 개발하다가 급하다 보면 익숙한데로 쓰기 마련입니다. 거외 지금 쓰면 나중에는 유익한데 당장 쓰기에는 귀찮은 기술들이 있잖아요. 이런 면에서 장점이 있을것 같습니다. 그외 액티브 레코드가 자바 진영의 ORM에 비해 좀더 쓰기 좋고 강력한 성능을 가졌는지는 저는 책만 읽어보고 정리하고 있기 때문에 다른 분이 답해주셔야 할것 같습니다.


+ 기타 스프링등의 자바 프레임워크에서 다 지원하는 기능들이 있다.
루비 앤 레일스의 전형적인 MVC 컨트롤러, HTML 폼 값 검증, HTML 레이아웃 설정, JSP의 JSTL과 비슷한 기능들은 모두 자바 진영의 웹 프레임워크에도 다 있고 비슷한 기능들이 있었습니다.


+ 정리하면
옛날부터 루비 앤 레일스가 왜 웹 개발을 편하게 즐겁게 해주는지 궁금했고 나름 판단을 해보려고 했습니다. 그랬더니 이게 뭐야~ 루비 앤 레일스의 기능 대부분은 자바 프레임워크에서도 충분히 제공하고 있었습니다.

그래도 루비 앤 레일스와 자바의 차이점을 한번 생각하면, 일단 루비란 언어의 간결성/사용성과 자바 프레임워크에서도 존재하는 루비 앤 레일스 기능 하나하나의 사용성과 성능 자체가 뛰어날 수 있다는 것입니다.

일단 같은 기능이지만 기능의 질을 무시하면 안되는 것을 저는 애플 제품을 통해 크게 느꼈는데요. 윈도우나 MacOS나 거기서 거기지..컴퓨터 디자인이 다 거기서 거기지...마우스가 다 거기서 거기지.. 했다가 애플 제품 써보고 저는 같은 제품이라도 이렇게 질이 다르구나라는 것을 한번 크게 느꼈거든요. 루비 앤 레일스 기능의 사용성과 성능 자체가 뛰어날 가능성도 있을 것 같습니다. 그런데 이점은 내가 루비 앤 레일스를 실제로 써보지는 않았기 때문에 판단은 어렵고요.


다른 장점은 바로 루비 앤 레일스의 표준화와 일관성의 강점입니다. 자바에서는 루비 앤 레일스 처럼 디렉토리 구조나 네이밍 규칙이나 ORM을 꼭 쓰라고 강제할 수 없습니다. 메이븐을 쓰면 자바에서도 프로젝트 구성을 일관되게 가져갈수 있지만 메이븐을 쓰는 곳은 이제 막 늘어나고 있을 뿐입니다.

루비 앤 레일스를 쓴다는 것은 루비 앤 레일스의 모토인, DRY원칙을 지향하기 위한 관련 규칙을 철저히 지켜야만 개발이 가능하다는 것입니다. 그 결과 루비 앤 레일스 개발자 모두가 표준화된 개발을 할 수 있고, 그래서 저절로 DRY 원칙을 지키게 될 것입니다.

마치 루비 앤 레일스는 애플의 앱스토어 정책과 비슷하고 자바는 안드로이 진영의 정책과 비슷합니다. 애플의 앱스토어는 개발규칙과 어플의 정책을 철저하게 지킬것을 강조하고요. 안드로이드는 커널도 자유롭게 쓸수 있을 정도로 개방적이고 자유롭죠. 각각 장단점이 있을 것입니다. 루비 앤 레일스의 독특한 정책에 따른 장점이 신선하게 다가옵니다.

이제 루비 앤 레일스의 비밀을 나름 알았으니 다음 자바 프레임워크 만들때 그 비밀을 사용해봐야 겠습니다.

웹 개발 2.0 루비 온 레일스 - 8점
황대산 지음/에이콘출판


덧) 실제로 루비 써보신 분의 이견/의견 없으신가요 ^ ^;