Ruby on Rails 서비스 객체의 숨겨진 아이디어와 최적의 코드 구성 방식

Ivan Nemytchenko, "The Curse of Service Objects"

작성자
EuRuKo
발행일
2025년 01월 13일

핵심 요약

  • 1 Ruby on Rails에서 서비스 객체는 복잡성을 조직화하는 사실상의 표준이지만, 내부적으로 복잡성을 증가시키는 비효율적인 방식입니다.
  • 2 강연자는 비즈니스 규칙, 데이터 변이, 컨트롤러 로직 등 '작업 유형별'로 코드를 분리하여 계층형 아키텍처를 구축하는 새로운 방법론을 제시합니다.
  • 3 이는 기존 서비스 객체의 모호한 개념을 벗어나, Martin Fowler와 Eric Evans의 '서비스 레이어' 및 '도메인 서비스' 개념에 부합하는 명확한 코드 구조를 제안합니다.

도입

본 강연은 Ruby on Rails 애플리케이션에서 널리 사용되는 '서비스 객체(Service Object)'의 개념과 그 한계점을 심층적으로 분석하고, 보다 효율적인 코드 구성 방안을 제시합니다. 2006년부터 Rails 개발에 참여해 온 베테랑이자 현재 cle.com의 CTO인 강연자는, 서비스 객체가 Rails에서 복잡성을 조직화하는 '사실상의 표준'이 되었음에도 불구하고 실제로는 '가짜 개념(fake concept)'에 가깝다고 주장합니다. 강연의 주요 목표는 서비스 객체의 '형태(shape)'에 초점을 맞추고, 이를 설명하기 위해 고안된 '코드 토폴로지 표기법(code topology notation)'을 활용하여 코드의 복잡성 증가 양상을 시각적으로 보여줍니다.

강연자는 ‘코드 토폴로지 표기법’으로 객체, 메서드 등을 시각화하여, 서비스 객체들이 공통적으로 ‘생성자, 하나의 public 메서드, 다수의 private 메서드’ 형태를 가지며, GitLab 사례처럼 시간이 지남에 따라 내부 복잡성이 심화됨을 지적합니다. 이에 대한 대안으로, 강연자는 ‘Painless Rails’ 방법론의 세 가지 원칙을 제시합니다: 계층형 아키텍처 실천, 단일 추상화 수준 유지, 그리고 코드를 ‘작업 유형(types of work)’별로 분리하는 것입니다.

강연자는 서비스 객체 리팩토링 시연을 통해 이 원칙들을 적용합니다. 비즈니스 규칙은 User 모델로, 데이터 변이 로직은 ‘Mutators’ 함수로, 컨트롤러 로직은 다시 컨트롤러로 분리합니다. 그 결과, 원래의 서비스 객체는 고수준의 ‘오케스트레이터’ 역할을 하는 단일 함수로 간결해집니다. 이러한 재구성은 모델, 변이, 서비스, 컨트롤러로 이어지는 명확한 계층형 아키텍처를 확립하며, 모듈성 및 테스트 용이성을 향상시킵니다. 강연자는 현재 서비스 객체 사용 방식이 Rails의 계층형 아키텍처를 훼손하고 책임을 모호하게 만든다고 비판합니다. 또한, Martin Fowler의 ‘서비스 레이어’와 Eric Evans의 ‘도메인 서비스’ 개념을 언급하며, 진정한 도메인 서비스의 특징들(상태 비저장, 비즈니스 오퍼레이션 표현, 도메인 객체 조정 등)을 ‘Fowler-Evans Ruler’로 제시합니다.

결론

강연자는 '서비스 객체'라는 용어가 '텅 빈 개념'이자 '텅 빈 추상화'이므로 사용을 지양하거나, 사용 시 명확한 의도를 가져야 한다고 조언합니다. 대신 코드의 '작업 유형'에 따라 적절한 빌딩 블록을 구성하고, Martin Fowler와 Eric Evans의 원칙에 따라 서비스의 역할을 명확히 정의할 것을 제안합니다. 강연자는 자신의 웹사이트(rails.services)에서 관련 자료와 'Fowler-Evans Ruler'를 적용할 수 있는 ChatGPT 도구를 제공하며, 서비스 객체에 대한 다양한 의견을 가진 개발자들과의 지속적인 토론을 독려하며 강연을 마무리합니다.

댓글 0

댓글 작성

0/1000
정중하고 건설적인 댓글을 작성해 주세요.

아직 댓글이 없습니다

첫 번째 댓글을 작성해보세요!