Ruby on Rails #24번째 소식

안녕하세요 구독자님,

이번 뉴스레터를 준비하면서 흥미로운 이야기들이 눈에 들어왔어요. Rails 소식을 모니터링하다 보니 자연스럽게 DHH의 글들이 가장 많이 보였는데요, 이번에는 자녀를 낳는 것의 의미를 다룬 내용이었어요.

DHH는 아이를 낳는 것이 재정적 상황과 관계없이 누구나 할 수 있는 가치 있는 일이라고 주장하며, 저출산 문제를 해결하기 위해서는 재정적 지원보다는 문화적 변화가 필요하다고 이야기했어요. 그가 공유한 다른 글에서는 문화적 변화가 시작되면 재정적 이유로 출산을 기피하는 현상도 자연스럽게 사라질 것이라는 주장도 덧붙였죠.

이 글 이후 Rails 엔지니어들이 X 프로필에 "부모 인증"을 하며 참여하는 모습이 이어졌는데요, 저출산 문제와 이를 둘러싼 논의가 우리나라와 크게 다르지 않다는 점이 특히 인상적이었어요. Rails 커뮤니티의 색다른 면모를 보여주는 이 이야기를 공유하고 싶었어요.

이번 주 소식은 Ruby Central이 Ruby Meetup에 보조금 지원, Mission Control Jobs 1.0 발표, 새로운 Ruby Version Manager, Validations와 Pull Request에 대한 소식을 다뤄봤어요.

새로운 소식

Ruby Central, Ruby Meetup 보조금 지원 안내

Ruby Central이 Fastly.com의 후원을 받아 전 세계 25개의 Ruby Meetup에 보조금을 지원한다고 발표했어요. 현재 지원 신청을 받고 있으며, 지원금은 주류를 제외한 행사 준비 및 운영 비용에 사용할 수 있어요.

한국에서는 Ruby 모임이 상대적으로 적지만, 이런 기회를 통해 새로운 모임을 시작하거나 기존 모임을 활성화할 수 있을 것 같아요. 특히 다양한 지역에서의 신청을 중요하게 여길 가능성이 높기 때문에 한국 내 모임이라면 눈에 띌 가능성이 있지 않을까 하는 생각도 드네요.

Mission Control Jobs 1.0 발표

37signals의 엔지니어인 Rosa Gutiérrez가 Mission Control Jobs 1.0버전 릴리즈를 공개했어요. 이 프로젝트는 Solid Queue나 Resque를 활용할 때 백그라운드 작업의 운영을 돕는 대시보드와 확장 기능을 제공해요.

현재 37signals에서는 HEY와 Basecamp4 프로젝트에서 이 툴을 함께 사용하고 있으며, 앞으로 Rails에 Solid Queue와 함께 기본으로 탑재하기 위해 지속적으로 개선할 계획이라고 해요.

저는 주로 사이드킥을 사용했기 때문에 아직 Mission Control jobs를 직접 사용해본 경험은 없지만, 최근에 Rails8로 개인 프로젝트를 구성하고 있어서 실제로 사용해보고 후기를 전해볼 수 있을 것 같아요. 개인적인 느낌으론 GitHub 레포지토리에 공개된 사진만으로 봤을 때는 여전히 사이드킥이 더 마음이 가긴 하네요 😅 하지만 Solid Queue와의 통합과 Rails 생태계와의 호환성을 생각하면 앞으로의 발전이 기대가 되기도 해요.

새로운 Ruby 버전 매니저 - Mise

Mise는 Josef Strzibny가 새로운 Ruby 버전 매니저를 찾았다고 공유한 도구로, rbenv, asdf, pyenv처럼 다양한 개발 도구를 관리할 수 있고 direnv처럼 프로젝트 디렉토리별 환경 변수를 관리할 수 있어요. 또한 make처럼 프로젝트를 빌드하고 테스트하는 데 필요한 작업을 효율적으로 관리할 수 있다고 해요.

간단히 살펴봤을 때는 toml 파일로 프로젝트마다 설정을 다르게 관리할 수 있고, shims와 PATH를 업데이트하는 방식 모두 지원해서 성능적으로 더 나은 모습을 보여준다고 해요. 또한 asdf와 관련 플러그인과도 호환이 되기 때문에 asdf가 가지고 있던 문제들도 해결할 수 있다는 의견도 있었어요.

저는 현재 rbenv를 기본으로 사용하며, asdf로 다른 언어들을 관리하고 있어 Mise로의 전환은 아직 고민 중이에요. 하지만 Greg Molnar처럼 Rails 생태계에서 Mise를 사용하기 시작하는 목소리가 점차 늘어난다면, 한번 시도해볼 가치는 있을 것 같아요.

