번역자: "lenani":lenani

상태: -번역- -> -교정- -> *출시* <BR> 완성일: 2005년 9월 8일 목요일

원문: http://www.oreillynet.com/pub/a/network/2005/08/30/ruby-rails-david-heinemeier-hansson.html

O'Reilly Network Published on O'Reilly Network(http://www.oreillynet.com)

h1. Ruby on Rails: David Heinemeier Hansson씨와의 인터뷰

by Edd Dumbill

08/30/2005

떠오르는 유명 플랫폼 Ruby on Rails에 대해서 모르는 사람은 거의 없을 겁니다. Rails의 제작자인 David Heinemeier Hansson씨는 이번에 열린 OSCON에서 여러 사람을 놀라게 했습니다. 그리고 이번 10월에 암스테르담에서 열릴 European O'Reilly Open Source Convention에서 강연을 하기로 되어 있습니다.

Heinemeier Hansson씨는 덴마크 코펜하겐에 살고 있습니다. 창조적인 37signals에 참여하고 있으며 프로젝트 관리 웹 어플리케이션인 Basecamp의 제작자입니다. O'Reilly Network는 그와 Rails의 성공과 앞으로의 전망에 대해서 이야기를 나눠봤습니다.

h2. Ruby on Rails의 성공

Edd Dumbill: Rails는 이미 너무 유명해졌습니다. 지난 2004년과 같이 계속 이 유명세를 지속할 것으로 생각하십니까?

David Heinemeier Hansson: 글쎄요. 누구도 지금 Rails의 인기를 예측하지 못했을 겁니다. 그러나 제 생각에는 Rails는 계속 유명해 질것 같습니다. 저는 Rails를 사용해서 작업을 하는데요 예전에 비해서 즐겁고 생산성이 많이 향상됨을 느낍니다. 다른 사람도 분명 그렇게 느낄 겁니다.

저는 2개의 서로 다른 배경을 가지고 있습니다. PHP로 오랫동안 작업을 했습니다. 그래서 결과를 빨리 확인하면서 일을 빨리 하는데 익숙해져 있습니다. 또한 동시에 대학에서 교육을 받았고 J2EE를 사용하는 곳에서 Java를 사용해 본적도 있습니다. 그런 경험때문에 패턴이라든지 여러가지 습관으로부터 나오는 순수함과 좋은 유지보수성에 대해서 알고 있습니다.

그래서 소프트웨어 개발의 두 진영에 모두 익숙합니다. PHP로 대변되는 문화는 빠르지만 좋은 코드는 아닙니다. 반면 Java로 대변되는 문화는 느리지만 좋은 코드를 만듭니다. 이 두개의 문화를 합치면 빠르고 좋은 코드를 만들게 되고 이것은 양쪽 진영에 환영을 받을 겁니다.

ED: 그것이 Rails의 인기 비결이라고 생각하십니까?

DHH: 그것 하나만은 아닙니다. 그건 좀더 설명하기 복잡합니다.

한가지 원인을 생각한다면 Rails는 철학을 가진 소프트웨어 입니다. Rails는 소프트웨어에 관한 낡은 생각들을 떨쳐버렸습니다. 그런 낡은 생각중 하나는 될수 있으면 많은 방식을 포용해야 된다는 겁니다. 그런 낡은 생각에 의하면 우리는 어떤 방법이 다른 방법보다 좋다고 판단 내리면 안됩니다. 그러나 Rails는 그런 판단을 내립니다. 저는 그것이 Rails의 성공 비결이라고 생각합니다.

Rails는 저수준의 유연함을 고수준의 유연함을 얻기 위해서 포기합니다. Rails의 방식에 따르게 되면 고수준에서 얻어지는 생산성 향상이라는 보상을 받게 됩니다.

그것이 쉽게 결정내려질것이 아니라는걸 잘 알고 있습니다. 한번 코딩 규칙에 관한 논쟁을 살펴봅시다. 모든 개발자가 괄호를 어디다 두어야 할지 정하면 읽기 쉽고 동일한 형태의 코드를 얻을수 있습니다. 그러나 많은 개발자들은 그렇게 생각하지 않습니다. 그들은 개발자에게 자유를 주는 것이 코딩 규칙을 강제로 적용하는 것보다 중요하다고 생각합니다.

Rails는 코딩 규칙과 비슷한 역할을 합니다. 개발자에게 자유를 빼앗긴 하지만 Rails가 인기있는 것은 그 댓가로 얻는 것이 매력적이기 때문입니다. 공통 형식의 코드를 얻는 것은 모호하고 그룹의 입장을 반영한 겁니다. 금방 동작하는 결과물은 구체적이고 개인적인 보상입니다.

철학을 가진 소프트웨어 특징중 하나는 구성 대신에 관습을 따른다는 겁니다. 클래스는 단수이고 테이블은 복수라는(사람 클래스는 사람들 테이블과 연관된다) 몇가지 기본적인 관습을 따르면 이 둘간의 관계를 설정할 필요가 없습니다. 클래스는 자동으로 어떤 테이블이 persistence를 위해서 사용되는지 알게 됩니다. 우리는 이런 방식을 많이 사용합니다. 그래서 이것은 매일 사용할수록 이것이 더 좋다는 것을 느끼게 됩니다.

ED: 37signals를 제외한 곳에서 Rails의 강력함을 느껴보신적 있으십니까?

DHH: 43things.com의 성공에 많이 만족합니다. Robot Co-op는 Rails가 출시 되자마자 Rails를 적용한 첫번째 대기업일 겁니다. 그들은 독특한 모토가 있는데요, 그것은 사람들을 도와서 인생의 목표에 도달할수 있게 하자 입니다. 좋은 생각 아닙니까?

게다가 그것은 잘 동작합니다. Nat Torkington씨가 내 목표중 하나인 "500명 이상의 사람에게 Rails에 대해서 강연한다" 를 보게 되어서 OSCON에서 강연을 하기로 계약했었습니다. 그래서 이번 8월에 OSCON에서 2000명의 사람들 앞에서 강연을 하게 된 것입니다.

그러나 무엇보다 Rails가 빨리 퍼지고 상업적으로도 성공하게 된것을 본것이 가장 기쁩니다. Rails 전문 프로그래머들이 40개국에서 3000명 이상으로 집계되었습니다. 저는 그 숫자가 너무 빨리 늘어나서 놀랐습니다.

ED: Rails의 어떤 기능이 가장 맘에 드십니까?

DHH: 맘에 들지 않는 것들 모두가 그렇습니다. 우리가 아니라고 한 모든 기능이 그렇습니다. 우리가 꺼버렸던 장식품들이 그렇습니다. 80%의 문제를 해결하는 20%의 해결방식들이 그렇습니다.

구체적으로 말하자면 우리가 사용하는 문제 중심적인 언어가 맘에 듭니다. 관계를 설정할때 belong_to, has_one, has_many, has_and_belongs_to_many를 사용하는 것이 맘에 듭니다. validates_presence_of :name 처럼 검증 코드를 쉽게 만들수 있다는게 맘에 듭니다.

h2. 프로그래밍 언어

ED: Rails를 처음 봤을때 Ruby언어로 만들어졌다는게 꺼려지더군요. Ruby는 널리 알려진 언어가 아닙니다. 어떻게 Ruby를 사용하게 됐습니까?

DHH: 2003년 여름에 Rails를 만들기 시작했습니다. 37signals는 Basecamp의 개발을 시작하고 있었습니다. Basecamp는 그 회사를 컨설트 회사에서 개발 회사로 바꿔 놓을 제품이었습니다. 우리는 PHP를 사용하고 있었고 쓸만하고 재사용 가능한 프레임워크를 찾는데 고생하고 있었습니다. 그때는 Rails가 PHP로 만들어졌었고 저는 그것에 대해서 별로 좋지 않은 기억을 가지고 있습니다.

그때는 그대로 진행하던지 다른 방향으로 전환하던지 해야 했었습니다. 그때 맘에 안드는 도구를 참고 쓰느니 차라리 좋아하는 도구를 쓰는게 좋겠다고 생각이 들었습니다. 그래서 다른 대안을 찾기 시작했었습니다.

그당시 이런 생각이 떠올랐습니다. 저는 the Pragmatic Programmers라는 책과 Martin Fowler씨의 팬이었습니다. 그리고 이곳 저곳에서 Ruby 언어가 등장하는 것을 봤었습니다. 제 친구중 하나가 Ruby를 시험해보고 왜 PHP를 사용하냐고 물어봤었습니다.

그래서 잠시나마 왜 Ruby가 필요없고 PHP를 꼭 써야 하는지 설명했었습니다. Ruby 프로그래머는 찾기가 힘들거다. PHP는 좋은 라이브러리가 더 많다. 이렇게 말했습니다. 그러나 다행스럽게도 그 기간은 길지 않았습니다. 우리는 Ruby를 사용해 보기로 결정했었습니다.

"Ruby가 정말 좋은데."라고 말하는데 딱 하루가 걸렸습니다. "이젠 PHP로 못하겠어."라고 말하는데 딱 일주일 걸렸습니다. 그리고 그로부터 한달이 안돼서 PHP보다 Ruby에 더 익숙해져 버렸습니다. 정말 Ruby는 나한테 딱 맞았습니다. 나는 더 재미있게 더 많은 작업을 할수 있게 되었습니다.

PHP가 나쁘다는 소리로 들릴지 모르겠습니다. PHP도 좋습니다. PHP는 활용도가 뛰어나서 처음에 PHP를 사용해서 프로그래밍을 시작했습니다. 나는 오랫동안 PHP를 사용했습니다. 그냥 PHP의 한계를 벗어나는 지경에 이르렀을 뿐 입니다. Ruby는 현재 상태에서 가장 좋은 언어입니다.

ED: Rails가 Java나 Python을 사용했을면 좋았을 거라고 생각된 부분이 있었습니까?

DHH: 더 좋다라는 말은 이런 비교를 하기에는 부적절한 말 같습니다. 만약 Rails가 Java로 만들어졌다면 기업용으로 더 쉽게 유명해졌을 겁니다. 그러나 저에게는 이것이 성공이라고 생각되지 않습니다. 저는 제가 하는 일을 더 쉽고 빠르게 하기 위해서 Rails를 만들었습니다. 기업용으로 성공하기 위해서 Rails를 만들지 않았습니다. 어쨌든 지금 Rails는 성공했습니다. 하지만 만약 그런 의도로 Rails를 만들었다면 아마 성공하지 못했을 겁니다.

Python의 경우는 잘 모르겠습니다. 밖에서 보면 두 언어는 아주 비슷해 보입니다. 그러나 일단 두 언어를 잘 알게 되면 전혀 다르게 느껴지는 작은 차이들이 있습니다. Python 도 분명히 좋은 점이 많습니다. Ruby에 좋은 점이 전혀 없었더라면 아마도 Rails는 Python으로 만들어졌을 겁니다.

Rails는 정말 Ruby와 비슷하게 느껴집니다. Rails는 Ruby에 많이 의존합니다. 예를 들면 block, 상황에 맞게 언어를 만들수 있는 능력등이 있습니다.

ED: 지금은 PHP나 Perl을 사용해서 웹 어플리케이션을 만드는게 좋다고 생각하십니까?

DHH: 네. Rails는 만능이 아닙니다. 웹페이지에 동적인 면이 필요할때는 지금도 PHP를 사용하고 있습니다. 37signals 에서도 모든 광고 페이지는 PHP를 사용하고 있습니다.

반면 Rails는 커다란 웹 어플리케이션에 적합합니다. 그래서 Basecamp, 43things.com, ODEO, Strongspace와 같은 규모의 어플리케이션을 만들때 PHP나 Perl을 사용하는게 좋냐고 물어본다면 당연히 내 대답은 아니오 입니다.

그러나 상황에 따라서 어쩔수 없이 할수 밖에 없을 때도 있을 겁니다. 그러나 제 생각에는 그런 상황이 너무 과장되어있습니다. 예를 들면 Ruby 프로그래머가 없어서 Rails를 사용할수 없을수 있습니다. 다른 환경에 너무 익숙해져 있어서 바꾸기 싫을때도 있습니다. 이런 것들은 변명에 불과 합니다. 좋은 프로그래머는 그런것에 연연하지 않습니다. Rails는 생각보다 당신이 하던 일과 아주 비슷합니다. 더군다다 Rails는 배우기 쉽습니다.

h2. 웹 어플리케이션 프레임웍

ED: Rails를 사용할때 좋은 점중 하나가 출시 환경과 개발 환경이 분리되어 있다는 겁니다. 그런 기능들은 스크립트 언어 웹 도구에선 볼수 없습니다. Rails를 만들때 기업 환경을 염두에 두고 있었습니까?

DHH: 저는 저의 일을 편하게 할수 있는데만 신경을 썼습니다. Rails는 그런면에서 보면 이기적인 프로젝트 입니다. 제가 겪는 문제를 겪지 않는 사람들을 위해서 만들지 않았기 때문에 Rails가 많은 인기를 얻었다고 생각합니다. 출시 환경과 개발 환경이 달라서 생기는 문제는 저에게는 현실적인 문제였습니다. 그래서 그 문제를 해결한것 뿐입니다.

다른 사람을 시켜서 내 문제를 해결하기는 어렵습니다. 다른 사람의 문제를 해결하는 것도 거의 불가능 합니다. 만족의 관점에서 본다면 더욱 그렇습니다.

그래서 프레임웍은 만들어진다고 하는 겁니다. 프레임웍은 문제가 발생하기 전에 존재하는 것이 아닙니다. 프레임웍은 문제를 해결한 결과로서 만들어집니다. 우리가 미리 생각해서 만들어지는 과정을 생략해 버린다면 그 결과는 그냥 문제 해결 이전의 상태로 되돌아오는 것 뿐 입니다.

나는 그래서 많은 사람들이 Rails를 좋아한다고 생각합니다. 앞으로 일어날 일에 대해서 미리 대비하기 이전에 진정으로 사람들을 돕기 때문입니다.

ED: 관계 데이터베이스가 필요의 90%를 충족하지만 때로는 다른 저장 수단이 더 편리할 때가 있습니다. 객체 데이터베이스나 RDF 저장소를 Rails에 추가할 생각은 없습니까?

DHH: Rails는 그 어떤 저장 형태라도 지원합니다. 제가 Instiki라는 위키를 만들었는데요, 최근에 Rails를 사용해서 다시 만들었습니다. 저장 수단으로는 Madeleine을 사용합니다. Madeleine은 객체 데이터베이스와 비슷한 역할을 하는 Prevayler를 Ruby를 사용해서 구현한 겁니다.

Active Record를 대신해서 다른 저장 수단을 사용하는 것은 아주 쉽습니다. 최근에 SOAP, SAP, LDAP, 기타 등등을 저장 수단으로 사용하는 것을 목격하고 있습니다. 심지어는 보통 text 파일을 사용하기도 합니다. 어떤 것 이라도 가능합니다.

하지만 Active Record는 객체와 관계의 불일치 문제를 좀더 쉽게 다룰수 있게 합니다. 그래서 SQLite 처럼 일반 text 파일과 같은 느낌이 나지만 SQL을 쓸수 있는 데이터베이스를 쓰지 않다도 될 정도 입니다.

그래서 Active Record가 점점 나아질수록 Madeleine 같은 프로젝트에 덜 신경쓰게 됩니다. 그런 다른 방식이 나쁘다는게 아닙니다. 다만 다른 방식에 신경쓸만큼 상황이 나쁘지 않다는 겁니다.

ED: 상당히 편리한 웹 프레임웍들이 점점 커지고 관리가 점점 어려워지고 있습니다. 예를 들면 Zope가 그런데요. 이런 문제들을 피해갈 방도가 있습니까?

DHH: 기반 구조에 머무르십시오. 비지니스 로직을 제외시키십시오. Rails는 content management, access control lists, forums, chats 등등을 다루지 않습니다. 우리는 Rails가 기반 구조가 되어 어떠한 어플리케이션이라도 될수 있게 신경쓰고 있습니다.

우리는 Rails를 Zope나 Open ACS처럼 만들지 않을 겁니다. 우리는 Rails를 비지니스 로직에 흡수된 프레임웍으로 만들지 않겠습니다.

우리는 많은 사람들이 어떠한 어플리케이션이라도 좀더 쉽게 만들수 있게 하고 있습니다. 예를 들면 다음 버전의 Rails에는 Switch Tower라는 새로운 하위 프로젝트를 준비하고 있습니다. 그것은 어플리케이션을 배치하기 위해서 사용됩니다. 배치의 어려움은 모든 어플리케이션이 안고 있는 문제입니다. 하지만 Switch Tower를 사용하면 개발 프로세스가 복잡해지지 않습니다. default 설정을 많이 사용할 필요가 없기 때문입니다. Rails는 당신의 문제를 해결하기 위해서 존재합니다.

ED: 다음으로 나올 Rails의 새 기능은 무엇입니까?

DHH: 이미 Switch Tower가 다음에 나올 새 기능이라고 말 했습니다. 하지만 지금 당장은 1.0을 다듬는 일을 하고 있습니다.

그 일이 끝나면 할 여러가지 계획을 가지고 있습니다. The Conductor라는 것에 특별히 관심이 갑니다. 그러나 아직은 여러사람에게 공개하지 않을 생각입니다.

Edd Dumbill씨는 O'Reilly Network에서 편집자로 일하고 있습니다. 또한 Mono: A Developer's Notebook의 공동 저자이기도 합니다. 동시에 GNOME에서 돌아가는 공개 소프트웨어 개발자입니다. 데비안 GNU/Linux 배포판에서 Bluetooth에 관련된 소프트웨어의 패키징을 수행하기도 합니다. Behind the Times라는 블로그도 운영하고 있습니다.

Copyright © 2005 O'Reilly Media, Inc.

<hr>

If you want to send us any correction, recommendation, or idea, feel free to email us at: objectorientedkick (at) gmail_dot_com