다음 프로젝트에서 rails new를 입력한 순간, 이제 무엇부터 해야 할까요? 모든 코드를 하나의 앱에 담을까요, 아니면 서비스 지향 아키텍처(SOA)를 선택할까요? RSpec을 배우기 좋은 타이밍일까요? 데이터 모델을 모두 설계하는 게 좋을까요, 아니면 몇 가지 기능을 처음부터 끝까지 동작하게 만드는 게 나을까요?
프로젝트 초기에 내려야 할 결정은 셀 수 없이 많습니다. 그래서 길을 잃고, 미루고, 답답해지다가 결국 앱을 완성하지 못하는 일이 자주 생깁니다.
이 문제는 놀랍도록 흔합니다. 정보가 가장 부족한 시점에 너무 많은 선택을 강요받기 때문입니다.
결정보다 관습(Convention Over Decision-making)
'설정보다 관습(Convention over Configuration)'은 제가 가장 좋아하는 Rails 원칙입니다. Rails를 접하기 전에는 파일을 어디에 둘지, 데이터베이스 테이블 이름을 어떻게 지을지, 테이블을 객체에 어떻게 매핑할지 같은 사소하고 무의미한 결정들에 발목 잡혔습니다. 방향을 고르는 데 드는 시간이, 나중에 판단이 틀렸음을 알고 갈아타는 데 드는 시간보다 더 길었습니다.
새 프로젝트를 시작할 때 마주하는 수많은 결정도 이와 비슷합니다. 하지만 책, 블로그, 스타일 가이드에서 관습(convention)을 빌려오면 이런 고민 자체를 없앨 수 있습니다. 시간과 스트레스, 의미 없는 논쟁도 함께 줄어듭니다.
새 앱을 시작할 때 제가 따르는 관습은 다음과 같습니다.
-
온전히 동작하는 핵심 기능 몇 가지부터 만듭니다.
앱이 처음부터 떠오르는 모든 기능을 갖출 필요는 없습니다. 작고 단순하게 시작하세요. 없어서는 안 될 한두 가지 기능을 정하고, 그것에 온 힘을 쏟아 아주 잘 만드는 겁니다. 나중에 필요하면 추가하면 됩니다. 아니, 어차피 YAGNI(You Aren't Gonna Need It)일 가능성이 큽니다. 그리고 대개 내가 필요하다고 생각하는 것과 고객이 필요하다고 여기는 것은 전혀 다르다는 사실을 깨닫게 됩니다.
-
단일 앱으로 시작합니다.
거대한 모놀리스(Monorail)를 피하고 싶은 마음은 압니다. SOA야말로 Rails 앱을 장기적으로 유지보수하기 좋게 만든다는 RailsConf 발표도 여럿 있었으니까요. 앱의 어떤 부분을 독립시킬 수 있을지 파악해서, 각 부분마다 서비스를 만들어야 하는 것 아닐까요?
SOA는 크고 복잡한 앱을 분리하는 데 훌륭한 방법입니다. 하지만 그만큼 엄청난 고통이 따릅니다. 서비스를 구축하고, 유지하고, 모니터링하는 고통이 모놀리식 Rails 앱을 다루는 고통보다 크지 않다면, 그럴 가치가 없습니다. 그리고 아직 앱 개발을 시작하지 않았다면 그 고통을 느껴본 적조차 없는 상태입니다. 그러니 하나의 앱으로 시작하세요.
-
사용해 본 적 있는 스택으로 시작합니다.
익숙한 스택이 없다면 오마카세(Omakase) 스택, 즉 Rails 기본 구성을 그대로 쓰세요. 어떤 경우든, 한 번도 써본 적 없는 테스트 프레임워크를 Rails에 연동하는 데 반나절을 허비하고 싶진 않을 겁니다. VCR과 WebMock의 버전 충돌을 잡느라 싸우고 싶지도 않고, 테스트가 깨졌을 때 그것이 내 실수인지 resque_unit 탓인지 추적하고 싶지도 않을 겁니다. 새 라이브러리를 써보고 싶다면 언제든 나중에 추가할 수 있습니다. 혹은 장난감 프로젝트에서 먼저 시도해 보세요.
배포(shipping)는 결코 쉽지 않습니다. 앱을 끝까지 완성하고 싶다면, 얻을 수 있는 이점이라면 하나라도 더 챙겨야 합니다. 그러니 작게, 단순하게, 그리고 아는 것부터 시작하세요.
관습이 항상 완벽한 것은 아니지만, 시작하는 데는 분명한 도움이 됩니다. 그리고 시작이 가장 어렵습니다.
다음은?
여러분은 프로젝트에서 어떤 관습을 따르시나요? 어떤 기능이나 테스트부터 시작할지는 어떻게 결정하시나요? 다음 글에서 제 생각을 공유하겠지만, 여러분의 경험도 꼭 들려주세요.