Rails가 던지는 질문: 개발 도구를 덜 고르면 더 빨라질까

핵심 요약

Rails는 데이터베이스 접근부터 서버에서 만드는 화면까지 공통 규칙으로 묶는 웹 프레임워크입니다.
정해진 관례를 따르면 도구를 고르고 연결하는 일을 줄일 수 있습니다.
통합 프레임워크를 써도 복잡한 업무 규칙과 성능 문제는 따로 해결해야 합니다.
생산성을 판단하려면 코드를 쓰는 시간뿐 아니라 테스트·배포·수정에 드는 시간도 봐야 합니다.

웹 서비스를 만들 때는 코드 작성 외에도 손이 많이 갑니다. 화면과 서버를 어떻게 연결할지, 데이터를 어떻게 저장할지 정하는 데도 시간이 듭니다. Rails는 이런 선택의 부담을 줄여주는 프레임워크입니다. 개발 과정에서 어떤 수고를 덜어주는지 살펴보겠습니다.

Rails는 무엇을 한데 묶을까요

Ruby on Rails는 Ruby 언어로 웹 애플리케이션을 만드는 프레임워크입니다. 사용자의 요청을 처리하는 일부터 데이터베이스를 읽고 쓰는 일까지 맡습니다. 그 결과를 화면에 보여주는 과정도 같은 틀 안에서 다룹니다.

상품 목록을 만든다고 해보겠습니다. Rails에서는 Active Record로 데이터베이스의 상품 정보를 다룹니다. 컨트롤러는 요청을 처리하고, 뷰 템플릿으로는 화면을 구성할 수 있습니다. 각 부분이 맡는 역할과 서로 연결되는 방식에는 기본 규칙이 있습니다.

이 규칙의 바탕에는 설정보다 관례라는 원칙이 있습니다. 파일을 어디에 두고 어떤 이름을 붙일지 팀이 처음부터 정하는 대신, 프레임워크에서 정해둔 규칙을 따릅니다.

규칙을 익히는 데는 시간이 듭니다. 대신 팀원들에게 프로젝트 구조를 일일이 설명하거나 매번 합의할 일이 줄어듭니다. 자유롭게 고를 수 있는 항목이 적은 만큼, 같은 결정을 되풀이하는 수고도 덜 수 있습니다.

도구를 연결하는 데도 시간이 듭니다

고객 정보를 등록하고 수정하는 관리 화면을 만든다고 해보겠습니다. 화면과 서버를 별도 애플리케이션으로 운영한다면, 둘 사이에서 데이터를 어떤 형식으로 주고받을지 정해야 합니다. 입력 오류를 전달하는 방식도 맞춰야 합니다.

이렇게 나누면 화면과 서버를 각각 독립적으로 개발하고 배포해야 할 때 편합니다. 다만 둘을 나눠서 운영하는 데도 손이 갑니다.

Rails에서 서버가 화면까지 만드는 구성을 택하면, 일부 작업을 한 애플리케이션 안에서 처리할 수 있습니다. 데이터를 처리하는 코드와 화면을 바꾸는 코드를 함께 검토하기도 수월합니다.

이때 줄어드는 것은 코드 몇 줄만이 아닙니다. 선택과 연결의 비용도 줄일 수 있습니다. 라이브러리를 비교하고 서로 다른 규칙을 맞추는 데는 시간이 듭니다. 문제가 생겼을 때 어느 쪽에서 원인을 찾아야 할지 가려내는 시간도 개발 시간에 들어갑니다.

소규모 팀에서는 이런 부담이 더 잘 드러납니다. 한 사람이 기능을 만들고 운영까지 맡는다면, 도구 사이의 연결을 직접 챙겨야 할 일이 적다는 점만으로도 도움이 될 수 있습니다.

복잡성은 어디까지 줄어들까요

그렇다고 Rails를 도입하면 어려운 문제가 모두 사라지지는 않습니다.

쇼핑몰에서 상품을 등록하는 화면은 비교적 단순할 수 있습니다. 하지만 쿠폰을 적용한 주문을 부분 취소하고 배송비까지 다시 계산해야 한다면 처리가 복잡해집니다. 이때 문제를 어렵게 만드는 것은 도구의 조합보다 업무 규칙입니다.

데이터베이스 조회가 왜 느린지 찾거나 사용자별 접근 권한을 설계하는 일도 여전히 필요합니다. 프레임워크가 기본 기능을 제공해도, 서비스에 맞게 쓰는 일은 개발팀이 맡아야 합니다.

관례를 따르는 데도 비용은 듭니다. 정해진 흐름대로 만들 때는 편하지만, 내부 동작을 모르면 예상 밖의 결과가 나왔을 때 이유를 찾기 어려울 수 있습니다. 설정을 많이 생략할 수 있을수록 프레임워크가 뒤에서 무엇을 처리하는지 알아야 합니다.

통합 프레임워크의 효과를 볼 때는 두 가지를 구분해야 합니다. 불필요한 연결 작업은 실제로 줄일 수 있습니다. 다만 프레임워크 내부에서 처리하는 동작은 필요할 때 이해하고 추적할 수 있어야 합니다.

우리 팀에 맞는지는 기능 하나로 확인할 수 있습니다

회원 정보, 게시물, 예약, 주문처럼 데이터를 등록하고 조회하는 기능이 중심이라면 Rails의 기본 구조와 잘 맞을 가능성이 큽니다. 같은 팀이 화면과 서버를 함께 바꾸는 환경에서도 하나로 묶어 쓰는 장점을 누리기 쉽습니다.

웹과 모바일이 같은 서버를 쓰거나 화면의 상호작용이 복잡하다면, 화면과 서버를 분리할 이유가 생깁니다. 이때도 Rails를 데이터와 기능을 제공하는 API 서버로 쓸 수 있습니다. Rails를 선택하더라도 모든 화면을 서버에서 만들 필요는 없습니다.

우리 팀에 맞는지 판단하려면 실제로 필요한 기능 하나를 끝까지 만들어보는 편이 좋습니다. 관리자만 상품 가격을 바꿀 수 있고, 바꾼 기록도 남기는 기능이 한 예입니다.

화면을 완성하는 데 걸린 시간만 재면 놓치는 부분이 많습니다. 권한 검사를 어디에 넣었고 테스트하기는 쉬운지 확인해야 합니다. 배포 과정도 봐야 합니다. 이후 “예약한 시각에 가격을 바꿔달라”는 요구가 들어왔을 때 얼마나 고쳐야 하는지까지 살펴보면, 처음의 선택이 적절했는지 더 잘 알 수 있습니다.

통합 프레임워크는 팀이 반복해서 마주치는 문제에 쓸 만한 기본값을 제공합니다. 그 기본값이 서비스에 잘 맞으면 제품 자체에 더 많은 시간을 쓸 수 있습니다. 지금 팀이 고객의 요구를 구현하는 데 시간을 많이 쓰는지, 도구를 연결하는 데 오래 매달리는지 살펴보면 Rails가 어디에 도움이 될지도 판단하기 쉬워집니다.