Rails Validations: 어디까지 신뢰할 수 있을까?

Rob Zolkos가 ONCE의 Campfire와 Writebook에서 사용된 validation 구현 사례를 언급하며, 대부분 데이터베이스 제약사항이나 클라이언트에서의 예외 처리에 의존한다고 이야기를 시작했어요.

이에 대해 Rails 가이드 문서에서는 데이터베이스 제약을 제거하고 Rails의 validation을 권장한다는 점을 언급하는 의견과, 비즈니스 로직에 의존성이 있는 경우에는 다른 접근이 필요하다는 의견이 엇갈렸는데요.

흥미롭게도, DHH는 이 토론에 참여하며 “서버의 validation이 UI로 노출되는 것은 안티패턴이다”라는 입장을 밝히며, 사용자가 유효하지 않은 데이터를 서버로 전송하지 않도록 해야 한다고 주장했어요. 또한 Rails 9에서 관련 helper를 개선하겠다고 언급했어요.

이후 쓰레드에서는 다양한 의견이 나왔는데요:

모델 validation과 데이터베이스 제약 조건을 결합해 사용하는 방식을 선호하는 의견
클라이언트에서 validation을 우회할 가능성이 있기 때문에, 클라이언트 validation을 신뢰하지 않는다는 입장

구독자님은 어떻게 생각하시나요?

저는 어느 한쪽이 절대적으로 옳다고 보긴 어렵다고 생각해요. 프로젝트의 성격과 상황에 따라 적절한 선택이 필요하겠죠. DHH의 주장처럼 서버의 validation 로직이 사용자 UI에 노출되는 것이 안티패턴일 수 있지만, “어떻게 보여지는지”가 관건이라고 생각해요.

예를 들어:

이메일 형식이 잘못되었다는 에러 메시지는 사용자 경험을 돕는 방향이 될 수 있어요.
반대로, 비즈니스 로직이나 보안에 관련된 상세한 에러 메시지를 노출하는 것은 분명히 피해야겠죠.

Rails 9의 새로운 helper가 어떤 방향으로 개선될지 기대됩니다.

오랜 시간 진행되는 Pull Request의 장점

2022년에 작성한 블로그와 함께, DHH가 오랜 시간 진행되는 Pull Request(PR)의 장점에 대해 이야기를 공유했어요.

DHH는 PR을 작은 단위로 쪼개기보다는 하나의 큰 PR로 처리하는 것이 더 바람직하다는 입장이에요. 그는 블로그에서 PR을 “비용”의 관점이 아닌 “가치”의 관점에서 바라봐야 한다고 지적해요.

DHH는 큰 PR의 장점을 아래와 같이 이야기하고 있어요.

디자인 표준과 아키텍처의 일관성 유지: 여러 개의 개별적이고 단절된 PR보다 큰 그림을 중심으로 코드 리뷰를 진행하면, 더 나은 구조적 무결성을 유지할 수 있어요.
셀프 코드 리뷰의 중요성: DHH는 PR을 스스로 리뷰하는 습관을 강조하며, 이것이 조직적 코드 품질을 높이는 강력한 도구라고 주장해요.
조직의 상황에 따른 적합성: 큰 PR은 소규모 시스템에서는 적합하지만, 수백만 줄의 코드베이스를 운영하는 대기업에서는 비효율적일 수 있어요.

저는 일하면서 다양한 크기의 PR을 경험했어요. DHH가 말하는 큰 PR은 흔히 “빅뱅 PR”이라고 불리며, 리뷰가 어렵고 부담스러운 경우가 많았어요. 그래서 최근에는 잘게 쪼개진 PR을 더 선호하는 편이에요.

다만 DHH의 의견에서 공감이 갔던 부분은 일관된 아키텍처 유지의 중요성이에요. 조직 내에서는 종종 “깨진 창문”처럼 일관성을 잃는 경우가 발생하고, 이를 다시 복구하는 데도 많은 노력이 필요하다는 것을 경험적으로 이해하기도 했어요.

각 조직의 환경과 상황에 따라 PR의 전략은 달라질 수밖에 없어요. 특히, 동료 간 코드 리뷰를 진행할 때는 컨텍스트를 충분히 이해하기 어려운 상황도 자주 발생해요. 그렇기 때문에 저는 여전히 이해 가능한 수준으로 PR을 나누는 것이 실질적으로 더 효과적이라고 생각해요.

마지막으로, PR의 크기나 방식보다 중요한 것은 일관된 아키텍처와 방향성에 대해 동료들과 지속적으로 소통하는 것이라고 생각해요. PR이 크든 작든, 팀 전체가 같은 목표와 비전을 자주 공유하는 것이 DHH가 이야기하는 가치에 더 가까이 다가갈 수 있지 않을까하는 생각이에요.